При работе с торговым оборудованием марки Дримкас (Вики Принт 57, Вики Принт 80 и др.) в устаревших или кастомизированных конфигурациях «1С:Предприятие» пользователи часто сталкиваются с неприятной ситуацией. При проведении оплаты через эквайринг (документ «Операция по платежной карте») фискальный регистратор печатает на чеке и отправляет в ОФД информацию о том, что операция совершена в кредит (последующая оплата), хотя деньги фактически списались с карты покупателя. При этом в кассовой книге и в документах приходного кассового ордера (ПКО) всё отражается корректно.
В этой статье мы подробно разберем технические причины этого сбоя, выясним, как требования ФФД влияют на логику драйверов, и предоставим пошаговый алгоритм устранения проблемы в конфигурации «1С:Управление торговлей 10.3» и аналогичных решениях на обычных формах.
Для начала проанализируем ситуацию с точки зрения форматов фискальных данных (ФФД 1.05 и 1.2). Кассовый чек содержит два ключевых тега, которые передаются из 1С в кассовое ядро драйвера:
Если со стороны 1С в драйвер передается пустое (незаполненное) значение способа расчета, кассовое ПО Дримкас применяет собственный алгоритм автоматического определения. В устаревших версиях драйверов пустые значения или некорректная структура XML-пакета интерпретируются кассой по умолчанию как «Передача в кредит» или «Оплата кредита». Чтобы решить эту проблему, нам потребуется обновить драйверное обеспечение и устранить программную очистку реквизитов внутри 1С.
Часто в конфигурациях «1С:Управление торговлей 10.3» подключение торгового оборудования выполняется через внешние обработки обслуживания (с расширением .epf). Обновление самого драйвера в операционной системе не дает результата, так как 1С использует собственную DLL-библиотеку, зашитую в макет этой обработки. Нам необходимо заменить старую компоненту на актуальную native-библиотеку Дримкас.
Рассмотрим процедуру замены интеграционной компоненты по шагам:
Dreamkas_KКТ.epf или DreamkasKKT_comm.epf).Dreamkas_KKT.dll актуальной версии (например, версии 1.2.1.3 или выше), скачанной с официального портала Дримкас. Обратите внимание, что библиотека является Native-компонентой, ее не нужно регистрировать в системе через regsvr32.Ctrl + S).Замена файла внутри макета гарантирует, что при инициализации подключения ККТ программа 1С автоматически выгрузит во временный каталог операционной системы и зарегистрирует правильную версию драйвера.
Даже с самой новой компонентой касса продолжит печатать «кредит», если сама учетная система отправляет пустые параметры. Выясним причину, почему признак способа расчета может затираться или передаваться неверно.
В конфигурациях 1С на обычных формах (УТ 10.3) логика заполнения параметров чека завязана на структуру подчиненности документов. Если документ «Операция по платежной карте» введен на основании «Заказа покупателя» или «Реализации товаров и услуг», система пытается автоматически рассчитать признак способа расчета. Если связи между документами нарушены или в код были внесены некорректные доработки, значение реквизита очищается.
Проанализируем программный код формирования XML для фискализации чека. Нам необходимо найти модуль, отвечающий за отправку данных на ККТ (обычно это общий модуль МенеджерОборудованияКлиент или модуль самой внешней обработки обслуживания) и проверить логику передачи тега способа расчета. Код инициализации параметров должен выглядеть следующим образом:
// Проверим заполнение признака способа расчета перед отправкой в ККТ
Если Не ЗначениеЗаполнено(ОбъектДрайвера.ПризнакСпособаРасчета) Тогда
// Если параметр не определен, принудительно устанавливаем "Полный расчет"
ОбъектДрайвера.ПризнакСпособаРасчета = Перечисления.ПризнакиСпособаРасчета.ПолныйРасчет;
КонецЕсли;
// Убедимся, что тип оплаты передается как электронный (безналичный)
Если ТипДокументаОплаты = "ОплатаКартой" Тогда
ТипОплатыККТ = 1; // Код 1 соответствует безналичному расчету в таблице ККТ Дримкас
КонецЕсли;
Если в вашей конфигурации выполнялись доработки, обязательно найдите место, где реквизиты очищаются принудительно. Очень часто разработчики очищают признак способа расчета, ошибочно полагая, что касса сама подставит «Полный расчет» по умолчанию. В случае с ККТ «Вики Принт» это гарантированно приводит к выводу чека с признаком «Кредит».
Если ручные манипуляции с кодом внешней обработки кажутся вам слишком сложными, рассмотрите возможность обновления конфигурации. Начиная с релизов серии 10.3.49.x, фирма 1С полностью перевела механизмы интеграции с торговым оборудованием на использование БПО (Библиотеки подключаемого оборудования).
Использование БПО дает важные преимущества:
.epf.Для стабильной работы рекомендуется обновить конфигурацию «1С:Управление торговлей» как минимум до релиза 10.3.49.4 или выше.
Иногда корни проблемы лежат в настройках самого фискального регистратора. После аварийного обновления прошивки ККТ или сбоев в ОЗУ таблицы типов оплат в кассе могут смещаться. В результате, когда 1С отправляет команду «Оплатить типом 1» (подразумевая безналичные), ККТ считывает из своей внутренней таблицы под индексом 1 значение «Кредит».
Выясним, как проверить настройки ККТ напрямую через сервисную утилиту Дримкас:
Выполнение этих шагов гарантирует полное восстановление корректного обмена данными между «1С:Предприятием» и ККТ «Вики Принт», исключая появление нежелательных чеков с признаками кредита при оплате банковскими картами.