При настройке торгового оборудования в 1С программисты и системные администраторы часто сталкиваются с требованиями бухгалтерии реализовать в чеках тип оплаты «Встречным представлением» (например, для операций Trade-in, обмена товаров или удержаний из зарплаты сотрудников). Возникает распространенное заблуждение, что для работы с этим типом оплаты необходимо обязательно обновлять кассовый аппарат (ККТ) и фискальный накопитель (ФН) до версии ФФД 1.1.
В этой статье мы подробно проанализируем ситуацию, разберем устройство форматов фискальных документов (ФФД), выясним, почему переход на ФФД 1.1 не требуется, и покажем, как правильно настроить драйверы касс и программный код в 1С для корректного пробития таких чеков.
Рассмотрим классический сценарий: компания начинает принимать старые товары в зачет стоимости новых (сделки мены или Trade-in). Бухгалтер требует, чтобы в чеке фигурировала оплата «Встречным представлением». Разработчик заглядывает в техническую документацию и видит упоминание о том, что полноценный тег 1217 («Сумма по чеку встречным представлением») жестко зафиксирован в спецификациях ФФД 1.1. После этого начинается долгий и сложный поиск прошивок под ККТ и дефицитных версий ФН, поддерживающих этот стандарт.
Выясним причину этой путаницы. Формат ФФД 1.1 действительно существует, однако он оказался «проходным». На рынке практически невозможно найти стабильные рабочие прошивки кассовых аппаратов и сертифицированные драйверы, работающие с ФФД 1.1. Большинство производителей (Атол, Штрих-М и др.) и сама фирма 1С перешли со старого формата ФФД 1.05 сразу на ФФД 1.2, который стал обязательным для маркированных товаров. Те компании, которые не торгуют маркировкой, продолжают успешно работать на ФФД 1.05.
Важное правило: переходить на ФФД 1.1 для отражения встречного предоставления не нужно! Этот тип оплаты полностью поддерживается в рамках массового и стабильного стандарта ФФД 1.05.
Проанализируем структуру фискальных документов. В версии ФФД 1.05 теги, отвечающие за дополнительные виды расчетов (включая встречное предоставление), являются необязательными к заполнению с точки зрения налоговой отчетности, но они физически поддерживаются самой структурой формата.
Если касса работает под управлением ФФД 1.05, мы все равно можем передавать данные об оплате встречным представлением. При этом на бумажном чеке (в зависимости от шаблона ККТ и версии прошивки) эта строка может напечататься как «Иная форма оплаты», «Обмен» или «Прочая оплата». Но в электронном виде в ОФД и налоговую службу будет отправлен корректный признак оплаты (тег 1217). Для целей бухгалтерского учета и соблюдения 54-ФЗ этого абсолютно достаточно.
Согласно действующему законодательству о применении контрольно-кассовой техники, существуют всего 5 базовых типов оплаты, которые касса способна зарегистрировать на физическом уровне:
Таким образом, «Встречное предоставление» и «Иная форма оплаты» — это синонимы с точки зрения фискального ядра кассы. Наша задача — правильно сопоставить настройки в системе 1С и таблицы драйвера кассового аппарата.
Очень часто при попытке пробить чек со встречным представлением из 1С возникает ошибка драйвера: «Неверный тип оплаты» или «Способ оплаты не поддерживается». Посмотрим, почему это происходит.
Внутри прошивки каждого фискального регистратора есть таблица оплат, где каждому типу расчета присвоен свой порядковый индекс (внутренний код). У разных производителей эти индексы существенно различаются. Проанализируем стандартные настройки популярных ККТ:
Для ККТ АТОЛ (Платформа 5.0 / Драйвер v.10):
Для ККТ Штрих-М (Драйвер 4.15 / 5.16):
Если учетная система 1С пытается отправить команду на закрытие чека встречным представлением, используя неверный индекс (например, отправляет код 5 для ККТ Штрих-М), касса вернет ошибку.
Чтобы решить эту проблему, необходимо зайти в утилиту тестирования драйвера производителя ККТ (например, «Тест драйвера ККТ Атол» или «Тест драйвера ФР Штрих-М»), перейти в раздел «Свойства» -> «Таблицы» -> «Типы оплат» и проверить, под каким номером зарегистрирована иная форма оплаты/встречное предоставление. Затем аналогичный код необходимо прописать в 1С в настройках подключаемого оборудования для конкретного кассового узла.
Современные конфигурации 1С (УТ, Розница, ERP, УНФ) взаимодействуют с ККТ через специальную БСП-компоненту интеграции (так называемую «прокладку» драйвера). Обмен данными происходит посредством передачи XML-пакетов.
Если мы разрабатываем собственное решение или дорабатываем нетиповую конфигурацию, нам необходимо сформировать правильный XML-пакет для фискализации чека. Рассмотрим пример XML-структуры чека, где часть оплаты закрывается встречным представлением (тип платежа Barter):
<?xml version="1.0" encoding="UTF-8"?>
<Receipt>
<Positions>
<FiscalString Name="Смартфон Apple iPhone (Trade-in)" Quantity="1" Price="80000" Amount="80000" Department="1" Tax="20"/>
</Positions>
<Payments>
<!-- Сумма, закрываемая старым телефоном клиента (Встречное предоставление) -->
<Payment Type="Barter" Sum="30000"/>
<!-- Сумма, которую клиент доплачивает картой (Безналичные) -->
<Payment Type="Electronically" Sum="50000"/>
</Payments>
</Receipt>
В интеграционной компоненте 1С поддерживаются следующие строковые идентификаторы для типов оплаты в XML:
Cash — наличные платежи;Electronically — безналичные платежи;Prepayment — зачет ранее полученного аванса;Postpayment — отпуск товара в кредит;Barter — оплата встречным представлением (иная форма оплаты).Если при передаче параметра Barter ККТ выдает ошибку, это означает, что интеграционная компонента (драйвер 1С) не сопоставлена с внутренней таблицей оплат ККТ. В этом случае требуется обновить интеграционную компоненту ККТ в базе 1С до актуальной версии или проверить настройки маппинга видов оплат в справочнике «Кассы ККТ» (раздел «Эквайринговые терминалы и виды оплат»).
Рассмотрим несколько практических ситуаций, когда необходимо задействовать встречное предоставление:
Barter (встречное предоставление), а оставшиеся 20 000 рублей закрываются наличными или картой.Подведем итог и составим четкий план действий по шагам:
Barter в XML-пакете.