gifts2017

UTM Proxy для УТМ ЕГАИС (или как не пропустить дубль алкогольной марки)

Опубликовал Сергей (nettoxic) в раздел Оборудование - ККМ

Что такое УТМ прокси? Это отдельное программное обеспечение, которое ставится между вашей кассовой учетной системой или любой другой кассой и УТМ ЕГАИС. Чеки, передаваемые с кассы или УС, сначала попадают в УТМ Прокси и далее, если такая марка ранее не продавалась, то отправляет эту марку в сам УТМ, предварительно записав её в свою базу данных. Если же данная марка есть в БД УТМ прокси, то такая марка до УТМ ЕГАИС не дойдет, и на кассе будет выдана ошибка с аннулированием такого чека. Аналогично УТМ прокси работает и с возвратами алкогольной продукции. Если происходит возврат и данная алкогольная марка присутствует в БД УТМ прокси, то такой возвратный чек пройдет дальше в УТМ ЕГАИС. Если же в базе данных УТМ прокси такой марки нет, то УТМ прокси не пропустит такой чек в УТМ ЕГАИС.

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

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

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

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

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

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

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

Как пользоваться.

Запускать можно со следующеми параметрами:
UTMProxy.exe -hide [UTM Host] [UTM Port] [Listen port]
(Пример: UTMProxy.exe -hide 192.168.1.1 8080 888)

где

UTM Host - IP адрес на котором работает УТМ ЕГАИС

UTM Port - порт на котором работает УТМ ЕГАИС (по умолчанию 8080)

Listen Port - порт на котором работает сам УТМ прокси (Этот порт и ip компьютера на котором запущен УТМ прокси необходимо прописать в настройки кассы вместо ip и порта самого УТМ ЕГАИС).

История изменений:

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. Исправлена ошибка отправке сообщения кассе, ранее в кассу сообщение отправлялось через раз.

v.0.1beta

Что умеет UTM Proxy?

1. При продаже записывает ШК марки к себе в файл.

2. Не пропускает ШК марки, которую уже продали.

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

4. При возврате проверяет - продавалась ли данная бутылка или нет.
В случае, если бутылка ранее с кассы не продавалась, вернуть не получится.

233000 марок - время обработки при продаже менее ~2 секунды с учетом обработки чека самим УТМ
233000 марок - время обработки при возврате менее ~2 секунды с учетом обработки чека самим УТМ

Тестирование производилось на VM с выделенным однопроцессорным ядром, работающем на 70%, 512Мб ОЗУ, WinXP.

Скачать файлы

Наименование Файл Версия Размер
UTMProxy0.7.4 11
.zip 790,54Kb
08.12.16
11
.zip 0.7.4 790,54Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Алексей (pablo_escobar) 16.11.16 15:18
В случае, если бутылка ранее с кассы не продавалась, вернуть не получится.
Ситуация продали бутылку вчера, сегодня ставим этот "прокси", приходит клиент хочет вернуть, марки соответственно нет в базе, и вернуть не получится. Что с остальными документами (WAYBILL и др)? они просто переправляются через прокси в УТМ?
РАР анонсировал новый механизм контроля целостности, когда УТМ будет во время подписания чека проверять связь с кассой, которая прислала чек, в этом случае сверяться будет с прокси, и УТМ не узнает что касса отвалилась.
2. Сергей (nettoxic) 16.11.16 15:40
(1) pablo_escobar, Тут начало сбора марок это стартовая точка. Конечно если в БД нет этой марки, то УТМ прокси пропустит такую продажу, но со временем все встанет на места свои, когда БД разрастется. Остальные документы просто переправляются через УТМ прокси. С новыми анонсированиями РАРа тоже всё в порядке инициатор - это касса если касса отвалится значит УТМ прокси тоже отсоединяется от УТМ, УТМ узнает что касса отвалилась.
3. Василий (malinko.vasiliy) 16.11.16 15:46
Интересно. Нужен механизм загрузки имеющейся базы проданных марок в базу SQLite, возможно? Еще интересует другая сторона: выгружаем все имеющиеся на складе марки, база при продаже проверяет, есть ли такая марка в базе, проверяет продана ли она и только тогда разрешает продажу. (страхуемся от диверсантов от конкурентов)
Совместимость с UTM 2.0.4 планируется делать?
4. Максим Радченко (coolseo) 16.11.16 15:51
Демо версия работает с БД не более 500 марок.

Что происходит когда в базе больше 500 марок, база перезаписывается?
Как купить полную версию?
5. Василий (malinko.vasiliy) 16.11.16 15:54
Про скорость. Продажа с базой 233000 марок 2 сек. Это если в чеке 1 бутылка? При продаже 80 бутылок какая задержка?
6. Максим Радченко (coolseo) 16.11.16 15:54
(3) По идеи можно выгрузить из 1ски напрямую, в базу SQLite
Опишите пожалуйста более подробно механизм работы программы.
7. Сергей (nettoxic) 16.11.16 16:29
(3) malinko.vasiliy, механизм загрузки имеется внутри дистрибутива там файлик есть txt2sqlite.exe, вот им можно все загнать в БД. формат txt файла обычный: марка с каждой строки. С УТМ 2.0.4 совместим.
8. Сергей (nettoxic) 16.11.16 16:29
(5) malinko.vasiliy, нет. в чеке не имеет значение сколько марок. хоть 100
9. Сергей (nettoxic) 16.11.16 16:33
(6) coolseo, первоначально БД УТМ прокси пуста, по мере накапливания марок БД ростет, и соответственно каждый раз при добавлении в БД марка проверяется - есть ли такая марка уже в БД, если в БД марка есть, то такой чек до УТМ ЕГАИС не дойдет. Тоже самое и с возвратами - только при возвратных чеках с БД марка удаляется.
10. Сергей (nettoxic) 16.11.16 16:37
(3) malinko.vasiliy, в принципе можно придумать обратный механизм, возьмем базу с 1000 марками, и при продажи марка будет искаться в этой 1000 марок, далее при нахождении этой марки чек передается в УТМ и марка удаляется с БД, если же марка не находится в этих 1000 марок, то такой чек до УТМ ЕГАИС не долетает. Ну и с возвратами тоже самое.
11. Сергей (nettoxic) 16.11.16 17:10
Да и еще, про механизм работы УТМ прокси. Марка записывается в БД (при продаже) или удаляется с БД (при возврате) только, когда УТМ ЕГАИС подписывает чек, т.е. на чек приходит <SIGN> тэг.
12. Василий (malinko.vasiliy) 16.11.16 17:24
Уточните, дистрибутив во вложении полнофункционален? Или есть ограничения 500 марок (как писали в 4)?
Если есть, где взять полный дистрибутив?
13. Сергей (nettoxic) 16.11.16 17:31
(12) malinko.vasiliy, есть ограничение на 500 марок. Для получение полного пишите на u_saya@pisem.net
14. Алекс Алекс (gigabyte-leha@yandex.ru) 16.11.16 20:04
15. Антон Азанов (Djelf) 16.11.16 23:31
Не претендую на истину, но...
Почему такая древняя либа sqlite 3.5.4? Она режим wal не умеет, а он сильно ускоряет запись... Да и вообще движок за 9 лет быстрее стал...
CREATE TABLE barcode (ID INTEGER PRIMARY KEY, BARCODE TEXT)
CREATE INDEX bcode ON barcode(BARCODE ASC)

ID INTEGER PRIMARY KEY нужен только чтоб rowid не сбивалось при VACUUM, но у нас есть другая уникальность - марка!
Affinity TEXT будет прогоняться через юникодовое сравнение, а в марке нет юникодных символов, BLOB будет чуток быстрее, особенно на 233000 марках
Индекс не уникальный, поэтому без гарантии дубликатов и просмотр всей таблицы без limit 1
Зачем нужна сортировка (BARCODE ASC)? Это дополнительная нагрузка на базу.
Поэтому как то вот так можно упростить
CREATE TABLE barcode (PRIMARY KEY BARCODE BLOB)
Не проверял, но 2с на выборку одной марки из 233000 это довольно долго!
16. Максим Радченко (coolseo) 17.11.16 02:37
Я так и не понял что происходит в демо версии после заполнения 500 марок?
Для маленьких ларьков как раз на 1 месяц будет хватать.
17. Сергей (nettoxic) 17.11.16 10:19
(15) Djelf, спасибо, подумаем над ускорением записи в БД. А БД проверялась именно на такой цифре, по времени все ок. Без индекса почему-то намного медленнее работает.
18. Сергей (nettoxic) 17.11.16 10:20
(14) gigabyte-leha@yandex.ru, да, только это бета версия 0.4 и она возвраты не поддерживает и многопоточность.
19. Алекс Алекс (gigabyte-leha@yandex.ru) 18.11.16 17:14
20. Сергей (nettoxic) 18.11.16 17:16
(15) Djelf, 2 секунды на выборку 80 марок в чеке с базой 250 тыс. Это с учетом что еще какоето время нужно самому УТМу ЕГАИС на их обработку и выдачу слипа. Думаю если база будет около 1млн марок - время не сильно изменится. т.к. с пустой базой это время примерно такое же.
21. Сергей (nettoxic) 18.11.16 17:21
(19) да и что?? Это демо версия, такая же как я выложил и тут.
22. Сергей (nettoxic) 18.11.16 17:22
(19) Она только работает с 500 марок в БД, для получения лицензии писать на почту (см. выше).
23. Сергей (nettoxic) 18.11.16 17:26
Новое в версии 0.7:

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

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

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

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

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

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

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

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

24. Антон Азанов (Djelf) 20.11.16 20:18
(20) Да не должно. Просто меня 2 секунды в описании убили наповал. Проверил для интереса... Нагенерил 10 миллионов марок ~2гб база.
Проверка марки - 1мс. Вставка/Удаление - 33мс.
Поправь в описании, что 2-3с это с учетом обработки чека в УТМ, а количество марок в базе sqlite вообще на скорость не влияет.
25. Сергей (nettoxic) 21.11.16 09:29
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа