Как интегрировать онлайн-кассу в самописную конфигурацию 1С?

Программист 1С v8.3 (Управляемые формы) Управленческий учет IT и автоматизация бизнеса
← На главную

При автоматизации торговых процессов в нетиповых и самописных решениях на платформе 1С неизбежно возникает задача фискализации расчетов в соответствии с требованиями 54-ФЗ. Оценим сложность задачи, разберем возможные варианты реализации, а также выясним, какие изменения потребуется внести в учетную структуру конфигурации.

Оценка трудоемкости и предварительный анализ конфигурации

Сложность и сроки подключения кассового оборудования к самописке напрямую зависят от текущего состояния прикладного решения. Проанализируем ключевые факторы:

  1. Наличие базовых учетных сущностей: если в базе уже есть документы розничных продаж (например, аналоги документов ЧекККМ, ОтчетОРозничныхПродажах или ПриходныйКассовыйОрдер), интеграция займет значительно меньше времени. Если же учет продаж и кассовых смен отсутствует, придется с нуля проектировать кассовые документы, учет чеков, открытие и закрытие смены.
  2. Используемая версия формата фискальных данных (ФФД): интеграция с поддержкой актуальных форматов (ФФД 1.05 и ФФД 1.2) требует передачи расширенного набора обязательных тегов, включая признаки способа и предмета расчета, данные кассира (ИНН и должность), а при работе с маркированной продукцией — кодов маркировки и результатов их проверки.
  3. Архитектура клиентских мест: важно учитывать, где запускается сеанс пользователя (толстый клиент, тонкий клиент, Web-клиент или терминальный сервер RDP), а также разрядность платформы (32-bit или 64-bit).

Вариант 1. Внедрение Библиотеки подключаемого оборудования (БПО)

Рассмотрим стандартный и наиболее масштабируемый подход — перенос в самописную систему подсистем из типовой «1С:Библиотеки подключаемого оборудования».

Преимущества подхода:

  1. Универсальность: БПО содержит стандартизированный API для взаимодействия с большинством моделей фискальных регистраторов (Атол, Штрих-М и др.), эквайринговых терминалов и сканеров штрихкодов.
  2. Готовые механизмы формирования чека: библиотека берет на себя генерацию XML-пакетов фискализации с учетом требований актуальных версий ФФД, управление кассовыми сменами (открытие, закрытие, X-отчет) и обработку ошибок драйверов.
  3. Простота поддержки: при изменении законодательства или формата обмена достаточно обновить подсистему БПО до актуальной версии без ручной переработки низкоуровневого кода.

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

Вариант 2. Прямое подключение через внешнюю компоненту или драйвер производителя

Разберем вариант, когда внедрение полной библиотеки БПО является избыточным, и требуется реализовать точечное пробитие чеков через Native API или COM-интерфейс драйвера ККТ.

Особенности подхода:

  1. Минимум изменений в метаданных: нет необходимости внедрять десятки объектов БПО, достаточно подключить внешнюю компоненту или обработку обслуживания.
  2. Ручное формирование структуры чека: программисту необходимо самостоятельно программно передавать все реквизиты (теги ФФД), рассчитывать суммы скидок, налоги (НДС), передавать данные кассира и обрабатывать типы оплат (наличные, безналичные, авансы).
  3. Зависимость от производителя: при смене марки оборудования (например, переход со «Штрих-М» на «Атол») код взаимодействия придется переписывать или адаптировать под API нового драйвера.

Посмотрим на общую схему вызова внешней компоненты на клиенте:


// Подключение внешней компоненты драйвера ККТ
ИмяКомпоненты = "AddIn.Fptr10";
Подключено = ПодключитьВнешнююКомпоненту(ИмяКомпоненты);

Если Подключено Тогда
    ДрайверККТ = Новый(ИмяКомпоненты);
    // Установка параметров соединения и открытие чека
    ДрайверККТ.setParam(ДрайверККТ.LIBFPTR_PARAM_PORT, ДрайверККТ.LIBFPTR_PORT_USB);
    ДрайверККТ.open();
Иначе
    ВызватьИсключение "Не удалось загрузить внешнюю компоненту ККТ!";
КонецЕсли;

Вариант 3. Использование локального веб-сервиса или службы печати

Если самописная конфигурация работает в режиме веб-клиента, на Linux-клиентах или в терминальной ферме (RDP), прямое подключение COM-компонент к локальным портам часто вызывает сложности. В таких случаях рассмотрим архитектуру через промежуточный HTTP/REST-сервис.

  1. На локальном компьютере, к которому физически подключена ККТ, запускается служба печати или локальный веб-сервер драйвера.
  2. Из 1С отправляется HTTP-запрос (через объект HTTPСоединение и HTTPЗапрос) с телом чека в формате JSON.
  3. Служба выполняет печать и возвращает в 1С фискальные параметры документа: номер чека, номер смены, фискальный признак документа (ФПД) и номер ФД.

Необходимые реквизиты для хранения фискальных данных

При проектировании документов продажи в самописной базе важно предусмотреть реквизиты для сохранения результатов фискализации. Добавим в документ или специальный регистр сведений следующие поля:

  1. СтатусЧека (перечисление или булево: НеПробит, Пробит, Ошибка);
  2. НомерФискальногоДокумента (число / строка);
  3. ФискальныйПризнак (строка);
  4. НомерКассовойСмены (число);
  5. НомерЧекаЗаСмену (число);
  6. ДатаВремяФискализации (дата).

Итог: для простой базы с готовым документом продажи подключение через готовый драйвер или базовую обработку занимает от 1 до 3 рабочих дней. Если база полностью самописная без кассового контура, либо планируется масштабирование парка оборудования и поддержка ФФД 1.2 с маркировкой, оптимальным решением является интеграция типовой подсистемы БПО, что займет в среднем от 1 до 2 недель разработки.

← На главную