Рынок EDI, ЭДО, ЭСФ в России активно развивается. И объем клиентов, ожидающих подключения к EDI провайдеру или оператору ЭДО, растет.
Как сделать подключение и переход на EDI и ЭДО быстрым, простым, технологичным?
Первым из множества решений является способ предложить клиенту работать через web-интерфейс платформы оператора. В облаке. Так называемый Web-EDI. Это может быть сделано очень быстро, клиент получает логин и пароль и входит в систему, видит там своих торговых партнеров, документы со статусами их обработки, может настроить свой профиль и начинает электронное взаимодействие в части заказов товаров и управления поставками. Однако у этого способа есть один существенный недостаток, — невозможно произвести перенос электронных документов между платформой оператора и собственной внутренней системой учета клиента (бухгалтерской системой, системой складского учета и т.п.).
Отказаться от собственной учетной системы клиент не может. Более того, в этой системе работает множество сотрудников клиента со своими ролями, настроены определенные процессы для принятия решений об отгрузках и оплатах товара, обработке первичных учетных документов. Все это тесно взаимосвязано друг с другом и выстраивалось годами. По этой причине клиент вынужден вести диалог с провайдером о реализации механизмов интеграции или переноса документов между платформой провайдера и внутренней системой (или системами) клиента.
Обеспечить перенос документов между платформой провайдера и учетной системой клиента помогает интеграция. Интеграция является вторым способом подключения клиента к платформе провайдера. И именно этот способ на сегодня становится наиболее востребованным. Интеграция на практике реализуется следующими механизмами:
- Предоставлением клиенту документации на API к платформе оператора. В этом случае клиент производит подключение своими силами или с привлечением организации, обслуживающей внутренние учетные системы клиента. При хорошо документированном и отложенном API оператору практически ничего дополнительного делать не нужно. Однако клиенту придется заплатить круглую сумму за реализацию и поддержку интерфейса обмена на стороне его учетной системы. Часто эта задача является технически сложной и дорогой. Косвенным подтверждением тому является тот факт, что сами операторы реализуют API-интеграцию друг с другом порою годами, многократно дорабатывая свои интерфейсы. Сегодня хорошими примерами интеграционных предложений можно назвать решения КОРУС Консалтинг СНГ и СКБ Контур.
- Предоставлением клиенту некоторого интеграционного модуля (коннектора), который устанавливается на сервере или локальном компьютере клиента и обеспечивает прием-передачу файлов между этим компьютером и платформой оператора. При таком способе интеграции клиент получает некое файловое хранилище документов у себя на компьютере и дальнейший перенос файлов между этим хранилищем и внутренними учетными системами является целиком прерогативой клиента. Подобный интеграционный модуль может иметь свой UI для просмотра документов и их статусов и использоваться как универсальный для любых учетных систем клиента. Это чем то напоминает электронную почту с набором входящих и исходящих почтовых ящиков для каждого контрагента. Скачать с сайта оператора, установить и настроить такой модуль довольно просто. Однако потом клиенту все равно придется заниматься переносом данных. Только уже между файловым хранилищем на своем компьютере и своей же учетной системой. Оператору этот способ также удобен и прост. А клиенту? Клиенту снова не очень.
- Предоставлением клиенту специализированного интеграционного модуля для конкретной учетной системы клиента. Так как самой распространенной в России учетной системой является 1С, то и наиболее востребованным интеграционным модулем является 1С адаптер. Задачей такого модуля является обеспечение бесшовной интеграции «1С-платформа провайдера». Погружаясь более детально отметим, что бесшовная интеграция предполагает правильное размещение новых входящих документов в базе данных учетной системы клиента, с учетом целостности и связанности данных, версионности и прочих особенностей кастомизации клиентом своей системы. Клиент получает возможность обмена документами непосредственно из привычных ему экранных форм, что упрощает процесс обучения. Такая интеграция исключает какие-либо дополнительные действия по вводу или переносу данных и документов. Иными словами, дает максимум преимуществ для клиента. Установить и настроить такой модуль просто только в случае типовых конфигураций 1С. И они на практике встречаются довольно часто. Но к каждой новой конфигурации нужно иметь свою версию модуля. Если конфигурация не типовая, кастомизирована клиентом, то вновь без программирования не обойтись. И после таких манипуляций интеграционный модуль станет уникальным решением для единственного клиента. Все это хорошо и удобно до тех пор, пока не потребуется что-то изменить. Например, по требованию бизнеса добавить новый атрибут в документ, или в связи с изменением законодательства перейти на новую спецификацию документа. Тогда ситуация из крайне удобной превращается в диаметрально противоположную. Эта проблема встречается все чаще и чаще и заслуживает более детального рассмотрения. Она ставит в тупик и клиента и провайдера и зачастую может привести к полному разрыву отношений.
Почему интеграция зачастую вызывает такие сложности?
Дело в том, что при обмене электронными документами в структурированном виде на провайдера возлагается ряд функций, требующих анализа содержимого документа, и по итогам этого анализа принятия тех или иных решений. В этом состоит отличие от пересылки бумажных документов, где почтальон перевозит документ в конверте, не заглядывая в него, или от простого перемещения файлов при использовании e-mail. Перечислим некоторые из функций, возлагаемых на оператора:
- проверить полноту и качество заполнения всех обязательных полей в документе, соответствие форматов данных требованиям спецификации,
- проверить логические и арифметические связи между значениями, в отдельных случаях произвести вычисления для заполнения результирующих полей,
- сверить ассортимент товара с ранее загруженным справочником
- проконтролировать цены на товары в соответствии с загруженным прайс-листом
- при возврате товара проверить, есть ли ранее проведенные документы на его поставку и по какой цене и так далее.
Каждое из этих событий оператору нужно обработать и сформировать соответствующий документ с исправлениями или служебное сообщение в адрес отправителя и получателя документа и загрузить что-то в учетную систему клиента. Иногда требуется вернуть документ отправителю с сообщением об ошибке или предложить повторно отправить документ с уже внесенными в него исправлениями. В этой ситуации оператор пытается расширить функционал своего интеграционного модуля и учесть в нем специфику кастомизированной клиентской системы. В результате интеграционный модуль становится уникальным и практически необновляемым. Стоимость поддержки таких интеграций резко возрастает. Временные затраты на внесение изменений и последующую отладку интеграционных модулей могут составлять несколько месяцев. И сквозной процесс управления поставками прерывается.
Вот пример краткого описания функций одного из релизов интеграционного решения СКБ Контур для Ашан и Nestle:
Из EDI сообщений мы используем только ORDERS и INVOIC. ЭТорг-12 и ЭСФ формирует провайдер на базе INVOIC в момент отправки груза в АШАН. Юридически значимые документы размещаются в ящике АШАНа в Диадок. Провайдер отправляет фактуру в АШАН в формате, требуемом учетной системой. Учетная система проводит сверку фактуры с приемкой и отправляет статус сверки провайдеру. На основании статуса в Диадоке автоматически производится ряд действий: подписание/отклонение ЭТОРГ-12, отправка поставщику подписанного уведомления об уточнении, перемещение документов в папку «Удаленные». Поставщик на основании уведомления об уточнении может выслать нам ЭКСФ и ЭИСФ. Вручную в Диадоке обрабатываются корректировочные ЭСФ и примерно 10% накладных.
Бывает и обратная ситуация, когда клиент сам вносит изменения в свою учетную систему и забывает проверить влияние этих изменений на интеграционный интерфейс. Эту ситуацию заметить заблаговременно бывает очень сложно. Обмен электронными документами прерывается до тех пор, к примеру, пока клиенту не позвонит его контрагент с претензией, почему нет заказов или поставок. А это уже конфликтная ситуация с возможными финансовыми последствиями. Идя на встречу клиенту, провайдер пытается контролировать и выявлять подобные ситуации заблаговременно по косвенным признакам, строя суточные графики активности клиентов и т.п. Или как-то выявлять изменения учетной системы клиента посредством тестирования ее конфигурации со стороны интеграционного модуля. Но все это очень дорого и сложно.
Наиболее правильное решение проблемы удешевления и упрощения интеграции лежит в распределении задач между вендорами или разработчиками учетных систем и операторами ЭДО.
Разработка и поддержка вендорами (1С, SAP, Axapta, Navision, Галактика, Парус, …) во всех конфигурациях своих решений открытых стандартных API для EDI и ЭДО в соответствии с утвержденными в России спецификациями электронных документов могли бы существенно облегчить электронный обмен с внутренней учетной системой клиента.
Такое требование к отечественному и зарубежному ПО, применяемому в России, может быть закреплено законодательно. И похожие успешные примеры можно найти в странах Европы и Латинской Америки.
Однако для этого нужны национальные стандарты EDI и ЭДО, а также организация, которая может их разработать и поддерживать в актуальном состоянии, учитывая как международные, так и российские особенности ведения бизнеса и взаимодействия бизнеса с госструктурами. Средства на финансирование такой организации должны быть сформированы совместно, бизнесом и государством. Ведь это и есть инвестирование в инфраструктуру, причем новейшую и высоко технологичную инфраструктуру, о которой так много говорят сегодня на всех уровнях.
Алексей Тихонов