Nav и ЭДО

[Smart]

Всем добрый день,
а кто-либо реализовывал интеграцию с операторами ЭДО (обмен электронными СФ, ТОРГ-12 и др. с контрагентами)? Если есть такие то какого оператора выбрали, какие подводные камни, может есть какие-то готовые решения?

[Captain]

Приветствую!
- На текущий момент в России 15 операторов ЭДО, и как итог - универсального решения нет.
- У отдельных партнеров, есть решения по Диадоку, СБИС и.т.п.
- С 01.07.2017 года вступает новый стандарт обмена на базе Универсального Передаточного документа и поэтому наработки в старом формате будут неактуальны.
Для информации в xsd схеме старого (текущего) стандарта 300 узлов, в новой за 700.

Если есть вопросы, то в личку.
С уважением

[Smart]

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

[jopagames]

Цитата:

Сообщение от Smart

Примерно так я и представлял себе ситуацию.

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

Достаточно просто там всё устроено, есть SDK в свободном доступе, дают тестовые ключи для разработки.
Единственное что, пришлось дописывать свой враппер к их стандартной DLL-ке, чтобы Нав мог нормально отлавливать ошибки выполнения.
(но, вообще исходник самой DLL-ки тоже в SDK есть, если что)

[grnik]

У нас клиенты требовали ЭДО,а некоторые EDI. Сделали через Контур.Ритейл. Они сделали портал в Контур.Диадок. Таким образом одной загрузкой убили двух зайцев
Если интересует могу рассказать подробней.

[Smart]

Цитата:

Сообщение от jopagames

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

Достаточно просто там всё устроено, есть SDK в свободном доступе, дают тестовые ключи для разработки.
Единственное что, пришлось дописывать свой враппер к их стандартной DLL-ке, чтобы Нав мог нормально отлавливать ошибки выполнения.
(но, вообще исходник самой DLL-ки тоже в SDK есть, если что)

Пошли этим путем, сначала пробовал API Такскома - сырой, не подходит, половина методов возвращает xml в виде строки(более 1024) и Нав Classic не переваривает такое, либо я не умею его готовить . Сейчас занимаюсь Диадок, правда тоже не все гладко, но процесс идет. Jopagames, вы УПД формировали? Если да, то как заполняли данные по ТД, стране?

[Captain]

Dear Smart,
Ваш подход к решению в ФОРМАТЕ text(1024) очень "коварен".
Посмотрите в сторону XMLPorts. Примеров в сети достаточно Даже на 3.70..
С уважением.

[Smart]

Цитата:

Сообщение от Captain

Dear Smart,
Ваш подход к решению в ФОРМАТЕ text(1024) очень "коварен".
Посмотрите в сторону XMLPorts. Примеров в сети достаточно Даже на 3.70..
С уважением.

XMLPorts в 3.7 - были? Поясните, пожалуйста, в чем коварность? Ест у API метод, к примеру GetContactListUpdates, возвращает строку. Никак не могу обработать/сконвертировать этот ответ, при любом вызове метода и длине ответа >1024 валится ошибка. К примеру тут Сохранить XML такая же проблема и люди пишут дополнительные обертки. Может быть есть какое то решение, но я его не вижу.

[Captain]

Сегодня - передали клиенту выгрузку УпеРдока в файловом формате. Клиент все отправил на валидацию в паралленую систему(1С).

Пока нет одной функции (во всех системах ДО) - "Доброе утро - файлики", то мы Ждем ответа.

P.S - 2013..2017

[Captain]

На ваш вопрос отвечаю,

1. Сформировать правильно оформленный хмл документ, с проверкой инструментами с nalog.ru
2.Передать готовый файл для загрузки и тестирования через стандартный интерфейс(хоть черту с интеграцией ...)
3.Выбрать(выбрали) платформу для интеграции,Это уже вторично

Для наводки,
Диадок АПИ, полезен для вызова части функций по идениефикации почтового ящика получателя. Но разве у всех Диадок?

Удачи.