Ребята, я запутался, просто лежу... Прямо как шлюз...

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

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

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

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

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

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

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

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

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

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

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

Владимир Игнатов 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

egais2018 wrote:

GusVal 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

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

Владимир Игнатов 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>

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

GusVal wrote:

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

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

"Удалили путем слияния" - не важно. Хоть путем аннигиляции. GUIDы поменяться не должны. UUID - может, конечно, а вот GUID. Кому я это рассказываю? Зачем? Разработчики давно уже в каких-то нездешних высях розовых покемонов ловят, как я вижу...

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

GusVal wrote:

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

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

"Удалили путем слияния" - не важно. Хоть путем аннигиляции. GUIDы поменяться не должны. UUID - может, конечно, а вот GUID. Кому я это рассказываю? Зачем? Разработчики давно уже в каких-то нездешних высях розовых покемонов ловят, как я вижу...

Как раз, если удалили объединением, гуид и ууид поменяется. У каждой площадки был свой, объеденили, остался один. Это не поменяли инфу, а объеденили 2 элемента справочника.
Вот только мне казалось, что если указан GUID удаленных элементов, путем объединения, то система сама должна была понять, что имеется ввиду активный элемент. По крайне мере в справке где то такое читал.

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

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

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

oleg-x wrote:По крайне мере в справке где то такое читал.

Так у них справку одни "гении" писали, а шлюз Меркурия другие...

GusVal wrote:Проблема не в том, что объединили, а в том, что по одному и тому же UUID (состоянию в конкретный момент) документа разные методы возвращают разные GUID'ы

Пока писал интеграцию не раз сталкивался с тем, что при получении документов списком некоторые данные отличаются от данных при получении одного документа по uuid. Видимо одно правят, другое калечат...

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

И уж конечно, если есть один GUID, то все UUIDы должны меняться в рамках этого GUIDа. Там всякие next/prev. Тогда получается обычный двусвязный список. А так что? Как вот этот тип связей назвать? Был один список, у каждого элемента есть свой next/prev, был второй список. Потом "удалили путем слияния", в результате в какой-то момент в обоих списках самым новым стал 1 элемент, оба списка, если пройти по ним, своими next указывают на этот объединенный. А у него в prev - что???
Да и не в том счастье, безусловно. А в том, что 2 запроса про одну запись (в данном случае - ВСД) дают разную информацию. И вот это - недопустимо!

Владимир Игнатов wrote:Да и не в том счастье, безусловно. А в том, что 2 запроса про одну запись (в данном случае - ВСД) дают разную информацию. И вот это - недопустимо!

И тут есть подозрение что берутся из разных источников, что не должно быть. А судя по всему, построили они такого монстра, если что то менять в нем - это целый проект у них.

oleg-x wrote:И тут есть подозрение что берутся из разных источников, что не должно быть. А судя по всему, построили они такого монстра, если что то менять в нем - это целый проект у них.

Да скорее всего так и есть, просто баг походу.

> Да скорее всего так и есть, просто баг походу.

с их точки зрения это не баг а фича