Как правильно использовать параметр TypeClose в драйвере ККТ АТОЛ для различных видов оплат

При интеграции торгового оборудования, в частности контрольно-кассовой техники (ККТ) АТОЛ, с программными продуктами 1С (особенно на платформе 7.7), программисты часто сталкиваются с нехваткой документации по специфическим параметрам драйвера. Одним из ключевых параметров при закрытии чека является TypeClose. Этот параметр определяет, каким именно способом клиент оплатил покупку. Неверное указание этого значения приведет к некорректной отчетности в ОФД и налоговой, а также к расхождениям в денежном ящике кассы.

В данной статье мы подробно разберем, какие значения может принимать параметр TypeClose, как они соотносятся с современными требованиями форматов фискальных данных (ФФД 1.05 и выше) и как правильно реализовать программную логику на стороне 1С.

Основные значения параметра TypeClose по ФФД 1.05

С внедрением онлайн-касс и обновлением протоколов обмена, значения типов оплат стали жестко регламентированы. Если раньше (в эпоху ФФД 1.0) зачастую делили оплату только на «наличные» и «все остальное», то современные прошивки ККТ АТОЛ требуют четкой классификации. Разберем стандартную кодировку, которая зашита в логику драйвера и прошивки:

1. 0 — Наличные: Это самый важный тип оплаты. Именно при использовании этого индекса ККТ увеличивает счетчик наличности в денежном ящике. Если вы проведете оплату через другой тип, касса «не увидит» этих денег физически, и вы не сможете выполнить операцию инкассации (выплаты).
2. 1 — Безналичные (Электронные): Используется для оплаты банковскими картами через эквайринговый терминал, а также для интернет-платежей и переводов по QR-коду (СБП). В чеке это будет отображаться как «БЕЗНАЛИЧНЫМИ».
3. 2 — Предварительная оплата (Аванс): Применяется в ситуациях, когда вы закрываете чек в счет ранее полученных денег (например, при реализации товара, который был оплачен ранее).
4. 3 — Последующая оплата (Кредит): Используется, если товар отпускается покупателю без оплаты (в долг) или в рассрочку.
5. 4 — Иная форма оплаты (Встречное предоставление): Этот тип предназначен для специфических случаев, таких как оплата бонусами, подарочными сертификатами (если они не проведены как аванс) или бартерные сделки.

Особенности расширенных типов оплаты (5–9)

Рассмотрим ситуацию, когда в настройках ККТ мы видим больше пяти видов оплат. Драйвер АТОЛ позволяет использовать индексы от 5 до 9. Однако здесь есть важный технический нюанс. На уровне фискального накопителя и передачи данных в ОФД эти типы не являются самостоятельными. Как правило, в современных прошивках индексы с 5 по 9 принудительно маппируются (перенаправляются) в «Электронные» или «Иную форму оплаты».

Вы можете зайти в «Тест драйвера ККТ», перейти в раздел «Параметры ККТ» и в таблице №2 («Названия типов оплат») изменить текстовое описание для типа №5, назвав его, например, «Оплата баллами». В печатной форме чека покупатель увидит ваше название, но в электронном документе для налоговой инспекции этот платеж пройдет по одной из стандартных категорий ФФД. Проанализируем это: для ОФД существует ограниченный набор тегов, и касса обязана «впихнуть» любой кастомный тип оплаты в один из разрешенных законом форматов.

Реализация смешанной оплаты в 1С

Часто возникает задача пробить чек, который оплачен частично наличными, а частично — картой. Для этого в драйвере предусмотрен механизм последовательного вызова метода Payment(). Выясним причину, почему это важно: чек закрывается не одной командой, а последовательным накоплением суммы оплат, которая в итоге должна в точности совпасть с суммой всех позиций в чеке.

Посмотрим на пример кода, который иллюстрирует этот процесс. Предположим, у нас есть переменные СуммаНал, СуммаБезнал и СуммаСертификатов:

// Предполагается, что объект драйвера уже создан и связь установлена (drv)

// 1. Регистрируем оплату наличными
drv.Summ = СуммаНал;
drv.TypeClose = 0;
drv.Payment();

// 2. Регистрируем оплату банковской картой
drv.Summ = СуммаБезнал;
drv.TypeClose = 1;
drv.Payment();

// 3. Регистрируем оплату подарочным сертификатом (иная форма)
drv.Summ = СуммаСертификатов;
drv.TypeClose = 2; // Или 4, в зависимости от настроек учета авансов
drv.Payment();

// 4. Финализируем чек
drv.CloseCheck();

Важный момент: Если сумма всех вызванных методов Payment() окажется меньше итоговой суммы чека, метод CloseCheck() вернет ошибку «Сумма всех типов оплат меньше суммы чека». Если же сумма будет больше, драйвер воспримет разницу как сдачу (но только для типа оплаты №0).

Технические рекомендации и типичные ошибки

Проанализируем наиболее частые проблемы, возникающие при работе с TypeClose:

1. Контроль наличности: Если вы ошибочно отправите оплату по карте с TypeClose = 0, касса будет считать, что в ящике лежат лишние деньги. При инкассации в конце смены возникнет недостача в кассовом ПО и излишек в ККТ.
2. Версии прошивок: В старых версиях АТОЛ (до введения онлайн-касс) типов оплаты было всего два: 0 (нал) и 1 (безнал). Если вы работаете с очень старым оборудованием, убедитесь, что оно поддерживает расширенные типы 2, 3 и 4.
3. Округление копеек: При распределении оплаты между наличными и безналичными могут возникать ошибки округления. Рекомендуется всегда рассчитывать сумму последнего платежа как ИтогЧека - СуммаУжеЗарегистрированныхПлатежей, чтобы гарантированно закрыть чек без ошибок.
4. Работа в DTO 10: Если вы используете современный драйвер 10-й версии, свойство TypeClose заменено на метод setPaymentType(). Однако логика индексов (0, 1, 2...) осталась идентичной для сохранения преемственности.

Рассмотрим подробнее работу с таблицами ККТ. Если вам нужно программно узнать, какие названия типов оплат настроены в конкретном аппарате, вы можете обратиться к Таблице №2 через методы драйвера. Это полезно для динамического построения интерфейса в 1С, чтобы бухгалтер видел те же названия кнопок, что и на чеке.

Таким образом, правильное использование параметра TypeClose — это залог корректного фискального учета. Всегда придерживайтесь стандарта: 0 для денег, 1 для эквайринга и 2–4 для специфических расчетов. Это обеспечит отсутствие проблем с налоговой отчетностью и корректную работу счетчиков денежного ящика.