Как хлебзаводу настроили автозаполнение маршрутных листов в 1С

Кто обратился за доработкой

Заказчик — производитель хлебобулочных изделий из Курской области. Доставку продукции по магазинам компания осуществляет своим транспортом. Заказчик ранее пользовался услугами консультаций по 1С от компании Scloud, но текущее обращение касалось доработки конфигурации.

С какой проблемой обратился клиент

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

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

Вторая проблема касалась логики группировки товаров в «Отчете по заявкам». Отчет сводил данные по районам — так в системе были обозначены группы контрагентов. Предполагалось, что каждой группе соответствует конкретный водитель. Однако на практике география подводила: фактическое местонахождение магазина часто не совпадало с районом, к которому этот магазин был приписан в справочнике. В результате отчет распределял товары некорректно — часть позиций уходила не тому водителю. Сотрудникам приходилось вручную переносить магазин из одной группы в другую, чтобы получить пригодный для работы результат.

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

Как решалась задача 

Работа программистов началась с анализа существующей доработки стороннего разработчика.

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

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

Обе линии работ шли параллельно. Управляла проектом Ирина Гайдина, за техническую реализацию и запуск отвечал программист 1С Павел Дороничев.

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