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

Планируем передавать в заказ номер ВСД.

lebrosha wrote:Добрый день, меркурианцы!
Начал погружаться в детали (не так глубоко, как хотелось бы, но все же). Дошел до оформления входящей партии.
При использовании веб интерфейса я вижу список всех непогашенных ВСД.
По api нам также будет приходить к-л запрос (заявка) на гашение ВСД?
Планируем из заявки подтягивать номер ВСД в заказ, ну и после приемку указывать номер этого ВСД при гашении (оформлении входящей партии)

Спасибо

lebrosha wrote:Спасибо большое.
Отлично, с этим разобрались.
Доступ админский на сколько я понял, я могу получить на все свои юр лица и места хранения (площадки). Читал про подключение групп и холдингов.

Еще ряд вопросов. Заранее благодарен знающим людям за желание делиться информацией.
1. Как скоро после отправки в Меркурии получатель увидит входящий документ?
2. Есть ли информация, что EDI провайдеры предлагают для однозначной идентификации транзакции в Меркурии? ИНН, дата и номер накладной, конечно, хорошо, дак ведь точно ошибутся поставщики. В целом сервисом провайдером не планируем пользоваться, интегрируем через API самостоятельно.
3. Кто-то планирует в договоре прописать, что поставку "будем разворачивать" при несоответствии данных в Меркурии и на бумаге

lebrosha wrote:Коллеги, прошу помочь начинающим.
Несколько вопросов, буду благодарен за ответы.
1. Торговая сеть представляет собой совокупность юридических лиц. У каждого юр. лица несколько точек продаж (магазинов). Учетная система, естественно, общая. Нужно ли подключать каждый магазин или можем обойтись юр лицами? Если не отражать каждое место хранения, тогда вроде как и перемещения между магазинами в меркурии делать не нужно, с другой стороны как поставщики в транзакциях будут разграничивать фирму и предприятие получателя.
2. Возвраты поставщику (некачественного товара) выполнять также через транзакцию. У поставщика тоже будет фирма и предприятие (каждый склад). В демо версии я такого не нашел.
Спасибо!

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

maltsev wrote:но ведь для розницы нужно все равно интегрироваться с Меркурием, как минимум для возвратов. Верно ?
Поставщик не сможет за розницу оформить возврат. Ему не позволит сделать это система.

Сможет, если поставщик является в системе представителем получателя. И система ему это сделать позволит.

Егорова Ирина wrote:Здравствуйте!

-Поддержка унифицированного классификатора продукции GS1 International (GPC).
- Поддержка стандарта GLN для идентификации площадок.

Сейчас идёт обсуждение реализации в рамках рабочей группы. Мы будем рады, если вы поделитесь с нами опытом использования GPC и GLN в бизнес-процессах на своём предприятии.

ANIT wrote:

gni wrote:
А вот еще пара вопросов:
Допустим ХС автоматизировал подачу заявок. Но, как я понял, пока вет врач не примет решение мы все-равно не получим ВС и не сможем отгрузить продукцию. А если вет врач это делает вручную да еще у него 8 часовой рабочий день - вообще отгрузка выглядит проблематично. Т.е. для нормальной работы ХС в этом случае необходимо еще и автоматизировать работу ветврача. А кто в этом случае должен давать заявку на доступ к API? Вет управление?

Начну с конца.
А кто в этом случае должен давать заявку на доступ к API? Вет управление?
Заявку подает ХС на своем фирменном бланке с печатью и подписью ген дира, а может и вет. управление. Подробно тут: http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.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
Если вет. врач штатный, то от лица ХС отсылаете.
Доступ вам дадут только на тестовый шлюз. На рабочий вы получите только после адекватного теста, когда набор безошибочных транзакций будет на тестовом шлюзе достаточный. Т.е. отправить 1-2 заявки и подать запрос на рабочий шлюз, не вариант, заявок нужно прогнать штук 20. С тестовым шлюзом работайте В КОПИИ 1Ски. В любом случае копия будет у вас на долго, т.к. нужно проверять корректность релизов Меркурия, корректность релизов интеграционного продукта который вы внедрять будите и делать всякие эксперименты.
Второй момент: Допустим ХС автоматизировал подачу заявок. Но, как я понял, пока вет врач не примет решение мы все-равно не получим ВС и не сможем отгрузить продукцию.
Не совсем так. Если вы работаете через ВЕТИС.API, то заявку должен отсылать вет. врач под своим логином. УВЫ И АХ. Это еще один существенный недочет системы. Ветис.API почему-то не умеет работать через 2х ступенчатую систему, как это работает в ВЭБ интерфейсе. Т.е. ХС сделал заявку, а врач через ГВЭ жмет кнопочку Принять или Отклонить. Через API ваш Вет.врач должен будет работать в 1Ске и из нее отправлять ветки в Меркурий. И это огромная головная боль для внедренцев и ХС, мои коллеги с другой фирмы уже столкнулись с нею, на проекте где вет. врач не штатник. Четыре месяца работы, вышли на этап "продакшена", в рабочей версии состыковали все справочники и стопорнулись на пару недель, пока решали вопрос, что вет врач из вет. управления обязан будет работать в 1Ске. Хоть и со скандалом, но вопрос благо урегулировали и вет. управление все же пошло на встречу в такой ситуации. Я пока с клиентами по интеграции, где штатника нет, стараюсь дел не иметь. Но в любом случае я нарвусь на эту проблему, когда штатники пойдут в отпуска или на больничные, т.к. в таком случае будут привлекаться к работе приходящие специалисты из вет. управлений. Когда этот недочет шлюза будет решен, не известно. Поэтому перед тем как вбухивать деньги в интеграционный проект, в первую очередь поинтересуйтесь вопросом, готовы ли "приходящие" специалисты, если они есть, отправлять ВСД из 1Ски?
По хорошему механизм Ветис.API должен иметь обе схемы работы. И схема когда ВСД влетает со статусом "Оформлена" и с подписью отправившего с 1Ски вет врача (т.е. текущая схема) и схема работы в два этапа (как в ВЭБ интерфейсе). Но когда разработчики это реализуют, БООООЛЬШОЙ вопрос.
С текущей схемой работы через шлюз есть еще один весомый затык. Как только ВСД влетело в Меркурий, ничего вы поправить там руками уже не можете. Не все реквизиты влетают корректно, какие-то недочеты есть в работе разработчиков интеграционных решений, какие-то у разработчиков ШЛЮЗА (методов нет для заполнения реквизитов). Как итог через ВЭБ вы оформить корректно ветку можете, а через шлюз нет, можно только аннулировать. Если бы Ветка влетала и она была бы доступна для редактирования, то это бы сняло целый ряд проблем.

gni wrote:А если вет врач это делает вручную да еще у него 8 часовой рабочий день - вообще отгрузка выглядит проблематично.

А это судя по всему уже проблемы индейцев. Увы и ах.

ANIT wrote:

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

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

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

maltsev wrote:то есть если в Вики по ВЕТИС API не написано ничего в части ВЕСТЫ, значит для бизнес сообщества эта система не предназначается. Верно ?

Нет, не верно.

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

maltsev wrote:

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

Globus64 wrote:Возможно не по теме, но нужно провести конференцию специалистов которые внедряют ГИС Меркурий .Так люди могу пообщаться на прямую с разработчиками, обменяться опытом , обсудить вопросы плюсов и минусов, что нахватает в системе и т.д.
Есть регионы в которых еще даже не знаю, что это такое и с чем его едят !
Николай Анатольевич огромная просьба организовать конференцию по внедрением электронной ветеринарной сертификации.

Возможно ли гашение в автоматическом режиме по истечению срока годности ?
Еще вопрос ,отправка непродуктивных животных , РЖД произведет перевозку по ВСД на обычной бумаге ?

Вы имеете в виду вебинар?
Да, возможно.
Скоро выйдут новые правила - там все будет прописано. РЖД об этом будет оповещено.

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

Об этом будет объявление на нашем сайте (www.fsvps.ru). Когда удастся его организовать пока не могу сказать: проблемы со временем.

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

Globus64 wrote:Возможно не по теме, но нужно провести конференцию специалистов которые внедряют ГИС Меркурий .Так люди могу пообщаться на прямую с разработчиками, обменяться опытом , обсудить вопросы плюсов и минусов, что нахватает в системе и т.д.
Есть регионы в которых еще даже не знаю, что это такое и с чем его едят !
Николай Анатольевич огромная просьба организовать конференцию по внедрением электронной ветеринарной сертификации.

Возможно ли гашение в автоматическом режиме по истечению срока годности ?
Еще вопрос ,отправка непродуктивных животных , РЖД произведет перевозку по ВСД на обычной бумаге ?

Вы имеете в виду вебинар?
Да, возможно.
Скоро выйдут новые правила - там все будет прописано. РЖД об этом будет оповещено.