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

Николай Власов wrote:Тут все просто. Дата перемещения (если указывается в документе данного типа) должна быть одинаковой. Дата оформления может быть разной.

Вот тут еще больше запутали. Еще раз, кратко: клиент работает почти 24/7, товарная накладная, по которой будет идти прием товара у покупателя, выписывается числом = дате фактической отгрузки. Меркурий, при загрузке ВСД ставит дату = дате загрузки в систему этого ВСД. И это время МОСКОВСКОЕ! В итоге, при выгрузке ВСД ночью, когда машина собрана, веса откорректированы, мы попадаем на разность дат. Т.к. накладная датируется допустим 3м числом, машину грузили 3го в 2.00 ночи, а в Москве ещё 2е 19.00

Как итог получаем ВСД N555 от 02.12.17 а у нее в графе ТТН: ТТН #444 от 03.12.17.

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

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

молочники пока к нам не обращались по меркурию, а вот рыбников и мясняков уже прилично было с вопросом, а внедрите нам. Оно и понятно, у молочников тут ассортимент и клиентские базы небольшие и список сертифицируемой продукции не велик, другое дело рыба и мясо. А на Дальнем Востоке еще и импортной продукции много, порты морские рядом, вообще доля привозной огромная, в том числе и РФ и Беларусь, рыба только по большей части местная и Китай, Корея, Япония. И у всех мясников и рыбников есть специфика плавающего веса в таре. Когда два клиента заказали по две коробки, нельзя ответить на вопрос сколько КГ продукции получит каждый, это вы узнаете только после того как склад этот заказ клиентам собирет. Т.к. одна коробка может весить 10,5 вторая той же продукции 9,5, в итоге пол кило туда, пол кило сюда, при заявке можем только сказать средний вес, а когда груз собран, то этот разбег от среднего в рамках заказа выходит на десятки, а то и сотни кило.
И вот тут то и встает вопрос с поточностью и вот это как раз та загвоздка почему на Дальнем Востоке у Вас проблема с внедрением Меркурия, почему так ему противятся. Контроль остатков с невозможностью откорректировать вес после выписки ВСД, как итог чтобы это обеспечить на данный момент необходимы штатные вет врачи, а то и несколько! Которые будут заниматься отправкой ВСД ночью, когда машина набрана и мы знаем точный вес до грамульки, по каждой реализации, по каждой позиции. Пока не принят закон о сертификации неветврачей для выписки ВСД, такое удовольствие не всем по карману и гдеж их столько набрать, вет врачей. Вот и получается, что некоторые объявляют байкот до 2018го.
Не совсем понятна вышеприведенная Ваша фраза. Что Вы понимаете под Пора кончать с многопоточность? Перестать отгружать продукцию ночью? Но ведь все хотят прийдя в магазин, засунуть руку в полку подальше и достать сосиски посвежее, в т.ч. и Ваша жена

а для этого магазин должен утром получать свежую продукцию, а уехать она должна со склада ночью и чем меньше машины будут стоять у рампы, из-за бюрократии, тем качественнее и свежее будет продукция на полках.
С бардаком в их организации пора прощаться. Что имеется в виду под этой фразой? Мое мнение как человека который не занимается торговлей поднадзорной продукцией, а является ее потребителем: вет ВРАЧЕЙ, да простят они меня, превратили в канцелярских крыс, их обязали в течении суток выписать ВСД. И стоят они перед выбором, оформить бланк другой или прогуляться по холодильникам и потратить время на проверку качества продукции, чистоту и температурные режимы. Но нет у них у многих на эти вещи толком времени, сидят и боятся по шее получить за то, что кому-то не успеют ВСД оформить, накатают на них кляузу, оштрафуют или депремируют. Приходишь в магазин и думаешь, чтож взять с прилавка, куда протянуть руку, чтоб не протянуть ноги. ВСД хоть на цветном бланке, хоть электронная увы не панацея, пока не прекратится вся эта бюрократия и ветврачи не займутся делом.
Прошу так же пояснить про

Вет врач не должен контролировать отгрузку Готовой продукции произведенной из сертифицированного сырья

вот тут поподробнее. Не молоко, рыба и мясо! Охлажденка и заморозка, отгрузки в магазины и т.п. товар упакован и вариант неупакован, туши. Упаковка в виде коробки, упаковка в виде пакеты внутри коробки. Весь товар рассматриваем с точки зрения, что он из холодильников в авторефрижератор грузится. Какова роль вет врача в процессе отгрузки того или иного товара, кроме досмотра пришедшего авто?

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

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

nat163rus wrote:Вы копнули очень глубоко....своими вопросами.
Вчера был семинар в Москве, а для удаленных включили он лайн вебинар. Вот Вам бы туда свои вопросы задать

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

nat163rus wrote:Разработчики 1с предложили пакет интеграции 1с с Ветис API

Разработчики пока только мышкой по экрану поводили, оценивать их ПО слишком рано, слишком мало информации. Наша фирма неделю назад заказала NFR их продукта, я из франча, придет буду лично смотреть их ПО и чувствую, что не один день мы с ними еще проведём на скайпе и в переписках по доработкам.

Пол года назад мы взялись уже запускать клиента, точнее я взялась, клиент со сложным учетом, большой ассортимент в т.ч. импортная продукция, большая клиентская база в т.ч. междугородние перевозки. Обычно любой проект берется с клиента поменьше и попроще, но тут критерий выбора был желание клиента, первые вопросы про меркурий были еще в 2015м, а второй момент, порядок в учете, там уже учет по коробкам ведется много лет и партионка отслеживается и сроки и инфа по веткам. Плюс ветврачи штатные. Я с пол года регулярно мониторила этот форум и сайты в поисках интеграционгых ПО, уже даже была мысль самим писать, но с тех документацией тогда разобраться не смогли и свободних кадров на проект не было для собственной разработки. Как только первый продукт появился схватились ща него. В итоге пол года допила конфы, переговоров с разработчиками (там было всё и ругались и смеялись), как итог мы недели три как получили более менее нормальную конфу для работы с Меркурием, когда действительно красота и то для красоты там огромное количество сервисных примочек было мной написано, если взять даже нынешний продукт из коробки который мы запускаем, то у другого подобного клиента без этих примочек вет врач будет долго щелкать кнопки для сопоставления НСИ и прочей канетели, купить и поставить пока увы не получится, надо граммотного программиста, который будет допиливать под базу клиента. Но и по сервисам разработчик тоже не успевает, т.к. мы просто корректной работы выгрузки добивались долго. Просто мы столкнулись с тем, что часть документированных методов для работы со шлюзом, в тестовой базе отработали, а в рабочей встали колом из-за некорректности самих данных в меркурии. Добиться исправления данных в базе ни мы ни разработчики интеграционного ПО не смогли, как итог разработчики писали какие-то собственные вэб-сервисы (точно не уверена) чтобы 1С смогла принять некорректные данные. Некорректность иногда заключалась в элементарном несоответствии длинны поля, лимит допустим 100 символов, а реально в базе меркурия их 200 и все и система ложится на загрузке таких данных и стопорит загрузку остальных нормальных записей. Мы копию реальной базы прогоняли через тестовый шлюз два месяца, а потом в сентябре колом встали при запуске на рабочем шлюзе. Боюсь у разработчиков 1с:Управление ветеринарными свидетельствами еще все впереди

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

Но в любом случае работа ведется, тех поддержка помогала всем чем могла, результат мы получили. На сегодняшний день проект запущен в части прихода, инвентаризаций и производства, единственное застопорились на организационном моменте с датами всд и ттн, но технически все прогружается без особых проблем, надеемся в понедельник полетят в рабочий меркурий первые отгрузки. (PS: Прошу прощение за опечатки, пишу с планшета).

Николай Анатольевич, прошу дать разъяснение по указанию дат в ВСД и в отгрузочных документах.
Я не вет. врач, я программист, в нашу компанию обращаются ряд фирм с просьбой интеграции их систем с Меркурием и у нас есть ряд вопросов с методологией, это один из них.
Допустимо ли разночтение в датах самого ветеринарного свидетельства и в дате товарной накладной, счет-фактуре, ТТН? Например: ВСД №4444 от 12.12.2016 (в графе Отправитель будет указано: ООО "Оптовик", ИНН:ххххххх, ТТН: №12345 от 13.12.2016 г.)?
Пытались общаться по данному вопросу с несколькими вет. врачами, логистами и разработчиками как интеграционных продуктов, так и самого Меркурия, с коллегами внедренцами, но четкого ответа так и не получили, мнения разошлись. Кто говорит, что однозначно расхождения не допустимо, кто говорит что плохо, но в принципе, в рамках 12 часов вполне возможно, кто вообще пожимает плечами.

Перечитала Приказ 281, там по датам ни слова, единственное что есть по срокам, это 4й пункт

"Ветеринарные сертификаты оформляются и выдаются в течении одного рабочего дня при отсутствии необходимости проведения лабораторных исследований...",

но это на сколько я понимаю означает, что ХС дает заявку на оформление ВСД и в течении дня вет. врач обязан его оформить.

Методические указания о порядке проведения инспекций боенских и мясоперерабатывающих предприятий на соответствие единым ветеринарно-санитарным требованиям РФ и Республики Беларусь от 22.09.2009 г
XVIII раздел пункт 3

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

Продукция уходи на склад филиала, в торг точки или другим конечным потребителям и не в вагонах, а в авторефрижераторах, погрузка на территории предприятия, а не на станции, про это ни слова. Опять же не ясно как трактовать "Удостоверение качества...", это все же отдельный документ или ВСД в том числе?
ПРАВИЛА ВЕТЕРИНАРНОГО ОСМОТРА УБОЙНЫХ ЖИВОТНЫХ И ВЕТЕРИНАРНО-САНИТАРНОЙ ЭКСПЕРТИЗЫ МЯСА И МЯСНЫХ ПРОДУКТОВ
7. ВЕТЕРИНАРНО-САНИТАРНАЯ ЭКСПЕРТИЗА И ВЕТЕРИНАРНЫЙ КОНТРОЛЬ МЯСА И МЯСОПРОДУКТОВ НА ХОЛОДИЛЬНИКАХ

7.13. Подготовку мяса и сырых мясопродуктов на мясоперерабатывающих предприятиях или на холодильниках к транспортировке его железнодорожным, водным, автомобильным и другими видами транспорта, а также контроль в процессе транспортировки осуществляют в порядке, предусмотренном действующими правилами перевозок указанных видов грузов железнодорожным, водным или автомобильным транспортом.
Перед погрузкой мясопродукты должны быть осмотрены ветврачом с целью определения их качественного состояния и пригодности к транспортировке. Все данные о их состоянии должны быть записаны в удостоверении о качестве установленной формы.
Мясо, предназначенное для промышленной переработки, принимают к перевозкам при условии обязательной записи в удостоверении о качестве об обнаруженных дефектах.
7.14. На каждую отправляемую партию мяса и сырых мясных продуктов ветеринарный врач холодильника выдает ветеринарное свидетельство в установленном порядке.

Николай Власов wrote:Работа через API-интерфейс позволяет работать многократно быстрее, многократно дешевле, точнее и качественней, и освобождает врача от обезьяньей работы, оставляя его рабочее время для того, что он и должен делать – для контроля безопасности объекта и товаров.

А теперь про обезьянью работу. Некоторые лица утверждают, что даты ВСД должны совпадать с датой ТОРГ-12 и ТТН, что в большинстве случаев при применении Меркурия является утопией. При этом привести ссылки на нормативку не могут, все что нашла я, указано выше. Причем такое требование предъявляют иногда и покупатели, отказываясь брать ВСД с датой отличной от ТОРГ-12 и ТТН. Если эти требования законны, хотелось бы получить ссылку на основания, в противном случае имеем большие проблемы с повсеместным внедрением Меркурия. Т.к. в Меркурии фиксируется и указывается на бланках дата отправки ВСД, произвольное указание невозможно.

Проблема №1
Разность часовых поясов. В электронной ВСД дата ставится в соответствии с датой отправки и ставится она по МОСКОВСКОМУ времени. Таким образом любая ночная или утренняя отгрузка на Дальнем Востоке или вечерняя в Калининграде будет разниться с датой ВСД. Например: для ДВ уже 13е, а в Москве еще 12е. Калининград 12е, а в Москве уже 13е. Подгонять даты накладных под даты ВСД, тоже не вариант, получим бардак на складе, бардак в оперативном и бухгалтерском учете, там и НДС, там и дебиторка и остатки полетят.
Проблема №2
Ночные отгрузки, запрет на въезд большегрузов. Рыбники, молочники и мясники многие грузят продукцию или по ночам или вообще в режиме 24 на 7. В ряде городов Хладокомбинаты расположены в черте города, и в ряде городов существуют запреты на въезд большегрузов в дневные часы. Таким образом иногда загрузка в машины осуществляется после 21-22. Естественно вет врач не полезет в фуру лопатить паллеты и проверять качество и пригодность к транспортировке по каждой накладной, это физически не возможно сделать внутри груженной фуры, если он не Коперфильд или Ванга, проверка товара идет в Наборочной камере, так же идет проверка машины при прибытии ее для погрузки. Что и соответствует вышеприведенным требованиям: ПЕРЕД ПОГРУЗКОЙ мясопродукты должны быть осмотрены ветврачом, но фура уйдет ночью, т.е. дата проверки < дата отправки. Со склада списывать товар заранее не вариант, он списывается в момент окончания погрузки или в процессе. Регламентные бух. документы, отражают факт свершенной хоз. операции, она свершилась ночью. Вот и получаем ВСД 12го, ТТН 13го.
Проблема №3
Ночные отгрузки, скоропорт. Молочка и охлажденка в таких компаниях грузится чуть ли не с колес, летом вообще каждая минута на счету при погрузке и из-за жары в полдень мало кто рискнет грузить. На складах продукцию долго не держат. Пришла, быстро перегрузили в камеры, заявки за день набрали, ночью машины уже уехали, рано утром, а то и в ночь они уже на разгрузке в магазины. Зимой у таких клиентов та же история, если перемерзнет продукция, то тоже на выброс пойдет. На ДВ зимой на улице до -40, про Сибирь вообще молчу. А летом днем до +40. Таким образом опять же вся проверка ПЕРЕД ПОГРУЗКОЙ в Наборочной. Опять расхождения в датах.
Проблема №4
Требования крупных сетей. Головная боль логистов, т.к. сети диктуют время прибытия транспорта на разгрузку, если поставили время в 6 утра, значит машина уедит ночью, не успеет, да еще и скоропорт, на утилизацию уйдет и грузоотправитель уйдет в убытки. Опять разница во времени. Примерно та же ситуация при междугородних перевозках, особенно когда груз еще в порт или на станцию доставляется для дальнейшей транспортировки.
Проблема №5
Дефицит вет. врачей. Вет врач не продавец и не секретарша, на бирже не стоят, профильное высшее образование + сертификат, в штат не каждый то может взять, не то что посменно нескольких на выписку ВСД. Если требования Дата ТТН=Дата ВСД, то по факту любой компании с ночными отгрузками придется каким-то волшебным образом искать вет. врачей, согласных работать по ночам и выполнять по сути обезьянью работу, нажимать в 1С кнопочку отправить ВСД в Меркурий, не в 22.00, а в 01.00. У кого приходящие вет. врачи, там посменку тем более не организуешь, у торговых предприятий в основном приходящие, штатников вижу в основном только у производственников/переработчиков или в очень крупных торговых с большими объемами отгрузок.

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

Прошу дать разъяснение по правилам оформления ВСД и порядку отражения операции перефасовки в Меркурии.
Пример:
Организация ООО "Птицефабрика" поставляет курицу в коробках по 40 кг компании ООО "Оптовик"
Далее ООО "Оптовик" перефасовывает данную продукцию в мелкую тару, допустим упаковки по 2 кг.
На упаковке и в качественном удостоверении указывается Производитель: ООО "Птицефабрика", Упаковщик: ООО "Оптовик".
Далее такая продукция отгружается в розничные точки или другим оптовикам.
Вопрос:
1. Как правильно отразить операцию перефасовки в Меркурии?
2. Как должно быть заполнено ВСД, что должно быть в "Производителе"?

Если оформлять через производство, то в производителе встанет ООО "Оптовик". Добавлять несколько производителей в меркурии для выпускаемой продукции нельзя, нет функционала, список производителей допустим только для чистого вида.

Решение здесь: http://www.fsvps.ru/vetrf-forum/posts/list/705/6855.page#40348

ANIT wrote:На форуме ВЕТИС так ответа и нет, поэтому дублирую вопрос сюда:
при выгрузки хоз-субъекта с ОКОПФ Автономная некоммерческая организация (АНО) с кодом 28001, выдает сообщение "Организационно правовая форма с указанными параметрам не найдена в реестре РСХН"

waterfalls wrote:Так же есть эта проблема, но с ОПФ - сельское потребительское общество
Видимо со всеми нестандартными ОПФ такая проблема.

Ответа так и нет, не дождались помощи, пришлось разгребаться самостоятельно.
waterfalls, если у вас интеграция с 1С:УТ 10.3, то там даже в самых свежих релизах, совсем не первой свежести классификатор. Свежий макет с классификатором, можно выдернуть из УПП 1.3, или как вариант перебить коды в существующем справочнике на актуальные. Для моего примера (АНО) актуальный код 71400.

Сергей, отдаю, безвозвратно, безвозмездно, без обременения. Упоминание обработки не было связано с попыткой обвинить вас в плагиате, а было моей эмоциональной реакцией на последний пост в битриксе по данной теме, а точнее на его формулировку и то как его по итогу приходится трактовать.
Цель этой ветки привлечь внимание разработчиков к возникшей проблеме и решить её. Пока из разработчиков откликнулась только ваша сторона. Обратной связи от разработчиков Меркурия и Ветис.api по данной проблеме на протяжении нескольких дней я так и не увидила, что не добавляет оптимизма. Хотя какой тут к черту оптимизм когда на часах половина третьего ночи.

Сергей, при всем уважении, убедительная просьба внимательно ознакомьтесь с перепиской в битриксе по данной теме.
Что касается самой обработки загрузки иностранных производителей, упомянула я о ней именно из-за позиции "почему вы" (см. Битрткс), а не за тем чтобы вы ее исключали из своего програмного продукта. Если обработку буду переписывать я, то она будет работать. Однако, завтра поменяют формат или добавят реквизит для синхронизации предприятий, и моя обработка окажется нерабочей, а ваша не будет иметь нужного мне функционала, перетянуть новый функционал не смогу из-за закрытости вашего кода. И буду я опять сутками на пролет раскуривать документацию и ночами не спать созваниваясь с вами. Что касается

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

, то позволю себе заметить, что вы выпустили тиражируемый продукт. На сегодняшний день, согласно статистики, интеграционных проектов всеголишь 36, в т.ч. и мой проект числится. Увы сбор статистики ведется на основании выданных доступов к рабочему шлюзу, а не на основании статистики по отправленным заявкам всд. Из этих 36ти в основном птицефабрики. Завтра этот перечень предприятий может существенно расшириться, а реальность такова, что на огромной территории нашей необьятной родины властвуют неблагоприятные климатические условия, и в таких условиях животноводство и с/х штука нерентабельная. А кушать хочется всем и на всех отечественного производителя не хватает. И как говорил великий комбинатор: "заграница нам поможет". Вот и приходится нам воевать с неработающей загрузкой данных по зарубежным предприятиям и с присловутыми ошибками в форматах передачи. Стоит чуть шире смотреть на предметную область, чем большую часть бизнес процессов, ваш програмный продукт сможет автоматизировать, чем продуманнее будут алгоритмы и архитектура вашего программного продукта, тем большую часть рынка вы сможете охватить. Не стоит зацикливаться на одних прицефабриках и фермах. Поэтому не стоит принимать все мои "нам очень надо" в штыки. Есть проблема загрузки через шлюз, это факт. Есть моя переписка с вами, это факт. Есть ваша переписка с меркурием, это факт. Есть недовольство со стороны клиента по срокам внедрения вашего программного продукта, так сказать в продакшн, это факт. Решение вопроса с загрузкой лежит вне зоны моей компетенции или компетенции моего клиента, это тоже факт. Ругаться с вами или со своим клиентом я не желаю. Нужно просто решить проблему. Решать ее должны либо Вы, либо разработчики Меркурия и шлюза Ветис.API. Будут проблемы решены, будет запущен интеграционный проект, будут еще проекты. И клиенту хорошо и нам и вам и Меркурианцам.

SergZh wrote:Т.е., как мы понимаем, обращаться нужно именно к ним.
Поэтому мы предложили пропустить такую площадку при синхронизации.

К кому обращаться? К китайцам? К белорусам? К таможенникам? К министру? Или сразу к президенту?
Что значит Пропустить такую площадку? Вы в своей системе сделали подобный функционал? При том, что часть касающаяся непосредственной синхронизации находится в закрытых модулях! Ах да! Я забыла, что я же вам эти модули собственноручно писала два месяца назад и отсылала чтоб вы включили их в рабочий релиз. И даже если я напишу свою обработку синхронизации и она исключит предприятия с длинным наименованием вида деятельности из списка, простите, а клиенту я должна буду тоже сказать "слушай у тебя там на складе будет лежать пару тонн неучтенного товара, ты его без веток шуруй налево и направо или завод левый в ветке укажи. Ну подумаешь арестуют пару контейнеров в порту за несоответствие маркировки и веток. Производство твое стопорнут. Просто у нас тут траблы с фасетами макслейт по производителям и система сыпится при проверке данных xdto. А так мы убрали эти заводы из списка и ошибок нет, правда и нужных нам заводов нет!"

Опять к вопросу прав доступа. Интегрируем 1С с меркурием. Проблема с отгрузкой и постановкой на учет продукции от/для контрагентов с филиальной структурой.
Пример: Есть воинские части, юридический адрес г.Санкт-Петербург. Т.е. хозсубъект в Питере, соответственно на сколько я понимаю его должно заводить Питерское управление ветеринарии, которое В МЕРКУРИИ НЕ РАБОТАЕТ судя по словам Николая Анатольевича (ответы в вэбенаре). Клиент (которого автоматизируем) отгружает продукцию на воинские части разбросанные по всему дальневосточному округу. При этом нет возможности привязки предприятия расположенного в г. Хабаровск (где поставщик и вет.врач), т.к. хозсубъект в Питере, т.е. привязку должен осуществить опять же Питерское ветуправление.
ОК. Смотрим второй вариант. Контрагент зарегистрирован в городе Хабаровске, при этом имеет точки (пусть будут столовые) расположенные в Хабаровске и в Приморье. Пытаемся привязать Приморское предприятие к Хабаровскому хоз.субъекту и опять сталкиваемся с проблемой, что предприятие не может быть привязано из-за того, что оно находится в ведении другого региона.
Т.е. получается, что даже с воинскими частями и Питерское управление не сможет решить вопрос даже если захочет? Или мы должны плодить кучу Хозсубъектов с "левыми" юридическими адресами, которые на самом деле всего-лишь адреса доставки?
Прошу предоставить разъяснения по работе с хозсубъектами других регионов, куда звонить, кому звонить, кто будет вносить данные в меркурий?

Я не ищу виновных, я ищу ответственных по данному вопросу и жду от них решения вышеописанной проблемы.

На форуме ВЕТИС так ответа и нет, поэтому дублирую вопрос сюда:
при выгрузки хоз-субъекта с ОКОПФ Автономная некоммерческая организация (АНО) с кодом 28001, выдает сообщение "Организационно правовая форма с указанными параметрам не найдена в реестре РСХН"

Так же имеем проблему с загрузкой зарубежных предприятий (производителей), детали в отдельной теме в разделе ВЕТИС. Просьба к тех поддержке ознакомиться с проблемой и решить ее.
http://vetrf.ru/vetrf-forum/posts/list/6993.page

С июля месяца пытаемся запустить у клиента интеграцию с ветис, все сроки по проекту сорваны к чертовой бабушке. С тестовым шлюзом было все ок, с рабочим шоу.
На данный момент одной из причин стопора проекта является проблема с загрузкой информации по зарубежным предприятиям (производителям импортной продукции). Так в частности не можем подгрузить предприятия Белорусских и Китайских производителей. Проблема в длинных наименованиях вида деятельности. Получаем ошибку следующего вида:

{ОбщийМодуль.Vetis_Server.Модуль(4777)}: Ошибка при вызове метода контекста (GetForeignEnterpriseList)
по причине:
Ошибка вызова операции сервиса:  {http://api.vetrf.ru/schema/cdm/registry/service}:EnterpriseServiceBindingQSService:GetForeignEnterpriseList()
по причине:
Неизвестная ошибка. Ошибка проверки данных XDTO:
Значение: 'Убой КРС и свиней, разделка, производство готовой мясной продукции. Производство, хранение, реализация консервно-паштетной продукции. Производство консервированных кормов для непродуктивных животных. Производство мясных полуфабрикатов, производство мясных полуфабрикатов в тесте.' не соответствует простому типу: {http://api.vetrf.ru/schema/cdm/base}String255
[b]Несоответствие фасету MaxLength = '255'[/b]
по причине:
Ошибка проверки данных XDTO:
Значение: 'Убой КРС и свиней, разделка, производство готовой мясной продукции. Производство, хранение, реализация консервно-паштетной продукции. Производство консервированных кормов для непродуктивных животных. Производство мясных полуфабрикатов, производство мясных полуфабрикатов в тесте.' не соответствует простому типу: {http://api.vetrf.ru/schema/cdm/base}String255
Несоответствие фасету MaxLength = '255'

Соответственно оприходовать продукцию в нашей системе с корректным отражением в Меркурии мы не можем. И как следствие не сможем ни продавать, ни перемещать, ни пускать ее в производство.
Проблему выявили 7го СЕНТЯБРЯ, информация была передана разработчикам WIZARD. Они в свою очередь передали информацию на тех. поддержку Ветис.API.
9го сентября пришел ответ Цитирую:

[Поддержка Ветис.API - Поддержка #36637]

Здравствуйте!

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

--
С уважением, Ирина Егорова,

Что имеем в итоге? на сегодняшний день всё без изменений.
Как со всем этим работать, большой вопрос. Сроки выхода следующего релиза шлюза не обозначены. Исправлений пакетов WSDL нет ни от разработчиков Ветис, ни от Визарда. Модули обмена Визарда, закрыты, что не дает мне как разработчику возможности корректировать какие-либо механизмы связанные с обменом, даже если какие-либо свойства открыты для этого, т.к. код с ними связанный я посмотреть или поправить не могу.
На календаре конец сентября!!! Убедительная просьба в кратчайшие сроки разобраться в сложившейся ситуации. Несоответствие размерности данных по факту ведет к сбою, который не позволяет осуществлять работу в системе, и это не должно быть головной болью конечного пользователя или внедренцев. О каком массовом внедрении Меркурия и интеграционных проектах может идти речь, при таком наплевательском отношении со стороны разработчиков?

при выгрузки хоз-субъекта с ОКОПФ Автономная некоммерческая организация (АНО) с кодом 28001, выдает сообщение "Организационно правовая форма с указанными параметрам не найдена в реестре РСХН"

А за что заплатил клиент при переходе на электронные ве. свидетельства, если Меркурий не требует затрат на бланки?

За интеграцию с 1С! Весело и прикольно работать в меркурии через вэб интерфейс когда товарный ассортимент около 10 позиций, какая-нибудь птицефабрика. А когда там ассортимент около 1000 позиций, и весь этот зоопарк с разных стран и разных заводов, да еще и производство и клиентская база около 2500 контрагентов, вот тогда работать через вэб интерфейс становится совсем не весело. Особенно с учетом того, что нужно вести партионный учет всего этого добра в меркурии и контролировать остатки. И тут только один вариант, допил 1Ски, причем не слабый. Даже с учетом что был взят готовый модуль интеграции, три месяца серьезного допила базы для того чтобы с этим было комфортно и быстро пользователям работать. И в итоге проект до сих пор не запущен.