Ошибка при гашении сертификата

День добрый, при гашении ВСД через API 2.0 возникает необрабатываемое исключение, явно не связанное с нарушением синтаксиса. Пример XML для гашения в аттаче (выкнуты данные по логинам и т.п).
Ошибка такая (она уже встречалась у многих - но причины всегда разные):

<apl:errorcode="APLM0017">An unexpected error has occurred while processing target service response.</apl:error>

1. Login для initiator, docInspection, vetInspection - одинаковый
2. Все GUID (ХС,ПЛ, поставщик, получатель) и UUID (для сертификата) проверены, в справочниках все есть.

В чем может быть причина?
Как вариант - неверная последовательность тегов, неработоспособность сервиса, какая-то простая причина (но уже в голову ничего не лезет) и т.п.

Такая же проблема

Скорее проблема в сервисе.

Файл посмотрел, что можно попробовать сделать:
1. Убрать миллисекунды из дат (issueDate, deliveryDate).
2. В качестве номера запроса не использовать ГУИД, а как в примерах, например, А0001
3. В accompanyingForms указать номер ТТН (добавить waybill).

К сожалению не помогло...

vld wrote:К сожалению не помогло...

3. В accompanyingForms указать номер ТТН (добавить waybill).

Пробовали?

Да, пробовали, блок вида
<vd:waybill>
<vd:issueNumber>цц2ц4454454</vd:issueNumber>
<vd:issueDate>2017-12-21</vd:issueDate>
<vd:type>1</vd:type>
</vd:waybill>
ошибка та же самая

vld wrote:Да, пробовали, блок вида
<vd:waybill>
<vd:issueNumber>цц2ц4454454</vd:issueNumber>
<vd:issueDate>2017-12-21</vd:issueDate>
<vd:type>1</vd:type>
</vd:waybill>
ошибка та же самая

В инфо о сроках попробовать указать не ноль, а просто пустое значение, если во вход. всд нет этой информации

Вот пример рабочего гашения с минимальными заполненными данными =)

Ну что сказать, это просто какой-то позор....

В общем удалось погасить сертификат, неопределенная ошибка стала более определенной (подозреваю, что разработчики правят непрерывно код),
оказывается была ошибка

1. в формате передачи дат производства и сроков годности. В руководстве http://help.vetrf.ru/wiki/ProcessIncomingConsignment_v2.0#.D0.A1.D1.86.D0.B5.D0.BD.D0.B0.D1.80.D0.B8.D0.B9_1.1.1._.D0.A1.D0.B2.D0.B5.D0.B4.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B2.D0.BE_.D0.B2.D1.85.D0.BE.D0.B4.D1.8F.D1.89.D0.B5.D0.BC_.D0.92.D0.A1.D0.94_.D1.81.D0.BE.D0.BE.D1.82.D0.B2.D0.B5.D1.82.D1.81.D1.82.D0.B2.D1.83.D1.8E.D1.82_.D1.84.D0.B0.D0.BA.D1.82.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.BC.2C_.D0.BF.D0.B0.D1.80.D1.82.D0.B8.D1.8F_.D0.BF.D1.80.D0.B8.D0.BD.D0.B8.D0.BC.D0.B0.D0.B5.D1.82.D1.81.D1.8F_.D0.B2_.D0.BF.D0.BE.D0.BB.D0.BD.D0.BE.D0.BC_.D0.BE.D0.B1.D1.8A.D0.B5.D0.BC.D0.B5.
по ProcessIncomingConsignment v2.0 сказано, что передача часов и минут является необязательной для скоропорта - так вот, это не так - они требуются, первый блин, так сказать.

2. оказалось, что страну - производителя и собственно производителя НЕЛЬЗЯ просто так взять и написать, как это следует из свойств товара - только так, как было во входящем ВСЭД. В нашем примере был товар - российского производства, для него НЕЛЬЗЯ указывать его реального производителя, поскольку такой не приходил с ВСЭД. Поскольку приходила только страна, то и указывать нужно только ее, не очевидно совсем, ведь производитель товара то не меняется никоим образом.

3. общие замечания (наверняка уже риторический вопрос) - зачем повторять в гашении все, что было во входящем ВСЭД и является его неотъемлемой частью - и поставщик и получатель и машины, перевозящие грузи и т.п. - масса всего, все это, очевидно, может быть получено и так, из свойств самого ВСЭД в основной базе, но, видимо, повторение - мать "мученья" + скучать не приходится.

4. перейдем к отказу от поставки, посмотрим, что будет там.

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