1Суб’єкт
ФОП або юридична особа з власним фіскальним контуром.
NATIVE ПРРО · РОБОЧИЙ КОНТУР
ПРРО для магазину — Native ПРРО в OutPOSt
Native ПРРО уже реалізовано як окремий робочий фіскальний контур екосистеми OutPOSt. Архітектура підтримує кілька суб’єктів і ПРРО, маршрути товарів, КЕП, контроль документа, зміни та recovery. Зараз тривають фінальні польові перевірки перед об’єднанням із настільною версією OutPOSt.
NATIVE PRRO CONTROLTEST
Суб’єктФОП / юр. особа
ПРРОПрофіль · Ready
КЕПReadiness
МаршрутТовар → ПРРО
Fail‑closed recoveryБез сліпого retry
Вбудований модуль · робочий контур. Native ПРРО реалізовано як окремий робочий контур OutPOSt; зараз тривають фінальні польові перевірки перед об’єднанням із настільною версією. Це не концепт «на майбутнє» і не функція «в розробці».
Поточний статусРобочийфінальні польові перевірки
АрхітектураMulti‑ПРРОкілька профілів і суб’єктів
МаршрутиТовар → категорія → defaultконтрольований вибір профілю
БезпекаFail‑closedневідомий стан не стає “успіхом”
РЕАЛЬНІ ЕКРАНИ OUTPOST
Як виглядає Native ПРРО в програмі
Два справжні Native-екрани показують маршрутизацію ПРРО та перевірку готовності касира перед фіскальною дією.
Маршрут операції
Перед фіскалізацією OutPOSt визначає потрібний контур і не підміняє вибір профілю прихованим автоматичним рішенням.
Перевірка готовності
Перед відповідальною дією окремо перевіряються передумови. Неготовий або невизначений стан має блокувати операцію, а не маскуватися під успіх.
Це реальні екрани інтерфейсу на безпечній демонстраційній базі. Вони показують реалізований UI та логіку контуру, але не є підтвердженням завершеного production-приймання ДПС, КЕП або бойового транспорту.
01 · МОДЕЛЬ
Один магазин може мати кілька фіскальних профілів.
Фіскальний профіль прив’язується до конкретного ФОП або юридичної особи. Спільний каталог магазину не треба дублювати під кожного суб’єкта: товар або категорія отримує правило маршрутизації.
2Профіль ПРРО
Активний ПРРО й параметри роботи.
3Маршрут
Товар → категорія → ПРРО за замовчуванням.
4Чек
Документ іде в обраний фіскальний профіль.
Пріоритет маршрутизації
- Правило конкретного товару.
- Якщо його немає — правило товарної категорії.
- Якщо немає й категорійного правила — ПРРО за замовчуванням.
Такий порядок робить вибір детермінованим і дозволяє одному магазину рознести різні групи товарів між кількома суб’єктами без окремих каталогів.
Що не зберігається в маршруті
Маршрутизація визначає фіскальний профіль, а не банківські секрети. Профілі оплат та еквайрингу керуються окремо й не повинні змішуватися з правилами “який товар → який ПРРО”.
06 · ПРОФІЛІ Й ОПЛАТА
Фіскальний профіль — більше, ніж номер ПРРО.
Для кількох суб’єктів важливо розділяти юридичну ідентичність, фіскальний профіль і спосіб оплати. Це дає змогу змінювати маршрути товарів без копіювання каталогу та без зберігання банківських секретів у правилах маршрутизації.
Суб’єкт
- ФОП або юридична особа.
- Може мати один або декілька фіскальних профілів.
- Профіль можна активувати або вивести з роботи без видалення історії.
ПРРО-профіль
- Окрема фіскальна ідентичність каси.
- Readiness-стан перед операцією.
- Профіль за замовчуванням використовується лише після перевірки більш точних правил.
Профілі оплат
Тип оплати й еквайринг розглядаються окремо від маршруту “товар → ПРРО”. Це не місце для зберігання банківських секретів або реквізитів, які не потрібні маршрутизації.
Історія
Зміна налаштувань не повинна робити старий фіскальний документ “документом нового профілю”. Історія зберігає зв’язок із фактичним контуром, через який операція виконувалась.
02 · ДОКУМЕНТ І КЕП
Перед відправленням — перевірити, що саме буде підписано.
Native-контур будується не як “HTTP-кнопка”. Перед бойовою дією є підготовка даних, readiness-перевірки, XML/XSD-контроль, КЕП та evidence стану, щоб після помилки можна було відновити ланцюг, а не вгадувати.
КЕП
- Окремий readiness-контур ключа.
- Підготовка даних до підпису до мережевої дії.
- Помилка КЕП має блокувати відправлення, а не створювати невизначений документ.
XML / XSD
- Формування фіскального документа у контрольованому форматі.
- Перевірка структури до транспортного виклику.
- Невалідний документ не повинен доходити до мережевого шару як “можливо коректний”.
Readiness
Перед виконанням перевіряється не лише наявність налаштування, а й готовність потрібних частин контуру для конкретної операції.
Evidence
Критичні переходи стану мають залишати достатньо технічного контексту, щоб recovery міг прийняти рішення без повтору “наосліп”.
03 · РОБОЧИЙ ДЕНЬ
Зміна, продаж і повернення — окремі стани.
Фіскальна зміна не повинна “виникати сама” з факту локального продажу. OutPOSt відокремлює стан профілю, робочого дня, документа і транспортного результату.
Відкрити, контролювати, закрити
Профіль має власний стан робочого дня. Перед операцією перевіряється, чи дозволяє поточний стан формувати фіскальний документ.
Продаж
Локальний чек проходить маршрутизацію, підготовку документа, readiness і підпис; після цього фіскальний результат зберігається як окремий стан.
Повернення
Повернення не маскується під “негативний продаж”: це окремий документ і окремий контрольований сценарій.
Різні профілі — спільний магазин
Один касир може працювати зі спільною товарною базою, а фіскальний маршрут обирається правилами товару/категорії/default.
07 · КОНТРОЛЬ ОПЕРАЦІЇ
Кожна відповідальна дія проходить через однакову логіку перевірки.
Щоб multi‑ПРРО не перетворився на набір винятків, продаж, повернення й зміна спираються на спільний принцип: визначити профіль, перевірити readiness, побудувати документ, підписати, виконати транспорт і зафіксувати результат.
1Route
Визначити суб’єкт і ПРРО для конкретного товарного набору.
2Readiness
Перевірити профіль, зміну, КЕП і потрібні налаштування.
3Document
Сформувати й перевірити фіскальний документ до мережевої дії.
4Result
Зберегти підтверджений результат або durable recovery-стан.
04 · DURABLE + RECOVERY
Невизначений стан не можна перетворити на повторну відправку.
Мережевий тайм-аут після передачі документа — небезпечніший за звичайну помилку до відправлення. Якщо невідомо, чи сервер уже прийняв документ, автоматичний повтор може створити дубль. Саме тому Native ПРРО будується fail‑closed.
До відправленняReady / Blockedможна безпечно зупинити
У процесіDurable stateстан не губиться після restart
РезультатConfirmedуспіх лише коли є підтвердження
НевідомоNeeds recoveryне повторюємо наосліп
Що перевіряється після збою
- Чи була мережева дія виконана до обриву.
- Чи є локальний evidence/ідентифікатор для звірки.
- Чи можна підтвердити результат без повторної фіскалізації.
- Якщо ні — стан має залишатися видимим оператору/адміністратору.
Чому fail‑closed важливий
Для фіскального документа “не знаю, що сталося” не дорівнює “нічого не сталося”. Тому невизначений стан не переводиться в автоматичний retry лише для того, щоб інтерфейс швидше став зеленим.
05 · ПОТОЧНИЙ СТАТУС
Інтегровано — не означає “бойовий транспорт уже увімкнений”.
Native ПРРО вже має кодову базу, вікна керування, профілі, маршрути, durable-стани, KEP/XSD/readiness та recovery-контури. Перед production залишаються контрольні перевірки протоколу, КЕП, XML та поведінки в аварійних сценаріях.
| Частина | Стан | Що це означає |
|---|---|---|
| Архітектура multi‑ПРРО | Реалізована | Суб’єкти, профілі та маршрути вже є в продукті. |
| KEP / XSD / readiness / recovery | Інтегровані контури | Мають власні перевірки й стани. |
| Бойове фіскальне надсилання | Не ввімкнено до приймання | Сайт не повинен обіцяти production до завершення тестів. |
АЛЬТЕРНАТИВИ
Native ПРРО — не єдиний шлях.
Магазин може використовувати інший фіскальний контур, якщо він краще відповідає його поточному обладнанню або процесу.
| Варіант | Тип | Коли розглядати |
|---|---|---|
| Native ПРРО | Вбудований ПРРО | Коли потрібні multi‑ПРРО, маршрути товарів і максимальна інтеграція з OutPOSt. |
| CheckBox | Зовнішній ПРРО-сервіс | Коли магазин уже використовує або обирає CheckBox. |
| MINI‑T400ME | Фізичний РРО | Коли потрібен апаратний касовий реєстратор з прямим керуванням через COM. |
Для акцизних товарів окремо доступний еАкциз / XTrace — read-only Sandbox-контур для контрольованих перевірок без production-записів.
08 · ПИТАННЯ ПО СТАТУСУ
Що вже можна вважати фактом, а що ще перевіряється.
Ця частина важлива саме для чесної публічної сторінки: не змішувати завершену архітектуру з тим, що ще очікує production-acceptance.
Native ПРРО вже є в OutPOSt?
Так. Код, керування профілями, маршрути, readiness, КЕП/XSD і recovery-контури вже інтегровані в основну кодову базу.
Який поточний статус Native ПРРО?
Робочий контур інтегровано в основну кодову базу, але production-використання поки не заявляється. Перед роботою з реальними фіскальними даними потрібне завершене польове приймання на цільовій конфігурації.
Чи може один магазин мати більше двох ПРРО?
Архітектура не закладає жорстку межу “один або два”. Профілі й маршрути побудовані для кількості ПРРО, яку реально потребує структура магазину.
Чи потрібно дублювати товари під кожного ФОП?
Ні. Товарна база магазину спільна, а правила визначають, через який фіскальний профіль проходить конкретний товар або категорія.