Формирование ЭД (ТОРГ-12, СФ) на стороне клиента about diadocsdk-csharp

[atytsky]

Привет, на первый взгляд вариантов может быть несколько.

Например, можно использовать наши методы генерации документов, тогда проблема подстановки тэга СвОЭДОтпрСФ снимется автоматически:

• для СФ
• для ТОРГ-12, титул покупателя
• для ТОРГ-12, титул продавца.

Либо можно сохранять идентификаторы участника ЭДО и все необходимые данные для всех 3-х организаций в своей информационной системе, и синхронизировать их с Диадоком с какой-то периодичностью. Вероятность смены ИНН и идентификатора участника ЭДО крайне мала.

Если СКБ Контур есть в контрагентах, то может подойти еще вариант с использованием метода GetOrganizationsByInnList

Но в любом случае, кажется эту задачу можно решить и без отдельного метода.

[SLenik]

Но в любом случае, кажется эту задачу можно решить и без отдельного метода.

Собственно, мы задачу кое-как и решили. Вопрос можно ли сделать её более эффективно: избавившись в коде от Вашего ИНН и/или уменьшив количество вызовов.

[SLenik]

Если СКБ Контур есть в контрагентах, то может подойти еще вариант с использованием метода GetOrganizationsByInnList

Это уменьшит количество вызовов на 1, однако всё ещё потребует захардкоденного ИНН СКБ Контур в коде.

Либо можно сохранять идентификаторы участника ЭДО и все необходимые данные для всех 3-х организаций в своей информационной системе, и синхронизировать их с Диадоком с какой-то периодичностью.

Это было изначальное решение, однако, например, Ваши коллеги из Тензор почему-то такое не рекомендуют (пруфлинк, страница 45):

Идентификатор участника документооборота может меняться в произвольное время, не рекомендуется сохранять и использовать кроме случая генерации первичного документа непосредственно перед отправкой.

Если же мы сделаем такое кэширование, с какой периодичностью Вы бы рекомендовали обновление данных?

Можно использовать наши методы генерации документов

Про методы генерации в курсе, но сейчас напрямую использовать не можем (а где используем - выпиливаем). Помимо того, что нам нужен контроль за используемым форматом (вы же до сих пор, например, не поддерживаете ТОРГ-12 2016 года), наша система использует интеграцию с несколькими провайдерами (генерация на нашей стороне обеспечивает большее удобство при подключении нового провайдера).

Конечно, существует вариант, что перед отправкой мы будем генерировать через Ваше API какой-то "левый" документ, затем парсить его и вытаскивать требуемые данные - но кажется это ещё больший костыль...

[atytsky]

Например, в приказе ММВ-7-6/93@ написано следующее:

Значение элемента представляется в виде ИдОЭДОКодПрод(Пок), где:
ИдОЭДО - идентификатор оператора электронного оборота счетами-фактурами (оператор ЭДО), услугами которого пользуется покупатель (продавец), символьный трехзначный код. При включении оператора ЭДО в сеть доверенных операторов ЭДО ФНС России, идентификатор присваивается Федеральной налоговой службой;

КодПрод(Пок) - код продавца (покупателя) - уникальный код участника, присваиваемый оператором электронного документооборота, услугами которого пользуется покупатель (продавец), длина кода продавца (покупателя) не более 43 символов

ИдОЭДО выдает ФНС и врядли поменяется у уже существующего оператора.

КодПрод(Пок) задается самим оператором, видимо у коллег из Тензора есть какие-то свои нюансы. У нас же в системе идентификатор участника документооборота задается один раз при создании организации и в дальнейшем не меняется.

Мне кажется смело можно делать кэширование и обновлять данные например раз в сутки.

[SLenik]

Хорошо. Большое спасибо за помощь!