diadocsdk-csharp
diadocsdk-csharp copied to clipboard
diadoc
Формирование ИДПол при отправке в роуминг
Версия sdk 1.83.0.0 У нас есть контрагент в роуминге Synerdocs 2IGd6d8839d-78df-47ff-89ca-20c9378be073 (81d022b5-49f2-45ce-99e7-6e6a49e4fb2e). При этом в списке наших контрагентов у нас только этот контрагент.
При этом есть контрагент в роуминге Тензор 2BE515a2f9a81a711e29ac5005056917125 (cac2cb09-e90b-48c6-8973-7d5aac23ea21).
Отправляем УПД СЧФДОП в 820 приказе. В случае с Synerdocs ИДПол, ИДФайл формируется Диадока (2BM-7705716967-2012052808214990062630000000000). В случае с Тензор все формируется корректно
OrgName - заполняем Inn - заполняем Kpp - заполняем Address - заполняем FnsParticipantId - не заполняем OrgType - заполняем https://github.com/diadoc/diadocsdk-csharp/issues/392 рекомендуют добавить заполнение FnsParticipantId.
Есть ли настройка на роуминге, которая обязует заполнять FnsParticipantId?
В #392 правильно рекомендуют заполнять FnsParticipantId. Как указано в документации https://api-docs.diadoc.ru/ru/latest/proto/utd/ExtendedOrganizationInfo.html В зависимости от контекста использования структуры ExtendedOrganizationInfo требования к обязательности заполнения ее полей могут меняться.
Но зачем нам заполнять FnsParticipantId если по инн\кпп мы однозначно можем найти ящик? почему при формировании одного и того же типа документа для разных контрагентов отличаются правила?
В случае, если не указаны какие-либо данные о контрагенте при генерации документа, мы пытаемся найти данные самостоятельно. Так как с данными инн-кпп есть три ящика в Диадока, есть вероятность, что итоговый результат будет отличатся от ожидаемого.
Для однозначного поведения рекомендуем заполнять ФНС идентификатор самостоятельно.
Мы заполняем все реквизиты получателя(см.вложение), но при этом идпол и идфайла некорректно заполняется
@Kat1on вам надо определиться со способом заполнения данных либо указывайте все данные в структуре
ExtendedOrganizationDetails вместе с идентификатором, либо выбирайте ExtendedOrganizationReference и указывайте boxid. У контрагентов может быть разное количество роуминговых ящиков, поэтому по инн-кпп нельзя точно определить какой роуминговый ящик нужен, выбирается какой-то.
Мы заполняем ExtendedOrganizationDetails, без идентификатора ФНС.
Но по инн-кпп есть только один роуминговый клиент, почему идпол некорректно формируется?
При этом методом GetBox получаем корректный ящик.
При генерации используется логика, отличная от логики в методе GetBox, но учитывающая все возможные ящики в Диадоке. Изменение этой логики не планируется. Поэтому вам рекомендуем либо указывать все данные в структуре ExtendedOrganizationDetails вместе с идентификатором, либо использовать ExtendedOrganizationReference и указывать boxid
Но вопрос остается актуальным...
Почему при прочих равных для одного клиента работает без идентификатора, а для другого клиента надо указать?
Причем методы генерации обоих документов для клиентов одинаковые.
Заметили еще, что при формировании документа не заполняется кпп в идпол и идфайл, но мы его отправляем. С чем это может быть связанно?
Если для организации в Диадоке создан один ящик, то проблемы выбора не возникает. Для инн 4003014954 ящик как раз один
инн 4003014954 это отправитель, с ним проблем нет.
Клиент МГК 2 ящика в диадоке, проблем с отправкой (отправляем на роуминг) нет.
Клиент Дистрибьшен 3 ящика (при этом наш контрагент только один роуминговый). Ранее скриншот отправляла.
Т.е. проблема явно не с заполнением всех данных ExtendedOrganizationDetails ( FnsParticipantId)
Заметили еще, что при формировании документа не заполняется кпп в идпол и идфайл, но мы его отправляем. С чем это может быть связанно?
ИдПол - идентификатор участника ЭДО, который формируется не при каждой отправке документа, а один раз при регистрации организации. Вероятно, изначально для организации не был указан КПП, поэтому идентификатор сформировался без него.
По формированию ИдПол в случае нескольких ящиков. Проверили на своей стороне для МГК - при генерации, если использовать структуру ExtendedOrganizationDetails и явно не указать FnsParticipantId, то в ИдПол подставится идентификатор диадочного ящика, а не роумингового. Чтобы все работало корректно для всех контрагентов, вам нужно либо использовать ExtendedOrganizationDetails и всегда указывать для роуминговых ящиков FnsParticipantId, либо использовать структуру ExtendedOrganizationReference с указанием boxid
А возможно ли такая ситуация: в документе для МГК указан ИдПол диадочного ящика, но в контрагентах у нас только роуминговый ящик и отправка идет на роуминг вне зависимости от ИдПол?
Нет, такого быть не должно. Если диадочный КА не заблокирован вами и не заблокировал вас (статус КА не IsRejectedByMe и не RejectsMe ) и КА принимает документы от всех ящиков (Sociability = AllOrganizations), то документ будет отправлен в диадочный ящик.
Обнаружили следующую ситуацию отправляем клиенту в роуминг, видим, что документ принят в роуминге, но при этом ИДпол диадочный.
При отправке в Synerdocs ситуация такая же, но документ у клиента в ошибке: Неправильный порядок следования идентификаторов отправителя и получателя в идентификаторе файла (атрибут ИдФайл). Сначала должен быть указан идентификатор получателя, затем идентификатор отправителя.;InvalidFormatField;Document.Content;. Изначально в техподдержке сказали, что скорее всего это потому что ИДпол сформировался диадочный. Но судя по всему это все таки какая -то надстройка на роуминге. Отличие клиента в Synerdocs в том, что КПП роумингового участника, отличается от КПП диадочного участника.