При автоматизации розничной торговли на базе решений «1С:Предприятие» разработчики часто сталкиваются с аппаратными нюансами фискальных регистраторов (ФР). Один из самых неприятных сюрпризов — ситуация, когда бумажный чек на кассе печатается идеально, но в ОФД или сторонние программы мониторинга продаж товары уходят без названий (с пустым полем наименования). Покупатель видит чек на бумаге, а в личном кабинете налоговой или оператора фискальных данных отображаются только суммы без расшифровки.
Сегодня мы детально проанализируем, почему возникает эта проблема при использовании интеграционной компоненты AddIn.DrvFR1C от компании «Штрих-М», выясним техническую первопричину сбоя и рассмотрим несколько проверенных практических способов её решения.
Любая контрольно-кассовая техника (ККТ) под управлением драйверов «Штрих-М» оперирует различными низкоуровневыми свойствами при регистрации товарной позиции. Когда в кодовой базе «1С» вызывается стандартный метод интеграционной компоненты НапечататьФискСтроку (PrintFiscalString), под капотом происходит сопоставление переданных параметров со свойствами физического драйвера.
В устаревших версиях интеграционной библиотеки 1С (физически находящейся в DLL-файле SMDrvFR1CLib24.dll или drvfr.dll в каталоге установки драйвера Штрих-М) была допущена системная нестыковка:
StringForPrinting (Строка для печати). Это свойство отвечает только за вывод физического текста на термоленту ККТ.Name (Наименование предмета расчета).Поскольку компонента AddIn.DrvFR1C оставляла свойство Name пустым, внешние программы мониторинга и ОФД получали чеки без наименований позиций. Так как исходный код DLL-компоненты закрыт, напрямую переписать метод НапечататьФискСтроку невозможно. Однако мы можем обойти это ограничение несколькими способами.
Если ваша конфигурация «1С» не привязана к жестким стандартам БСП (например, вы работаете в рамках СНГ или используете сильно кастомизированную самописную систему), наилучшим решением будет отказ от урезанной обертки AddIn.DrvFR1C в пользу работы напрямую с полноценным COM-объектом общего драйвера ККТ Штрих-М — AddIn.DrvFR.
При использовании прямого COM-соединения мы получаем полный контроль над заполнением всех реквизитов перед вызовом метода печати. Разберем по шагам пример кода для попозиционной регистрации продаж:
// Инициализируем прямое COM-подключение к драйверу Штрих-М
Попытка
ДрайверФР = Новый COMОбъект("AddIn.DrvFR");
Исключение
Сообщить("Ошибка: Драйвер Штрих-М не зарегистрирован в системе!");
Возврат;
КонецПопытки;
// Устанавливаем параметры связи (используются настройки по умолчанию)
ДрайверФР.Password = "30"; // Пароль системного администратора Штрих-М
ДрайверФР.Connect();
Если ДрайверФР.ResultCode <> 0 Тогда
Сообщить("Не удалось установить связь с ККТ: " + ДрайверФР.ResultCodeDescription);
Возврат;
КонецЕсли;
// Переходим к регистрации товарной позиции чека
ДрайверФР.Quantity = 1; // Количество товара
ДрайверФР.Price = 1250.50; // Цена за единицу товара
ДрайверФР.Department = 1; // Номер секции (отдела)
ДрайверФР.Tax1 = 0; // Код ставки НДС
// Заполняем текстовое поле для бумажной ленты
ДрайверФР.StringForPrinting = "Конструктор детский развивающий";
// КРИТИЧЕСКИ ВАЖНО: Принудительно заполняем структурированное имя для ОФД
ДрайверФР.Name = "Конструктор детский развивающий";
// Вызываем метод регистрации операции.
// Для современных касс с ФН вызывается метод FNOperation(), для старых - Sale()
ДрайверФР.FNOperation();
Если ДрайверФР.ResultCode <> 0 Тогда
Сообщить("Ошибка регистрации позиции: " + ДрайверФР.ResultCodeDescription);
КонецЕсли;
// Завершаем работу с драйвером
ДрайверФР.Disconnect();
Этот способ гарантирует, что товар получит свое наименование как на чековой ленте, так и в электронном документе ОФД.
Разработчики компании «Штрих-М» со временем признали эту проблему и доработали свои библиотеки интеграции. В новых релизах драйверов (начиная с линеек версии 4.14 и 4.15) логика работы внутренней компоненты 1С была скорректирована.
Теперь при вызове метода НапечататьФискСтроку интеграционная библиотека автоматически дублирует значение наименования товара в системное свойство Name. Чтобы решить проблему без изменения программного кода «1С», выполним следующие шаги:
SMDrvFR1CLib24.dll (или drvfr.dll) обновился в системных каталогах Windows (например, в папке C:\Program Files (x86)\Shtrih-M\) и в каталоге платформы «1С».Рассмотрим интересный недокументированный механизм, который присутствует в некоторых прошивках ККТ и промежуточных версиях драйверов Штрих-М. Если перед передачей названия товара в метод НапечататьФискСтроку подставить специальный префикс в виде двойного слэша //, драйвер воспринимает это как команду принудительного копирования строки в реквизиты ОФД.
Посмотрим на пример реализации данного подхода в коде «1С»:
// Формируем наименование со спецсимволами префикса
НаименованиеДляПередачи = "//" + СокрЛП(ВыборкаТоваров.Наименование);
// Вызываем стандартный метод компоненты 1С
Объект.Драйвер.НапечататьФискСтроку(
Объект.Драйвер.Пароль,
НаименованиеДляПередачи,
ВыборкаТоваров.Цена,
ВыборкаТоваров.Количество,
ВыборкаТоваров.Сумма,
ВыборкаТоваров.Отдел,
ВыборкаТоваров.НДС
);
При использовании этого лайфхака драйвер автоматически отсекает символы // при выводе на бумажную чековую ленту, но транслирует все символы после них напрямую в структурированное свойство Name для ОФД.
Если конфигурация вашей базы данных позволяет использовать новые стандарты интеграции торгового оборудования от фирмы «1С» (БСП версии 2.0 и выше), мы рекомендуем полностью отказаться от устаревших методов построчной печати.
Современный стандарт предусматривает передачу всей структуры чека единым XML-пакетом. При этом используются методы:
СформироватьЧек (для подготовки XML-структуры);ЗаписатьФискальныйДокумент (для отправки пакета на устройство).В XML-структуре чека наименования товарных позиций жестко регламентированы соответствующими XML-тегами. Драйверы ККТ корректно разбирают такой XML-пакет и гарантированно заполняют все обязательные свойства, включая фискальные признаки для ОФД.
Для решения сложных нетиповых задач или при работе на специфических операционных системах существует возможность отправлять сырые байты команд непосредственно в кассу, используя низкоуровневый метод драйвера TransferBytes. Этот метод позволяет полностью эмулировать протокол обмена ККТ Штрих-М в обход любых стандартных ограничений библиотек.
Однако создание собственного транслятора команд требует глубокого изучения протокола «Штрих-М» и ручного расчета контрольных сумм пакетов, поэтому к данному методу стоит прибегать только в самых крайних случаях.
Мы проанализировали причины сбоя при передаче названий номенклатуры в ОФД и рассмотрели основные пути решения проблемы. Выбор конкретного метода зависит от архитектуры вашей информационной системы:
AddIn.DrvFR (**Способ 1**).