Модуль ЭТрН: назначение и архитектура

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

Не является. Модуль представляет собой прикладной слой в учётной системе, работающий поверх операторов. Схема взаимодействия: 1С клиента → модуль → оператор ИС ЭПД → ГИС ЭПД. Договорные отношения с оператором и оплата пакета документов сохраняются в прежнем виде.

Титул Т1 (грузоотправитель) и титул Т3 (грузополучатель). Титулы Т2 и Т4 относятся к зоне ответственности перевозчика. Поддерживается оформление переадресовки (Т9 и Т7) и эстафеты (Т8).

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

Не потребуется. Бизнес-процесс формирования и подписания титулов реализован в учётной системе клиента и не зависит от того, через какого оператора документ передаётся в ГИС ЭПД. При переходе к другому провайдеру изменяется подключение в настройках; процессы, шаблоны, сопоставление полей и порядок работы пользователей сохраняются, переобучение сотрудников не требуется. На начальном этапе поддержаны Контур.Логистика, Калуга-Астрал, СберКорус и ЭДИ Софт, перечень расширяется.

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

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

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

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

• если новые данные EDI-сообщения сохраняются в реквизиты документа 1С и это тот же документ, по которому формируется накладная, либо связанный с ним документ, — достаточно изменить сопоставление полей в модуле, написание кода не требуется;
• если новые данные в учётной системе не появляются, перенести их в накладную невозможно.

Практически задача делится на две части: обеспечить попадание данных в реквизиты документа учётной системы (сторона EDI и учётной системы клиента) и сопоставить эти реквизиты с полями титула (сторона модуля, выполняется настройкой). Обратная сторона того же принципа: модуль не вмешивается в действующий обмен клиента — при установленном 1С-ЭДО документы стороннего обмена он не перехватывает (см. «Не нарушит ли установка модуля работу учётной системы?»).