ОФД и касса: что должно работать на сервере, чтобы чеки уходили

MAATRIX

Онлайн-касса обязана передавать данные о каждой продаже через оператора фискальных данных, и с этим требованием знакомы все, кто работает по 54-ФЗ. Но между «касса пробила чек» и «чек дошёл до ОФД и налоговой» стоит инфраструктура — сеть, сервер, очередь на отправку, — и именно она чаще всего оказывается слабым звеном. Разберём, что должно быть исправно на этой стороне, чтобы передача чеков не срывалась, и как заранее замечать проблему, а не узнавать о ней от бухгалтера через месяц.

Как устроена цепочка передачи чека technически

Смысл фискализации в том, что каждый чек — это не просто бумажка для покупателя, а структурированная запись, которая должна попасть к оператору фискальных данных, а через него — в налоговую. Технически цепочка выглядит так:

1. Касса (или кассовое ПО, если у вас программная реализация ККТ) формирует фискальный документ.
2. Документ подписывается фискальным накопителем внутри кассы.
3. Касса (либо промежуточный сервер-агрегатор, если у вас несколько точек продаж и общая интеграция) отправляет документ оператору фискальных данных по сети.
4. ОФД подтверждает приём, касса помечает документ как отправленный.
5. Если подтверждения нет — документ остаётся в очереди на кассе и повторяется до успешной отправки.

Важный нюанс: касса физически обязана хранить неотправленные документы и пытаться отправить их снова — это заложено в саму логику работы ККТ с фискальным накопителем, а не является дополнительной опцией. Но здесь есть предел: у фискального накопителя есть ограниченный срок, в течение которого он может держать неотправленные документы без блокировки кассы (это несколько десятков часов — точный срок лучше сверяйте по документации к конкретной модели ФН, не полагайтесь на приблизительные цифры из статей). Если связь не восстанавливается достаточно долго, касса блокируется и продажи физически становятся невозможны. Отсюда практический вывод: инфраструктурная часть — это не про «чтобы было красиво в отчётах», а про то, чтобы касса вообще могла продолжать продавать.

Если у вас не отдельно стоящая касса с собственным модемом, а интеграция через сервер — свой бэкенд, который агрегирует чеки с нескольких точек продаж, работает с эквайрингом, ведёт складской учёт и уже оттуда стыкуется с ОФД, — то к цепочке добавляется ещё один потенциальный отказ: сам этот сервер. И вот здесь начинается зона ответственности, которая реально в ваших руках.

Сетевой канал в точке продаж

Первое и самое очевидное звено — интернет-канал непосредственно там, где стоит касса или откуда касса стучится на ваш сервер интеграции.

Для розничной точки типичная проблема — не «интернета совсем нет», а нестабильность: канал то есть, то пропадает на секунды-минуты, особенно в моменты пиковой нагрузки на провайдера в округе (вечер, выходные, распродажи — как раз тогда, когда касса больше всего работает). Рекомендации на общем уровне:

• Резервный канал. Основной провод + LTE-резерв на роутере с автоматическим переключением снижает риск полного простоя точки. Для точки, где простой кассы прямо означает потерю выручки, резервный канал окупается быстро.
• Отдельная сеть для кассового оборудования. Касса и терминал эквайринга в идеале не должны сидеть в одной перегруженной Wi-Fi-сети с гостевым доступом или камерами видеонаблюдения — широковещательный трафик и случайные перегрузки такой сети создают лишние задержки и потери пакетов именно тогда, когда идёт фискализация.
• Контроль на стороне роутера. Простой мониторинг связности (проверка доступности внешнего узла раз в минуту с логированием обрывов) на самом роутере точки продаж — недорогой способ понять, была ли проблема в интернете точки, если чек не ушёл вовремя.

Здесь же стоит развеять расхожее заблуждение: наличие интернета «в принципе» (страница гугла грузится) не гарантирует, что конкретное соединение к оператору фискальных данных или к вашему серверу интеграции пройдёт стабильно — оно может упираться в качество маршрута, а не в наличие канала как такового.

Доступность сервера интеграции

Если между кассами и ОФД у вас стоит свой сервер — это отдельная точка отказа, и относиться к ней нужно так же серьёзно, как к самому кассовому оборудованию.

Базовые требования к такому серверу на общем уровне:

• Стабильный аптайм. Сервер интеграции с ОФД — не тот сервис, который можно перезагружать «когда удобно» посреди рабочего дня без предупреждения. Плановые работы стоит выносить на ночь или выходные с минимальной нагрузкой продаж.
• Достаточный запас по ресурсам. Пиковая нагрузка (открытие точки утром, обеденный наплыв, вечерний час пик) не должна упираться в CPU или память — сервер, который «еле дышит» в обычном режиме, в пиковый момент начнёт откладывать обработку чеков в очередь, и очередь будет расти быстрее, чем разгребаться.
• Резервирование самого сервера. Для сети из нескольких точек продаж имеет смысл держать вторичный узел (горячий или холодный резерв), на который можно быстро переключиться при отказе основного — простой сервера интеграции при десятках активных касс кратно дороже простоя сети одной точки.
• Мониторинг диска. Очередь неотправленных документов, логи и локальные копии фискальных данных занимают место — закончившееся место на диске останавливает обработку так же надёжно, как и обрыв сети.

Отдельно стоит сказать про локацию такого сервера. Фискальные и персональные данные покупателей, которые проходят через интеграцию, по требованиям законодательства должны обрабатываться в российском контуре — это не тема для компромиссов ради экономии на хостинге. Разбор требований к серверу для кассы и эквайринга на этот счёт есть в отдельной статье: VPS в России для онлайн-касс и эквайринга.

Обработка очереди неотправленных чеков

Разрыв связи — это не аварийная ситуация, а штатный сценарий, к которому инфраструктура должна быть готова с самого начала, а не «доделана» после первого инцидента.

Принцип на общем уровне такой: каждый чек, который не удалось подтверждённо отправить, должен встать в очередь с повтором, а не потеряться и не заблокировать обработку следующих чеков. Ключевые моменты, за которыми стоит следить при построении такой логики (собственной или на стороне используемого кассового ПО):

• Идемпотентность повторов. Если сервер один раз отправил чек, но не получил подтверждение (например, оборвалась связь уже после отправки, но до ответа), при повторной попытке не должно происходить задваивание фискального документа. Это забота кассового ПО и протокола работы с ФН, но на уровне интеграции стоит понимать этот риск и не городить поверх него свою логику ретраев, которая его усугубит.
• Экспоненциальная задержка между повторами. Долбить оператора запросами каждую секунду при затяжном сбое — плохая идея: это создаёт лишнюю нагрузку и на канал, и на сам ОФД. Разумный бэкофф (растущий интервал между попытками) — стандартный паттерн для любой очереди с повторами, не только в кассовой теме.
• Видимость размера очереди. Вы должны в любой момент видеть, сколько документов ждут отправки и как давно самый старый из них в очереди. Растущая и не убывающая очередь — первый и самый надёжный сигнал, что где-то в цепочке проблема, ещё до того, как касса физически заблокируется. Общие принципы работы с такими очередями разобраны здесь: бэклог очереди и отказ в соединении.
• Алерт по возрасту самого старого документа в очереди, а не только по факту наличия очереди — очередь из пяти документов, зависших на два часа, тревожнее, чем очередь из полусотни документов, которая обычно рассасывается за десять минут.

Для точек, где связь исторически нестабильна (удалённые локации, места с плохим покрытием), локальная буферизация на самой кассе или на локальном мини-сервере в точке продаж снижает зависимость от постоянной связи с центральным сервером интеграции. Похожий подход к работе кассы при проблемах с интернетом на месте разобран в статье касса без интернета: работа через локальный сервер.

Типичные инфраструктурные причины сбоя передачи чеков

Если чеки не доходят или доходят с задержкой, на практике причина почти всегда одна из следующих (по убыванию частоты, по общему опыту, без претензии на точную статистику):

Последний пункт кажется мелочью, но на практике встречается регулярно: если время на сервере или кассе «уехало» на минуты (сбойный NTP, ручная правка времени, зависшая виртуальная машина после долгой паузы), это может ломать проверку TLS-сертификатов и подпись документов, и внешне выглядит как «ОФД не принимает чеки», хотя причина — в рассинхроне часов. Настроенный и работающий NTP-клиент на сервере интеграции — простая, но легко забываемая вещь.

Мониторинг: что и как отслеживать

Задача мониторинга здесь простая по формулировке и не всегда простая в реализации: узнать о проблеме раньше, чем о ней узнает бухгалтер, который свёл отчёты и увидел расхождение, или того хуже — раньше, чем касса заблокируется от переполнения очереди в фискальном накопителе.

Практический набор того, что стоит контролировать:

• Доступность сервера интеграции. Базовый uptime-мониторинг с проверкой раз в одну-пять минут и алертом в мессенджер или на почту при недоступности. Настройка такого мониторинга на бесплатном self-hosted инструменте разобрана здесь: Uptime Kuma: мониторинг сайта и сервера.
• Размер и возраст очереди неотправленных документов. Метрика специфична для вашей интеграции, но принцип общий: собирайте её (счётчик + таймстамп самого старого элемента) и выводите на дашборд с порогом алерта.
• Ресурсы сервера — CPU, память, свободное место на диске, — со стандартными порогами (например, алерт при свободном месте меньше 15–20%, задолго до того, как диск заполнится полностью).
• Сетевая связность от сервера интеграции до внешнего мира и от точек продаж до сервера интеграции — можно синтетическими проверками (ping, TCP-check на нужный порт) с интервалом в одну-две минуты.
• Сертификаты и сроки их действия, если взаимодействие идёт с использованием TLS-сертификатов — истечение сертификата посреди рабочего дня останавливает передачу так же надёжно, как обрыв интернета.
• Синхронизация времени — простая проверка расхождения системных часов с NTP-сервером, желательно с алертом при отклонении больше нескольких секунд.

Отдельно стоит проговорить честный нюанс: мониторинг сам по себе не чинит проблему, он только сокращает время до того, как о ней узнает человек, способный её решить. Если алерты приходят, но их никто не читает (уходят в общий канал, который никто не открывает, например), толку от такого мониторинга немного.

Резервирование и план действий при сбое

Мониторинг говорит о проблеме, но должен быть заранее продуманный порядок действий, а не импровизация в момент, когда касса уже встала.

Разумный минимум для точки продаж и для сервера интеграции:

• Понятный owner инцидента. Кто получает алерт и что делает в первую очередь — проверяет связь точки, перезапускает сервис на сервере интеграции, звонит в техподдержку провайдера или оператора ОФД. Без этого распределения алерт может просто «повиснуть», пока кто-то не заметит его случайно.
• Резервный интернет-канал в точке продаж (см. выше) — снижает вероятность самой частой причины сбоя ещё до того, как она произойдёт.
• Резервный узел для сервера интеграции, если у вас много точек продаж и простой центрального сервера критичен для всех сразу, а не для одной точки.
• Регламент по срокам ФН. Внутренний документ или хотя бы понимание у ответственного за кассы: сколько времени касса может копить неотправленные документы до блокировки, и что делать, если этот срок приближается, а связь не восстанавливается.
• Резервная копия конфигурации сервера интеграции — если сервер физически выходит из строя, поднятие нового узла с нуля не должно занимать часы на восстановление настроек взаимодействия с ОФД.

Важная честная оговорка: ни резервный канал, ни резервный сервер не устраняют саму зависимость от исправной работы оператора фискальных данных — если проблема на стороне ОФД, ваша инфраструктура может быть идеальной и всё равно ждать восстановления не у вас. Задача инфраструктурной части — исключить из списка причин простоя всё, что реально в вашей зоне ответственности, и сократить время реакции на то, что не в ней.

Частые вопросы