Автозадачи

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

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

Самый простой и востребованный пример - отложенное исправление ошибок (когда ошибку сразу не видно или нельзя исправить). Например, бухгалтер забыл сделать выписку и у исходящих платежек не стоит признак Оплачено. Или возникли отрицательные остатки по товарам в бух.учете. Или числится одновременное сальдо на 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% случаев об этом будет молчать до тех пор, пока не спросят. А чтобы спросили - есть автозадача для снабженца. Подошел или прошел срок - звони поставщику, выясняй что не так, договаривайся о новом сроке. Автозадача закроется в двух случаях - если срок станет адекватным или если заказ приедет к нам. Чтобы не хулиганили - изменение сроков через начальника снабжения.