Касир має сканувати марку в тому ж workflow, що й товар.
еАкциз для магазину та XTrace
Є необов’язковий read-only Sandbox-модуль еАкциз / XTrace: контрольоване читання ЕО, об’єктів, довідників і одинична перевірка електронної марки. Production-середовище та віддалені записи залишаються заблокованими.
Різні ФОП не повинні автоматично змішуватися через fuzzy-зіставлення.
еАкциз і ПРРО проектуються як один контрольований касовий сценарій.
Одна марка проходить кілька перевірок.
Мета OutPOSt — не змушувати продавця працювати в окремій програмі XTrace. Товар, марка, юридичний суб’єкт і фіскальний чек мають зустрічатися в одному касовому процесі.
OutPOSt визначає товар і фіскальний маршрут.
Зчитується код електронної акцизної марки.
Перевіряється статус марки за офіційним контрактом.
Марка пов’язується з правильним суб’єктом і об’єктом.
Касова операція завершується узгодженим фіскальним документом.
Не лише сканування марки.
Повноцінний еАкциз-контур потребує довідників, зовнішніх ідентифікаторів, документів, підпису, статусів і безпечної поведінки при невизначеному результаті.
Електронні марки
- Пошук і перевірка за кодом марки.
- Зв’язок із товаром і штрихкодом.
- Зберігання необхідного статусу без підміни невідомого результату.
EO та об’єкти
- Явне зіставлення ФОП/юрособи з Economic Operator.
- Явна прив’язка магазину або складу до Object.
- Заборона автоматичного змішування різних суб’єктів.
АЕД
- Акцизні електронні документи.
- XML та структурна валідація.
- КЕП і контроль відповідального підпису.
- Стан надсилання та отримання.
Recovery
- Durable-стан зовнішньої операції.
- Відсутність сліпого retry після timeout.
- Перевірка фактичного стану перед повтором write-команди.
Що працює зараз, а що навмисно вимкнено.
Інтеграція працює консервативно: читання в Sandbox дозволене, а ризикові віддалені записи й production-доступ не вмикаються без окремого перевіреного приймання.
Доступні EO/Object, довідники, GET-маршрути й інформаційна перевірка електронної марки.
АЕД, XML, КЕП-підпис і зміни віддаленого стану не виконуються в робочому режимі.
Робота з реальними production-даними не заявляється до окремого польового приймання.
Менше нових кнопок — більше автоматичної перевірки.
Касовий UX має лишатися знайомим. Складність зовнішнього API, КЕП, EO/Object та службових ідентифікаторів не повинна перекладатися на продавця.
Товар + марка
Звичайне машинне зчитування замість ручного переписування довгих кодів.
Статус до критичної дії
Якщо статус марки або маршруту невідомий — система не повинна домислювати його як правильний.
Єдиний касовий workflow
Дані марки мають бути узгоджені з фіскальним документом, а не існувати як окремий журнал.
Що можна сказати вже зараз.
OutPOSt містить read-only Sandbox-контур еАкциз / XTrace, але це не production-модуль і не контур віддалених записів.
Чи вже можна підключити еАкциз у магазині?
Не як production-сценарій. Можна ввімкнути локальний read-only Sandbox-модуль, вручну ввести свіжий токен і виконати контрольоване читання та перевірку. Production і write-операції заблоковані.
Чи підтримуватиметься Data Matrix?
Одинична перевірка електронної марки інтегрована у вікно марок. Результат інформаційний і не виконує активацію, погашення або віддалений запис.
Чи буде зв’язок із ПРРО?
Перевірка марки вже вбудована у чинне вікно ПРРО-марок, але в read-only Sandbox-режимі вона не надсилає АЕД і не змінює фіскальну операцію.
Чи бачитиме продавець токени й технічні ID?
Sandbox-токен вводиться вручну й зберігається поза SQLite через Windows DPAPI CurrentUser. У діагностиці показується лише 12-символьний SHA-256-відбиток токена.

