Згідно з вимогами законодавства, під час інтернет-торгівлі, роботи під замовлення або продажу товарів у розстрочку, підприємці зобов'язані фіскалізувати не лише факт передачі товару, а й отримання авансу.
Режим фіскалізації передоплат у Торгсофт створює правильний ланцюжок чеків: від чека «Передоплата» (із зазначенням частки сплаченого товару) до чека «Остаточний розрахунок» (із посиланням на фіскальний номер першого платежу та відображенням залишку боргу).
Проте на практиці цей процес є одним із найскладніших для користувачів. Підприємці найчастіше звертаються до техпідтримки з проблемою, коли ПРРО відхиляє чек передоплати або післяплати з помилкою DocumentValidationError (код 9) через розбіжності в сумах до копійки, неможливість провести змішану оплату, появу фантомної «Попередньої оплати» у звичайних чеках або складнощі при спробі повернути аванс.
Цей матеріал детально розбирає технічні причини помилок під час фіскалізації передоплат та способи їх уникнення.
Як працює алгоритм фіскалізації передоплат у Торгсофт
Оскільки немає єдиного затвердженого ДПС стандарту щодо формування чеків часткової оплати, Торгсофт реалізував механізм, що базується на офіційних роз'ясненнях податкової.
-
Чек передоплати. При внесенні авансу за рахунком або замовленням кількість товару в чеку розраховується пропорційно — як відношення суми передоплати до загальної суми чека. Перед назвою товару автоматично додається фраза «Передоплата за».
-
Чек чергової оплати / Остаточний розрахунок. При наступних оплатах формується чек, який містить фіскальний номер першого чека передоплати. У ньому вказується повна вартість та кількість товару, але до сплати виводиться лише сума поточного внеску або залишок боргу.
Типові помилки та їх вирішення (Troubleshooting)
1. Помилка DocumentValidationError (код 9): сума по рядкам не дорівнює загальній сумі в документі
Це найпоширеніша помилка, яка блокує друк чека передоплати або остаточного розрахунку. Вона означає, що сума вартості товарів у XML-файлі чека не збігається із загальною сумою оплат, відправленою до ДПС. Основні причини:
- Дробова кількість товару та нецілі знижки. Якщо в рахунку присутні товари з дробовою кількістю (наприклад, вагові), а до них застосовані складні знижки або округлення, при розрахунку пропорції для передоплати виникала похибка, через яку сума по рядках відрізнялася від суми документа.
-
Рішення: ця проблема була глобально виправлена в оновленнях Торгсофт (починаючи з версій 2022.0.57 та 2022.4.10) за рахунок збільшення точності розрахунку цін. Необхідно оновити програму.
-
Фіскальний та нефіскальний товар у одному рахунку. Якщо ви відвантажуєте фіскальний товар і нефіскальну послугу (наприклад, доставку), Торгсофт намагається пропорційно розділити суму передоплати між фіскальною та нефіскальною частинами. При округленнях (особливо при часткових чи змішаних оплатах готівка+картка) це часто призводило до помилки.
-
Рішення: оновіть програму до актуальної версії. Як превентивний захід — рекомендується виписувати окремі рахунки на фіскальні та нефіскальні позиції, або зробити всі товари/послуги у базі фіскальними.
-
Передоплата за рахунком в іноземній валюті. Програмний РРО працює виключно з національною валютою (гривнею). Якщо рахунок створено у валюті (наприклад, USD чи KZT), а передоплата вноситься у гривні, через конвертацію курсів виникає похибка в копійках, і сума часткової сплати перевищує або стає меншою за суму документа.
-
Рішення: розробники відключили можливість прямого формування фіскальних чеків з оплат не в національній валюті. Для уникнення помилок взаєморозрахунки, що підлягають фіскалізації, слід проводити виключно у гривні.
-
Проблема округлення готівки. Якщо сума боргу за рахунком не кратна 10 копійкам, а оплата вноситься готівкою, під час формування чека остаточного розрахунку або переплати може виникнути розбіжність.
-
Рішення: Торгсофт скасував автоматичне округлення до 10 копійок для чеків ПРРО, якщо у формах оплати документа відсутня готівка.
2. У чеку раптово з'являється рядок «Попередня оплата» на кілька копійок
Підприємці іноді помічають, що у звичайних фіскальних чеках або при формуванні видаткової накладної з'являється незрозуміла форма оплати «Попередня оплата» (наприклад, на 1 чи 59 копійок), що збільшує загальну суму чека.
-
Причина 1 (Зміна ціни). Користувач створив рахунок, прийняв за ним передоплату, а потім змінив відпускну ціну товару в рахунку (наприклад, збільшив її на 1 грн) і створив видаткову накладну, доплативши різницю.
-
Причина 2 (Оплата бонусами). При оплаті реалізації бонусами, якщо сума бонусів повністю покрила вартість однієї з позицій, через механізм округлення програма могла розцінити, що товар оплачено бонусами більше за його вартість. Ця різниця вилазила у ПРРО як «Попередня оплата».
- Рішення: не змінюйте ціни, кількість або знижки в рахунку після того, як по ньому вже був пробитий фіскальний чек передоплати. Помилку з бонусами виправлено у нових версіях.
3. Помилка «Не визначений фіскальний номер документа, для якого здійснюється повернення»
Виникає під час спроби зробити повернення передоплати клієнту в режимі «Торгівля з випискою рахунка».
-
Причина. Спроба роздрукувати фіскальний чек на повернення авансу, хоча чек на внесення цього авансу не був роздрукований (або пройшов як нефіскальний).
- Рішення: ПРРО не може повернути фіскальну передоплату, якої не існує в реєстрах податкової. Повернення в такому разі слід робити без друку фіскального чека.
4. Від’ємні суми у фіскальному чеку передоплати
У старих версіях програми (наприклад, 2022.0.3) при формуванні чека за видатковою накладною, по якій була передоплата, якщо в чеку містилося 2 одиниці одного товару, чек формував від'ємну суму оплат та негативну кількість.
- Рішення: оновити програму Торгсофт.
Головні правила безпомилкової роботи з авансами
-
Послідовність дій. Правильний алгоритм роботи з інтернет-замовленнями: Створити рахунок -> Внести передоплату з друком чека -> Створити видаткову накладну -> Натиснути «Оплата за видаткову в рахунок передоплати» -> Роздрукувати чек на залишок боргу.
-
Ніяких змін «заднім числом». Якщо за документом (замовленням чи рахунком) вже внесено фіскальну передоплату, заборонено додавати/видаляти товари, змінювати їх кількість чи ціну. Це неминуче призведе до того, що під час остаточного розрахунку суми не зійдуться (помилка DocumentValidationError). Якщо замовлення змінилося, необхідно спочатку зробити фіскальне повернення передоплати на повну суму, внести зміни в документ, і лише потім заново пробити аванс.
-
Не видаляйте часткові оплати. Видаляти оплати, за якими вже було надруковано фіскальний чек, категорично не рекомендується, оскільки чеки залишаються в ДПС. Завжди використовуйте механізм повернення передоплати.
Законодавчі норми
Станом на травень 2026 року базове правило таке: якщо підприємець приймає оплату за товар через РРО/ПРРО, він має провести розрахунок на повну суму операції та видати покупцю паперовий або електронний розрахунковий документ; це стосується і замовлень через інтернет. Простими словами: не лише “віддали товар — пробили чек”, а й “отримали частину грошей — правильно показали цю частину в ланцюгу чеків”. ДПС пояснює: при авансі перший чек має показувати “аванс за…” із назвою або артикулом товару та сумою, яку фактично отримали; останній чек має містити повну номенклатуру, повну ціну, кількість, раніше отриманий аванс і суму до сплати після його врахування. Якщо аванс надійшов саме як банківський переказ з рахунку на рахунок за IBAN без відпуску товару, ДПС вказує, що сам такий аванс може не потребувати РРО/ПРРО, але потім його треба відобразити у першому фіскальному чеку, коли буде наступна оплата через РРО/ПРРО або відпуск товару. Джерела: Закон України № 265/95-ВР, ст. 3, ст. 9; роз’яснення ДПС щодо авансів. (Закон України)
У Торгсофт це краще оформлювати через спеціальний режим фіскалізації передоплат: створити рахунок або замовлення, прийняти аванс і надрукувати чек “Передоплата”, а при відвантаженні сформувати чек остаточного розрахунку із прив’язкою до першого фіскального чека та відображенням залишку. Програма допомагає зібрати правильний ланцюг документів, щоб у ДПС не було “відірваних” оплат, а у покупця — незрозумілих сум. Після першого фіскального чека не варто змінювати ціну, кількість, знижку або склад замовлення: для ПРРО це виглядає так, ніби перший і останній чек описують різні операції, і тоді виникають розбіжності до копійки. Якщо замовлення змінилося, безпечніший шлях — повернути фіскалізований аванс, виправити замовлення і провести оплату заново. Фіскальний чек за Наказом Мінфіну № 13 повинен містити, зокрема, назву товару/послуги, кількість і вартість, форму оплати, суму та фіскальний номер, тому “дрібні” розбіжності в копійках для ПРРО юридично не дрібниця. (Закон України)
Практичне правило для ритейлера: працюйте в гривні, оновлюйте Торгсофт до актуальної версії, не змішуйте без потреби фіскальні й нефіскальні позиції в одному складному рахунку, не видаляйте фіскалізовані часткові оплати, а при поверненні авансу використовуйте саме механізм повернення. Якщо чек авансу не був фіскалізований, ПРРО не зможе коректно зробити фіскальне повернення “того, чого немає” у фіскальному ланцюгу. Короткий приклад з практичної публікації ДПС: покупець вніс аванс, потім відмовився від товару; ДПС пояснює, що при поверненні товару, купленого з оплатою частинами, анулюванню підлягає весь ланцюг чеків у межах такого продажу. Для бізнесу це означає: не виправляти аванс “заднім числом”, а робити прозору послідовність чеків. Інакше ризик не лише в помилці DocumentValidationError, а й у штрафі за непроведення або проведення розрахунку на неповну суму: ст. 17 Закону № 265/95-ВР передбачає фінансові санкції 100% суми порушення за перше порушення і 150% — за наступне. (zir.tax.gov.ua)
Повернутися до попереднього кроку