Добрый день!
Кто-нибудь пробовал кидать запросы в ВЕТИС?

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

То есть она подразумевает,  что вет. врач работающий на предприятии кристально честный человек и следит чего там склад кому отгрузил и сколько чего цех произвел,  а не тупо подмахивает входящие заявки на ВСД.

(38) Ветврачей на молочных заводах нет. Дело не их честности. То, что ветсертификация не достигает декларируемых целей- согласен.
Для ЭВС требуется ведение партионного учета или его имитация, но и она стоит денег, нервов.

(39)  Основная проблема с запуском меркурия на молочке - это не столько партионный учет который можно легко имитировать,  сколько потребность в штатном вет. враче который "подпишет" все ВСД в 3-4 утра,  потому как в 5 утра уже пора развозить продукцию по точкам.  А молочка это не колбаса,  она лишний день на складе пролежать не может.

(40) Приедет другая машина, подписывай заново! Завис Меркурий, сыпятся ошибки - плати за простой перевозчикам.

(36) идея интересная, и как я понимаю востребованная. Но при желании рубится легко. Админам системы ведь никто не мешает констрейн поставить, чтобы дата производства соответствовала системной дате сервака плюс/минус какой-то часовой разброс. Пока - да, можно старые даты. Но вот что будет потом - никто не знает.

(0) именно на семерке? Так вообще я пробовал. Работает.

(40) Не нужен никакой ветврач. Ветврачи на молзаводе нонсенс. Кто-то не разобрался как должна работать система

(44) Костыли-косытли-костыли, как будут крупные организации работать - ума не приложу, Меркурий: часто долго обрабатывает заявки, блокирует остатки (т.е. по одной партии не отгрузите одновременно товар двумя ТТН) - выдаст ошибку.
Также бывают случаи что есть остатки по продукции, но он запись гасит и все - приплыли (производство с высокой прослеживаемостью не отправить толком, например был 1л молока, списали в производство 0.5л, потом 0.4л и еще 0.09л и все, запись периодически блокируется и пишет остаток - 0л).

(45) ппц. это как? сейчас будем оценивать как у нас.. но у нас в основном одна большая входная партия, которую мы продаем-продаем сотнями документов в ночь собираем по штучкам.. Пришло 20 больших партий, а мы дальше магазам нарезаем хохландов по 3 штучки каждого вида и так 300 документов. с ЕГАИС вроде работает, а тут если еще будет затык.. и ночью некому разруливать что там за отлупы (

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

(45) А высокой прослеживаемости в молочке не может быть по определению.
(46) А кто требует бумажные ВСД?

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

(48) А можно как-то раскрыть вашу мысль? Я утверждаю, что для молочной промышленности построение системы с высокой прослеживаемостью невозможна. Могу это показать на примере. Если у вас иное мнение- расскажите как можно это сделать. Потом поговорим про широту и узость. Ок?

(49) Высокую для молочки - не могу сказать как на практике.

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

(высокая прослеживаемость):
1. списание молока (партия 1), производство творога (полуфабрикат); ок
2. транспортная ВСД творога (полуфабрикат) без смены владельца;
3. списание творога (полуфабрикат), списание молока (партия 1), производство сыров (готовая продукция); ошибка

На шаге 3 ошибка списания 0.01л молока.

(низкая прослеживаемость):
1. списание молока (партия 1), производство сыров (готовая продукция); ок
2. списание молока (партия 1), производство творога (готовая продукция); ошибка

На шаге 2 ошибка списания 0.01л молока.

Отгрузка готовой продукции (всего по всем записям 5кг сыров, 6кг творога числятся остатками):
1. транспортная ВСД (сыры 5 кг); ок
2. транспортная ВСД (творог 2.99кг - партия 1 и 0.01кг - партия 2); ок
3. транспортная ВСД (творог 0.01кг - партия 1 и творог 2.99 кг - партия 3); ошибка

На 3 шаге ошибка списания 0.01кг творога.

(50) Спасибо за развернутый ответ.
Источником молока является корова, не так ли? Сырье поступает от хозяйства с ветсертификатом(что имеет смысл). Сырье поступает различными обьемами, от одного бидона, до Камаза. Имеет ли возможность молочный завод отдельно хранить и перерабатывать сырье каждого из сдатчиков или это сырье сливается в общие хранилища, где проходят первичную переработку? Если в танке сырье от 10-20 хозяйств, то чей ветсертификат я буду отслеживать?

(51) С этим согласен, что идея Меркурия в этой части - утопия.
У вас, как у разработчика коробки, завязаны руки: списать сырье без привязки к полуфабрикатам или готовой продукции по-хорошему нельзя, это идет в разрез с позицией Россельхознадзора.

По поводу чей сертификат использовать, то мне видится два решения: объединять записи, либо делать производством одну партию полуфабриката из танка (сырье - все слитые ВСД между помывками).

(44) У меня информация,  что оформить выпуск продукции молочной можно без вет. врача.  А вот ВСД для перевозки без вет. врача с 1.01.18 оформить будет нельзя.

(52) То есть полная прослеживаемость для молочки- это утопия. Что и требовалось доказать. Вообще говоря, не только для молочки.
Не может быть общих сертификатов на танк.
Вы из Мск? Фирма на 4 буквы?

(54)  Да на мясике то же самое. Никто не будет делать замес на треть чебурашки потому что партия свинины закончилась. Будут дополнять мясом с других партий сырья.

с внутренними продажами ктото уже завязался?

(54) Да из Мск, нет не 4. Но я понял кого вы имеете ввиду :)

(44) Это проблема производителей молока- колхозников. По умолчанию в штате у них должен быть ветврач. Для молочных заводов неактуально

(58) к (53)

таки шо вы про это думаете?

https://www.esphere.ru/press/mercury-perenos-srokov

(60)Когда я увижу официальное решение, тогда будем думать

http://www.dairynews.ru/news/gosduma-mozhet-rassmotret-izmenenie-trebovaniy-min.html

Но пока никаких изменений нет

а какова схема работы ветврачей (и аттестованных спецов, которых пока пока факту нет?) в учетной системе ХСа? типа накладную собрали, партии определились, эВСД выпустили(в каком виде?) чтобы ветврач ее утвердил, мы должны как-то получить инфу что ветврачом подписана и тогда сослаться уже на этот эВСД ?

а в терминах заявок Ветис.API как это формулируется? что такое ХС оформляет заявку (которую они видят в своём Меркурии и могут нажать кнопку "оформить"), если есть только операция "оформление транспортной партии" ?

(64)Позиция ветврача для кого? Колхозника? Переработчика?

(64) мы просто торгаши ) - дистрибуторы.
получаем (покупаем) мед например в банках, или супы куриные. (а это все в 648 и 647 приказе соответственно)

или я опять не понимаю ни хрена, и тВСД даже и на эти коды ТН ВЭД из приказов 647 и 648 оформляют просто уполномоченные лица ХС ?

http://www.dairynews.ru/news/rosselkhoznadzor-prinyato-reshenie-o-perenose-obya.html

Ну слух давно ходил,  что поступят как с онлайн-кассами.  Тех кто не подготовился полгода штрафовать не будут.  Теперь официально продлили срок перехода до 01.07.

Неужто этот Новый Год придется встречать не на заводе, а дома.  )

(69) По большому счету это решение ничего не меняет. Нужно вести партионный учет с НГ

(70) Где связь? Партионку можно вводить с любого месяца.

(71) Если это элементарно, то удач

(72)  По сложности внедрения партионка с января и партионка с марта ничем не отличаются.   Кроме писков об убитых отпусках/выходных от сотрудников в первом варианте.

От куда информация о продлении срока до 01.07? и какого года?

(74) см(68)

Больше походит на желтопрессные вбросы.

"Официально мы об этом не объявляли. Однако в целом информация соответствует действительности", - сказал Николай Власов, комментируя сообщение на сайте системы Ветис -- а шойта за сайт такой? и почему отсутствует ссылка?

(77) https://vetrf.ru/ Но там никаких таких сообщений нет. А вот часы судного дня тикают.

(73) Как обоснуешь переход со средней на фифо в течении налогового года?

(79) требования законодательства.
не?

(79) Фифо не нужно. Нужен партионный учет

(79) Каким боком вет.сертификаты влияют на налоговый учет?

(66) Власов "обещал" что вся продуктовая розница (ассортимент ритейла) будет выведена из этих приказов. В том числе и мёд.

(83) т.е. все должно пойти по 646му приказу? они новый приказ что-ли выпустят.

(81)(82) Потому что самый простой вариант "нарисовать" партионный учет является как раз принцип фифо

(85) Соглашусь

(85) (86) Никому в вет.справках ваш ФИФО не нужен. И сейчас сверяют дату выработки в ветсправке и на маркировке.
Это не "простой вариант", а "нерабочий вариант".

(84) Будут внесены изменения в списки. Каким образом это будет оформлено - не так уж и важно. Важно что он сказал , что ритейлу и опту их обслуживающему не нужно беспокоится, и всё смогут выписывать штатные сотрудники.

(79) Никаких переходов на ФИФО для партионки не требуется.  Принцип ФИФО вообще никак не связан с учетом по партиям. Более того в отгрузке скоропорта используют принцип ФЕФО, а не ФИФО. Я могу отгрузить более свежую продукцию раньше чем более старую. Потому что свежая поедет в какую нить сетку, а вчерашняя в какой нить киоск на рынке.   А в налоговом учете все будет продолжать списываться по средней.

(85) Ну так рисуйте его в упр. учете, а бухгалтерский не трогайте.

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

GetStockEntryListOperation - по сути вернет все поставленные на баланс входящие ВСД с количествами принятыми изначально?
А как понять каков актуальный остаток?

и еще вопрос - как вы предпочли сделать систему классификаторов продукции - один иерархический справочник или 4 разных для каждого уровня детализации продукции?

(91) GetStockEntryList возвращает актуальные остатки на конец,  т.е. входящие партии за минусом расхода. Проблема в том что он вообще не фильтруется, т.е. вываливает все партии по всей номенклатуре. Причем в версии 1 даже обнуленные возвращает зачем-то.

+ (91) если интересны движения, то разумнее юзать GetStockEntryListChanges или как-то так. Собственно, там всего две операции по работе с партиями, так что не запутаешься :)

(93) ну нам думаю достаточно будет появившегося в 2 фильтра по непустым.  конце концов ЕГАИС тоже выдает полные остатки - у нас не так много надеюсь будет. (для производителей и у кого много партий наверное своя специфика).

а что может значить такая ошибка, при попытке импортировать wsdl (хочу через WS-ссылки обращаться к web сервису меркурия)

api.vetrf.ru/schema/platform/services/2.0-RC-last/ams-mercury-g2b.service_v2.0_pilot.wsdl


набор схем не может содержать схемы с одинаковыми целевыми пространствами

(44) я те за молочку так скажу. Не все так однозначно %) мелкие заводы региональные забили на меркурий . один директор сказал так - я посажу на выдаче ветврача. он будет штамповать живые бумажки. Это вполне в рамках закона. Это ему дешевле сделать чем все это мутить

Ксатти. ходят слухи и одному моему товарищу некая фирма реализует возможность импорта в меркурий который стоит их локально софт через дбфки все накладные входящие.

коллеги, помогите ))
что может быть:
1. получая в 1с с помощью xdto пакетов объект XDTO который содержит в себе SAOP пакет. Преобразовав его в xml (для последующей отправки в HTTP запросе) получаею такой:


    <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">;  
        <Body>  
            <submitApplicationRequest xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">;  
                <apiKey>***</apiKey>  
                <application xmlns="http://api.vetrf.ru/schema/cdm/application">;  
                    <serviceId>mercury-g2b.service:2.0</serviceId>  
                    <issuerId>1ef8e97f-23f5-4496-a7c0-76a775a4147d</issuerId>  
                    <issueDate>2017-10-02T15:18:31</issueDate>  
                    <data>  
                        <getVetDocumentListRequest xmlns="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">;  
                            <localTransactionId>a9046578-7c02-44d6-93cf-26ca4d5c6b6b</localTransactionId>  
                            <initiator xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">;  
                                <d7p1:login>***</d7p1:login>  
                            </initiator>  
                            <listOptions xmlns="http://api.vetrf.ru/schema/cdm/base"/>;  
                            <vetDocumentType xmlns="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">INCOMING</vetDocumentType>;  
                            <vetDocumentStatus xmlns="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">CONFIRMED</vetDocumentStatus>;  
                            <enterpriseGuid xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">452ff3be-bdda-44f5-853e-35cc0f5e03c8</enterpriseGuid>;  
                        </getVetDocumentListRequest>  
                    </data>  
                </application>  
            </submitApplicationRequest>  
        </Body>  
    </Envelope>  



когда отправляю его в SOAP GUI (в https://api2.vetrf.ru:8002/platform/services/2.0/ApplicationManagementService) то сервер принимает заявку, выдает ИД и поэтому ИД получаю список ВСД!

когда это же тело запроса отправляю из 1С:


    Соединение = Новый HTTPСоединение("api2.vetrf.ru", 8002, ПараметрыПодключения.Логин, ПараметрыПодключения.Пароль,,, Новый ЗащищенноеСоединениеOpenSSL);  
    Запрос     = Новый HTTPЗапрос("/platform/services/2.0/ApplicationManagementService");        
    Запрос.УстановитьТелоИзСтроки(ТелоЗапроса);  
          
    Ответ = Соединение.ОтправитьДляОбработки(Запрос);  



тоже сервер принимает, выдает ИД, но при при получении ответа по этому ИД


    <apl:error code="APLM0002" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported application data format</apl:error>  



я уже не знаю что думать.. Как так может быть - один и тот же текст запроса из SOAP GUI норм, из 1С не норм..

"При получении ответа по этому ИД" - это уже вторая заявка? По каждой ветке что-то вытягиваете? Вот этот запрос давайте сюда. Он у вас и сбоит.

Обычно эта ошибка возникает в случае, когда ид (guid,uuid и т.д.) оказывается не в том неймспейсе, в котором его ожидает получить их система. Ставьте себе Фидлер и внимательно сравнивайте ваши запросы с примерами на help.vetrf.ru, особое внимание уделяйте неймспейсам гуидов в каждом конкретном случае.

(100) с запросом на получение результат заявки все ок - потому что я смотрю ответ из SOAP UI.
т.е. одним и тем же запросом receiveApplicationResultRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions">;
   <soapenv:Header/>
   <soapenv:Body>
      <ws:receiveApplicationResultRequest>
         <ws:apiKey>MzYxMzVmNmYtYzE0Mi00NTA3LTliYzMtYTliOWVmZWVmNzI0M***</ws:apiKey>
         <ws:issuerId>1ef8e97f-23f5-4496-a7c0-76a775a4147d</ws:issuerId>
         <ws:applicationId>47624ac6-be6d-4d11-95cc-39a49b4c7821</ws:applicationId>
      </ws:receiveApplicationResultRequest>
   </soapenv:Body>
</soapenv:Envelope>

я получаю результат операций
1. которую отправил через SOAP UI - получаю список ветдоков.
2. которую отправил из 1С запросом (как в (99)) - получаю ответ, что в этом запросе был Unsupported application data format

и сами понимаете пространства имен в тегах те же самые, Потому что я из отладчика 1С скопипастил текст запроса и его же отправил на тот же сервер через SOAP UI.

префиксы расставлены самим 1Сом исходя из пакетов XDTO, т.е. там ошибки вроде не может быть (да и если бы бы была, то не проходило бы и через SOAP UI). Т.е. подозреваю что как-то иначе сам http запрос делается, где-то какая-то особенность у 1С есть, но не пойму куда копать

(102) так поставьте фиддлер и посмотрите что именно уходит из 1С. Зачем вам соап уи, если вы в конечном итоге работать будете не из соап уи?

"и сами понимаете пространства имен в тегах те же самые" -- почему вы так в этом уверены?

(104) ну потому что текст xml один и тот же. не думаю что при копи-пасте подменяются пространства имен )
фиддлер щаз скачаю, попробую (никогда не пользовался, вообще мало приходилось с http работать)

там нетрудно. Нужно только ему сказать чтобы HTTPS обрабатывал  и все. При копипасте не меняется, а вот что за пакет 1С выдает на сервис - я бы посмотрел. С борландом и его реализацией SOAP вопросов было ну очень прилично.

фиддлер показал вот так:

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">;
    <Body>
        <submitApplicationRequest xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">;
            <apiKey>****</apiKey>
            <application xmlns="http://api.vetrf.ru/schema/cdm/application">;
                <serviceId>mercury-g2b.service:2.0</serviceId>
                <issuerId>1ef8e97f-23f5-4496-a7c0-76a775a4147d</issuerId>
                <issueDate>2017-10-03T12:34:25</issueDate>
                <data>
                    <getVetDocumentListRequest xmlns="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">;
                        <localTransactionId>b6a8b08b-52ce-4450-a9e8-e6965aa790df</localTransactionId>
                        <initiator xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">;
                            <d7p1:login>nerov_mj_170813</d7p1:login>
                        </initiator>
                        <listOptions xmlns="http://api.vetrf.ru/schema/cdm/base"/>;
                        <vetDocumentType xmlns="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">OUTGOING</vetDocumentType>;
                        <vetDocumentStatus xmlns="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">CONFIRMED</vetDocumentStatus>;
                        <enterpriseGuid xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">452ff3be-bdda-44f5-853e-35cc0f5e03c8</enterpriseGuid>;
                    </getVetDocumentListRequest>
                </data>
            </application>
        </submitApplicationRequest>
    </Body>
</Envelope>

сейчас буду сравнивать ))

тю. заработало.
они чото подкрутили чтоли(( не могло же заработать только потому что фиддлер поставил )

могли и подкрутить, потому как v2, кажется, до сих пор в статусе беты

но све равно странно почему через SOAP UI прошло а через 1с нет.

UI юзаю, т.к. удобно им получать эталонный работающий пример.
в 1с приходится изгалятся собираю пакет из xdto пакетов

Эх жаль идентификаторы ссылок нельзя получить в запросе. Аж интересно, почему?

с этими всеми guid, uuid логично ссылки создавать сразу по этим guid но неудобно визуализировать и получать.

(111) ну... так соап сделан, что тебе надо, то и тянешь явно. В принципе, это обычное "традиционное" программирование, а не как в 1с, где "через точку" можно черт-те куда забраться...

(111) я сейчас не про меркурий, а уже про загруженные объекты из меркурия.
сделал, чтобы все классификаторы-документы создавались с ссылками, у которых уникальные идентификаторы (1с-ные) раны guid. Соответственно встроенным языком всегда по guid легко получить ссылку и работать. Но вывести на формы (особенно управляемые) непросто (и все равно поиска по ним не будет) т.к. в запросе (1С ном) к им не обратиться.
Разве что создавать строковый реквизит в котором дублировать содержимое идентификатора ссылки.

(113) было к (112)
так и не пойму, почему платформа не позволяет в запросе добраться до идентификатора ссылки. (в данных то это такая же колонка как и реквизиты).

А, речь про функционал платформы при работе со ссылками... Тогда не знаю.

тут такая тишина, давайте оживим ))

подскажите по оформлению транспортной партии (PrepareOutgoingConsignmentOperation )

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


<apl:error code="MERC02469" qualifier="CSNT_34353939343833343439353135343636" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">;Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение).</apl:error>
[/code]как-то неконкретно. что такого я еще должен указать ) ?? куда бы копнуть.

рискну процитировать всю delivery:
[code]
                  <v2:delivery>
                     <v21:deliveryDate>2017-10-20T15:10:00</v21:deliveryDate>
                     <v21:consignor>
                        <v22:businessEntity>
                           <base:guid>1ef8e97f-23f5-4496-a7c0-76a775a4147d</base:guid>
                        </v22:businessEntity>
                        <v22:enterprise>
                           <base:guid>452ff3be-bdda-44f5-853e-35cc0f5e03c8</base:guid>
                        </v22:enterprise>
                        <v22:globalID>4607810709992</v22:globalID>
                     </v21:consignor>
                     <v21:consignee>
                        <v22:businessEntity>
                           <base:guid>108a8401-25f0-4828-98b1-4ef1e8f10718</base:guid>
                        </v22:businessEntity>
                        <v22:enterprise>
                           <base:guid>f197f446-6247-469b-827d-3d6fa34fe053</base:guid>
                        </v22:enterprise>
                     </v21:consignee>
                     <!--Zero or more repetitions:-->
                     <v21:consignment>
                        <v21:volume>1.12</v21:volume>
                        <!--Optional:-->
                        <v21:unit>
                           <base:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</base:guid>
                        </v21:unit>
                        <v21:sourceStockEntry>
                           <base:guid>b0e39e4a-ab96-40d5-9557-bd8f83ffa54c</base:guid>
                        </v21:sourceStockEntry>
                     </v21:consignment>
                     <v21:transportInfo>
                        <v21:transportType>1</v21:transportType>
                        <v21:transportNumber>
                           <v21:vehicleNumber>o001oo161</v21:vehicleNumber>
                        </v21:transportNumber>
                     </v21:transportInfo>
                     <v21:transportStorageType>CHILLED</v21:transportStorageType>
                     <v21:accompanyingForms>
                        <!--Optional:
                        <v21:waybill for="?" qualifier="?">
                           <v21:issueNumber>?</v21:issueNumber>
                           <v21:issueDate>?</v21:issueDate>
                           <v21:type>?</v21:type>
                    </v21:waybill>-->
                        <!--Zero or more repetitions:-->
                        <v21:vetCertificate>
                           <v21:authentication>
                              <!--Optional:-->
                              <v21:purpose>
                                 <base:guid>96de622d-2cb2-424a-888b-7ced5225ce17</base:guid>
                              </v21:purpose>
                              <!--
                              <v21:cargoInspected>false</v21:cargoInspected>
                              -->
                              <v21:cargoExpertized>UNFULFILLED</v21:cargoExpertized>
                              <v21:locationProsperity>Местность благополучна.</v21:locationProsperity>

                           </v21:authentication>
                        </v21:vetCertificate>
                     </v21:accompanyingForms>
                  </v2:delivery>

Ща сравню со своим...

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

Вы уверены что transportNumber не надо указывать? Мы туда обычно пихаем "реф.", типа, рефрижератор, если не знаем номер на момент выписки. Чего-то пихнуть надо, кажется, оно на пустоту проверяет

да и данные отгрузочного документа (Waybill) мы обычно даем

Кстати, хотел посоветоваться. Народ, кто как с партиями работает? Вы их укрупняете за несколько дней или проводите отдельно каждый день, когда есть выпуск? Во втором случае, есть опасения, объем очень быстро станет настолько большим, что любое восстановление локального регистра по данным Меркурия станет нереальным. Еще я столкнулся с тем, что некоторые сети, в частности Магнит, не желают наблюдать в ВСД несколько одинаковых номенклатур с разными датами выпуска - требуют, мол, объединяйте и ставьте дату выпуска от... до...! Возникает вопрос - кто как решает эту тему?

(121) Как можно укрупнять? Там же дата выработки, сроки. Каждая выработка должна быть показана.

(122) ну вот так, запросто. Позвонили с РЦ магнитовского и сказали - а чего это у вас колбаса с датой изготовления 19.10 и 20.10 разными позициями? Делайте одну позицию, где указана первая дата 19.10, а вторая - 20.10.

на самом деле, если у вас срок хранения 45 или 60 дней, а "разбег" периода 4 дня, то думаю, страшного в этом ничего нет. Молочка другое дело, там сроки маленькие. Но, как бы, могу вам на своем опыте сказать, что вопросы уже возникают как в (123). Информация к размышлению.

(123) Все правильно и сказали. Номенклатура одна, а партии разные. Такие вольности со сроками годности-это ваши риски.

(125) Ерунда какая-то. Какие риски, вы о чем? Я могу вообще выпускать одну и ту же колбасу каждый день в течение года, и по-вашему, мне нужно ее всю оприходовать одной партией 31 декабря?

Есть две партии одной продукции. Они выпущены в разные дни, на них разные производственные ВСД. На каком основании от меня требуют их объединять - мне, сказать честно, непонятно. Как я понимаю, на основании желания левой пятки их ветврача...

(126) Кто сказал, что требуют обьединять. Наоборот, вы должны каждый выпуск колбасы делать по отдельному ВСД. Выпустили- запросили у меркурия производственный сертификат, отгрузку делаете- указываете разные сертификаты на одноименную колбасу, выработанную в разные дни.
Про риски. В перспективе г-н Власов мечтает, что любой покупатель со смартфоном сможет в любой торговой точке проверить когда, кем и по какому ВСД была выпущена колбаса(молоко, селедка)

(128) Может, я непонятно объяснил... Еще раз. Я сделал отгрузку в соответствии с производственными партиями. Две партии одного изделия с разными датами производства. Это реально разные даты производства и производственные ВСД разные. Мне позвонил представитель торговой сети и сказал что им так не нравится. Должна быть отгрузка с одной объединенной партии, у которой указана начальная и конечная дата производства. И еще присовокупили, что в следующий раз не примут, если не будем делать так как они хотят. Теперь понятнее?
>> Кто сказал, что требуют обьединять.
Сеть и потребовала.

(128) >> В перспективе г-н Власов мечтает, что любой покупатель со смартфоном сможет в любой торговой точке проверить когда, кем и по какому ВСД была выпущена колбаса(молоко, селедка)

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

(129) А если вам некто Иванов позвонит и скажет хочу чтобы  завтрашним днем производства?

То что сети требуют это не значит что так правильно. Напрягайте своих юристов, они не должны есть хлеб зря.

(129) Из вашего сообщения я понял, что вы делаете под каждую партию новую номенклатуру. Если вы так не делаете, а делаете 2 позиции с одинаковой номенклатурой, но разными ВСД, то вы правы на 200%

(133) нет, конечно. Номенклатура одна, UUID у нее один, но разные производственные партии.

(134) Тогда сетевики не правы.

мило-мило
http://help.vetrf.ru/wiki/Ветис.API#.D0.9F.D1.80.D0.B5.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B4.D0.BE.D1.81.D1.82.D1.83.D0.BF.D0.B0

особенно доставляет:
Регистрация может быть аннулирована в следующих случаях.

    Если общее количество любых ошибок при выполнении бизнес-операций в продуктивной версии Ветис.API превысило 10% от общего количества запросов этого типа за сутки. В этом случае организации или учреждению, ответственному за оформление запросов к шлюзу, выносится предупреждение. Если ошибки не устранены в течение 5 рабочих дней, производится отключение программной системы от продуктивной версии Ветис.API на срок не менее 1 месяца и до устранения ошибок. В этот период учреждению или организации доступна только тестовая версия Ветис.API.

ну правда хоть 5 дней дают...

http://help.vetrf.ru/images/b/bc/Ecr.pdf
вроде бы прояснили ситуацию с возвратами. посмотрим как это будет за пределами сроков годности по факту.
в "инвентаризации" появился момент про "оприходование". будем посмотреть по факту.