Доработки, предложения,советы по улучшению Меркурия

Добрый день.

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

Предложение по доработке и улучшению №1

На данный момент при формировании ВСД можно выбрать товар с истекшим сроком годности и отправить его, что является грубым нарушением.

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

Ответ ТП: ввести запрет на оформление эВСД при перемещение продукции с истекшим сроком годности невозможно.
В случае перевозки подконтрольной продукции с истекшим сроком годности в место уничтожения/утилизации при оформлении транспортного эВСД требуется ставить отметку «некачественный груз». При этом перечень целей перевозки строго ограничен: «для утилизации», «переработка», «предназначенные и направляемые для захоронения/обезвреживания/уничтожения».

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

Решение: Это можно сделать для "Производственный сертификат. Форма № 1", "
Ветеринарное свидетельство. Форма № 2 ", "Ветеринарная справка. Форма № 4".

Т.к. продукция может перемещаться на утилизацию «Форма № 3 (Утилизация)» оставить без изменений.

Кто пишет программный код понимает что можно поставить условие на тип или вид реквизита и исходя из этого поставить запрет на то или иное действие. На XML-сообщение это никак не повлияет.
Напишу пример как это должно выглядеть, чтобы понял человек который в коде ничего не понимает.

Если Это "Производственный сертификат. Форма № 1" Тогда
Запретить выбирать продукцию с истекшим сроком годности
ИначеЕсли Это «Форма № 3 (Утилизация)» Тогда
Разрешить выбирать продукцию с истекшим сроком годности
Конец

Также необходимо это условие для работы через API.

Предложение по доработке и улучшению №2

На данный момент при формировании/гашении ВСД можно выбрать товар со сроком годности превышающим текущую дату и отправить его, что является грубым нарушением.
Например: сегодня 04.02.2020, ВСД сформировано этой же датой, а Дата выработки 04.02.2022 года.

Ошибка может появиться в следствии человеческого фактора или сбоя в автоматизированной системе поставщика/клиента (для API).

Ответ ТП:В ФГИС "Меркурий" отсутствует ограничение по формированию даты выработки и срока годности на вырабатываемую продукцию в связи с возможностью использования «авансового» оформления ВСД.

Решение: Поставить условие на тип транзакции или тип операции и исходя из этого поставить запрет. Написать это можно за 15 минут, протестировать еще 15 минут.

Предложение по улучшению №3

Будет ли реализован функционал по исправлению/корректировке исходящих и входящих ВСД?

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

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

Даже не поняв моего вопроса, дают уже ответ. При чем тут гашение?
Я оформил ВСД и увидел свою ошибку, почему нельзя сделать изменение? Нет! Я должен аннулировать и пересоздавать все заново! А на следующий день приходит письмо от СББЖ, чтобы я объяснил им,
Почему я ошибся в дате? что за детский сад и тд и тп?!?!

Я очень надеюсь что это сообщение прочтут компетентные люди и будет сделано решение, надеюсь на улучшение в работе Меркурий!

А штрафовать тогда за что, если все это сделают?

AlexeyAv wrote:А штрафовать тогда за что, если все это сделают?

Очевидно никто не будет делать эти улучшения.

№ 1 и № 2
В общем случае для некоторых видов товаров сроки сроки годности могут быть представлены в виде неполной даты(8 форматов дат http://help.vetrf.ru/wiki/%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D1%8B_%D0%B4%D0%B0%D1%82 ).
Для живых животных он может быть не указан.

<vd:expiryDate>
<vd:firstDate>
<dt:year>2021</dt:year>
<dt:month>12</dt:month>
<dt:day>6</dt:day>
<dt:hour>1</dt:hour>
</vd:firstDate>
</vd:expiryDate>

Т.е. даты в Меркурии хранятся не в виде даты, которая может участвовать в сравнении.

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

Этот функционал вы можете реализовать в своём интеграционном решении или использовать имеющиеся.

№ 3
Очевидно, что меркурий всячески пытается избежать обновляемых полей, и это правильно.
Проще добавить новую запись в БД(База данных), чем обновить существующую, на таких объёмах данных это практически невозможно сделать. Любая БД загнётся, либо нужно каждый деть отключать систему от работы для сервисного обслуживания, проводить VACUUM и т.п.

dk wrote:Очевидно никто не будет делать эти улучшения.

№ 1 и № 2
В общем случае для некоторых видов товаров сроки сроки годности могут быть представлены в виде неполной даты(8 форматов дат http://help.vetrf.ru/wiki/%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D1%8B_%D0%B4%D0%B0%D1%82 ).
Для живых животных он может быть не указан.

Т.е. даты в Меркурии хранятся не в виде даты, которая может участвовать в сравнении.

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

Этот функционал вы можете реализовать в своём интеграционном решении или использовать имеющиеся.

№ 3
Очевидно, что меркурий всячески пытается избежать обновляемых полей, и это правильно.
Проще добавить новую запись в БД(База данных), чем обновить существующую, на таких объёмах данных это практически невозможно сделать. Любая БД загнётся, либо нужно каждый деть отключать систему от работы для сервисного обслуживания, проводить VACUUM и т.п.

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

Меркурий и так регулярно падает. - поставить доп. сервер

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

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

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

Если вас проблема с просрочкой. У нас есть услуга ежедневное автоудаление просрочки: стоит это всего 3000 руб в год на одну площадку + 3000 руб. загрузка остатков за предыдущие периоды (единоразово).

Prometeusll wrote:Меркурий и так регулярно падает. - поставить доп. сервер

Сервера не помогут, нужно ограничивать кол-во запросов.
Большинство недорогих решений не имеют собственной БД и по любому поводу делают запрос в БД Меркурия. Если такие решения не запретить, то система будет регулярно падать.
Потом нужен чёткий алгоритм запроса результата транзакций, если он не соблюдается, блокировать доступ. Многие бездумно "долбят" шлюз каждую секунду забивая очередь запросов.

Prometeusll wrote:чтобы сравнивать даты, нужно их преобразовывать и хранить в формате пригодном для сравнения, создавать соответствующие индексы в БД и т.п. - так создайте! разве нет отдела разработки?

Думаю, это необоснованно дорого будет стоить, нет смысла это делать для всей БД. Это можно сделать в интеграционном решении.

Prometeusll wrote:Проще добавить новую запись в БД(База данных), чем обновить существующую, на таких объёмах данных это практически невозможно сделать. - дайте пользователю, который создал ВСД - удалить это ВСД! Даллее по расписанию регламентным заданием очищать БД от удаленных ВСД. БД меньше будет разраста́ться и не загибаться.

Чем вас аннулирование ВСД не устраивает?

Чем вас аннулирование ВСД не устраивает?

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

[quote=Сергеевна-Я]Чем вас аннулирование ВСД не устраивает?

Отвечу:
ВСД создан и уже принят системой приёмки у клиента, и вдруг обнаруживается ошибка. Я аннулирую ВСД, и создаю новый, НО у клиента в базе остаётся старый всд, так как идёт ещё и привязка к связанным докам (например заказ).
Т.е когда я создаю новый ВСД- нужно тогда и электронное уведомление обновить, водителю позвонить и сказать-Это ВСД не отдавай, оно не правильное, Вот фото Нового.
и много ещё чего....[/quote]

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

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

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

[quote=Сергеевна-Я]Чем вас аннулирование ВСД не устраивает?

Отвечу:
ВСД создан и уже принят системой приёмки у клиента, и вдруг обнаруживается ошибка. Я аннулирую ВСД, и создаю новый, НО у клиента в базе остаётся старый всд, так как идёт ещё и привязка к связанным докам (например заказ).
Т.е когда я создаю новый ВСД- нужно тогда и электронное уведомление обновить, водителю позвонить и сказать-Это ВСД не отдавай, оно не правильное, Вот фото Нового.
и много ещё чего....[/quote] что-то мне не ясно, если ВСД аннулировать то и у получателя он не будет виден, если получатель уже погасил ВСД то вам его уже нельзя аннулировать. Водителю достаточно уникальный код новый скинуть и все. даже если он отдаст аннулированый ВСД его в любом случае не смогут погасить...

Вряд ли они что поменяют в пользу пользователей меркурия.У тех кто использует программы интегрирующие 1С с Меркурием с этим нет проблем.Ну по крайне мере у некоторых стоит блокировка.Программа не даст выписать.Единственное производственные могут просроченные сделать.Но она дальше никуда отправиться.Они не могут с возвратными решить.Как отправляли сети возвратные с граммами так отправляют. По сотни в день приходят.

Практически полностью согласен с предложениями в первом посте. Некоторые пункты настолько очевидны, что не понимаю почему это не реализовано. К примеру предложение #1.

snogl wrote:Практически полностью согласен с предложениями в первом посте. Некоторые пункты настолько очевидны, что не понимаю почему это не реализовано. К примеру предложение #1.

Да потому-что систему на коленке делали. Плюс распилинг и откатинг.

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

[quote=eLIASS][quote=Сергеевна-Я]Чем вас аннулирование ВСД не устраивает?

Отвечу:
ВСД создан и уже принят системой приёмки у клиента, и вдруг обнаруживается ошибка. Я аннулирую ВСД, и создаю новый, НО у клиента в базе остаётся старый всд, так как идёт ещё и привязка к связанным докам (например заказ).
Т.е когда я создаю новый ВСД- нужно тогда и электронное уведомление обновить, водителю позвонить и сказать-Это ВСД не отдавай, оно не правильное, Вот фото Нового.
и много ещё чего....[/quote] что-то мне не ясно, если ВСД аннулировать то и у получателя он не будет виден, если получатель уже погасил ВСД то вам его уже нельзя аннулировать. Водителю достаточно уникальный код новый скинуть и все. даже если он отдаст аннулированый ВСД его в любом случае не смогут погасить...[/quote]

1)Работа не через интерфейс.В 1С я вижу все ВСД оформленные в мой адрес(даже аннулированнные поставщиком), система цепляет сразу после нажатия вами оформить
2)фото водителю- это QR-код
3) Знаете ли вы,что многие на приёмке товара даже не открывают Мерк-только в своей учётной системе сидят, и если у них что-то Красненьким горит- отказ в приёмке-хотя ВСД оформлен.
3) Правило торговли:Клиент всегда прав никто не отменял....даже 589 приказ, до введения Мерка все контрагенты присылали свои толмуты о правилах приёмки- не смог подстроится- Досвидос!