diadocsdk-1c-docs
diadocsdk-1c-docs copied to clipboard
diadoc
ОШИБКА?! Странное поведение при отправке формализованных Торг-2 в роуминг. Похоже, что иногда вы отправляете документы не тому контрагенту, что указан в документе
Добрый день.
Общая информация для упрощения «разбора полётов»: Организация: «ДНС Ритейл» ИНН: 2540167061 КПП: 254301001 ID организации: [email protected] ID участника ЭДО: 2BM-2540167061-254001001-201312151140099321090
Мы работаем с Диадок с использованием компонент АПИ для 1С https://diadocsdk-1c.readthedocs.io/ru/latest/index.html Текущая используемая версия: COM x64 5.54.0.1016
Совершенно случайно заметили странную ошибку при отправке документа в роуминг.
Пример документа: /c4390c58-315b-4323-a9b4-b5d87d6e868b/Document/Show?letterId=70dc4a8e-51c7-4ad5-9d0b-7afa8581a850&documentId=e06726fa-edd1-4329-855e-9c4260d4b795
При формировании документа на отправку мы указываем контрагента в роуминге:
Обращаем внимание на FnsParticipantId = [2AE3FCB9AC3-CE35-4125-BDE9-68C58026E2CA].
Данные контрагента из ЭДО:
Далее заполняем все для отправки документа и отправляем.
Происходит отправка и в итоге мы получаем следующее:
1
В данных отправленного документа указан Id другого получателя:
RecipientFnsParticipantId = [2BM-7730126288-773301001-201408210506505801645]
Это данные вот этого контрагента:
2
Отправка документа в роуминг проходит успешно:
3
А вот при приеме документа получатель фиксирует ошибку:
Текст ошибки полностью:
ваш документ DP_PRIRASXPRIN_2BM-7730126288-773301001-201408210506505801645_2BM-2540167061-254001001-201312151140099321090_20250402_649db76c-47f7-440a-9048-12498aa0e14c.xml содержит ошибки. Не совпадают идентификаторы получателя в описании сообщения 2AE3FCB9AC3-CE35-4125-BDE9-68C58026E2CA и имени файла 2BM-7730126288-773301001-201408210506505801645. Обратитесь к разработчику вашего ПО для исправления (3.00.24.002)
Т.е. указывается как раз то, что мы уже выше нашли и на картинках показали - при отправке указан один контрагент, а в данные формируемого вами (не нами!) XML-файла документа попадает другой.
Мы указываем отправку контрагенту в роуминге. А вы в документе указываете данные того же самого контрагента (с теми же ИНН и КПП), но заведенного в Диадоке. А не в роуминге.
Дополнительно
Провели небольшой анализ проблемы и выявили у себя 233 документа с подобной ошибкой.
При этом все они:
- Формализованные Торг-2
- Отправлялись контрагенту в роминг оператору "Калуга Астрал"
Еще один документ для примера: /c4390c58-315b-4323-a9b4-b5d87d6e868b/Document/Show?letterId=d5bbfd8d-92f6-4aa0-84aa-392a8dafdfea&documentId=ceb4ecbc-afb9-4850-a00c-fb34bc1fda97
Итого
Это очень похоже на какую-то внутреннюю ошибку у вас при формировании XML-файла, при которой данные по контрагенту указываются/находятся не по его явно указанному FnsParticipantId, а каким-то поиском по ИНН и КПП с приоритетностью выбора контрагента, напрямую работающего с Контур.Диадок, а не в роуминге.
Хотя при отправке мы указываем именно роуминговую версию контрагента. Что отмечаем и в FnsParticipantId контрагента, и в его Guid.
Плюс есть ощущение, что документов с подобным странным (ошибочным?!) заполнением может быть и больше. Просто при приеме документов оператор "Калуга Астрал" проверяет эти данные и фиксирует ошибку в роуминге. Но не факт, что такой же контроль есть у других операторов ЭДО. И что они видят эту проблему в заполнении XML-файла и фиксируют ошибку.
Очень хотелось бы услышать от вас ошибка это или нет. Если ошибка - узнать когда она будет исправлена. Если нет - то получить указание, как отправлять такие документы. С учетом того, что XML формируете вы, а не мы.
Спасибо.
Добрый день
А какие данные заполняются в поле RecipientFnsParticipantId документа перед отправкой?
Добрый день.
Наверное, я ранее несколько неясно выразился.
Попробую уточнить:
НАМИ эти данные НИКАК не заполняются. ВООБЩЕ!
Мы только указываем данные контрагента (ID), которому отправляем документ в Counteragent.
Данные в полях:
- RecipientFnsParticipantId
- SenderFnsParticipantId
формируете ВЫ САМИ! КОНТУР.
Для нас это выглядит как автоматическое заполнение этих полей Контуром по указанной организации (ID), из которой мы отправляем документ и указанному контрагенту (ID), которому мы отправляем документ.
Т.е. это заполнение срабатывает где-то у вас "внутри".
Я поэтому и писал, о том, что это, похоже, какая-то внутренняя ошибка у вас при формировании XML - просто потому, что это именно так и выглядит. Мы передаем вам данные (ID) организации и контрагента, вы формируете XML и при вставке данных в некоторых случаях очень похоже, что контрагента, из которого нужно взять информацию для заполнения XML, ищите не по его указанному ID, а, такое ощущение, что по его ИНН и КПП. И найдя нескольких - например, роумингового и не роумингового - подставляете в XML данные неверно выбранного контрагента.
Не факт, что у вас "внутри" происходит именно так. Но выглядит - так!
Надеюсь, так понятнее.
Добрый день.
Я тут вдруг понял, что, возможно, я очень неправильно заголовок темы сделал.
Скорее всего получается, что отправка-то идет именно тому контрагенту, что указан в получателе. Но вот в XML указываются ИД ФНС другого контрагента.
Но это, надо уже вам посмотреть - кому в итоге из двоих указанных вы отправляете такие документы.
Добрый день, @JohnSergeev
Верно ли, что
-
данные из скрина
указываете в PackageSendTask2.CounteragentId
-
в контенте титула заполняете
- Content.Torg2SenderTitle.CircumstancesAcceptanceInfo.Seller
- Content.Torg2SenderTitle.CircumstancesAcceptanceInfo.Buyer А поля
- Content.Torg2SenderTitle.RecipientFnsParticipantId
- Content.Torg2SenderTitle.SenderFnsParticipantId оставляете пустыми ?
Добрый день.
Хотя и так вроде знали, как всё работает, но на всякий случай еще раз проверили-пересмотрели.
Всё верно.
НЕТ, мы НЕ заполняем: Content.Torg2SenderTitle.RecipientFnsParticipantId Content.Torg2SenderTitle.SenderFnsParticipantId
ДА, мы заполняем: Content.Torg2SenderTitle.CircumstancesAcceptanceInfo.Seller Content.Torg2SenderTitle.CircumstancesAcceptanceInfo.Buyer
НО! В них вот эти поля: Content.Torg2SenderTitle.CircumstancesAcceptanceInfo.Seller.OrganizationDetails.FnsParticipantId Content.Torg2SenderTitle.CircumstancesAcceptanceInfo.Buyer.OrganizationDetails.FnsParticipantId
Мы тоже ничего НЕ заполняем!
То есть мы, при формировании и заполнении титула отправителя
вообще нигде и никак не заполняем поля вида FnsParticipantId!
Ни в этих формализованных Торг-2, ни вообще нигде.
Эти поля заполняете вы.
Судя по всему из ваших справочников контрагентов ЭДО.
Просто такое ощущение, что контрагентов в своем справочнике вы не по GUID ищите (что, по идее, предполагается), а иногда почему-то по ИНН и КПП. И поэтому для некоторых ситуаций вместо роумингового контрагента с ИНН1 и КПП1 находите контрагента Контура с такими же ИНН1 и КПП1. Но с другим GUID. Это, конечно, гипотеза. Но она хотя бы как-то объясняет, как можно вообще выбрать неверного контрагента при том, что у вас есть их GUID.
Насколько знаю, Диадок для всех документов (Торг-2, УПД, ....) применяет примерно следующую логику на примере покупателя:
- Данные из Buyer (Торг-2) или Buyers (УПД) используются для заполнения соответствующих тэгов в XML
- Если в контракте есть отдельные поля для указания идентификатора получателя
RecipientFnsParticipantId, то использует его для формирования тэга с именем файла - Если Такого поля нет или оно не заполнено, то пытается по данным из
BuyerилиBuyers[0]найти ящики в Диадок - Если нашёлся только один ящик в Диадок, то исполльзуется он
- Если нашёлся один роуминговый ящик, то используется он
- Если нашлось несколько подходящих ящиков или не нашлось ни одного - будет ошибка
Итого. Для решения проблемы нужно в явном виде заполнять Content.Torg2SenderTitle.RecipientFnsParticipantId
Эээ.... это как-то несколько странно, если честно!
Т.к. по идее ваш пункт №3 с точки зрения здравого смысла предполагает, что ящик будет искаться по его ID или GUID. Которые в документе нас как раз задаются!
Но каким образом тогда в этом пункте находятся данные совершенно другого ящика - с другими ID и GUID?!
Поэтому я и писал, что такое ощущение, что этот поиск у вас зачем-то (?!!) ведется по ИНН и КПП.
Что совершенно непонятно, т.к. вы же сами прекрасно знаете, что у вас разных ящиков с одинаковыми ИНН и КПП - огромная куча! Т.к. каждый контрагент может быть представлен несколькими ящиками для каждого из операторов своего роуминга. Первый - для Диадок, Второй - для Тензора, Третий - для еще кого-нибудь.
И у всех этих ящиков РАЗНЫЕ ID и GUID. И одинаковые ИНН и КПП!
Если бы поиск происходил по GUID, то проблемы бы не было. А она каким-то образом есть.
Кажется, что у вас явно что-то странное происходит на вашем шаге №3!
В титуле мы GUID'ы отправителя и получателя указываем!
И выполняя поиск ящика по имеющимся в документе ID и GUIDу контрагента просто невозможно получить данные какого-то ДРУГОГО контрагента - с другими ID и GUID. Но с такими же ИНН и КПП!
Если вы все-таки найдете проблему и поправите ее, то нам и другим пользователям АПИ не придется заполнять то, что Контур так удобно (тут без шуток!) заполняет сам.
Дополнительно
По идее с учетом того, что данные могут быть заполнены пользователями АПИ по-разному, должен быть какой-то приоритет поиска - по чему искать.
Например:
- Если задан FnsParticipantId - ищем по нему, т.к. это однозначный ключ.
- Если FnsParticipantId не задан - идем дальше.
- Если задан GUID контрагента - ищем по нему, т.к. это однозначный ключ, пусть и только в рамках Диадока.
- Если и GUID не задан - только тогда переходим к поиску по ИНН и КПП. Ну и тут уже может найтись целый список. И из него уже выбираем по какой-то логике того, кого считать более приоритетным. Например, контрагента в Контуре, если он попал в список.
А сейчас, кажется, что текущий поиск будто бы пропускает в своей работе шаг №3. И, если FnsParticipantId не задан, сразу переходит к поиску по ИНН и КПП, минуя GUID.
Диадок ответил следущее:
Из UserDataXSD
<xs:attribute name="SenderFnsParticipantId" use="optional">
<xs:annotation>
<xs:documentation>ИдОтпр - идентификатор участника ЭДО (отправителя файла обмена информации покупателя)</xs:documentation>
<xs:documentation>Если не указан, то в атрибут ИдОтпр подставится идентификатор организации указанной в элементе Buyer</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="4" />
<xs:maxLength value="46" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="RecipientFnsParticipantId" use="optional">
<xs:annotation>
<xs:documentation>ИдПол - идентификатор участника ЭДО (получателя файла обмена информации покупателя)</xs:documentation>
<xs:documentation>Если не указан, то в атрибут ИдПол подставится идентификатор организации указанной в элементе Seller</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="4" />
<xs:maxLength value="46" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
то есть ИдПол берётся из Seller'а, если отсутствует RecipientFnsParticipantId. Притом, если Seller.OrganizationDetails.FnsParticipantId не заполнен, то поиск ящика будет произведён по ИНН-КПП. Если по ИНН-КПП ящик определить не удалось, то по ИНН.
Притом поиск идёт по всем ящикам Диадок и приоритет отдаётся Диадочным.
Итого, при отправке документов в роуминговые ящике нужно явно указывать идентификаторы получателя в контенте.
Если логика остаётся непонятной, предлагаю прислать XML, получаемую методом CustomDocumentToSend.SaveUserData(FilePath), чтобы разобрать на примере