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

Не получается оформить транспортную партию во второй версии на тестовом контуре.
Уже неделю бьюсь с этим запросом. Сначала делал по описанию в справке, теперь вижу в справке появились примеры.
Делаю как в примере, но в ответ получаю:
Error parsing XML: {err}FORG0005: expected exactly one item, got 0 items
Помогите разобраться в чем причина.
Валидацию текста запроса проверяю с помощью он-лайн сервисов, все проходит. А Меркурий в упор не хочет принимать запрос.
Вот текст запроса:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2"
xmlns:bs="http://api.vetrf.ru/schema/cdm/base"
xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2"
xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
xmlns:apl="http://api.vetrf.ru/schema/cdm/application"
xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<apldef:submitApplicationRequest>
<apldef:apiKey>apiKey</apldef:apiKey>
<apl:application>
<apl:serviceId>mercury-g2b.service:2.0</apl:serviceId>
<apl:issuerId>1121bd89-bcb3-4c1d-a7bf-0ce78d905fa9</apl:issuerId>
<apl:issueDate>2017-11-27T08:53:49</apl:issueDate>
<apl:data>
<merc:prepareOutgoingConsignmentRequest>
<merc:localTransactionId>000000002779</merc:localTransactionId>
<merc:initiator>
<vd:login>login</vd:login>
</merc:initiator>
<merc:delivery>
<vd:deliveryDate>2017-11-27T08:53:47</vd:deliveryDate>
<vd:consignor>
<dt:businessEntity>
<bs:guid>1121bd89-bcb3-4c1d-a7bf-0ce78d905fa9</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:guid>100c6b08-453b-4913-9390-1a2f6194424c</bs:guid>
</dt:enterprise>
</vd:consignor>
<vd:consignee>
<dt:businessEntity>
<bs:guid>1121bd89-bcb3-4c1d-a7bf-0ce78d905fa9</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:guid>b66abc76-e564-48b5-aa74-a89416091706</bs:guid>
</dt:enterprise>
</vd:consignee>
<vd:consignment>
<vd:volume>50</vd:volume>
<vd:unit>
<bs:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</bs:guid>
</vd:unit>
<vd:sourceStockEntry>
<bs:guid>9bbf00ff-e14c-48fb-bda6-9bd068c79cf4</bs:guid>
</vd:sourceStockEntry>
</vd:consignment>
<vd:broker>
<bs:guid></bs:guid>
</vd:broker>
<vd:transportInfo>
<vd:transportType>1</vd:transportType>
<vd:transportNumber>
<vd:vehicleNumber>Н105ЕТ142</vd:vehicleNumber>
</vd:transportNumber>
</vd:transportInfo>
<vd:transportStorageType>FROZEN</vd:transportStorageType>
<vd:accompanyingForms>
<vd:waybill>
<vd:issueSeries></vd:issueSeries>
<vd:issueNumber>НХК-0000009527</vd:issueNumber>
<vd:issueDate>2017-11-24</vd:issueDate>
<vd:type>1</vd:type>
</vd:waybill>
<vd:vetCertificate>
<vd:authentication>
<vd:purpose>
<bs:guid></bs:guid>
</vd:purpose>
<vd:cargoInspected>false</vd:cargoInspected>
<vd:cargoExpertized>false</vd:cargoExpertized>
<vd:locationProsperity>Местность благополучна</vd:locationProsperity>
</vd:authentication>
</vd:vetCertificate>
</vd:accompanyingForms>
</merc:delivery>
</merc:prepareOutgoingConsignmentRequest>
</apl:data>
</apl:application>
</apldef:submitApplicationRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Добрый день.
Пытаюсь оформить производственную партию.
Указываю количество произведенной продукции 1053 кг.
Указываю, что этот объем упакован в коробки и их 234.
Отправляю запрос. Все проходит гладко.
Потом через веб смотрю что получилось и вижу:
Остаток 1053 кг...
Упаковка:
Промежуточный уровень
Примечание:
Фасовка:
Тип упаковки: Коробка, картонная
Количество единиц упаковки: 10
Объем единицы упаковки товара: 4,5 кг
Вопрос: куда делись мои 234 коробки? Почему всесто 234 я вижу цифру 10?

Вот фрагмет запроса, что в нем неправильного?:
<vd:productiveBatch>
<vd:productType>5</vd:productType>
<vd:product>
<bs:guid>d34504bb-7a93-e1c8-4859-339eafd97c6c</bs:guid>
</vd:product>
<vd:subProduct>
<bs:guid>a9cf8e60-b42e-afe1-bde2-23e408529c0b</bs:guid>
</vd:subProduct>
<vd:productItem>
<bs:guid>dbd96899-a73d-4ff7-8514-b6cc52cfddc8</bs:guid>
</vd:productItem>
<vd:volume>1053</vd:volume>
<vd:unit>
<bs:uuid>069792f0-053d-11e1-99b4-d8d385fbc9e8</bs:uuid>
</vd:unit>
<vd:dateOfProduction>
<vd:firstDate>
<dt:year>2017</dt:year>
<dt:month>8</dt:month>
<dt:day>4</dt:day>

</vd:firstDate>
</vd:dateOfProduction>
<vd:expiryDate>
<vd:firstDate>
<dt:year>2019</dt:year>
<dt:month>8</dt:month>
<dt:day>4</dt:day>

</vd:firstDate>
</vd:expiryDate>
<vd:batchID>НХК-0000000840</vd:batchID>
<vd:perishable>false</vd:perishable>
<vd:lowGradeCargo>false</vd:lowGradeCargo>
<vd:packageList>
<dt:package>
<dt:level>3</dt:level>
<dt:packingType>
<dt:globalID>CT</dt:globalID>
</dt:packingType>
<dt:quantity>234</dt:quantity>
<dt:productMarks class="EAN13">4607015936001</dt:productMarks>
<dt:productMarks class="EAN13">4607015938715</dt:productMarks>
</dt:package>
</vd:packageList>
</vd:productiveBatch>

Это "Меркурий"!
В нем возможно всё! В том числе и то, что одно и то же предприятие принадлежит разным Хоз.Субъектам.

В системе много дублей записей в адресных классификаторах с разными GUIDами. Я правильно понимаю, что мы можем выбирать любую запись из понравившихся?

Скачайте лучше SoapUI и не мучайтесь.
Там все гораздо наглядней.

Неужели С1 также все бухгалтера России создавали.???

Это вы к чему?
Если это вопрос мне, то напоминаю, что 1с не является общегосударственной системой или программой учета.
Она никого ни к чему не обязывает.

Т.е. вся розница должна там зарегистрироваться и сообщить свой GUID поставщику.

Это даже ЕГАИСу не удалось реализовать. А там санкции скорее всего по серьезнее.

Мы уже делаем предложение EDI провайдеру Контур для внесения изменения в формат EDI документов. Необходимо чтобы в документах передавались GUIDы Меркурия. Если бы такие поля были, проблем бы было гораздо меньше.
Волнует другой вопрос. Сколько ещё всяких разных разрозненных Государственных систем учета будет появляться? Почему все они разрознены и нет единых классификаторов и реестров. Под каждую систему нужно подделываться, дописывать, приобретать новое оборудование и мощности.
Уверен только в одном - Государство программистов без куска хлеба не оставит, проявляя таким образом "заботу".

Почему сложно? В жизни так и есть: имеется ХС (юр.лицо, производящее замороженные полуфабрикаты), который ведет свою деятельность на 3 ПО: на одном изготавливает исключительно пельмени, на втором - котлеты, на третьем и то, и другое, но в другом регионе.
И в то же время первый ПО обслуживает другого ХСа - изготавливает и ему пельмени.

Такого:

И в то же время первый ПО обслуживает другого ХСа - изготавливает и ему пельмени.

Не бывает. Люди устроены в конкретной организации и если они выпускают пельмени для другой, то здесь будет либо операция продажи, либо что-то ещё...
Но не будем дискутировать на эту тему. Структура Меркурия уже заложена, многим поначалу не понятна, но будем привыкать и работать как есть.

Метод getBusinessEntityByGUID - в acivityLocations будут указаны обслуживаемые ПО указанного ХС.

К примеру, этот метод ворачивает мне для сетевого клиента Розница К-1 около 1000 предприятий (ПО как вы выражаетесь).
Для оформления транспортной партии при отгрузки нашей продукции на конкретную точку мне нужно выбрать нужную среди 1000 точек.
В настоящий момент кроме как сидеть и сравнивать адреса других механизмов нет. Поэтому и прошу рассказать про поддержку GLN номеров.
Сетевые клиенты когда делают нам заказы указывают GLN номера своих точек. По этим номерам мы бы смогли без ручного поиска точки по адресу оформлять ВСД автоматически.
Кто-нибудь из разработчиков может сказать что-нибудь внятное про поддержку GLN в Меркурии?

А нельзя ли все операции делать по GUID?
Неужели для выполнения операций нужно будет всегда сначала узнавать UUIDы объектов и только потом выполнять операцию? Они же связаны между собой, если уж так нужны UUIDы выясните их сами на своей стороне по GUIDам.

У ХС и ПО связь многие ко многим

Как тут все сложно!!!
По проще нельзя?
Каким образом сопоставить информацию о контрагентах и торговых точках?
Получается что кроме как вручную-никак?

1. Егорова Ирина вы имеете отношение к команде разработчиков или поддержки?
2. По GLN меня интересует следующий вопрос:
если сеть присылает мне по каналу EDI заявку на поставку продукции в определенную свою точку, при этом указывает GLN своего предприятия и GLN своей точки, смогу я по этим номерам отыскать GUIDы ХС и площадки для оформления электронного ВСД? Если да, то какими методами сервисов нужно воспользоваться? Может быть есть методы которые не будут требовать GUIDов, а сразу по GLN оформят транспортную партию?

От себя твой запрос отправил. Получил вот такой ответ (мож чем поможет) :

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">soap-env:Server: BEA-382030</faultcode>
<faultstring>Error in operation: GetProductItemList</faultstring>
<faultactor>api2.vetrf.ru/platform/services/ProductService</faultactor>
<detail>
<ws:internalServiceFault xmlns:ws="http://api.vetrf.ru/schema/cdm/base/ws-definitions">
<base:message xmlns:base="http://api.vetrf.ru/schema/cdm/base">Internal Service Error!</base:message>
</ws:internalServiceFault>
<business/>
<runtime>
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-382030</con:errorCode>
<con:reason>Failure while unmarshalling message: Failed to parse XML text</con:reason>
<con:location>
<con:node>RouteToGetProductNameList</con:node>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
</runtime>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>

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

Вроде оно.