...

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

Архитектура

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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. Запрет добавления товара не прошедшего проверку установлен
   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. Проверка происходит однократно при добавлении нового товара
   1. в чек