Код boxid что это

Получение подписантов в ЭДО через API СБИС и Диадок

Всем привет. Эта статья будет полезна тем, кто столкнулся с проблемой проверок доверенностей при работе с электронным документооборотом через СБИС и Диадок. Речь идет не о МЧД (машиночитаемой доверенности), а о проверке обычных бумажных доверок.

Так же возможно кому то просто будет полезно почерпнуть принципы работы через API.

Ко мне эта задача прилетела от юристов, нашей компании, которые постоянно проверяли документы вручную. (смотрели вручную кем подписан документ и потом искали эту доверенность в сканах.

1. Первое что нам понадобится это реестр подписантов контрагентов. Формируется в полу автоматическом режиме, автоматом подгружается: ФИО, должность, название компании, ИНН. Далее вручную заполняются поля: дата истечения доверенности, номер доверенности, ФИО и почта ответственного за контрагента, а также ФИО и почта руководителя ответственного.

2. Реестр прочитанных документов, по которым еще не завершился документооборот. Это необходимо что бы не запускать каждый раз программу на большие сроки сканирования документов. (По умолчанию я запускаю скрипт, читающий вчерашнюю дату) если нужен другой период — это возможно указать при вызове скрипта. Реестр незавершенных документов хранит только два значения. Идентификатор документа и его состояние.

Для решения поставленной задачи использовал API сервисов СБИС и Диадок.

Весь код написан на PowerShell.

Отдельно разобью описание для каждого их сервисов.

1. Самое первое что необходимо сделать это пройти авторизацию на сервисе.

API сбиса принимает все запросы в формате JSON что бы не конвертировать массив в JSON я сразу пишу переменные в формате JSON.

2. Загружаем в переменную реестр доверенностей

3. Проверяем реестр ранее незавершенных документов, если у них изменилось состояние на “завершено” то проваливаемся вглубь документа, в противном случае просто заново записываем эти данные в реестр незавершенных сообщений (реестр перезаписывается каждый запуск программы, что бы не удалять построчно из экселя).

Внутри пакета документов нас интересует документ с названием “Уведомление о приеме”. А что бы получить именно подписанта (того чьей эцп был подписан документ, а не промежуточных лиц) нужно вычленять вложение которые содержит слово титул(таких вложений может быть много, но нам нужно самое первое с индексом 0.

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

Если кратко нужный нам сертификат передается по следующему пути: Документ/событие(уведомление о приеме)/вложение Название:(Передаточный документ (титул покупателя))/Подпись/сертификат/ФИО. Получаем это через метод СБИС.ПрочитатьДокумент

4. После того как прочитали старые документы переходим к чтению новых.

Сперва полаем список документов, а далее обращаемся к каждому документу напрямую.

Сразу хочу отметить что при обращении к списку документов чтение происходит постранично, и на странице влазит не более 200 документов.

По-этому читаем постранично и заносим все в массив документов.

После того как все прочитали заносим подписантов в реестр, проверяем не истекла ли их доверенность и оповещаем об этом ответственных лиц и их руководителей. А так же не завершенные документы заносим в реестр неоконченных.

В данном примере write – host $msg это как раз оповещения и переменную $msg нужно передать в процедуру отправки почты (см ниже)

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

5. Модуль отправки почты

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

Диадок

Логика примерно такая же, только ключ разработчика для обращения к документам диадока стоит денег в год. И авторизация немного другой вид имеет. По-этому выложу просто код целиком без пояснений.

Как отправить и получить товарную накладную ТОРГ-12 в рекомендованном ФНС формате¶

Рассмотрим последовательность действий к функциям интеграторского интерфейса Диадока, которые требуется совершить при отправке товарной накладной ТОРГ-12.

1. Продавец формирует файл титула продавца, подписывает и направляет покупателю.
2. Покупатель получает товарную накладную, подписанную и отправленную продавцом;
3. Покупатель формирует файл титула покупателя, подписывает своей ЭП и отправляет в адрес продавца.

Более подробно о порядке обмена электронными накладными между компаниями можно почитать на сайте

Формирование файла титула продавца для товарной накладной ТОРГ-12¶

Если на стороне интеграционного решения не предусмотрено функциональности для формирования XML-документов, соответствущих утвержденным форматам, то продавец может сгенерировать файл титула, используя команду GenerateTorg12XmlForSeller .

В теле запроса должны содержаться данные для изготовления титула продавца для товарной накладной ТОРГ-12 в XML-формате в виде сериализованной структуры Torg12SellerTitleInfo .

HTTP-запрос для генерации файла титула продавца товарной накладной ТОРГ-12 выглядит следующим образом:

В теле ответа содержится XML-файл титула продавца, построенный на основании данных из запроса.

Успешный ответ сервера выглядит так:

Файл генерируется в соответствии с XML-схемой , которой должны удовлетворять XML-накладные, согласно приказу ФНС.

Имя файла титула продавца для товарной накладной возвращается в стандартном HTTP-заголовке Content-Disposition .

Отправка файла титула продавца для товарной накладной ТОРГ-12¶

После того, как у вас есть XML-файл титула продавца, его нужно отправить с помощью команды PostMessage .

Для этого нужно подготовить структуру MessageToPost следующим образом:

в значение атрибута FromBoxId указываем идентификатор ящика отправителя;

в значение атрибута ToBoxId указываем идентификатор ящика получателя;

для передачи XML-файла титула продавца товарной накладной ТОРГ-12 нужно использовать атрибут XmlTorg12SellerTitles, описываемый структурой XmlDocumentAttachment:

• внутри структуры XmlDocumentAttachment находится вложенная структура SignedContent;
• сам XML-файл нужно передать в атрибут Content, подпись продавца в атрибут Signature.

Описание структур, используемых при отправке товарной накладной ТОРГ-12:

После отправки в теле ответа будет содержаться отправленное сообщение, сериализованное в протобуфер Message .

Все дальнейшие действия происходят на стороне покупателя.

Поиск товарной накладной ТОРГ-12¶

Сначала покупателю необходимо найти все входящие товарные накладные ТОРГ-12, которые требуется обработать. Для этого нужно воспользоваться методом GetDocuments :

• в значении параметра boxId указываем идентификатор ящика, в котором следует выполнить поиск входящих документов;
• в параметр filterCategory указываем статус и тип документа: XmlTorg12.InboundNotFinished .

Пример запроса на получение товарной накладной ТОРГ-12 выглядит следующим образом:

В теле ответа вернется список документов в виде структуры DocumentList с вложенной структурой Document. Для каждого из этих документов запоминаем: MessageId, EntityId.

Получение товарной накладной ТОРГ-12¶

Теперь необходимо получить найденную товарную накладную XmlTorg12 .

Чтобы получить товарную накладную ТОРГ-12 нужно вызвать метод GetMessage и указать нужные GET-параметры boxId , messageId , entityId .

BoxId — это идентификатор ящика получателя, messageId — идентификатор полученного сообщения с накладной ТОРГ-12, entityId — идентификатор товарной накладной. Их можно взять из структуры Message .

Пример структуры товарной накладной ТОРГ-12 XmlTorg12 в теле ответа:

Формирование файла титула покупателя для товарной накладной ТОРГ-12¶

Файл титула покупателя можно сформировать как на стороне интеграционного решения, так и используя команду GenerateTorg12XmlForBuyer . Для этого надо передать следующие параметры:

• boxId — идентификатор ящика получателя;
• sellerTitleMessageId — идентификатор сообщения, содержащего соответствующий титул продавца;
• sellerTitleAttachmentId — идентификатор сущности, представляющей титул продавца, для которого требуется изготовить титул покупателя.

Эти идентификаторы соответствуют идентификаторам из параметров boxId , messageId , entityId для метода GetMessage .

В теле запроса должны содержаться данные для изготовления титула покупателя для товарной накладной ТОРГ-12 в XML-формате в виде сериализованной структуры Torg12BuyerTitleIhfo .

HTTP-запрос для генерации файла титула покупателя товарной накладной ТОРГ-12 выглядит следующим образом:

В теле ответа содержится XML-файл титула покупателя, построенный на основании XML-файла титула продавца и данных из запроса.

Успешный ответ сервера выглядит так:

Файл генерируется в соответствии с XML-схемой , которой должны удовлетворять XML-накладные, согласно приказу ФНС.

Имя файла титула покупателя для товарной накладной возвращается в стандартном HTTP-заголовке Content-Disposition .

Отправка файла титула покупателя для товарной накладной ТОРГ-12¶

После того, как у вас есть XML-файл титула покупателя, его нужно отправить с помощью команды PostMessagePatch .

Для этого нужно подготовить структуру MessagePatchToPost следующим образом:

в значение атрибута BoxId указываем идентификатор ящика, в котором находится исходное сообщение;

в значение атрибута MessageId указываем идентификатор сообщения, к которому относится отправляемый патч;

для передачи XML-файла титула продавца товарной накладной ТОРГ-12 нужно использовать атрибут XmlTorg12BuyerTitles, описываемый структурой ReceiptAttachment:

• ParentEntityId — идентификатор документа, к которому относится титул покупателя; это идентификатор соответствующей сущности из родительского сообщения (поле EntityId в структуре Entity .);

• внутри структуры ReceiptAttachment находится вложенная структура SignedContent;
• сам XML-файл нужно передать в атрибут Content, подпись продавца в атрибут Signature.

Описание структур, используемых при отправке товарной накладной ТОРГ-12:

После отправки в теле ответа будет содержаться отправленное дополнение, сериализованное в протобуфер MessagePatch .

Пример кода на C# для отправки файла титула продавца для товарной накладной ТОРГ-12:

Пример кода на C# для получения файла титула продавца для товарной накладной ТОРГ-12 и отправки файла титула покупателя:

Электронная подпись для e-commerce

Пандемия внесла существенные коррективы в работу всех участников торговой цепочки, включая производителей товаров и дилеров. В этот период практически единственным вариантом работы для них стал онлайн-формат: активно создавались магазины, компании начинали сотрудничать с существующими виртуальными площадками. В электронной торговле происходило быстрое масштабирование маркетплейсов.

Именно маркетплейсы стали особенно популярны среди покупателей и превратились в основной источник заказов для продавцов. В этом нет ничего удивительного, ведь создание и поддержание собственной торговой площадки требует серьезных финансовых вложений. Партнерская модель не менее эффективна и обходится дешевле. Вот почему многие предприниматели сотрудничают с несколькими сайтами, не создавая собственный интернет-магазин или не занимаясь его продвижением.

Однако пандемия и снижение покупательской способности – далеко не единственные причины расцвета маркетплейсов. По мнению экспертов, немаловажную роль здесь сыграла растущая финансовая нагрузка на бизнес. Например, в последнее время заметно и постоянно увеличиваются затраты на аренду площадей, выплату зарплат и налогов. Более того, косвенные платежи иногда превышают основные затраты в несколько раз.

Сфера e-commerce развивалась и ранее, но это развитие было постепенным и плавным. Но фоне пандемии и сопровождающих ее ограничений, карантина, самоизоляции, ситуация сильно изменилась. Пока торговые центры и офлайн-магазины были закрыты, покупателям пришлось делать покупки через интернет. Многие уже давно покупали таким способом бытовую технику или мобильные устройства, ведь именно интернет-магазины предлагают самые выгодные цены на такую продукцию. Теперь пришел черед заказа продуктов, медикаментов, товаров первой необходимости.

Поначалу это было непривычно, и даже в определенной степени страшно, но со временем люди освоились с такими покупками. И после возобновления работы торговых центров выяснилось, что покупателей в них стало значительно меньше, чем до пандемии. Люди оценили все преимущества онлайн-покупок, от экономии времени и шопинга в любое время суток, до расширенного ассортимента и простоты возврата товаров.

Создание аккаунта на площадке

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

Начать рекомендуется с настройки внутренних процессов в компании с учетом новых условий работы. Это касается деятельности склада, бухгалтерии и других подразделений. Только после этого стоит подписывать договор с виртуальной площадкой.

На практике это означает прохождение нескольких этапов:

• Получение квалифицированной электронной подписи (КЭП/ЭЦП);
• Регистрацию декларации соответствия на оказываемые услуги или предлагаемые товары;
• Подключение электронного документооборота (ЭДО);
• Подключение сервиса маркировки;
• Подготовку контента – описаний товаров, которое будет загружено на маркетплейс.

Каждый этап является обязательным, пропускать такие действия нельзя, чтобы работа в формате онлайн была полностью законной и эффективной.

Электронная подпись и электронный документооборот

Электронная цифровая подпись необходима каждому продавцу. Ее предоставляют Удостоверяющие центры, аккредитованные Минкомсвязи. В плане работы с виртуальными площадками КЭП дает возможность:

• Зарегистрировать декларацию соответствия на услуги и товары;
• Подписать договор с маркетплейсом в электронном формате;
• Подтвердить загрузку товара на виртуальную витрину;
• Создать заявку на поставку;
• Работать в рамках сервиса электронного документооборота (ЭДО).

ЭЦП необходима для совершения множества юридически значимых действий от лица организации. Сертификат квалифицированной электронной подписи выдается вместе с лицензией Crypto Pro и защищенным носителем.

Наш сервисный центр предлагает ЭЦП двух типов:

• Обычная электронная подпись предназначена для установки на стационарный компьютер или ноутбук;
• Мобильная электронная подпись устанавливается на смартфон в виде DSS-сертификата.

Во втором случае после установки ЭЦП на смартфон, необходимо скачать приложение для ведения документооборота в электронном формате. После этого на телефон поступит push-уведомление, в котором будут указаны все реквизиты подписываемого документа. Там же будет содержаться предложение подписать его. После этого необходимо проверить документ, и при отсутствии замечаний, подписать его. Для этого достаточно одного клика. Пользователь может просматривать документ, даже если не находится на своем рабочем месте. В этом случае для подписи используется мобильная кнопка.

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

Маркетплейсы передают документы продавцу двумя способами. Первый предусматривает использование системы электронного документооборота, второй – размещение в личном кабинете, который продавец регистрирует на виртуальной площадке.

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

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

• Наименование провайдера ЭДО – АО ПФ СКБ Контур. Среди всех ЭДО провайдеров, включенных в перечень на официальном интернет-портале ФНС, мы занимаем 1-е место. В этом можно убедиться, перейдя по ссылке;
• Код GUID («ID», «идентификатор участника ЭДО») – его можно найти в Личном кабинете. Подробную инструкцию можно найти по ссылке;
• Код boxid – доступен в ящике Диадок. Вверху в адресной строке вверху указаны данные с BoxId, после /diadoc.kontur.ru/ до следующего «/».

Таким образом, пользователь получает все необходимое для полноценного использования системы ЭДО.

Маркировка

Для оперативной обработки УПД и передачи информации в систему маркировки «Честный знак» также используется ЭДО. Электронный документооборот обеспечивает унификацию данных, сокращение вероятности ошибок, ускорение бизнес-процессов. Благодаря возможностям системы, каждый пользователь своевременное получает объективную информацию о рынке маркированных товаров и может сохранять ее.

Система работает по следующему алгоритму:

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

Работать с маркировкой без системы ЭДО нельзя, поскольку «Честный знак» предусматривает только автоматическое получение документации в электронном формате. Товар не будет принят при отсутствии электронного документа с маркировочными кодами. Приемка товаров с маркировкой без электронного УПД чревата штрафами для обоих участников сделки на 50-300 тыс.рублей.

Если оборот с нарушениями порядка маркировки превысит 1,5 млн руб., предпринимателю или юрлицу грозит уголовный срок до 3-х лет и штраф в 80 тыс.руб.

Тарифы Контур Диадок для маркировки

Оставьте контакты, чтобы мы подобрали оптимальный тариф маркировки и удалённо продемонстрировали возможности сервиса Контур.Диадок

Менеджер свяжется с вами в рабочее время: будни 9:00-18:00 (Мск). Ни одно обращение не останется без внимания.

Интеграция с учетной системой

ЭДО для маркетплейсов может интегрироваться со стандартной системой бухучета, что существенно упрощает работу бухгалтерии. Диадок подходит для интеграции с большинством существующих систем и обеспечивает выполнение всех документальных операций в одном окне. Это означает, что Диадок и 1С (или другая программа) становятся единым целым, и необходимость в переносе данных из одной системы в другую отпадает.

Для обработки УПД от виртуальных площадок в окне 1С отображается перечень документов, полученных и отправленных в электронном формате с указанием статуса каждого из них. Если модуля интеграции с 1С нет, при получении УПД нужно заходить в Личный кабинет Диадока, выгружать данные, сохранять их во временную папку, и только после этого загружать в 1С.

Интеграция Диадок и системой 1 С дает возможность:

• Создавать и подписывать счета-фактуры и акты, накладные, другую документацию посредством сервиса Диадок в среде 1С;
• Отправлять перечисленную документацию;
• Получать документы от контрагентов в электронном формате и учитывать их в 1С по мере поступления.

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

Электронный документооборот напрямую связан с получением счетов. Пользователи Диадок могут оплачивать счета прямо из списка входящих документов. Платежное поручение создается автоматически: назначение платежа, сумма и реквизиты счета получателя подставляются из документа, отправленного в формате XML.

ЭДО ДЛЯ ОБСЛУЖИВАЮЩИХ БУХГАЛТЕРИЙ

Ведение бухгалтерского и налогового учета одновременно для нескольких организациях, как правило, осуществляется удалённо бухгалтерской службой. Электронный документооборот дает возможность бухгалтерским службам оперативно собрать первичный пакет документации для своевременной сдачи своим клиентам в кратчайшие сроки.

ПРИ ОПЛАТЕ СЧЕТОВ ВАЖНА СКОРОСТЬ

Электронный документооборот напрямую связан с получением счетов. Пользователи Диадок могут оплачивать счета прямо из списка входящих документов. Платежное поручение создается автоматически: назначение платежа, сумма и реквизиты счета получателя подставляются из документа, отправленного в формате XML.

ПРИ ОПЛАТЕ СЧЕТОВ ВАЖНА СКОРОСТЬ

Электронный документооборот напрямую связан с получением счетов. Пользователи Диадок могут оплачивать счета прямо из списка входящих документов. Платежное поручение создается автоматически: назначение платежа, сумма и реквизиты счета получателя подставляются из документа, отправленного в формате XML.

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Где взять BoxId в GUID формате для УПД по 820 приказу? #576

Где взять BoxId в GUID формате для УПД по 820 приказу? #576

Comments

В теле запроса GenerateTitleXml нужно заполнять BoxID продавца и покупателя. Формат требуется GUID. API Диадока позволяет нам получить идентификатор ящика вызовом GetBox. Но в ответе мы получаем идентификатор вида «97be5d3704394d62bf40442dcb2489b8@diadoc.ru», что совсем не похоже на GUID. Вопрос: где брать идентификатор ящика в GUID формате?

The text was updated successfully, but these errors were encountered:

В части получения идентификатора ящика вы правы. Это я неправильно указал метод, конечно же GetOrganization и далее по списку ящиков получаем их идентификаторы (непонятно только, зачем список, если ящиков всегда один). А вот в части преобразовать самостоятельно можно подискутировать. Да это не сложно, да, я это в итоге так и сделал. Но возникает вопрос о единообразии данных в API Диадока. Почему в одном случае BoxId должен быть такого вида «97be5d3704394d62bf40442dcb2489b8@diadoc.ru», а в другом «97be5d37-0439-4d62-bf40-442dcb2489b8»? Уважаемые разработчики, объясните вашу логику!

@Edward72 boxid возвращается в таком виде в целях обратной совместимости. Мы планируем поднять версию метода и возвращать BoxId как guid. Сроков нет пока.

Ок. Поясните тогда по списку ящиков. Зачем в структуре Organization ящики представлены в виде списка? Бывают ли ситуации когда их больше одного?

Да, бывают. Если запрос не по конкретным orgId или boxId, а по ИНН или ИНН-КПП, то могут вернуться — роуминговый (если есть), тестовый ящик (если есть), все ящики с данным ИНН, но разными КПП (филиальная структура).

Тогда объясните в чем смысл плодить контрагентов в справочнике? Например контрагент с ИНН 7740000076 КПП 997750001. В справочнике он представлен два раза. Первый: ID участника ЭДО: 2KY-7740000076-997750001-1702201 — Роуминг (МТС), второй: ID участника ЭДО:
2BM-7740000076-2012060107272343894520000000000. Почему не как один контрагент с двумя ящиками?

Ок. Поясните тогда по списку ящиков. Зачем в структуре Organization ящики представлены в виде списка? Бывают ли ситуации когда их больше одного?

Это опять для обратной совместимости: когда-то давно у одной организации могло быть несколько ящиков. Сейчас понятия организации и ящика фактически смешались, так как их отношение 1:1 — у организации ровно один ящик.

Когда-нибудь мы приведем все в единообразное состояние — везде будет использоваться нормальный boxId, а у организации не будет массива ящиков 🙂

Да, бывают. Если запрос не по конкретным orgId или boxId, а по ИНН или ИНН-КПП, то могут вернуться — роуминговый (если есть), тестовый ящик (если есть), все ящики с данным ИНН, но разными КПП (филиальная структура).

Это опять для обратной совместимости: когда-то давно у одной организации могло быть несколько ящиков. Сейчас понятия организации и ящика фактически смешались, так как их отношение 1:1 — у организации ровно один ящик.
Два ответа, два противоположных мнения. В одном — «бывают», в другом — «когда-то могло быть, сейчас нет». Походу, сами разработчики уже запутались в своем коде, где уж до порядка в документации.

Тогда объясните в чем смысл плодить контрагентов в справочнике? Например контрагент с ИНН 7740000076 КПП 997750001. В справочнике он представлен два раза. Первый: ID участника ЭДО: 2KY-7740000076-997750001-1702201 — Роуминг (МТС), второй: ID участника ЭДО:
2BM-7740000076-2012060107272343894520000000000. Почему не как один контрагент с двумя ящиками?

никто не ответил. С каким контрагентом мне работать? Если их два, с одинаковым ИНН/КПП?

Никаких противоположных мнений нет. Организация=Ящик=уникальная связка ИНН-КПП-Id участника ЭДО-признак тестовая/роуминговая/реальная

• Может быть несколько ящиков с одинаковыми ИНН-КПП и разными Id участника ЭДО, среди которых один ящик будет диадоковским, все остальные роуминговыми.
• Может быть несколько ящиков с одинаковым ИНН, но разными КПП
• Может быть один ящик реальный, а остальные тестовые

Это всё нормальные ситуации.

Если вы получили в ответе несколько ящиков, то вы сами выбираете, с каким работать:

• если вы знаете, что контрагент работает через роуминг, то выбираете роуминговый ящик
• если контрагент работает через диадок, то выбираете ящик в диадоке
• если надо отправить реальный документ, то при наличии тестового и реального ящика выбираете реальный
• если тестируете интеграцию ли взаимодействие с новым КА, то выбираете тестовый ящик
  И еще может быть много условий, которые известны только вам и вашим контрагентам. Оператор ЭДО за вас не может решить, какой именно ящик надо использовать.

Ок. Описываю ситуацию подробнее. Мы — энергосбытовая компания. Соответственно, у нас огромное количество договоров с юр. лицами. Руководство ставит задачу: перейти на электронный документооборот со всеми контрагентами, которые работают через Диадок. Ок. Пишем программу, в которой в цикле посредством GetOrganization ищем по ИНН/КПП нужных нам контрагентов. Если нашли — отправляем приглашение. Но вот незадача, по одной паре ИНН/КПП находится несколько организаций. Например описанный выше случай. Их две. Одна роуминговая, вторая не роуминговая. Что я должен сделать на уровне алгоритма? Выставить приоритеты по видам ящиков? Где в документации это описано? Какой приоритет у ящиков? Или в каждом случае нужно вызывать помощь в виде диалога пользователю «Выберите ящик.»?

Мы считаем, что ответ на вопрос «Как производить обмен — с роуминговым ящиком или ящиком в Диадоке?» лежит на отправителе. Сервис не может заранее знать, где контрагент готов принимать документы — это надо уточнять непосредственно у него. Обычно сбытовые компании заключают доп.соглашение о переходе на ЭДО где этот момент обговаривается и определяется ящик получателя.
Мы можем только порекомендовать отправлять всегда ящики Диадока, но это не означает, что контрагент будет готов получить там документы. Это связано с тем, что настройка роуминга производится через запрос в техподдержку и занимает некоторое время.

Если вам требуются технические консультации, я могу предложить оплатить платные консультации. Вы будете получать ответ оперативнее с учётом всего вашего контекста от выделенного специалиста. Если это потребуется, обратитесь к вашему менеджеру.

Опять про ящики. Есть контрагент. Подразделение ПАО «Ростелеком» ИНН 7707049388 КПП 860143001. GetOrganization ищем по ИНН/КПП, находим, отправляем приглашение. И что? И ничего. А почему? А потому что, этот ящик они когда-то использовали, но потом все поменялось. У них теперь другой ящик. А старый остался висеть, непонятно зачем. А новый ящик где? А внутри ящика другого контрагента, у которого КПП 66854300. Это Макрорегиональный филиал «Урал». Но господа, в договоре с этим контрагентом КПП 66854300 не прописан! У нас есть КПП головы 770545001 и собственно грузополучателя КПП 860143001. Руками конечно все можно настроить, но мы говорим об интеграции. Итак, есть ИНН/КПП головы и грузополучателя. Ищем GetOrganization по ИНН/КПП грузополучателя, находим, приглашаем и тишина. Что дальше? Ок. Ищем только по ИНН. Находим 66 организаций! Куда дальше? Мне что, нужно лепить в программе костыль, где указывать, что в Диадоке работаем через конкретный КПП? Ок. Допустим. Следующий вопрос. В поддержке мне объяснили, что направляя формализованные документы с КПП грузополучателя в ящик филиала «Урал», документы перенаправятся в ящик нашего потребителя. А что делать с неформализованными документами? Куда их слать? На деревню дедушке? Когда наконец логику работы с Диадоком приведут в нормальный вид?

Структуру филиалов каждая компания формирует самостоятельно, как и принимает решения об удалении ящиков. Мы не можем гарантировать работу Ростелекома, информация о том, куда следует отправлять документы вам необходимо согласовать с контрагентом.

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

Речь идет не о структуре филиалов. А о том, что Диадок не позволяет работать с филиалами, не заморачиваясь с той самой структурой филиалов. Мне то какое должно быть дело до их структуры? Сегодня она одна, завтра другая. Есть ИНН/КПП получателя. Все. Больше ничего не должно быть нужно. И слова «Диадок не может», которые звучат из уст разработчиков того самого Диадока, выглядят как минимум неубедительно. Как максисмум: типа, мы тут сделали кое как, пользуйте как хотите и как можете, мы ничего переделывать не будем.

ToDepartmentId в методе отправки.

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

Что еще можно было услышать? Виноваты не мы, виноваты сами пользователи. А наша система самая офигенская, что-то допиливать, изменять в ней нет необходимости. Платите деньги за использование и пользуйте как есть. А сделать элементарное, поиск по ИНН/КПП в своей базе (базе Диадока) в том числе и подразделений ну никак. Еще расскажите мне про «техническую невозможность».

Попрошу вас воздержаться от оценочных суждений.

Это пожелание по доработке тоже зафиксировал, но в ближайшие задачи она не попадёт

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