Навіщо «Яндекс» запустив передачуфіскальних даних як послугу
Леонід Шнир, керівник сервісу Яндекс.ОФД про нові правила роботи з касовою технікою для інтернет-магазинів та ролі «Яндекса»
Поправки до федерального закону № 54 «Про застосування контрольно-касової техніки» принесли ринку багато нових понять , що з процесом передачі фіскальних даних із чеків від продавців у Федеральну податкову службу. Варто сказати, що сама по собі процедура не унікальна, у світі є аналогічні схеми, наприклад, у Кореї, Чехії та низці інших країн.
Серед іншого з'явилося поняття оператор фіскальних даних (ОФД). Загалом на ринку вже працюють 12 ОФД, серед яких тепер і «Яндекс», і понад 20 виробників контрольно-касової техніки, і кількість учасників швидше за все збільшуватиметься.
Чому з'явився протокол обміну фіскальними даними
Якщо раніше фіскальні дані записувалися в касі в «електронній контрольній стрічці захищеної» (ЕКЛЗ) і потім вручну передавалися у ФНП, за новими правилами обмін відбувається автоматично через оператора фіскальних даних, при цьому фіскальні дані, як і раніше, зберігаються і в касі в фіскальному накопичувачі ( ФН). Перш ніж потрапити до ФНП, дані від каси збираються ОФД, і це відбувається за певним протоколом. Його специфікація була запропонована та описана ФНП. Реалізація ж залишалася за учасників ринку. Каса та ОФД спілкуються між собою у бінарному форматі. Завдяки протоколу каса та ОФД розуміють одне одного — він регламентує, де якісь дані записані. Наприклад, спочатку номер фіскального документа, потім дата, назва торгової точки, фіскальна ознака і так далі. Таким чином, можна взяти бінарне повідомлення від каси і перетворити його на фіскальний документ, або навпаки - взяти фіскальний документ і перекластийого в бінарний формат, щоб каса зрозуміла. Використання бінарного формату є найпростішим з технічного погляду рішенням — із цим форматом можуть досить швидко працювати навіть не дуже сучасні та просунуті моделі кас, у тому числі старі моделі після модернізації під вимоги 54ФЗ. Потенційно це здешевлює вартість виробництва відповідного заліза, проте через дефіцит ринку його ціна ще досить висока.
Проблеми реалізації
Як вже згадав , кожен із учасників ринку реалізує цей протокол самостійно і в міру своїх можливостей. «Яндекс» не виняток, ми теж реалізовували цей протокол, щоб запустити передачу фіскальних даних як послугу.
Примітно, що сам процес реалізації зайняв близько місяця, і, можливо, якби в нашому розпорядженні була готова версія протоколу, ми серйозно заощадили б час (як і інші компанії). Крім того, що протокол потрібно було робити з нуля (реалізованих варіантів у відкритому доступі не було), на першому етапі було відразу кілька перешкод - дефіцит обладнання для тестування (тепер воно вже є), відсутність в описі протоколу конкретних алгоритмів (їх доводилося підбирати самостійно і тестувати кожен новий варіант) і, нарешті, дві частини запропонованого протоколу (взаємодія каси та ОФД та взаємодія ОФД та ФНП) були просто не сумісні один з одним (і це теж довелося допрацьовувати досвідченим шляхом). Отже, три тижні пішло на реалізацію взаємодії ОФД з касою (у тому числі доопрацювання самого протоколу) і тиждень на доопрацювання коду.
Наявність на ринку відкритого варіанта протоколу могла б, на наш погляд, сильно полегшити життя і діючим, і майбутнім гравцям. Це підштовхнуло нас до того, щоб відкрити доступ до нашоїверсії протоколу всім охочим. Як показав досвід ClickHouse, ділитися знаннями при створенні технічно складних продуктів може бути дуже привабливим рішенням. Тим більше, що з боку ФНП напевно ще будуть зміни і у форматах обміну, і у форматно-логічному контролі, під які всім теж потрібно буде адаптувати свої продукти. Спільна робота дозволить сконцентруватися на продуктах для користувачів та менше часу витрачати на внесення необхідних змін до технології обміну даними.
Додатково ми виклали JSON схеми фіскальних документів, якими здійснюється форматно-логічний контроль розшифрованих документів від кас. Їх можна використовувати для перевірки того, наскільки сформоване повідомлення від каси відповідає вимогам, які заявлені у протоколі.
Для чого це потрібно і що з цим робити? Очевидно, що це відкрите рішення стосується обмеженого кола осіб - виробників кас, операторів фіскальних даних, експертних організацій. Але ми очікуємо, що воно, з одного боку, полегшить їм життя, а з іншого — допоможе систематизувати нову для українського ринку процедуру. Наприклад, якщо ФНП вносить зміни до специфікації протоколу, то наявність єдиного відкритого для всіх варіанта, який відповідає всім змінам, дозволить швидко протестувати обладнання — чи коректно воно працює.
Як приклад використання ми створили "Емулятор ОФД" - додаток, який отримує повідомлення від каси, розшифровує його і у відповідь надсилає касі підтвердження про прийом документа. Воно цілком може бути використане для тестування нових кас та ОФД. Наша програма вже доступна всім бажаючим. А ми відкриті для обговорень та спільної роботи з цим форматом.