«Попередня оплата» на кілька копійок у чеку ПРРО: як знайти причину округлення

«Попередня оплата» на кілька копійок у чеку ПРРО: як знайти причину округлення та DocumentValidationError

У торгівлі з випискою рахунка покупець може внести завдаток, оплатити замовлення частинами або остаточно розрахуватися під час отримання товару. ПРРО має відобразити кожний етап розрахунку та пов’язати остаточний чек із раніше фіскалізованою передоплатою. Підприємці запитують фахівців, чому в чеку з’являється рядок «Попередня оплата» на 0,01–0,59 грн, хоча нової передоплати не було, чому ДПС не приймає документ із DocumentValidationError, чи вплинуло округлення готівки, як розподілився платіж між двома ФОП і який саме документ треба перевірити. Відповідь залежить від того, на якому етапі виникла різниця: у вихідній накладній, попередньому фіскальному чеку, поточному платіжному документі, налаштуванні округлення або розподілі реалізації між підприємствами.

Базові поняття та актуальний стан питання

Передоплата — сума, яку покупець сплачує до повної передачі товару або завершення розрахунку. У Торгсофт вона може бути зафіксована одночасно:

• у документі замовлення або видатковій накладній;

• у фінансовому документі оплати;

• у фіскальному чеку ПРРО;

• у реквізитах наступної оплати або остаточного розрахунку.

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

Наступна оплата — чергова частина розрахунку за тим самим замовленням. Остаточний розрахунок закриває залишок за документом з урахуванням раніше прийнятих оплат.

DocumentValidationError, або код 9 у відповіді ПРРО, — загальна відмова валідації документа. Важливий не лише код, а весь текст після нього. Наприклад, сервер може вказати, що сума позицій не відповідає загальній сумі документа або сумі за формами оплати. Сам код не називає конкретне налаштування Торгсофт.

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

1. склад і суми товарів у поточній накладній;

2. уже зареєстровану передоплату;

3. поточну оплату;

4. округлення;

5. розподіл платежу між ФОП або юридичними особами.

У різних випусках Торгсофт виправляли окремі сценарії коду 9: дробові знижки, часткові платежі, готівкове округлення, поєднання фіскальних і нефіскальних товарів, бонуси, валютні накладні та розподіл реалізації між підприємствами. Тому коректна діагностика починається з актуальної версії програми, але оновлення саме по собі не змінює вже зареєстрований чек і не відновлює порушений зв’язок між старими документами.

Яка рівність має виконуватися у фіскальному чеку

Спрощено ПРРО перевіряє, чи узгоджуються між собою три частини документа: сума фіскальних товарних рядків після знижок та округлення = сума поточного розрахунку = сума за формами оплати.

Для передоплати перевірка складніша, тому що поточний чек має також коректно врахувати раніше фіскалізовані суми та залишок боргу. У програмі можуть одночасно використовуватися значення:

• «Сума» — розрахована сума документа до касового округлення;

• «До сплати» — сума, яку фактично має сплатити покупець після застосованого правила округлення;

• попередні оплати;

• поточна оплата;

• борг;

• суми окремих чеків, якщо реалізацію поділено між підприємствами.

Якщо одна частина алгоритму використала 999,97 грн, а інша — округлені 1 000,00 грн, різниця 0,03 грн стає суттєвою для валідації. Для ДПС немає допустимого «копійчаного відхилення»: контрольні суми мають збігтися точно.

Звідки беруться одна, кілька або десятки копійок

 1. Пропорційний розподіл часткової оплати між товарами

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

Наприклад, у замовленні є товари на 199,99 грн і 100,01 грн, разом 300,00 грн. Передоплата становить 100,00 грн. Математичні частки дорівнюють приблизно 66,6633 грн і 33,3367 грн. У чеку вони мають перетворитися на 66,66 грн та 33,34 грн, щоб разом залишилося 100,00 грн.

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

2. Різниця між сумою документа та готівковою сумою «до сплати»

У Торгсофт є окремі механізми:

• округлення загальної суми чека;

• округлення лише готівкової оплати для України;

• застосування округлення у режимі торгівлі з випискою рахунка.

Глобальне округлення суми чека впливає на весь документ і має пріоритет над індивідуальним округленням цін за видами товару. Спеціальне касове округлення має стосуватися готівкової частини, а не оплати карткою чи іншого безготівкового розрахунку.

З 1 жовтня 2025 року Національний банк поступово вилучає з готівкового обігу монети 10 копійок. Вони залишаються платіжним засобом, але за відсутності таких монет у касі загальну суму готівкового розрахунку округлюють до 50 копійок: 1–24 коп. — до 00, 25–49 коп. — до 50, 51–74 коп. — до 50, 75–99 коп. — до наступної гривні. Безготівкові платежі не округлюють. Правила пояснює Національний банк України.

Практичний сценарій: накладна має суму 249,97 грн. Під час готівкової передоплати каса приймає 250,00 грн після округлення. Якщо остаточний розрахунок надалі відніме від первісної суми документа саме 250,00 грн, а блок товарів або боргу розрахується від 249,97 грн, виникне різниця 0,03 грн. Історичне виправлення такого класу в Торгсофт описує зміну №201060: у блоці оплати, передоплати та боргу потрібно враховувати значення «Сума», а не лише «До сплати». Деталі наведено в описі версії 2022.4.7.

3. Зміна накладної після фіскалізації передоплати

Це один із найважливіших сценаріїв. Первинний чек передоплати вже зафіксував у ДПС конкретні товари, кількість, ціни, знижки та суму. Якщо після цього в накладній:

• змінити ціну;

• додати або видалити товар;

• змінити кількість;

• надати іншу знижку;

• змінити ознаку фіскальності товару;

• перерозподілити товар між підприємствами,

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

Наприклад, після передоплати касир збільшив ціну однієї позиції на 1 грн. За наступного пропорційного розподілу ця гривня може змінити частки кількох товарів, а результатом стане не рівно 1 грн, а службовий залишок «Попередня оплата» 0,01 грн або 0,59 грн. Саме такі причини описано у довідці Торгсофт про чеки передоплати.

Правильний порядок зміни замовлення після фіскальної передоплати:

1. переконатися, що первинний чек справді зареєстрований у ДПС;

2. оформити фіскальне повернення передоплати штатною операцією;

3. змінити склад, кількість, ціну або знижку в документі;

4. прийняти оплату заново;

5. сформувати новий чек передоплати або остаточного розрахунку.

Не потрібно компенсувати залишок довільним товаром чи послугою на 0,01 грн: це приховує причину, але змінює склад розрахункової операції.

4. Поділ однієї реалізації між кількома ФОП

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

Наприклад, покупець сплачує карткою 1 000,00 грн, а товари належать двом ФОП у співвідношенні, яке дає частки 333,335 грн і 666,665 грн. У платіжному документі неможливо записати пів копійки. Один чек має отримати 333,33 грн, інший — 666,67 грн, інакше їхня сума не дорівнюватиме 1 000,00 грн.

В актуальному алгоритмі Торгсофт залишок від округлення передається одному з чеків так, щоб загальна сума зійшлася. Для реалізації, розділеної більш ніж на два підприємства, попередні частини округлюються вниз до копійки, а залишок отримує остання. Окремо враховується округлення готівки до 10 або 50 копійок. Цю зміну для розподілу між підприємствами описано у версії 2026.0.3, завдання №205082.

Однак правильна загальна сума ще не означає, що налаштування виконано повністю. Для кожного підприємства потрібно перевірити:

• прив’язку виду товару до потрібного ФОП або юридичної особи;

• відповідний ПРРО та його чинний фіскальний номер;

• форму оплати;

• банківський рахунок і еквайринг, якщо використовується картка;

• підсумок товарних рядків та оплату саме в окремому чеку цього підприємства.

Кожний чек проходить валідацію самостійно. Сервер не компенсує нестачу 0,01 грн у чеку одного ФОП надлишком 0,01 грн у чеку іншого.

5. Фіскальні та нефіскальні товари в одному документі

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

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

6. Нерівномірний розподіл бонусної оплати

Коли бонусами повністю оплачено одну позицію, а решту — іншою формою оплати, пропорційний розподіл та округлення можуть тимчасово дати для товару бонусну частку на копійку більшу за його вартість. Такий сценарій, у тому числі в чеках повернення, виправляли в оновленні 2022.0.59.

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

7. Валютний документ та гривневий фіскальний розрахунок

Фіскальна операція в Україні проводиться у гривні. Якщо рахунок або взаєморозрахунок ведеться в іноземній валюті, різні курси чи моменти перерахунку можуть дати гривневий еквівалент із копійчаною різницею. В історії оновлень Торгсофт окремо описано код 9 для часткової безготівкової оплати валютної накладної, коли сума платежу не дорівнювала сумі накладної у національній валюті.

Для ПРРО потрібно перевіряти саме гривневі значення, які передаються у чек. Не слід фіскалізувати валютну суму як гривневу без коректного перерахунку.

8. Видалення або сторнування одного з пов’язаних документів

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

Тому не видаляйте платіж, чек, офлайн-пакет або зв’язок між документами для «обнулення копійок». Спочатку встановіть фіскальний статус кожного чека.

Покрокова перевірка: як знайти конкретну причину

Збережіть повний текст відповіді та зробіть знімок екрана. Відкрийте аналітику за ПРРО і з’ясуйте, чи чек:

• відхилено сервером;

• зареєстровано, але відповідь не потрапила до програми;

• залишився в черзі або офлайн-пакеті;

• сторновано чи повернено.

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

DocumentValidationError — це категорія, а не діагноз. Випишіть із повідомлення:

• суму товарних рядків;

• суму документа або поточної оплати;

• суму за формами оплати;

• розмір і знак розбіжності;

• назву поля або блока, який сервер вважає неузгодженим.

Якщо в тексті є дві суми, відніміть меншу від більшої. Отримані 0,01, 0,03, 0,50 або 0,59 грн допоможуть зіставити ситуацію з конкретним видом округлення.

Зафіксуйте, що саме формувалося:

• перша передоплата;

• наступна часткова оплата;

• остаточний розрахунок;

• повернення передоплати;

• сторно;

• звичайний продаж;

• продаж, розділений між підприємствами.

Якщо рядок «Попередня оплата» з’явився лише в остаточному чеку, насамперед перевіряйте відповідність первинної передоплати поточному стану накладної.

Для одного замовлення відкрийте та порівняйте:

1. рахунок або замовлення;

2. видаткову накладну;

3. фінансовий документ першої оплати;

4. перший фіскальний чек передоплати;

5. наступні платежі та чеки;

6. повернення або сторно, якщо вони були;

7. поточний чек, який не пройшов валідацію.

Потрібно встановити не лише поточні суми, а й послідовність подій.

Порівняйте первинний чек із поточною накладною за такими полями:

• товар і його фіскальна назва;

• кількість;

• ціна;

• знижка;

• ставка та група оподаткування;

• ознака фіскальності;

• вид товару та пов’язане підприємство;

• валюта і гривневий еквівалент.

Навіть якщо загальна сума змінилася на цілу гривню, пропорційний розподіл між позиціями може дати копійчаний залишок.

Відкрийте Налаштування → Параметри → Чек і перевірте:

• «Округлення суми чека»;

• «Округлювати готівкову оплату (лише для України)»;

• крок округлення — 10 або 50 копійок;

• «Використовувати округлення в торгівлі з випискою рахунка».

З’ясуйте, які налаштування діяли на дату першої передоплати, а не лише які встановлено зараз. Не змінюйте їх у робочій базі під час відкритої зміни без розуміння впливу на інші каси.

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

Налаштування «Друк чека накладної на ПРРО» має режими:

• «На суму оплати»;

• «На суму оплати і боргу»;

• «Запитати користувача».

Ці режими впливають на те, яку суму програма має фіскалізувати під час передоплати або часткового розрахунку. Їхню логіку описано в оновленні 2022.0.48. Якщо касир очікував чек лише на фактичну оплату, а режим охопив також борг, пошук копійок треба починати з невідповідності типу чека, а не з ручного коригування суми.

Складіть просту таблицю:

Перевірте дві рівності:

• у кожному рядку сума товарів дорівнює сумі оплати відповідного чека;

• сума всіх окремих чеків дорівнює платежу покупця.

Якщо перша рівність порушена, причина в окремому чеку або прив’язці підприємства. Якщо перша виконується, а друга ні, перевіряйте алгоритм розподілу залишку та версію Торгсофт.

Не орієнтуйтеся лише на одну «мінімальну версію». Виправлення накопичувалися у кількох випусках:

• 2022.0.49 — часткові оплати, дробові знижки, касове округлення, переплата та повернення передоплати;

• 2022.0.57 — окремі розбіжності для фіскальних і нефіскальних позицій;

• 2022.0.59 — валютні накладні та нерівномірна бонусна оплата;

• 2026.0.3 — розподіл округленої суми між підприємствами.

Опис окремих сценаріїв є в оновленні 2022.0.49, 2022.0.59 та 2026.0.3.

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

Як діяти після встановлення причини

Чого не варто робити

• Не додавайте довільну послугу «Округлення» або товар на 0,01 грн лише для вирівнювання чека.

• Не змінюйте ціну товару на кілька копійок після фіскалізації передоплати.

• Не видаляйте локальний чек, платіж або офлайн-пакет, не перевіривши стан документа в ДПС.

• Не замінюйте остаточний розрахунок звичайним продажем: у ньому не буде коректного зв’язку з передоплатою.

• Не перемикайте ПРРО, ФОП чи форму оплати після прийняття платежу без перевірки всього ланцюжка.

• Не вимикайте округлення одночасно на всіх касах, якщо не визначено, яке саме правило спричинило розбіжність.

• Не редагуйте фіскальні таблиці бази даних вручну.

Як швидко визначити джерело за ознакою

Відповіді на поширені питання

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

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

Ні. DocumentValidationError охоплює різні порушення структури та контрольних співвідношень. Потрібно читати весь текст відповіді. Загальну логіку коду пояснює довідка Торгсофт.

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

Оновлення виправляє алгоритм наступних розрахунків, але не переписує зареєстрований у ДПС чек. Для старого документа все одно потрібно встановити його статус і коректно оформити повернення або завершення розрахунку.

Ні. Це розрахунковий елемент чека. Ручне видалення не усуває розбіжність між товарними сумами й оплатою та може створити іншу невідповідність.

Ні. Правила касового округлення стосуються готівкових розрахунків. За змішаної оплати треба окремо перевірити готівкову та безготівкову частини.

Для покупця операція може починатися з одного кошика й однієї загальної суми. Торгсофт розділяє її на окремі реалізації та чеки. Кожний ФОП повинен мати свій коректний чек, ПРРО і належну йому частину оплати; підсумок окремих частин має дорівнювати платежу покупця.

Лише після підтвердження, що попередня спроба не зареєстрована. Спочатку перевірте аналітику ПРРО та стан документа на фіскальному сервері.

Що підготувати для технічної підтримки

Щоб фахівець визначив джерело розбіжності, надайте:

• повний знімок екрана з кодом і текстом відповіді;

• номер версії Торгсофт;

• номер і дату рахунка, замовлення, накладної та реалізації;

• номер першого фіскального чека передоплати;

• суму першої, наступних і поточної оплати;

• значення «Сума», «До сплати», попередніх оплат і боргу;

• форми оплати та їхні суми;

• перелік ФОП, ПРРО і частин реалізації, якщо продаж розділяється;

• інформацію, чи змінювали товар, кількість, ціну, знижку або вид товару після передоплати;

• знімки налаштувань округлення;

• статус усіх пов’язаних чеків в аналітиці ПРРО.

Не надсилайте файл особистого ключа КЕП і пароль до нього.

Звернення можна створити безпосередньо в програмі: Допомога → Запит на техпідтримку.

Також доступні офіційні канали:

•  телефон: +38 (067) 558-37-84, понеділок–субота, 09:00–18:00;

•  Telegram: @torgsoft_help;

•  електронна пошта: info@torgsoft.ua.

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

Контрольна послідовність перед повторною фіскалізацією

1. Перевірити, чи попередній чек не зареєстрований у ДПС.

2. Зберегти повний текст DocumentValidationError.

3. Визначити тип операції та точний розмір розбіжності.

4. Зіставити первинну передоплату з поточною накладною.

5. Перевірити «Суму», «До сплати», форму оплати та налаштування округлення.

6. Для кількох ФОП перевірити кожний чек і загальний підсумок.

7. Звірити версію Торгсофт з описами виправлених сценаріїв.

8. Створити резервну копію бази перед змінами або оновленням.

9. Виправити саме джерело розбіжності: документ, налаштування, прив’язку або послідовність повернення.

10. Повторно сформувати чек лише після контролю статусів і сум.

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