Каса всередині BAS: як узгодити продаж, оплату та фіскальний чек із ПРОРРО
Практична схема роботи каси без повторного введення продажу: як налаштувати інтеграцію BAS із ПРОРРО, контролювати відповідність документа, отриманих коштів і зареєстрованого чека, а також безпечно обробляти повернення, змішану оплату та збої зв’язку.. Що саме з’явилося в типових рішеннях BAS. Трикутник контролю: документ, гроші, чек. Звичайний продаж: правильна послідовність. Змішана оплата: одна покупка, кілька підтверджень. Повернення: не видалення продажу, а нова контрольована операція. Немає зв’язку: що насправді означає автономна робота. Помилка під час відправлення: коли повторювати безпечно. Щоденна звірка, яка виявляє пропуск і дубль. Наскрізне тестування перед запуском. Ролі й короткі інструкції для команди. Чек-лист керівника перед промисловим запуском. Практичний висновок
Що саме з’явилося в типових рішеннях BAS
Трикутник контролю: документ, гроші, чек
Звичайний продаж: правильна послідовність
Змішана оплата: одна покупка, кілька підтверджень
Повернення: не видалення продажу, а нова контрольована операція
Немає зв’язку: що насправді означає автономна робота
Помилка під час відправлення: коли повторювати безпечно
Щоденна звірка, яка виявляє пропуск і дубль
Наскрізне тестування перед запуском
Ролі й короткі інструкції для команди
Чек-лист керівника перед промисловим запуском
Покупець уже розрахувався, товар відпущено, у BAS є проведений документ — але чи зареєстровано чек у ДПС? Це питання не можна залишати до кінця зміни. Для бухгалтера й керівника успішний продаж має складатися не з однієї зеленої позначки на екрані касира, а з трьох узгоджених фактів: облікова система зафіксувала реалізацію, магазин дійсно отримав гроші, а фіскальний сервер прийняв розрахунковий документ.
Інтеграція каси з BAS прибирає повторне введення номенклатури, цін і сум в окремій касовій програмі. Проте вона не скасовує контроль — навпаки, переносить його з ручного набору даних на правильне відстеження статусів. Якщо касир не розуміє різниці між «документ проведено», «запит відправлено» і «чек фіскалізовано», автоматизація може так само швидко створити пропущений або подвійний чек.
Що саме з’явилося в типових рішеннях BAS
Із 12 серпня 2026 року «ПРОРРО» пропонується як окремий сервіс ІТС. У огляді нового сервісу ІТС «ПРОРРО» заявлено реєстрацію чеків у ДПС, роботу з різними видами оплат, сторнування і службові операції, контроль касових змін, друк та електронне надсилання чеків, а також автоматичне перемикання між онлайн- і офлайн-режимами. Серед рішень із реалізованою інтеграцією названо BAS ERP, BAS Комплексне управління підприємством, BAS Роздрібна торгівля та BAS Управління торгівлею.
Для конкретного орієнтира в цій статті розглянемо типову конфігурацію BAS Роздрібна торгівля, редакція 2.2, версія 2.2.15.5. Інтеграція з «ПРОРРО» з’явилася в гілці 2.2.15; тому перед налаштуванням треба відкрити відомості про програму у своїй базі й перевірити не лише назву конфігурації, а повний номер релізу. Наявність схожого пункту меню у старішій або зміненій базі ще не доводить, що типовий механізм підтримується.
Вбудована інтеграція — не те саме, що додаткова обробка
Вбудована інтеграція означає, що підтримку постачальника ПРОРРО реалізовано в типовій підсистемі торговельного обладнання конфігурації: касир працює зі звичайного робочого місця, а склад чека формується з документа продажу. Окремо переносити товари й суми до стороннього касового вікна не потрібно.
Водночас це не означає, що весь сервіс фізично міститься у файлі інформаційної бази. Потрібні чинний доступ до сервісу, зареєстрований ПРРО, КЕП касира або печатка, налаштована каса й установлений локальний компонент чи підключення до хмарного компонента постачальника. Це частини штатної схеми обміну, а не ручний повтор продажу.
Додаткова обробка — інша модель: до бази підключають зовнішній файл або розширення, яке самостійно читає документи, перетворює дані й звертається до сервісу. Вона може бути корисною для нетипової чи старої конфігурації, але має власну сумісність, правила оновлення і журнал помилок. Тому в акті впровадження варто прямо записати: назву та версію конфігурації, спосіб підключення ПРОРРО, версію компонента, перелік модифікацій і відповідального за оновлення.
Трикутник контролю: документ, гроші, чек
Надійна касова операція завершується лише тоді, коли збігаються три незалежні контури.
- Документ продажу в BAS. У ньому мають бути правильні товари, кількість, ціна, знижка, податкові ставки, сума до оплати, каса, зміна і касир. У BAS Роздрібна торгівля це передусім касовий чек, а за підсумками зміни — дані звіту про роздрібні продажі.
- Фактично отримані кошти. Для готівки це сума, прийнята касиром і наявна в касі; для картки — успішна операція платіжного термінала та подальше зарахування еквайром; для комбінованої оплати — окремі підтверджені частини, сума яких дорівнює підсумку продажу.
- Фіскальний чек. В онлайн-режимі доказом реєстрації є фіскальний номер, присвоєний сервером ДПС. Статус «відправлено» або наявність надрукованого папірця без фіскального номера не є рівнозначним підтвердженням.

Ці контури пов’язані, але не тотожні. Термінал може схвалити платіж, а фіскалізація — завершитися технічною помилкою. Чек може отримати фіскальний номер, а документ BAS — не провестися через блокування зміни. Готівку можна прийняти правильно, але в чеку помилково зазначити безготівковий спосіб оплати. Саме тому контроль будується не лише за загальною виручкою, а за кожною операцією і її ідентифікаторами.
Які реквізити варто зберігати разом
Щоб касир не шукав одну операцію в трьох журналах навмання, у BAS або контрольному звіті доцільно зберігати зв’язку:
- номер, дату й час документа продажу в BAS;
- касир, касове робоче місце, фіскальний номер ПРРО та номер зміни;
- сума продажу і розподіл за способами оплати;
- ідентифікатор транзакції платіжного термінала, якщо була картка;
- локальний ідентифікатор запиту до ПРОРРО;
- стан запиту: створено, відправляється, зареєстровано, офлайн, відхилено або результат невідомий;
- фіскальний номер чека або номер із зарезервованого офлайн-діапазону;
- текст і час останньої помилки, кількість спроб та автор повторної дії.
Ключовий принцип: фіскальний номер має повертатися в той самий документ, з якого сформовано чек. Якщо працівник бачить лише загальний журнал сервісу без посилання на продаж у BAS, пошук розбіжності під час закриття зміни перетворюється на ручне зіставлення сум і хвилин.
Звичайний продаж: правильна послідовність
- Касир сканує товари й перевіряє кількість, ціну, знижку та суму.
- Покупець обирає спосіб оплати. До фіскалізації система ще може дозволяти виправити склад кошика, але після фактичного списання коштів потрібен контрольований маршрут завершення операції.
- Підтверджується оплата: прийнято готівку або отримано успішну відповідь термінала.
- BAS формує розрахунковий документ і передає його через інтеграцію до ПРОРРО.
- Каса отримує результат реєстрації. В онлайн-режимі це фіскальний номер; лише після цього операція має перейти до стану «фіскалізовано».
- Покупець отримує паперовий або електронний чек, а в BAS зберігається зв’язок із фіскальним документом.
Якщо кроки 3–5 розірвалися, продаж не можна мовчки вважати завершеним. Система має показати касиру одну зрозумілу дію: дочекатися результату, перевірити статус, перейти в дозволений офлайн-режим або передати випадок адміністратору. Кнопка «пробити ще раз» не повинна бути першою реакцією.
Змішана оплата: одна покупка, кілька підтверджень
Припустімо, сума покупки становить 1 250 грн: 300 грн покупець дає готівкою, а 950 грн сплачує карткою. У BAS повинні бути дві частини оплати, у терміналі — успішна транзакція на 950 грн, у касі — фактично прийняті 300 грн, а у фіскальному чеку — ті самі способи й суми. Арифметика проста, але саме тут часто виникає розбіжність, якщо касир спочатку вибрав повну оплату карткою, а потім змінив рішення після відповіді термінала.

Перед відправленням чека система має перевірити рівність: готівка + картка + інші засоби оплати = сума розрахунку з урахуванням знижки та округлення. Після успішної карткової транзакції не можна просто змінити спосіб оплати в документі BAS. Спочатку з’ясовують стан операції в терміналі: якщо кошти списані, або завершують фіскалізацію з правильним розподілом, або виконують документоване скасування/повернення платежу.
У щоденному звіті змішані оплати корисно показувати окремо. Тоді бухгалтер бачить не лише суму чеків, а й три контрольні підсумки: готівку за ПРРО проти каси, карткові оплати за ПРРО проти підсумку термінала, загальну суму чеків проти продажів BAS.
Повернення: не видалення продажу, а нова контрольована операція
Проведений і фіскалізований продаж не виправляють видаленням касового документа. Повернення оформлюють окремою операцією на підставі первинного чека: у BAS виникає документ повернення, ПРОРРО реєструє видатковий чек, а покупцеві фактично повертають кошти.
Тут також мають збігтися три факти:
- у BAS відновлено товар і зменшено реалізацію на правильну кількість та суму;
- гроші реально видано з каси або повернено на картку, причому статус карткового повернення підтверджений;
- ПРОРРО зареєстрував видатковий чек із коректною сумою, способом розрахунку й посиланням на вихідну операцію, якщо такий реквізит передбачений робочим сценарієм.
Часткове повернення перевіряють особливо уважно: повертається саме потрібна позиція, а не пропорційна частина всього чека; знижка і податки розраховані за правилами конфігурації; сума повернення не перевищує доступного залишку первинного продажу. Повторне повернення тієї самої позиції має блокуватися або потрапляти до окремого контролю.
Якщо покупець сплачував і готівкою, і карткою, заздалегідь визначте правила повернення кожної частини. Касир не повинен сам вирішувати, що весь платіж зручніше віддати готівкою, коли первинні документи та банківська операція показують інший маршрут.
Немає зв’язку: що насправді означає автономна робота
Офлайн-режим ПРОРРО — не дозвіл складати чеки в довільну папку до появи інтернету. Це спеціальний фіскальний режим, у якому документам присвоюються номери із діапазону, заздалегідь сформованого фіскальним сервером ДПС. У чеку має бути позначка про офлайн-операцію, а програмне рішення контролює стан зв’язку.
За загальним правилом автономна робота може тривати не більше 36 годин поспіль і не більше 168 годин протягом календарного місяця. Однак станом на вересень 2026 року офіційне роз’яснення ДПС враховує спеціальну норму для періоду воєнного чи надзвичайного стану або обставин непереборної сили: ці строки можна перевищити, але лише за умови використання фіскальних номерів із отриманого діапазону. Без такого діапазону проводити розрахунки через ПРРО під час відсутності зв’язку заборонено.

Після відновлення зв’язку ПРРО повинен автоматично перейти до онлайн-обміну. Пакет із повідомленнями про початок і завершення офлайн-режиму та електронними копіями створених документів надсилається до фіскального сервера протягом години. Тому фраза «програма сама все дошле» має супроводжуватися перевіркою результату: скільки документів було в черзі, скільки прийнято, скільки відхилено і чи залишилися операції з невідомим статусом.
Порядок дій касира при зникненні мережі
- Не натискати повторно оплату або фіскалізацію, доки система визначає стан останнього запиту.
- Перевірити, чи ПРРО справді перейшов в офлайн-режим і чи доступний резерв фіскальних номерів.
- Переконатися, що чек отримав офлайн-номер і позначку автономної операції.
- Не змінювати вручну дату, час, нумерацію або склад черги.
- Після відновлення мережі дочекатися передавання пакета й перевірити кожен відхилений документ.
- Не закривати інцидент, поки кількість і сума чеків у BAS, черзі ПРОРРО та результатах приймання ДПС не збіглися.
Помилка під час відправлення: коли повторювати безпечно
Найнебезпечніша ситуація — не явна відмова, а невизначений результат. Наприклад, BAS передала чек, фіскальний сервер його прийняв, але відповідь не повернулася через обрив мережі. Якщо сформувати новий чек із новим ідентифікатором, у ДПС можуть опинитися дві фіскальні операції на один продаж.
Рішення залежить від стану:
- Явна відмова до реєстрації. Є текст перевірки, фіскального номера немає, а сервіс однозначно повідомляє, що документ не прийнято. Виправляють причину й повторюють відправлення штатною командою.
- Тайм-аут або обрив після відправлення. Результат невідомий. Спочатку запитують стан за локальним ідентифікатором, перевіряють журнал ПРОРРО та дані ДПС; новий чек не створюють.
- Є фіскальний номер. Повторне пробиття заборонене. Якщо BAS не зберегла відповідь, відновлюють зв’язок документа з уже зареєстрованим чеком за передбаченою сервісом процедурою.
- Офлайн-чек у черзі. Його не замінюють онлайн-чеком після появи мережі. Потрібно дочекатися передавання документа з тим самим офлайн-номером і перевірити квитанцію приймання.
Фіскальний чек, сформований онлайн, можна перевірити в реєстрі «Пошук фіскального чека» на вебпорталі ДПС за номером чека, фіскальним номером ПРРО, датою і часом. Офлайн-чек стане доступним у базі ДПС після передавання. Для внутрішнього контролю також використовуйте особистий кабінет сервісу та дані РРО в приватній частині Електронного кабінету. Одна відсутність чека в публічному пошуку одразу після офлайн-продажу ще не доводить помилку, але після синхронізації така операція не повинна залишатися непідтвердженою.
Щоденна звірка, яка виявляє пропуск і дубль
Підсумок зміни «сума зійшлася» недостатній: одна пропущена операція на 500 грн і один зайвий чек на 500 грн дадуть нульову різницю. Звіряти треба як суми, так і кількість та унікальні ідентифікатори.
Корисний реєстр контролю містить один рядок на продаж і такі колонки: номер документа BAS, час, сума, готівка, картка, ідентифікатор термінала, фіскальний номер, онлайн/офлайн, стан у ДПС, повернення та примітка. На його основі формують щонайменше п’ять винятків:
- продаж у BAS є, а фіскального або офлайн-номера немає;
- фіскальний чек є, а пов’язаного документа продажу немає або він не проведений;
- на один документ BAS припадає два фіскальні номери;
- сума або способи оплати в BAS і чеку не збігаються;
- чек довго залишається в офлайн-черзі чи має відмову після відновлення зв’язку.
Далі окремо звіряють підсумки: готівкові чеки з фактичною касою та службовими внесеннями/видачами; карткові чеки з журналом термінала й звітом еквайра; усі фіскальні чеки з документами BAS; повернення з видатковими чеками й фактичним рухом грошей. Z-звіт закриває зміну, але не виправляє невідповідність автоматично.
Наскрізне тестування перед запуском
Перевіряти інтеграцію варто не демонстраційним чеком на одну гривню, а набором сценаріїв, які відтворюють реальну зміну:
- звичайний продаж за готівку;
- продаж карткою з успішною відповіддю термінала;
- змішана оплата двома способами;
- повне й часткове повернення, зокрема на картку;
- помилка в обов’язковому реквізиті та повторна відправка після виправлення;
- обрив мережі до відправлення, під час очікування відповіді та після отримання фіскального номера;
- кілька офлайн-чеків, відновлення зв’язку та перевірка всієї черги;
- службове внесення, службова видача, відкриття й закриття зміни;
- спроба повторно фіскалізувати вже зареєстрований документ.
Для кожного тесту заздалегідь запишіть очікуваний результат у всіх трьох контурах. Якщо перевіряється лише екран касира, можна не помітити, що платіж пройшов у банку, але не потрапив у правильний спосіб оплати фіскального чека, або що чек зареєстрований, а документ BAS залишився непроведеним.
Ролі й короткі інструкції для команди
Касир відповідає за склад продажу, вибір оплати, отримання підтвердження та правильну реакцію на статус. Йому потрібна коротка пам’ятка без технічного жаргону: коли чек завершено, коли чек офлайн, коли не натискати повторно і кого викликати.
Адміністратор магазину контролює відкриті зміни, залишок офлайн-номерів, чергу відправлення, службові операції та незакриті помилки. Він не повинен виправляти розбіжність видаленням документа без погодженого маршруту.
Бухгалтер звіряє продажі, гроші й чеки, окремо аналізує еквайринг, повернення та округлення, зберігає реєстр винятків і контролює їх закриття.
ІТ-фахівець або партнер супроводу фіксує версії конфігурації та компонента, забезпечує резервне копіювання перед оновленнями, доступ до журналів і процедуру відновлення зв’язку вже зареєстрованого чека з документом BAS. Технічна помилка має залишати достатньо даних для діагностики, а не лише повідомлення «операцію не виконано».
Чек-лист керівника перед промисловим запуском
- у відомостях про програму зафіксовано точну назву, редакцію та версію конфігурації;
- зрозуміло, використовується типова інтеграція чи додаткова обробка/розширення, і хто її підтримує;
- ПРРО, каси, касири та КЕП належно зареєстровані, права доступу перевірені;
- на кожній касі протестовано готівку, картку, змішану оплату і повернення;
- фіскальний номер автоматично записується до пов’язаного документа BAS;
- повторна команда не створює новий чек, якщо результат першої відправки ще невідомий;
- є контроль отриманого офлайн-діапазону та сценарій зупинки роботи без нього;
- після відновлення мережі видно склад черги, результат кожного документа й дотримання годинного строку передавання;
- щоденний звіт порівнює не лише суми, а й кількість операцій та унікальні номери;
- визначено відповідального і строк закриття кожного відхиленого або непідтвердженого чека.
Практичний висновок
Цінність інтеграції BAS із ПРОРРО полягає не просто в тому, що касир працює в одному звичному сценарії. Головний результат — простежуваний ланцюг: один продаж у BAS, одна підтверджена оплата та один належно зареєстрований фіскальний чек. Для повернення будується такий самий ланцюг у зворотному напрямку.
Якщо система зберігає ідентифікатори, розрізняє відмову й невідомий результат, безпечно передає офлайн-чергу та дає бухгалтеру реєстр розбіжностей, автоматизація справді економить час. Якщо ж контроль обмежується фразою «чек начебто надрукувався», окреме касове вікно зникає, але касовий ризик залишається. Тому впровадження варто приймати не за наявністю кнопки «ПРОРРО», а за результатами наскрізної звірки кожного критичного сценарію.