Защита от повторного сканирования АМ

[anamedved]

Доброго времени суток.

Уже 10 дубль. В голову продавцам не влезешь и всех не переувольняешь...
Самый разумный вариант, на мой взгляд, - ведение базы данных реализованных АМ на уровне ПО магазина и принудительная блокировка в режиме реального времени в момент при повторной продаже. Есть ли у кого инфо о такой возможности, уже реализованной разработчиками кассового ПО? Знаю на УКМ 4.0 есть проверка трех последних чеков, но это не вариант - дубли и через неделю с первой продажи обнаруживали. Или есть возможность такое ПО как-то написать, за разумное денежное вознаграждение? Help!

[stn]

Так у всех же кассовое ПО разное.
В SET Retail от Кристала реализована такая проверка, не сразу, но сделали.

[igor1971]

это легко реализуется.
я где-то на форуме выкладывал для 1 с розницы изменения (для старой версии) чтобы вести свою внутреннюю нумерацию чеков и номеров смен. подобным же образом сохраняется номер проданной марки в файл, а при продаже проверяется.
сам я не реализовал, потому что боюсь, что через несколько месяцев, не говоря про годы, проверка будет занимать много времени. тупить при продаже начнет.
в последнем релизе 1с розницы - вообще элементарно. в одном месте формирование xml файла. там все очевидно.
можно не мудрить с блокировкой продажи, а просто заблокировать отправку в ЕГАИС. если сотрудники тупые - пусть и платят виртуальную недостачу. и наказание и урок будет.

[anamedved]

Так у всех же кассовое ПО разное.
В SET Retail от Кристала реализована такая проверка, не сразу, но сделали.

А какой период они контролируют? Кассовую смену, неделю, месяц?

[anamedved]

это легко реализуется.
я где-то на форуме выкладывал для 1 с розницы изменения (для старой версии) чтобы вести свою внутреннюю нумерацию чеков и номеров смен. подобным же образом сохраняется номер проданной марки в файл, а при продаже проверяется.
сам я не реализовал, потому что боюсь, что через несколько месяцев, не говоря про годы, проверка будет занимать много времени. тупить при продаже начнет.
в последнем релизе 1с розницы - вообще элементарно. в одном месте формирование xml файла. там все очевидно.
можно не мудрить с блокировкой продажи, а просто заблокировать отправку в ЕГАИС. если сотрудники тупые - пусть и платят виртуальную недостачу. и наказание и урок будет.

Спасибо, попробуем как вариант.

[igor1971]

тоже попробую, но раз в 3 месяца буду обнулять файл с номерами марок. может и раз в месяц придется обнулять- надо тестировать. хоть какая-то защита от дурака.

[stn]

Так у всех же кассовое ПО разное.
В SET Retail от Кристала реализована такая проверка, не сразу, но сделали.

А какой период они контролируют? Кассовую смену, неделю, месяц?

Всю базу. Марки копятся, проверка по всем накопленным маркам.

[igor1971]

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

[stn]

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

Вам в 1с надо таблицу делать.
И в ней учитывать, продажа это или возврат (количество марок, 1 или -1). А разрешать/запрещать по сумме. Т.е., <=0 - только продать, > 0 - только вернуть.
И нельзя ограничивать 3 месяцами, я думаю.

[igor1971]

да не хочу я в 1с таблицу делать. там обновления со скоростью пулемета выходят. ЕГАИС этот, каждый месяц правила игры меняет.
есть риск просто не обновиться, если кардинальные изменения в конфигурацию внести.
я на вскидку про 3 месяца говорю. надо смотреть через 3 месяца на сколько будет тупить при продаже.
если меньше секунды - фигня. можно и увеличить срок.