При работе с торговым оборудованием в среде 1С разработчики и системные администраторы нередко сталкиваются с ситуацией, когда после планового обновления прошивки контрольно-кассовой техники (ККТ) или перерегистрации кассы на новый формат фискальных данных (например, переход с ФФД 1.0 на ФФД 1.05) привычные чеки начинают печататься некорректно. Одной из наиболее распространенных проблем является сбой при оформлении безналичных расчетов: на бумажной ленте вместо ожидаемой надписи «ЭЛЕКТРОННО» или «БЕЗНАЛИЧНЫМИ» касса внезапно выводит «ПОСЛЕДУЮЩАЯ ОПЛАТА (КРЕДИТ)». При этом оплата наличными продолжает проходить в штатном режиме.
В данной статье мы подробно разберем, почему возникает эта ошибка, проанализируем техническую суть происходящего сдвига типов оплат и рассмотрим несколько способов устранения проблемы — от простого обновления программного обеспечения до ручной корректировки таблиц сопоставления.
Давайте рассмотрим типичный пример из практики. В самописной конфигурации 1С, построенной на базе Библиотеки стандартных подсистем (БСП) и Библиотеки подключаемого оборудования (БПО), код для формирования таблицы оплат выглядит следующим образом:
СтрокаОплаты = МенеджерОборудованияКлиентСервер.ПараметрыСтрокиОплаты();
СтрокаОплаты.ТипОплаты = ?(ДанныеДокумента.ФормаОплаты = Перечисления.ФормыОплаты.Наличная,
Перечисления.ТипыОплатыККТ.Наличные,
Перечисления.ТипыОплатыККТ.Электронно);
СтрокаОплаты.Сумма = ДанныеДокумента.Сумма;
ОбщиеПараметры.ТаблицаОплат.Добавить(СтрокаОплаты);
При тестировании на встроенном эмуляторе чеков 1С все работает идеально. Наличные и безналичные платежи распределяются верно. Однако при отправке этой же структуры на реальный фискальный регистратор АТОЛ FPrint-22птк (с обновленной под ФФД 1.05 прошивкой) электронный платеж превращается в кредит. Если мы заглянем в отладчик и проанализируем XML-пакет, который отправляется на драйвер кассы, мы увидим вполне корректную структуру:
<?xml version="1.0" encoding="UTF-8"?>
<CheckPackage>
<Parameters PaymentType="1" TaxVariant="2" CashierName="Кассир А.Ю." CustomerEmail="" CustomerPhone="">
<AgentData/>
<PurveyorData/>
</Parameters>
<Positions>
<FiscalString Name="Воск ортодонтический" Quantity="1" PriceWithDiscount="162" SumWithDiscount="162" DiscountSum="" Department="0" Tax="none" SignMethodCalculation="4" TaxSum="0">
<AgentData/>
<PurveyorData/>
</FiscalString>
</Positions>
<Payments Cash="0" ElectronicPayment="162" Credit="0" AdvancePayment="0" CashProvision="0"/>
</CheckPackage>
Обратите внимание на строку Payments Cash="0" ElectronicPayment="162". Платформа 1С честно передает сумму по каналу электронного платежа. Но на выходе из печатающего устройства мы получаем неверный тип оплаты. Выясним причину этой аппаратной путаницы.
Сбой напрямую связан с изменением правил классификации платежей при переходе на новые фискальные стандарты и обновлением прошивки кассового аппарата.
В старом формате (ФФД 1.0) понятия типов оплат не имели жесткой фискальной привязки на уровне драйвера. В кассах использовалась настраиваемая внутренняя таблица оплат. Безналичные платежи часто программировались ЦТО или администраторами под произвольными индексами (например, под номером 2, 3 или 4), в зависимости от специфики настройки кассы.
С введением ФФД 1.05 типы оплат стали строго фискальными и привязались к конкретным тегам ФФД на уровне законодательства:
При обновлении прошивки кассы АТОЛ под требования ФФД 1.05 внутренняя таблица типов оплат ККТ автоматически перестроилась под эту жесткую структуру. Но если учетная система использует старый драйвер торгового оборудования (например, АТОЛ ДТО 8-й или ранних версий 9-й ветки), то этот драйвер продолжает отправлять безналичный платеж по устаревшим правилам сопоставления. Драйвер считает, что безналичная оплата должна идти под индексом 2 или 3. Новая прошивка кассы, приняв этот индекс от старого драйвера, честно сопоставляет его со своим новым встроенным реестром и выводит на печать «ПОСЛЕДУЮЩАЯ ОПЛАТА (КРЕДИТ)».
Рассмотрим подробнее по шагам, какими способами мы можем решить эту проблему.
Самый надежный и правильный путь — приведение программного обеспечения в актуальное состояние. Производитель АТОЛ полностью прекратил поддержку 8-й и 9-й веток драйверов. Все современные прошивки ККТ разрабатываются с расчетом на использование ДТО 10 (Драйвер торгового оборудования версии 10.х).
Выполним следующие действия:
Современный драйвер 10-й версии берет на себя всю абстракцию взаимодействия: он корректно принимает от 1С логический тип оплаты ElectronicPayment и самостоятельно транслирует его в кассу по правильному фискальному тегу 1081 (Безналичными), исключая любые «съезды» индексов.
Если быстро обновить БПО или конфигурацию 1С не представляется возможным (например, база сильно кастомизирована и находится на поддержке сторонних разработчиков), можно попытаться исправить ситуацию в режиме «1С:Предприятие»:
Иногда требуется проверить, какие именно наименования типов оплат зашиты в саму кассу. Для этого воспользуемся сервисной утилитой от производителя:
Если вы ограничены рамками старых версий программного обеспечения и вынуждены использовать устаревший драйвер, проблему можно решить путем переопределения XML-пакета непосредственно перед отправкой на устройство. Разберем этот пример по шагам.
Найдем в конфигурации модуль, отвечающий за формирование XML для ККТ (обычно это функции вида ПолучитьXMLПакетДляФискализацииЧека). Нам необходимо перенаправить сумму безналичного расчета на верный индекс, который старый драйвер сможет сопоставить правильно.
Ниже представлен пример того, как можно программно вмешаться в процесс формирования XML-пакета:
// Пример модификации XML-пакета для подмены типов оплат
Функция СкорректироватьПакетОплат(ЗначениеXML) Экспорт
// Если касса ожидает безналичные платежи под другим тегом/индексом
// Мы можем принудительно заменить атрибут ElectronicPayment на нужный индекс
// или переформировать структуру Payments в зависимости от требований старого драйвера
Чтение = Новый ЧтениеXML;
Чтение.УстановитьСтроку(ЗначениеXML);
// Производим разбор XML и заменяем индексы оплат,
// если зафиксировано расхождение на старых версиях ДТО.
// ... (код парсинга и модификации узла <Payments/>) ...
Возврат МодифицированныйXML;
КонецФункции
Тем не менее, помните, что программные «костыли» в коде интеграции — это лишь временная мера. Настоятельно рекомендуем переводить кассовые узлы на ДТО 10, так как требования фискального законодательства регулярно меняются, и только актуальные версии драйверов гарантируют корректную работу оборудования без постоянного вмешательства в программный код.