ЩО ТАКЕ ФІСКАЛЬНІ ПРИНЦИПИ ЩОДО РРО

     ЩО ТАКЕ ФІСКАЛЬНІ ПРИНЦИПИ ПО ВІДНОШЕННЮ ДО РРО

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

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

     Нижче наведено ключові фіскальні принципи, які закладені в роботу будь-якого класичного РРО або сучасного ПРРО (програмного РРО):

     1. Принцип фіскалізації (Реєстрація операції)

     Будь-яка розрахункова операція (прийом готівки, платіжних карток, жетонів тощо) має бути зафіксована в момент її проведення.

• · Як це працює: Продавець зобов'язаний видати фіскальный чек установленої форми покупцеві. Це основний принцип контролю виконання фіскальної функції. Дані про продаж миттєво шифруються та готуються до відправки в ДПС. Так працює класичний РРО. На жаль, цю норму прибрали з чинного Закону.

     2. Принцип цілісності та незмінності даних

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

• · У класичних РРО: за це відповідає апаратна фіскальна пам'ять (одноразовий запис) та модуль КСЕФ (контрольна стрічка в електронній формі).
• · У ПРРО: Цілісність забезпечується пакетом даних, який підписується ЕЦП/КЕП (электронним цифровим підписом) касира або підприємства. Будь-яка спроба змінити бодай одну цифру в чеку зруйнує електронний підпис, і система відразу зафіксує втручання.

     3. Принцип унікальної ідентифікації (Фіскальний номер)

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

• · Навіщо це потрібно: Податкова служба може в будь-який момент перевірити справжність чека в реєстрі. Якщо покупець перевіряє чек на сайті податкової, і його там немає — це ознака нефіскального (сірого) чека.

     4. Принцип автономності (Робота в режимі офлайн)

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

• · Реалізація: ПРРО отримує від сервера ДПС (Державної податкової служби) заздалегідь зарезервований діапазон фіскальних номерів. У режимі офлайн ПРРО присвоює чекам ці номери та підписує їх ключем касира. Щощойно зв'язок відновлюється, всі накопичені чеки автоматично «скидаються» на сервер податкової. Даний режим суворо обмежений за часом (наприклад, в Україні — не більше 36 годин поспіль та 168 годин на місяць).

     5. Принцип обов'язальної звітності (Z-звіт)

     Фіскальний день на торговій точці обов'язково має закриватися підбиттям підсумків.

• · Що таке Z-звіт: це підсумковий документ, який обнуляє оперативну пам'ять РРО та заносить загальну суму виручки за зміну в нередаговану фіскальну пам'ять (або відправляє на фіскальний сервер). Без своєчасного закриття зміни блокується подальша реєстрація чеків.

     Суть фіскального режиму: резюме

     Головна відмінність звичайного чекового (товарного) принтера від РРО полягає саме у фіскальному режимі.

     Звичайний принтер просто друкує текст за командою комп'ютера (дані можна стерти з бази облікової програми в будь-який момент). РРО/ПРРО — це юридичний інструмент контролю, який пов'язує підписом касира, часом та незмінним кодом кожну копійку, що пройшла через касу, гарантуючи державі прозорість оподаткування.

     Чи можна вважати фіскальний сервер ДПС фіскальним пристроєм? Справа в тому, що фіскальный сервер — це все ж таки сервер, створений на звичайному комп'ютері. Доступ до даних на ньому має той, хто обслуговує цей комп'ютер. Там немає «залізної» фіскальної плати, як у класичних касових апаратах.

     Проте, з точки зору закону та архітектури безпеки, фіскальний сервер ДПС офіційно виконує роль фіскального пристрою (а точніше, центрального фіскального органу).

     Давайте розберемо, чому «звичайний комп'ютер» податкової має право так називатися, і як вирішується проблема доступу адміністраторів до даних.

     1. Юридичне визначення

     В українському законодавстві поняття фіскального режиму було переосмислено з появою ПРРО.

• · Раніше: фіскальний пристрій — це була коробочка з опломбованою мікросхемою пам'яті на території магазину.
• · Сьогодні: фіскальним пристроєм (носієм фіскальних функцій) визнається сам фіскальний сервер ДПС. Закон наділяє його статусом «контролюючого програмно-техничного комплексу». Тобто фіскальним його робить не унікальна мікросхема, а юридичний статус і функції, які він виконує.

     2. Як захищаються дані від адмінів та зміни?

     Щоб не було фальсифікації даних фіскальний сервер захищений технологіями, які перетворюють його з «просто комп'ютера» на захищене сховище:

• · КЕП (Кваліфікований електронний підпис) як замок: Кожен чек, що надходить від ПРРО, підписується електронним підписом (КЕП) касира. Коли сервер приймає чек, він миттєво підписує його своїм технологічним підписом фіскального сервера.
• · Принцип хешування (ланцюжки даних): Чек не можна просто так змінити в базі даних. Якщо адмін вирішить змінити суму в чеку за минулий місяць, цифровий підпис цього чека «зруйнується» (стане невалідним). Система відразу б'є на сполох, так як порушено цілісність даних.
• · Логування та аудит: Дії самих адміністраторів сервера жорстко протоколюються незалежними системами аудита. Напряму залезти в базу SQL і поміняти цифру без слідів у системі такого рівня практично неможливо.

     3. Порівняння: Класичний РРО та Фіскальний сервер ДПС

     Щоб остаточно розставити точки над «i», подивіться, як трансформувалися фіскальні принципи:

     Підсумок

     Вопрос - Ответ.

     Вопрос. Чи можна фіскальний сервер вважати фіскальним пристроєм?

     Ответ. Так, можна. Але якщо класичний РРО був «фіскальним пристроєм» за рахунок заліза та пломби, то сервер ДПС є «фіскальним пристроєм» за рахунок математичної криптографії (КЕП) та жорстких регламентів безпеки.

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

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

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

     Як технічно можлива схема, про яку йдеться?

     Щоб реалізувати описаний вище сценарій (когда чек б'ється, QR-код валідний, но в підсумкову податкову базу дані не йдуть або йдуть вибірково), алгоритм фіскального сервера має бути розділений на два незалежні контури:

1. 1. Контур валідації (веб-інтерфейс перевірки чеків): Коли покупець сканує QR-код, його телефон відправляє запит на сервер. Сервер дивиться на хеш-функцію, звіряє контрольну суму і каже: «Так, цей чек був згенерований правильним ПРРО з правильним ключем касира. Він справжній». Тобто для зовнішнього світу все виглядає ідеально.
2. 2. Контур фіскального обліку (база даних для розрахунку податків): А ось тут на етапі запису даних (інсерту в БД) вмикається «нужний алгоритм». Програма може відсіювати певні транзакції (наприклад, за обсягом, за конкретними ФОП-ами чи за часом) і перенаправляти їх у прихований масив або просто стирать після валідації.

     Чому це простіше зробити віддалено, ніж на «залізному» РРО?

     У класичному апаратному РРО код «зашитий» у ПЗУ (одноразово програмовану пам'ять) на заводі та опломбований. Щоб змінити алгоритм, потрібно фізично приїхати, розкрити апарат і перепаяти чип.

     У випадку з фіскальним сервером:

• · Зміни вносяться віддалено через оновлення ПЗ (у вигляді нового релізу).
• · Скрипт-модифікатор може працювати прямо в оперативній пам'яті та не залишати явних слідів у логах самої бази даних.
• · Контролювати процес (вмикати/вимикати фільтрацію даних) можна непомітно в режимі реального часу.

     Де «слабке місце» в захисті державного сервера?

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

     1. Людський фактор (Доступ розробників)

     Будь-яку програму пишуть люди. Якщо умовний «головний архітектор» системи за вказівкою зверху або за винагороду впровадить у код сервера прихований фільтр (своєрідний фіскальний троян), то система працюватиме саме так, як було описано. Жодна зовнішня перевірка (КСЗІ, аудит) цього не помітить, якщо фільтр актується за секретним тригером.

     2. Уразливість офлайн-режиму

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

     Висновок

     Недовіра до ПРРО абсолютно виправдана. Класичний фіскальний пристрій захищає дані фізично та децентралізовано (мільйони апаратів по всій країні не можна зламати одночасно).

     Фискальний сервер переніс увесь захист у цифру та централізував її. А централізація завжди означає, що у того, хто контролює «рубильник» і код цього сервера, з'являється абсолютна влада над всіма даними. І якщо алгоритми будуть написані з умислом сокриття, то зовні система здаватиметься чесною, а всередині — працюватиме як кастомний фільтр.

     Це питання не технологій, а довіри до тих, хто цей сервер обслуговує.