Edi в логистике что это такое
EDI стандарт. Технический обзор
Формат данных в EDI
EDI использует delimited text формат. Он хорошо работает для плоских структур данных, таких как таблицы. Он не так хорош для представления иерархических структур данных. Вложенные объекты лучше сериализуются с помощью tagged форматов, таких, как XML и JSON.
Очень странно, но так и не был создан язык описания (document definition) для EDI. Прошло столько лет с момента появления EDI и столько усилий было затрачено на него, но язык описания так и не создан. Язык описания позволяет автоматизировать обработку данных, а именно их генерацию, верификацию, преобразование, сериализацию, десериализацию. Для сравнения, для верификации XML данных мы берем схему данных (XML Schema, xsd) и парсер автоматически проверяет данные на соответствие этой схеме.
Можно обойтись и без схемы, но тогда желательна разметка документа. XML и JSON документы могут быть десериализованны и без схемы, потому что сами данные содержат тэги (имена) элементов данных. EDI имеет тэги только для сегментов и не имеет тэгов для элементов. Элементы определяются позицией внутри сегмента. Универсальный EDI парсер сможет разобрать документ только на примитивные коллекции, потому что документ не содержит ни имен, ни типов для элементов данных.
Давайте обратимся к деталям.
Пакетный формат
ISA*00* *00* *ZZ*RECEIVERID *12*SENDERID *100325*1113*U*00403*000011436*0*T*>
’ — символ разделения сегментов; ‘*’ — символ разделения элементов внутри сегмента; ‘>’ — символ разделения подэлементов внутри элемента. Изменяя эти символы мы по сути изменяем форматы пакетов и документов. В XML и JSON разделительные символы прописаны в стандарте, их нельзя изменить. Изменяемые разделительные символы — это рудименты эпохи, когда Unicode еще не был создан. Но даже в те времена делать разделительные символы изменяемыми было не очень хорошей идеей. Разделительные символы — очень важные символы. Если мы можем использовать любые символы в качестве разделителей, это не только именяет логику разбора пакетов на составляющие части, это сильно усложняет логику разбора текста внутри самих элементов.
Еще в ISA сегменте мы видим элементы, определяющие форматы времени и дат. Они помогают нам использовать настраиваемые форматы дат и времён внутри документов. Это имело смысл в семидесятых годах, когда нам надо было сохранить несколько байт при кодировке дат и времён. Нужны ли эти элементы теперь, после того как мы побороли проблему «2000-ного года», после того как были созданы специализированные и очень подробные стандарты представления времени?
Мы видим в ISA сегменте элементы, определяющие отправителя и адресата. По сути это — адресная (routing) информация. То есть стандарт упаковки объединен со стандартом адресации. Используя EDI, мы должны задавать отправителя и адресата внутри наших данных. В сегменте ISA есть еще и авторизационные элементы. Вся идея размещения этой авторизационной информации внутри самих сообщений когда-то была довольно прогрессивная, но сейчас она выглядит по меньшей мере наивной, а то и опасной. Сейчас мы понимаем, что авторизационная информация — много-много сложнее чем пара значений. То же самое можно сказать и про адресную информацию. EDI стандарт подталкивает нас к использованию этих элементов.
Еще мы видим элемент запроса подтверждения (acknowledgement request). То есть создатель документа задает стратегию использования подтверждений прямо в документе. Хорошая ли это идея? Мы можем использовать документы в разных сценариях. В некоторых из них подтверждения используются на уровне приложений, в других для повышения надежности используются другие протоколы. Политика надежности определяется не внутри самих данных, потому что надежность — это довольно сложная тема в передаче данных, определяемая многими участниками коммуникации.
Еще внутри сегментов пакетов мы видим контрольные номера (Control Numbers). Они нужны в сценариях, когда мы получаем набор документов, но часть набора потеряна или искажена по пути, и мы пытаемся восстановить как можно больше данных. Этот сценарий давно уже не используется, так как подобная проблема надежности как правило решается на нижних уровнях коммуникационных протоколов. Мы не встраиваем надежность коммуникаций на уровень приложений, так ведь?
Другой элемент ISA сегмента, это EDI версия (Standard Identifier). Это похоже на поддержку версионности, знакомую нам по сериализационным стандартам.
В сегменте GS находится элемент, определяющий тип документа (Type of Document). К примеру, это заказ или накладная. Ничего очень плохого в этом нет, хотя задавать тип документа проще внутри самого документа.
Как видим, практически все элементы в пакетных сегментах или бесполезны, или, более того, опасны, если мы будем их использовать в соответствии со стандартом.
Пожалуйста, не пытайтесь использовать данные из пакетных сегментов для аутентификации и адресации.
EDI был создан во времена, когда размещение этой информации в пакетах было единственным вариантом. Сейчас мы передаем документы через интернет и используем большой набор стандартов и протоколов для упаковки, адресации, аутентификации, авторизации, надежности, кодирования, сериализации, сегментирования и т.д., и т.п. Специфичная для конкретного протокола информация добавляется и удаляется на всем пути данных, и эта информация независима от самих данных.
EDI — это стандарт формата данных или протокол?
EDI пытается быть протоколом, именно поэтому мы видим эти элементы адресации, авторизации и запроса подтверждения. Я не знаю, как эту информацию можно сопоставить с OSI protocol layer model.
Но все же большая часть EDI стандарта посвящена форматам данных.
Форматы документов
Внутри пакетов мы видим сами документы. Но мы не найдем стандарта для универсального, обобщенного документа. Стандарт определяет многочисленные форматы для всевозможных типов документов: для заказов, для накладных, для описей вложения… Здесь вы найдете небольшую часть из громадного списка стандартизованных документов.
EDI следует известному мифу: «Где-то там есть идеальный формат, который описывает все на свете сценарии. Мы обязательно найдем этот формат. Нам нужно просто добавлять новые сценарии и подстраивать старые.»
Как результат EDI стандартные документы (спецификации) чрезмерно сложные.
Возьмем один пример: Нам нужна накладная для небольшого местного книжного магазина. Мы нашли подходящую стандартную спецификацию, EDI 850, заказ на покупку (Purchase Order). На первый взгляд он выглядит чересчур детальным. Мы не будем покупать продукты питания, уголь, зерно, жидкие продукты, опасные продукты, медицинские препараты. Нам не нужны международные адреса. Мы не будем использовать службы срочной доставки. EDI спецификация описывает все эти возможные варианты, но в ней слишком много полей, которые мы никогда не будем использовать. Она чересчур сложна для нашего простого документа.
Существует много индустриальных (domain) стандартов, которые используются как своеобразные хранилища знаний. Но эти стандарты не используются как стандарты передачи данных. (Посмотрите эту статью, описывающую проблему индустриальных стандартов.)
Циклы (Loops) внутри документов
Структура индивидуальных документов довольно проста. Документы составлены из серии сегментов, внутри которых находятся данные документов.
Но оказывается, что сегменты могут объединяться в группы или в повторяющиеся группы, так называемые циклы (loops). Пикантность в том, что эти циклы абсолютно никак не выделены в документе. О наличии цикла мы можем прочитать в спецификации данного конкретного документа. Сегменты одинакового типа (с одинаковыми тэгами) могут располагаться как независимо, так и внутри циклов. Создать парсер, распознающий циклы (которые, повторяю, никак не отмечаются в документе), это довольно нетривиальная задача.
В XML и JSON такой проблемы не стоит, иерархические объекты или коллекции объектов любого уровня вложенности очень просто задаются с помощью открывающих и закрывающих тэгов, именованных или неименованных.
EDI попытался усидеть на двух стульях. С одной стороны, его документный формат похож на формат csv и удобен для представления табличных данных. С другой стороны, он пытался описывать иерархические объекты, и попытка эта окончилась очень неубедительно. Конечно, мы понимаем это сейчас, когда имеем перед глазами JSON. Но давайте вспомним, что EDI был сделан не для передачи табличных данных, а именно для передачи документов, структура которых именно иерархическая.
Нетехнический взгляд на EDI
Как видим, EDI стандарт устарел практически в каждом аспекте, если мы рассматриваем его с технических позиций. Вряд ли сейчас есть рациональные технические причины для его использования. Но, несмотря на это, EDI по-прежнему широко используется.
В следующей части мы постараемся найти этому причины. Скорее всего они будут не технического характера.
Что такое EDI-система. Типы EDI-сообщений
Чем больше у вас контрагентов, тем сложнее организовать закупки и отгрузки. Этот ликбез для тех, кто устал от таблиц в Excel, гор бумажных документов и хочет работать проще. Разбираемся в EDI за 10 минут.
Что вы узнаете
Что такое EDI
EDI — система электронного обмена данными. Она позволяет передавать коммерческую и логистическую информацию. По EDI поставщики и покупатели отправляют заказы, прайсы, счета, уведомления об отгрузках и другие документы.
Чем отличается от ЭДО
Между EDI и ЭДО разница в том, что EDI-документы не имеют юридической силы и строгого формата. Их основная функция — ускорение бизнес-процессов. При ЭДО документы составляют строго по требованиям закона и заверяют квалифицированной электронной подписью. Это делает их юридически значимыми и позволяет предъявить в госорганы.
В СБИС можно совмещать ЭДО и EDI. Так вы ускорите работу по поставкам и обеспечите юридическую значимость электронных документов.
Где используется EDI-система
Если раньше электронные заказы отправляли только крупные торговые сети, то сейчас этим занимаются и небольшие продавцы. EDI-провайдер СБИС выбирают более 70 торговых сетей и поставщиков по всей России.
Типы EDI-сообщений
Существует около 50 типов стандартных сообщений, но на практике их требуется гораздо меньше. Рассмотрим 7 основных.
PRICAT (Price Catalogue) — каталог товаров с ценами и характеристиками. Его отправляет поставщик.
ORDERS (Purchase Order) — заказ на поставку. В нем покупатель перечисляет заказанные товары, их количество, цены, даты и адреса доставки.
ORDRSP (Order Response) — ответ на заказ. В нем поставщик подтверждает или корректирует заказ.
DESADV (Despatch Advice) — уведомление об отгрузке. Поставщик отправляет при отгрузке и отмечает, сколько каких товаров отгружено и по какой цене.
RECADV (Receiving Advice) — уведомление о приемке. Покупатель сообщает, сколько и каких товаров получено.
RETANN (Announcement for Returns) — уведомление о возврате с указанием причины. Отправляется покупателем.
INVOIC (Invoice) — черновик УПД. Приходит от поставщика покупателю.
Схема работы EDI
Цепочки взаимодействия между покупателями и поставщиками могут отличаться: зависит от специфики деятельности и категорий товаров. Но примерную схему нарисовать можно.
Самая простая и распространенная цепочка EDI — заказ.
Дополнительные EDI-сообщения
В схеме выше мы показали обычный функционал EDI, где не задействовали сообщения с дополнительными сведениями. Смотрите, что еще можно передать.
RETDES — уведомление об отправке возврата. Покупатель подтверждает факт отправки возвращаемого товара.
RETREC — уведомление о приемке возврата. Поставщик подтверждает получение возвращенного товара.
ALCDES — уведомление об отгрузке алкогольной продукции. Поставщик отправляет вместе с DESADV или после него. ALCDES сообщает дату розлива, код вида алкогольной продукции, страну происхождения, данные лицензии на алкоголь, данные производителя.
DELFOR — график поставок. Покупатель регулярно отправляет поставщику, чтобы тот наперед знал потребности покупателя и мог поставлять заказы в полном объеме без задержек. DELFOR можно отправить по конкретным товарам или адресам доставки.
PARTIN — информация о местах доставки. Продавец отправляет поставщику, чтобы тот своевременно внес данные о контрагенте в свою учетную систему. Отправляется в начале сотрудничества и при каждом изменении реквизитов у продавца.
APERAK — оповещение о статусе документа. Системное сообщение о статусе отправленных ORDRSP и DESADV: принято или найдены ошибки.
EDI как базовая система для электронного обмена данными и интеграций с партнёрами
Содержание
EDI возник в 1970–1980-х и популярен до сих пор. Как и многие другие ранние информационные технологии, EDI-обмен придуман военными и изначально использовался в логистике.
В конце 1940-х воздушное сообщение в Европе сопровождалось передачей больших объёмов информации о грузах, при этом процесс обмена данными был неудобным, остро требовалась разработка новых концепций и методов обмена. Одной из первых интегрированных систем, использующих EDI, была схема лондонского аэропорта Cargo EDP Scheme (LACES) в аэропорту Хитроу (Лондон, Великобритания) в 1971 году. Внедрение метода прямого ввода данных трейдером (DTI) позволило экспедиторам вносить информацию непосредственно в систему таможенного оформления. После этого процесс оформления стал быстрее и легче.
Рост морских перевозок и проблемы на таможне, схожие с теми, что возникали в аэропорту Хитроу, привели к внедрению систем DTI в некоторых портах и группах портов в 1980-х.
Электронная передача данных между компаниями, а также между бизнесом и государством в едином, общем для всех формате привлекала всё больше внимания, и в 1987 году был утверждён стандарт UN/EDIFACT (стандарт Организации Объединённых Наций для электронного обмена данными в управлении, торговле и на транспорте). ООН взяла на себя эту ответственную миссию и до сих пор выпускает обновлённые справочники каждые полгода, инвестируя в эту работу немалые средства. Справочники содержат стандартные сообщения для разных отраслей, сейчас это более двухсот сообщений.
В разработке справочника принимает участие и Технический комитет по стандартизации № 154 Международной организации по стандартизации (ISO, сокр. от англ. International Organization for Standardization).
Использование единых стандартов EDI удобно бизнесу и выгодно контролирующим органам: таможенной, налоговой службе и т. д. Это делает обмен сообщениями прозрачным и легко управляемым. ООН даже рекомендует использовать стандарт UN/EDIFACT при обмене сообщениями в государственных органах и между правительствами стран.
Итак, для интеграций с иностранными партнёрами может использоваться стандарт UN/EDIFACT, а для обмена данными с компаниями внутри России распространены его подмножества, например SWIFT — в банковской сфере, EANCOM — в торговле. Также есть ряд других подмножеств для разных отраслей.
В российской интернет-торговле распространён формат CommerceML в виде XML от «1С», а также YML (сокр. от англ. Yandex Market Language) в виде XML. Но если вам нужна интеграция с глобальными корпорациями, этот стандарт не будет им знаком.
В Северной Америке распространён стандарт Американского национального института стандартов (ANSI, сокр. от англ. American National Standards Institute) — ASC X12 (также известен как X12).
GS1 EDI устанавливает стандарты в глобальных поставках. TRADACOMS — стандарт, распространённый в ретейле Великобритании. ODETTE, VDA используются в автомобильной промышленности, HL7 — в здравоохранении.
Заказчику разработки необходимо определиться: нужен ли ему именно обмен юридически значимыми документами, отчётность или всё же интеграция ИС? Это разные вещи.
Естественно, что у бизнеса есть много юридически значимых документов, которыми нужно обмениваться с покупателями, поставщиками и налоговой (как минимум). Особенность EDI в России — в многообразии форм: на рынке есть несколько систем электронной отчётности («СКБ Контур», СБИС); формат УПД (сокр. от «универсальный передаточный документ») носит рекомендательный характер; есть несколько операторов ЕЦП (сокр. от «единая цифровая подпись») и т. д.
Но обмен проще, когда все стороны используют единый формат и единые правила. Чтобы сделать такую интеграцию, нужен электронный документооборот. В таком случае под EDI подразумевают набор стандартов (Legacy), касающихся электронного документооборота.
EDI как средство отчётности и обмена юридически значимыми документами — обширная тема, но в этой статье мы поговорим об EDI как о технологии для интеграций: именно с этой частью задач мы имеем дело в своей работе.
Простая XML-схема не подойдёт.
Разработка собственных EDI-стандартов потребует большого количества усилий аналитиков (а если мы говорим о межгосударственном взаимодействии, то и политиков) с обеих сторон. А вот усилия, потраченные на техническую реализацию, в сравнении с согласованиями будут незначительными.
— Так сложилось исторически. Во-первых, все основные логистические системы и WMS были созданы 20–30 лет назад, когда существовал только EDI. Сейчас эти WMS не просто древние, а мегадревние, и сделать для них API часто бывает невозможно.
Во-вторых, в логистике до сих пор есть очень высокий уровень доверия к обмену файлами по EDI. Логисты — прагматичные люди, им привычнее представлять файл как физический объект, артефакт. С EDI логист может сказать «я выслал тебе файл» и «я получил твой файл». Ответственность прозрачна: каждый участник обмена всегда может доказать, что, когда и кому он отправил.
API и транзакционный обмен гораздо сложнее для понимания. Сложно концептуализировать формат передачи данных через API и доверять ему. Думаю, это главная причина, по которой EDI-обмен так популярен. Но во многих логистических компаниях уже есть подвижки: приходит молодое поколение с другими взглядами на EDI и API.
В-третьих, написать скрипт и подключить его к API гораздо сложнее, чем использовать EDI. У большинства IT-решений есть стандартная EDI-спецификация на входе или на выходе, и это достаточно легко использовать: когда ты хочешь подключить одну систему ERP-клиента к WMS или другой ИС, тебе достаточно сделать mapping — не нужно писать скрипты, методы, подключать их к API и т. д.
EDI: что это такое, типы документов, расшифровка понятия — система электронного обмена данными
Стандарты EDI-технологий разработаны в одном из Американских национальных институтов (ANSI). Их применение обеспечивает комфортные условия для ведения и развития бизнеса. На этой почве популярность технологий проявилась и в других отраслях экономики, а также в социальной сфере. Что же это такое — система электронного обмена данными EDI (еди ай) или Electronic Data Interchange.
Про платформу
Контрагенты пользуются ей для обмена информационными данными в интернет-формате. Здесь доступна отправка и принятие финансовых, коммерческих и логистических сведений. Круг посылаемых и принимаемых документов не ограничен. Это могут быть также каталоги и любая сопроводительная документация к заказам. Пользователь моментально обрабатывает заявки, отправляет документы поставщикам или торговым сетям. Усилий на это тратится минимальное количество, и взаимодействие происходит чрезвычайно быстро. Плюсом является и то, что сервис способен проводить проверки на наличие ошибок. Формировать данные разрешается даже для госсистем, контролирующих производство, сбыт и сертификацию продукции на территории России, например, ЕГАИС.
Кроме того, платформа предлагает хранение созданной документации. Таким образом, можно по опознавательным признакам найти нужную бумагу, хранящуюся в защищенном архиве. Доступна и опция по формированию отчетности. Этому способствует внедренный сюда аналитический Business intelligence инструмент.
Фактически предлагаемая система не нова. Расшифровка EDI-технологии — это Electronic Data Interchange. Она является новшеством в сознании российских предпринимателей, медленно принимающих прогрессивные идеи для облегчения их работы. Тем не менее опыт использования показал, что обсуждаемая здесь технология помогает оптимизировать деятельность и в целом развивать свой бизнес гораздо эффективнее. Она позволяет отправлять заявки, обрабатывать информацию по тысячам заказов ежемесячно. Хотя такой объем необязателен. EDI становится частью электронного документооборота, который присутствует повсеместно на большинстве предприятий.
Если, к примеру, ваша компания работает с маркировкой определенных видов товаров (обувь, табак, одежда, алкоголь и др.), то ведение ЭДО для вас обязательно. А облегчить и оптимизировать этот процесс вам поможет ПО, предлагаемое компанией «Клеверенс».
Стандарты и способы передачи данных
Для EDI-обмена можно использовать широчайший массив международных нормативов для удовлетворения всевозможных запросов. Но в первую очередь необходимо понимать значение представленных далее двух стандартных идентификаторов.
GTIN-код
В расшифровке это Global Trade Item Number или уникальный цифровой штрихкод товара. Он заменил американский UPC и европейский EAN. Присваивается национальными регистраторами и зашифровывается в геометрическом формате. В него включаются циферный ряд, состоящий из разного количества цифр: 8, 12, 13, 14. Сведения о нем заносятся в единую информационную базу, действующую по всему миру. Такой штрих-код для товарных категорий получают производители, владельцы брендов, импортеры. Его разработкой и принципом присвоения занималась международная организация GS1.
GLN-код
Полное значение — Global Location Number. Уникализированный код из 13-ти чисел. Нужен для идентифицирования пользователя в системе, то есть для обозначения всех участвующих в поставке лиц. Его расположение — зачастую под штрихкодом. Кроме национального префикса, здесь содержится информация про фигуранта сделки: его адрес для почтовых отправлений, категория объекта, регион размещения, телефонный и факсовый номера, реквизиты банка, требования и ограничения по доставке, а также указание представителя фирмы для связи.
Чтобы организации-поставщику создавать партнерские отношения с торговыми объединениями, ему приходится получить GLN.
EDI в логистике, примеры и перспективы
Давайте зададимся вопросом «что такое логистика?»
С точки зрения практического применения логистика — это выбор наиболее эффективного варианта обеспечения нужного товара, нужного качества, нужного количества, в нужное время, в нужном месте и с минимальными затратами. Поэтому необходимым условием работы логистической отрасли является эффективное управление и быстрая передача информации, именно этот фактор и оптимальная организация бизнес процессов в компании, позволяют ей осуществлять эффективную логистику.
Думаю, что никто не будет спорить, что оптимизация работы с потоком информации и бизнес-процессов в целом возможна на сегодняшний день исключительно благодаря использованию современных информационных технологий. Именно о технологиях и возможностях, которые дают решения Comarch, я и хотела Вам рассказать. Решения Comarch по обмену данными и управлению документами позволяют оперативно и безопасно обмениваться информацией, управлять документами и перепроверять данные на корректность, что помогает участникам логистического процесса быстро адаптироваться к любым изменениям.
В течение 25 лет Comarch помогает своим партнерам, работающим во многих отраслях промышленности, внедрять соответствующие решения ИТ для оптимизации процессов обмена информацией. Проект по реализации обмена данными реализуется для оптимизации обмена информацией между производителем, дистрибьютором и розничными сетями. Но сегодня прогресс не стоит на месте, и компании ищут всевозможные пути для усовершенствования взаимоотношений с партнерами в каждом аспекте сотрудничества. Одним из востребованных процессов сегодня является автоматизация обмена логистической информацией. Реализовать такого рода обмен данными можно как в рамках уже реализованной схемы, так и используя новые типы электронных документов, а также подключая новых участников, например, логистических операторов, перевозчиков.
Одним из возможных вариантов может быть автоматизация передачи штрих-кодов логистических единиц. Штрих-код (код SSCC), находящийся на логистической этикетке, передается в электронном документе (Уведомление об отгрузке). Таким образом грузополучатель точно знает сколько товара и в каких логистических единицах будет доставлено на склад. Ответственному сотруднику остается только сканировать штрих-код и товар принят. Функционал Платформы Comarch B2B Network позволяет определять разные логистические единицы, задавать определенный алгоритм формирования кода SSCC либо вводить его вручную, создавать логистическую этикетку на основе уведомления об отгрузке. Дополнительно облегчает работу с грузом визуальное отображение важных данных о грузе на самой логистической этикетке, например: срок годности, данные об аллергенах и другие параметры.
Другой возможный вариант – это автоматизация обмена информацией с логистическими операторами. В этом случае могут использоваться как торговые электронные документы: Уведомление об отгрузке с кодом SSCC, Уведомление о приемке, Инструкция по упаковке, так и логистические электронные документы: Заказ логистических услуг, Информация о транспортном средстве и т.п.
Компания Comarch имеет опыт реализации множества успешных проектов логистического характера, среди которых хотелось бы отметить следующие:
Автоматизация обмена информацией с логистическими партнерами для UNILEVER:
В рамках проекта для компании LEROY MERLIN удалось:
– Автоматически создавать уведомление об отгрузке (DESADV) на основе полученного заказа согласно спецификации Leroy Merlin;
– Создавать логистические единицы, соответствующие требованиям Leroy Merlin (включая поддоны, коробки, рулоны), наряду с автоматическим/ручным вводом SSCC-кода и возможностью обозначения логистических единиц в случае сгруппированных товаров
– Быстро и легко сопрягать линию заказа с данной логистической единицей и указывать количество товара, которое необходимо упаковать. Дополнительно, появилась возможность упаковки незапакованного товара с помощью одного нажатия;
– Распечатывать логистическую этикетку согласно шаблону Leroy Merlin непосредственно из веб-приложения (без необходимости установки приложения on-site) на принтере этикеток (например, Zebra, Sato) и офисных принтерах.
Среди преимуществ внедрения EDI в логистике можно выделить: обмен коммерческой и логистической информацией в одном месте, быстрый и безопасный обмен ключевыми данными, улучшение качества данных, разные способы подключения (веб-приложение и интеграционное соединение), адаптация к требованиям и техническим возможностям каждого участника, доступ ко всем статусам реализации поставки в одном месте, что несомненно ведет к значительной оптимизации логистических процессов и положительно влияет на другие бизнес-процессы в компании.
Для получения более детальной информации касательно EDI в логистике обратитесь в техническую службу поддержки платформы COMARCH EDI по телефону 0 800 300 142.
Больше информации о решениях по обмену данными и управлению документами на сайте.
Автор: Анна Васильева, бизнес-консультант по решениям электронного документооборота Comarch e-invoicing на украинском рынке, компания Comarch.