Интеграция ЭДО (Диадок, СБИС) с магазином на Битрикс

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

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

Что такое ЭДО и зачем он B2B-магазину

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

Для оптового магазина на 1С-Битрикс это не абстрактное удобство, а прямая экономия. Каждая отгрузка B2B сопровождается пакетом закрывающих документов, и пока они ходят на бумаге, бизнес несёт скрытые издержки: почтовые расходы, зарплату сотрудников, которые печатают и сканируют, задержки в закрытии периода, потерянные оригиналы и, как следствие, невозможность своевременно принять НДС к вычету. ЭДО убирает физическую логистику бумаги целиком.

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

Наконец, ЭДО — это часть более широкой картины цифрового B2B. Электронные документы логично встают рядом с онлайн-оплатой по счёту, личным кабинетом дилера и интеграцией с учётной системой. Как выстроить документооборот B2B целиком, мы подробно разбираем в отдельном материале про документооборот B2B и ЭДО на Битрикс — там больше про процессы, здесь — про техническую интеграцию с операторами.

Какие документы ходят в ЭДО: УПД, счёт-фактура, акты

Документы в ЭДО делятся на две большие группы, и это деление напрямую влияет на интеграцию. От типа документа зависит, обязан ли оператор передавать его в строго заданном формате ФНС и нужно ли формировать XML по утверждённой схеме.

• Формализованные документы. Имеют утверждённый ФНС XML-формат: счёт-фактура, универсальный передаточный документ (УПД), корректировочный счёт-фактура и УКД, некоторые акты и накладные в формате ФНС. Именно для них важна точность формирования — любое несоответствие схеме приводит к ошибке приёма.
• Неформализованные документы. Договоры, счета на оплату, акты сверки, письма — их можно передавать в произвольном виде (PDF, скан), они тоже подписываются, но жёсткого XML-формата не требуют.

Центральный документ для торговли — УПД (универсальный передаточный документ). Он объединяет в себе функции счёта-фактуры и накладной (или акта), поэтому вместо двух бумаг отгрузка закрывается одной. УПД бывает двух статусов: со статусом «1» он заменяет и счёт-фактуру, и первичный документ (используется, когда есть НДС), со статусом «2» — только первичный документ (когда счёт-фактура не нужен). Для интеграции это значит, что формат один, а поведение по НДС зависит от поля статуса.

Отдельная история — счёт на оплату. Это неформализованный документ, и его нередко путают с онлайн-оплатой по счёту в самом магазине. Счёт на оплату в B2B удобно выставлять прямо в личном кабинете дилера и дублировать в ЭДО, а закрывающие документы (УПД, счёт-фактуру) присылать уже после отгрузки. Про то, как устроить выставление и оплату счёта в B2B на Битрикс, мы писали в материале про оплату по счёту для B2B.

Операторы ЭДО: Диадок и СБИС

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

Диадок — сервис компании СКБ Контур. Один из самых распространённых операторов, с развитым REST-API, готовыми модулями для 1С и большой абонентской базой. Для интеграции с сайтом важно, что у Диадока задокументированный HTTP-API и понятная модель сущностей: организация, ящик (box), сообщение (message), документ и его статусы.

СБИС — сервис компании Тензор. Тоже массовый оператор, часто уже стоит у клиентов, которые сдают через СБИС отчётность. У СБИС свой REST-API и своя логика авторизации по токену приложения. Функционально для магазина оба решают одну задачу, но детали API, форматы ответов и нюансы роуминга отличаются, поэтому интеграцию всегда пишут под конкретного оператора.

Выбор оператора чаще диктует не магазин, а сложившаяся практика: если бухгалтерия уже работает в Диадоке или СБИС и там настроена подпись, разумно интегрировать именно этого оператора и не плодить сущности. Если операторов нет вовсе, выбирают по цене тарифа (обычно считается по числу исходящих документов), удобству API и по тому, где сидит большинство ваших контрагентов — чтобы меньше зависеть от роуминга.

Электронная подпись и юридическая значимость

Сердце ЭДО — квалифицированная электронная подпись (КЭП). Именно она делает электронный документ юридически равным бумажному. КЭП выдаёт аккредитованный удостоверяющий центр (для юрлиц с 2022 года — Удостоверяющий центр ФНС), она привязана к организации и уполномоченному лицу и хранится на защищённом носителе или в облаке.

Для интеграции важно понимать несколько практических вещей о подписи.

• Подпись организации для автоматизации. Чтобы интеграция отправляла документы без ручного участия, используется сертификат организации, привязанный к сервисному ящику оператора. Он подписывает исходящие УПД программно через криптопровайдер.
• Машиночитаемая доверенность (МЧД). Если документ подписывает не руководитель, а сотрудник, с 2023 года требуется электронная доверенность в машиночитаемом формате. МЧД прикладывается к подписи и передаётся вместе с документом.
• Криптопровайдер. Для формирования подписи по ГОСТ нужен сертифицированный криптопровайдер (например, КриптоПро CSP). На стороне 1С это обычно уже настроено; при прямой интеграции с сайтом провайдер ставится на сервер или используется облачная подпись оператора.
• Двусторонность подписи. УПД подписывают обе стороны: продавец при отправке и покупатель при приёмке. Пока покупатель не подписал, документооборот по этому документу не завершён — это отдельный статус, который важно показывать в кабинете.

С точки зрения магазина на Битрикс критично не «встроить криптографию в сайт», а корректно передать в оператора уже сформированный и подписанный документ и потом отслеживать, кто и когда его подписал. В большинстве проектов подпись остаётся на стороне 1С или облака оператора, а Битрикс работает со статусами и файлами, а не с сертификатами напрямую. Это и безопаснее, и проще в поддержке.

Архитектура интеграции ЭДО с 1С-Битрикс

Прежде чем писать код, полезно нарисовать общую схему: кто формирует документ, кто подписывает, кто отправляет оператору и где во всём этом Битрикс. В большинстве B2B-проектов участников четыре: интернет-магазин на 1С-Битрикс, учётная система 1С, оператор ЭДО (Диадок или СБИС) и контрагент со своим оператором.

Есть две базовые схемы интеграции, и выбор между ними определяет весь проект.

• Схема через 1С (рекомендуемая для большинства). УПД и счета-фактуры формируются и подписываются в 1С штатным модулем ЭДО (1С-ЭДО, модуль Диадок или СБИС для 1С). Битрикс получает от 1С статусы и файлы подписанных документов в рамках обмена и показывает их дилеру. Криптография и форматы ФНС остаются в 1С, где это отлажено.
• Прямая схема (Битрикс ↔ оператор). Магазин сам формирует документы и общается с REST-API оператора: отправляет XML, инициирует подпись, слушает вебхуки статусов. Оправдана, когда учётной системы в виде 1С нет или когда документооборот нужно вести полностью на стороне сайта.

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

Сценарии обмена: исходящие и входящие документы

Любая интеграция ЭДО складывается из двух встречных потоков. Их удобно проектировать отдельно, потому что у них разная логика и разные точки касания с Битриксом.

Исходящие документы (магазин → контрагент). Это основной поток для продавца. По факту отгрузки заказа формируется УПД, подписывается КЭП и отправляется оператору, который доставляет его покупателю. Битрикс в этом потоке инициирует событие («заказ отгружен») и потом принимает статусы: доставлен, просмотрен, подписан покупателем или отклонён с указанием причины.

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

Для B2B-витрины ключевой сценарий выглядит так: заказ оформлен в кабинете дилера, оплачен по счёту, собран и отгружен; в момент отгрузки в 1С формируется УПД и уходит через оператора; Битрикс получает уведомление и меняет статус документа у заказа; дилер видит в кабинете «УПД отправлен», скачивает его, подписывает у себя, и статус в кабинете обновляется на «подписан обеими сторонами». Весь путь клиент проходит, ни разу не написав менеджеру.

Жизненный цикл электронного УПД

Чтобы корректно отображать статусы, нужно понимать полный жизненный цикл формализованного документа. У УПД он состоит из нескольких этапов, и на каждом оператор фиксирует событие, которое можно получить через API.

1. Формирование. В 1С (или в интеграции) создаётся XML-файл УПД по формату ФНС с реквизитами продавца, покупателя, позициями и суммами.
2. Подпись продавца. Документ подписывается КЭП организации-продавца. Без подписи он не может быть отправлен как юридически значимый.
3. Отправка оператору. Подписанный документ уходит оператору ЭДО, который присваивает ему идентификатор и фиксирует дату отправки.
4. Доставка покупателю. Оператор доставляет документ в ящик покупателя (при необходимости — через роуминг к другому оператору). Появляется статус «доставлен».
5. Приёмка и подпись покупателя. Покупатель просматривает документ и подписывает его своей КЭП (или отклоняет с указанием причины). Для двустороннего УПД это завершающий шаг.
6. Завершение или аннулирование. После подписи обеими сторонами документооборот завершён. При ошибке стороны могут по обоюдному согласию аннулировать документ — это отдельный статус.

Каждый переход статуса — это событие, которое стоит отразить рядом с заказом. Наивная реализация показывает лишь «документ отправлен», но опытный дилер хочет видеть именно текущее состояние: доставлен, но не подписан; отклонён; аннулирован. Хороший личный кабинет отображает эту цепочку как таймлайн, чтобы клиент понимал, ждут ли действия от него.

API операторов: Диадок и СБИС изнутри

Когда интеграция идёт напрямую, а не через 1С, магазин общается с REST-API оператора. Модели у Диадока и СБИС похожи концептуально, но различаются в деталях авторизации и наборе методов.

API Диадока (Контур). Работает по HTTP, авторизация — по ключу разработчика (API-ключу приложения) и токену авторизации сотрудника или сервисной учётной записи. Основные сущности: организация и её ящик (box), документы и сообщения (messages), в которые упакованы документы и подписи. Типичный сценарий отправки: получить список организаций, найти нужный box, сформировать сообщение с документом, подписать и отправить, затем опрашивать события ящика на предмет смены статусов. Для получения изменений есть метод выборки новых событий по указателю (индексу последнего обработанного события).

API СБИС (Тензор). Тоже HTTP-API, авторизация по токену приложения, который получают через сервисную аутентификацию с идентификатором приложения и секретом. Логика похожа: есть документы, их движения и статусы, методы отправки и запроса состояния. Различаются форматы полей, справочники статусов и способ постраничного получения обновлений. Поэтому даже при похожей архитектуре код интеграции для СБИС и Диадока не взаимозаменяем — обёртку пишут отдельно под каждого оператора, пряча различия за единым внутренним интерфейсом.

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

Связка ЭДО, 1С и Битрикс: где формируется документ

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

В типовой связке роли распределяются так:

Ключ к аккуратной связке — не дублировать данные, а обмениваться ими. Когда 1С отправила УПД и получила от оператора идентификатор документа и статус, эти данные передаются в Битрикс в рамках того же обмена, что и заказы: по идентификатору заказа проставляются номер документа, ссылка на файл и текущий статус. Тогда Битриксу не нужно ни формировать XML, ни знать про сертификаты — он получает готовую «карточку документа» и показывает её.

Если 1С в проекте нет, роль формирователя берёт на себя интеграционный слой на стороне Битрикса: он собирает XML по формату ФНС из данных заказа, отправляет облачной подписи оператора и работает с API напрямую. Это заметно дороже в разработке и поддержке, поэтому к прямой схеме прибегают, только когда учёт действительно ведётся не в 1С.

Реализация в 1С-Битрикс: модули и шаги

Теперь конкретика по платформе. Со стороны Битрикса интеграция ЭДО складывается из нескольких технических элементов. Ниже — как это раскладывается по модулям и компонентам.

1. Хранилище документов. Заведите под документы ЭДО отдельную сущность — highload-блок или пользовательские поля заказа (модуль sale). Минимальный набор полей: тип документа, номер, идентификатор у оператора, статус, дата, ссылка на файл, признак подписи покупателя.
2. Приём данных от 1С. Расширьте штатный обмен с 1С так, чтобы вместе с заказами приходили и данные по документам ЭДО. Обработчик события выгрузки заказа (OnSaleOrderSaved и события модуля обмена) сохраняет карточку документа рядом с заказом.
3. Приём статусов от оператора. Если статусы идут напрямую от оператора, реализуйте эндпоинт для вебхуков (публичный контроллер на bitrix:main / собственный модуль) и агент (CAgent), который по расписанию опрашивает API и обновляет статусы по указателю событий.
4. Отображение в личном кабинете. В компоненте личного кабинета дилера (кастомный компонент или доработка sale.personal.section) выведите список документов заказа со статусами и кнопками скачивания.
5. Уведомления. На смену статуса вешайте уведомление дилеру — письмо через CEvent, сообщение в кабинете или push. Клиент должен узнавать о новом документе без захода на сайт.
6. Права и безопасность. Ограничьте доступ к файлам документов: дилер видит только свои документы, ссылки на файлы отдаются через контроллер с проверкой прав, а не прямой ссылкой на файл в /upload/.

Схематично карточка документа ЭДО в интерфейсе заказа выглядит так:

Отдельно про производительность и надёжность приёма статусов. Вебхуки от оператора нужно обрабатывать быстро и идемпотентно: одно и то же событие может прийти дважды, и повторная обработка не должна ломать статус или плодить дубли документов. Практика — принять вебхук, положить его в очередь (или просто быстро сохранить сырое событие), ответить оператору 200 OK и обработать асинхронно агентом. Так вы не держите соединение оператора открытым на время тяжёлой логики и не теряете события при всплесках.

Статусы документов в личном кабинете дилера

Личный кабинет — это то место, ради которого магазину вообще нужна интеграция ЭДО с Битриксом (а не только с 1С). Хорошо сделанный раздел документов снимает основную массу обращений «а где мой УПД» и «пришлите подписанный экземпляр».

Что стоит показать дилеру:

• Список документов по каждому заказу. УПД, счёт-фактура, счёт на оплату, акты — с типом, номером и датой.
• Понятный статус. Не технический код оператора, а человекочитаемое состояние: «Отправлен», «Доставлен», «Подписан обеими сторонами», «Ждёт вашей подписи», «Отклонён».
• Действие, которого ждут от клиента. Если документ ждёт подписи покупателя, кабинет должен явно на это указывать — это ускоряет закрытие документооборота.
• Скачивание подписанного экземпляра. Файл документа вместе с протоколом подписей — то, что бухгалтерия дилера подошьёт к себе.
• Фильтр и поиск. По типу документа, статусу и периоду — чтобы в конце квартала легко собрать все закрывающие.

Раздел документов логично встроить в уже существующий личный кабинет дилера рядом с заказами, ценами и историей. Как устроить сам кабинет — отдельная большая тема, которую мы разбираем в материалах рубрики B2B и опт. Здесь важно одно: документы ЭДО — не отдельный «остров», а ещё одна вкладка в едином окне работы дилера с вашим магазином.

Роуминг между операторами

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

Что важно знать про роуминг на практике:

• Роуминг настраивается по паре операторов и по паре контрагентов. Для обмена с конкретным контрагентом у другого оператора обычно нужно один раз отправить заявку на роуминг и дождаться подтверждения.
• Настройка не мгновенная. В зависимости от операторов это занимает от нескольких часов до нескольких рабочих дней. Если запустить обмен «в лоб» без роуминга, документ просто не доставится.
• Автоматический роуминг. Между рядом крупных операторов (включая Диадок и СБИС) действует автоматический или упрощённый роуминг, когда заявка не нужна или обрабатывается моментально. Но полагаться на это для всех пар нельзя — проверяйте.
• Приглашение к обмену. Прежде чем слать документы, стороны обычно обмениваются приглашениями (устанавливают связь между организациями у оператора). Без принятого приглашения оператор не знает, куда доставлять документ.

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

Сравнение Диадок и СБИС

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

На практике решающий фактор — что уже стоит у вас и у ваших ключевых контрагентов. Если бухгалтерия годами работает в Контуре, тащить в проект СБИС ради магазина бессмысленно, и наоборот. Для интеграции же принципиально одно: обёртку над API пишут под конкретного оператора, но проектируют так, чтобы при необходимости добавить второго оператора без переписывания всей логики — за единым внутренним интерфейсом «отправить документ», «получить статус», «скачать файл».

Безопасность, хранение и сроки

Юридически значимые документы — чувствительные данные, и обращение с ними требует аккуратности как по закону, так и по здравому смыслу.

• Сроки хранения. Первичные документы, счета-фактуры и УПД хранятся установленные законом сроки (по общему правилу — не менее пяти лет, а для ряда документов дольше). Электронные экземпляры вместе с подписями и протоколами должны быть доступны весь этот срок.
• Хранение файлов. Сами подписанные документы удобнее держать у оператора (он гарантирует хранение) и в 1С, а в Битриксе хранить ссылки и кэш для быстрой отдачи дилеру. Дублировать полный архив на витрине не обязательно и рискованно.
• Разграничение доступа. Дилер должен видеть только свои документы. Файлы отдавайте через контроллер с проверкой прав, а не прямыми ссылками на /upload/, которые можно перебрать.
• Защита канала. Весь обмен — только по HTTPS. Вебхуки от оператора проверяйте на подлинность (подпись запроса, белый список IP, секретный токен в URL), чтобы никто не подделал смену статуса.
• Персональные данные. В документах есть реквизиты организаций и лиц — относитесь к ним по правилам обработки персональных данных и не выводите лишнего в логи.

Отдельно про целостность: статус документа в Битриксе — это всегда копия «истины», которая живёт у оператора. Проектируйте систему так, чтобы при расхождении источником правды считался оператор, а Битрикс умел пересинхронизировать статус по запросу. Это спасает от ситуаций, когда из-за пропущенного вебхука в кабинете висит «отправлен», а у оператора документ давно подписан.

Частые ошибки при внедрении

• Пытаются «встроить криптографию в сайт» и формировать УПД в Битриксе, хотя рядом есть 1С с готовым модулем ЭДО — это удорожает проект в разы и усложняет поддержку.
• Забывают про роуминг: запускают обмен, а документы контрагентам у другого оператора не доставляются, потому что межоператорское соединение не настроено.
• Не проверяют, подключён ли контрагент к ЭДО, и шлют УПД в пустоту — документы копятся в статусе «не доставлено».
• Синхронизируют статусы «дёрганьем всех документов подряд» вместо выборки по указателю событий — при росте объёма интеграция начинает тормозить и упирается в лимиты API.
• Обрабатывают вебхуки не идемпотентно — повторное событие плодит дубли документов или ломает статус.
• Показывают дилеру технические коды оператора вместо человекочитаемых статусов — клиент не понимает, ждут ли действия от него.
• Отдают файлы документов прямой ссылкой на /upload/ без проверки прав — чужие закрывающие документы становятся доступны перебором.
• Тестируют сразу в боевом контуре — ошибочный формализованный документ уходит реальному контрагенту, и его приходится аннулировать.
• Не закладывают пересинхронизацию: при пропущенном вебхуке статус в кабинете навсегда расходится с реальным состоянием у оператора.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность интеграции ЭДО перед запуском:

1. Выбран оператор. Определён Диадок или СБИС с учётом того, что уже используют бухгалтерия и ключевые контрагенты.
2. Подпись настроена. Есть действующая КЭП организации, при необходимости — МЧД для сотрудников; криптопровайдер работает на стороне 1С или облака оператора.
3. Схема интеграции выбрана. Решено, где формируется и подписывается УПД (1С или прямая схема), и Битрикс не дублирует эту логику зря.
4. Обмен с 1С расширен. Вместе с заказами в Битрикс приходят карточки документов: тип, номер, идентификатор у оператора, статус, ссылка на файл.
5. Приём статусов работает. Настроены вебхуки и/или агент опроса по указателю событий; обработка идемпотентна; есть пересинхронизация.
6. Личный кабинет готов. Дилер видит документы по заказам с человекочитаемыми статусами, действиями и скачиванием подписанных экземпляров.
7. Роуминг проверен. Для ключевых контрагентов у других операторов настроены соединения и приняты приглашения; есть признак «подключён к ЭДО».
8. Безопасность закрыта. Файлы отдаются с проверкой прав, вебхуки аутентифицируются, канал по HTTPS, сроки хранения соблюдены.
9. Всё обкатано на тесте. Отправка, подпись, приём статусов и роуминг проверены в тестовом контуре оператора до боевого запуска.

Вывод

Интеграция ЭДО с магазином на 1С-Битрикс — это не про то, чтобы научить сайт подписывать документы, а про то, чтобы выстроить прозрачную связку «1С формирует и подписывает — оператор доставляет — Битрикс показывает». Тогда УПД и счета-фактуры доходят до дилера за минуты, статусы видны в личном кабинете без звонков менеджеру, а бухгалтерия закрывает период без коробок с бумагой. Выберите оператора под свою ситуацию, оставьте криптографию и формализованные документы в 1С, аккуратно синхронизируйте статусы и не забудьте про роуминг — и электронный документооборот перестанет быть узким местом B2B-продаж.