Сталкнулись с интересной особенностью.
Поставщик нам передаёт только коды,  это видно по тегу "content", при этом Честный знак подставляет своё описание кода марки которые было присвоино этому коду при получении.
Мы передаём через api своё описание,  но ЧЗ это не интересно, и оно подставляет своё описание кода марки которые было присвоино этому коду при получении.

Может ктонибудь знает можно ли сменить описание для кода марки, или то что даётся при выписывании живёт всю жизнь с этим кодом?

(0) У ЧЗ своеобразное понимание логики. Созданный документ нельзя изменить - ошибся?! ну извини - создай новый документ (вообще нету понятия редактирования документа). Вообще чем больше погружаюсь в эту тему тем больше у..еваю (к сожалению никакого другого слова подобрать не смог, как ни старался)

(1) в твоем состоянии был, когда ЧЗ признал свои косяки и разрешил 1% от всех кодов не списывать...
Вот это треш...так треш...

(0) В "product_description"? Напишите в тех.поддержку, пускай исправляют поведение API.
(1) Это в СУЗ? В личном кабинете ЧЗ сохраняется в виде черновика и потом корректируется.

(3) Речь про API (хоть СУЗ хоть МТ, я не нашел возможности создать черновики с проверкой заполнения, да и вообще просто создавать черновики). Увидеть ошибки можно только после подписания документа а после этого ничего исправить уже нельзя...

(4) Если по API, тогда в чем проблема? Получить описание ошибки, исправить и отправить новую заявку.
Главное ошибки 404 и 500 игнорировать.

(5) да в том то и дело, что новую (а не исправить старую)

(6) Не припомню систему, где можно по старому идентификатору отправлять заявку.
Это надо будет еще одну сущность номер версии вводить, те же яйца, только в профиль.

(7) так далеко за примером ходить не надо - Меркурий можно посмотреть.
А то, что реализация у чз полное ... это даже не требует объяснение....
Вопрос тут задал (к сожалению ответа не получил) если знаешь может подскажешь - как получит статус заказа ?

(1) И начинаю уважать ЕГАИС :))

(8) В Мерке и используется связка guid / uuid. По-моему мнению, API ЧЗ наголову выше. С ЕГАИС не работал, сравнивать не могу.

Чисто метода нет по статусу как вы хотите в теме, в типовых можно посмотреть как обрабатываются закрытые заявки с отказом:
ИнтерфейсСУЗ.СтатусыБизнесЗаказов_V2
ИнтерфейсИСМП.СтатусыБизнесЗаказов_V2

(10) Посмотрел "СтатусыБизнесЗаказов_V2" в типовых конфах - ничего нового они там не придумали, используют "orders?omsId" для получения статуса всех заказов (правда сам ЧЗ рекомендует не использовать данный метод). Почему нет возможности получить статус конкретного заказа СУЗ (а тем более статус закрытого заказа) одному богу (зачеркнуто) ЧЗ известно.

>>API ЧЗ наголову выше
API ужасен, начиная с описания (почему-то одно описание (ТМ) в PDF другое (СУЗ) в DOC) заканчивая реализацией.

(11) Я такой рекомендации не видел, откуда вы это нашли? Там ограничение только не более 100 запросов в секунду по данному методу.

(12) Читаю описание их API
4.5.8. Метод «Получить статус заказов»
Этот метод используется для получения статуса бизнес заказов используя следующие параметры: маркер безопасности (token), идентификатор СУЗ. Маркер безопасности (token) генерируется СУЗ при регистрации клиента СУЗ. Маркер безопасности (token) передаётся на сервер в HTTP-заголовке с именем «clientToken».
Примечания:
    1) метод предназначен для восстановления АСУТП после полной потери данных, использование предоставляемых им возможностей в штатных процессах работы с СУЗ запрещено.

(13) Понял.
Только все-равно не понимаю, зачем вам статус документа? Мы используем методы:
http://<server-name>[:server-port]/api/v2/{extension}/buffer/status?omsId={omsId}&orderId={orderId}>in={gtin}

Далее получаем марки:
http://<server-name>[:server-port]/api/v2/{extension}/codes?omsId={omsId}&orderId={orderId}>in={gtin}&quantity={quantity}&lastBlockId={lastBlockId}

Если что-то пошло не так (инет обвалился), то:
http://<server>[:port]/api/v2/{extension}/codes/retry?orderId={orderId}>in={gtin}&blockId={blockId}

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

(14) >>Только все-равно не понимаю, зачем вам статус документа? Мы используем методы:
Я правильно понимаю, что вы не пишите статус заказа? или все таки пытаетесь его определить на основание статуса буфера?

P.S. С получением марок проблем нет, так же как с получением статуса буфера (пока заказ не закрыт)

(15) (16) Заказ может закрываться на каждую позицию GTIN (их в одном заказе может быть несколько).
У нас есть документ заказа марок. У него есть статус ожидания получения марок после подписания и передачи заявки в СУЗ.
Далее по каждой позиции GTIN есть информация по количеству заказанных и полученных марок. Таким образом мы знаем по какому orderID и GTIN еще не получены марки.
Получаем марки по каждой позиции GTIN в заказе, обновляем данные по полученному количеству.

Если заказанное количество равно полученному количеству марок, то подзаказ закрывается (без параметра lastBlockId):
http://<server-name>[:server-port]/api/v2/{extension}/buffer/close?orderId={orderId}>in={gtin}&omsId={omsId}&lastBlockId={lastBlockId}

Если по всем GTIN в документе получены марки (общее количество заказанных = полученных), то статус у документа выставляем полностью получено.
В СУЗ заказ марок сам закроется, как только все подзаказы закрыты.

(17) >>Заказ может закрываться на каждую позицию GTIN (их в одном заказе может быть несколько).
Только это не заказ закрывается а (они это называют подзаказ) т.е. конкретная позиция в заказе.

>>Если по всем GTIN в документе получены марки (общее количество заказанных = полученных), то статус у документа выставляем полностью получено.
В СУЗ заказ марок сам закроется, как только все подзаказы закрыты.

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

>>Далее по каждой позиции GTIN есть информация по количеству заказанных и полученных марок. Таким образом мы знаем по какому orderID и GTIN еще не получены марки.
Получаем марки по каждой позиции GTIN в заказе, обновляем данные по полученному количеству.

У меня в сущности все точно также.

>>Если заказанное количество равно полученному количеству марок, то подзаказ закрывается (без параметра lastBlockId):
На сколько я знаю он сам закроется через 3 дня (автоматически)

В любом случае спасибо за подробное описание вашей работы - видимо придется сделать все аналогично.

(18)
> На сколько я знаю он сам закроется через 3 дня (автоматически)
У нас на импорт заказывают по 700-800 GTIN за раз, а в СУЗ активных может быть не более 100 заказов.

С отвалом инета главное на тесте отработайте механизм, получите марки по подзаказу, а потом еще раз с обработкой ответа и если ошибка - повторное получение.

(19) >>получите марки по подзаказу, а потом еще раз с обработкой ответа и если ошибка - повторное получение.
Имеется ввиду отработать механизм повторного получения марок?

(20) Да, на случай если отправили запрос на получение подзаказа и инет отвалился, базу решили обновить и забыли остановить регламентное задание по получению марок.
Без него повторно марки уже не получить.