Как работает новая подсистема «Доставка 2.5» в 1С:ERP и 1С:УТ и как решить проблемы при переходе?

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

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

Почему при изменении адреса создается новая точка доставки, а не изменяется существующая?

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

Поведение системы определяется двумя ключевыми факторами:

1. Контроль неизменности исторических данных: в новой подсистеме действует строгий запрет на изменение адреса точки доставки, если она уже задействована в проведенных документах (например, в документах ЗаказКлиента, ЗаказНаДоставку, рейсах или первичных накладных). Если бы система обновляла адрес существующего элемента, это привело бы к ретроспективному искажению логистической информации в закрытых периодах и печатных формах. Поэтому при наличии ссылок на точку в базе система автоматически инициирует создание нового элемента справочника.
2. Работа с адресным классификатором (ГАР/ФИАС): справочник точек доставки опирается на структурированные данные классификатора и идентификаторы GUID. Если пользователь меняет адрес вручную свободной строкой, меняет регистр символов или структуру полей, алгоритм сопоставления не может однозначно связать новый адрес с имеющимся объектом и регистрирует новую точку.
3. Концепция основной точки доставки: по правилам подсистемы автоматическая синхронизация предусмотрена для основной точки доставки партнера, привязанной к его основному фактическому адресу. Дополнительные точки формируются либо пользователем вручную, либо помощником миграции.

Почему зацикливается помощник перехода на «Доставку 2.5» и как устранить ошибку?

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

Проанализируем механику этого сбоя:

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

Разберем по шагам, как локализовать и устранить зацикливание:

1. Откроем ЖурналРегистрации и установим фильтр по событиям с уровнем Ошибка. В теле исключения находим конкретного партнера, контрагента или склад, на котором падает транзакция.
2. Перейдем в карточку проблемного объекта и проанализируем всю контактную информацию вида Адрес, ФактическийАдрес и ЮридическийАдрес.
3. Выполним стандартизацию адреса: откроем форму ввода адреса и перезаполним его строго по актуальному адресному классификатору (ГАР/ФИАС), исключая ручной ввод текста в неструктурированные поля.
4. При наличии дублирующихся строк контактной информации удалим лишние или неактуальные записи.
5. После нормализации адресных данных перезапустим помощник перехода на подсистему «Доставка 2.5».

Ограничения первой очереди подсистемы и рабочее место логиста

При переходе важно учитывать архитектурные рамки текущей реализации «Доставки 2.5». Функционал логистики развивается поэтапно, из-за чего логисты и диспетчеры могут столкнуться с неожиданными изменениями в привычных процессах.

Рассмотрим ключевые особенности и ограничения нового функционала:

1. Исключение внутренней и входящей логистики: в первоначальной редакции новой доставки поддерживается только исходящий контур продаж клиентам. Документы ЗаказНаПеремещение, ПеремещениеТоваров, а также входящие распоряжения ЗаказПоставщику и ПриобретениеТоваровУслуг временно не поддерживаются новым механизмом. Их включение в общий контур маршрутизации запланировано в последующих версиях конфигурации.
2. Локализация рабочего места «Доставка»: старая обработка позволяла видеть сводную картину по группе складов и нескольким организациям одновременно. Новое рабочее место логиста оптимизировано под поскладское формирование рейсов и требует жесткого отбора в разрезе конкретного склада отправления и организации. Для получения глобальной картины по предприятию разработчики предлагают использовать специализированный отчет СостояниеДоставки.
3. Сборка рейсов по товарам: в отличие от прежней концепции, где доставка оперировала исключительно целыми документами-распоряжениями, новое рабочее место позволяет включать в рейс отдельные товарные позиции. Это дает возможность распределять один заказ по разным машинам (например, в зависимости от габаритов груза или температурных требований к перевозке).
4. Необратимость перехода: включение функциональной опции «Доставка 2.5» является необратимым действием. Вернуться на классическую схему «Доставка 2.0» штатным переключателем невозможно, поэтому миграцию рабочих баз следует выполнять только после полноценного тестирования на копии.

Таким образом, перед активацией подсистемы «Доставка 2.5» необходимо провести предварительный аудит адресной базы, проверить используемые логистические сценарии (особенно наличие межскладских перемещений) и подготовить персонал к обновленному регламенту работы с точками доставки.