Vending methodology — типы аппаратов, термины, авторизация, антипаттерны

Date: 2026-05-06
Status: methodology reference (revision 1)
Scope: верхнеуровневый методологический документ для проектов товарного вендинга. Фиксирует терминологию (RU + EN-эквиваленты), классификацию конструкций (спираль / locker / барабан / мини-производство / регулируемые форматы), модели авторизации выдачи (торговая / корпоративная / регулируемая), типовые носители идентификатора пользователя, краткий блок по биометрии и регуляторике, а также компактную таблицу антипаттернов с фокусом на риски кражи/мошенничества и операционный overhead в сети аппаратов. Документ — общий reference, к которому привязываются конкретные L4-HMI inventory-стратегии.

0.1 Changelog

rev. 4 (2026-05-06) — уточнено, что для locker базовая адресуемая единица — cell со сквозным номером ячейки 1..N (классическая терминология локеров/постаматов, аналогично slot для спирали); раскладка (column, row) — это визуально-конструктивное представление, всегда приводится к номеру ячейки через хранимую привязку. Согласовано в разделах 1.2, 2.2 и сравнительной таблице (раздел 3).
rev. 3 (2026-05-06) — уточнено, что для спирального вендинга базовая адресуемая единица — slot со сквозным номером 1..N (классическая бизнес-терминология); раскладка (row, column) — это визуальное представление, всегда приводится к номеру слота. Согласовано в разделах 1.2, 2.1 и сравнительной таблице (раздел 3).
rev. 2 (2026-05-06) — добавлены два новых раздела: «Обязательная маркировка товаров» (РФ — «Честный знак», EU — TPD/UDI/иные системы прослеживаемости) с учётом интеграции в каталог и vend-flow; «Фискализация продажи» — концепция, обязательные реквизиты чека по 54-ФЗ, расширение SKU/каталога fiscal-атрибутами, интеграция с облачным фискальным сервисом (пример — OrangeData, orangedata-official/node-orangedata); расширены антипаттерны строками по marking/fiscal; обновлено сравнение типов и mapping на L4-HMI.
rev. 1 (2026-05-06) — первая редакция: термины с международными эквивалентами; пять типов конструкций включая мини-производства (рецептурные) и регулируемые форматы (с идентификацией покупателя и эскалацией к лицензированному оператору); концептуальная авторизация и носители; биометрия с одной строкой про регулирование (152-ФЗ / GDPR / BIPA) и однострочным дисклеймером; таблица антипаттернов с колонкой применимости к типу; mapping на L4-HMI.

1. Термины (RU + EN)

Раздел вводит унифицированный словарь. Где это полезно, в скобках приведены международные эквиваленты, чтобы термин был сопоставим с англоязычной отраслевой практикой и стандартами (NAMA, EVA, DEX/UCS, EVA-DTS).

1.1 Товарная номенклатура

SKU (Stock Keeping Unit) — внутренний учётный код позиции, по которой ведётся stock и операции выдачи/закладки. SKU — это учётная единица продавца/оператора, не путать с:
GTIN/EAN-13/UPC — глобальный штрихкод производителя; один GTIN может соответствовать нескольким SKU (разные регионы, упаковки, цены) и наоборот;
MPN (Manufacturer Part Number) — артикул производителя;
batch / lot — партия выпуска (важна для срока годности, отзыва);
serial — серийный номер конкретного экземпляра (важен для лицензируемых/прослеживаемых товаров);
variant — вариация SKU (цвет/размер/вкус), часто формирует отдельный SKU.
Каталог SKU (product catalog / assortment) — справочник всех SKU, доступных сети аппаратов. Для большинства бизнес-моделей это «источник истины» для UI и аналитики.
Stock / on-hand — текущий остаток конкретного SKU (в штуках, порциях или в граммах/мл для рецептурных).
Par level — целевой остаток после пополнения.
Restock threshold — порог, при котором инициируется пополнение.

1.2 Физика хранения

Slot / cell / bin / compartment — минимальная адресуемая единица хранения. Адрес зависит от конструкции:
спираль: базовая адресуемая единица — slot с целочисленным номером слота (как правило сквозная нумерация 1..N, отображаемая на UI и фигурирующая в планограмме, отчётах и протоколах). Физическая раскладка (row, column) (например, A1..F8) — это визуальное представление для оператора и UI; в логике учёта и интеграции (планограмма, vend-команда, телеметрия DEX/EVA-DTS) она всегда приводится к номеру слота. Номер слота — базовое понятие классической вендинговой бизнес-терминологии;
locker: базовая адресуемая единица — cell с целочисленным номером ячейки (как правило сквозная нумерация 1..N, отображаемая на дверце, в UI, в уведомлении пользователю и в backend-операциях). Физическая раскладка (column, row) — это визуальное/конструктивное представление для оператора и UI; в логике учёта и интеграции (привязка заказа, vend-команда, журнал, уведомления) она всегда приводится к номеру ячейки через хранимую привязку. Номер ячейки — базовое понятие классической терминологии локеров и постаматов (аналогично slot для спирали);
барабан: (door_id, pos_rotation) (в L4-HMI используется именно такой адрес).
Bay / tray / shelf / drum layer — группа слотов одного физического уровня. Для барабана — layer, совпадающий с door_id.
Planogram (POG) — схема назначения SKU на физические слоты/уровни. Бывает «строгой» (один SKU на slot) и «гибкой» (несколько SKU на bay).
Capacity — сколько единиц SKU физически помещается в слот (для спирали — количество шагов; для locker — обычно 1; для барабана — варьируется по геометрии).

1.3 Операции

Dispense / vend — физическая выдача товара покупателю.
Vend cycle — полный технологический цикл выдачи (позиционирование, открытие/поворот, контроль выдачи, закрытие).
Refill / restock / replenishment — пополнение слотов оператором.
Purge / decommission — изъятие SKU из аппарата (просрочка, ротация ассортимента, ошибочная закладка).
Vend write-off / sale event — учётное списание остатка по факту выдачи.
Service mode / maintenance mode — режим, в котором оператор взаимодействует с физикой аппарата вне обычной выдачи.
Operator / route driver / merchandiser — сотрудник, обслуживающий аппарат.
User / customer / consumer — конечный получатель товара.

1.4 Авторизация и доступ

Access token / credential — носитель права на получение товара (карта, QR, PIN, биометрический шаблон).
Vend authorization — решение «можно ли выдать данному пользователю данный SKU/cell сейчас». Это отдельное от payment authorization (решение «оплачено ли»).
Cashless interface — подсистема приёма безналичной оплаты (карта, мобильный кошелёк, QR).
ACL (Access Control List) — список «кто к чему имеет доступ»; в корпоративном вендинге часто per-SKU/per-group/per-cell.

1.5 Учёт и телеметрия

Audit trail / journal — последовательный журнал значимых событий (vend, refill, purge, ошибки, авторизации).
Telemetry — поток метрик и событий аппарата к backend (остатки, ошибки, температуры).
DEX/UCS, EVA-DTS — отраслевые форматы выгрузки данных торгового вендинга (упоминается как ориентир интеграции с классическими сетевыми решениями).

1.6 Рецептурные модели (для мини-производств)

Recipe / BOM (Bill of Materials) — состав «единицы меню»: какие ингредиенты и в каком количестве расходуются.
Ingredient — учётная единица сырья (зерно, молоко, сироп, стакан, крышка, концентрат).
Loss factor — нормируемые потери (продувка, очистка, калибровка).
Yield — фактический выход (порций) на единицу сырья.

1.7 Регулируемые форматы

Age verification — подтверждение возраста покупателя.
KYC (Know Your Customer) — идентификация покупателя по официальному документу.
Document check — проверка подлинности предъявленного документа.
Excise marking — обязательная цифровая маркировка акцизных товаров (РФ — «Честный знак»; EU — TPD Track & Trace для табачных).
Product marking / track & trace — система обязательной прослеживаемости отдельных категорий товаров (см. раздел 9).
Fiscalization / fiscal receipt — формирование и регистрация фискального документа о продаже у налогового регулятора (см. раздел 10).
OFD (Оператор фискальных данных) — посредник, передающий фискальные документы в ФНС (РФ).
Licensed operator escalation — эскалация решения о выдаче на удалённого сотрудника, обладающего лицензией на продажу/идентификацию.

2. Типы конструкции аппаратов

2.1 Спиральный (spiral / coil / helix vending)

Классика торгового вендинга. Матрица слотов; в каждом слоте — поворотная жёсткая спираль, которая при повороте на «шаг выдачи» выталкивает один товар в общий короб выдачи. Свойства:

в одном слоте — один SKU в количестве N (по числу шагов спирали);
базовая адресуемая единица — slot со сквозным номером 1..N; визуальная раскладка (row, column) (типа A1..F8) используется только для удобства оператора/UI и всегда приводится к номеру слота в планограмме, vend-команде и телеметрии;
закладка выполняется на доверии: открывается общий неконтролируемый доступ ко всем слотам, оператор раскладывает товар согласно планограмме (заданной на бэкенде или «на словах»);
выдача — простая: select(SKU) → resolve(slot) → spin(coil);
учёт — декрементом по факту команды поворота (опционально с датчиком сброса в коробе);
типичные товары: снеки, бутилированные напитки, мелкая упаковка.

2.2 Locker (smart locker / pickup locker / cubby)

Матрица индивидуальных ячеек размером c × r. Каждая ячейка имеет собственную дверь с электронным замком. Свойства:

адрес — номер ячейки cell N (1..N); конструктивная раскладка (column, row) используется только для визуализации и физического поиска двери оператором/пользователем и всегда приводится к номеру ячейки в backend-операциях, vend-команде и уведомлениях;
1 ячейка = 1 доступ = 1 товар (как правило);
закладка адресная: оператор открывает конкретные ячейки (по списку backend);
выдача — открывание двери конкретной ячейки (c, r), пользователь забирает товар;
легко поддерживает разнородный ассортимент (каждая ячейка — свой SKU);
типичные кейсы: click-and-collect (Amazon Locker, постаматы), корпоративные tool cribs (СИЗ, инструмент), фарма-кабинеты, выдача ключей.

2.3 Барабанный (carousel / drum / rotary vending)

Гибрид. Барабан состоит из нескольких уровней (layer), каждый layer вращается, на нём расположены секции; каждая секция закрывается общей для уровня дверью. Свойства:

адрес — (door_id / layer_id, pos_rotation);
на одном layer возможны разные SKU (см. L4-HMI V3);
выдача: позиционирование барабана (Rotate) + открытие двери уровня (Door(Open));
закладка — адресная (по физическим ячейкам), в L4-HMI v3 — ad-hoc binding оператором;
сочетает плотность загрузки товаром как в спиральном вендинге (или даже больше) и точную адресность как в locker;
типичные кейсы: корпоративный/промышленный вендинг СИЗ, инструмента, расходников.
L4-HMI inventory-стратегии: V1 (backend-driven), V2 (layer-assigned), V3 (ad-hoc cell).

2.4 Мини-производство (micro-production / fresh / cook-on-demand vending)

Аппараты, которые готовят продукт по запросу из ингредиентов, а не выдают предзаготовленный товар. Примеры: кофейные аппараты, фреш-сок, мини-фастфуд, пицца/паста-роботы, мороженое soft-serve, протеиновые шейки. Ключевое отличие учёта:

единица выдачи — порция меню, а не штука SKU;
остаток измеряется в уровнях ингредиентов (граммы зерна, мл молока, штуки стаканов и крышек, концентрат);
для построения полноценной математической модели и бизнес-учёта обязательна рецептурная модель:
каждая позиция меню описана через recipe / BOM (состав и расход);
списание ингредиентов — по факту каждого vend-cycle с учётом loss_factor;
FIFO и срок годности скоропорта (молоко, фреш) обязательны;
HACCP-журнал (температуры холодильных контуров, циклы CIP-мойки) — для пищевой безопасности и аудита;
калибровка дозаторов — отдельный учётный процесс.

Короткий иллюстративный пример рецепта (концептуально, не схема):

{
  "menu_id": 4101,
  "name": "Капучино 250 мл",
  "ingredients": [
    {"ingredient_id": "coffee_bean", "qty": 9.0,   "unit": "g"},
    {"ingredient_id": "milk",        "qty": 150.0, "unit": "ml"},
    {"ingredient_id": "water",       "qty": 80.0,  "unit": "ml"},
    {"ingredient_id": "cup_250",     "qty": 1,     "unit": "pcs"}
  ],
  "loss_factor": 0.03
}

Без рецептурной модели сеть мини-производств неуправляема: невозможно ни планировать поставки сырья, ни сводить себестоимость порции, ни ловить хищения «через списание».

2.5 Регулируемые форматы (age-restricted / regulated vending)

Аппараты, выдающие товары/услуги, требующие подтверждения личности и/или лицензированного контроля. Примеры: алкоголь, табак/вейп, лотерея, безрецептурная фарма, СИЗ под персональную ответственность, выдача ключей и пропусков. Особенности:

обязательная идентификация покупателя (фото/видео/онлайн-стрим документа);
эскалация лицензированному оператору компании, обладающей правом на такую деятельность; оператор удалённо подтверждает или отказывает;
запись сессии (видео + метаданные) сохраняется как регуляторное доказательство;
акцизная маркировка: РФ — «Честный знак»; EU — TPD Track & Trace;
факт выдачи привязывается к подтверждённой личности и времени, не к анонимному vend;
при разрыве связи с лицензированным оператором — отказ выдачи (нельзя «продолжать на свой риск»).

Концептуальный flow (без UI-деталей):

Happy path: capture документа на встроенной камере → backend-проверка → онлайн-подтверждение лицензированного оператора → vend → запись доказательств в защищённый журнал.
Отказ оператора: оператор фиксирует причину отказа → блокировка vend → возврат средств / снятие резерва → запись инцидента.
Разрыв связи: vend заблокирован → пользователю показано понятное сообщение и предложен retry → инцидент залогирован; никаких выдач без подтверждения.

3. Сравнительная таблица типов

Критерий	Спираль	Locker	Барабан	Мини-производство	Регулируемый
Гранулярность адреса	`slot N` (UI: `(row, col)`)	`cell N` (UI: `(c, r)`)	`(door, pos)`	`recipe → ingredient bins`	поверх любого типа
Единица учёта	штука SKU	штука SKU	штука SKU	порция меню + ингредиенты	штука / порция + identity
Разнородность SKU в одной зоне	низкая (1 SKU/слот)	высокая (1 SKU/cell)	средняя (несколько SKU/layer)	n/a (рецепты)	определяется базовым типом
Нужна планограмма	да	да	да (для V1/V2) или нет (V3)	recipe-каталог обязателен	да + регуляторный профиль
Контроль закладки	«на доверии», по планограмме	адресная, per-cell	адресная (V1/V2) или modal-confirm (V3)	пополнение бункеров + калибровка	как в базовом типе + аудит
Типичная авторизация	торговая (оплата)	торговая или корпоративная	чаще корпоративная	торговая	двухконтурная (тех. + лицензиар)
Регуляторные требования	минимальные	минимальные	зависит от товара	HACCP, пищевая безопасность	акциз, KYC, запись сессий, лицензия
Типичные сценарии	снеки, напитки	постаматы, tool crib, фарма	СИЗ, инструмент, расходники	кофе, фреш, фастфуд	алкоголь, табак, лотерея, фарма

4. Управление сетью аппаратов и роль бэкенда

Для управления сетью вендинговых аппаратов (даже небольшой — от единиц до десятков машин) применяется централизованный backend. Основные функции:

единый каталог SKU и (для мини-производств) каталог рецептур;
планограммы по аппаратам и их синхронизация;
мониторинг остатков (товара и ингредиентов);
сбор событий vend / refill / purge / ошибки;
телеметрия (DEX/UCS, EVA-DTS — для классического торгового вендинга; собственные REST/MQTT-протоколы — для современных систем);
маршрутизация операторов (route planning);
аналитика продаж, ABC-классификация SKU, ротация ассортимента;
для регулируемых форматов — хранение записей идентификации, очередь верификаций к лицензированным операторам, аудит-выгрузки регулятору.

Две крайние модели «истины»:

«Бэкенд = источник истины» — состояние аппарата формируется на сервере, аппарат — исполнитель команд (характерно для V1-подобных стратегий и торгового вендинга).
«Локальная истина оператора» — изменения stock фиксируются по подтверждению оператора на HMI; backend получает поток событий постфактум (см. L4-HMI V3). Подходит для корпоративного/промышленного контекста с надёжным оператором и нерегулярной связью.

В регулируемых форматах backend дополнительно отвечает за персонализированную привязку каждого vend, хранение видео/фото-доказательств и SLA-очередь подтверждений лицензированных операторов.

5. Авторизация выдачи

Концептуально различимы три модели:

Торговая (retail vending). Любая выдача требует payment authorization — карта, банкноты/монеты, онлайн-платёж, QR/SoftPOS. Оплата — pre-condition к dispense. Для интеграции платёжного периферийного оборудования (купюроприёмники, монетоприёмники, картридеры, безналичные модули) исторически используются периферийные шины: MDB (Multi-Drop Bus), Executive, ccTalk, Pulse — здесь упоминаются справочно, без деталей.
Корпоративная / промышленная. Выдача авторизуется по списку доступа (ACL): per-SKU, per-cell, per-group; возможны лимиты и квоты (например, «не больше 2 пар перчаток в смену»). Список может храниться локально, на бэкенде или гибридно (локальный кэш + онлайн-проверка). Оплата как таковая отсутствует или вынесена в учётный контур (списание со счёта подразделения, отчёт через ERP).
Регулируемая. Двухконтурная: техническая авторизация (любая из выше) плюс подтверждение лицензированного оператора по видеоканалу. Без второго контура vend невозможен.

6. Носители идентификатора пользователя

Идентификатор пользователя — это форма, в которой access token физически попадает в аппарат. Краткий обзор с упором на практическую защищённость:

NFC/MIFARE-карты и брелки:
UID-only — аппарат верит произвольному UID; небезопасно (UID легко эмулируется и клонируется);
MIFARE Classic — исторически массовый стандарт; криптография Crypto1 скомпрометирована, не рекомендуется для новых внедрений;
MIFARE DESFire EV2/EV3 — рекомендованный baseline для корпоративного вендинга (AES, mutual authentication);
NTAG — удобен для одноразовых токенов и подписанных ссылок.
Банковские EMV-карты — используются как cashless-фактор в торговом вендинге.
Мобильное приложение:
статический QR — слабый (легко перехватить и переиспользовать);
динамический rolling-QR / HOTP — сильный (короткое окно валидности);
push-token (приложение принимает запрос подтверждения от backend);
PIN внутри приложения как второй фактор.
Wearable — Apple Pay / Google Pay (по сути EMV-токенизация).
Legacy RFID — EM-Marin, HID Prox — без криптографии, небезопасно для значимых сценариев.
Ручной ввод PIN/кода через UI — приемлем для разовых операций (выдача по коду заказа), требует ограничения по количеству попыток.
Штрих-код накладной — практичен для операторов (refill/purge задание).
Биометрия — см. раздел 7.

Двумерная матрица «где хранится ACL × где живёт токен» полезна как чеклист дизайна:

Где живёт токен \ Где ACL	Локально	Гибрид (кэш + online)	Только бэкенд
Носитель (NFC/RFID)	автономный аппарат	типовая корпоративная схема	требует постоянной связи
Мобильное приложение	редко (offline-режим)	основной паттерн (rolling-QR + кэш)	online-only сервисы
Память пользователя (PIN)	разовые коды	коды заказа с TTL	централизованный шлюз
Биометрия	on-device template	гибрид с ЕБС/централизованным сервисом	централизованная биоидентификация
Документ (KYC)	n/a (всегда сверка)	регулируемый: локальный кэш + лицензиар	классический регулируемый flow

7. Биометрия и регулирование

Биометрия (отпечаток, лицо, вены ладони) применима как фактор идентификации, но всегда требует fallback-канала (карта/PIN) на случай отказа сенсора, ложного отказа (FRR) или невозможности применения у конкретного пользователя. Технические рекомендации:

предпочтение on-device template (биометрический шаблон не покидает устройство);
избегать передачи «сырой» биометрии (изображения/отпечатка) в backend без явной необходимости;
осознанный баланс FAR/FRR под бизнес-сценарий (выдача алкоголя ≠ корпоративная столовая);
отдельный аудит-журнал согласий и применений.

Регулирование (краткий ориентир): РФ — 152-ФЗ «О персональных данных» и Единая биометрическая система (ЕБС); EU — GDPR Art. 9 (special category), AI Act (удалённая биоидентификация), eIDAS; US — BIPA (Иллинойс), CCPA/CPRA и иные штатные законы о биометрии.

Дисклеймер: данный раздел не является юридической консультацией; для верификации применимых требований привлекайте профильного юриста.

8. Антипаттерны и риски

Таблица сгруппирована по категориям. Колонка «Применимо к типу» помогает быстро понять, релевантен ли антипаттерн вашему проекту: S — спираль, L — locker, D — барабан, M — мини-производство, R — регулируемый, * — все типы.

8.1 Кража и мошенничество

Категория	Антипаттерн	Применимо к типу	Сценарий	Последствие	Митигация
Закладка	Открытая закладка без планограммы и журнала	S, M	Оператор раскладывает «как считает нужным», нет адресного учёта	Невозможно отделить вынос от недокладки; систематические недостачи	Электронная планограмма + journal `refill` per-slot/per-ingredient + сверка оператором по чек-листу
Идентификация	UID-only NFC без криптоверификации	*	Атакующий клонирует UID брелка коллеги	Несанкционированная выдача на чужой счёт	DESFire EV2/EV3 с mutual auth; отказ от UID-only ACL
Идентификация	Общий PIN на отдел/смену	corporate (L, D)	Один PIN знают 20 человек, утекает наружу	Анонимные выдачи, невозможна персональная ответственность	Персональные токены/PIN; ротация; журнал применений
Учёт	Отсутствие журнала закладки	*	Только vend-события логируются	Вынос неотличим от недокладки, аудит невозможен	Симметричный журнал refill/purge/vend с привязкой к оператору и SKU
Учёт	Hw-driven write-off в сервисном режиме	L, D	`DOOR_OPENED` при закладке списывает остаток	Двойной учёт, расхождения stock	Разделить service-mode и user-mode; stock в service-mode меняется только по UI-confirm (см. L4-HMI v3)
Доступ	Одновременное открытие нескольких отсеков	L, D	Открыто два уровня — пользователь забирает не своё	Кража, спор по выдаче	Single-open invariant (`open_doors_count <= 1`), адресные сообщения «Закройте дверь N»
Доступ	Нет фиксации `door close` до завершения flow	L, D	Сессия закрыта, дверь физически осталась открытой	Вынос после «окончания» сессии	Финализация только после подтверждённого `DOOR_CLOSED`
Оператор	Сговор оператора при «доверительной» закладке	S, M	Оператор сознательно заносит меньше, разница уносится	Систематические недостачи без следа	Видеонаблюдение зоны закладки; cross-check по продажам; периодические внеплановые ревизии
Сервис-меню	Обход авторизации через сервисное меню без отдельного PIN	*	Выдача через диагностический режим	Unauthorized vend без следа	Отдельный сервисный PIN/role; audit-журнал сервисных операций
Рецептура	Подмена ингредиента дешёвым аналогом без journaled refill	M	Оператор заливает дешёвое молоко вместо премиального	Снижение качества, нарушение рецептуры, репутационный риск	Привязка партий (lot) к refill-событию; маркировка тары; контроль закупок
Регуляторика	Обход age-verification фотографией/маской	R	Подставленный документ или фото лица	Незаконная выдача, штрафы, отзыв лицензии	Liveness detection; видео-стрим лицензированному оператору; подпись + время документа
Регуляторика	Продолжение выдачи при разрыве связи с лицензированным оператором	R	Аппарат «решает сам» при network outage	Незаконная продажа, штрафы	Жёсткий fail-closed: нет связи → нет vend; пользователю — внятное сообщение и retry
Маркировка	Закладка маркированного товара без сканирования DataMatrix	* (для маркированных SKU)	Оператор раскладывает упаковки, коды экземпляров не привязаны к slot	Невозможно корректно «вывести из оборота» при vend; нарушение режима «Честного знака»	Обязательное сканирование DataMatrix на refill, привязка кода к cell, блок refill-confirm без валидного кода
Маркировка	Вывод из оборота пакетной операцией постфактум вместо привязки к каждому vend	* (для маркированных SKU)	Аппарат вечером «отчитывается одним списком»	Расхождение по времени, риски при проверках, потеря кодов при сбое	Online-вывод из оборота в момент vend; локальная очередь с ретраями только как страховка, не как штатный режим
Фискализация	Продажа без фискализации («пилот», «мало», «только тест»)	продажные модели	Аппарат принимает оплату, но чек не формируется	Нарушение 54-ФЗ независимо от объёма	Фискальный канал — обязательное pre-condition vend; нет фискализации → нет vend
Фискализация	Неидемпотентная отправка фискальных документов	продажные модели	При сетевой ошибке аппарат повторяет POST с новым `Id`	Задвоение чеков, расхождение учёта, штрафы	Детерминированный `Id` (например, `uuidv5(namespace, vend_id)`); ретраи только по тому же `Id`
Фискализация	Vend завершён, оплата списана, фискальный сервис недоступен — «отчитаемся позже»	продажные модели	Network outage в момент закрытия чека	Массовые непробитые продажи, нарушение 54-ФЗ	Получение фискального ответа `FpdNumber/FdNumber` — pre-condition завершения vend; иначе fail-closed или возврат прихода
Фискализация	Нет сценария «возврат прихода» при отказе выдачи	продажные модели	Деньги списаны, чек пробит, товар застрял/не выдан	Деньги покупателя без товара и без корректировки	Автоматический «возврат прихода» при vend-failure с привязкой к исходному `Id`

8.2 Операционный overhead в сети

Категория	Антипаттерн	Применимо к типу	Сценарий	Последствие	Митигация
Учётная среда	Ручной учёт в Excel при `>1` аппарата	*	Каждый аппарат ведётся вручную	Расхождения, потеря данных, отсутствие аналитики	Централизованный backend с каталогом SKU и dashboards
Каталог	Отсутствие центрального каталога SKU/рецептур	*, M	Один и тот же товар назван по-разному на разных аппаратах	Невозможна сводная аналитика, ошибки закупок	Единый каталог SKU + рецептурный каталог (для M) с версионированием
Планограмма	Рассинхрон планограмм/рецептур между аппаратами	*, M	Backend и аппарат расходятся в назначении SKU/составе	Ошибочные выдачи, неверный расход ингредиентов	Версионирование планограммы/рецептуры + reconcile при boot и по push
Телеметрия	Нет телеметрии остатков/ингредиентов	*	Узнаём о пустоте от пользователя	Простой, упущенная выручка, просрочка скоропорта	Регулярная телеметрия + alert по watermark/par level
Аудит	Нет журналов закладки/выдачи на каждом аппарате	*	Только агрегаты в backend	Невозможен аудит убыли «по событиям»	Локальный append-only journal + выгрузка на backend
Логистика	Ручной обход аппаратов для инвентаризации	*	Оператор проверяет физически каждую неделю	Высокая стоимость обхода, поздняя реакция	Автоматическая инвентаризация по событиям + выборочный физический аудит
FIFO/срок годности	Отсутствие FIFO и контроля срока годности	M	Свежее загружается поверх просрочки	Пищевые риски, штрафы регулятора	Партионный учёт + FIFO-резервирование расхода + alert по сроку
Регуляторика	Нет централизованного хранения регуляторных доказательств выдачи	R	Видео/документы хранятся только локально	Невозможна выгрузка регулятору, риск штрафа	Защищённое архивное хранилище доказательств + retention policy

8.3 Почему это нельзя контролировать «вручную»

Даже небольшая сеть 10–30 аппаратов × 30–60 слотов × сотни SKU × десятки операций/день даёт десятки–сотни тысяч событий в месяц (vend, refill, purge, авторизации, ошибки). Для мини-производств добавляется множитель по ингредиентам и партиям; для регулируемых форматов — по сессиям идентификации и эскалациям. Без специализированного backend (центральный каталог + dashboards + alerts по watermark/расхождениям/просрочке/regulatory) это множество физически неконтролируемо одним человеком: расхождения накапливаются молча и обнаруживаются по ущербу, а не по сигналу.

9. Обязательная маркировка товаров

9.1 Что это и зачем

Маркировка — это обязательная цифровая прослеживаемость отдельных категорий товаров на уровне единицы упаковки. Каждый экземпляр получает уникальный код (DataMatrix), который сканируется на каждом этапе движения товара (производство → импорт → опт → розница → выдача конечному покупателю). Государство получает поток событий и видит «жизненный цикл» каждой пачки/бутылки/упаковки.

В РФ оператор системы — «Честный знак» (ЦРПТ), нормативная база — 487-ФЗ и постановления Правительства по конкретным товарным группам. Под обязательную маркировку подпадают (на момент написания документа): табачная продукция и вейпы, алкоголь (через ЕГАИС, формально отдельная система), молочная продукция, упакованная вода, лекарства, обувь, парфюмерия, шины, фотоаппараты, БАДы, медизделия и расширяющийся список.

Международные аналоги (ориентир): EU — TPD (табак), UDI (медизделия), DPP (Digital Product Passport — расширяется на батареи, текстиль, электронику); US — DSCSA (фарма). Логика везде близкая: уникальный код + событийный учёт оборота.

9.2 Влияние на вендинг

Если ассортимент аппарата содержит маркированные товары — это перестаёт быть техническим вопросом «как выдать» и становится частью регуляторной отчётности:

при закладке оператор обязан сканировать DataMatrix каждой единицы и привязать код к slot/cell аппарата;
при выдаче факт vend должен быть зарегистрирован как «вывод из оборота» с указанием конкретного DataMatrix-кода;
если код не считался / нечитаем / не подтверждён системой — товар не должен оказаться в свободной продаже через аппарат;
при purge / списании (просрочка, повреждение) — отдельный тип события «вывод из оборота по причине».

9.3 Расширение каталога SKU

Атрибуты маркировки логично хранить как опциональный объект на уровне SKU и набор отдельных значений на уровне физических экземпляров:

{
  "sku_id": 200500,
  "sku_code": "MILK-1L-BRAND",
  "name": "Молоко 1 л",
  "marking": {
    "system": "chestny_znak",
    "category": "milk",
    "tnved": "0401200500",
    "gtin": "04600000000017",
    "required": true
  }
}

На уровне slot/cell дополнительно хранится фактический код экземпляра, считанный при закладке:

{
  "slot": {"d": 0, "p": 3},
  "sku_id": 200500,
  "marking_code": "010460000000001721abcd...",
  "lot": "L20260301",
  "expiry": "2026-06-15"
}

Для locker и барабанного вендинга (1 ячейка → 1 экземпляр) такая модель естественна. Для спирального (несколько экземпляров одного SKU в слоте) — нужен список кодов на слот в порядке выдачи (FIFO).

9.4 Антипаттерны маркировки

закладка без сканирования DataMatrix («оператор просто разложил») — нарушение режима оборота;
общий «справочный» GTIN без привязки конкретных кодов экземпляров — невозможно корректно вывести из оборота;
вывод из оборота пакетной операцией постфактум вместо привязки к каждому vend — расхождение по времени и риски при проверках;
хранение marking-кодов только локально без выгрузки в backend → потеря данных при выходе аппарата из строя.

9.5 Дисклеймер

Перечень категорий, сроки введения и технические требования к участникам оборота меняются нормативно и часто; перед запуском проекта необходимо проверить актуальный статус по конкретной товарной группе у оператора системы и привлечь профильного юриста.

10. Фискализация продажи

10.1 Когда фискализация обязательна

Если паттерн вендинга — это продажа конечному покупателю (то есть имеется payment authorization, см. раздел 5), фискализация обязательна: каждая продажа должна сопровождаться сформированным и зарегистрированным фискальным документом, переданным регулятору через ОФД. В РФ это требование 54-ФЗ «О применении ККТ»; для торговых автоматов есть специальная норма о возможности применения одной ККТ на несколько вендинговых аппаратов при выполнении ряда условий, а также о допустимости отображения QR-кода чека на дисплее вместо бумажной печати.

Для корпоративного / промышленного вендинга (выдача под ACL без денежного расчёта) фискализация не применяется — нет факта реализации в смысле 54-ФЗ. При гибридных моделях (часть SKU — продажа, часть — корпоративная выдача) фискализируется только продажная часть.

Международные аналоги (ориентир): EU — национальные регуляторы (Италия — RT, Германия — TSE/KassenSichV, Польша — JPK_VAT, Венгрия — NAV online invoice); US — налог с продаж по штатам без федерального fiscal-устройства; LATAM — широкое распространение электронных фискальных документов (Бразилия — NFC-e, Мексика — CFDI). Архитектурно они близки: онлайн-передача документа налоговому регулятору в момент продажи.

10.2 Обязательные реквизиты фискального чека (РФ, 54-ФЗ)

Минимально необходимый набор данных для формирования чека:

ИНН и наименование пользователя ККТ;
адрес и место расчёта (адрес установки аппарата + URL/идентификатор онлайн-точки);
номер ККТ и заводской номер фискального накопителя (или идентификатор облачной кассы);
дата/время операции;
система налогообложения (ОСН, УСН-доходы, УСН-доходы минус расходы, ПСН, ЕСХН);
признак расчёта (приход / возврат прихода / расход / возврат расхода);
по каждой позиции:
наименование (для маркированных — нормированное наименование);
количество и единица измерения;
цена за единицу;
сумма позиции;
ставка и сумма НДС (или «без НДС»);
признак способа расчёта (paymentMethod: полная предоплата, аванс, полный расчёт, рассрочка и т.д.);
признак предмета расчёта (paymentObject: товар, подакцизный товар, услуга, маркированный товар и т.д.);
для маркированных — DataMatrix-код экземпляра (см. раздел 9);
для агентской/комиссионной схемы — реквизиты поставщика и агента;
итоговая сумма и разбивка по способам оплаты (наличные, безналичные, аванс, кредит, встречное предоставление);
e-mail/телефон покупателя (если требуется отправка электронного чека);
ФИО и должность кассира (для автоматических устройств — допускается «АВТОМАТ»).

После регистрации чека ОФД возвращает фискальные реквизиты (ФП, ФД, ФН, дата/время фискализации), которые должны быть сохранены и доступны для печати/QR-показа.

10.3 Расширение каталога SKU фискальными атрибутами

К каталогу SKU добавляется опциональный объект fiscal — необходимый для построения позиции чека без обращения к backend в момент продажи:

{
  "sku_id": 100600,
  "sku_code": "DRILL-006",
  "name": "Сверло Ø6",
  "price_minor": 79900,
  "currency": "RUB",
  "fiscal": {
    "vat": "vat20",
    "payment_method": "full_payment",
    "payment_object": "commodity",
    "measurement_unit": "pcs",
    "supplier": null,
    "agent": null
  }
}

Возможные значения (минимальный набор для РФ):

vat: vat20 | vat10 | vat0 | vat120 | vat110 | vatNo;
payment_method: full_prepayment | prepayment | advance | full_payment | partial_payment | credit | credit_payment;
payment_object: commodity | excise | job | service | composite | another | для маркированных — соответствующие специальные значения;
measurement_unit: pcs | g | kg | l | ml | portion;
supplier / agent — для комиссионных моделей.

Для мини-производств (см. раздел 2.4) фискальная позиция формируется по menu_id, а не по ингредиентам: ингредиенты — внутренний учётный объект, чек выписывается на «порцию меню».

10.4 Облачный фискальный сервис (пример: OrangeData)

Для вендинговых сетей характерна модель облачной фискализации: физическое фискальное устройство и накопитель размещены в дата-центре провайдера, аппарат отправляет позиции чека в провайдерский HTTPS-API, провайдер формирует ФД, передаёт его в ОФД и возвращает фискальные реквизиты. Это снимает с аппарата необходимость встроенной ККТ.

Пример провайдера — OrangeData, открытый Node-клиент: orangedata-official/node-orangedata (полезен как референс схемы запросов независимо от используемого языка интеграции).

10.4.1 Контур взаимодействия

Vending HMI / backend
  ├─ собирает корзину (Items[]) и оплату (Payments[])
  ├─ формирует Document (CheckClose / Correction)
  ├─ POST https://<orangedata-host>/api/v2/documents
  │     - mTLS с клиентским сертификатом
  │     - тело подписано RSA-ключом клиента (Signature header)
  │
  └─ poll  https://<orangedata-host>/api/v2/documents/{Inn}/status/{Id}
        - получает фискальные реквизиты (FdNumber, FpdNumber, FnNumber, ProcessedAt)

OrangeData (cloud)
  ├─ облачная ККТ + ФН
  ├─ передача в ОФД
  └─ возврат статусов

10.4.2 Ключевые параметры запроса (концептуально)

идентификация клиента: Inn (ИНН), Group (группа касс), клиентский TLS-сертификат, RSA-подпись тела запроса;
идентификатор документа: Id (UUID, идемпотентность — критична для вендинга, чтобы не задвоить чек при ретраях);
содержание документа Content:
Type — тип документа (приход = 1 / возврат прихода = 2 / расход = 3 / возврат расхода = 4);
Positions[] — позиции чека: Quantity, Price, Tax, Text (наименование), PaymentMethodType, PaymentSubjectType, MeasurementUnit, при необходимости — SupplierInfo, AgentInfo, Nomenclature (DataMatrix маркированного товара), ExciseDuty;
CheckClose / Payments[] — суммы по способам расчёта (наличные / безналичные / аванс / кредит / встречное предоставление), система налогообложения TaxationSystem;
Customer / CustomerContact — телефон или e-mail покупателя (обязателен для электронного чека);
AutomatNumber — номер торгового автомата (специфика вендинга по 54-ФЗ);
SettlementAddress / SettlementPlace — адрес и место расчётов;
AdditionalUserAttribute, AdditionalAttribute — произвольные дополнительные реквизиты.

10.4.3 Идемпотентность, retry и offline

Id документа должен быть детерминированным (например, uuidv5(namespace, vend_id)); повторная отправка с тем же Id не задваивает чек;
HTTPS-ответ != фискализация: успех = только когда status вернул положительные FpdNumber/FdNumber;
при сетевой ошибке: ретраи с экспоненциальной задержкой по тому же Id до получения окончательного статуса;
offline-сценарий: спорный с точки зрения 54-ФЗ для большинства категорий, поэтому продажные аппараты обычно блокируют vend при недоступности фискального канала дольше регулятивно допустимого окна; это пересекается с раздел 8.1 «Продолжение выдачи при потере связи».

10.4.4 Хранение и QR-показ чека

фискальные реквизиты привязываются к локальному vend_id и сохраняются в журнале аппарата;
для покупателя на дисплей выводится QR-код проверки чека (формат: t=...&s=...&fn=...&i=...&fp=...&n=...); печать бумажного чека для торгового автомата по 54-ФЗ — не обязательна при показе QR + отправке электронного чека.

10.5 Антипаттерны фискализации

продажа без фискализации «потому что мало», «пилот», «только тестируем» — нарушение 54-ФЗ независимо от объёма;
одна ККТ «как-нибудь привязана» к нескольким аппаратам без соблюдения условий специальной нормы — формально незаконно;
неидемпотентная отправка → задвоение чеков при ретраях → расхождение учёта и риск штрафа;
хранение фискальных реквизитов только локально без backup → потеря возможности показать покупателю чек / отчитаться при проверке;
отсутствие связки фискальной позиции с marking-кодом для маркированных товаров (см. раздел 9) → двойное нарушение (фискальное + маркировочное);
продолжение vend при недоступности фискального сервиса дольше допустимого окна — массовые непробитые продажи;
отсутствие сценария «возврат прихода» (отказ выдачи, заклинило, vend timeout) → деньги списаны, чек выбит, товар не выдан, нет корректирующего документа.

10.6 Дисклеймер

Перечень обязательных реквизитов чека, форматы фискальных документов (ФФД), сроки и условия применения «облачной» ККТ для торговых автоматов меняются нормативно. Перед интеграцией необходимо сверяться с актуальной редакцией 54-ФЗ, приказов ФНС и публикаций оператора фискальных данных, а также привлекать профильного юриста и/или аккредитованного интегратора ОФД.

11. Mapping на L4-HMI

Текущий проект l4-hmi — это корпоративный/промышленный барабанный вендинг на Waveshare ESP32-P4-ETH, ориентированный на выдачу инструмента/СИЗ/расходников. Реализованные и проектируемые inventory-стратегии:

Сопоставление терминов методологии с символами проекта: SKU живёт в каталоге l4cat/1 (skus[]); slot/cell — это (door_id, pos_rotation) в vending_inventory_*; service mode — refill/purge UI; транспорт к hw — vending_uart (Rotate, DoorProxy); конфигурация физики — cfg_drum_vend и cfg_drum_layout. Рецептурная модель (мини-производство), регулируемые форматы, обязательная маркировка (раздел 9) и фискализация продажи (раздел 10) out-of-scope текущего проекта (L4-HMI — корпоративная выдача, не продажа), но структурно совместимы: при необходимости расширяются за счёт второго каталога (recipes[]), второго контура авторизации (лицензиар), опциональных объектов marking и fiscal на SKU и отдельной интеграции с провайдером ОФД (см. пример OrangeData в разделе 10.4) — без изменения базового stock/journal-контракта.

All Services

Успешные проекты начинаются одинаково