Практика применения подсистемы Автозадачи

Публикация № 990710

Управление - Пользователю системы

практика автозадачи альфа-авто

22
На Инфостарте есть публикация о подсистеме Автозадачи (https://infostart.ru/public/656758/). Я решил поделить своим опытом применения этой подсистемы Альфа-авто 5.

Примеры использования будут из конфигурации Альфа-авто 5.1 (платформа 8.3.10). Это обычные формы и отраслевое решение от 1С-Рарус.

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

 

Пример полуавтоматизации с помощью автозадачи.

Чтобы в Альфа-авто автомобиль можно было выбрать в документе Тест-драйв, этот автомобиль должен быть на остатках в регистре накопления Автомобили для тест-драйва.

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

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

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

И еще одна, что автомобиль есть в регистре тестовых авто, но его нет на остатке.

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

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

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

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

 

Пример не совсем стандартного применения автозадач.

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

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

В итоге получилась такая панель с информацией для менеджеров по продажам.

В ней выводиться информация для каждого менеджера индивидуально.
По клику на строки открывается расшифровка, что именно в этой строке.

Одновременно с этим у каждого из руководителей подразделений в панели своя сводная информация по всем подчиненным менеджерам.

По клику по сроке открывается расшифровка более подробная.

И далее по клику на ячейки с ссылками открываются именно те же самые расшифровки, как у менеджеров.

У директора, которому подчиняются руководители подразделений, тоже собирается информация, но уже по всем руководителям.

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

По скриншотам очевидно, что вся схема собрана на автозадачах.

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

Столбец «Мои» - это ключ автозадачи. Столбец «Всего» - это остаток автозадачи.

Иерархия формировалась по данным справочника подсистемы - Роли пользователей.

Папка «Отделы продаж по брендам», в этой папке роль «Директор по продажам» и много папок вида «Отдел продаж <Марка авто>». В папках по отделам — роль «Руководитель ОП <Марка авто>» и папка «Сотрудники ОП <Марка авто>».

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

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

Для более удобного разделения автозадач, которые дают информацию для каких-либо действий, от автозадач, которые просто информируют, был добавлен реквизит ДляИнформации (булево) и в формах списка справочника Автозадачи перенастроены отборы с учетом этого реквизита. И когда этот реквизит установлен в значение Истина, то в форме элемента Автозадач убирается много элементов.


Отслеживание ошибок, опасных ситуаций.

Как итог использования подсистемы Автозадачи я начал практически на каждую ошибку делать автозадачу. В идеале даже до исправления ошибки. Ведь если сначала сделать автозадачу, то она каждый день при входе в 1С маячит и не дает забыть о проблеме.

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

Еще пример. Почему-то появлялась запись в регистре Характеристики автомобилей с видом Пробег и значением 0. А пробега ноль, не может быть по объективным причинам. По той же схеме сначала автозадачу на появление нулевой записи, потом исправление. Юмор ситуации в том, что несколько раз правили в конфигурации то, что вызывало появление такой записи. И оказывалось, что исправления не помогли. Нулевая запись появлялась снова.

Далее примеры отслеживания опасных ситуаций, о которых, чем раньше узнаешь, тем лучше.

В справочнике Автоработы реквизит Номенклатура должен быть обязательно заполнен предопределенным элементом справочника Номенклатура, код – 00000003, наименование - AutoWork Авторабота. При ином заполнении некорректно работает Фронт кассира, при пробитии чека не учитываются суммы по автоработам с другим заполнением реквизита.

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

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

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

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

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

Причем если не следить, он может разрастись очень сильно.

Поэтому сделана автозадача с простым запросом:
ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Количество
ИЗ
    Справочник. внКэшЖурналаРегистрации КАК внКэшЖурналаРегистрации

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

Вот именно в таких ситуациях автозадачи незаменимы.


Пояснения к автозадачам.

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

Пример пояснения для журнала изменений:
В справочнике внКэшЖурналаРегистрации накапливаются и постепенно удаляются с переносом во внешнюю SQL-базу данные по изменяемым объектам.
В идеале в этом справочнике должно быть немного элементов (для возникновения задачи установлено пороговое значение 10 000).
А сейчас в этом справочнике 14065 элементов.
Надо принять меры, иначе он может разрастись до немыслимых размеров, что приведет к значительному росту рабочей базы.
Ниже приведен список метаданных и их количества в этом справочнике для первичного анализа.

Посмотрел на список метаданных и практически сразу понятна проблема. Или хотя бы где начинать искать.


Автозадача по автозадачам.

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

Я назвал ее - Усредненная история остатков из автозадач. Я смотрю ее за 7 дней, но можно и больше при желании.

В автозадачах есть табличная часть с историей остатков автозадач, т. е. количеством строк в расшифровке.

Я беру из нее данные и делаю вот такую автозадачу.

В колонке «Автозадача» - ссылка на параметры автозадач, в колонке «Час» — начало часа столбца «Дата» из истории остатков автозадач, в колонке «Средний остаток за час» - средняя по остаткам из истории остатков за этот час.

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

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

Еще видно, что 23 января убрали из корректировки регистра «Автомобили для тест-драйва» тестовые автомобили лишние, а 26 января в районе 12 часов видимо тестовый автомобиль продали и опять корректировку надо скорректировать.

Так же можно при необходимости залезь в конкретные автозадачи и посмотреть в них расшифровки с ссылками на конкретные объекты.

 

Что в итоге.

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

На последней конференции Инфостарта было выступление Тимура Кашафутдинова «Логирование в приложениях». Докладчик на обсуждении после выступлений прямо сказал, что в первую очередь он хотел не просто поделится примером, как у них сделано логирование, а привлечь внимание к этой проблеме. Что изначально при проектировании нужно закладывать, как следить, что все работает и работает именно так, как задумывалось.

Я считаю, что с помощью автозадач можно сделать такую систему, систему для отслеживания всего важного, сделать сразу в 1С. Причем делать это постепенно, можно сказать, эволюционно. А потому больше шансов, что в итоге получиться что-то дельное.

22

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. 1c-intelligence 7328 29.01.19 11:43 Сейчас в теме
Антон, выражаю мою глубочайшую личную признательность за эту статью. Надеюсь, она не последняя. Вы выполнили одну из моих целей на год, сами того не ведая.
Еще раз спасибо!
2. best_it_director 29.01.19 12:29 Сейчас в теме
Шьёрт, может и мне написать, а то с 12 года пользуюсь некоторыми штуками.
Оставьте свое сообщение