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

Костылетворец? Скачай их модуль и смотри там а лучше купите его и уже через него можно регламентом такое делать https://developer.kontur.ru/Docs/Diadoc_UM/proc/Reglamentnoye_Zadaniye.html

(1) Уже купили api, почти всё сделано, документы с файлами загружаются, осталось доделать подпись и отклонение

(2) верхнеуровнево процесс выглядит следующим образом:
- сформировать xml для УПД
- подписать ЭЦП
- Отправить полученный файл в Диадок вызвав соответствующий метод сервиса (ранее был PostMessage) с передачей  структуры содержащей ящик отправителя: FromBoxId, ящик получателя ToBoxId, признак черновая отправка или нет IsDraft, а также массив вложений  DocumentAttachments.
В свою очередь массив вложений (DocumentAttachments) может содержать данные счета на оплату и он не подписывается ЭЦП, а также подписанные двоичные данные УПД.

Ряд сложностей интеграции был вызван процессом генерации самой XML для УПД, но у Диадока есть метод  - GenerateTitleXml https://developer.kontur.ru/docs/diadoc-api/instructions/generation.html  ,  предназначенный для генерации титула, что значительно упростило мне работу.

Подписание ранее выполнял через плагин от Диадок  с вызовом Плагин.ПодписатьКонтент (данные, двоичныеДанныеСертификата), на тот момент в платформе не было  встроенных средств работы  с криптографией.
Обработку для 1С от Диадока я смотрел, удивился количеству абстракций и коду. Написал своё лаконичнее и проще

В заключение хочу сказать, что API диадока реализовано достаточно удобно. Для сложных момент вроде генерации титутал есть свои методы. Совершенно нетиповую конфигурацию я синтегрировал в течение 2-х месяцев. Техподдержка работает достаточно оперативно, был ряд проблем связанных с неправильным получение BoxID покупателей, так как данные в веб версии и по API могли отличаться,  в случае работы покупателя через роуминг.

(3) В целом, я понимаю, как это делается. У есть меня куча вопросов, например, есть сообщения с одиночными счетами, есть сообщения с пакетами документов Акт+СФ. Есть разница, как их подписывать? Нужно подписывать каждую сущность или пакеты целиком? В Вэб-версии диадока, можно, например, отклонить только Акт, а УПД подписать в пакете. В методах с подписями вроде везде используются только id сообщения и сущности.

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

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

Готов купить у вас обработку, если у вас всё работает через api.

1) сообщения с одиночными счетами не подписываются, отправляется неформализованный документ ProformaInvoice
2) Формирование титула для каждого документа своё. Более того, разные версии в зависимости от требований законодательства. На сайте Диадока смотри описания здесь
https://developer.kontur.ru/docs/diadoc-api/http/GenerateTitleXml.html
Если сыпятся ошибки, прочитай требования к формированию прото титула, типов передаваемых данных. Возможна ситуация, при которой необходимо передавать массив структур с единственной записью вместо структуры.
Купить не получиться, в компании уже не работаю. Это была не обработка, а целый блок, с возможностью отправлять/получать приглашения на работу через Диадок, автоматическое обновление идентификаторов почтовых ящиков, автоматическая отправка счетов, договоров, УПД.
Документооборот был примерно 15-17 тыс. документов в месяц, но особенностью, что всё выставление происходило в первые дни нового месяца (услуги, биллинг). За первые 2 дня, необходимо оперативно собрать данные, сформировать документы и в третий рабочий день их разослать.

(5) Со счетами понятно. Я имел в виду, что если один документ в пакете, например УПД. Значит для каждой сущности свое.
2 месяца работы программиста на это убить не готов, проще отказаться от автоматизации, это никогда не окупится

Может у кого-то еще есть готовая обработка, не настолько сложная как у вас и кто готов продать ее

На инфостарте есть рабочий стол диадок+сбис, можно было бы купить, но там модули закрытые

(6) у диадок есть обработки для типовых. Также через них можно заказать разработку под свою конфу

Сейчас ошибка вылезает. Я уже переделывал несколько раз и на Signers и на SignersSignerDetails и на ExtendedSignerDetails и везде ошибки и не понятно,в каком случае, что нужно использовать.

Invalid data UserContractData:
Line: 3, Position: 3, /UniversalTransferDocumentBuyerTitle[1]/SignerDetails[1]: The element 'UniversalTransferDocumentBuyerTitle' has invalid child element 'SignerDetails'. List of possible elements expected: 'Employee, OtherIssuer, AdditionalInfoId, Signers, ContentOperCode, BuyerInfoCircumPublicProc'.

Мне по сути нужно подписывать только актуальную версию УПД, Акт и СФ, Счет не подписывается.
Процедура отправки запросов готова, остался затык с титулом отправителя

(8) указана суть ошибки, неправильная дочерняя структура, ожидаются:  Employee, OtherIssuer, AdditionalInfoId, Signers, ContentOperCode, BuyerInfoCircumPublicPro
УПД может подписывать как ген.дир, так и другие сотрудники, в случае ген.дира в signers указываются его данные FirstNam, LastName и т.д., но нужно смотреть документацию, возможны изменения.

(10) Так вот непонятно, нужно ли именно этот массив использовать и его заполнить корректно или нужен другой тип массива. Я просто время потрачу, а окажется что нужно было по другому алгоритму вообще идти

(11) что указано в документации? https://developer.kontur.ru/docs/diadoc-api/index.html как необходимо генерировать титул?

Вы возьмите последнюю обработку Контур Диадок. И встройте ее в свою конфигурацию.
  У нас на подсоединение к 100% не типовой конфигурации ушло несколько дней.
  Конечно это тормозная обработка. Но подписание 100 тыс документов в месяц она тянет. Плюс можете добавить свои алгоритмы автоматического подписания, отправки и получения документов.

(13)
Генерируем титул получателя (на сколько я понял, это UniversalTransferDocumentBuyerTitle - титул продавца?).

Получили упрощенную xsd схему титула UserDataXsdUrl.

Возник вопрос - как автоматом сгенерировать и заполнить xml файл титула получателя на основе полученной схемы xsd, чтобы передать его как тело запроса в метод GenerateTitleXml?

Неужели надо вручную построчно формировать xml и заполнять все поля? Там же разные типы документов и заполнение будет разным.

Если есть листинг процедуры, пришлите, пожалуйста

далее ошибка
MessagePatchToPost.RecipientTitles[0]: Формат титула покупателя должен соответствовать формату титула продавца (Data at the root level is invalid. Line 1, position 1.)

дело было в полке, убрали ее и заработало

(16) какая нахер полка?

Добрый день!
Подниму тему. Кто-то смог решить вопрос с подписанием УПД 970 регзаданием?

При запросе на создание сообщения /V3/PostMessage можно указать документ на полке, для этого в DocumentAttachment.SignedContent нужно заполнить поле NameOnShelf, поле Content не заполняется.
Метод PostMessage трактует переданное имя файла как локальное для пользователя, подробнее см. в документации.

(19) С Вами есть возможность связаться?

найдите контакт в телеге @vakrisi