Сервер валидации СуперМарко предназначен для контроля продажи маркированных товаров любых типов (в том числе, и алкоголя).

СуперМарко получает информацию из торговой системы о товарах с КиЗ, которые могут быть реализованы через кассы. Таким образом, в СуперМарко хранится "связка" штрихкода определенного товара и его марки КиЗ. При считывании КиЗ товара на кассе в процессе продажи или возврата, касса отправляет запрос на проверку возможности продажи/возврата считанного КиЗ, а сервер валидации обрабатывает такие запросы. В СуперМарко также хранится информация об уже проданных КиЗ, что позволяет серверу передавать в УКМ информацию о товарах, которые невозможно продать. Помимо этого, СуперМарко выгружает информацию об ошибках, возникших в процессе обработки запросов с касс и при приёме информации из торговой системы.

Архитектура

В торговой сети может быть установлено несколько серверов валидации. Каждый сервер валидации обслуживает один или несколько магазинов. Один магазин обслуживается только одним сервером валидации. Серверы валидации независимы друг от друга.

Взаимодействие с ТС

Предполагается следующая процедура обмена информацией:

- торговая система (ТС) делает выгрузку в СВ информации о поступивших КИЗ с исходным состоянием «не продан»

- при продаже КИЗ на кассе состояние в СВ меняется на «продан» (при возврате на кассе статус меняется на «не продан».

- информация о продаже КИЗ передается из кассовой системы в ТС стандартным образом в составе кассовых чеков (через xml-конвертор)

- на основании этой информации ТС изменяет в своей базе информацию о состоянии КИЗ.

Таким образом, возможна рассинхронизация информации о состоянии КИЗ между СВ и ТС на время доставки чеков от кассы до ТС и их обработки в ТС.

Ограничения

Контроль минимальной цены для алкоголя реализован или на уровне торговой и кассовой системы и/или в УТМ.

Аналитика проблем, возникающих при продаже товаров с КИЗ, производится во внешней системе.

Функциональные требования к СВ

1. Каждая запись о КИЗ может находиться в базе СВ в двух статусах «не продана/продана».
2. Статусы КИЗ могут меняться и торговой и кассовой системой неограниченное количество раз.
3. КИЗ может быть сопоставлен один или несколько кодов, по которому товар может быть введён в чек, т.е. товар должен вводиться в чек и считыванием штрихкода (или выбором артикула) и считыванием КИЗ (например, алкоголь).

Если коды не сопоставлены, то проверка не выполняется.

1. Торговая система должна иметь возможность ограничить продажу/возврат КИЗ одним магазином.

Если магазин не указан, то проверка не выполняется.

1. Необходимо фиксировать историю изменения записи о КИЗ, включая дату-время изменения, параметры чека и документа ТС, которые изменили запись о КИЗ
2. Если ТС загружает КИЗ со статусом «не продан», а в базе СВ КИЗ имеет статус «продан», то в Журнал СВ фиксируется ошибка (но статус КИЗ меняется). Считается, что ТС обладает наиболее правильными «знаниями» о статусе КИЗ.
3. СВ разрешает кассе продать только те КИЗ, которые имеют статус «не продана».
4. СВ разрешает кассе вернуть только те КИЗ, которые имеют статус «продана».
5. В случае ошибок СВ формирует сообщения, которые должна вывести касса:

- при попытке повторной продажи - «Товар с КИЗ (маркой) ХХХХХХ уже был продан»

- при попытке возврата непроданной марки – «Товар с КИЗ (маркой) ранее не был продан»

- «КИЗ (марка) не соответствует товару» (если для КИЗ необходимо проверять код)

- «КИЗ (марка) не может быть продана/возвращена в этом магазине» (если для КИЗ указан магазин).

1. СВ должен иметь параметр, ограничивающий хранение КИЗ в статусе «продана».

Журнал

1. СВ должен формировать Журнал, в котором должны сохраняться сообщения о проблемах, возникающих при продаже товаров с КИЗ.
2. Период хранения информации в Журнале – 2 недели (не настраивается, это всё-таки не продажи)
3. События, которые должны регистрироваться в Журнале, в Приложении 1.

API СВ

1. СВ должен иметь API позволяющее внешней (торговой) системе:

- добавлять КИЗ

- корректировать параметры записи о КИЗ

- удалять КИЗ

- по запросу передавать ТС перечень ошибок записанных в Журнале

- по запросу передавать ТС информацию об истории изменения записи о КИЗ:

- дата-время изменения,

- статус,

- сопоставленные коды товара,

- сопоставленный код магазина,

- ссылка на чек или на ТС.

Требования к кассовой системе:

1. К товарам и/или товарным группам должна быть возможность привязать признак «Товар с КИЗ». Должна быть возможность загружать признак через конвертор импорта (для товаров).

Есть предположение, что не получится обойтись одной универсальной меткой для всех типов товаров с КИЗ. На данном этапе будет добавлена специализированная метка для табачных изделий «Маркированный табак».

1. Должна быть возможность в Типе кассы указать какие товары необходимо проверять в СВ. Сейчас это «Маркированный табак» и «Товар ЕГАИС».
2. Должна быть возможность управлять возможностью проверки КИЗ сразу при вводе товара в чек и/или перед оплатой чека. Момент выполнения проверки должен настраиваться в параметрах кассовой системы (на уровне магазина).
3. В случае отмены чека, касса должна сообщать СВ КИЗ, которые не удалось продать/вернуть.
4. Необходим параметр на уровне магазина регулирующий возможность продажи/возврата товаров с КИЗ при отсутствии связи с СВ.
5. Возвраты

Проверка возможности возврата происходит на сервере СВ. Если КИЗ имеет статус «не продана», то возврат товара с данной КИЗ невозможен.

Приложение 1. Ошибки, фиксируемые в Журнале

Общее описание задачи

<Что просит сделать заказчик>

<Описание бизнес-цели изменений: что станет лучше если сделать изменение>

Необходимо решить несколько проблем:

1. Проверка разрешения продажи АМ на текущий момент проверяется только после добавления всех товаров в чек
   1. приводит к сложностям со сторнированием не прошедших проверку в УТМ товаров
2. Проверка разрешения продажи КМ строится на списке проданных КМ в данном магазине (черный список)
   1. приводит к возможностипродажи КМ не принадлежащих юр. лицу осуществляющему продажу
3. Отсутствует проверка соответствия ШК товара и АМ
   1. приводит к продаже товара ниже минимальной цены
4. Отсутствует возможность добавления товара в чек сканирование только АМ
   1. увеличивает время обслуживания

Как заказчик работает сейчас

<Конфигурация системы заказчика>

1. Какой клиент он использует (ukmclient или lillo)
2. Версия УКМ4
3. Общее количество касс
4. Используется ли внешняя система лояльности, если да, то какая

<Описание как заказчик работает с существующим функционалом>

User Stories

<Описание как будет использоваться измененный функционал заказчиком>

US01: Добавление товара сканированием марки

Для КиЗ уже имеется базовый режим добавления специального маркированного товара в чек
Если требуется  марки перед добавлением специального маркированного товара в чек:

1. Касса проверяет марку в СММ.
   a. Если марка проверена успешно, то товар добавляется в чек
   b. Если марка не проходит проверку, то кассиру показывается окно с сообщением "Марка товара не прошла проверку. Отложите данный товар". Товар не добавляется в чек.
   c. Если отсутствует связь с сервером проверки - переходим к US03.

Для алкогольного товара:

1. Кассир сканирует марку товара (определяется шаблоном ввода). Касса проверяет марку в СММ
   1. Если марка проверена успешно, то товар добавляется в чек
      
      1. Если товар не найден (сервер проверки возвращает пустой список ШК) , то кассиру показывается окно с сообщением "Товар не найден". Товар не добавляется в чек. 
         Для добавления товара можно воспользоваться сценарием US02.
      2. Если сервер проверки вернул список из нескольких штрих кодов товара - кассиру в открывшемся окне предлагается сканировать штрих код товара.
         - Если кассир закрывает окно - выдается сообщение "Товар не может быть добавлен в чек" и сценарий заканчивается. Товар не добавляется в чек. Для добавления товара можно воспользоваться сценарием US02.
         - Если считанный штрих код товара содержится в списке, присланном сервером проверки, товар добавляется в чек по этому штрих коду без повторного сканирования акцизной марки.
         - Если считанный штрих код товара НЕ содержится в списке, присланном сервером проверки - выдается сообщение "Товар не может быть добавлен в чек" сценарий заканчивается.
      3. Если отсутствует связь с сервером проверки, то кассиру показывается окно с сообщением "Сервер проверки марок недоступен. Сначала сканируйте штрих код товара". Товар не добавляется в чек. 
         Для добавления товара можно воспользоваться сценарием US02.
   2. Если марка не проходит проверку, то кассиру показывается окно с сообщением "Марка товара не прошла проверку. Отложите данный товар". Товар не добавляется в чек.

US02: Добавление товара сканирование штрих кода и акцизной марки

1. Кассир сканирует штрих код товара. Кассир сканирует акцизную марку товара. Касса проверяет марку, отправляя также информацию о штрих коде
   1. Если марка проверена успешно, то товар добавляется в чек
   2. Если марка не проходит проверку, то кассиру показывается окно с сообщением "Марка товара не прошла проверку. Отложите данный товар". Товар не добавляется в чек
   3. Если марка не соответсвует штрих коду, то кассиру показывается окно с сообщением "Товар не соответсвует акцизной марке. Отсканируйте повторно". Товар не добавляется в чек

US03: Строгое требование проверки марки (опция)

1. Запрет добавления товара не прошедшего проверку установлен
   1. - Если связь с проверяющим сервером отсутствует,  то кассиру показывается окно с сообщением "Сервер проверки марок недоступен. Отложите данный товар". Товар не добавляется в чек
2. Запрет добавления товара не прошедшего проверку не установлен
   1. - Если связь с проверяющим сервером отсутствует. Товар добавляется в чек

Концептуальное описание решения

Для всех способов добавления товаров в чек добавляется дополнительный шаг с отправкой марки в СММ для проверки

Для акцизной марки товар добавляется на основании информации от сервера проверки. Для контрольной марки товар добавляется на основании информации из самой марки

Техническое описание решения

В раздел "Параметры магазина и настройка операций/Интеграция" добавить новую интеграцию "СуперМагМарко"

Настройки хранить на уровне магазина (аналогично CWV)

Список настроек:

1. Включение/выключение интеграции
2. URL сервера СММ
3. Таймаут ожидания ответа (по умолчанию 2 секунды)
4. Тайм-аут ожидания ответа с изменением статуса марки (по умолчанию 30 секунд)
5. Опция "Тип маркированного товара для проверки" с мультивыбором из типов маркировки. Опция показывает какой тип маркированного товара следует проверять в СММ
   1. На текущий момент это будут:
      • Акцизный маркированный товар
      • Специальный маркированный товар
6. Опция "Запрет добавления товара не прошедшего проверку"

Добавить работу с АМ на уровне ШВ

На кассе в соответствии с настройками добавить асинхронную отправку марки в СММ коммитером.
Особенность:
Проверка алкогольной марки по сценарию US02 и асинхронная отправка марки в СММ не производится если не включена и не настроена интеграция с ЕГАИС.

Компоненты для изменения

<Перечень компонентов, которые будут затронуты изменением>

Версии ОС: Windows и Linux

Версии ПО: Ukmserver, Ukmclient и Lillo 

Функционал: интеграция с новым сервисом

Экранные формы: нет

Настройки: web

Импорт и экспорт: нет

Оборудование (с учетом прошивок): нет

Дополнительное логирование: подробный лог работы с новым сервисом под отдельной меткой

Лицензирование функционала: отдельная новая лицензия

Ограничения предложения

1. Функционал поиска товара по КМ уже реализован в УКМ4, поэтому данный сценарий для СММ не будет реализован
2. На кассе происходит только проверка марок, фиксация марки происходит на сервере магазина после репликации чека
3. Проверка происходит однократно при добавлении нового товара в чек