Обновление и использование подразделений контрагентов в обработке Диадок для 1С

← На главную

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

Зачем нужны подразделения в ЭДО?

Давайте сначала разберемся с проблематикой. Как верно замечено в обсуждении, существуют контрагенты, у которых сотни точек доставки. Если отправлять все документы в "голову", центральная бухгалтерия контрагента просто "утонет" в потоке накладных, о которых она ничего не знает. Требование таких клиентов (обычно это ритейлеры) — направлять документы строго в подразделение, соответствующее точке отгрузки.

Здесь важно провести четкую границу между двумя понятиями, которые часто путают:

Обособленное подразделение с точки зрения ФНС. Это филиал, который имеет свой уникальный КПП. В системе ЭДО такой филиал часто выглядит как отдельный участник обмена или "ящик", жестко привязанный к паре ИНН+КПП. Для корректного заведения таких филиалов в базе удобно использовать заполнение контрагентов по ИНН данными ФНС, чтобы исключить ошибки ручного ввода.
Структурное подразделение внутри Диадока. Это "виртуальная папка" внутри одного аккаунта (одного ИНН/КПП). У контрагента может быть один КПП, но сотни таких подразделений (отделы, конкретные магазины). У каждого подразделения есть свой уникальный идентификатор (GUID).

Мы будем рассматривать именно второй случай — работу с внутренними подразделениями (Department), которые идентифицируются по GUID, а не только по КПП.

Как получить список подразделений контрагента

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

Модуль интеграции 1С использует агрессивное кэширование. Чтобы не "дергать" API при открытии каждого документа, структура контрагента сохраняется локально. Если ваш контрагент добавил новый магазин в веб-интерфейсе вчера, ваш модуль 1С может не узнать об этом сегодня.

Рассмотрим, как это работает технически. Для получения данных используется метод API GetCounterparty. В ответе сервера приходит сложная структура Organization, которая содержит коллекцию Departments.

Важные нюансы метода:

API возвращает только активные подразделения. Если контрагент закрыл или скрыл подразделение, оно исчезнет из списка.
Для принудительного обновления списка в модуле 1С часто требуется ручное вмешательство: обновление и использование данных контрагентов через команду в карточке настройки или программная очистка кэша модуля.

Техническая реализация маршрутизации

Чтобы документ ушел по правильному адресу, нам недостаточно просто выбрать контрагента. Нам нужно указать конкретный DepartmentId. Разберем процесс для входящих и исходящих документов.

1. Исходящие документы (От нас к Контрагенту)

Это самый частый сценарий. Вы отгружаете товар в "Магазин №5", и накладная должна "упасть" в папку этого магазина в Диадоке покупателя. Если вы не укажете подразделение, документ уйдет в корневую папку (Головное подразделение), что вызовет штрафы или отказ в приемке со стороны сетей. Кроме того, при работе с сетями критически важен контроль заполнения полей маркированного товара, так как ошибки в маркировке также приводят к блокировке приемки.

При формировании пакета документов в модуле 1С (или если используется групповая выгрузка и загрузка файлов из 1С в XML для ЭДО для массовой отправки) необходимо корректно заполнять поле идентификатора подразделения получателя — ToDepartmentId.

Алгоритм действий программиста 1С:

В 1С у вас должна быть таблица соответствия. Например, регистр сведений или дополнительные реквизиты справочника "Грузополучатели" (или "Склады", "Партнеры" — в зависимости от конфигурации).
В этом соответствии мы храним связку: Объект 1С = GUID подразделения Диадок.
При отправке документа через методы модуля мы перехватываем формирование пакета и подставляем нужный GUID.

Примерная логика заполнения параметров отправки (псевдокод):


// Получаем GUID подразделения из наших настроек по грузополучателю накладной
ИдПодразделенияПолучателя = ПолучитьGuidПодразделения(Реализация.Грузополучатель);

Если ЗначениеЗаполнено(ИдПодразделенияПолучателя) Тогда
    // Заполняем служебное поле пакета Диадок
    ПараметрыОтправки.Вставить("ToDepartmentId", ИдПодразделенияПолучателя);
КонецЕсли;

2. Входящие документы (От Контрагента к Нам)

Если ваша организация имеет филиальную структуру, вам нужно настроить правильное распределение входящих. Когда контрагент присылает документ, он может указать DepartmentId (ID вашего подразделения).

Модуль Диадока при загрузке документа анализирует этот ID. Если в настройках модуля выполнено сопоставление (например, ID подразделения Диадока привязан к конкретной Организации или Подразделению в терминах 1С), документ автоматически "сядет" на нужный баланс. После загрузки документа часто требуется дальнейшая обработка, например, создание заказа поставщику из приобретения товаров, а для бумажного архива может понадобиться печать УПД за поставщика для документа Приобретение товаров услуг.

Сравнение подходов: Диадок vs СБИС

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

В СБИС (Тензор):

Подразделения часто реализуются через иерархию личных кабинетов. Каждый филиал может выступать как отдельный аккаунт, связанный с головным. Идентификация часто строится на жесткой связке ИНН + КПП. Чтобы отправить документ в филиал, иногда требуется менять контекст авторизации или использовать сложные составные идентификаторы (ID получателя).

В Диадок (Контур):

Это чаще единый аккаунт (один BoxId), внутри которого существует древовидная структура подразделений. Идентификация идет через GUID. Вы работаете в рамках одного соединения, просто переключая параметр DepartmentId или ToDepartmentId.