При переводе интернет-магазина на расчеты в соответствии с требованиями 54-ФЗ перед разработчиками встает задача автоматической фискализации безналичных оплат. Стандартная схема предполагает передачу данных об оплате из CMS сайта в учетную систему 1С, после чего чек должен быть отправлен на контрольно-кассовую технику (ККТ) и передан оператору фискальных данных (ОФД). Разберем, как правильно выстроить такую архитектуру, с какими аппаратными и платформенными ограничениями можно столкнуться и как избежать типичных ошибок при интеграции оборудования.
Архитектурные ограничения прямой печати из веб-сервиса
На первый взгляд самая очевидная схема кажется простой: веб-сервис 1С принимает запрос от интернет-магазина, тут же обращается к драйверу ККТ, пробивает чек и возвращает сайту статус успешной фискализации. Однако на практике такая линейная реализация быстро приводит к сбоям. Выясним причину:
Монопольный доступ к кассе: Физический фискальный регистратор подключен через порт (COM, USB или TCP/IP) и управляется драйвером, который в один момент времени способен выполнять только одну команду. Если на сайт одновременно поступает несколько заказов, параллельные вызовы веб-сервиса 1С попытаются одновременно захватить порт кассы, что приведет к ошибкам блокировки устройства («Порт занят» или «Устройство недоступно»).
Контекст исполнения кода 1С: Методы веб-сервисов и HTTP-сервисов выполняются исключительно в серверном контексте кластера 1С. Традиционные механизмы Библиотеки подключаемого оборудования (БПО) исторически ориентированы на работу в контексте клиента, так как стандартные COM-объекты драйверов касс часто не могут быть инициализированы в 64-битной серверной службе без специальных внешних компонент Native API.
Таймауты веб-запросов: Пробитие чека на ККТ — операция ввода-вывода, которая может занять от 2 до 10 секунд (опрос состояния, формирование фискального пакета, ответ фискального накопителя). Если драйвер зависнет или потеряет связь, веб-сервис превысит таймаут ответа, а интернет-магазин посчитает транзакцию аварийной.
Организация очереди фискализации через асинхронную схему
Для надежной работы системы разделим прием оплат и взаимодействие с кассой на два независимых контура. Рассмотрим архитектуру решения по шагам:
Прием запроса: Интернет-магазин отправляет структурированные данные по протоколу HTTP (REST API или SOAP) в сервис 1С.
Регистрация документа: Сервис выполняет валидацию данных, создает в базе документ оплаты (например, «Эквайринговая операция» или специализированный документ фискализации) со статусом «К пробитию» и сразу возвращает сайту ответ 200 OK с идентификатором зарегистрированного документа.
Обработка очереди: Отдельный фоновый поток (регламентное задание на сервере либо выделенный сеанс с обработчиком ожидания) последовательно выбирает документы из очереди и отправляет их на кассу по одному.
Посмотрим на пример логики регламентного опроса очереди с помощью обработчика ожидания на выделенном клиенте или в сервисном сеансе:
Процедура ПодключитьОбработчикОчередиЧеков() Экспорт
ПодключитьОбработчикОжидания("ОбработатьОчередьФискализации", 30);
КонецПроцедуры
Процедура ОбработатьОчередьФискализации() Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| Очередь.Ссылка КАК ДокументОплаты
|ИЗ
| Документ.ОплатаПоПлатежнойКарте КАК Очередь
|ГДЕ
| Очередь.СтатусЧека = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККТ.КПробитию)
|УПОРЯДОЧИТЬ ПО
| Очередь.МоментВремени ВОЗР";
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
// Вызываем процедуру фискализации в изолированном блоке
Попытка
ПробитьЧекНаККТ(Выборка.ДокументОплаты);
Исключение
ЗафиксироватьОшибкуФискализации(Выборка.ДокументОплаты, ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Особенности работы с драйверами торгового оборудования на сервере
Если требуется избавиться от постоянно запущенного клиентского сеанса и выполнять фискализацию непосредственно на сервере 1С, проанализируем доступные варианты реализации:
Использование внешних компонент Native API: Современные версии БПО поддерживают серверную фискализацию при условии, что драйвер производителя кассы (например, АТОЛ или Штрих-М) скомпилирован как кроссплатформенная компонента Native API и совпадает по разрядности с сервером 1С (x86 или x64).
Взаимодействие через локальный HTTP-сервис драйвера: Современные поколения драйверов ККТ содержат собственный встроенный веб-сервер. В этом случае 1С не загружает бинарные библиотеки в свое адресное пространство, а отправляет JSON-пакеты напрямую на порт службы драйвера через стандартный объект HTTPСоединение. Это полностью снимает проблемы с разрядностью и совместимостью операционных систем.
Типичные технические проблемы и ошибки интеграции
В процессе пусконаладки взаимодействия между 1С и реальным кассовым аппаратом часто возникают скрытые ошибки, которые не проявляются на программных эмуляторах касс:
Несоответствие типов данных реквизитов чека: В отличие от эмулятора ККТ, реальный фискальный регистратор строго проверяет типы переданных полей. Распространенная ошибка — передача реквизита «Кассир» в виде ссылки на справочник Справочники.Пользователи или Справочники.ФизическиеЛица. Драйвер ожидает исключительно строковое значение (ФИО ответственного лица) и его ИНН. Передача ссылки вызывает аварийное завершение формирования фискального чека.
Печать в безбумажном режиме: При онлайн-расчетах через интернет-магазин физическая печать чековой ленты не требуется. Более того, печать бумажного чека на каждый онлайн-заказ быстро приведет к замятию бумаги или ее окончанию, что заблокирует работу кассы. В настройках оборудования необходимо включить флаг электронного чека. При этом реквизит контактных данных покупателя (номер телефона или адрес электронной почты) становится обязательным для передачи в ОФД.
Блокировка кассовой смены более 24 часов: Фискальный накопитель аппаратно блокирует пробитие любых документов, если с момента открытия смены прошло более 24 часов. Для касс, работающих в автоматическом режиме круглосуточно, необходимо настроить регламентное задание на закрытие смены (снятие Z-отчета) и открытие новой смены по расписанию (например, раз в сутки ночью).
Альтернативные варианты архитектуры: облачные фермы касс
Если поддержка собственного физического сервера и локальной кассы несет слишком высокие операционные риски (отключение электропитания, обрыв интернет-соединения, обслуживание фискальных накопителей), рассмотрим использование облачных кассовых сервисов. Специализированные сервисы предоставляют кассы в аренду в дата-центрах. В такой схеме интернет-магазин может отправлять данные напрямую в API сервиса фискализации либо продолжать использовать 1С как единый центр формирования очереди, отправляя готовые чеки в облако по REST API без подключения физического оборудования к базе данных.