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

Добрый день!

Кто-нибудь знает, вышел ли в Т2 релиз версии 2.0?
Спасибо!

А полезно иногда писать на форуме))

Думаешь о том, что тебя прочитала куча людей, начинаешь испытывать ответственность, и сам находишь причину ошибки. Я разобрался. Все отработало. Прошу прощения за эмоциональность, но именно так, видимо, находятся правильные решения. Все загвоздка была в том, что как <vet:consignment>, так и <vet:stockEntry> могут содержать <vet:productName> и <vet:productCode>. И методом перебора, я нашел правильное место в запросе на выписку ВСД, куда нужно вставить <vet:productName> и <vet:productCode> в структуре <vet:consignment>, чтобы вся цепочка далее отработала. Это место между элементами <vet:packageList> и <vet:sourceStockEntry>.
При этом в запросе на погашение данные поля идут в конце структуры <vet:consignment>, сразу после элемента <vet:owner>.

alpsmirnov wrote:Результаты тестов по выписке ВСД и гашению ВСД с применением <vet:productName> и <vet:productCode>, которые якобы были созданы для передачи номенклатуры, отличной от номенклатуры производителя:

1) Несмотря на то, что в документации (изменения в версии 1.5) указано, что <vet:productName> и <vet:productCode> в запросе prepareOutcomingConsignmentRequest должны присутствовать в структуре <vet:consignment>, при добавлении этих полей в нее, постоянно возникают ошибки некорректной структуры XML. Наконец, убив несколько тысяч нервных клеток, я все же получил успешный результат теста, добавив их в структуру <vet:sourceStockEntry> вот в таком виде:
<vet:productName>TEST TEST TEST</vet:productName> <vet:productCode>TEST TEST TEST</vet:productCode>

2) В ответе на свой запрос (prepareOutcomingConsignmentRsponse) я получил уже другую картину. Опять же в структуре </merc:stockEntry> (не понятно, кстати, почему у нее в Rquest'e пространство имен vet, а в respons'e пространство имен merc) получил вот такой результат:
<vetd:productName xmlns:vetd="http://api.vetrf.ru/schema/cdm/mercury/vet-document">Pedigree dry first feeding 12*600g</vetd:productName> <vetd:productCode xmlns:vetd="http://api.vetrf.ru/schema/cdm/mercury/vet-document">2309</vetd:productCode>

То есть в ответе вместо того, что указал я при создании ВСД, приехало обратно описание товара в номенклатуре производителя, которое я ранее задавал для ProductItem в запросе ModifyProducerStockListRequest, а код - ТНВЭД, вместо кода, который указал я...

Отлично работает . Ну ок, на этом я не остановился и пошел дальше:

3) Решил погасить созданный ВСД на получающей площадке (т.к. у меня перемещение между площадками моего же ХС).
3.1) Сначала решил не указывать <vet:productName> и <vet:productCode>, ведь по документации они являются опциональными. Но не тут-то было. Меркурий вернул ошибку:
<apl:error code="MERC14098">Наименование продукции в сведениях о принимаемой партии обязательно для заполнения.</apl:error>

ОК, надо так надо:
3.2) Поскольку в запросе на погашение ВСД нет структуры <vet:stockEntry>, то вписывать <vet:productName> и <vet:productCode> больше некуда, кроме как в <vet:consignment>. Ну я и вписал, по аналогии со stockEntry в самом низу, настойчиво указывая следующее:
<vet:productName>TEST TEST TEST</vet:productName>
<vet:productCode>TEST TEST TEST</vet:productCode>[/code]

Ответ от Меркурия:
<apl:error code="MERC14232">Наименование продукции в запросе отличается от указанного в ветеринарно-сопроводительном документе без указания причины в акте несоответствия.</apl:error> <apl:error code="MERC14464">Unsupported error code: 14464</apl:error>

Ну ладно дорогуша, думаю я, укажу название так же, как оно было прописано в ответе на создание ВСД на шаге 2 (хоть это уже и некорректная работа). И чем Вы думаете это все закончилось? Правильно, - ошибкой с непонятным описанием, которая не поддерживается:

<apl:error code="MERC14464">Unsupported error code: 14464</apl:error>

Выводы:
1) Документация не соответствует функционалу (я молчу про help.vetrf.ru, на котором все уже устарело, но даже в описании версии 1.5 - приложено, информация представлена некорректно).
2) Функционал не соответствует заявленной идее. При попытке передать номенклатуру клиента в выделенных для этого полях, Меркурий все равно при создании ВСД в эти поля вписал не то, что нужно.
3) Погашение не получается сделать из-за неподдерживаемой ошибки.

Вопрос:
1) Кто-нибудь это читает? И куда писать, чтобы быть услышанным?

Результаты тестов по выписке ВСД и гашению ВСД с применением <vet:productName> и <vet:productCode>, которые якобы были созданы для передачи номенклатуры, отличной от номенклатуры производителя:

1) Несмотря на то, что в документации (изменения в версии 1.5) указано, что <vet:productName> и <vet:productCode> в запросе prepareOutcomingConsignmentRequest должны присутствовать в структуре <vet:consignment>, при добавлении этих полей в нее, постоянно возникают ошибки некорректной структуры XML. Наконец, убив несколько тысяч нервных клеток, я все же получил успешный результат теста, добавив их в структуру <vet:sourceStockEntry> вот в таком виде:

2) В ответе на свой запрос (prepareOutcomingConsignmentRsponse) я получил уже другую картину. Опять же в структуре </merc:stockEntry> (не понятно, кстати, почему у нее в Rquest'e пространство имен vet, а в respons'e пространство имен merc) получил вот такой результат:

То есть в ответе вместо того, что указал я при создании ВСД, приехало обратно описание товара в номенклатуре производителя, которое я ранее задавал для ProductItem в запросе ModifyProducerStockListRequest, а код - ТНВЭД, вместо кода, который указал я...

Отлично работает

. Ну ок, на этом я не остановился и пошел дальше:

3) Решил погасить созданный ВСД на получающей площадке (т.к. у меня перемещение между площадками моего же ХС).
3.1) Сначала решил не указывать <vet:productName> и <vet:productCode>, ведь по документации они являются опциональными. Но не тут-то было. Меркурий вернул ошибку:

ОК, надо так надо:
3.2) Поскольку в запросе на погашение ВСД нет структуры <vet:stockEntry>, то вписывать <vet:productName> и <vet:productCode> больше некуда, кроме как в <vet:consignment>. Ну я и вписал, по аналогии со stockEntry в самом низу, настойчиво указывая следующее:
<vet:productName>TEST TEST TEST</vet:productName>
<vet:productCode>TEST TEST TEST</vet:productCode>[/code]

Ответ от Меркурия:

Ну ладно дорогуша, думаю я, укажу название так же, как оно было прописано в ответе на создание ВСД на шаге 2 (хоть это уже и некорректная работа). И чем Вы думаете это все закончилось? Правильно, - ошибкой с непонятным описанием, которая не поддерживается:

Выводы:
1) Документация не соответствует функционалу (я молчу про help.vetrf.ru, на котором все уже устарело, но даже в описании версии 1.5 - приложено, информация представлена некорректно).
2) Функционал не соответствует заявленной идее. При попытке передать номенклатуру клиента в выделенных для этого полях, Меркурий все равно при создании ВСД в эти поля вписал не то, что нужно.
3) Погашение не получается сделать из-за неподдерживаемой ошибки.

Вопрос:
1) Кто-нибудь это читает? И куда писать, чтобы быть услышанным?

Добрый день, уважаемые участники Сообщества и евангелисты системы Меркурий!

Все же хотелось бы вновь поднять вопрос о добавлении опционального поля "ProducerBatchCode" в структуру vetd:Batch. Маркировка не покрывает все многообразие ситуаций, когда необходимо будет в Меркурии идентифицировать складские записи в соответствии с кодом партии, присвоенном производителем. Приведя аналогию с геометрией, отсутствие данного поля в структуре vetd:Batch схоже с переходом из трехмерного пространства (со всеми его степенями свободы) на плоский мир. Просто одно измерение убрано, и чтобы спроецировать красивый трехмерный мир, нужно использовать сложные геометрические преобразования. Так и в нашем случае, код партии производителя (а производитель одному и тому же продукту в течение суток при производстве может присвоить много кодов партий) используется в богатом многообразии бизнес-процессов, которые должны отражаться в Меркурии. Но поскольку Меркурий настойчиво не хочет разрешить производителям установить соответствие своих партий с партиями этого производителя, появляется необходимость строить изощренные средства преобразования на интеграционных порталах производителей....

Действительно, на стороне строящегося интеграционного решения производителя можно сохранять исторические данные, сложным образом устанавливать соответствие между "родными" партиями и партиями Меркурия путем расходования больших вычислительных ресурсов (со всеми вытекающими последствиями). Но вся эта концепция перестает работать как только мы говорим о том, что по каким-либо причинам пользователи решили вручную через веб-интерфейс Меркурия принять / произвести / поднять инвентаризацией сток. В этом случае никакой, даже самый высокоинтеллектуальный интеграционный портал, не найдет соответствие между созданной складской записью в Меркурии и стоками в терминах "родных" партий, потому что веб-интерфейс не предложит человеку указать "родную" партию производителя. А веб-интерфейс никто не отменял - это воркэраунд, если API-сервисы отвалятся...

Эти проблемы решаются одним простым способом: добавлением опционального поля ProducerBatchCode (или что-то в этом роде) в структуру vetd:Batch. Пусть кому не нужно, не пользуются. Но зато все остальные будут жить в красивом трехмерном мире, где птицы летают, а не скользят по плоскости

Спасибо!

Ну вот))

Сделал запрос на погашение выписанного ранее ВСД по перемещению внутри одного ХС (между площадками), и в ответ получил замысловатую ошибку, под которую даже выделили отдельный меркурианский код:
<apl:error code="MERC14464" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported error code: 14464</apl:error>

Неподдерживаемая ошибка в Меркурии - интересно, есть ли, все же, способ понять что пошло не так?))

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.

Спасибо!!! Информация, конечно, весьма дипломатично представлена)). И не содержит ответа на вопрос про ошибку 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. через веб-интерфейс возможность объединения существует, т.е. если проблема в "прослеживаемости"(хотя первый пункт опровергает существование таковой), то почему в >веб-интерфейсе возможность есть?

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

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

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

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

Попытался объединить две записи готовой продукции по запросу ниже. Вернулась ошибка 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>

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. Так почему же упаковка создает такие проблемы?

ОБНОВЛЕНИЕ: РАЗОБРАЛСЯ. ПОНЯЛ В ЧЕМ ПРОБЛЕМА - последовательность тегов структуры <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>

Николай Власов wrote:

alpsmirnov wrote:Пилю структуру БД для интеграционного решения для коннекта с Меркурием. Радовался как все логично придумано на стороне Меркурия, пока не осознал, что для такого важного объекта как код партии продукции нет специально выделенного поля в структуре vetd:Batch. Идентифицировать продукцию на стороне пользователей Меркурия по коду партии было бы намного приятнее, чем по срокам годности. Тем более, что большинство ERP-систем учитывают запасы именно в измерениях код материала / код партии, а не код материала / дата производства / дата окончания срока годности, как это предлагается делать во взаимодействии с Меркурием.

Может, добавите поле для кода партии в структуру vetd:Batch, чтобы далее складские записи можно было идентифицировать по коду партии, а не по срокам?

И второе логическое противоречие: структура vetd:StockEntry. Прекрасная структура, которая не содержит указания на то, к какому businessEntity и Enterprise она относится. Прям-таки зависшая в космосе ни к чему не относящая складская запись. Я понимаю, что во все операциях с участием stockEntry эти данные присутствуют. Но почему в спецификации к самому объекту StockEntry их нет, не понятно. Ну хоть убейте, не логично это.

Кажется логичным. А нельзя ли это сделать опциональным? Спрашиваю потому, что ни ECR мы вроде решили использовать именно код материала / дата производства / дата окончания срока годности

Хотя я посоветовался с Коллегами. В общем-то, если Меркурий не интересуют оригинальные производственные партии, то можно и не добавлять. Проблема возникнет у поставщиков, т.к. теряется отслеживаемость родных партий. Ведь на одном и том же заводе в одни и те же сутки могут быть произведены несколько "родных" партий одного и того же продукта. А если Меркурий в будущем будет использоваться для отзывов и блокировок продукции, то это может стать проблемой для поставщиков, ведь наименьшим "квантом" для такой блокировки будет партия Меркурия, характеризующая товар, произведенный в определенную дату, а не товар определенной оригинальной партии. Я не был на ECR'ах и относительно недавно начал заниматься интеграцией с Меркурием. Возможно, я не знаю о каких-то договоренностях о том, как поставщики будут производить точечную идентификацию "родных" партий, которые нужно будет отозвать.

Пилю структуру БД для интеграционного решения для коннекта с Меркурием. Радовался как все логично придумано на стороне Меркурия, пока не осознал, что для такого важного объекта как код партии продукции нет специально выделенного поля в структуре vetd:Batch. Идентифицировать продукцию на стороне пользователей Меркурия по коду партии было бы намного приятнее, чем по срокам годности. Тем более, что большинство ERP-систем учитывают запасы именно в измерениях код материала / код партии, а не код материала / дата производства / дата окончания срока годности, как это предлагается делать во взаимодействии с Меркурием.

Может, добавите поле для кода партии в структуру vetd:Batch, чтобы далее складские записи можно было идентифицировать по коду партии, а не по срокам?

И второе логическое противоречие: структура vetd:StockEntry. Прекрасная структура, которая не содержит указания на то, к какому businessEntity и Enterprise она относится. Прям-таки зависшая в космосе ни к чему не относящая складская запись. Я понимаю, что во все операциях с участием stockEntry эти данные присутствуют. Но почему в спецификации к самому объекту StockEntry их нет, не понятно. Ну хоть убейте, не логично это.