Сообщения, отправленные пользователем: GusVal

prosoft wrote:У нас все регистрируется

Ок, спс за информацию...

Ау, люди? Кто-нибудь производит продукцию через шлюз 2.0?
У меня со вчерашнего вечера
'Действие необходимо повторить - URL:https://api.vetrf.ru/platform/services/2.0/ApplicationManagementService - SOAPAction:submitApplicationRequest'

Работа встала...

(( Санкции что ли? Персональные?

У кого-нибудь производство работает?

Шлюз сдох

Владимир Игнатов wrote: GUIDы поменяться не должны. UUID - может, конечно, а вот GUID.

Так на эту аксиому и был мой скромный расчет... Ан нет... Наловился я всяких "MERC14225 Предприятие-отправитель в сведениях о принимаемой партии должен совпадать с указанным в ветеринарно-сопроводительном документе." пока не раскусил этот заговор...

Проблема не в том, что объединили, а в том, что по одному и тому же UUID (состоянию в конкретный момент) документа разные методы возвращают разные GUID'ы... Вот в этом засада полная, так не делается. Скорее всего в одном месте костыль воткнули, а про другие забыли.

Владимир Игнатов wrote:
Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?

Да запросто... В пятницу потратил пару часов...
Вот фрагмент getVetDocumentListRequest:
<vd:vetDocument>
<bs:uuid>287d1ca4-0f5e-4fa9-9097-6b24e07d36ec</bs:uuid>
<vd:issueDate>2018-08-03</vd:issueDate>
<vd:vetDForm>LIC2</vd:vetDForm>
<vd:vetDType>TRANSPORT</vd:vetDType>
<vd:vetDStatus>CONFIRMED</vd:vetDStatus>
<vd:lastUpdateDate>2018-08-03T09:14:56+03:00</vd:lastUpdateDate>
<vd:certifiedConsignment>
<vd:consignor>
<dt:businessEntity>
<bs:uuid>52223022-93c8-4014-b3b1-2113c9752105</bs:uuid>
<bs:guid>e01d5abc-7f57-44fb-a7e7-b6e8daf402a8</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:uuid>9eac2ffa-91b4-4601-b9a9-4fa46be828a0</bs:uuid>
<bs:guid>c463fc54-4fdc-43c0-9014-66994f414c0c</bs:guid>
</dt:enterprise>
</vd:consignor>

Потом беру GetVetDocumentByUuid с этим UUID документа и вижу
<vd:vetDocument>
<bs:uuid>287d1ca4-0f5e-4fa9-9097-6b24e07d36ec</bs:uuid>
<vd:issueDate>2018-08-03</vd:issueDate>
<vd:vetDForm>LIC2</vd:vetDForm>
<vd:vetDType>TRANSPORT</vd:vetDType>
<vd:vetDStatus>CONFIRMED</vd:vetDStatus>
<vd:lastUpdateDate>2018-08-03T09:14:56+03:00</vd:lastUpdateDate>
<vd:certifiedConsignment>
<vd:consignor>
<dt:businessEntity>
<bs:uuid>52223022-93c8-4014-b3b1-2113c9752105</bs:uuid>
<bs:guid>e01d5abc-7f57-44fb-a7e7-b6e8daf402a8</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:uuid>9c7afcfb-7f35-4e4d-b5c6-8f7ec02b10dc</bs:uuid>
<bs:guid>6150d3dd-ba54-36b8-676a-0b6a5c576622</bs:guid>
</dt:enterprise>

Сейчас еще проверил, что вернул processIncomingConsignment... Да-да... Как и "ожидалось"...

<merc:vetDocument>
<bs:uuid>287d1ca4-0f5e-4fa9-9097-6b24e07d36ec</bs:uuid>
<vd:issueDate>2018-08-03</vd:issueDate>
<vd:vetDForm>LIC2</vd:vetDForm>
<vd:vetDType>TRANSPORT</vd:vetDType>
<vd:vetDStatus>UTILIZED</vd:vetDStatus>
<vd:lastUpdateDate>2018-08-03T18:59:17+03:00</vd:lastUpdateDate>
<vd:certifiedConsignment>
<vd:consignor>
<dt:businessEntity>
<bs:uuid>52223022-93c8-4014-b3b1-2113c9752105</bs:uuid>
<bs:guid>e01d5abc-7f57-44fb-a7e7-b6e8daf402a8</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:uuid>9c7afcfb-7f35-4e4d-b5c6-8f7ec02b10dc</bs:uuid>
<bs:guid>6150d3dd-ba54-36b8-676a-0b6a5c576622</bs:guid>
</dt:enterprise>
</vd:consignor>

Вот такая вот история....
Если смотреть по партнерам, то там одного удалили путем слияния... Но почему тогда при гашении Меркурий это не учитывает?

egais2018 wrote:

GusVal wrote:Я все понимаю

Как вам это удалось (в случае с Меркурием)?

Самовнушение

Владимир Игнатов wrote:

GusVal wrote:Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!

У них разные Consignor.Enterprise.guid !!!

getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.

Ничего не понимаю. По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid? Или потом при запросе предприятия по GUID приходят разные статусы предприятия?

По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid

Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!

У них разные Consignor.Enterprise.guid !!!

getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.

И все это для одного и того же UUID-документа.

Я все понимаю, но @@@ть кто до такого додумался???

Uncore wrote:Что-то телефон 8-4922-55-99-29 недоступен, как еще можно связаться с техподдержкой?

8-4922-52-99-29

Ну шо? Опять? (с)

Точно... Для списания под ноль ему именно UUID нужен... Спасибо за помощь..

Именно UUID? Я ему GUID подсовываю...

Спрошу по-другому... Кто-нибудь через API вчера-сегодня списывал под ноль?

Не могу списать остаток по партии в ноль. Получаю набор ошибок.
<apl:error code="MERC24082" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Дата выработки для продукции обязательна для заполнения.</apl:error>
<apl:error code="MERC24083" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Дата окончания срока годности продукции обязательна для заполнения.</apl:error>
<apl:error code="MERC24091" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Объём продукции указан неверно.</apl:error>
Какие подводные камни могут быть, если делаю все по примеру запроса 3.1 в документации?

http://help.vetrf.ru/wiki/ResolveDiscrepancyOperation_v2.0#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.87.D0.B0.D0.BD.D0.B8.D1.8F_.D0.BA_.D0.B4.D0.B0.D0.BD.D0.BD.D1.8B.D0.BC_.D0.B7.D0.B0.D0.BF.D1.80.D0.BE.D1.81.D0.B0

Что за ересь?