ПРРО: помилка ZRepAlreadyRegistered — Z-звіт зареєстровано, але зміна не закрилася

Як діяти підприємцю коли Z-звіт зареєстровано, але зміна не закрилася

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

Проте під час цієї процедури користувачі іноді опиняються у ситуації, коли звітність начебто надіслана, але робоче місце залишається заблокованим, і вони ставлять технічній підтримці та відділу продажів такі запитання: «Чому виникає повідомлення від сервера ДПС про вже зареєстрований Z-звіт для поточної зміни?», «Чому зміна вважається відкритою, хоча фактично звіт сформовано?», «Як роздрукувати копію звіту, якщо принтер не спрацював, а повторна спроба блокується?», та «Яким чином закрити зміну вручну без задвоєння даних у податковій?».

Визначення базових понять та актуальний стан питання

Для правильного розуміння проблеми необхідно розрізняти такі ключові поняття:

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

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

• Документ закриття зміни (чек закриття зміни) — службовий електронний документ, який надсилається на сервер ДПС слідом за Z-звітом для офіційного припинення робочої сесії касира на конкретному ПРРО.

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

У сучасних версіях програми Торгсофт розробники суттєво мінімізували ризики виникнення цієї колізії. Раніше, наприклад, якщо під час друку Z-звіту виникала помилка шаблону чи збій принтера (наприклад, файл шаблону .rp53 не знайдено), процес закриття зміни переривався, хоча сам звіт уже зареєструвався на сервері ДПС. Тепер помилки друку або інші виняткові ситуації після успішної фіскалізації звіту не перешкоджають коректному завершенню сесії. Також додано механізми попередження користувачів про не закриті зміни при виході з програми для уникнення порушень тривалості зміни (яка за замовчуванням не повинна перевищувати 23–24 години).

Причини виникнення помилки ZRepAlreadyRegistered

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

Основні технічні чинники, що призводять до помилки:

1. Збої локального обладнання або шаблонів. Якщо у момент формування фіскального звіту програма стикається з критичною помилкою (наприклад, відсутній локальний файл форми звіту або пошкоджено шаблон), процес обробки переривався. Навіть якщо фіскальний сервер ДПС встиг прийняти та зареєструвати Z-звіт, у Торгсофт операція закриття зміни не реєструвалася як завершена. При повторному натисканні кнопки «Надрукувати Z-звіт» сервер повертає відмову з кодом помилки 8 та текстом ZRepAlreadyRegistered.

2. Невідправлений документ закриття зміни. Під час сесії зв’язку Z-звіт реєструється на сервері, але через розрив інтернет-з’єднання чи зависання відповіді серверний документ «Закриття зміни» не створюється або не доходить до Торгсофт. Програма залишає статус зміни як «відкрита», а спроби провести нові продажі блокуються ДПС через наявність зареєстрованого звіту.

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

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

5. Некоректні шаблони звітів та застаріле ПЗ. Користувачі застарілих версій програми частіше стикаються з подібними помилками. Також використання старих версій баз даних (наприклад, MS SQL Server 2005) може викликати внутрішній синтаксичний збій під час запису чи відображення типів оплат у звіті, що теж зупиняє процедуру.

Покроковий алгоритм усунення помилки ZRepAlreadyRegistered

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

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

• Перейдіть у меню Налаштування — Програмний РРО — Аналітика за програмним РРО.

• Перевірте, чи присутній документ Z-звіту у базі та які документи зареєстровані на державному порталі (наприклад, через Електронний кабінет платника податків або за допомогою дії «Підсумковий звіт за період» прямо з програми Торгсофт).

• Якщо звіт дійсно зареєстрований у ДПС, але у Торгсофт зміна вважається відкритою, перейдіть до наступного кроку.

Якщо Z-звіт уже зареєстровано на сервері ДПС, але у Торгсофт зміна залишається відкритою, не потрібно повторно формувати або надсилати Z-звіт. Повторна спроба призведе до помилки ZRepAlreadyRegistered, оскільки сервер ДПС уже має зареєстрований звіт для цієї зміни.

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

Не слід самостійно створювати службові документи закриття зміни або використовувати сторонні чи службові утиліти для зміни стану ПРРО.

Якщо колізія з помилкою ZRepAlreadyRegistered виникла через видалення чека закриття під час роботи офлайн, порядок дій наступний:

• У разі виникнення помилки при спробі виходу в онлайн, не намагайтеся повторно створювати офлайн-чеки.

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

Часті питання підприємців щодо роботи з ПРРО та Z-звітами

? Що робити, якщо Z-звіт у ДПС зареєстровано, але паперовий чек на принтері не надрукувався через відсутність паперу чи збій пристрою?

Це одна з найпоширеніших ситуацій. Якщо фіскальний сервер успішно прийняв документ і надав йому номер, зміну буде закрито на сервері, але на принтері чеків нічого не з'явиться. Не потрібно намагатися заново знімати Z-звіт, це призведе до помилки ZRepAlreadyRegistered. Замість цього перейдіть до розділу «Аналітика за програмним РРО», знайдіть зареєстрований документ та просто скористайтеся функцією друку копії Z-звіту. Також копію можна завантажити безпосередньо з сервера податкової.

? Чому виникає помилка доступу касира при спробі зняти Z-звіт після зміни ФОПа чи касира?

Якщо на торговій точці відбулася зміна суб'єкта господарювання (ФОПа) або касира, але у картці співробітника в Торгсофт залишився обраним цифровий підпис (КЕП) попереднього користувача, система спробує підписати звіт невідповідним ключем. У такому разі сервер поверне помилку на кшталт OperatorAccessToTransactionsRegistrarNotGranted (відсутній доступ до ПРРО). Для усунення проблеми необхідно перевірити налаштування у картці працівника та переконатися, що для підписання документів використовується КЕП діючого касира, зареєстрованого для цього конкретного ПРРО.

? Як запобігти механічним помилкам касира, коли замість X-звіту випадково натискають Z-звіт на початку дня?

Для цього розробники Торгсофт передбачили декілька інструментів захисту:

• У програмі реалізовано додаткові підтвердження під час спроби виконати дію «Надрукувати Z-звіт» безпосередньо з робочого вікна реалізації.

• Також користувачі зверталися з побажаннями розділити кнопки меню візуально. Відповідно до цього, кнопки Х-звіту та Z-звіту розташовані на відстані одна від одної (Х-звіт вгорі, а Z-звіт у самому низу списку дій), щоб унеможливити випадкове закриття зміни через неуважність.

? Чи можна закривати зміну наступного дня, якщо касир забув зробити це ввечері?

Закрити зміну наступного дня технічно можливо, проте тривалість однієї зміни ПРРО за законом обмежена (не більше 24 годин). Щоб касири не забували виконувати цю обов’язкову процедуру, у програмі рекомендується активувати функцію відображення нагадування про необхідність закриття зміни перед виходом з програми та повідомлення про перевищення допустимого ліміту тривалості зміни.

Рекомендації для запобігання технічним збоям у роботі ПРРО

Для забезпечення безперебійної та стабільної роботи фіскального модуля дотримуйтеся наступних правил:

1. Своєчасно оновлюйте програму обліку. Більшість виявлених помилок, пов'язаних із розсинхронізацією офлайн-документів, дублюванням записів про закриття змін чи некоректними перевірками ліміту часу, виправлено у сучасних версіях Торгсофт (починаючи з версії 2020.0.30 та в оновленнях лінійки 2022 і 2026 років).

2. Оновіть системне оточення. Слідкуйте за версіями баз даних та криптографічних бібліотек. Багато технічних збоїв під час друку та перегляду звітів виникають через використання застарілих СКБД (наприклад, MS SQL Server 2005). Перехід на MS SQL Server 2008 R2 або новіший гарантує коректну обробку SQL-запитів.

3. Контролюйте актуальність цифрових підписів. Вчасно замінюйте КЕП та перевіряйте термін дії сертифікатів. Якщо сертифікат підписувача відкликано (код помилки 9 DocumentValidationError з причиною на кшталт EnCrSuperseded), ПРРО не зможе закрити зміну, і вам доведеться звертатися до акредитованого центру сертифікації для перевипуску ключа.