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

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

Да никак не быть.
Ошибку эту выявляли несколько месяцев назад в ходе тестов. А дальше смотря на чем написана интеграция. Если для хранения остатков в ИС клиента используется регистр накопления, то труба. Если подхватывает данные по остаткам "налету" или хранит их в регистре сведений, то еще жить можно, можно погасить ВСД через ВЭБ и обновить записи журнала. Главное чтобы в интеграционном решении этот функционал был. Если же обновить записи журнала нет возможности (т.е. первый вариант, когда система построена на регистре накопления), то ничего вы тут не сделаете, кроме как гасить ВСД в вэбе и отгружать такую продукцию тоже в вэбе. Делали тест, с одного ХС на другой кидали продукцию с отбором лаб исследований через весту, та же фигня, с вэбом все ОК, а API затирает. Если вручную лабы вводили, у вас хоть есть возможность их перепечатывать. А если через весту, то всё, целостность потеряна. Как лаборатория будет результаты оформлять, по таким веткам, не понятно. Как ей передать этот отбор проб, тоже не ясно.
У вас вариант только акт несоответсвия в меркурии делать после подтверждения через АПИ и вносить лабы ручками, естественно перед тем как что либо гасить, вы должны будите заглянуть в ВСД и переписать на листик, в эксельку, всю инфу по лабам.
Но и тут можете споткнуться на архитектуру интеграционного решения и особенности работы АПИ. Как только по записи будет внесено изменения, UUID записи станет новый. А часть транзакций, в частности отгрузки, работают исключительно по нему, а не по ГУИДУ. И добиться от разработчиков механизма работы по ГУИДам никто не смог. Если интеграционная система не умеет актуализировать данные по остаткам, то всё, запись в 1С тупо зависнит, ничего вы с ней сделать не сможете, будет тупо болтаться на остатках.
Интеграция 1С из покупных или самописка?

nselezneva wrote:
Спасибо за ответ!
Но я так и не поняла, ХС может создать сам ВСД, чтобы отправить его на утверждение врачу?

Если через API, то Нет, нельзя. Только через вэб интерфейс. Через API сразу формируется утвержденное ВСД. Т.е. как ХС вы сможете через API оформить только ограниченный перечень продукции, в остальном вет врач должен будет под своей учеткой работать в вашей системе.

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

El_Djo wrote:
то ХС обязан делать (в смысле руками) или обеспечивать формирование (в смысле через API) заявку, которая должна быть источником данных для оформления сертификата. Получив такую заявку врач обязан произвести в течение дня оформление сертификата или дать мотивированный отказ в его оформлении.

БИНГО! Только обеспечить это должны РАЗРАБОТЧИКИ ШЛЮЗА API.
А вместо этого предлагается чтобы вет врачи отдавали свои пароли ХС, а те в свою очередь работали под его учёткой через API, а вет врач пусть смотрит чего они там понавыписывали. Ну а если пропустил, то ничего страшного. Сколько там штрафы будут вы говорили за "продукцию из воздуха"? Смешивается в одну кучу коррупция и нормальный вет надзор, под лозунгом "а на бланках все равно бардак". Только на бланках живая подпись вет врача, и если он коррумпирован то за руку его поймать и привлечь к ответственности можно. А теперь ситуация "Отдайте логины ибо система не работает по другому", ХС может нашлепать левые ВСД, и подпись будет там опять же вет врача который "якобы произвел досмотр продукции и ТС", а на самом деле знать не знает, что кто-то нашлепал левак под его учеткой. Отслеживать он должен, смотреть журналы? да когда обороты попрут, он чекнится отслеживать что он уже проверил, а что за запись новая левая появилась, отгрузка без его ведома. Он не должен быть сторонним наблюдателем. Его задача нажать кнопку Я ПОДТВЕРЖДАЮ.
Или вариант когда вет врача ХС будут заставлять работать в собственных учетных системах. Т.е. обслуживает вет врач 10 контор с интеграцией, вот во всем зоопарке интерфейсов он должен будет разобраться. И доступ ему на сервер с учетной системой дай, где хранится не только информация о товарообороте фирмы. А если не хотите предоставлять, то пишите отдельную базу для него с интеграцией и правила обмена. Огромный объем работы, при этом в кратчайшие сроки и с дефицитом специалистов на рынке труда которые умеют делать подобные вещи.
И все это никак не ускоряет внедрение интеграционных решений и никак не налаживает партнерские взаимодействия между ХС-ми и ВетУпрами.
А нужно то, всего то сделать этот кусок функционала на стороне шлюза, чтобы заявка могла прилетать в меркурий как Заявка, а не как оформленное ВСД, без "а зачем" и "это никому не нужно". Нужно, очень даже нужно.
дайте оба механизма работы, пусть ХС сам решает по какой схеме ему работать. есть свои вет врачи в штате, работает через API сразу с оформленными ВСД, нет вет. врачей в штате, пусть работает с заявками. Сейчас же выбора интеграторам не оставили.
Вместо того чтобы вет врач пошел на рампу, в склад, в цех и посмотрел продукцию, машину, открыл планшетик и нажал кнопку оформить, он будет торчать у монитора и тыкать кнопочки с десятью инструкциями, каждая под свою учетную систему. Ну а программисты будут каждый раз при выходе нового релиза API поминать Меркурий "добрым словом" т.к. помимо подгонки функционала обмена с API, надо еще успевать подогнать функционал в плане обменов Учетная база - Урезанная база для вет врача.

Л. Александр wrote:Премьер сказал ,что будет единая маркировка товара в РФ, так ,что новые обновления не за горами.
Я в СББЖ за бланками поехал. На сегодня всем пока.

Единая маркировка это конечно здорово. Только боюсь что если меркурий и дальше будут допиливать таким образом, то всю продукцию которая будет выпущена до ввода этого единого стандарта и всю импортную продукцию, можно будет благополучно сжечь. Ибо на ней может не оказаться полей которые будут ОБЯЗАТЕЛЬНЫ для заполнения в меркурии, а какие-нибудь поля которые позволяли идентифицировать старые партии опять уберут.

Милашка wrote:

Mak_VET wrote:так вручную через окошко "упаковка" добавляется маркировка, нет?

вручную) только прежде выходит вот это и что из этого выбирать? я не знаю ни одной расшифровки:GTIN; SSCC-код; BUNDLE; EAN
Вы знаете что это?

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

При этом все влетевшие к вам партии от поставщиков, нужно будет уточнять через акт несоответствия, ибо от поставщика вам придет скорее всего без этой детализации, а вот отгружать сети потребуют с ней, при этом каждая сеть будет требовать свои форматы, одному подай штрих-код что на коробке, другому тот что на потребительской упаковке. При этом каким образом это волшебство себе представляют на уровне больших оптовых складов, куда заходит продукция паллетами, а отгружаться она может упаковочками? С каждой упаковочки забей штрих код, т.е. снимаем палетту, разгружаем, вскрываем коробку, и пересчитываем упаковочки в разрезе штрих-кодов и маркировочки ПРОИЗВОДСТВЕННОЙ ПАРТИИ!!! При отгрузке каждому клиенту с "А я веду учет по EAN13", вскрываем коробочки, поштучно переписываем сколько каких штрих-кодов в разрезе производственных партий и ШК, запаковываем в ящичек, грузим ящички на паллеты.
Ах да, производственная партия!!! ПРишла вам продукция от производителя (в лучшем случае) от оптовика (в худшем). Пришла к вам ветка "Минтай" 10 тонн 1000 коробок производитель ООО "Рыбзавод". Ок. Встала она в меркурии в качестве записи № 12345. А дальше сеть говорит: принимаю, только в разрезе производственных партий. Более того, ее вы будете обязаны теперь указать при гашении входящего ЭВСД!!! А дальше прикол, что этих партий в вашем приходе, который вообще не факт что из РФ, а не из-за бугра с выпиской через АРГУС, может быть ни одна, ни две, а под сотню. Пришел вам ассортимент производства с 01.01.17 по 01.06.17. Идем на рампу, смотреть коробочки, "А ХДЕ???", а нет этой инфы на коробочках, она на потребительской упаковке. Ну дальше вы знаете, по схеме выше "Открыла кошелку, достала сумочку..."
Да, еще. Меркурий не умеет делить партии, он умеет их только объединять.
"Нууууу дееелайте через инвентаризациююю..."
УГУ, привязанные лабораторные пробы, отборы проб и вет сан экспертиза, которые прогнали через Весту, А нафига она? Увязка с Аргусом для "прослеживаемости оборота импорта", да зачем? И проверки за "Чтот много актов несоответствия оформляет этот ХС, значит что-то мутит".

Л. Александр wrote: Конкретизирую вопрос:Журнал есть ,но как там найти необходимого мне производителя ,ведь маркировки больше нет.???

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

когда ограниченный ассортимент, то работать еще можно, а когда там огромный ассортимент, попробуй разберись кто есть кто.

Wastman wrote:

деятельность по получению переработке (обработке) непереработанного продовольственного (пищевого) сырья животного происхождения

Здесь запятая потерялась? Что такое "получение переработке"?

одной запятой тут не обойтись, тут основная проблема в слове "производственных"

Напоминаю о вопросе который поднимался Мироторгом на форуме ECR, по поводу контента на странице Цербера и прилагаемых инструкций по регистрации ХС и Предприятий, которые вводят в заблуждение участников оборота поднадзорной продукции.

Цитирую:
https://cerberus.vetrf.ru/cerberus/

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

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

Lele4ka13 wrote:
Представьте объем моей работы если в неделю я оформляю около 200 бумажных бланков, и кроме трех-четырех поставщиков продукции никто не присылает мне ничего в Меркурии, а у меня и мясопродукция и рыба мороженая и многих производителей, а не одного двух. Плюс к этому я хочу, чтоб ваша команда разработала конкретные правила занесения продукции в электронный журнал, с указанием не просто ПОЛУФАБРИКАТЫ ИЗ МЯСА Ц/Б, а с разбивкой попозиционно: БЕДРО, ГОЛЕНЬ, ФИЛЕ и т.п., потому что товар по накладным отпускается не как ПОЛУФАБРИКАТЫ ИЗ МЯСА Ц/Б , а именно как БЕДРО, ГОЛЕНЬ, ФИЛЕ и т.п. Если не указывать конкретный вид продукции, то нет никакой прослеживаемости товара, потому что допустим 15 января мне пришли ГОЛЕНЬ и БЕДРО, а 23 января : ФИЛЕ и ГРУДКА, а в журнале под номерами 1 и 2 стоит продукция ПОЛУФАБРИКАТЫ ИЗ МЯСА Ц/Б с разными датами выработки, допустим Вы покупаете голень ( и в накладной будет написано-ГОЛЕНЬ) примерно 10 февраля, а я не смогу верно отписать Вам выбранную Вами продукцию с правильной датой выработки товара, потому что на подконтрольный мне объект продукция выбранного производителя приходит 3-4 раза в неделю и запомнить когда именно пришла ГОЛЕНЬ и следовательно от какой записи в журнале "ПОЛУФАБРИКАТЫ ИЗ МЯСА Ц/Б" мне отписать Вам эту продукцию я чисто физически не смогу. А если объединять записи журнала с видом продукции ПОЛУФАБРИКАТЫ ИЗ МЯСА Ц/Б одного производителя, то получается слишком большой разбег в датах выработки продукции и через запятую (например:01-05,17г,06-09,17г,12-13,01,17г,25-29,16г и т.д.), которые кстати не вмещаются полностью при распечатывании на защищенном бланке и приходится через инвентаризацию редактировать это.

Более того, если у вас свой цех по мясопереработке и вы каждый день выпускаете то же ФИЛЕ КУРИЦЫ, то в журнале продукции, эти партии вы объединить в Меркурии не сможете. И даты выработки вида 01-05.17 Вы уже не получите на продукцию, а будет у вас Филе Курицы 01.01.17, Филе Курицы 02.01.17, Филе Курицы 03.01.17 и т.д. И если там млекооптовые отгрузки, то можно штат складского персонала увеличивать в два раза и штат вет. врачей в т.ч. Т.к. в процессе отгрузки, вам необходимо будет заставить склад расписывать не просто, что и в каком объеме отгрузили, но и какие точные даты выработки и сроки годности и маркировки стояли на упаковке у каждого клиента. Потом, после того как машину загрузили, машина будет стоять часок другой возле склада, пока операторы подобьют все эти данные в своей учетной системе, и пока вы в разрезе всей этой аналитики будите выписывать ВСД. Одна ошибка в дате выработки и покупатель груз не примет или при проверке могут задержать за несоответствие маркировки. С производством там вообще много интересностей, вплоть до порчи продукции пока Вы будите отражать это в меркурии.

Александр Осминин wrote:ANIT, по поводу инвентаризации вы правы отчасти: только после инвентаризации реквизиты бумажных входящих ВСД и реквизиты Разрешений на ввоз продукции на территорию РФ не затираются и не убиваются, а становятся недоступны пользователям. Это дефект и мы его исправим в следующем релизе, как и сказала поддержка. Если точнее, то это 28 февраля. Раньше зарелизить мы не можем и это связано с нашим циклом разработки, думаю, вы это прекрасно понимаете. А чтобы ваш проект не простаивал и вы стали первыми на Дальнем Востоке, мы придумаем как вам помочь с корректировкой журнала для запуска. Напишу вам в личку по этому поводу.
Что касается редактирования записей после инвентаризации, то действительно их редактировать нельзя по причине того, что в ходе инвентаризации вы корректировали объем остатков и при этом прямое редактирование записи становится невозможным - только еще инвентаризация, поэтому кнопка "Редактировать" исчезла, а при попытке сохранения получаете "Недостаточно прав...".

Александр, спасибо что откликнулись. В личку сообщение отправила. Надеюсь на дальнейшее сотрудничество.

danver wrote:Почему ни техподдержка, ни уважаемый ВНА никак не реагируют на Вашу проблему?! Хотя проблема-то не Ваша, а программы. Я надеялась, что они с Вами напрямую как-то общаются...

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

Это ошибка на нашей стороне. Её исправление запланиовано в следующей версии ПО.

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

Any.V wrote:Коллеги! От нового приказ, все в шоке, задним числом вносить в базу тысячи корешков....Ну это ладно, уже дали понять что никого наши проблемы на местах не волнуют. У меня вопрос к тем кто работает на мелкооптовых складах где ассортимент аховский и все по килограмму. Сколько реально в день сделать всд если накладная 10-20 наименований и все разная продукция? Нужен Ваш опыт. Просто начальство взяло за горло и стоит вопрос о добавлении на объекты врачей. Нужно все продумать. Поделитесь опытом.

Соболезную.
В мелкооптовом еще очень много производителей и много импорта, а у импорта еще куча заводов, плюс куча разрешений на ввоз продукции + не малый перечень ВСД будет на продукцию, т.к. с бумажными естественно партии укрупняют, никто не расписывает коробку с какой датой выработки точно отгрузили, просто периодом шуруют. Вносить каждый раз эту информацию в журнал продукции, та еще песня. Если производство, можно сразу стреляться, т.к. производственные партии вы не объедините. Плюс у мелкооптовых еще и огромная клиентская база, там коробку, там коробку, да не просто по контрагентам, а по точкам отгрузки. По мелкоопту с большим ассортиментом и большим документооборотом, без интеграционных проектов вообще никуда, откуда на них на всех взять столько вет врачей, которые будут все делать в вэб интерфейсе и заниматься дополнительной операторской работой по внесению бумажных ВСД, не понимаю. С интеграционными проектами, тоже засада у мелкоопта, шлюз глючит, исправлять не спешат.
По факту проще уже выписывать ЭВСД, чем на бумажных и потом дублировать это всё в такой же форме. С той же канителью с заведением партий, что и при ЭВСД. Если при полном переходе на ЭВСД вы один раз при приходе партию забили, указали ветку по которой она пришла, а потом ее при необходимости объединили, чтоб склад пересорт не шуранул при отгрузки по одной две коробке на позицию в заявке какой-нибудь шашлычке и дальше просто работайте с этой партией, то с бумажными, каждый раз будите указывать эту входящую информацию, заводя "новую" партию. Единственное что при бумажных можно произвольно указать предприятие, которое в справочнике меркурия не подвязано к ХС, при этом он один фиг должен быть забит в справочник со всеми ИННми и т.п.
В общем так те же яйца только в профиль, я бы даже сказала, что это еще хуже вариант работы в разы.

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

nikolaech wrote:
4. Вопрос по инвентаризации. При оформлении инвентаризации существует возможность создания новой записи складского журнала, т.е. по сути необходимо вначале создать ее в учетной системе, а после обработки заявки уже присвоить ей GUID сформированный в Меркурии. Но в таких случаях есть вероятность не корректного сопоставления GUID Меркурия с записью в учетной системе, особенно если в одной инвентаризации не одна новая запись, а 10, 20 и больше. Существует ли возможность для таких ситуаций передать свой идентификатор и по нему уже получить GUID сформированный Меркурием? Или возможно подскажите иной вариант выхода из данной ситуации?

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

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