Взаимодействие с учетными системами хозяйствующих субъектов

указываете guid именно предприятия, не хозяйствующего субъекта? вы хорошо их различаете?
Хозяйствующий субъект - юр.лицо, ИП, и прочее
Предприятие - место проведения операции, адрес
вам нужен guid именно Предприятия для выполнения запроса.

Да, я немного путаюсь в их терминологии. Подскажите, как можно получить guid предприятия?

Ale059 wrote:Да, я немного путаюсь в их терминологии. Подскажите, как можно получить guid предприятия?

на мой взгляд вот эти запросы к сервисам должны реализовываться в первую очередь:
http://help.vetrf.ru/wiki/GetBusinessEntityByGUID
http://help.vetrf.ru/wiki/GetEnterpriseByGuid
http://help.vetrf.ru/wiki/ModifyBusinessEntityOperation
http://help.vetrf.ru/wiki/ModifyEnterpriseOperation
http://help.vetrf.ru/wiki/ModifyActivityLocationsOperation
первые два позволит получить полную информацию о любом ХС, в том числе и о Вашем, а так же список связанных с ним Предприятий, затем получить информацию о Предприятиях, остальные три - позволяют работать с полученной информацией
не спешите к транзакциям и ВСД - реализуйте механизмы, которые позволят комфортно работать

Спасибо. Покопаюсь в доке.

Что угодно, но только не это! Прошу Вас, исправьте проблему с кодировкой.
На запрос

Получаю ответ

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <ws:getRussianEnterpriseListResponse xmlns:bs="http://api.vetrf.ru/schema/cdm/base" xmlns:ikar="http://api.vetrf.ru/schema/cdm/ikar" xmlns:ent="http://api.vetrf.ru/schema/cdm/cerberus/enterprise" xmlns:ws="http://api.vetrf.ru/schema/cdm/cerberus/enterprise/ws-definitions">
            <ent:enterpriseList count="1" total="62789" offset="36191">
                <ent:enterprise>
                    <bs:uuid>43725329-7cf5-402f-b546-29fac4e214e1</bs:uuid>
                    <bs:guid>0584aa87-e50f-47aa-9793-50f4c1517b44</bs:guid>
                    <bs:active>true</bs:active>
                    <bs:last>true</bs:last>
                    <bs:status>100</bs:status>
                    <bs:createDate>2015-11-23T11:00:27+03:00</bs:createDate>
                    <bs:updateDate>2015-11-23T11:00:27+03:00</bs:updateDate>
                    <ent:name>Ð¿Ð°Ð²Ð¸Ð»ÑÐ¾Ð½ (ÐÐ ÐÐ¸ÑÐ·Ð¾ÐµÐ² Ð. Ð.)</ent:name>
                    <ent:type>1</ent:type>
                    <ent:address>
                        <ikar:country>
                            <bs:uuid>72a84b51-5c5e-11e1-b9b7-001966f192f1</bs:uuid>
                            <bs:guid>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</bs:guid>
                            <ikar:name>Российская Федерация</ikar:name>
                        </ikar:country>
                        <ikar:region>
                            <bs:uuid>4b2fd043-fc95-458a-9921-82c24e202e12</bs:uuid>
                            <bs:guid>1c727518-c96a-4f34-9ae6-fd510da3be03</bs:guid>
                            <ikar:name>Мурманская область</ikar:name>
                        </ikar:region>
                        <ikar:district>
                            <bs:uuid>45848ce6-537b-4286-b2f0-296ed5ae1477</bs:uuid>
                            <bs:guid>5b22eaf7-3bab-437c-938f-5af0f45502db</bs:guid>
                            <ikar:name>Кольский район</ikar:name>
                        </ikar:district>
                        <ikar:locality/>
                        <ikar:subLocality/>
                        <ikar:street/>
                        <ikar:addressView>Ð³. ÐÑÑÐ¼Ð°Ð½ÑÐº, ÑÐ». Ð§ÑÐ¼Ð±Ð°ÑÐ¾Ð²Ð°-ÐÑÑÐ¸Ð½ÑÐºÐ¾Ð³Ð¾, Ð´.15 (Ð¿Ð°Ð²Ð¸Ð»ÑÐ¾Ð½)</ikar:addressView>
                    </ent:address>
                    <ent:activityList count="1" total="1" offset="0">
                        <ent:activity>
                            <ent:name>Продажа готовой продукции</ent:name>
                        </ent:activity>
                    </ent:activityList>
                    <ent:owner>
                        <bs:uuid>bbad893f-63c4-448a-bf4b-f63da5c44fc7</bs:uuid>
                        <bs:guid>e80def34-bc06-454e-a6c5-1de7adc559e6</bs:guid>
                    </ent:owner>
                </ent:enterprise>
            </ent:enterpriseList>
        </ws:getRussianEnterpriseListResponse>
    </soap:Body>
</soapenv:Envelope>

До 36191 элемента проблем не наблюдалось.

ОБНОВЛЕНИЕ: РАЗОБРАЛСЯ. ПОНЯЛ В ЧЕМ ПРОБЛЕМА - последовательность тегов структуры <vetd:batch> изменена в версии 1.5. После <unit> в новой версии идут теги <vet:dateOfProduction> и т.д. до тега <vet:lowGradeCargo>. Потом нужно вставлять тег <vet:pakageList> и завершать все тегом <vet:owner>.

ОРИГИНАЛЬНЫЙ ТЕКСТ (до обновления):
Добрый день.

Создаю запрос на результат инвентаризации. Хочу создать новую складскую запись путем инвентаризации. Но SOAP упрямо выдает ошибку <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: Элемент 'dateOfProduction' не предусмотрен.

По документации он обязателен. Как и все следующие. Попробовал удалить из запроса все элементы, начиная с dateOfProduction до тэга </vetd:batch>, на что вышли уже меркурианские ошибки об отсутствии обязательных данных в запросе. Подскажите, где у меня нестыковка между схемой и требованием Меркурия?
Спасибо!

<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
                  xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions" 
                  xmlns:app="http://api.vetrf.ru/schema/cdm/application" 
                  xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/applications" 
                  xmlns:base="http://api.vetrf.ru/schema/cdm/base" 
                  xmlns:com="http://api.vetrf.ru/schema/cdm/argus/common" 
                  xmlns:ent="http://api.vetrf.ru/schema/cdm/cerberus/enterprise" 
                  xmlns:ikar="http://api.vetrf.ru/schema/cdm/ikar" 
                  xmlns:vet="http://api.vetrf.ru/schema/cdm/mercury/vet-document" 
                  xmlns:prod="http://api.vetrf.ru/schema/cdm/argus/production" 
                  xmlns:shp="http://api.vetrf.ru/schema/cdm/argus/shipment">
	<soapenv:Header/>
	<soapenv:Body>
		<ws:submitApplicationRequest>
			<ws:apiKey>API_KEY</ws:apiKey>
			<app:application>
				<app:serviceId>mercury-g2b.service:1.5</app:serviceId>
            		<app:issuerId>ISSUER_ID</app:issuerId>
		            <app:issueDate>2017-06-03T12:43:05</app:issueDate>
		            <app:data>
		            <merc:resolveDiscrepancyRequest>         
					   <merc:localTransactionId>A000000001</merc:localTransactionId>
					   <merc:initiator>
						  <com:login>user</com:login>
					   </merc:initiator>
					   <merc:enterprise>
						  <base:guid>GUID</base:guid>
					   </merc:enterprise>
					   <merc:inventoryDate>2017-06-05T00:00:00</merc:inventoryDate>
					   <merc:responsible>
						  <com:login>user</com:login>
					   </merc:responsible>
						<merc:stockDiscrepancy>
							 <vet:resultingList count="1" total="1" offset="0">                                                              
								<vet:stockEntry>
									<vet:batch>
									  <vet:productType>2</vet:productType>
									  <vet:product>
										 <base:uuid>64c7e27e-b999-c027-aa19-bb94269fcae9</base:uuid>
									  </vet:product>
									  <vet:subProduct>
										 <base:uuid>55132294-3e0e-95ef-fa0f-39a19bf1ef95</base:uuid>
									  </vet:subProduct>
									  <vet:productItem>
										 <base:guid>GUID</base:guid> 	
									  </vet:productItem>
									  <vet:volume>72</vet:volume>
									  <vet:unit>
										 <base:uuid>069792f0-053d-11e1-99b4-d8d385fbc9e8</base:uuid>
									  </vet:unit>
									  <vet:packageList>
										<vet:package>
										<vet:level>6</vet:level>
										<vet:packingType>
											<com:globalID>PB</com:globalID>
											<com:name>Поддон, ящичный</com:name>
										</vet:packingType>
										<vet:quantity>1</vet:quantity>
										<vet:productMarks class="BN">mark</vet:productMarks>
										</vet:package>
									<vet:package>
										<vet:level>4</vet:level>
										<vet:packingType>
											<com:globalID>4G</com:globalID>
											<com:name>Коробка из фибрового картона</com:name>
										</vet:packingType>
										<vet:quantity>72</vet:quantity>
										<vet:productMarks class="EAN13">15000159369678</vet:productMarks>
										<vet:productMarks class="BN">mark</vet:productMarks>
									</vet:package>
									<vet:package>
									<vet:level>2</vet:level>
										<vet:packingType>
											<com:globalID>BE</com:globalID>
											<com:name>Пакет (пачка/связка)</com:name>
										</vet:packingType>
										<vet:quantity>864</vet:quantity>
										<vet:productMarks class="EAN13">15000159369678</vet:productMarks>
										<vet:productMarks class="BN">mark</vet:productMarks>
									</vet:package>
									</vet:packageList>
   								    <vet:dateOfProduction>
										 <vet:firstDate>
											<base:year>2017</base:year>
											<base:month>5</base:month>
											<base:day>29</base:day>
											<base:hour>0</base:hour>
										 </vet:firstDate>
									</vet:dateOfProduction>
									<vet:expiryDate>
										 <vet:firstDate>
											<base:year>2017</base:year>
											<base:month>9</base:month>
											<base:day>29</base:day>
											<base:hour>0</base:hour>
										 </vet:firstDate>
									  </vet:expiryDate>
									  <vet:perishable>false</vet:perishable>
									  <vet:countryOfOrigin>
										 <base:uuid>72a84b51-5c5e-11e1-b9b7-001966f192f1</base:uuid>
									  </vet:countryOfOrigin>
									  <vet:producerList>
										 <ent:producer>
											<ent:enterprise>
											   <base:guid>GUID</base:guid>
											</ent:enterprise>
											<ent:role>PRODUCER</ent:role>
										 </ent:producer>
									  </vet:producerList>                              
									  <vet:lowGradeCargo>false</vet:lowGradeCargo>
									  <vet:owner>
										 <base:guid>GUID</base:guid>
									  </vet:owner>
								   </vet:batch>
								</vet:stockEntry>                        
							 </vet:resultingList>
						</merc:stockDiscrepancy>
						  <merc:discrepancyReport>
							 <vet:issueSeries>777</vet:issueSeries>
							 <vet:issueNumber>869588558</vet:issueNumber>
							 <vet:issueDate>2015-06-01</vet:issueDate>
							 <vet:reason>
								<vet:name>причина1</vet:name>
							 </vet:reason>
							 <vet:description>описание1</vet:description>
						  </merc:discrepancyReport>
					</merc:resolveDiscrepancyRequest>   
				</app:data>
			</app:application>
		</ws:submitApplicationRequest>
	</soapenv:Body>
</soapenv:Envelope>

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

Создаю запрос на результат инвентаризации. Хочу создать новую складскую запись путем инвентаризации. Но SOAP упрямо выдает ошибку <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: Элемент 'dateOfProduction' не предусмотрен.

По документации он обязателен. Как и все следующие. Попробовал удалить из запроса все элементы, начиная с dateOfProduction до тэга </vetd:batch>, на что вышли уже меркурианские ошибки об отсутствии обязательных данных в запросе. Подскажите, где у меня нестыковка между схемой и требованием Меркурия?
Спасибо!

Удалил <packageList> со всем его содержимым и запрос отработал. Странно, я думал в тесте уже работает версия 1.5. Так почему же упаковка создает такие проблемы?

Попытался объединить две записи готовой продукции по запросу ниже. Вернулась ошибка MERC17277 "Объединяемые записи складского журнала должны быть по входной продукции". Следует ли из нее, что объединять можно только записи для сырья? И в чем смысл такого ограничения? По мне так, чтобы сделать любую сверку запасов между Меркурием и учетной системой, нужно сначала получить единые складские записи в Меркурии независимо от вида продукции. Но что-то пока не получается. Никто не сталкивался с этой проблемой?

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
                  xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions" 
                  xmlns:app="http://api.vetrf.ru/schema/cdm/application"
                  xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/applications"
                  xmlns:base="http://api.vetrf.ru/schema/cdm/base" 
                  xmlns:com="http://api.vetrf.ru/schema/cdm/argus/common" 
                  xmlns:shp="http://api.vetrf.ru/schema/cdm/argus/shipment" 
                  xmlns:vet="http://api.vetrf.ru/schema/cdm/mercury/vet-document" 
                  xmlns:ent="http://api.vetrf.ru/schema/cdm/cerberus/enterprise" 
                  xmlns:prod="http://api.vetrf.ru/schema/cdm/argus/production" 
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
	<ws:submitApplicationRequest>
		<ws:apiKey>key</ws:apiKey>
		<app:application>
			<app:serviceId>mercury-g2b.service</app:serviceId>
           		<app:issuerId>guid</app:issuerId>
	            <app:issueDate>2017-06-03T12:43:05</app:issueDate>
	            <app:data>
				   <merc:mergeStockEntriesRequest>
					  <merc:localTransactionId>a0000000001</merc:localTransactionId>
					  <merc:initiator>
						 <com:login>login</com:login>
					  </merc:initiator>
					  <merc:enterprise>
						 <base:guid>guid</base:guid>
					  </merc:enterprise>
					  <merc:mergeOperation>
						 <vet:sourceStockEntry>
							<base:uuid>uuid1</base:uuid>
						 </vet:sourceStockEntry>
						 <vet:sourceStockEntry>
							<base:uuid>uuid2</base:uuid>
						 </vet:sourceStockEntry> 
						 <vet:batch>
						 	<vet:subProduct>
							   <base:guid>guid</base:guid>
							</vet:subProduct>
                                                        <vet:productItem>
								<prod:name>NAME</prod:name> 	
							</vet:productItem>
                     		                 </vet:batch> 
					  </merc:mergeOperation>
				   </merc:mergeStockEntriesRequest>
            </app:data>
         </app:application>
      </ws:submitApplicationRequest>
   </soapenv:Body>
</soapenv:Envelope>

lalex23 wrote:Объясните пожалуйста - в чём смысл запрета объединения записей журнала вырабатываемой продукции при работе через шлюз?
На тестовом сервере удалось без проблем объединить две записи, а через шлюз посылает лесом с ошибкой MERC17277

Добрый день, выяснилась ли причина данной проблемы? Тоже столкнулся с этой ошибкой. Не понятен в принципе ее смысл... То есть объединять складские записи можно только для сырья? Что значит входная продукция?

<apl:error code="MERC17277" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Объединяемые записи складского журнала должны быть по входной продукции</apl:error>

alpsmirnov wrote:

lalex23 wrote:Объясните пожалуйста - в чём смысл запрета объединения записей журнала вырабатываемой продукции при работе через шлюз?
На тестовом сервере удалось без проблем объединить две записи, а через шлюз посылает лесом с ошибкой MERC17277

Добрый день, выяснилась ли причина данной проблемы? Тоже столкнулся с этой ошибкой. Не понятен в принципе ее смысл... То есть объединять складские записи можно только для сырья? Что значит входная продукция?

<apl:error code="MERC17277" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Объединяемые записи складского журнала должны быть по входной продукции</apl:error>

ответ разработчиков полученный в почту год назад:

>1. при объединении партий информация о исходных партиях ни куда не пропадает и при необходимости можно "размотать" всю цепочку от актуальной записи до исходных, т.е. >"прослеживаемость" остаётся.

Не пропадает. Но в случае чего, оцените разницу, изымут из оборота 100 кг вашей продукции или 10 тонн? (в зависимости от объединения партий).

>2. через веб-интерфейс возможность объединения существует, т.е. если проблема в "прослеживаемости"(хотя первый пункт опровергает существование таковой), то почему в >веб-интерфейсе возможность есть?

Веб-интерфейс всё-таки не совсем правильно сравнивать со шлюзом. Тем не менее, да, там объединение есть и не исключено, что оно также будет в шлюзе.

Спасибо!!! Информация, конечно, весьма дипломатично представлена)). И не содержит ответа на вопрос про ошибку MERC17277. Жалко)

lalex23 wrote:

alpsmirnov wrote:

lalex23 wrote:Объясните пожалуйста - в чём смысл запрета объединения записей журнала вырабатываемой продукции при работе через шлюз?
На тестовом сервере удалось без проблем объединить две записи, а через шлюз посылает лесом с ошибкой MERC17277

Добрый день, выяснилась ли причина данной проблемы? Тоже столкнулся с этой ошибкой. Не понятен в принципе ее смысл... То есть объединять складские записи можно только для сырья? Что значит входная продукция?

<apl:error code="MERC17277" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Объединяемые записи складского журнала должны быть по входной продукции</apl:error>

ответ разработчиков полученный в почту год назад:

>1. при объединении партий информация о исходных партиях ни куда не пропадает и при необходимости можно "размотать" всю цепочку от актуальной записи до исходных, т.е. >"прослеживаемость" остаётся.

Не пропадает. Но в случае чего, оцените разницу, изымут из оборота 100 кг вашей продукции или 10 тонн? (в зависимости от объединения партий).

>2. через веб-интерфейс возможность объединения существует, т.е. если проблема в "прослеживаемости"(хотя первый пункт опровергает существование таковой), то почему в >веб-интерфейсе возможность есть?

Веб-интерфейс всё-таки не совсем правильно сравнивать со шлюзом. Тем не менее, да, там объединение есть и не исключено, что оно также будет в шлюзе.

alpsmirnov wrote:Спасибо!!! Информация, конечно, весьма дипломатично представлена)). И не содержит ответа на вопрос про ошибку MERC17277. Жалко)

смысл ответа мне понятен, не понятно различие в возможностях веб-интерфейса и шлюза

Добрый день!
Подскажите, нет ли ошибки в описании метода добавления/изменения продукции предприятия ModifyProducerStockListOperation http://help.vetrf.ru/wiki/ModifyProducerStockListOperation. Там написано, что при изменении номенклатуры нужно передавать UUID (Уникальный идентификатор версии записи в справочнике номенклатуры. Указывается только при редактировании записи). Получается, нужно хранить UUID всех версий на стороне учетной системы?
Кажется логичным передавать GUID (Глобальный уникальный идентификатор продукции), а в ответе уже получать UUID созданной на стороне Меркурия версии записи.

Artem_Bardyug wrote:Добрый день!
Подскажите, нет ли ошибки в описании метода добавления/изменения продукции предприятия ModifyProducerStockListOperation http://help.vetrf.ru/wiki/ModifyProducerStockListOperation. Там написано, что при изменении номенклатуры нужно передавать UUID (Уникальный идентификатор версии записи в справочнике номенклатуры. Указывается только при редактировании записи). Получается, нужно хранить UUID всех версий на стороне учетной системы?
Кажется логичным передавать GUID (Глобальный уникальный идентификатор продукции), а в ответе уже получать UUID созданной на стороне Меркурия версии записи.

А зачем хранить все UUID's? Если у Вас есть GUID, то всегда по нему можно получить актуальный (последний) UUID запросом getProductItemByGuid к продуктовому сервисуhttp://api.vetrf.ru/schema/platform/services/ProductService_v1.4_pilot.wsdl.

Добрый день.
Подскажите, пожалуйста:

1) Насколько я понимаю, получается, что можно приготовить товар, только указан его имя (без указания UUID из списка продукции).
Тогда в этом случае, получается, что при перемещении этого товара в ВСД так же будет только имя товара, а UUID не будет?

2) Если заводить ВСД на переработку через веб-интерфейс – получается, что будет создана партия, в которой не будет UUID?
(т.к. сейчас по сути через веб интерфейс нужно указывать название каждый раз, а не выбирать из списка товаров).