|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: dk
Индекс форума » Профиль для dk » Сообщения, отправленные пользователем dk
Автор Сообщение
anastasiyaomvasl wrote:Добрый день.

Есть ли какие-то нормативные документы, законы, правила, как покупатель должен принимать продукцию?

Проблема: мы (поставщики-производители) отправляем свою продукцию в федеральную сеть, сопровождая ее ТТН, УПД и ЭВСД. Покупатель гасит наши ВСД без разбора. Если какая-то торговая точка принимает продукцию частично или не принимает вовсе, отправляет нам возврат по документам, но без должного оформления ВСД (ВСД гасится полностью всегда).
На мои требования оформлять возврат также во ФГИС Меркурий получаю ответ "Еще раз вам напоминаю – у сотрудников магазина НЕТ И НЕ БУДЕТ НИКОГДА доступа в ГИС Меркурий. Все операции в Меркурий выполняет робот (интеграционный шлюз)"

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


Кто перевозит продукцию? Это получается перевозка без ВСД - коап 10.8 часть 1. Хотя водителю обычно, всё-равно никто номер ВСД не выдаёт, даже если всё правильно оформляет.
У нас тоже есть функция автогашение, но для таких случаев есть задержка: чтобы можно было аннулировать, погасить частично или сделать полный возврат.
Погасим ваши ВСД, в том числе за предыдущие периоды. https://меркурий.рус/pricing
http://vetrf.ru/vetrf/news/30670.html
Yoreg07 wrote:что можете посоветовать? как гасить такие ВСД?


Пришлось в код лезть искать. Похоже проблема была не с гашением, а с инвентаризаций, видимо в голове всё смешалось.
При гашении указывайте productItem.guid без productItem.uuid и всё нормально гасится. А при инвентаризации таких записей нужно из актуального справочника брать subProduct.guid, иначе будет ошибка.
Yoreg07 wrote:т.е. хотите сказать, что через WEB нельзя менять subProduct при гашении, а через API можно?


Не могу понять вопроса! Менять ничего нельзя. В ВСД неактуальная информация subProduct.guid(она была актуальной на момент выписки ВСД), а при гашении мерк видимо сверяется с актуальным справочником ProductItem.

Разрешали бы указывать только productItem.guid, без subProduct, product, productType, тогда бы и проблемы такой не было.
Yoreg07 wrote:
dk wrote:
oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.


Это ошибка в интеграции, если имеется актуальный справочник ProductItem, то всё можно погасить и инвентаризировать.
Вместо того, чтобы выдать рекомендации для интеграций, решили, что проще запретить.

Добрый день, скажите, а как через api погасить ВСД в таком случае? Есть ВСД с 4-м уровнем, после его оформления, но до гашения отправитель поменял 3 уровень у номенклатуры справочника. Если я не ошибаюсь, то 3-й уровень в оформленном ВСД должен совпадать с 3-им уровнем в фактической информации при гашении, или я не прав? Вобщем, что указывать при гашении в фактической информации?


subProduct guid берите из актуального справочника ProductItem, а не из ВСД.
Мы уже давно победили все проблемы с гашением через шлюз.
oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.


Это ошибка в интеграции, если имеется актуальный справочник ProductItem, то всё можно погасить и инвентаризировать.
Вместо того, чтобы выдать рекомендации для интеграций, решили, что проще запретить.
Через шлюз Ветис.API вообще нельзя комментарии оставлять.
http://vetrf.ru/vetrf/news/31168.html
А ещё информацию о подтверждённых ХС нельзя изменить, будет ошибка:
MERC04373 Редактирование указанного хозяйствующего субъекта запрещено, т.к. он добавлен в реестр ИС Цербер.
Ryasik wrote:В очередной раз пишу, к кому мне обратиться можно???
При нажатии кнопки "Оформите" в 1С 8.3 - выдает сообщение "Недостаточно прав оформления партии на рыбу"
При оформлении исходящей ВСД через WEB - все ОК!
В чем может быть проблема?


Права для веб и Ветис.API разные. Нужно прописать нужные права пользователю. Как это делается в 1С не могу подсказать.
Yoreg07 wrote:
nmzn1 wrote:
Yoreg07 wrote:Спасибо за "перегон", но думаю за это нас тоже не погладят. Вот интереснее ситуация. Например, есть цех, производит котлеты, а через дорогу (другой уже адрес) магазин этого же ХС. Естественно ни на какой машине не повезут из цеха в магазин ... в переносной холодильник и всё. Как быть в таком случае с транспортом?

тут опять же по моему, перегон, чтобы не указывать ТС - вариантов то больше нет

в документации написано, что перегон подразумевает перегон скота/живых животных ... думаю, что контроль в API за соответствие типа продукции и вида транспорта есть и он не даст сделать такое.


Не даст сделать такое! Вам придётся живое животное в партию добавлять, чтобы перегон сработал.
Я бы указал номер машины, что-нибудь типа без перевозки или без номера или что-то типа того. При проверке сказать адреса рядом, перевозим на погрузчиках без номера.
miskevich wrote:
egais2018 wrote:Читается как: "пусть хоть все не смогут работать, а мы и дальше будем DDoS-ить Меркурий раз в секунду". XD
Вы ждете ответа от сервера или сразу через секунду после посыла повторяете запрос? Попробуйте ради эксперимента увеличить в несколько раз. А может реализовать динамическую задержку ;D


А я же писал в основном посте, что prdcRsltDate не игнорируется. Первый запрос на получение ответа отправляется в указанное время + 1 секунда.


prdcRsltDate = Дата и время получения результата выполнения заявки. При получение этой даты можно сказать транзакция закрывается.
Если имеется ввиду Объект submitApplicationRequest/application rcvDate - то это дата постановки задачи в очередь, т.е. дата получения applicationId.

Не понятно, что значит "prdcRsltDate не игнорируется"? То, что вы запрашиваете результат заявки, только после получения rcvDate и соответственно applicationId, а не до этого, видимо без applicationId не получалось результат запрашивать))

Получается вы начинаете запрашивать Меркурий через 1 секунду после постановки задачи в очередь.

P.S. Вот по prdcRsltDate как раз можно определить разницу по времени, когда меркурий подготовил результат транзакции и ваша программа получила этот результат, т.е. проигрыш по времени.
Мы формирует 2 очереди одну на отправку запросов, вторую для получения результата(в каждой очереди по 3 приоритета), обе очереди имеют одно ограничение: 5 запросов в секунду.
Чем дольше нет результата, тем больше времени между повторными запросами. Каждая транзакция независимая, транзакции могут быть от разных клиентов.

Получается даже если один клиент гасит 10000 ВСД, то другой в этом время без проблем выписывает новые и не замечает этого.
exteris wrote:Мы с 1 июля формируем около 200 ВСД в день. С 1 ноября будет больше 1000. Если ждать результат от сервера минуту, то выходит 1000/60=больше 16 часов в день на формирование ВСД...


Тут не об этом речь. Ограничение 5 запросов в сек с одного ip.
Тут речь шла, сколько и когда делать запросы для получения результата одной транзакции. Что бессмысленно долбить сервер каждую секунду, чтобы получить результаты одной транзакции.
 
Индекс форума » Профиль для dk » Сообщения, отправленные пользователем dk
Перейти:   

Powered by JForum 2.1.8 © JForum Team