UTM Proxy (не пропустите дубль АМ и недостачу на кассе+Контроль МРЦ)

[1ctoxic]

Добрый день!
К продолжению темы "Защита от повторного сканирования АМ" viewtopic.php?f=4&t=5569

Как это работает?

УТМ прокси - это универсальное программное обеспечение для борьбы с дублями марок алкогольной продукции при розничной продажи. Данное программное обеспечение - это своего рода "прокладка" между кассовым ПО и УТМ ЕГАИС. UTM Proxy работает с любыми кассами, вот некоторые из них: miniPOS, рабочие места кассиров в конфигурациях 1С (в том числе и базовые версии), Фронтол и другие...

Основные преимущества UTM Proxy по сравнению с другими обработками и ПО подобного рода

1. Единая база марок на все кассы в торговой точке

2. Единая база марок на несколько УТМ ЕГАИС (при запуске в режиме "Ферма")

3. Высокая скорость обработки чеков и добавление марок в базу.

4. Нет необходимости изменять кассовое ПО для работы с UTM Proxy.

5. Предусмотрена функция онлайн проверки марок на сервере UTM Proxy.

Для чего нужен UTM Proxy?

Повторная продажа алкогольной продукции с одним и тем же штриховым кодом является нарушением порядка учета розничной продажи алкогольной продукции. Ответственность за нарушение порядка учета алкогольной продукции установлена статьей 14.19 Кодекса РФ об административные правонарушениях, предусматривающей наложение штрафа в размере 150-200 тысяч рублей на юридическое лицо и 10-15 тысяч рублей на должностное.

Вы наверное спросите: "Но ведь в новой версии УТМ 2.0.4 уже реализована такая проверка, зачем UTM Proxy?"

Ответ прост. Нужно представлять, что в ЕГАИС УТМ 2.0.4 указанная проверка марок на дубли не дает гарантии того, что Вами не заинтересуются контрольные органы, если Вы будете пытаться часто продать дубли.
По сообщениям представителей ФСРАР, все попытки продаж дублей будут фиксироваться службой и участвовать в контрольной деятельности при проверки организации представителями ФСРАР. При этом к Вам эта информация о Ваших попытках продать дубль не будет поступать в личный кабинет ФСРАР.



Наибольший процент двойных продаж (дублей марок) в одной торговой точке (или в двух разных) - это проблема персонала.

Самые популярные варианты:

1) Бутылки рядом с кассой используют специально для сканирования АМ.
(в одной торговой точке так можно "пикнуть" бутылку несколько раз)

2) Разбили бутылку, "пикнули" другую бутылку - скрыли факт боя.
(пошли в другой магазин, купили бутылку, поставили на продажу в своем магазине)

3) Закупают продукцию в других торговых точках, а далее продают в своих торговых точках.

4) Невнимательность продавцов, нет должной организации процесса.

Что умеет UTM Proxy?

1. Не пропускает в УТМ ЕГАИС чеки со штрих-кодами марок, которые уже были проданы ранее.

2. Не пропускает в УТМ ЕГАИС возвратные чеки со штрих-кодами марок, которые ранее не продавались.

3. Добавлен режим выгрузки в базу данных УТМ прокси по поступлению (реверс) (см. историю изменений в версии 0.7)
(3 пункт только для торговых точек, которые ведут учет марок при поступлении в своих учетных системах)

4. Добавлен новый режим "Блокировать недостачу"
(см. историю изменений в версии 0.8)

5. Блокировать продажу в запрещенное время продажи алкогольной продукции.

6. Он-лайн проверка марок на сервере UTM Proxy.


Как происходит отправка чека без УТМ прокси?

Кассовое ПО отправляет чек напрямую в УТМ ЕГАИС не задумываясь о возможных дублирующих марках.

Как происходит отправка чека с УТМ прокси?

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

2. Если УТМ прокси примет от кассы возвратный чек с маркой, то такой чек сверяется с базой данных УТМ прокси и если марка есть в базе осуществляется передача возвратного чека далее в УТМ ЕГАИС (соответственно тут УТМ прокси ожидает слип чека от УТМ ЕГАИС), в противном случае УТМ прокси блокирует такой чек и до УТМ ЕГАИС он просто не доходит.

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

4. Режим блокировки недостачи не позволит осуществить продажу товара, если в торговом зале (Регистр 2) остаток по данному алко-коду нулевой или имеет не обеспеченный расход.

5. Режим "Разрешить продажу" позволяет установить время в которое можно осуществлять продажу АП. В другое время такие продажи будут блокироваться.

6. Режим "Он-лайн проверки марок" в добавок с проверкой по локальной БД позволяет осуществлять проверку на онлайн сервере UTM Proxy.


ИСТОРИЯ ИЗМЕНЕНИЙ
v.1.0.0 (stable)
1. Добавлен значок доступности онлайн сервиса

2. Добавлено дополнительное логирование

v.0.9.9
1. Включена поддержка касс использующих механизм постоянного соединения (keep-alive)

v.0.9.8
1. Добавлена возможность записи сокращенного лог файла.
(подробнее смотрите инструкцию к UTM Proxy стр. 6)

2. Добавлена онлайн проверка марок через сервер UTMProxy. (тест. режим)

v.0.9.7

1. Изменен формат лог файла на UTMProxy_yyyy_mm_dd.log

2. В БД начали добавляться имена торговых точек первоначальной продажи марки.

3. При обнаружении дубля марки в сообщении для касс теперь выводится имя торговой точки, где была продана марка (первоначально).

4. В утилите txt2sqlite в функцию загрузки/выгрузки добавлено имя торг.точки.

5. Добавлена возможность запуска UTM Proxy как службы Windows.
(подробнее смотрите инструкцию к UTM Proxy стр. 6)

6. Добавлена функция блокировки проверки марок в УТМ 2.0.4

v.0.9.6 (build 2)

1. Отменена блокировка продажи по времени при отключенной "галочки" - "Разрешить продажу".

2. При включенном режиме "Блокировать недостачу" старые марки перестали блокироваться
(из старых марок нельзя однозначно вычислить алко-код АП)

3. Обновлена утилита txt2sqlite и документация к UTM Proxy.
(подробнее см. Документацию к UTM Proxy)

v.0.9.5

1. Добавлена "галочка" запрета на продажу АП по времени
(пример: только с 10 часов до 22 часов).

2. Исправлена ошибка в обработке чеков состоящих из одной, длинной строки.

3. В БД начали добавляться номера касс первоначальной продажи марки.

4. При обнаружении дубля марки в сообщении для касс теперь выводится номер кассы, где была продана марка (первоначально).


v.0.9.4

1. В БД начали добавляться даты продажи марок.

2. При обнаружении дубля марки в сообщении для касс теперь выводится дата продажи марки.

3. Добавлена погрешность в параметры оборудования при лицензировании.

4. Улучшение быстродействия обработки чеков

5. Исправлены ошибки при автоматическом обновлении ПО

6. Добавлена кнопка сжатия БД.

v.0.9.2 - 0.9.3 - Версии отозваны (При долгой или интенсивной работе происходит переполнение стека)

v.0.9.1

1.Исправлена ошибка возникающая в режиме работы "Ферма".
"Ферма" - режим работы двух или более УТМ ЕГАИС с одной базой UTM Proxy.

2. Добавлен запрет на запуск более одной копии ПО. Для запуска в режиме "Ферма" должны использоваться дополнительные параметры запуска.

v.0.9

1. Оптимизирована обработка чеков.
(Тестирование показало что, на данный момент добавление 1000 марок из чека в БД размером 300тыс. АМ происходит за 4 секунды.

2. Лог файл начал делится по дням.

3. Добавлена парольная защита для основной формы ПО.
(ВНИМАНИЕ, Для перехода с версии 0.7.3 и выше - на версию 0.9 необходимо через утилиту txt2sqlite удалить таблицу конфигурации)

v.0.8a

1. Незначительные изменения добавлен параметр RESTS (см. выше параметры запуска)
Поле Memo теперь вместо "абрыкатабры" выводи русские буквы при обработки ответов/запросов УТМ прокси.


v.0.8 - ВНИМАНИЕ!
Для перехода с версии 0.7.3 и выше - на версию 0.8 необходимо через утилиту txt2sqlite удалить таблицу конфигурации.


1. Добавлен новый режим "Блокировать недостачу"

Описание алгоритма "Блокировать недостачу":

a. Методом УС запрашиваются остатки по Торговому залу (регистр 2)
b. Методом УС загружаются данные по остаткам в Торговом зале (регистр 2) (обязательно через УТМ прокси!)
c. При получении УТМ прокси такого пакета данных, все алко-коды (19 значные) и остатки по этому алко-коду записываются в
отдельную таблицу БД (назавём её ShopRests с двумя полями AlcoCode и Quantity).
d. При продаже на кассе, из марки высчитывается алко-код и сверяется с алко-кодом из таблицы ShopRests, если поле Quantity больше
0, то такая марка пропускается в УТМ ЕГАИС и при получении слипа уменьшается Quantity на "1". В противном случае такой чек
блокируется УТМ прокси, с отправкой ошибки о блокировки в кассу.

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

v.0.7.6

1. Исправлена незначительная ошибка при включенном режиме "реверс",
ранее в StatusBar'e некорректно отображалось поле "Количество марок в БД" при возврате и продаже.

2. Устранена незначительная загруженность ЦП при отключенной галочки "Сворачивать при запуске в Tray"

v.0.7.5

1. Добавлена функция автоматического обновления UTM Proxy.
(С этой функцие начал ругаться drweb на какого-то трояна,
сейчас ведем переписку с drweb о ложном срабатывании)

v.0.7.4 (build 4)

1. При запуске стала блокироваться БД УТМ прокси от внешних воздействий.

2. Устранена ошибка с кассами, которые отсылаю в заголовке "Connection: Keep-Alive"

3. Добавлено дополнительное логирование, для выявления возможных проблем.

v.0.7.4

1. Устранена ошибка работы УТМ прокси при использовании параметра -hide

v.0.7.3a

1. Добавлена возможность включения/отключения записи лог файла.
(Для перехода с версии 0.7.3 на версию 0.7.3а необходимо через
утилиту txt2sqlite_v073 удалить таблицу конфигурации)

v.0.7.3

1. Настройки УТМ прокси теперь хранятся в отдельной таблице БД

v.0.7.1a

1. Исправлена ошибка в StatusBar (при запуске ПО с параметрами - не обновлялся текст "Нет соединения с УТМ".

2. Устранены мелкие недочеты по форме ПО.

v.0.7.1

1. Добавлена возможность "сворачивать"/"разворачивать" в/из трея windows.

2. В windows 10 устранена проблема с лицензированием ПО.
ВНИМАНИЕ! Требуется перегенерация лицензии.

v.0.7

1. Добавлен режим выгрузки в БД по поступлению (реверс)

Как работает:

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

Прокси находит марку, читает поле "Остаток". Если 1 разрешает продажу и обнуляет поле,
если 0 - запрещает продажу.

Таким образом если в БД нет марки, которая числится на остатке прокси продать не даст.

При возврате прокси находит марку, читает поле "Остаток". Если 0 разрешает вернуть и
изменяет поле "Остаток" на 1, если 1 или в БД прокси нет марки - запрещает вернуть.

2. Обновлена библиотека SQLite

3. Добавлено поле "OST" - Остаток, изменен тип поля BARCODE с TEXT на BLOB.

Внимание!!! Для работы с предыдущими версиями БД необходимо добавить/изменить поля указанные в пункте 3,
или воспользоваться утилитой txt2sqlite (входит в комплект поставки)

v.0.5

1. В сообщении о дубле добавлен Алко-код продукции, тот который 19-значный.

2. В сообщении о дубле добавлена визуальная идентификация АМ. (20 символ марки с длинной 18)

3. Сообщения о дубле марки стали на русском языке.

4. Устранена избыточная загрузка CPU (в некоторых случаях) при обращении нескольких касс.

5. Добавлена возможность работы с несколькими УТМ одновременно,
марки сохраняются в одну БД УТМ прокси с нескольких УТМ'ов.
(ранее это возможность была, но при обращении одновременно к БД УТМ прокси, из-за открытой транзакции
одна из марок не записывалась в БД УТМ прокси)

6. Исправление незначительных ошибок.

v.0.4 beta

1. База штрихкодов перенесена на SQLite

2. Исправлена ошибка работы прокси с двумя и более кассами одновременно

3. Произведена оптимизация и увеличено быстродействие.

4. Добавлен лог файл.

5. Исправлена ошибка отправке сообщения кассе, ранее в кассу сообщение отправлялось через раз.

[pspbelru]

Исходный код можно включить в архив? Или это секрет?

[slider]

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

[1ctoxic]

1. Исходный код дать пока не можем. т.к. пишем для заказчика.
2. Если несколько магазинов, то на каждый магазин придется ставить отдельно. - исправлено, можно вести все в одной БД

3. Полный процесс: если прокси находит передаваемый пакет с чеком, то сверяет со своей БД (БД конечно это сложно назвать обычный txt), если такой марки нет в БД, то прокси туда эту марку помещает. Если же марка в БД присутствует, то в УТМ этот чек не попадает,а прокси сообщает кассе об ошибке. Точно так же и с возвратами, только наоборот: если делается возврат и в БД нет такой марки, то такой чек (возврат) до УТМа не дойдет, если же в БД есть такая марка, то возврат сделать получится и с БД данная марка удаляется. Единственное НО, пока не могу придумать многопоточность проверок чеков. т.е. если в одно время две кассы отсылают чек. Пока данная проблема решается только запуском еще одного процесса Прокси УТМ на отличном порту.

[milukoff]

1. Исходный код дать пока не можем. т.к. пишем для заказчика.
2. Если несколько магазинов, то на каждый магазин придется ставить отдельно.

3. Полный процесс: если прокси находит передаваемый пакет с чеком, то сверяет со своей БД (БД конечно это сложно назвать обычный txt), если такой марки нет в БД, то прокси туда эту марку помещает. Если же марка в БД присутствует, то в УТМ этот чек не попадает,а прокси сообщает кассе об ошибке. Точно так же и с возвратами, только наоборот: если делается возврат и в БД нет такой марки, то такой чек (возврат) до УТМа не дойдет, если же в БД есть такая марка, то возврат сделать получится и с БД данная марка удаляется. Единственное НО, пока не могу придумать многопоточность проверок чеков. т.е. если в одно время две кассы отсылают чек. Пока данная проблема решается только запуском еще одного процесса Прокси УТМ на отличном порту.

А какая проблема с многопоточностью? На этапе проверке в файле? или на этапе прослушивания коннектов? Т.е. проблема в монопольном доступе к файлу? (В прочем я это ранее озвучивал чем плох файл для хранения такого типа информации), или же порт занят и не дает соединиться другим кассам? Установка подразумевается на сервере УТМ или на кассе? Как прокси пропускает другие запросы к УТМ (не от касс)?

[1ctoxic]

А какая проблема с многопоточностью? На этапе проверке в файле? или на этапе прослушивания коннектов? Т.е. проблема в монопольном доступе к файлу?
(В прочем я это ранее озвучивал чем плох файл для хранения такого типа информации), или же порт занят и не дает соединиться другим кассам?

С портом как раз таки все нормально. А вот на этапе проверки - в массив заполняются марки с чека, если при заполнении начнет подключатся другое соединение (для передачи чека) к ПО, то этот массив обнуляется по условию и тем самым заполнение массива происходит не корректно. Тоже самое происходит и с переменным "флажками", т.е. нужные переменные обнуляются, тем самым первый поток может отработать не верно. Если же сделать ожидание на 1 соединение, т.к. пока однин поток не отработает другой находится в ожидании, то происходит проблема с многопоточными запросами. т.е. тупо браузером нельзя будет открыть страницу УТМ через прокси.

Про доступ к файлу, тут как раз проблем нет, ПО может при записи проверять есть ли доступ к нему или нет в цикле,

Установка подразумевается на сервере УТМ или на кассе?

тут без разницы.

Как прокси пропускает другие запросы к УТМ (не от касс)?

тут тоже всё хорошо. проблема происходит именно при передаче двух и более чеков одновременно!

Единственным решением вижу пока - вместо переменных "флажков" использовать массив, а вместо одномерного массива использовать двумерный с передачай в такую матрицу параметра с номером потока.

[milukoff]

А какая проблема с многопоточностью? На этапе проверке в файле? или на этапе прослушивания коннектов? Т.е. проблема в монопольном доступе к файлу?
(В прочем я это ранее озвучивал чем плох файл для хранения такого типа информации), или же порт занят и не дает соединиться другим кассам?

С портом как раз таки все нормально. А вот на этапе проверки - в массив заполняются марки с чека, если при заполнении начнет подключатся другое соединение (для передачи чека) к ПО, то этот массив обнуляется по условию и тем самым заполнение массива происходит не корректно. Тоже самое происходит и с переменным "флажками", т.е. нужные переменные обнуляются, тем самым первый поток может отработать не верно. Если же сделать ожидание на 1 соединение, т.к. пока однин поток не отработает другой находится в ожидании, то происходит проблема с многопоточными запросами. т.е. тупо браузером нельзя будет открыть страницу УТМ через прокси.

Про доступ к файлу, тут как раз проблем нет, ПО может при записи проверять есть ли доступ к нему или нет в цикле,

Установка подразумевается на сервере УТМ или на кассе?

тут без разницы.

Как прокси пропускает другие запросы к УТМ (не от касс)?

тут тоже всё хорошо. проблема происходит именно при передаче двух и более чеков одновременно!

Единственным решением вижу пока - вместо переменных "флажков" использовать массив, а вместо одномерного массива использовать двумерный с передачай в такую матрицу параметра с номером потока.

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

Код: Выбрать все

using (Socket clientSocket = new Socket(AddressFamily.InterNetwork
                                                    , SocketType.Stream
                                                    , ProtocolType.Tcp))
                {
                 byte[] buf = new byte[ReceiveBufferSize];
                 DosCashMessage request = new DosCashMessage();
                ...
                if (clientSocket.Connected) //If connected
                    {
                        // Send request to Loyalty server
                        try
                        {
                            clientSocket.Send(request.GetBuffer()
                                            , request.MessageLen + 4
                                            , SocketFlags.None);
                        }
                        catch (Exception e)
                        {
                            throw new ApplicationException(Res.SendError, e);
                        }
                        ...
                        // Receive answer from Loyalty server
                        try
                        {
                            int bytesRead = clientSocket.Receive(buf, 0, buf.Length, SocketFlags.None);
                            while (bytesRead != 0)
                            {
                            ...
                            }
                        }


Код: Выбрать все

byte[] buf = new byte[ReceiveBufferSize];

- срок жизни buf - на текущее соединение, и внутри соединения, 1 клиент, подключенный к сокету - один экземпляр buf. А дальше внутри кода что хочешь то и делай с ним. Зачем использовать на все коннекты один общий статический класс/массив?! ну объявил к примеру DosCashMessage класс, внутри коннекта создал экземпляр, отработало соединение - ну там в зависимости от языка - он либо умрет сам (поработает сборщик мусора), либо надо убивать... Использовать общие глобальные переменные/массивы/классы при многопоточности это зло! И это противоречит правилам ООП. Хотя, к примеру, в .net для таких целей есть [b]BlockingCollection[b]

Код: Выбрать все

private static BlockingCollection<BlockCouponsRow> сouponsToBlock;

- пример, думаю подобное есть и в Delphi (давно уже на нем не писал). И уж, тем более, если несколько потоков лезут в одно и то же место, и используется не потокобезопасные типы данных, - странно, что не попались еще на deadlock.

[vladkoff]

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

[milukoff]

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

как и раньше, в чем проблема то? касса-прокси-утм стало, касса-утм - было. Интернет где? За УТМ, поэтому от кассы через прокси всё ушло в УТМ также как и если бы не было прокси. Как раз интернет то вообще не при делах.

[1ctoxic]

[quote="vladkoff"]Добрый день. задумка очень даже неплоха.
но есть вопрос. а как быть в случае часто отваливающегося инета? (имеем gsm модем)
как тогда будет вести себя разработка?
касса как бы уже распечатала чек, а в егаис пакет не смог уйти.[quote]
если касса распечатала чек, значит в УТМ уже этот чек попал. причем тут сервер ЕГАИС?!