Миграция с коммерческих операторов ЭДО на ЭДО-Лайт : Маркировка

Только что, появился еще один документ, тот-же самый, но, статус - "Подпись требуется":



Почему так? Ошибка поставщика, или еще что-то?

В УПД есть подпись отправителя и получателя, а счет-фактуре - только подпись отправителя. Получатель не может подписать счет-фактуру.
В ЭДО должны применяться только УПД: в xml-файле поле "функция" надо СЧФДОП, а не СЧФ.

Спасибо, понятно. Я так и подумал.
Похоже, просто поставщик ошибся, и не то запулил... Потом, увидел ошибку, и исправился, прислал УПД правильную.

Буду сейчас с подписанием разбираться.

Хм...

Ничего такого нет, даже если скачать архив...



Подскажите, кто знает, где брать ЭЦП документа продавца, для вставки в тело ХМЛ информации покупателя?
Что-то я не догоняю, как это делается... Или я чего-то не понимаю, и все не так должно делаться?
Или нужно скачать ZIP архив, вытащить из него открепленную ЭЦП продавца в бинаргном формате "p7s", преобразовать ее в текстовый в Base64, и дальше ее использовать?
jokerpnz, как наиболее опытный в этом вопросе, подскажите пожалуйста? А то у меня прям тупик какой-то...

В общем, со списком служебных квитанций - разобрался.
При получении входящего документа, никаких квтитанций нет, поэтому запрос списа пустой.
Но, стоит открыть документ, загрузив XML, автоматически формируется неподписанная квитанция о получении.
Она(ее ИД) видна в списке неподписанных квитанций, полученным запросом.
А дальше - непонятно, как имея ее идентификатор, загрузить ее XML - ? В нем есть нужная для создания документа "тиул" открепленная ЭЦП продавца в текстовом формате.
Но... Никакими методами, ни из входящих, ни из исходящих, получить его не выходит - запрос 404 аозвращает, типа по этому ИД ничего не найдено...
Как можно ее получить? Мли может есть какой-то другой способ получить ЭЦП продавца входящего документа в формате Base64 - ???

PS А еще, странное дело, для меня вообще загадка, как это происходит - если загрузить архив всего ДО по документу, то квитанция исчезает из списка... Ну, правильно, так, как она становится ПОДПИСАННОЙ, причем не подписью оператора, а именно МОЕЙ подписью!
Как? Чем? РуТокен с ЭЦП (2.0., не извлекаемой) у меня на компе. Как оператор умудряется подписать ею документ у себя на сервере, без каких-либо действий с моей стороны? Кажется бредом, но, почему-то так и есть.

извиняюсь, что долго не отвечал, загорать ездил
нужно получить титул продавца DP_PDOTPR, в нём ЭЦП находится

по этому адресу я получаю имя файла и eventId
/api/v1/incoming-documents/{0}/events/{1}

{0} - идентификатор документа
(1) - 112003

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

получаем xml документ по адресу
/api/v1/incoming-documents/{0}/events/{1}/content
{0} - идентификатор документа
(1) - eventId, который запомнили ранее

ну а в этом файле уже подпись продавца, поле ЭЦППолФайл или ЭПОтпрФайл в зависимости от версии документа DP_PDOTPR

либо тащить весь архив и оттуда в файле DP_PDOTPR брать подпись, только файлов DP_PDOTPR в архиве может быть несколько на упд и другие квитанции отправителя

Вот этого не знал, что можно получить по типу, думал только по ИД квитанции.
Спасибо, попробую

Сейчас у меня другая проблема - отправка титула с типом мультипарт не правильно работает ни через WinHTTP, ни через XmlHttp...
1С не умеет отправлять через них файлы, может только строку передать. Это допустимо, но, строка должна быть в кодировке windows-1251... А эти запросы отправляют ее только в utf-8, не смотря на то, что на входе, в теле, windows-1251...
Соответственно, на все возвращается ответ, что 400, и в расшифровке: Ошибка {"errors":[{"error_message":"Element type "Р" must be followed by either attribute specifications, ">" or "/>"."}]}
"P" это как раз первый кирилический символ в строке XML-документа, если его в utf-8 открыть, не смотря на то, что он 1251...
Есть интересная ВК(внешняя компонента) для 1С, которая на базе curl сделана, по сути, обертка к нему. Она даже умеет мультипарт сама формировать(для обычных запросов я тело запроса сам формировал, отдельной функцией).
С ней - работает нормально, доки подписываются, если готовые файлы титула и ЭЦП титула подсунуть, открыть, и строками передать. Но, она почему-то конфликтует с MS_DOM, через который я файлы квитанций читаю для получения ЭЦП отправителя, и формирую ХМЛ титула, 1С-ка крашится ...

PS Можно конечно, чистым curl щтправлять титулы, но, как-то это не очень...

Не знаю, какие ресурсы ВК-обертка к cutl не может поделить с MS_DOM, мне отсюда не видно... Ну, да ладно, разработчику этой ВК информация донесена, захочет - разберется.
А пока, переделал парсинг входящего документа и квитанции, для получения информации, нужной для формирования файла титула, на другой способ парсинга XML, без использования DOM, c помощью XML-анализатора, из состава штатной для 1С ВК - v7Plus.
Так не падает, титул передается на сервер, но пока проверить не на чем было - небыло новых входчщих УПД.
А на старых, возвращается ошибка, что док с типом 504 в статусе 61 не может быть подписан.
Значит все работает(доки естественно не могут быть подписаны, так, как они уже подписаны), других ошибок нет.
Сегодня есть входящий УПД, получат товар, проверят, и после этого попробую подписать его уже из программы.

Сделал, и все как часики работало, пока сегодня такую фигню не словил:



Почему там тег ЭЦП получателя, вместо отправителя? И содержится в нем ЭЦП оператоа, самого ЦРПТ....

Где в таком случае брать ЭЦП отправителя?
Ну, скачаю я архив, разархивирую... А в нем этот-же файл.
Нет, в архиве есть файлы ЭЦП для всех ХМЛок, в том числе и самого документа, то, что в принципе и нужно... Но, они там в бинарном формате с расширением "p7s"...
Можно как-то из него получить ЭЦП текстом, для вставки в титул?

PS Архив ДО этого "странного документа" тут, в хранилище...