Касса внутри 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, одна подтверждённая оплата и один надлежащим образом зарегистрированный фискальный чек. Для возврата строится такая же цепочка в обратном направлении.
Если система хранит идентификаторы, различает отказ и неизвестный результат, безопасно передаёт офлайн-очередь и даёт бухгалтеру реестр расхождений, автоматизация действительно экономит время. Если же контроль ограничивается фразой «чек вроде бы распечатался», отдельное кассовое окно исчезает, но кассовый риск остаётся. Поэтому внедрение стоит принимать не по наличию кнопки «ПРРО», а по результатам сквозной сверки каждого критического сценария.