Автозадачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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