Как подключить фискальный регистратор к самописной конфигурации 1С

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

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

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

Первый и наиболее рекомендуемый путь — использование типового решения от фирмы «1С». Библиотека подключаемого оборудования (БПО) предоставляет универсальный интерфейс для работы с огромным списком моделей ККТ. Рассмотрим подробнее процесс интеграции:

Для начала проанализируем структуру БПО. Вам не обязательно переносить всю библиотеку целиком. В самописную конфигурацию достаточно внедрить так называемое «ядро» и необходимые обработки обслуживания. Основное преимущество здесь заключается в том, что при выходе новых моделей оборудования или изменении законов (например, правил печати чеков с маркировкой), вам достаточно будет обновить только компоненты БПО, не переписывая логику формирования чека.

Процесс внедрения обычно включает следующие шаги:

  1. Интеграция общих модулей, отвечающих за работу с торговым оборудованием.
  2. Добавление справочников ПодключаемоеОборудование и ДрайверыОборудования.
  3. Настройка вызова внешних компонент через стандартизированное API.

Недостатком этого метода является высокая сложность «первого входа» и зависимость от наличия подписки ИТС у заказчика для легального получения обновлений библиотеки.

Вариант 2: Прямое взаимодействие с драйвером производителя (АТОЛ, Штрих-М)

Если конфигурация максимально простая и вы не хотите перегружать ее тяжелыми типовыми механизмами, разберем вариант прямого обращения к драйверу. Современные драйверы, такие как АТОЛ 10 (DTO 10), предлагают удобные интерфейсы для разработчиков.

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

Рассмотрим пример формирования JSON-задания для печати чека:


// Пример упрощенной структуры JSON для драйвера АТОЛ 10
Задание = "{
|  ""type"": ""sell"",
|  ""items"": [
|    {
|      ""type"": ""position"",
|      ""name"": ""Товар тестовый"",
|      ""price"": 100,
|      ""quantity"": 1,
|      ""amount"": 100,
|      ""tax"": { ""type"": ""none"" }
|    }
|  ],
|  ""payments"": [
|    { ""type"": ""cash"", ""sum"": 100 }
|  ]
|}";

// Передача задания в драйвер (объект драйвера должен быть предварительно создан)
Драйвер.setParam(Драйвер.LIBFPTR_PARAM_JSON_DATA, Задание);
Драйвер.processJson();

Для реализации этого метода необходимо выполнить загрузку внешней компоненты. Выясним, как это сделать правильно, используя технологию Native API, которая работает стабильнее устаревшего COM:


&НаКлиенте
Процедура ПодключитьДрайвер()
    Результат = УстановитьВнешнююКомпоненту("ОбщийМакет.ДрайверАтол10");
    Если Результат Тогда
        ОбъектДрайвера = Новый("AddIn.Atol_KKT_10");
        // Далее следует установка параметров связи (порт, скорость)
    КонецЕсли;
КонецПроцедуры

Вариант 3: Использование промежуточных утилит и текстовых файлов

Существует еще один метод, который часто называют «быстрым стартом». Он заключается в использовании сторонних утилит-прослоек, которые умеют считывать данные из текстовых файлов определенного формата и отправлять их на печать. Проанализируем этот подход.

В этом случае ваша 1С-система просто выгружает файл (например, check.txt или cmd.xml) в определенную папку. Специальная служба «монитор» подхватывает этот файл и выполняет команды на фискальном регистраторе. Это позволяет избежать прямой регистрации DLL в системе и решает проблемы с разрядностью (32/64 бит), однако такой способ менее надежен в плане получения обратной связи (например, если закончилась бумага, 1С может об этом не узнать сразу).

Критически важные аспекты при разработке

Независимо от выбранного пути, разберем ключевые технические моменты, которые нельзя игнорировать:

  1. Работа с маркировкой (Честный ЗНАК): Если ваша конфигурация предполагает продажу товаров с кодами маркировки, использование БПО становится практически обязательным. Согласно ФФД 1.2, ККТ должна выполнять предварительную проверку кода маркировки через ОФД. Реализовать эту последовательность команд вручную крайне трудозатратно и чревато штрафами для клиента.
  2. Контекст выполнения кода: Помните, что оборудование физически подключено к клиентскому компьютеру. Следовательно, весь код, взаимодействующий с драйвером, должен исполняться &НаКлиенте. Если данные для чека подготавливаются НаСервере, их необходимо передать на клиент в виде структуры или массива.
  3. Налоги и СНО: При формировании чека важно правильно передавать код системы налогообложения и ставки НДС. Ошибка в этих данных в фискальном чеке является нарушением налогового законодательства.
  4. Эмуляторы: На этапе разработки обязательно используйте программные эмуляторы ККТ (они есть в составе БПО). Это позволит вам отладить логику формирования чека, не расходуя фискальный накопитель и чековую ленту.

Подводя итог, можно сказать следующее: если вы планируете долгосрочную поддержку решения и работу с маркированным товаром — выбирайте БПО. Если задача разовая, оборудование однотипное и маркировки нет — использование JSON-интерфейса драйвера АТОЛ или аналогичных методов от Штрих-М будет более быстрым и экономным вариантом для «чистой» конфигурации.

← На главную