При обновлении драйверов торгового оборудования или переходе на новые версии обработки обслуживания касс АТОЛ (особенно при работе с драйвером версии 10.х) программисты 1С часто сталкиваются с диагностическим сообщением "Тип чека не поддерживается". Эта ошибка блокирует фискализацию чека, хотя визуально XML-пакет кажется корректным, а связь с кассой установлена. В этой статье мы детально разберем, почему возникает эта ситуация, проанализируем структуру XML-пакета и найдем способы решения проблемы для различных конфигураций 1С.
Рассмотрим типичный пример формирования XML-пакета, который передается в драйвер АТОЛ 10 через обработку обслуживания. Проанализируем структуру, представленную в одном из рабочих кейсов:
<?xml version="1.0" encoding="UTF-8"?>
<CheckPackage>
<Parameters PaymentType="3" TaxVariant="0" CashierName="Кассир" CustomerEmail="" CustomerPhone="" CustomerInfo="ИП Мамедов" CustomerINN="650100428574">
<AgentData/>
<PurveyorData/>
</Parameters>
<Positions>
<FiscalString Name="Охотничьи колбаски" Quantity="0.001" PriceWithDiscount="120" SumWithDiscount="0.12" DiscountSum="" Department="0" Tax="10" SignCalculationObject="1" SignMethodCalculation="6" TaxSum="0.01"/>
</Positions>
<Payments Cash="0" ElectronicPayment="0" Credit="0.12" AdvancePayment="0" CashProvision="0"/>
</CheckPackage>
В данном примере мы видим классическую структуру для ФФД 1.05. Однако при попытке пробить такой чек драйвер возвращает ошибку. Выясним причину: она кроется в механизме взаимодействия между 1С и драйвером, который определяется так называемой ревизией интерфейса (Interface Revision).
Драйверы АТОЛ 10-й серии поддерживают несколько стандартов взаимодействия с внешним ПО. В мире 1С эти стандарты делятся на две основные группы:
Проанализируем ситуацию: если ваша обработка обслуживания сообщает драйверу, что она работает по стандарту 3000, но при этом передает XML старого образца (как в примере выше), драйвер не находит обязательный атрибут OperationType и выдает ошибку "Тип чека не поддерживается".
Если вы используете "самописную" или сильно измененную старую конфигурацию (например, УТ 10.3), самым быстрым и эффективным решением будет принудительная установка ревизии интерфейса. Рассмотрим, как это реализовать в коде.
Найдите место в коде, где происходит инициализация параметров подключения или вызов метода фискализации. Вам необходимо убедиться, что переменная, отвечающая за ревизию, имеет значение ниже 3000 (например, 2000 или 2005). Посмотрим на пример изменения логики:
// В обработке обслуживания при открытии или фискализации
РевизияИнтерфейса = 2000;
// Вместо получения значения 3000 из новых версий обработки
Как показывает практика, после принудительной установки ревизии в значение 2000, драйвер начинает корректно интерпретировать XML-пакет старого образца, и чек успешно пробивается.
Если вы все же решили использовать современную ревизию 3000 (что рекомендуется для полной поддержки требований ФФД), вам необходимо привести структуру XML в соответствие с новыми требованиями. Проанализируем, чего не хватает в стандартном пакете.
В ревизии 3000 за тип чека отвечает атрибут OperationType в узле Parameters. Значения могут быть следующими:
Если этот тег отсутствует или заполнен некорректно, драйвер не понимает, какую операцию совершить с фискальным накопителем. Рассмотрим исправленный фрагмент заголовка XML:
<Parameters OperationType="1" PaymentType="1" TaxVariant="0" CashierName="Кассир" ... >
Часто возникает ситуация, когда в системе установлен основной драйвер ККТ АТОЛ одной версии (например, 10.5.1.3), а в 1С загружена обработка или внешняя компонента (fptr10.dll) другой версии (например, 10.5.0.0). Выясним, почему это критично:
Разные сборки драйверов могут по-разному обрабатывать пустые значения атрибутов. Например, в одном случае DiscountSum="" может быть допустимым, а в другом — приводить к логической ошибке разбора пакета.
Рекомендация: Всегда используйте файл fptr10.dll именно из того дистрибутива драйвера, который установлен на рабочем месте кассира. Путь к актуальному файлу обычно: C:\Program Files (x86)\ATOL\Drivers10\KKT\bin\.
Разберем еще несколько тонких моментов, которые могут провоцировать данную ошибку:
PaymentType="3". В драйверах 10-й версии это значение сопоставляется с таблицами самого кассового аппарата. Если в настройках ККТ (через "Тест драйвера") тип оплаты №3 не задан или отключен, драйвер может вернуть ошибку типа чека.SumWithDiscount строго соответствовала сумме в блоке Payments. В нашем примере 0.12 = 0.12 в секции Credit. Если будет расхождение даже в 1 копейку из-за округления, драйвер может выдать общую ошибку поддержки типа чека.TaxVariant="0" соответствует системе налогообложения, настроенной в кассе. Для ОСНО это обычно 0, для УСН доход — 1 и так далее. Если вы отправляете налог 10% (Tax="10"), но при этом указываете СНО, которая не предполагает НДС, возникнет конфликт.Чтобы оперативно решить проблему "Тип чека не поддерживается", рекомендуем придерживаться следующего алгоритма:
РевизияИнтерфейса = 2000 в коде интеграции.OperationType.fptr10.dll в справочнике "Драйверы оборудования" 1С с версией установленного в Windows драйвера АТОЛ.Таким образом, мы выяснили, что ошибка чаще всего является следствием "трудностей перевода" между старыми алгоритмами формирования XML в 1С и новыми требованиями драйверов АТОЛ 10.х. Корректная настройка ревизии интерфейса решает проблему в большинстве случаев.