Имя: Пароль:
1C
1С v8
Архитектура ЭДО (EDI) в типовых семейства ERP
0 Комрад1
 
17.04.20
08:20
Кто-нибудь имеет опыт использования EDI на больших объемах документов в типовых? Стоит вопрос, разрабатывать свою подсистему, начиная с архитектуры, с нуля, или можно за основу взять типовые? Объем входящих/исходящих документов примерно 20тыс. в день.
1 zak555
 
17.04.20
08:21
1с в марте говорила, что скоро будет edi
2 Комрад1
 
17.04.20
08:23
(1) Да я вот то-же посмотрел подсистему обмена ЭДО с контрагентами, судя по количеству метаданных с префиксом Удалить писатели типовых ещё в творческом поиске :(
3 zak555
 
17.04.20
08:26
1с-эдо сейчас сделано для ЮЗД

Для остальных идёт разработка
Есть уже заказы, коммерческие предложения и т.д., которые идут через бизнес сеть
4 ДенисЧ
 
17.04.20
08:31
(3) ЮЗД - это грубое ругательство?
5 Комрад1
 
17.04.20
08:35
(3) Так архитектура от того, ЮЗД или не ЮЗД, по идее особо не должна меняться. Какая разница, какие сообщения обрабатывать, УПД или Desadv, подписание ЭЦП это уже сбоку.
6 zak555
 
17.04.20
09:04
(4) юридически значимый документооборот
7 Комрад1
 
17.04.20
09:11
По архитектуре мне пока ясно, что должно быть несколько независимых задач - получение сообщений от провйдеров, запись сообщений в БД в "сыром" виде, проверка корректности сообщений, обработка корректных сообщений, операции в ИС на основании сообщений, обработка ошибок.
8 Lokli
 
17.04.20
09:34
Работал с EDI и на самописной обработке и на типовой от провайдера. Для понимания объёмов: количество ORDERS порядка 20 тыс. в день.
Обработка от провайдера удобнее, в том смысле что в ней уже прописан функционал по приёмке, разбору, формированию и отправке edi-документов и ЭДО (зависит от провайдера).
Но при таких объемах она все равно нуждается в доработке.
Если нужны подробности или какие-то консультации, то пиши в почту.
9 NorthWind
 
17.04.20
09:36
(5) это по идее. На практике отличий много, хотя бы в том что в ЮЗДО помимо самого дока существует ворох квитанций, каждая из которых тащит свою ЭЦП. В EDI ничего этого нет, в силу чего это в десятки раз легче по трафику и по документообороту.
10 NorthWind
 
17.04.20
09:49
а вообще занятно, что EDI сети заставляли людей внедрять примерно с 10 года, на 12-13 пришелся пик + добавились ON_SFAKT, а 1С распапашилась только сейчас :)
11 NorthWind
 
17.04.20
09:50
как говорится, не прошло и десяти лет
12 Комрад1
 
17.04.20
10:21
(8) Это хорошо, только вот провайдеров 5 штук действующих, поэтому нужен универсальный механизм. И типовые механизмы не обеспечивают быстродействия и надежности.
13 Комрад1
 
17.04.20
10:23
(10) Так это потому, что 1С и крупный бизнес повернулись лицом друг к другу относительно недавно. А крупный бизнес уже своих велосипедов настроил по EDI.
14 Комрад1
 
17.04.20
10:25
(9) Эти квитанции можно (и, я бы даже сказал, нужно) вполне себе сбоку прикрепить. Разбирался тут с обменом ЕГАИС с нуля, где какраз куча квитанций, всё это разбирается в одном потоке - это адъ какой-то.
15 Новиков
 
17.04.20
10:50
(12) универсальный механизм уже разработан для формализованных документов. Между всеми провайдерами они передаются согласно формата, утвержденному ФНС. Т.е. здесь разрабатывать ничего не нужно, все и так разработано. Если же говорить формализованные не по стандарту, но обмен которыми предполагает обмен именно "формализованным" (стандартизированным) XML, а не бинари, и чтобы такой обмен был с виду - аналогичный формализованному, то здесь формализации никакой нет, т.к. пока нет настолько крупного заказчика, который бы смог "стандартизировать" свой формат, для всех провайдеров. Как правило, у крупных сетей в обязательном порядке при работе с ними через ЭДО, указан провайдер, у которого такая интеграция уже есть, и дешевле подключить себе +1 провайдер, нежели писать такой обмен.

По поводу типового ЭДО от 1С - с ним не работал. Работал с модулем диадок. Для типовых кейсов, когда к формализованному ФНС документу, мы хотим в пакет добавить какую-то свою "формализованную" информацию - все есть из коробки. Если же нужен полностью свой формализованный обмен - это сильно трудоемко, дешевле ее в самом диадоке заказать и стать к ним на поддержку, т.к. сам внутренний формат обмена они могут изменить и у тебя все посыпется в этом случае.
16 Комрад1
 
17.04.20
11:04
(15) По ЮЗД да, согласен. Но DESADV, ORDERS и т.п. тоже вроде как формализованы, но только в теории. То есть, если у нас 5 провайдеров, у всех они будут хоть немного, да разными. При этом провайдеры тоже только на словах "обеспечивают единый формат от любого контрагента". Что влечет за собой как минимум необходимость разработать свою схему этих документов, и сначала все входящие приводить к этой схеме, и только потом грузить.
17 NorthWind
 
17.04.20
11:15
(16) в реальности они формализованы. EDI представляет собой довольно специфический формат, где теги являются невнятными сочетаниями заглавных букв и цифр. Те DESADV и ORDERS, которые видят у себя сети и их клиенты и где бизнес-сущности описаны английским языком - это, строго говоря, не совсем стандарт EDI. Провайдер внутри себя все равно все это конвертирует во внутренний формат и потом назад для клиента.
18 NorthWind
 
17.04.20
11:17
Посмотреть, как выглядит "хардкорный" EDI, можно, загрузив себе документ PRICAT - ценовую спецификацию для сети Х5. Его, кажется, не "причесывали".
19 Комрад1
 
17.04.20
11:22
(18) PRICAT, слава богу, не моя зона ответственности :))
20 Комрад1
 
17.04.20
11:24
(17) Может, по составу полей они и формализованы, но значения, обязательность заполнения, допустимые значения и всё такое прочее у всех разные на практике работы с 5 провайдерами...
21 NorthWind
 
17.04.20
11:25
(20) "Кишки", т.е. настоящий EDI, выглядит вот так https://imgur.com/P8F5oy4
Изначально, когда оно только появилось, это, кстати, был даже текст, а не XML.
22 Комрад1
 
17.04.20
13:30
(21) Это то, что провайдер видит. На выходе вроде там более культурно всё.
23 Комрад1
 
17.04.20
13:32
А так, вообще прикинул оценку разработки "с нуля", с учетом имеющегося устаревшего решения по интеграции, часов 300 выходит, чтобы конфетка вышла, по готовой архитектуре. А вот оценка разработки архитектуры непонятна :(
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn