Кто-нибудь имеет опыт использования EDI на больших объемах документов в типовых? Стоит вопрос, разрабатывать свою подсистему, начиная с архитектуры, с нуля, или можно за основу взять типовые? Объем входящих/исходящих документов примерно 20тыс. в день.

1с в марте говорила, что скоро будет edi

(1) Да я вот то-же посмотрел подсистему обмена ЭДО с контрагентами, судя по количеству метаданных с префиксом Удалить писатели типовых ещё в творческом поиске :(

1с-эдо сейчас сделано для ЮЗД

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

(3) ЮЗД - это грубое ругательство?

(3) Так архитектура от того, ЮЗД или не ЮЗД, по идее особо не должна меняться. Какая разница, какие сообщения обрабатывать, УПД или Desadv, подписание ЭЦП это уже сбоку.

(4) юридически значимый документооборот

По архитектуре мне пока ясно, что должно быть несколько независимых задач - получение сообщений от провйдеров, запись сообщений в БД в "сыром" виде, проверка корректности сообщений, обработка корректных сообщений, операции в ИС на основании сообщений, обработка ошибок.

Работал с EDI и на самописной обработке и на типовой от провайдера. Для понимания объёмов: количество ORDERS порядка 20 тыс. в день.
Обработка от провайдера удобнее, в том смысле что в ней уже прописан функционал по приёмке, разбору, формированию и отправке edi-документов и ЭДО (зависит от провайдера).
Но при таких объемах она все равно нуждается в доработке.
Если нужны подробности или какие-то консультации, то пиши в почту.

(5) это по идее. На практике отличий много, хотя бы в том что в ЮЗДО помимо самого дока существует ворох квитанций, каждая из которых тащит свою ЭЦП. В EDI ничего этого нет, в силу чего это в десятки раз легче по трафику и по документообороту.

а вообще занятно, что EDI сети заставляли людей внедрять примерно с 10 года, на 12-13 пришелся пик + добавились ON_SFAKT, а 1С распапашилась только сейчас :)

как говорится, не прошло и десяти лет

(8) Это хорошо, только вот провайдеров 5 штук действующих, поэтому нужен универсальный механизм. И типовые механизмы не обеспечивают быстродействия и надежности.

(10) Так это потому, что 1С и крупный бизнес повернулись лицом друг к другу относительно недавно. А крупный бизнес уже своих велосипедов настроил по EDI.

(9) Эти квитанции можно (и, я бы даже сказал, нужно) вполне себе сбоку прикрепить. Разбирался тут с обменом ЕГАИС с нуля, где какраз куча квитанций, всё это разбирается в одном потоке - это адъ какой-то.

(12) универсальный механизм уже разработан для формализованных документов. Между всеми провайдерами они передаются согласно формата, утвержденному ФНС. Т.е. здесь разрабатывать ничего не нужно, все и так разработано. Если же говорить формализованные не по стандарту, но обмен которыми предполагает обмен именно "формализованным" (стандартизированным) XML, а не бинари, и чтобы такой обмен был с виду - аналогичный формализованному, то здесь формализации никакой нет, т.к. пока нет настолько крупного заказчика, который бы смог "стандартизировать" свой формат, для всех провайдеров. Как правило, у крупных сетей в обязательном порядке при работе с ними через ЭДО, указан провайдер, у которого такая интеграция уже есть, и дешевле подключить себе +1 провайдер, нежели писать такой обмен.

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

(15) По ЮЗД да, согласен. Но DESADV, ORDERS и т.п. тоже вроде как формализованы, но только в теории. То есть, если у нас 5 провайдеров, у всех они будут хоть немного, да разными. При этом провайдеры тоже только на словах "обеспечивают единый формат от любого контрагента". Что влечет за собой как минимум необходимость разработать свою схему этих документов, и сначала все входящие приводить к этой схеме, и только потом грузить.

(16) в реальности они формализованы. EDI представляет собой довольно специфический формат, где теги являются невнятными сочетаниями заглавных букв и цифр. Те DESADV и ORDERS, которые видят у себя сети и их клиенты и где бизнес-сущности описаны английским языком - это, строго говоря, не совсем стандарт EDI. Провайдер внутри себя все равно все это конвертирует во внутренний формат и потом назад для клиента.

Посмотреть, как выглядит "хардкорный" EDI, можно, загрузив себе документ PRICAT - ценовую спецификацию для сети Х5. Его, кажется, не "причесывали".

(18) PRICAT, слава богу, не моя зона ответственности :))

(17) Может, по составу полей они и формализованы, но значения, обязательность заполнения, допустимые значения и всё такое прочее у всех разные на практике работы с 5 провайдерами...

(20) "Кишки", т.е. настоящий EDI, выглядит вот так https://imgur.com/P8F5oy4
Изначально, когда оно только появилось, это, кстати, был даже текст, а не XML.

(21) Это то, что провайдер видит. На выходе вроде там более культурно всё.

А так, вообще прикинул оценку разработки "с нуля", с учетом имеющегося устаревшего решения по интеграции, часов 300 выходит, чтобы конфетка вышла, по готовой архитектуре. А вот оценка разработки архитектуры непонятна :(