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

SergP wrote:День добрый.

Отправил контейнера во Владивосток, внутри одной ООО без смены владельца, погасил ВСД ранее времени, то есть ранее чем "РСХН снял пломбу". Забородили контейнера, мол: "Не имел права!".
Подскажите, как изменить дату "гашения" в ВСД которое уже"погашено"?
Аннулировать? Инвентаризация?

Жесть бюрократическая, реальность подгоняем под бумаги...

Спасибо.

Если по железной дороге отправляли, то там все серьезно, пока вет. врач на станции не разрешит, гасить не можете (выгрузка только после осмотра). Поэтому договаривайтесь с вет. врачом, "задним" числом ничего не сможете сделать. Автомобильным транспортом не так строго, но там дороже.

ZDmitry wrote:Через АПИ тоже отправляются на не привязанные! Проверял. Но вот эти мертвые нам все портят.

Действительно отправляются, раньше вроде бы не отправлялись.

Сегодня разбирался с площадками, итоги:
1. Через АПИ Меркурий не все ХС отдает методом GetBusinessEntityList. Есть ХС которые по ИНН находятся в веб-интерфейсе, но через АПИ нет (по ГУИД нормально находятся GetBusinessEntityByGuid). GetBusinessEntityList по ИНН или региону ХС не возвращает (по ГУИД не пробовал, но смысл этот метод использовать, если он известен).
2. Метод GetBusinessEntityList возвращает "мертвые" ХС. В веб-интерфейсе ХС не находятся и соответственно через АПИ выходит ошибка MERC02129 (Хозяйствующий субъект, получатель партии продукции, с указанным идентификатором не найден...). Через АПИ по такому ХС и привязанная площадка нормально получается, но отправить ничего нельзя.
3. Площадки могут быть привязаны, а могут и не привязаны к ХС, соответственно через АПИ полный список площадок получить невозможно (во всяком случае быстро, учитывая, что не привязанные ищутся только по наименованию и не всегда их корректно обзывают, да и не все из них рабочие, что можно выяснить только при выписке ВСД).

В итоге сейчас невозможно через АПИ сопоставлять контрагентов, только через веб-интерфейс (самый надежный способ). ГУИД ХС и площадки получателя можно узнавать по "тестовой" продаже из веб-интерфейса через АПИ (ГУИД ХС может найти только получатель из Цербера, но у многих нет доступа). Но это совсем не быстро, а если учесть активизацию проверяющих и то что они проверяют буквально все (и сроки на товаре), то придется отказываться от продаж до гарантированной отправки ВСД (это еще молока нет, там контрагентов море).

ZDmitry wrote:Да. Полно таких. Видим. Можно как-то проверить, площадка рабочая или нет до выполнения транзакции по ней? Или только через веб смотреть? Ведь веб. показывает только живые площадки. Как запросом получать только живые? Я так понимаю у есть несколько баз, которые не совсем зеркальные?! Когда я делаю запрос к сервису с площадками, то она живая, а когда запрос на транзакцию - то мертвая! А воз и ныне там(((. Система работает штатно!!!

Проверить можно только при отправке ВСД (в Цербере по площадке информация не показывается, что с ней что-то не так). Если площадка не привязана к ХС, то через веб отправить можно, через АПИ нельзя (но там можно привязку проверить, при установленной галочке "с учетом связи...." площадка должна находиться). Через веб скорее всего можно отправить даже по некорректно заведенным (привязаны к ХС, но через АПИ не отправляются).

А в запросе точно GetStockEntryByGuidRequest отправляете? Нужно getStockEntryByGuidRequest, эта ошибка у многих была. Ошибка в получении результата говорит об ошибке в запросе.

ksu66 wrote:добрый день

заметил что в запросе у меня <serviceId>mercury-g2b.service:2.1</serviceId>
а в ответе я получаю <serviceId>mercury-g2b.service</serviceId>
может надо заново регистрироваться для версии 2.1?

Это нормально, не ошибка.

ksu66 wrote:

<applicationId>728b0bb0-6b57-4852-b74e-dc705881ccc9</applicationId>

Почему ответ получаете по непонятному запросу, если заявка была зарегистрирована на <applicationId>2a4b7284-6f31-4abc-a856-2bdc37b89020</applicationId> или это для примера написали?

Таких площадок море. Раньше писали (где-то в какой-то ветке было), что помогает только заведение новых.

inco wrote:

mevgenym wrote:попробуйте так

<apl:serviceId>mercury-g2b.service:2.1</apl:serviceId>

не прокатило (

Псевдоним объявлен как "SOAPENV", а в тексте пишите "soapenv:Header", то же самое "soapenv:Body". Нужно "SOAPENV:Header" и т.д. В Меркурии регистр важен.

Codev wrote:Подскажите, пожалуйста, на какой адрес отправлять запрос на гашение ВСД?

Все заявки подаются на адреса для продуктивного контура:

Версия 2.0:
адрес для 2.0: api.vetrf.ru/platform/services/2.0/ApplicationManagementService

Версия 2.1:
адрес для 2.1: api.vetrf.ru/platform/services/2.1/ApplicationManagementService

ly_il wrote:Подскажите как убрать\сменить Контактный телефон пользователя в разделе "Кто выписал ВСД"?

В Ветис.Паспорте этого раздела нет.
В Меркурий.ХС в разделе "Настройки-Информация о пользователе-Общие сведения" ничего редактировать нельзя.

В Ветис.Паспорт контактный телефон есть, в разделе Профиль - закладка Информация. Если оттуда убрать телефон, тогда все ранее выписанные ВСД все равно будут содержать информацию о телефоне.

inco wrote:Спасибо! Это уже глаз "замылился" похоже...
Теперь на "unit" ругается.

кусок с ними:
<vd:consignment id="id1"> <vd:productItem> <bs:guid>4408533a-70d3-4b3f-b431-33375e658ce0</bs:guid> <dt:packaging> <dt:packagingType> <bs:guid>cd449f46-29f4-42af-8d36-046f0954ae63</bs:guid> </dt:packagingType> <dt:volume>2</dt:volume> <dt:unit> <bs:guid>069792f0-053d-11e1-99b4-d8d385fbc9e8</bs:guid> </dt:unit> </dt:packaging> </vd:productItem> <vd:volume>1.7</vd:volume> <dt:unit> <bs:guid>069792f0-053d-11e1-99b4-d8d385fbc9e8</bs:guid> </dt:unit> <vd:packageList> <dt:package> <dt:level>4</dt:level> <dt:packingType> <bs:guid>cd449f46-29f4-42af-8d36-046f0954ae63</bs:guid> </dt:packingType> <dt:quantity>0</dt:quantity> </dt:package> </vd:packageList> <vd:applicableClassifications>MANUFACTURED</vd:applicableClassifications> <vd:sourceStockEntry> <bs:guid>321616fc-6bd1-43d0-b094-454808888e50</bs:guid> </vd:sourceStockEntry> </vd:consignment>

Ответ:

<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions"> <application xmlns="http://api.vetrf.ru/schema/cdm/application"> <applicationId>4717ef01-04d2-461d-a988-c12f92fb2cdd</applicationId> <status>REJECTED</status> <serviceId>mercury-g2b.service</serviceId> <issuerId>c5518005-b375-445d-9298-bcd74a1ec2d8</issuerId> <issueDate>2019-02-05T10:28:35+03:00</issueDate> <rcvDate>2019-02-05T10:34:48+03:00</rcvDate> <prdcRsltDate>2019-02-05T10:34:48+03:00</prdcRsltDate> <errors> <apl:error code="APLM0007" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Wrong application data format. Format validation failed due to XML Schema rules: Element 'unit' not expected. </apl:error> </errors> </application> </receiveApplicationResultResponse></soap:Body></soap:Envelope>

По структуре вроде там, где нужно, "namespace" проверил. ":" даже переставил (было опасение, что символ с русскоязычной раскладки стоит). По описанию полей внутри глянул: "Обязательно должно быть заполнено хотя бы одно из полей: либо UUID, либо GUID. При указании обоих полей приоритет у UUID." Один обязательный (GUID) у меня есть. Что удивило - в примерах оттуда же (http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0) блок "vd:productItem" и, соответственно "dt:unit" внутри совсем ответствует.
На что еще обратить внимание стоит?

Прошу подсказать так же: Как правильно читается обязательность заполнения XML - элементов.
Было соображение, что:
[1..1] - все обязательны
[0..1] - обязательно заполнение хотя бы одного
[1..*], [0..*] - непонятно.

Но обратил внимание, что, допустим, для "dt:businessEntity" на странице http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0 стоит "[1..1]", но, при этом, текстом в колонке описание написано, что обязательно хотя бы одно.

Спасибо!

Здесь пространство имен для unit не то указано (должно быть vd:unit):

[1..1] - тег обязательно присутствует, и он может встречаться в xml только один раз
[0..1] - тег можно указать, а можно пропустить (в Меркурии это означает в большинстве случаев, что нужно указать какой-нибудь один тег из таких {пример, uuid и guid})
[1..*] - тег обязателен, но можно указать несколько раз в xml (несколько последовательных блоков)
[0..*] - тег можно не указывать, но если нужно, то можно несколько раз.

Можно указывать и UUID и GUID, но приоритет у GUID.

inco wrote:Спасибо, увидел, где ошибся, исправил. Кроме того, были пустые значения ID упаковки и ед. измерения. Тоже исправил, но результат тот же.

Что означает "Element 'guid' not expected" - так и не пойму. И какой именно гуид. По запросу проверил еще раз. Проверял по описанию здесь: http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0 .
Прошу совета в какую сторону копать вообще...

Если в оригинале текст запроса такой же, тогда ошибка в отсутствии указания namespace у тега guid (должно быть bs:guid):

inco wrote:Добрый день! Отправляю запрос на регистрацию транспортной партии

<errors>
<apl:error code="APLM0007" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Wrong application data format. Format validation failed due to XML Schema rules: Element 'guid' not expected.
</apl:error>

Ошибка здесь (тег purpose закрывается не там где нужно):

Зачем в <vd:consignment xmlns:id="id1"> "xmlns:" (в vd:vetCertificate то же самое)? id - это атрибут.

Atlashkin wrote:serg882, Спасибо за информацию.
По сути преимущества на данный момент только появление дополнительных фильтров по датам при загрузке списка эВСД и изменений. это поможет избежать ошибки APLM00012 ?
фильтр по связанному документу не работает.
поиск по GTINу работает.

По преимуществам имеет смысл сравнивать версии 1.4 и 2.0, версия 2.1 = 2.0 + новый функционал (в виде фильтров). В 2.0 получение ВСД было только по фильтрам: тип (исходящий, входящий), и статус (оформлен, погашен, закрыт), и если не погашенных ВСД по площадке много, то получить ВСД в 2.0 было невозможно. Поэтому лучше перейти на 2.1, на ней критичных ошибок нет.

АнтонКос wrote:

АнтонКос wrote:Как шлюз работает? Что-то моросит его.

???

Работает, 10 минут назад отправилась транзакция на 150 строк за 2 минуты (немного дольше чем обычно).

dk wrote:

serg882 wrote:В GetVetDocumentListOperation фильтры работают как нужно.

Попробуйте сделать фильтр по referencedDocument. Неделю назад не работало, была ветка на форуме, обсуждали.

serg882 wrote:В 2.1 объединили фильтры GetVetDocumentListOperation и GetVetDocumentListOperation. Все же у GetVetDocumentChangesListOperation назначение другое и получать ВСД для гашения удобнее методом GetVetDocumentListOperation.

В 2.1. никакой разницы, но GetVetDocumentListOperation чаще выдаёт ошибки, видимо из-за того, что его чаще используют.

Я написал, что нужные мне фильтры работают как и должны работать. Экзотику не проверял, она и на 2.0 не работала. GetVetDocumentListOperation ошибок на 2.1 в принципе не выдавала (в последнее время, по началу были дни), но если в выборке будет много ВСД, тогда конечно "отбойник" сработает.