Интеграция с 1С

Особенности операции GetDistrictChangesList (возможно всех операций ...ChangesList)

по картинке колонки расположены в порядке получения из операции
можно предположить, что в порядке updateDate
в нижней строчке пронумерованы в порядке версий
createDate не совпадает ни в одной версии, хотя должна быть неизменной

и это все в продуктиве

Добрый день коллеги!

есть небольшой вопрос.

Возникла проблема при отправке ВСД.

У нас имеется два предприятия. На одном мы изготавливаем продукцию, от другого предприятия происходит отгрузка.
В Веб-версии меркурия никаких проблем не возникало, и отгружалось все нормально.
тут наступил момент интегрирования шлюза в 1С.

Пройдя сквозь болото, подводные камни, ураганы, при интеграции мы вышли на финишную прямую, и тут образовался овраг.

Вкратце об овраге:

Нам нужно отгрузить продукцию от предприятия номер 2, которая выпускалась на предприятии номер 1.

при отправке ВСД, меркурий выражается матерно-лингвистическим языком, и выдает ошибку, в которой показывает что предприятия отправитель и предприятие производитель должны быть одинаковыми.

Кто с этим сталкивался и как решил эту проблему?

Всех прошу помочь очень нужно

KuBeR21rus wrote:
Нам нужно отгрузить продукцию от предприятия номер 2, которая выпускалась на предприятии номер 1.
при отправке ВСД, меркурий выражается матерно-лингвистическим языком, и выдает ошибку, в которой показывает что предприятия отправитель и предприятие производитель должны быть одинаковыми.

А в чем проблема то? Делаете внутреннюю перевозку с предприятия 1 на предприятие 2, гасите входящий ВСД и отгружаете.

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

если только... отгрузка с производства1 с маркировкой на предприятие2, с предприятия2 с указанием маркировки производства - потребителю. Только как это оформляется в интегрированной версии не подскажу...
Можно попробовать предприятие2 поставить как перевозчика...

http://help.vetrf.ru/wiki/ProcessIncomingConsignment_v2.0

подскажите, по какому сценарию оприходовать ЧАСТЬ продукции?
т.е. по ВСД к нам приходит 10кг, но принимаем только 7.
что будет с остатком - нас не интересует.

попробовал как в примере "Частичное гашение электронного ВСД с возвратом части продукции"
получил ошибку: расхождение более 5%.

добавил секцию <merc:discrepancyReport> - гашение произошло, но принят ВЕСЬ объем продукции.
как все-таки оприходовать на склад 7 вместо 10?

из ссыли пункты 3.2.2, 10.3, 10.5
на выбор

Agnostik wrote:из ссыли пункты 3.2.2, 10.3, 10.5
на выбор

вот именно этими пунктами я и пользовался.
взял пример из 10.3.
в секции <merc:delivery> количество=10 (это то что указано в ВСД)
<vd:decision>PARTIALLY - партию принимаю частично

в <merc:returnedDelivery> количество=3 (делаю возврат, на склад должно оприходоватся 7)
получаю ошибку про 5%

если добавляю <merc:discrepancyReport> - запрос отрабатывает, но на склад поступает полный объем партии = 10

что-то где-то с количеством намудрил...

как я вижу идеальный вариант:
1. поставщик отписал 10, со склада списано 10. получатель имеет входящий ВСД со статусом CONFIRMED и количеством 10.
2. получатель из 10 принимает 7. получателю на склад приходит 7. поставщику на склад возвращается 3.

поставщик и получатель - это 2 наши ХС. учет ведется в одной базе.

наоборот делаете. ставьте 7.
указывать надо сколько на склад примете, разницу для возврата мерк сам посчитает

Agnostik wrote:наоборот делаете. ставьте 7.
указывать надо сколько на склад примете, разницу для возврата мерк сам посчитает

да. уже разобрался.

Добрый день!

Может на этом форуме отзовется кто.
После обновления тестовой платформы производственная партия без собственно номера партии не оформляется.
Если создавать ProductiveBatch на основе опубликованных описаний, то поле batchID оказывается списком и присвоить номер не получается.
Попробовала отправить полученный в программе запрос вклинив в текст xml нужное поле - партия создалась.
Как изящно обмануть программу и подменить тип свойства у партии?

GNN wrote:Добрый день!

Может на этом форуме отзовется кто.
После обновления тестовой платформы производственная партия без собственно номера партии не оформляется.
Если создавать ProductiveBatch на основе опубликованных описаний, то поле batchID оказывается списком и присвоить номер не получается.
Попробовала отправить полученный в программе запрос вклинив в текст xml нужное поле - партия создалась.
Как изящно обмануть программу и подменить тип свойства у партии?

надо изначально собрать фабрику таким образом что бы batchID получился нужного типа

lalex23 wrote:
надо изначально собрать фабрику таким образом что бы batchID получился нужного типа

А как? Вместо схемы от Меркурия http://api.vetrf.ru/schema/platform/services/2.0-RC-last/document_v2.0.xsd использовать свою?
Не очень нравится такое решение, так как если на том конце что-то изменят, то программа этого не увидит - схема будет статичной.

GNN wrote:

lalex23 wrote:
надо изначально собрать фабрику таким образом что бы batchID получился нужного типа

А как? Вместо схемы от Меркурия http://api.vetrf.ru/schema/platform/services/2.0-RC-last/document_v2.0.xsd использовать свою?
Не очень нравится такое решение, так как если на том конце что-то изменят, то программа этого не увидит - схема будет статичной.

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

lalex23 wrote:
не раз и не два приходилось редактировать схемы - без этого никак, до этой конкретно доберусь вероятно сегодня или завтра.

ProductiveBatch наследуется от Batch, в типе Batch это поле по описанию может быть списком. Получается, что при создании производственной партии нужно указывать схему, где Batch - не список, а в остальных случаях брать типовую схему? То есть каждый раз пересобирать фабрику? Так?