При организации электронного документооборота (ЭДО) в системах 1С ключевыми критериями выбора провайдера являются стабильность работы при высокой нагрузке (от 1500–2000 документов в день), гибкость интеграции с нетиповыми или самописными конфигурациями, а также корректность обработки документов, поступающих по роумингу.
Разберем основные технические особенности, плюсы и минусы использования операторов Диадок (Контур) и СБИС (Тензор), а также архитектурные нюансы, которые необходимо учитывать при встраивании обмена в 1С.
Проанализируем способы подключения учетной системы к сервисам ЭДО, если конфигурация 1С существенно отличается от типовых решений:
У Диадока поставляются механизмы на базе расширений и специализированных интеграционных модулей. Для самописных и нетиповых конфигураций существует отдельная облегченная обработка, содержащая готовые шаблоны и структуру под произвольные конфигурации. По опыту специалистов, стандартная тяжелая обработка Диадока может замедлять конфигуратор при сохранении из-за большого количества модулей и форм, поэтому для нетиповых систем предпочтительнее использовать специальную модификацию или прямое API.
У СБИС интеграция чаще выполняется через внешнюю обработку или прямое взаимодействие с API. Внешняя обработка СБИС является универсальным инструментом, но при попытке кастомизации ее кода визуализация формализованных документов требует работы с XSLT-преобразованиями, что усложняет доработку печатных форм своими силами.
При использовании собственных алгоритмов интеграции и Диадок, и СБИС предоставляют развитые REST/HTTP API. Для Диадока разработчики часто пишут легкие модули прямого взаимодействия через COM/HTTP API, что позволяет обойти громоздкость типовых обработок и ускорить загрузку входящих пакетов в разы.
Рассмотрим частые технические сложности, возникающие при обмене документами между разными операторами ЭДО:
Основная проблема при роуминге между Диадоком и СБИС связанa с тем, как сервисы интерпретируют XML-файлы титулов продавца и покупателя согласно приказам ФНС (например, Приказ № 155 и Приказ № 820).
Проанализируем атрибуты XML-структуры УПД:
<!-- Пример структуры атрибутов в XML УПД -->
Документ КНД="1115125" Функция="СЧФ"
Документ КНД="1115125" Функция="СЧФДОП"
Документ КНД="1115125" Функция="ДОП"
Значения атрибута Функция определяют роль документа:
СЧФ — счет-фактура, используемый для расчетов по НДС.СЧФДОП — счет-фактура и документ об отгрузке (соглашение/акт) в одном файле.ДОП — документ об отгрузке товаров или оказании услуг (первичный документ, заменяющий ТОРГ-12 или Акт).Особенности отображения: При отправке из Диадока первичного документа ТОРГ-12 в формате Приказа № 155 с функцией ДОП (именной файл ON_SCHFDOPPR) СБИС при получении по роумингу может интерпретировать файл как УПД и генерировать печатную форму УПД. Если получатель является бюджетной организацией или строго завязан на печатную форму ТОРГ-12, это может вызывать разногласия. Для точной визуализации документов от сторонних провайдеров в 1С рекомендуется полагаться на парсинг XML-файла и собственные печатные макеты 1С, а не на встроенные XSLT-преобразования операторов.
При обработке интенсивного потока входящей первичной документации интерактивная работа пользователей через внешние обработки 1С приведет к постоянным блокировкам и зависаниям интерфейса. Выясним, как правильно построить архитектуру высокой производительности:
Загрузка XML-файлов, проверка подписей и создание входящих документов учетной системы должны выполняться на стороне сервера 1С с помощью РегламентныеЗадания. Запросы к API операторов следует выполнять пакетами через HTTP-соединение.
Не следует создавать документы учета (например, ПриобретениеТоваровУслуг или ПоступлениеТоваровУслуг) напрямую при получении XML. Сначала данные записываются в промежуточный регистр сведений или буферный справочник. В нем выполняется сопоставление номенклатуры, контрагентов и договоров, после чего оператор или автоматический алгоритм проводит документ учета.
При параллельной работе нескольких операторов или при отправке документа по автороумингу существует риск дублирования. Контролируйте уникальность входящих данных по сочетанию ИНН/КПП контрагента, номеру и дате документа, а также по уникальному GUID XML-файла (идентификатору файла ФНС).
Посмотрим на ключевые выводы по выбору системы: