Фіскальний чек із термінала, де немає касира

Чим це відрізняється від звичайної каси

Готові сервіси програмних РРО — Checkbox, Кашалот, рішення банків — зроблені під людину з телефоном або планшетом: касир пробив, чек пішов. Вони добре роблять свою роботу і для магазину чи кавʼярні цього достатньо.

Термінал самообслуговування, вендинговий автомат чи мийний пост відрізняються трьома речами. По-перше, нема кому повторити операцію, якщо щось не спрацювало. По-друге, оплата й надання послуги розділені в часі: гроші прийняті зараз, а мийка триватиме ще шість хвилин. По-третє, пристрій може бути офлайн — і це нормальний, очікуваний стан, а не аварія.

Саме тому фіскалізацію в такій системі не можна «підключити збоку». Вона мусить бути частиною того самого потоку, що й приймання грошей.

Порядок, який не можна міняти місцями

Гроші прийняті й порахувані → чек сформований і відправлений → обладнання запущене. Саме в такому порядку. Спокуса запустити пост одразу, а чек «дослати потім», виглядає розумною: клієнт не чекає зайвих двох секунд. Але щойно дослання ламається, система тихо продає без чеків, і зовні все виглядає справним.

Якщо затримка критична для клієнтського досвіду, правильне рішення не «спершу запустити», а зробити відправку асинхронною з гарантією: транзакція записана локально, черга на відправку існує, і будь-яка відправка, що не вдалась, лишається в черзі, поки не пройде. Різниця в тому, що втрачений чек видно, а не в тому, що він не втрачається.

Що робити, коли пропав звʼязок

Обрив — не виняток, а штатний режим. На мийці це буває щотижня. Тому термінал мусить уміти працювати без мережі: приймати готівку, запускати пости, писати транзакції в локальне сховище.

Питання, на яке треба відповісти ще на етапі проєктування: що саме станеться з цими транзакціями, коли звʼязок повернеться. Вони підуть у податкову з фактичним часом оплати чи з часом відправки? Чи є межа, після якої накопичене вже не можна фіскалізувати заднім числом? Хто побачить, що черга росте?

У робочій системі на це є окремий екран: скільки транзакцій чекає відправки і найстаріша з якого часу. Якщо такого екрана немає, про проблему дізнаються з акту перевірки.

Два журнали замість одного

Найпоширеніша помилка — вести один журнал «оплати» і вважати, що фіскалізація в ньому теж є. Журналів має бути два: що прийнято і що фіскалізовано. Різниця між ними — головне число, на яке дивиться будь-хто, кому доведеться розбиратись.

Поки ця різниця нуль, система здорова. Щойно вона стала ненульовою і не повертається до нуля — щось зламалось, і краще дізнатись про це з власного дашборда, ніж з листа.

Те саме стосується розбивки за каналами. Готівка, монети, картка, QR — кожен рахується окремо. Загальна сума одним числом виглядає охайно рівно доти, доки не треба знайти, де саме розійшлось.

Що питати в постачальника ПРРО

Чи є API, а не лише застосунок для касира. Чи можна відправити чек від імені пристрою, а не людини. Що повертається у відповідь і чи можна за цим ідентифікатором потім знайти конкретний чек. Чи є пісочниця для тестів — фіскалізувати справжні чеки під час налагодження не варіант.

І окремо: які обмеження на відправку заднім числом. Це визначає, скільки годин офлайну система переживе без наслідків, а отже — наскільки надійним має бути звʼязок на точці.

Часті питання