Автозадачи

Управление - Бизнес-процессы

Универсальный механизм управления потоками задач в информационной базе 1С. Самый востребованный инструмент из "кастомизации на лету".

Итак, дошла очередь до Автозадач. После доклада "Кастомизация на лету" многие коллеги обращались с просьбами опубликовать какие-нибудь решения. Особенно часто упоминали автозадачи.

Суть проста (как и реализация, впрочем). Довольно часто нужно, чтобы пользователям информационной системы ставились задачи. Причины разные - или что-то пошло не так, или надо что-то доделать, или обработать связанные данные, или выполнить свой кусок процесса.

Самый простой и востребованный пример - отложенное исправление ошибок (когда ошибку сразу не видно или нельзя исправить). Например, бухгалтер забыл сделать выписку и у исходящих платежек не стоит признак Оплачено. Или возникли отрицательные остатки по товарам в бух.учете. Или числится одновременное сальдо на 60.01 и 60.02. И т.д.

Такого рода ошибки сразу никто не кидается исправлять, и это зачастую не так просто. Ошибка может быть создана не одним, а несколькими документами и пользователями, поэтому с ней не справляются средства контроля при записи, наподобие Проверки данных.

Казалось бы - ну и ладно. Можно использовать отчеты с нужными настройками. Можно использовать средства контроля, наподобие Проверки ведения учета.

А нет, не ладно. Отчеты обладают существенным недостатком - они требуют дисциплины и внимания. Человек должен не забыть зайти в отчет. А когда не забыл - должен не полениться. Не говоря уже о том, что он должен сделать то, чего от него требуется.

Мы, допустим, человеку не доверяем. Хотим знать, работает ли он с проблемной областью. Как это проверить? Путь один - тоже заходить и смотреть те же отчеты. Если там совсем ничего не происходит, вывод очевиден - не работает человек. А если что-то меняется, но ошибки все равно все время есть? Как часто он работает с этими ошибками? Сколько исправляет в день или неделю? Сколько времени эти ошибки уже болтаются в базе? А если мы - ребята продвинутые, и хотим управлять негативными состояниями по принципу Айсберг?

Теперь уберем слово "ошибка", заменим словом "задача". Нам нужно, чтобы человек что-то сделал - неважно, исправил ли ошибку, согласовал ли заявку, оформил ли перемещение, создал ли бюджет, совершил ли 10 звонков, и т.д. Как автоматизировать управление такими задачами?

Обычно мы делаем либо бизнес-процессы (через конфигуратор или какой-нибудь рисовалкой из типовых решений), или кучу отчетов, или букет разнообразных напоминалок/выскакивалок/письмоотправлялок.

Автозадачи значительно упрощают этот процесс:

  • автоматически создают задачи, когда возникли подходящие условия;
  • описывают необходимый контекст задачи - ссылки на документы, справочники, приводят количественные данные;
  • автоматически закрывают задачи, когда человек сделал все, что нужно (или условия изменились, и задача не актуальна);
  • позволяют третьим лицам контролировать выполнение задач, в т.ч. ретроспективно.

Не буду больше ходить вокруг да около, изложу инструкцию по работе с автозадачами. Конфигурация приложена, инструкция по внедрению в конце статьи.

Программирование автозадач

АЗ программируются в справочнике «.Параметры автозадач» - это вроде как типы АЗ.

Центральное место в программировании АЗ занимает составление схемы компоновки. В чем ее суть:

  1. Схема должна описывать, при каких условиях есть задача. Например, схема возвращает платежку исходящую, которая проведена, но в ней не стоит флаг Оплачено. Это будет задача – сделать выписку, чтобы в 1С списались деньги;
  2. В то же время, когда человек выполнит задачу, схема должна вернуть пустую выборку – это будет означать, что задача выполнена;
  3. Ну т.е. должно быть четкое понимание при разработке схемы, при каких условиях задача есть, а при каких она выполнена. Это одно из основных отличий АЗ от прочих подобных механизмов – АЗ не привязаны к событиям системы, нет понятий «возникновение задачи» или «закрытие задачи»;
  4. Одна из аналогий АЗ – отчеты, которые пользователь настраивает сам себе, чтобы понять, что ему еще надо сделать. В примере из п.1 это будет отчет «Неоплаченные исходящие платежи»: если отчет что-то показал – есть задача, если вышел пустой – все в порядке, задачи нет.

Требования к схеме компоновки:

Схема компоновки должна обязательно содержать два поля:

  1. КлючЗадачи – любого типа. Должно быть всегда, в разделе «Выбранные поля» схемы;
  2. ТекущийОстаток – числового типа. Должно быть всегда, в разделе «Выбранные поля» схемы;
  3. Исполнитель – типа «Справочник.Пользователи» или «Справочник.итРолиПользователей». Должен быть в зависимости от типа определения исполнителя (см. раздел ниже).

КлючЗадачи (КЗ) – это поле, которое отвечает за количество созданных АЗ. Своего рода способ группировки. Каждая задача должна к чему-то относиться, как-то идентифицироваться в этом мире.

Также, ключ задачи имеет важное значение при определении срока выполнения задачи.

Если вернуться к примеру с платежками, то варианты могут быть такие:

  1. Ключ задачи – платежка. В этом случае задач будет ровно столько, сколько неоплаченных платежек. В задаче при этом будет ссылка на одну эту платежку. Срок выполнения при этом надо будет определять исходя из знаний об этой платежке – например, дата платежки + сутки;
  2. Ключ задачи – начало дня платежки. В этом случае задач будет ровно столько, сколько разных дней есть в неоплаченных платежках. Например, если есть неоплаченные платежки за сегодня и за вчера, то автозадач будет две. Срок выполнения при этом можно вычислять исходя из ключа задачи – например, ключ задачи + сутки, или ключ задачи + 8 часов.
  3. Ключ задачи – пустой, или какое-то постоянное значение (типа «», 1, истина, «ключ»). В этом случае задача будет одна, и в ней будут все неоплаченные платежки. Когда настанет момент, что все платежки будут оплачены, задача закроется. Когда вновь возникнут неоплаченные платежки, создастся новая задача. Ну это вообще общее правило АЗ – если задача закрылась, она уже не откроется – всегда будет создана новая.

Теперь про «Текущий остаток». Любую задачу можно измерить с помощью цифры. Например, в примере с платежками это может быть количество документов, или общая сумма. Сам я на практике обычно использую количество документов/справочников.

Так вот, эта количественная характеристика и хранится в поле «Текущий остаток». Как только текущий остаток становится равен нулю – задача закрывается. Собственно, если при выполнении схемы компоновки не вернулось вообще ничего (пустая выборка), текущий остаток считается равным нулю.

Также, внутри автозадачи есть история изменения текущего остатка, в виде табличной части. Это для тех задач, которые могут выполняться поэтапно. В примере с платежками это варианты ключа задачи 2 и 3. Например, было 10 документов – тек. остаток будет 10. Человек сделал выписку, 2 дока оплатились – текущий остаток будет 8. И т.д., до нуля.

Ограничений по использованию вычисляемых полей, функций общих модулей – нет.

Определение исполнителя

Исполнитель задачи определяется двумя способами:

  1. Просто указывается в параметрах автозадачи – там есть соответствующее поле Исполнитель. Можно выбрать конкретного пользователя или роль пользователя. В таком варианте поле «Исполнитель» не является обязательным для схемы компоновки. Например, в случае с платежками именно такой вариант подойдет, т.к. с платежками работает, как правило, один человек и он известен;
  2. Определяется схемой компоновки – это тот случай, когда информация об исполнителе хранится где-то внутри объектов, к которым привязана автозадача. Например, если вы хотите сделать автозадачу по согласованию договора, а перечень согласующих хранится в табличной части, то исполнитель – это и будет согласующий. В таком варианте схема компоновки должна обязательно содержать группировку Исполнитель. В параметрах автозадачи при этом надо ставить флаг «Исполнитель из схемы».

Группировки схемы компоновки

Тут всего два варианта:

  1. Если исполнитель определяется в параметрах автозадачи, то группировка должна быть одна - <Детальные записи>. Все остальные поля – в выбранных полях;
  2. Если исполнитель берется из схемы, то первой должна идти группировка «Исполнитель», в ее иерархии - <Детальные записи>. Все остальные поля – в выбранных полях.

Сроки выполнения автозадач

Срок выполнения автозадачи определяется исходя из самой автозадачи. Вычисление срока реализуется на встроенном языке платформы, с помощью произвольной формулы. В формуле доступны все конструкции языка, а также доступна формируемая задача (типа СправочникОбъект.итАвтозадачи). Имя переменной – Источник. Результат вычисления по формуле должен быть помещен в переменную Результат.

Это стоит учитывать при разработке схемы компоновки и выборе ключа задачи.

Если ключом задачи является какой-то документ, то обычно срок определяется датой этого документа. Например, если задача должна быть решена через сутки после создания документа, то формула будет:

Результат = Источник.КлючЗадачи.Дата + 3600 * 24.

Если не сутки, а конец того дня, когда был создан документ, то формула будет такой:

Результат = НачалоДня(Источник.КлючЗадачи.Дата) + 3600 * 17.

Если ключом задачи является, например, дата (сама задача при этом содержит несколько документов), то формулы будут такие:

Результат = Источник.КлючЗадачи + 3600 * 24, или Результат = НачалоДня(Источник.КлючЗадачи) + 17 * 3600.

Также, при вычислении срока доступны все реквизиты задачи. Например, у задачи есть реквизит ДатаПостановки – он равен дате создания задачи, его тоже можно использовать. Формула будет такой, к примеру:

Результат = НачалоДня(Источник.ДатаПостановки) + 17 * 3600.

И так далее, с разными вариациями. Например, можно делать запрос к производственному календарю, если срок задачи измеряется в рабочих днях.

Для себя я сделал отдельную функцию в общих модулях, типа ПолучитьСрокЗадачи(ДатаНачала, КоличествоРабочихДней). В нее передаю дату, от которой отсчитывать срок, и количество рабочих дней.

Формулы вычисления сроков живут в справочнике итПроизвольныеФормулы. В параметрах автозадачи выбирается конкретный элемент этого справочника. У меня, например, чаще всего используются два элемента этого справочника – «3 рабочих дня от даты постановки» и «Конец дня постановки задачи».

Написание текста и заголовка задачи

У автозадачи есть заголовок, который отображается в списках, и есть текст, который читает пользователь, когда зайдет в задачу. Заголовок потом превращается в наименование элемента справочника итАвтозадачи.

Самый простой вариант – написать обычным текстом заголовок и текст задачи. В этом случае при формировании автозадачи тексты просто скопируются. Но так не совсем интересно, т.к. задачу лучше делать контекстно зависимой.

Поэтому в текстах можно вставлять вычисляемые куски. Вычисление происходит платформенной функцией Вычислить. Доступна переменная Задача, в которой содержится записываемая автозадача (тип СправочникОбъект.итАвтозадачи).

Вычисляемый кусок в тексте оформляется квадратными скобками, например:

[Формат(ТекущаяДата(), «ДФ=dd.MM.yyyy») + « г.»]

Если в примере с платежками, то примерно так:

  1. Для варианта, когда ключом задачи является платежка, можно сделать такое краткое представление:
    1. «Оплатите платежку [Задача.КлючЗадачи]!!!»
  2. Для варианта, когда ключом задачи является дата платежки, можно написать так:
    1. «Надо сделать выписку и оплатить платежки от [Формат(Задача.КлючЗадачи, «ДФ=dd.MM.yyyy») + « г.»]»

Правила вычисления одинаковы для краткого представления и для текста задачи. Я в тексте задачи обычно даю более подробное описание того, что надо сделать, какие условия выполнить, чтобы задача закрылась.

Расшифровка автозадачи

Результат выполнения схемы возвращается человеку в виде расшифровки. Расшифровка очень важна, т.к. она позволяет человеку прямо из задачи проваливаться в нужные документы, справочники и т.д. и делать то, что просит автозадача.

Расшифровка бывает двух типов:

  1. В виде табличного документа – применяется, когда автозадача содержит несколько объектов для обработки;
  2. В виде ключа задачи – когда объект один.

Также, можно эти варианты комбинировать, но я сам такую настройку ни разу не использовал.

Расшифровка в виде табличного документа – это просто выгруженный в таблицу результат компоновки. Из результата запроса автоматически убираются служебные поля (КлючЗадачи, ТекущийОстаток, Исполнитель), все остальное попадает в табличный документ. Соответственно, в выбранные поля схемы компоновки можно и нужно добавлять то, что поможет пользователю быстро решить задачу.

Например, в случае с платежками, когда мы выводим все платежки за день, я добавляю в выбранные поля саму платежку, расчетный счет и сумму. Пользователь видит в расшифровке таблицу из трех колонок, может выбрать исходя из своего понимания ситуации, провалиться в документ и сделать то что надо.

Сам табличный документ будет отображен пользователю в форме автозадачи.

Хранится табличный документ в регистре сведений итРасшифровкиАвтозадач. Я намеренно вынес его из справочника автозадач, чтобы можно было по истечении определенного времени безболезненно удалить расшифровки старых автозадач (регистр чистить значительно проще, чем справочник).

Чтобы пользователь увидел расшифровку, надо в параметрах автозадачи поставить флаг «Показывать расшифровку».

Второй вариант – показывать только ключ задачи. Это тот случай, когда автозадача содержит только один объект для обработки.

Тут все значительно проще – пользователю на форму будет просто выводится ключ задачи. При этом в параметрах автозадачи можно указать заголовок для ключа (чтобы не было написано «Ключ задачи» или «Объект»). Например, в примере с платежкой, когда ключом задачи является сама платежка, можно задать заголовок ключа «Вот эта платежка, которую надо оплатить».

Ключ задачи будет выведен пользователю на форму в виде гиперссылки, он сможет в него проваливаться.

Чтобы пользователь видел ключ, надо в параметрах задачи поставить флаг «Показывать ключ».

Остальные реквизиты настройки

  1. Ответственный – можно указать пользователя или роль человека, который отвечает за выполнение задачи. Это вроде как ответственный за процесс, или просто начальник исполнителя задачи. Используется для группировки потом. Можно не указывать;
  2. Единица измерения остатка – строковое поле, которое добавляет к текущему остатку по задаче. Например, «док.» или «руб.»;
  3. Количество знаков после запятой – для форматирования вывода текущего остатка автозадач;
  4. Закрывать по окончании срока – если флаг установлен, то задача будет автоматически закрываться по окончании срока выполнения. При этом в задаче будет стоять признак «Закрыта»;
  5. Закрывается вручную – это для задач, у которых нельзя запросом отследить, что они выполнены. У меня одна такая задача – удаление пользователей из домена/почты при увольнении. Возникновение задачи отследить можно, исполнение – нет. Для ручных задач в форме появляется кнопка «Отметить выполнение», и пользователь должен ее нажимать сам;
  6. Дополнительные исполнители – таблица, где можно указать, кто еще может выполнить эту задачу. Я использовал эту таблицу для RLS, чтобы доп.исполнители видели эту задачу;
  7. Степень влияния исполнителя на результат – доп.аналитика задач, я ее использовал при оценке состояния задач. Есть задачи, где человек сам все сделать может, есть такие, где нужна помощь других людей. Вот этим реквизитом оно и разделяется;
  8. Кто видит задачу – таблица, где можно перечислить зрителей. Я использовал для RLS.

Формирование автозадач

Для формирования автозадач используется регл.задание итФормированиеАвтозадач.

Что оно делает:

  1. Выполняет все схемы компоновки их параметров задач, в которых стоит признак «Активная»;
  2. Формирует таблицу новых актуальных задач;
  3. Формирует таблицу старых актуальных задач (которые не выполнены и не закрытые);
  4. Сравнивает таблицы новых и старых актуальных задач;
  5. Если задача совсем новая – создает, если уже была такая – обновляет. Сравнение идет по полям «КлючЗадачи» и «Исполнитель». Это означает, к примеру, что при изменении исполнителя в параметрах автозадач все ранее поставленные задачи будут перепоставлены новому исполнителю;
  6. Закрывает старые задачи, которые стали не актуальными;
  7. Закрывает задачи, у которых вышел срок и стоит флаг «Закрывать по окончании срока».

Расписание регл.задания я ставлю через консоль. Сначала ставил раз в минуту, потом увеличил до 5 минут, т.к. задач стало много. Сервер у меня слабый, выполнение всех схем занимает 2-3 минуты.

Для отладки на файловых базах я добавил обработку ФормированиеАвтоЗадач – там одна кнопка, которая делает ровно то же, что и регл.задание.

Инструкция по внедрению.

Непосредственно к автозадачам (АЗ) относятся объекты:

  1. Общие модули итАвтозадачи и итАвтоЗадачиПривилегированный;
  2. Регламентное задание итАвтоЗадачи;
  3. Справочники итПроизвольныеФормулы, итРолиПользователей, итАвтоЗадача, итПараметрыАвтоЗадач;
  4. Документ итНазначениеРолейПользователей;
  5. Перечисление итВидыДействийНачатьПрекратить;
  6. Обработка ФормированиеАвтозадач;
  7. Регистры сведений итНазначениеРолейПользователей и итРасшифровкиАвтозадач.

Также есть объекты типовой конфигурации, с которыми взаимодействуют АЗ, я их оставил в конфигурации:

  1. Справочник Пользователи (оставил только сам справочник, убрал формы и модули);
  2. Параметр сеанса ТекущийПользователь;

Для демонстрации работы добавлен документ ДемоЗаказПокупателя, его не нужно переносить в свою конфигурацию.

Соответственно, чтобы внедрить АЗ в конфигурацию, надо взять объекты из первого списка, и посмотреть что скажет сравнение/объединение насчет объектов второго списка.

Если в вашей конфигурации есть справочник Пользователи и параметр сеанса ТекущийПользователь, то мои накатывать не нужно.

Если таких объектов у вас нет, то надо переделать ссылки с моих объектов на ваши – пишите, если нужна помощь.

Демобаза

Приложил маленькую демонстрационную базу, с той же конфигурацией.

Внутри есть документ Демо заказ покупателя, на него реагируют две автозадачи - одна отслеживает согласование, другая отслеживает отгрузку. Сами автозадачи можно увидеть, зайдя в справочник Автозадачи. Настройки можно увидеть, зайдя в справочник Параметры автозадач. Смоделировать работу автозадач можно, если что-нибудь сделать с документами Демо заказ покупателя - например, согласовать, или поставить признак Отгружено, или создать новый документ. При этом надо не забыть открыть обработку Формирование автозадач и нажать в ней кнопку (регл.задания не включены в демобазе).

Что дальше

Как использовать и развивать механизм - решать вам. Я в своей практике приделывал к нему разную функциональность. Например, создавал отчет, который выводит просроченные автозадачи, сгруппированные по исполнителю. Или делал систему восходящего реагирования - автозадачу для руководителя, когда просрочена автозадача исполнителя.

Примеры из моей практики

Друзья в комментариях потребовали рассказать о примерах автозадач из моей практики.

Расскажу то, что помню.

1. Все согласования проходили через автозадачи. Заявки на расход денег, договоры, спецификации, разные проверки качества, служебки, акты на списание и т.д. Все процессы, где для продолжения кто-то должен поставить флажок.

Такие автозадачи очень просты. Нет флага - есть автозадача. Есть флаг - закрылась автозадача.

Исполнителей легко определить по штатной структуре.

2. Напоминалки, не требующие каких-то действий в системе, тоже стали выводить в автозадачи.

Типовые напоминания, например, о днях рождения контактных лиц контрагентов, требуют отслеживания - надо в каждом зайти и нажать, чтобы система напоминала о дне рождения. Причем, напоминать она будет менеджеру, который указан в контрагенте. Если менеджер уволился, то новому менеджеру придется повторить настройку.

Автозадача проще - она сообщает за несколько дней обо всех днях рождения по контрагентам выбранной папки, причем всему отделу сразу. Как уж там они поздравляют - их дело. Задача закрывается либо по сроку (на следующий день после ДР), либо руками.

Ну и напоминалки попроще - ввести бюджет подразделения, оформить табель, зарезервировать ДС на неделю, составить отчет по состоянию проектов. Такие напоминалки контролируются автоматически, т.к. в системе что-то появляется - документ бюджета, например. А если не появился - хрен с ним, задача закроется по истечению срока (мало ли, не нужен человеку резерв денег).

3. Реальные оцифрованные задачи, в основном по снабжению.Реальными я их называю потому, что от их качества и исполнения зависят важные бизнес-процессы, коим являлось снабжение.

Задача содержала в себе все позиции с количествами, которые конкретный снабженец должен был заказать.

"Заказать" - это оформить заказ поставщику. Количества и позиции определялись с помощью универсального механизма планирования.

Как только снабженец все заказал, задача закрывалась. Как только появлялась новая потребность - задача открывалась снова.

Другой реальной задачей было опустошение склада возвратов. На этом складе была продукция от поставщиков, которая не прошла ОТК, и ее надо было вернуть. На возврат - 30 дней. Ответственный за вывоз - тот, кто купил (он известен из приходной накладной). Задача закрывалась, когда продукция исчезала со склада возвратов.

Еще была задача для склада и менеджеров по пополнению склада филиала, который территориально находится в сотнях километров. Система (универсальный механизм планирования) вычисляла, какие позиции номенклатуры и в каких количествах там нужны, и формировала автозадачу. Закрывалась задача, когда появлялся внутренний заказ на перемещение.

4. Задачи на корректность отложенного заполнения справочников/документов.Отложенное - это когда значение сразу зааполнить нельзя, т.к. неизвестно, чем заполнять.

Банальный пример - добавляем нового сотрудника в 1С, в пользователе надо указать физ.лицо, а кадровая служба работает неоперативно, и физ.лицо появится через пару дней. У нас физ.лицо было нужно в пользователе, т.к. в нем живет и контактная информация, и через физ.лицо работали многие автозадачи - например, чтобы понимать место пользователя в штатном расписании.

Получается простая автозадача - вывалить список пользователей, у которых не заполнено физ.лицо.

Другой пример - коды ТНВЭД в номенклатуре. Номенклатуру создает один человек, код ТНВЭД знает другой человек, работать синхронно они не могут. Появляется автозадача - поставить код ТНВЭД, со сроком исполнения дней пять.

Вообще к номенклатуре много чего привязывалось. Например, плановое время поставки нужно было вводить. Указать, в сборе поставляется или по частям. Ввести плановую себестоимость, для расчета коммерческих предложений. 

5. Задачи на следующие этапы бизнес-процесса. Как таковые бизнес-процессы не использовались - они тяжелые, скучные и громоздкие. А вот отслеживать важные этапы с помощью автозадач - самое оно, потому что видеть бизнес-процесс в виде карты, со всеми этапами - никому не интересно. А вот не профукать что-то важное - то, что надо.

Например, зарубежные закупки и авансы зарубежным поставщикам. Сами знаете, сколько там надо бумажек собрать и предоставить в бухгалтерию, и все это асинхронно - т.е. нельзя, например, запретить приходование продукции, пока нет бумажек, потому что они реально могут несколько дней идти.

Делаем нашлепку к поступлению товаров и услуг с галочками, типа "такой-то документ предоставлен", и вешаем автозадачу ответственному за поступление. А одновременно - и бухгалтеру, чтобы подпинывал менеджера. Принес бумажку, поставили галку, задача закрылась.

Отдельная тема - контроль авансов зарубежным поставщикам. Финконтроль за такие дела штрафует, когда вы запулили в Китай денег, указали срок аванса, а по его истечении у вас нет накладной или какой-то там бумажки (не помню, как она называется). Чтобы не попасть на штраф, вешалась автозадача, привязанная к авансовому документу.

Еще пример - те же заказы поставщикам. Оформление заказ поставщику снимает задачу "заказать продукцию", но порождает другую - подписать спецификацию с поставщиком (он ведь должен знать, что мы ему что-то заказали). Приделываем простецкую галочку к заказу поставщику - "спецификация согласована обеими сторонами" - и вешаем автозадачу, чтобы снабженец галку в течение 5 дней поставил. Заодно не даем потом заказ менять, когда галка стоит.

Для юристов делали автозадачу по предоставлению оригиналов договоров. Создание, согласование договоров, замечания, хранение сканов - все в системе. Но еще в архиве должны быть оригиналы. На эту тему - автозадача. Как только договор согласован, с инициатора в 30-дневный срок требуется предоставить оригинал, подписанный обеими сторонами. Предоставил, юрист поставил галку, задача исчезла.

Схожая задача - для бухгалтерии, по сбору оригиналов бумажек (накладные, счета-фактуры, ТОРГи, ГТД, инвойсы и т.д.). Был простенький механизм, который сам определял, какие бумажки должны быть предоставлены по конкретному документу в 1С, и бухгалтер ставил там галочки "предоставлен". А чтобы ответственный за документ не забывал бумажки сдать, ему вешалась автозадача.

Еще задача - удаление пользователей из системы при увольнении. Появился документ увольнения, в нем указан последний день работы - вот и вся необходимая информация. Вешается автозадача админу базы - удалить пользователя. Закрывается, когда пользователь деактивирован.

6. Задачи по контролю убегающей адекватности - это когда сегодня данные нормальные, а завтра уже нет.

Простейший пример - сроки поставок. В заказе поставщику по каждой позиции стоит дата, когда мы ее ждем у себя. Поставщик эти сроки тоже знает - они в спецификации стоят. Если поставщик не успевает, он в 99% случаев об этом будет молчать до тех пор, пока не спросят. А чтобы спросили - есть автозадача для снабженца. Подошел или прошел срок - звони поставщику, выясняй что не так, договаривайся о новом сроке. Автозадача закроется в двух случаях - если срок станет адекватным или если заказ приедет к нам. Чтобы не хулиганили - изменение сроков через начальника снабжения.

Скачать файлы

Наименование Файл Версия Размер
Конфигурация Автозадачи
.cf 95,58Kb
01.08.17
27
.cf 95,58Kb 27 Скачать
Демобаза Автозадачи
.dt 107,80Kb
01.08.17
62
.dt 107,80Kb 62 Скачать

См. также

Комментарии
1. Валерий Волошин (VVi3ard) 39 01.08.17 11:57 Сейчас в теме
На мой взгляд интересная разработка, относительно простая для понимания и полезная после внедрения.
4. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 09:57 Сейчас в теме
(1) не сомневайтесь, она и правда очень простая и полезная.
Я пользовался ей в реальном внедрении 3 года.
2. Геннадий Николаев (genayo) 01.08.17 23:09 Сейчас в теме
Сама идея далеко не нова, изюминка в использовании для всего этого СКД.
3. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 09:56 Сейчас в теме
(2) у вас есть ссылки на материалы, где упомянута такая идея, или описана реализация?
Не в качестве доказательства, просто интересно.

На конференции партнеров мне говорили, что почти полный аналог есть в ДО 2 (если собрать там комплексное решение из нескольких инструментов).

Что точно не ново, так это реализация - несколько человек независимо от меня реализовали подобный механизм, когда узнали идею.
7. Геннадий Николаев (genayo) 02.08.17 11:10 Сейчас в теме
(3) ДО2 это совсем другая тема, задачи там таки существуют как сущность и закрыться сами могут далеко не всегда.
Относительно похожая подсистема есть в одной WMS родом из начала 2010-х, только там все кодом без СКД, и кроме рассылки почтой иных способов доставки "задач" нет. Ваша подсистема конечно гораздо более продвинутая и удобная.
8. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 12:04 Сейчас в теме
(7) я видимо неправильно акцентировал внимание в публикации - здесь задачи тоже существуют как сущность. Это справочник.
9. Геннадий Николаев (genayo) 02.08.17 12:09 Сейчас в теме
(8) Я имел в виду объект платформы Задача.
10. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 12:11 Сейчас в теме
(9) Понятно. Ну это вроде не так важно.
11. Геннадий Николаев (genayo) 02.08.17 12:20 Сейчас в теме
(10) Использование объектов задача - это скажем так более классический подход, и накладывает определенные ограничения на функциональность, в отличии от вашего решения.
12. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 12:25 Сейчас в теме
(11) я за 12 лет несколько раз смотрел на ветку "Задачи" в дереве метаданных, но каждый раз что-то останавливало от их использования. Ну нет там ничего такого интересного, существенно выделяющего их на фоне справочников и документов.

Возможно, это просто мертворожденный тип объектов метаданных. Равно как и железобетонные бизнес-процессы, карты которых рисуются в конфигураторе.
13. Геннадий Николаев (genayo) 02.08.17 12:33 Сейчас в теме
(12) Вы видимо близко не смотрели ДО2, там все на задачах, бизнес-процессах и справочниках. И бизнес-процессы в конфигураторе там уже давно не рисуются, в последней версии даже сделана попытка обеспечить графический интерфейс создания новых бизнес-процессов в режиме предприятия.
Кстати, сейчас ДО2 внедряется на Почте России, и по результатам внедрения обещают новую прорывную версию :)
14. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 12:42 Сейчас в теме
(13) ладно, хрен с ними, с задачами этими :)
5. Артем Артеменко (dock) 30 02.08.17 10:30 Сейчас в теме
в демо базе поправьте режим совместимости интерфейса :)
что-то вообще какая-то странная демо-база... вроде как все под УФ, а пришлось пошаманить для правильного запуска
6. Иван Белокаменцев (1c-intelligence) 2355 02.08.17 10:53 Сейчас в теме
(5) там все правильно вроде. Режим совместимости интерфейса такой же, как в УПП, в которой автозадачи разрабатывались изначально.
15. Артем Артеменко (dock) 30 02.08.17 15:55 Сейчас в теме
(6) да, всё верно. Просто уже привык к УФ (даже не к УФ, а Такси) и мои необоснованные ожидания были не оправданы....
16. Ирли Бёрд (EarlyBird) 1 02.08.17 17:16 Сейчас в теме
У меня один вопрос: зачем конфигурацию и демо-базу выкладывать двумя разными архивами, почему не объединить в один?
Они что, весят по гигу?
evgefremov; astrius; +2 2 Ответить
17. Иван Белокаменцев (1c-intelligence) 2355 03.08.17 07:36 Сейчас в теме
(16) даже не знаю, что ответить. Не мелькнула такая мысль в голове.
18. Anton Klymov (antoklio) 04.08.17 17:00 Сейчас в теме
Получается, что на любую конфигурацию можно накатить? например, мне нужно на УТ10.3 и на Розницу 2.1.
19. Иван Белокаменцев (1c-intelligence) 2355 04.08.17 18:22 Сейчас в теме
(18) на УТ 10.3 и Розницу точно встанет.
А вообще - да, на любую, кроме самописанных - там минут 10 рихтануть придется.
Будут трудности - пишите.
20. Иван Белокаменцев (1c-intelligence) 2355 07.08.17 07:51 Сейчас в теме
Друзья, кто скачал, удалось попробовать сделать автозадачи?
Трудности есть?
21. Anton Klymov (antoklio) 14.08.17 17:12 Сейчас в теме
накатил на Розницу.
При добавлении нового элемента в справочник "Параметры автозадач" ошибка преобразования данных ХДТО: НачалоСвойства: {http://v8.1 бла-бла -бла} settingsVariant
Форма: Элемент
Тип:{http://www.w3 бла-бла-бла}

Версия Розницы 2.1.8.16, доработанная.
Платформа 8.3.6.2237

PS. Кажется, ошибка возникает в тонком клиенте. В Толстом нормально....
22. Иван Белокаменцев (1c-intelligence) 2355 14.08.17 17:25 Сейчас в теме
(21) да, так и должно быть - в тонком клиенте 8.3.6 нет конструктора схемы компоновки.
Схемы рисуйте в толстом, сами задачи в тонком нормально работают.
IgorroPadavan; +1 Ответить
23. Александр Романько (romankoav) 06.09.17 12:45 Сейчас в теме
Иван, а можете хотя бы список всех применяемых у вас автозадач выложить?
24. Иван Белокаменцев (1c-intelligence) 2355 07.09.17 10:30 Сейчас в теме
(23) обновил публикацию, дописал раздел про мою практику использования автозадач.
Задавайте вопросы, буду рад ответить.
Прям точный список дать не могу, т.к. у меня нет доступа к базе.
romankoav; aeteros; +2 Ответить
25. Иван Белокаменцев (1c-intelligence) 2355 11.10.17 12:09 Сейчас в теме
На днях, обсуждая развитие недавно начатого проекта flowcon, вспомнили про автозадачи.
Похоже, найдется им место во флаконе, как одному из ответвлений - управлению задачами, которых еще нет.

Когда задачи есть, как сущности, ими управлять не сложно. Об этом есть миллион программ и сервисов, типа redmine или JIRA.

А когда задач нет, управлять нечем, есть только хаос, некие двоичные данные, блоб, который называется "вот как-то так мы работаем". И никакой сервис тут не поможет, потому что ему нечем оперировать.

Спасаются, в основном, через KPI. Формула такая: я не могу прочитать этот блоб, оценю хотя бы его размер. Другими словами, не понимаю, что и как происходит и как этим управлять, поэтому буду смотреть на результат и оценивать его.

Управлять в такой ситуации очень сложно, только эпизодически и вручную, или как крутой управленец - "мне не нравится ваш результат, работайте лучше! Повышайте эффективность!".

Автозадачи это препятствие - отсутствие задач как сущностей - устраняют, и появляется шанс навести блестящую красоту.

Поэтому автозадачи войдут во флакон - причешем их методически, перепишем на metadata.js, сделаем красивую морду, и пойдем мир завоевывать.
Оставьте свое сообщение