Авторські блоги та коментарі до них відображають виключно точку зору їхніх авторів. Редакція ЛІГА.net може не поділяти думку авторів блогів.
29.03.2024 15:41

П’ять лопат для поховання програмної фіскалізації. Перелік загроз, яких боїться бізнес

Співзасновник Асоціації провайдерів програмних РРО України, співзасновник та CEO Checkbox

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

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

Ризик 1: Повна заборона офлайну для ПРРО, яка несе ризики для всієї сфери торгівлі та послуг

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

Чому це небезпечно: ключова вимога для сфери торгівлі — забезпечення високої доступної систем автоматизації. Кожна зайва секунда при розрахунку призводять до збільшення черги клієнтів, і в результаті покупець швидше відмовиться від товару, ані ж чекатиме на нього довше, ніж зазвичай. Адже якщо, до прикладу, додати до часу розрахунку лише 30 секунд, то черга з 10 клієнтів обслуговуватиметься вже на 5 хвилин довше.

Тому офлайн-режим важливий не лише через можливість працювати з ПРРО під час перебоїв з електрикою. Фактично офлайн — це механізм, який гарантує високу доступність. Збої в роботі можуть виникати як на рівні серверу, так і на рівні зовнішніх сервісів (наприклад АЦСК), але бізнес може продовжувати обслуговувати клієнтів саме через можливість працювати в офлайні. 

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

Ризик 2: Вирішення “проблеми офлайну” через додавання фізичного модуля в ПРРО

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

Чому це небезпечно: низька вартість, зберігання на хмарному сервері, відсутність прив’язки до “заліза” та швидка реєстрація нових кас — це ключові переваги ПРРО перед РРО. 

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

Ризик 3: Введення обов’язкової сертифікації для ПРРО, як інструмент для впливу на окремих операторів

Як відомо, в Україні ПРРО реєструється за лічені хвилини, тоді як класичні РРО потребують сертифікації. Проте сьогодні ми чуємо, що це наче “проблема”, яку треба “вирішувати”, тобто, ввести обов’язкову сертифікацію для ПРРО. 

Звичайно, за своїм принципом сертифікація програми є абсурдом, проте таку пропозицію дійсно обговорюють як один зі шляхів “вирішення проблем ПРРО” (Серед інших “ідей” - реєстр розробників ПРРО та реєстр операторів ПРРО). Те, що така новація значно ускладнить процес реєстрації ПРРО — лише частина проблеми. Ключова небезпека у корупційних ризиках. 

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

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

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

Ризик 4: Обмеження сфер застосування ПРРО

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

Можливо саме тому в глобальній повістці про уявну “небезпеку ПРРО” потреба “захистити найдорожче” через обмеження застосування програмних реєстраторів для підакцизних товарів — серйозна стратегічна мета супротивників ПРРО. Неможливість продавати певні категорії товарів, таким чином, має вдарити по продовольчих магазинах, які є активними користувачами ПРРО

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

Тож практика демонструє - обмеження КВЕДів в цьому випадку не змусить підприємця перейти на класичне РРО, проте може спокусити почати продавати товари взагалі без чеків.

Ризик 5: Виключення центральної ланки (серверів ПРРО) з ланцюга фіскалізації

Як розповідають інсайдери, в Міжвідомчій робочій групі “з питань ПРРО” бачать цю проблему настільки серйозною, що вважають, що вона потребує “негайного вирішення”. Суть “проблеми” - інформація про чеки потрапляє з пристрою на сервер ПРРО сервіс-провайдера, а вже з сервера — до ДПС. Мовляв, там, на сервері ПРРО, інформація про придбані кимось огірки буде негайно спотворена, щоб у зміненому вигляді потрапити до ДПС. Тож щоб цього не сталося, пропонується, щоб чек летів до ДПС одразу з пристрою, не зупиняючись на сервері ПРРО. 

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

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

До того ж не одразу зрозуміло, чому саме в Мінфіні взагалі переймаються через це, адже прикладів таких зловживань взагалі надано не було. Як відомо, сервери сервіс-провайдерів ПРРО розміщуються в найнадійніших світових дата-центрах, а деякі сервіс-провайдери мають Комплексну систему захисту інформації (КСЗІ) що є державним стандартом з захисту інформації в Україні (Держоргани не мають права використовувати ІТ системи без КСЗІ і відповідно КСЗІ є тим стандартом що гарантує інформаційний захист в тому числі від зловживань посадових осіб). 

Чи так все погано? 

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

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

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

Відправити:
Якщо Ви помітили орфографічну помилку, виділіть її мишею і натисніть Ctrl+Enter.
Останні записи
Контакти
E-mail: [email protected]