Оптимизируем зоопарк: как поселить всех операторов ЭДО в одной клетке

Меня зовут Александр Андрюшин. Я расскажу о том, как в «Самокате» устроено ЭДО и взаимодействие с сервисами провайдеров на стороне 1С.

В 2022 году я пришел в компанию и подключился на проект создания мультипровайдерной шины с нуля. А до этого у меня за спиной четыре года внедрения ЭДО и EDI в различные торговые сети в одном из крупных провайдеров ЭДО.

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

Материал был подготовлен в 2023 году. С тех пор многое в продукте изменилось, но основные принципы работы остались актуальны. – Прим. ред.

Основная проблема рынка сервисов ЭДО/EDI

ЭДО – это и боль, и благо для любого бизнеса. Без ЭДО работать тяжело, а с ЭДО иногда еще тяжелее. Но если к нему приспособиться, ЭДО становится сильным подспорьем в любой крупной компании.

Одна из основных проблем современного рынка сервисов ЭДО и EDI заключается в том, что все операторы пытаются тащить одеяло на себя и максимально усложняют настройку роуминга, а некоторые даже отказываются обеспечивать такую возможность. Особенно это заметно в сегменте EDI.

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

Изначально в наш «зоопарк» ЭДО/EDI-систем входили:

• Две учетные системы для различных направлений деятельности – УТ для товарных поставок и СЭД для обработки документов.

• Две отдельные внешние обработки для 1С:УТ, обеспечивающие обмен документами с EDI-провайдерами. Эти обработки встраивались в нетиповую конфигурацию УT и были существенно доработаны, из-за чего их обновление становилось проблематичным. При изменении механизмов работы им требовались новые доработки, а это неизбежно влекло за собой дополнительные расходы времени и денег.

• Для ЭДО у нас использовалась сторонняя мультипровайдерная шина в виде внешней обработки – для каждой учетной системы своя.

• Между собой эти шины никак не синхронизировались – каждая работала со своими документами, отфильтровывая их по собственным алгоритмам. Из-за этого мы постоянно получали проблему дублей документов в разных базах, хотя с точки зрения логики документ должен был обрабатываться только в одной системе.

• А еще «Самокат» крайне быстро рос в объемах, как следствие, был лавинообразный рост количества документов.

Что хотел бизнес?

Текущий формат работы заказчиков не устраивал, и запросов на автоматизацию становилось все больше:

• Для бизнеса было важно максимально упростить работу с поставщиками. Изначально в компании использовалось два EDI-провайдера, бизнес просил третьего, а в перспективе четвертого и пятого. Мы понимали, что наш продукт должен поддерживать легкое и быстрое подключение дополнительных провайдеров. Но на практике подключение дополнительного ЭДО/EDI-провайдера занималось у нас от полутора до двух месяцев.

• Еще одним требованием было легкое масштабирование решения на все остальные юридические лица холдинга. Важно было предусмотреть в продукте возможность работы организации и в роли покупателя, и в роли поставщика. Реализация работы в обеих ролях и возможность полноценно генерировать как входящий, так и исходящий трафики ЭДО/EDI позволила нам упростить процессы автотестирования всех наших доработок.

• Большим сегментом системы стала функция внутреннего форматно-логического контроля – требовалось проверять документы не только в процессе тестирования, но и те, что приходят от поставщиков. Заказчикам было важно получать правильно оформленные документы, а далеко не все поставщики умеют отправлять документы корректно.

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

  • Мы проверяем документ на соответствие формату ФНС, если таковой есть.

  • Проверке подлежат не только обязательные поля формата, но и значения реквизитов, а также некоторые контрольные суммы по табличной части документа – мы сопоставляем цену номенклатуры с утвержденным прайсом и проверяем объемы поставок на соответствие заказу.

  • В то же время, система позволяет протолкнуть документ в работу, проигнорировав некоторые проверки, если это требуется заказчику.

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

• Как я уже ранее говорил, нам требовалась единая система обработки документов, при том, что в одном юридическом лице использовалось несколько учетных систем – как минимум, товароучетная система УТ и классический СЭД для обработки всевозможных документов. Продукт МПШ, который мы реализовали, умеет работать сразу с обеими этими системами, маршрутизируя документы между ними, что в принципе исключает проблему дублей в разных базах. Даже если документ ошибочно ушел не в ту информационную систему, в ручном режиме мы легко можем перенаправить документ, а впоследствии доработать логику маршрутизации.

• И финальная задача бизнеса – это архивное хранение документов. Например, при каждой проверке ФНС мы вынуждены предоставлять достаточно большой объем документов. Их нужно отобрать по определенным критериям и выгрузить в нужном формате.

Минусы сторонних решений

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

• Невозможность вести обмен с провайдерами от имени различных юридических лиц холдинга в одном месте.

• Необходимость поддерживать и дорабатывать обработки в каждой учетной системе.

• С учетом объема трафика документов возникала существенная нагрузка для учетных систем.

• Отсутствие мониторинга нагрузки и обработчика ошибок.

• Как следствие, стоимость внедрения и доработки подобных решений далеко не всегда гуманна.

Итог – делаем свою МПШ

Взвесив все «за» и «против», мы решили, что для реализации всех поставленных задач нужно написать свое собственное решение.

• МПШ – это МультиПровайдернаяШина обмена ЭДО с несколькими операторами, электронного документооборота и EDI.

• Это не просто вспомогательный инструмент, а полностью самописная конфигурация, которая позволяет работать с документами – как в своем интерфейсе, так и в сторонней системе, если поднята соответствующая интеграция.

При разработке мы постарались максимально унифицировать варианты работы с документами для простого масштабирования на юридические лица группы компаний. Это позволило бы в перспективе вывести это решение на рынок как коробочный продукт.

Этапы развития продукта. Выбор архитектуры решения и способа интеграции с провайдерами

Поговорим немного о создании продукта – в процессе его развития можно выделить три основных этапа:

1. Аналитика – выбор архитектуры решения и выбор способа интеграции с провайдерами.

2. Разработка и запуск базовой функциональности в продуктив – тоже в два этапа: внедрение EDI обмена и внедрение ЭДО обмена

3. Подведение итогов проекта и переход к оптимизации / доработкам на основании полученного опыта.

Сейчас подробнее о каждом из этих этапов расскажу.

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

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

• Контрагент с использованием сервиса провайдера отправляет нам документ.

• Мы получаем сообщение от провайдера и создаем из него сущность «Электронный документ» – через эту сущность мы впоследствии взаимодействуем с провайдером для получения печатных форм, статусов, подписания служебных квитанций и тому подобного.

• Внутри МПШ «Электронный документ» конвертируется в другую сущность – «Учетный документ».

• Далее посредством брокера сообщений Kafka этот учетный документ улетает в целевую систему.

• Обратный маршрут аналогичен.

• Параллельно процессу для обмена документами также есть вспомогательные контракты для обмена файлами и статусами.

По поводу выбора способа интеграции с провайдерами у нас были разные мысли.

Например, для EDI можно было бы придумать свой формат обмена и заставить операторов поддержать его, но здесь у нас возникли первые трудности:

• В качестве транспорта с провайдером нам, скорее всего, пришлось бы использовать какой-то файловый обмен – AS2, небезопасный FTP или перспективный, но сложный JMS, с которым, как потом впоследствии выяснилось, далеко не все провайдеры умеют работать, а мы были за унификацию.

• Внешние обработки для 1С мы отмели из-за сложности их внедрения в самописную конфигурацию.

• В итоге мы остановились на API, как на наиболее функциональном инструменте. Только API позволяет нам не только работать в реальном времени, но и получать исторические данные по запросу. Это решало вопрос синхронизации со старыми решениями – нам не требовалось перекачивать данные из базы в базу, можно было просто слить все запросом у провайдера.

Внедрение EDI обмена

После того как аналитика была закончена, мы начали разрабатывать.

Разрабатывать и запускать МПШ в продуктив мы решили поэтапно:

• Сначала внедряем и запускаем в работу EDI – он легче, там нет криптографии, обмены достаточно простые, это отличная возможность потренироваться с API провайдеров и понять логику их работы.

• Дальше мы внедряли уже ЭДО.

Типы документов для EDI-обмена у нас стандартные – такие же, как у большинства сетей:

• ORDERS – заказ;

• ORDRSP – ответ на заказ;

• DESADV – уведомление об отгрузке;

• RECADV – уведомление о приемке.

У каждого провайдера по данным типам документов используются свои форматы, поэтому нам пришлось внедрять каждый формат отдельно – благо набор данных по ним был плюс-минус одинаковый.

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

Таким образом мы от провайдера получаем сущность «Электронный документ» со своим типом и набором реквизитов в зависимости от типа.

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

В нашем случае в качестве целевой системы выступает УТ – оттуда уже полетят задания на приемку в складские сервисы наших РЦ и дарксторов, а также обратная информация о факте приемки.

Транспорт между информационными системами у нас выстроен на основании событийной интеграции – через брокер сообщений.

Немного подробнее о логике обработки документов.

• Заказ поставщику, полученный из учетной системы, мы конвертируем в классический ORDERS. В зависимости от настройки контрагента, электронный ORDERS генерируется в XML-файл соответствующего формата и благополучно уходит к нужному провайдеру.

• Получая ответ поставщика, мы создаем электронный ORDRSP. На основании него вносим определенные коррективы в заказ поставщику и передаем эту информацию нашим закупщикам.

• Далее мы ожидаем от контрагента DESADV. И здесь все становится намного интересней, так как начинается некоторое ветвление:

  • Если поставщик работает с ЭДО (а таких у нас уже около 95%), мы на DESADV не реагируем, потому что ждем документы по ЭДО.

  • Если ЭДО не предвидится, мы создаем у себя в базе МПШ ПТУ, передаем его в 1С:УТ, а дальше информация из УТ перетекает в соответствующие складские информационные системы. По факту приемки в складской системе формируется «Приходный ордер», через событийку летит к нам в МПШ, паркуется в набор документов по поставке, где его подхватывает регламент и формирует RECADV. На этом можно сказать, что EDI обмен закончен – поставка состоялась.

Внедрение ЭДО обмена

Но у нас есть еще и ЭДО. И здесь все становится немного сложнее.

С одной стороны, вроде бы должно быть проще, так как есть формат ФНС, где все четко регламентировано. Но на практике логика работы провайдеров местами сильно отличается, и нам в данном случае пришлось серьезно попотеть.

Сейчас у нас подключено 4 провайдера ЭДО и есть потребность в пятом. Модули интеграции с разными провайдерами сильно отличаются, но мы опять свели все к единому знаменателю:

• Так же, как и в случае с EDI, сообщения провайдера из ленты событий формируют «Электронный документ».

• Перед его конвертацией в «Учетный документ» требуется проверить корректность, сверить реквизиты и смаршрутизировать в нужную информационную систему.

• Таким образом, получив полностью разобранный электронный документ, мы его конвертируем в нужный нам целевой и по событийке отдаем.

• Вдогонку к «Учетному документу» идут статус, печатные формы или сами файлы для дальнейшей обработки.

В случае с товарным направлением возможна автоматическая обработка документов – например, подписание на основании «Приходного ордера» из складского контура: мы берем «Приходный ордер» и сравниваем его с «Учетным документом» (в нашем случае это ПТУ):

• Если данные совпадают, то накладывается команда на формирование и подписание титула покупателя с кодом итога 1 (принято без расхождений).

• Если количество принятого по «Приходному ордеру» расходится с ПТУ, то формируется учетный документ «Акт расхождений».

В случае формирования «Акта расхождений» мы уже выполняем несколько действий:

• Сначала мы формируем УоУ – уведомление об уточнении в адрес поставщика с текстом расхождений.

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

• Также на основании акта мы формируем электронный ТОРГ-2 в адрес поставщика. Здесь, к сожалению, тоже не все оказалось гладко так как формат есть, а регламент обмена ФНС не предоставила, и провайдеры стали придумывать свои регламенты.

• Финальное в работе с расхождениями – это автоматическое формирование корректировки и ожидание УКД.

По поводу формирования электронного ТОРГ-12 в зависимости от провайдера есть три варианта работы, которые выбираются, исходя из настроек на контрагенте:

• Первый вариант более-менее стандартный для любого документа – это классическое двухстороннее подписание.

• Второй вариант – односторонний. В этом случае регламент провайдера не подразумевает подписание документа второй стороной, документ носит сугубо информационный характер.

• Третий вариант – это всеми нами, наверное, нелюбимый роуминг. В роуминг мы отправляем простую печатную форму в формате PDF по регламенту неформализованного документа. В данном случае именно большое количество роуминга заставляет нас подключать дополнительных провайдеров.

Помимо автоматического формирования корректировки приобретения, УКД мы точно так же стараемся обрабатывать автоматически:

• При получении по ЭДО документа УКД мы подбираем корректировку, сверяем и, если все совпадает, подписываем.

• Если не совпадает, то подсвечиваем найденные расхождения и передаем документ на ручную обработку бухгалтеру в учетную систему УТ. Сотрудник бухгалтерии имеет отчет по корректировкам с полученными электронными документами и может напрямую в УТ инициировать действие по подписанию либо отклонению документа.

• Специально для удобства работы мы сделали кнопки, изменяющие статусы документов. Статусы синхронизируются в обе стороны и инициируют простановку команд – например, на подписание/отклонение/аннулирование и тому подобное. Также от статуса зависят допустимые действия над документом.

Итоги: какие планы, к чему стремимся

Менее чем за год мы вывели МПШ в продуктив и перешли к этапу оптимизации и масштабирования.

• Сегодня система успешно обрабатывает около 100 тысяч документов в сутки.

• Мы подключаем дополнительных провайдеров.

• Перерабатываем механизмы работы с лентой событий на более оптимальные.

• Масштабируемся на другие юрлица группы компаний.

• И придумываем задачи на будущее, анализируя новые потребности наших бизнес-заказчиков.

Задачи на развитие, которые стоят перед нами на ближайшее время:

• У нас есть потребность в кратном увеличении производительности системы. На синтетических тестах мы оценили нашу максимальную нагрузку в 1,5 миллиона документов в сутки. Но бизнес прогнозирует возможный рост до 4 миллионов документов в сутки.

• Для дальнейшей автоматизации нам также требуется внедрение новых типов документов – таких, как:

  • PRICAT – протокол согласования цен

  • формализованный договор в формате A-PDF;

  • внедрение электронных транспортных накладных.

• Для более точной проверки документов хотим вынести из УТ в контур МПШ некоторые модули взаимодействия с различными государственными информационными системами – Честный знак, Меркурий и другие ФГИС.

• И, чем черт не шутит, может быть, попробуем себя в ML и поработаем с распознаванием неформализованных документов.

Вопросы и ответы

На базе каких инструментов сделан МПШ? Логикой управляют брокеры? Или все зашивается в конфигурацию ЭДО? Есть ли возможность подключения сторонних не-1С-систем?

Можно интегрироваться различными способами – можно прикрутить REST API или наладить файловый обмен. Мы в данном случае работаем через Apache Kafka

МПШ не ограничена только 1С – интеграция возможна с любой информационной системой.

В чем была проблема работы от нескольких организаций? Вы же с провайдером работаете через API, авторизуетесь через токен, который привязан к конкретной организации. Понятно, что там сейчас еще МЧД появится, но разве есть ограничение на количество организаций?

Здесь ограничение не в API, а в реализации других интеграционных решений – тех обработок, которые предлагали сами провайдеры. У некоторых провайдеров для каждого юрлица приходилось запускать обработки в отдельных сеансах. А сейчас у нас на каждое юрлицо отдельная учетка провайдера, но мы можем одновременно с ними работать в рамках одной базы.

В чем проблема хождения формализованных документов в роуминге?

ТОРГ-2, например, не ходят в роуминге, хотя документ формализованный.

Вы говорили, что сначала отправляете заказы по EDI, а УПД по ним потом приходят по ЭДО. Я правильно понимаю, что в базе реализовано сопоставление этих сущностей и контроль?

Да, конечно. Получая УПД от контрагента, мы сравниваем ее с заказом, чтобы не было превышения, чтобы цены соответствовали, чтобы нам не привезли ничего лишнего.

В МПШ реализован интерфейс для работы пользователя, чтобы пользователь мог принимать решения в подобных ситуациях? Или это происходит автоматизировано?

Мы эту информацию автоматизированно подсвечиваем и передаем в целевую систему.

Как вы реализовали работу с электронной подписью в ситуации, когда несколько юридических лиц?

В данном случае мы копируем подпись на сервер. На данный момент (прим. ред. доклад от 11 октября 2023 года) мы работаем не с подписью генерального директора, а с подписью представителя юридического лица. До конца августа 2024 года у нас такая возможность есть – есть время подготовиться и проработать вопрос взаимодействия с МЧД и новым порядком подписания.

Какой размер у команды, которая реализовала МПШ за год?

На старте было три программиста, потом добавился четвертый. Сейчас команда немного расширяется, а я выступаю в качестве руководителя данного проекта.

Эта команда работает только над МПШ, правильно?

Да, все верно.

Как вы работаете с тем, что провайдеры в любой момент могут поменять API? У вас есть с ними какие-то соглашения, чтобы они, допустим, показывали дорожную карту?

Как правило, если изменения в API кардинальные и должны поменять логику работы, провайдеры анонсируют их заранее на своих ресурсах – недели за две-три, и за это время, в принципе, можно подготовиться.

Проверяете ли вы на этапе форматно-логического контроля соответствие МЧД и тому подобные вещи?

Да, конечно. При получении документа мы понимаем, что в пакете есть МЧД. Ее валидность проверяет сам провайдер. Мы же сейчас работаем над механизмом контроля полномочий: планируем разработать внутренний классификатор доверенностей контрагентов, чтобы автоматизировать проверку. Сейчас (прим. ред. доклад от 11 октября 2023 года) проблема в том, что во многих МЧД полномочия указываются просто текстом, и это вынуждает вести справочник МЧД вручную. При получении первой доверенности от контрагента мы заполняем полномочия в этом справочнике и дальше уже с ним работаем.

Вы сказали, что если у поставщика есть ЭДО (а таких 95%) DESADV от них не нужен – вы на его основании не создаете ПТУ. Так зачем вам этот документ?

Из DESADV мы забираем данные по ГУИД ВСД (ветеринарно-сопроводительных документов) и передаем их в ПТУ.

Вопрос по роумингу. Если у нас два провайдера, не такой большой документооборот (максимум десятки документов в сутки), обмениваемся только формализованными документами (УПД и счет-фактура), роуминг тоже не будет работать?

Роуминг в целом работает, но когда документов становится десятки тысяч, определенные накладки все равно случаются. Плюс на настройку роуминга нужно дополнительное время – поставщикам это не всегда удобно. Если провайдер не прямой, то приходится доносить те требования, которые у нас есть к документам. Не все провайдеры корректно могут это отрабатывать.

Почему вы решили реализовать форматы провайдеров, а не попросить провайдера реализовать ваш один?

Большая часть провайдеров с теми форматами, которые мы хотели бы реализовать на своей стороне, работает не через API, а через другие формы обменов – файловый обмен или SDK. А через API провайдер, как правило, работает только в своем формате.

У вас сотни тысяч документов. Как вы решаете проблему с тем, что провайдер может просто висеть? Есть ли балансировка на вашей стороне или у провайдера?

На стороне провайдера мне сложно сказать, что есть. Со своей стороны у нас есть многопоточная обработка. Если мы понимаем, что по одному провайдеру документов становится слишком много, мы выделяем дополнительные потоки для запросов в сторону провайдера.

Вы с контрагентом можете работать через нескольких провайдеров одновременно?

Мы можем использовать для товарного направления одного провайдера, для всего остального – другого, это допустимо. В принципе, мы даже можем завязаться на тип документа, такая возможность у нас есть – конкретный тип документа обрабатывать через конкретного провайдера.

Как вы проводили тестирование интеграций?

Все провайдеры предоставляют тестовые среды – учетки и стейджи API. Там можно посоздавать документы. Плюс, у нас на Vanessa поднято автотестирование, которое мы сейчас развиваем.

Нюансы по каждому конкретному провайдеру вынесены в макеты, в настройки или описаны в модулях? Насколько быстро нужно будет менять модули, если будет резкая смена форматов?

Мы поддерживаем версии форматов. Как известно, ФНС обычно предполагает какой-то переходный период, и мы можем работать по одному документу с несколькими форматами и ограничивать их работу по времени.

По поводу индивидуальности настроек в провайдерах и в нюансах работы – да, это вынесено в модули работы с провайдером. По каждому провайдеру – свой модуль.

Есть проблемы при работе с приглашениями к обмену по ЭДО с контрагентами нужно все время поддерживать актуальное состояние взаимоотношений. Как решена эта проблема?

На текущий момент с приглашениями мы работаем в ручном режиме. Далеко не у всех провайдеров это вынесено в API, как правило, это работает через личный кабинет. Но на наших поставщиках это не критично – один человек из группы поддержки вполне справляется с этим объемом.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.