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

nmzn1 wrote:
добрый
самое простое в такой ситуации, аннулировать всд тому кто выписал и перевыписать заново с указанием номеров, имхо

Этого делать не нужно.
Можно внести номера в выписанные ВСД. Это же точка перегрузки.

Вопрос правомерности требований.

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

При этом предоставляет основание ответ на свое обращение в mercury@fsvps.ru.

Дополнительно обращаем внимание на Ваш запрос в адрес mercury@fsvps.ru:
Просьба пояснить, если оформляется Ветеринарное свидетельство. Форма № 2 (мультимодальная перевозка) и товар везется через промежуточную точку (через логистическую компанию), МОЖЕТ ЛИ ЭТА ПРОМЕЖУТОЧНАЯ ТОЧКА сама вносить изменение в ветеринарное свидетельство в графе номер транспортного средства?

Ответ:
Может и должен.

Согласно описанием Меркурия, только оправить и получатель могут вносить изменения в номера ТС в точках перегрузки.

Отправитель и получатель могут вносить сведения о номере нового ТС в процессе перемещения партии через предусмотренные пункты перегрузки. Ответственность за внесение всех номеров ТС лежит на получателе партии продукции.

А также API https://help.vetrf.ru/wiki/UpdateTransportMovementDetailsOperation_v2.0

Вносить сведения о номере транспортного средства в пункте перегрузки может как отправитель, так и получатель партии, при наличии роли позволяющей гасить ВСД

Вопросы:
1) Промежуточный перевозчик уверяет, что не может видеть ВСД и соответственно не может внести в них номера авто. Это дествительно так?
2) Если это возможно - объясните как это сделать?
3) Если это невозможно - как такое может советовать тех. поддержка mercury@fsvps.ru???

Не смог сдержатся после новости http://www.vetrf.ru/vetrf/news/29708.html

Значит нас учат и пугают блокировкой при заведении 4 уровня названия нашей продукции.

А 3 уровень кто в порядок будет приводить????
Там похлеще чем «Бред сумасшедшего»

Пример
креветка тигровая с головой в панцире с/м
креветка тигровая с головой с/м
креветка тигровая в панцире с/м

креветка тигровая варено-мороженая в панцире и очищенная
креветка тигровая в/м
креветка тигровая в панцире в/м

креветка с/м б/г
креветка неочищенная, обезглавленная
креветка без головы
креветка сыро-мороженая
креветка с/м
креветка очищенная с/м
креветка тигровая без головы
креветка тигровая без головы в панцире с/м
креветка тигровая без головы с/м

креветка розовая мороженая ?

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

Прежде чем выстраивать 4 уровень нужно привести 3 уровень в порядок. Так чтобы продукция однозначно относилась к одному виду продукции.

Весь этот «Бред сумасшедшего» приводит следующей конкретной ситуации:

1) Поставщик1 заводит у себя запись с одним видом продукции (например креветка без головы)
2) Поставщик1 заводит у себя запись с одним видом продукции (например креветка неочищенная, обезглавленная)
3) Покупатель заводит у себя наименование с по смыслу одинаковым видом продукции (Например креветка с/м б/г)
4) Поставщик1 и 2 выписывают ВСД на Покупателя
5) Меркурий требует при гашении Вид продукции из ВСД, а покупатель хотел бы вставить свое наименование продукции (Что и логично в таком бардаке, чтобы дальше выписывать с корректным видом)

Резюме:
[MERC14231] () Вид продукции в сведениях о принимаемой партии должен совпадать с указанным в ветеринарно-сопроводительном документе.
[MERC24033] () Указанное наименование продукции относится к другому виду продукции
[MERC17034] () Вид продукции в сведениях об объединенной записи складского журнала не совместим с продукцией из объединяемых записей складского журнала [MERC17033] ()
[MERC17230] () Продукция должна совпадать для объединяемых записей складского журнала

Как это назвать "Хуже чем Бред сумасшедшего".

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

GNN wrote:

Gmix wrote:
Другими словами требование выписки 1ВСД на 1Артикул. Т.е заставляют нас как производителей объединять записи разных партий продукции выпущенными в разное время (2 смены например).
Также смазываются принципы прослеживаемости заявленные Меркурием.
Т.Е проблемы учета своих систем они перекладывают на поставщиков.

Данная ситуация для нас неприемлема так как разрушает выстроенный учет в нашей системе с интеграцией Меркурий.
Как с этим бороться?

А вы уверены, что правильно поняли их требования? Возможно, речь идет про то, что количество строчек в накладной должно совпадать с количеством ЭВСД?
Если у вас разные партии и даты изготовления у одного SKU, то может нужно просто разбить эту позицию в накладной на несколько строк и к каждой строке выписать свой ЭВСД?
Мы в Магнит пока ничего не поставляем, но с другими сетями работаем именно так и пока без претензий с их стороны.

Да мы их правильно поняли.
Официальные требования.

Для обеспечения оперативной приемки продукции, ЭВСД должен быть оформлен согласно параметров
работы в Системе. В виду различных технологических решений оформления ЭВСД параметры были
поделены на 2 блока с различными способами идентификации:
1. Передача в ЭВСД трехуровневого классификатора и номера ТН в ЭУПД/ЭТОРГ-12;
2. Передача номера (UUID) ЭВСД в DESADV

Формирование ЭВС допустимо по любому из указанных блоков.
Различные ЭВС в одной поставке могут быть оформлены по различным блокам параметров.
Плановый срок старта работы по параметрам блока 2 — 01.11.2018г.
Подробные параметры оформления ЭВСД представлены в приложении 1

Приложение 1
Общие параметры оформления ЭВСД в Системе:
1. Отправитель и его площадки должны быть зарегистрированы в системе ФГИС «Меркурий»;
2. При оформлении ЭВСД в разделе сведениях о получателе должен указываться адрес
соответствующего Распределительного Центра согласно приложению 3 к настоящему
уведомлению;
3. Партия поступающей продукции должна быть обеспечена оформленной ЭВСД в системе
«Меркурий» на момент прибытия а/м в точку разгрузки;
4. В пакет документов на поставку необходимо прикладывать сжатую с расширенной
информацией распечатку ЭВСД (образец в приложении 2);
5. Вид продукции при оформлении ЭВСД должен соответствовать трехуровневому классификатору
ФГИС «Меркурий», который был предварительно предоставлен для формирования данных в
разрезе СКЮ;
6. Предприятие изготовитель продукции в ЭВСД должно соответствовать ГУИД изготовителя,
который был предварительно предоставлен для формирования данных в разрезе СКЮ;
7. Строка ветеринарно-санитарной экспертизы должна быть заполнена одним из имеющихся в
системе значений, в оформленных ЭВСД должны быть указаны результаты ветеринарносанитарной
экспертизы (лабораторные исследования);
8. Дата изготовления поставляемой Вами продукции в ветеринарных сопроводительных
документах, как на бумажном носителе, так и в электронном ветеринарном свидетельстве, после
вашего перехода в следующий формат:
ДД.ММ.ГГГГ.
ДД.ММ.ГГГГ - ДД.ММ.ГГГГ, в случае указания дат изготовления диапазоном.
9. Дата окончания срока годности поставляемой Вами продукции в электронных ветеринарных
сопроводительных документах должна полностью совпадать с информацией на потребительской
упаковке;
10. Продукция со сроком годности 5 дней и менее должна быть указана как скоропортящаяся;
11. Вид транспорта и номер а/м в ЭВСД должны соответствовать транспортному средству, которым
осуществляется перевозка товара;
Номер а/м должен заполняться русскими или английскими буквами без спецсимволов (запятые,
двоеточие и т.д.)
Для указания номера а/м, прицепа, контейнера необходимо использовать только соответствующие
поля
12. Маркировка должна указываться русскими или английскими буквами без спецсимволов (запятые,
двоеточие и т.д.)
Указание нескольких маркировок необходимо заполнять отдельными полями
(1 маркировка = 1 поле)
13. При оформлении ЭВСД не ставить отметку «Учет ВСД».

Параметры оформления по блоку 1:
14.1 Оформление 1 ЭВСД на партию продукции равен 1 СКЮ, оформление нескольких ЭВСД на 1
СКЮ в одной поставке недопустимо.
15.1 Номер ТН должен соответствовать:
- номеру по которому были выписаны ЭВСД;
- номеру ТН в ЭУПД/ЭТОРГ-12.
16.1 Дата ТН должна соответствовать:
- дате ТН в ЭВСД;
- дате ТН в ЭУПД/ЭТОРГ-12.

Параметры оформления по блоку 2:
14.2 Оформление 1 ЭВСД на партию продукции равен 1 СКЮ, допускается оформление нескольких
ЭВСД на 1 СКЮ в 1й поставке;
15.2 Номер ТН должен соответствовать:
- номеру по которому были выписаны ЭВСД;
- номеру ТН в ЭУПД, ЭТОРГ-12, ТТН.
16.2 Дата ТН должна соответствовать:
- дате ТН в ЭВСД;
- дате ТН в ЭУПД, ЭТОРГ-12, ТТН.
17.2 В EDI документе DESADV должны быть заполнены дополнительные поля:
- Идентификатор ЭВСД - уникальный номер ЭВС присваиваемый в Меркурий
Пример: 550e8400-e29b-41d4-a716-446655440000;
- Дата изготовления;
- Срок годности;
Формат даты в DESADV должен полностью соответствовать формату в ЭВС.
При выписке нескольких ЭВСД с разными СГ на 1 СКЮ, в DESADV по 1 СКЮ вносим количество
отгруженной продукции и даты несколькими строками, кратно количеству ЭВСД.
При выписке 1 ЭВСД с несколькими СГ периодом на 1 СКЮ, в DESADV вносим СГ периодом к 1 СКЮ.

вот сейчас думаем по поводу блока 2:

Но ответа от них нет, что они это подтверждают.

С другими сетями проблем нет.

Уполномоченное_лицо wrote:

dk wrote:Т.е. хорошо было бы иметь функционал, чтобы складские записи по одному скю автоматически объединялись?

Наверное это тоже не есть правильно.
Объединение в одну запись должно происходить при одинаковом sku с одними и теми же датами выработки.
Представьте что есть Кефир с датой выработки 26.10.2018 и 27.10.2018 Не смотря на то что это одна и та же SKU, но даты выработки совершенное отличаются друг от друга. Поэтому в идеале должны быть два вет. сертификата.
Есть вариант выписки одного сертификата на кефир с разными датами, с указанием интервала в строке выработки.
Но представьте как затруднительно будет происходить разделения партии в случае аннулирования некоторого количества продукта. Как по мне это геморрой. Хотя....

Неправильно объединять записи вообще.
Этот функционал добавили для упрощения.
Он смазывает прослеживаемость.
Например выпустили 2 партии (1 утром, 2 вечером) делали из разных партий вх. сырья.
Объединили партии и продали 10 контрагентам.
Затем 1 из контрагентов обнаружил проблему с качеством продукции.

Вопрос какие партии вх сырья проверять?

Без объединения количество партий для проверки будет в 2 а может и 3 раза меньше.
А теперь представьте, что контрагенты тоже объединяют записи.

Есть новость http://www.fsvps.ru/fsvps/news/25798.html ,но на неё тандер не реагирует.
Ну ладно у себя пусть объединяет как хочет. Им потом объясняться.
Но требовать от производителей смазывать учет - ЭТО просто нонсенс. Россельхознадзор должен реагировать на такие Вещи.

Коллеги последнее время получаем вот такие требования.

Добрый день! Прошу связаться с поставщиками и поставить вопрос о составлении ВСД по принципу (1-серия, 1-ВСД)
В связи с введением шлюза в 1С, при отправке транзакций возникает проблема в момент гашения и привязке номенклатур Меркурий с 1С.
По системе мы можем привязывать только 2 строчки номенклатур 1с-Меркурий, но возникает ситуация, что по документам 1 позиция, а по ВСД несколько с разными сериями или наоборот.

ВСД Должны в обязательном порядке соответствовать приходным документам ( Одна номенклатура – Одна ВСД )
В противном случае я не буду принимать товар по ВСД, которые не соответствует документам и сериям.
На каждую номенклатуру и на каждую серию, должна быть отдельная ВСД.

С Уважением,
Алешин Иван
Менеджер по закупкам "GFC"
Skype: *****@gfc-russia.ru
Тел: +7 962 *** 5* 46

И тандер

From: Кузнецов Никита Дмитриевич [mailto:k*****@magnit.ru]
Sent: Tuesday, October 23, 2018 10:29 AM
Subject: Re: Несоответствие сопроводительной документации _ Меркурий _ ПОЛАР СИФУД РАША ООО (РЦ) _ РЦ Колпино _ Клп495809

Данный вариант неприемлем, т.к. не решает проблему в целом,
нам необходима выписка единой ЭВС по всему вашему ассортименту, не только 1604.

Другими словами требование выписки 1ВСД на 1Артикул. Т.е заставляют нас как производителей объединять записи разных партий продукции выпущенными в разное время (2 смены например).
Также смазываются принципы прослеживаемости заявленные Меркурием.
Т.Е проблемы учета своих систем они перекладывают на поставщиков.

Данная ситуация для нас неприемлема так как разрушает выстроенный учет в нашей системе с интеграцией Меркурий.
Как с этим бороться?

Прошу прокомментировать представителей ГИС Меркурий.

Пока я так понял не обновили.

Висит 6.7.8 в меркурии.
Ответы пока с ВСД приходят.

alexey-zmey wrote:

Gmix wrote:

Простите, а это что за запрос?

GetStockEntryByUuidOperation Этот?

GetStockEntryByGuidOperation
GetStockEntryByUuidOperation
GetStockEntryVersionListOperation

Любой из них

Так Запись Журнала не возвращает связанные с ней ВСД. Она возвращает только ВСД, которая создала StockEntry - проверено опытным путём.

Ну по крайней мере в моем решении настроена так что там всегда один ВСД входящий.
Что для меня очень удобно в целях интеграции.

Простите, а это что за запрос?

GetStockEntryByUuidOperation Этот?

GetStockEntryByGuidOperation
GetStockEntryByUuidOperation
GetStockEntryVersionListOperation

Любой из них

Пятница, 13-е: ученые рассказали о затмении Солнца суперлуной‍

Куда там Луне - МЕРКУРИЙ в этот день затмит все )))))))).

Алексей Баранов wrote:Вот у меня почему-то так и не заработали нормально запросы по изменениям....
Я всегда выбираю полный список ВСД за период.

Но если следовать логике оптимизации, так они бы убрали из запроса погашения ВСД все, кроме uuid ВСД, в случае полного согласия!
Там запрос уменьшился бы на 2-3 порядка.

И по списку измененных уже посылали бы только guid'ы измененных, чтобы уж совсем "оптимизировать"!
А всё-равно дополнительный запрос делать, так зачем столько инфы выдавать?

Путь бы на все запросы кроме примитивных возвращались только идентификаторы.
А чего? нагрузка на сервера сразу бы упала в ноль.
Тогда бы сделали нормальную распределенную систему. Примитивные запросы к справочникам идут на одни сервера.
А запросы application на другие и они бы никак не пересекались. Вообще бы нагрузка упала

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

Неужели не понятно, что нужно давать разработчикам самим решать получать, что им получать. ЗАПРОСЫ ДОЛЖНЫ БЫТЬ МАКСИМАЛЬНО ПАРАМЕТРАЛИЗИРУЕМЫЕ.
В них должны быть отборы НА ВСЕ. Тогда и xml ответов будут малые и скорость выполнения их повысится.

ЕСЛИ вы что-то отключаете нужно сделать параметр в запросе. И Комментарий "при использовании этого параметра скорость выполнения выше". Разработчики сами максимально быстро его начнут использовать.

Слышали новость
http://vetrf.ru/vetrf/news/27290.html

а также сведения о связанных с записью журнала ВСД, то есть в ответе не будут элементы <vd:laboratoryResearch>…</vd:laboratoryResearch> и <vd:vetDocument> …</vd:vetDocument> будут отсутствовать.

Ну лабораторные исследования может и не нужны. Хотя это виднее разработчикам систем которые УЖЕ РАЗРАБОТАНЫ.

Но убирать теги <vd:vetDocument> …</vd:vetDocument>
ЭТО ВЕРХ БЕЗГРАМОТНОСТИ. ПРИ ЭТОМ СООБЩАЮТ ЗА 1 ДЕНЬ до ОБНОВЛЕНИЯ.

Разработчики МЕРКУРИЯ Вы вообще раньше когда либо, что нибудь разрабатывали???????????????????????????????

Удаление объектов в любых системах (особенно связанных с миграцией данным между 1000 систем) сложная, ответственная задача.
За 1 день её решить невозможно.
Вы подумали об разработчика (ВАШИХ КОЛЛЕГАХ МЕЖДУ ПРОЧЕМ) интеграционных решений.

СРОЧНО ОТМЕНЯЙТЕ ЭТО РЕШЕНИЕ пока РОССИЯ не ВСТАЛА В ПРОБКЕ ПОД НАЗВАНИЕ МЕРКУРИЙ.

vet66 wrote:нее конечно бюджет надо увеличить однозначна, поэтому и неробит ,видимо, мало денег то выделено было

Не понятно причем тут бюджет.
Информации об отсутствии финансирования я не увидел на форуме от разработчиков.

Вот отсутствие системного подхода видно.

Владимир Игнатов wrote:

Gmix wrote:Не думаю что бюджет освоен. Учитывая планы выпуска Api 3.0 и дальнейшие планы.

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

Естественно.
Но поля, то в базе есть, а в Api почему-то не возвращаются Это как зачем и почему.

В моем понимании Api должно позволять получать/отправлять все, что можно делать в базе.
Иначе, что же это за "вход такой ограниченный"

Алексей Баранов wrote:

Gmix wrote:

"Кто не знает цену времени, тот не рожден для славы."
Люк де Клапье

Увы не про Меркурий на данный момент.

Полностью согласен с докладчиком!
Да что толку?
Я подозреваю, что сервис Ветис.API представляет собой такой жуткий монстр, что что-то изменить практически невозможно.
Проще заново написать, да кто ж позволит! Бюджет уже освоен!

Доработать можно все и вся, нет неразрешенных задач для целей автоматизации.
Не думаю что бюджет освоен. Учитывая планы выпуска Api 3.0 и дальнейшие планы.
Сейчас сложный момент запуска к которому подготовились явно плохо.