Почему в «1С:Розница 2.2» чеки пробиваются с видом оплаты «В кредит» при оплате картой и как это исправить?

В процессе эксплуатации программы «1С:Розница 2.2» в связке с эквайринговыми терминалами (например, Сбербанка) и кассовыми аппаратами (ККТ) Штрих-М, пользователи часто сталкиваются с аномалией: при попытке оплатить покупку картой чек пробивается с видом оплаты «Кредит» (или «Оплата в рассрочку»), либо «Наличные», хотя фактически клиент использовал банковскую карту. Рассмотрим детально, почему это происходит и как настроить систему, чтобы исключить подобные ошибки.

Анализ ситуации: как возникает ошибка

Проанализируем типичный сценарий возникновения проблемы. Кассир в интерфейсе РМК (Рабочее место кассира) инициирует оплату картой. В этот момент 1С отправляет команду на эквайринговый терминал. Если на карте недостаточно средств, происходит технический сбой связи или кассир ошибочно нажимает клавиши управления до завершения транзакции, система может повести себя непредсказуемо.

В старых релизах «1С:Розница» (например, 2.2.11.23) при получении отказа от банка программа не всегда блокирует возможность закрытия чека. Если кассир в спешке нажимает Enter или использует горячие клавиши, система пытается «закрыть» чек любым доступным способом. Если в системе разрешены расчеты с клиентами в рассрочку, 1С автоматически подставляет вид оплаты «Последующая оплата» (Кредит), чтобы фискализировать документ, раз команда на пробитие уже была инициирована в памяти ККТ.

Решение 1: Блокировка функционала расчетов с клиентами

Если ваша торговая точка не предполагает продажу товаров в долг или в рассрочку, первое, что необходимо сделать — полностью отключить этот функционал на уровне констант системы. Проанализируем, как это влияет на логику программы.

1. Перейдем в раздел Администрирование — Продажи.
2. Найдем опцию «Использовать расчеты с клиентами».
3. Снимем этот флаг. Это установит системную константу ИспользоватьРасчетыСКлиентами в значение Ложь.

Важное замечание: Как показывает практика, простого отключения константы иногда недостаточно. Если в интерфейсе РМК кнопка оплаты в кредит остается активной или на нее назначена горячая клавиша, система может продолжать предлагать этот вид оплаты при возникновении исключительных ситуаций с эквайрингом.

Решение 2: Настройка профилей групп доступа и прав кассиров

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

1. Откроем Администрирование — Настройки пользователей и прав — Профили групп доступа.
2. Выберем профиль, назначенный кассирам (например, «Кассир»).
3. На вкладке Разрешенные действия снимем флажки с пунктов, связанных с оплатой в кредит и передачей товаров без оплаты.
4. Проверим в справочнике Виды оплаты, нет ли там активных элементов с типом «Оплата в рассрочку». Если они есть и не используются — пометим их на удаление.

Решение 3: Изменение интерфейса РМК и скрытие кнопок

Рассмотрим самый эффективный способ борьбы с ошибками кассиров — физическое удаление возможности выбрать неверный вид оплаты в интерфейсе. Посмотрим, как это сделать в настройках РМК:

1. Перейдем в НСИ — Кассы ККМ и откроем настройки текущего РМК.
2. В разделе настройки горячих клавиш проверим, не назначены ли клавиши (например, F5 или F6) на операции «Кредит» или «Сложная оплата».
3. В настройках интерфейса РМК снимем галочку с кнопки «Передача без оплаты» и «Оплата в кредит».

После этих манипуляций, если оплата по карте не пройдет (например, при ответе терминала «Недостаточно средств»), кассир просто не увидит кнопок, позволяющих закрыть чек иным способом, кроме наличных (если они разрешены).

Решение 4: Техническая настройка драйвера ККТ и маппинг типов оплаты

Иногда проблема кроется глубже — в настройках драйвера Штрих-М. Выясним причину на уровне протокола обмена. В ККТ существует таблица «Типы оплаты», где каждому индексу соответствует название платежа, передаваемое в ОФД.

Проанализируем возможный конфликт:

1. Запустим «Тест драйвера ККТ».
2. Зайдем в раздел «Настройка свойств» — «Таблицы».
3. Найдем таблицу №18 (Типы оплаты).
4. Убедимся, что Тип оплаты 1 — это Наличные, а Тип оплаты 2 — Безналичные (или Электронные).

Если в таблице на месте типа оплаты, который 1С считает безналичным, стоит «Кредит», то физический чек выйдет с надписью «Кредит», даже если в 1С всё выбрано верно. 1С:Розница версии 2.2.11 жестко привязана к индексам типов оплаты в драйвере. Рекомендуется обновить драйвер до актуальной версии (например, 4.15 или выше), так как в версии 4.14 наблюдались ошибки обработки таймаутов.

Решение 5: Устранение таймаутов эквайринга Сбербанка

Если проблема возникает только с терминалами Сбербанка, разберем работу компоненты pilot_nt.dll. Часто бывает так: ответ от банка идет слишком долго, 1С «отваливается» по таймауту, но касса уже получила команду на открытие чека.

Для исправления ситуации выполним следующие действия:

• Проверим настройки в файле pinpad.ini (находится в папке с банковским ПО). Убедитесь, что параметры ожидания ответа сервера соответствуют качеству вашего интернет-соединения.
• В настройках «Эквайрингового терминала» в 1С попробуем увеличить время ожидания ответа.
• Если используется старый релиз 2.2.11.23, рассмотрим возможность обновления до последних версий линейки 2.2 или перехода на 2.3. В новых версиях механизм Автоматическая фиксация чека при оплате работает более корректно.

Как исправить уже пробитые «кредитные» чеки?

Если за смену накопились чеки с видом оплаты «Оплата в рассрочку», которые фактически являются дублями успешных оплат, необходимо выполнить следующие шаги для корректного закрытия смены и сдачи отчетности:

// Схема действий для кассира:
1. Найти ошибочный чек в списке чеков РМК.
2. Выполнить операцию "Чек возврата" на основании этого чека.
3. В виде оплаты возврата обязательно указать "Оплата в рассрочку" (Кредит), чтобы баланс по этому виду оплаты обнулился.
4. Проверить отчет по смене: суммы по безналичным оплатам должны совпадать со слип-чеками терминала.

Резюмируя: основная причина появления «кредитных» чеков в «1С:Розница 2.2» — это попытка программы закрыть документ при сбое основной транзакции. Использование жестких ограничений в профилях доступа и скрытие лишних кнопок в РМК полностью решает эту проблему, не позволяя кассиру случайно фискализировать долг клиента.