Що таке ПРРО і як зрозуміти, чи він потрібен бізнесу

ПРРО — це програмний реєстратор розрахункових операцій: інструмент, через який бізнес фіксує розрахунок із покупцем і створює фіскальний чек. Це не касова програма, не CRM і не платіжна сторінка. Вони можуть працювати разом, але відповідають за різні частини продажу. Платіжний сервіс приймає оплату. Інтернет-магазин передає дані про замовлення. ПРРО фіксує розрахункову операцію у фіскальному контурі.

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

Цей матеріал не замінює консультацію бухгалтера або податкового консультанта. Він допомагає описати процес продажу так, щоб поставити точні питання й не перетворити інтеграцію на набір ручних дій.

Що таке ПРРО?

Фіскалізація розрахункових операцій

ПРРО — програмний інструмент для фіскалізації розрахункових операцій і формування фіскального чека. Він отримує дані про продаж у момент, визначений для конкретного сценарію, та повертає результат фіскалізації в систему, де ведеться замовлення. Його задача вузька: зафіксувати розрахунок, а не керувати всім продажем.

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

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

CMS керує каталогом, сторінками, кошиком і замовленням. CRM зберігає взаємодію з клієнтом, звернення та роботу менеджера. Якщо потрібно розібрати її роль окремо, дивіться що таке CRM-система простими словами. ПРРО не веде залишки товарів замість CMS і не замінює CRM.

Схема проста: сайт передає склад замовлення, платіжний контур повертає статус оплати, ПРРО отримує дані для фіскалізації, а результат записується до замовлення. Кожна система робить свою частину.

Навіщо існує ПРРО і хто визначає правила

Правила встановлює законодавство

Фіскальний облік потрібен, щоб розрахунок із покупцем був зафіксований у встановленому державою порядку, а покупець отримував фіскальний чек. Чек пов’язує факт продажу, оплату й дані, які мають бути відображені в обліковому процесі.

Вимоги до бізнесу визначають законодавство та уповноважені державні органи. Вони встановлюють, у яких ситуаціях розрахунок підлягає фіскалізації, яка подія є підставою для чека та як обробляти скасування або повернення. Розробник не має вгадувати ці правила за способом оплати чи дизайном кошика.

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

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

Як працює ПРРО під час онлайн-продажу

Оплата і чек — окремі події

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

ПРРО отримує дані, потрібні для створення чека: склад замовлення, суму та інші відомості, погоджені для цього процесу. Після обробки він повертає результат. Сайт записує його біля конкретного замовлення, щоб менеджер і покупець бачили стан операції. Чек надсилається каналом, визначеним у сценарії продажу.

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

• коли покупець оформлює замовлення: зберегти склад замовлення; встановити статус "очікує оплату".
• коли надходить результат оплати: зберегти статус оплати; якщо подія відповідає сценарію фіскалізації:; передати дані замовлення до ПРРО; встановити статус "чек у процесі".
• коли ПРРО повертає результат: якщо чек створено:; зберегти статус "чек створено"; надіслати чек покупцю; інакше:; зберегти статус "чек не створено"; передати випадок відповідальному працівнику.

Такий маршрут потрібен для скасувань і повторних спроб після помилки. Перед повторним надсиланням система має перевірити, чи чек не створили раніше. Інакше один продаж перетвориться на дубль у фіскальному контурі.

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

Що таке фіскальний чек?

Підтвердження конкретного розрахунку

Фіскальний чек — результат фіскалізації розрахункової операції. Він підтверджує, що дані про конкретний розрахунок пройшли через фіскальний контур, а не залишилися лише в кошику, платіжному сервісі чи внутрішній системі замовлень. Для покупця це документ про розрахунок. Для бізнесу — пов’язаний із замовленням запис, потрібний для обліку та обробки повернення.

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

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

Як зрозуміти, чи потрібно перевіряти сценарій продажу для ПРРО

Шлях грошей і даних

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

Для інтернет-магазину опишіть шлях від кошика до отримання товару. З’ясуйте, яким способом платить покупець, у який момент платіж вважається отриманим і яка система зберігає склад замовлення. Якщо дані про товар живуть у каталозі, а статуси — у листуванні, їх потрібно звести в зрозумілий процес.

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

Окремо розберіть оплату за посиланням, оплату при отриманні та повернення коштів. Для кожного випадку зафіксуйте, хто приймає гроші, яка подія запускає наступну дію та де видно її результат. Скасоване замовлення не пояснює, що сталося з оплатою чи чеком.

Якщо продажі ведуть у системі для роботи з клієнтами, визначте її межі заздалегідь: що таке CRM-система простими словами. CRM може зберігати контакт і статус угоди, але не повинна ставати місцем, де губляться дані про оплату, чек і повернення.

Як закласти ПРРО в інтернет-магазин без ручних дублів

Статуси для кожної події

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

У технічному завданні потрібні окремі стани для кожної події: «оплату ініційовано», «оплату підтверджено», «чек створено», «чек не створено», «повернення потребує обробки». Назви можуть відрізнятися, але їхній зміст не повинен змішуватися.

Визначте, яка система є джерелом правди для замовлення. Вона зберігає склад покупки, дані покупця, спосіб оплати, статус доставки та результат фіскалізації. Платіжний сервіс повідомляє про гроші. ПРРО повертає результат створення чека. Сайт показує покупцеві стан. Це різні ролі.

Опишіть помилковий маршрут. Що відбувається, коли оплату підтверджено, а чек не створився? Хто бачить проблему? Чи можна повторити запит? Як система перевірить, що чек не з’явився під час збою? Без цих правил ручна робота повернеться після першої нестандартної ситуації.

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

Коли ПРРО не варто підключати навмання

Спочатку опишіть платіжний маршрут

ПРРО не варто підключати як кнопку, яку треба додати до сайту. Спочатку опишіть шлях платежу. Інакше з’являється зайва інтеграція, менеджери переносять дані вручну, а чеки перестають збігатися зі станом замовлень.

Зупиніться й розкладіть процес, якщо:

• власник не може чітко сказати, хто приймає оплату в кожному сценарії;
• замовлення живуть у сайті, месенджері та таблиці без спільного джерела правди;
• повернення оформлюють поза системою, через листування або окремий переказ;
• розробник не описав, що відбудеться після помилки фіскалізації.

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

Помилки під час інтеграції ПРРО з сайтом

Ідемпотентність повторних запитів

Найчастіша помилка — вважати оплату, створення чека та завершення замовлення однією подією. Це різні стани, які можуть настати в різний час або не настати через збій.

Створювати чек до підтвердження потрібної події небезпечно: замовлення ще може змінитися, а платіж — не перейти в очікуваний стан. У технічному завданні варто описати подію, після якої система передає дані на фіскалізацію.

Не зберігати ідентифікатор фіскалізації біля замовлення — означає втратити зв’язок між чеком і покупкою. Зберігайте результат операції, її статус і журнал подій. Тоді можна побачити, що було надіслано, який результат повернувся та чи потрібна повторна перевірка.

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

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

Ще одна проблема — ховати помилку фіскалізації в технічному журналі, недоступному для людей, які обробляють замовлення. Менеджер має бачити зрозумілий статус і наступну дію. Логіку ПРРО краще винести в окремий інтеграційний шар, а не прив’язувати до конкретної CMS. Тоді зміна сайту чи каталогу не зламає маршрут оплати й фіскалізації.

Що перевірити перед запуском

Погоджений маршрут продажу

Перед запуском потрібен погоджений маршрут кожного продажу. Він допомагає побачити прогалини до того, як менеджер почне виправляти їх вручну.

• Опишіть усі способи оплати, доступні покупцеві, включно з оплатою за посиланням, при отриманні та поверненням коштів.
• Визначте подію, після якої система передає дані для фіскалізації. Це не має бути припущенням на кшталт «оплата ніби пройшла».
• Погодьте окремі сценарії для скасування замовлення і повернення. Це різні дії.
• Визначте систему, де працівник бачить стан замовлення, платежу та чека.
• Призначте відповідального за помилки: хто перевіряє статус, хто приймає рішення про повторну дію, хто спілкується з покупцем.
• Звірте модель розрахунків із бухгалтером або податковим консультантом.
• Зафіксуйте правила інтеграції в технічному завданні: події, статуси, дані, відповідальних і маршрут помилки.

Якщо продажі ведуться через сайт, ці правила варто закладати разом із інтернет-магазином одягу з каталогом і оформленням замовлень, а не дописувати після запуску.

Порівняння

Ролі систем у продажу

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

ПРРО: відповіді на запитання