Как в 1С 7.7 Торговля и Склад настроить оплату банковской картой по 54-ФЗ и избежать расхождения в кассе?

← На главную

С введением в действие Федерального закона № 54-ФЗ перед пользователями и разработчиками старых, но надежных конфигураций на платформе 1С 7.7 (в частности, «Торговля + Склад») встал серьезный вопрос. Как правильно отразить оплату от покупателя по банковской карте через терминал (эквайринг) так, чтобы фискальный регистратор пробил чек с признаком «Электронно», а в самой программе не произошло расхождения по реальной кассе?

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

Шаг 1. Методологическое решение проблемы «расхождения кассы»

Прежде чем приступать к программированию, разберем, как правильно организовать документооборот в «1С 7.7 Торговля и Склад». Чтобы наличные деньги не смешивались с безналичными поступлениями по эквайрингу, рекомендуется следующий алгоритм:

Создание виртуальной кассы: В справочнике «Кассы» создадим отдельный элемент, например, «Терминал (безналичные)».
Оформление ПКО: При приеме оплаты картой в документе «Приходный кассовый ордер» выбираем именно эту виртуальную кассу. Реальные наличные деньги пойдут в «Основную кассу», а оплата по терминалу — на виртуальную кассу эквайринга. Это полностью решает проблему расхождения фактической наличности в кассовом ящике при снятии Z-отчетов.
Отражение в бухгалтерии: В бухгалтерском учете данные операции должны отражаться по дебету счета 57 «Переводы в пути». При фактическом зачислении денег банком на расчетный счет (за минусом комиссии банка) оформляется банковская выписка, которая закроет транзитную сумму на счете 57.

Шаг 2. Доработка формы ПКО и глобального модуля 1С 7.7

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

Добавим на форму документа «Приходный кассовый ордер» (или непосредственно в диалог перед печатью чека) признак безналичной оплаты — например, флаг (реквизит типа «Число») ОплатаКартой.

Далее найдем в глобальном модуле процедуру, отвечающую за печать чека на ККМ. Обычно это процедура глФРПечатьЧека. Нам нужно передать туда наш новый параметр. Изменим сигнатуру вызова процедуры и добавим обработку типа оплаты:


// В Глобальном модуле
Процедура глФРПечатьЧека(КонтекстДанных, СуммаЧека, ТипОплаты = 0) Экспорт
    // ТипОплаты: 0 - Наличные, 1 - Безналичные (Электронно)
    ...
КонецПроцедуры

При вызове этой процедуры из документа ПКО мы будем передавать значение нашего флага:

глФРПечатьЧека(Контекст, Итог("Сумма"), ФлагОплатыКартой);

Шаг 3. Модификация обработки обслуживания фискального регистратора (ККМ)

Теперь разберем, как передать этот параметр непосредственно в драйвер кассы. Большинство обработок обслуживания (например, для ККТ АТОЛ — frATOL54_comm.ert или Штрих-М) взаимодействуют с драйвером через OLE-объект. За распределение типов оплат в драйверах отвечает свойство TypeClose (тип закрытия чека).

В старых версиях прошивок и старых форматах фискальных данных (ФФД 1.0) для оплаты картой использовалось значение TypeClose = 3. Однако под требования 54-ФЗ (ФФД 1.05 и ФФД 1.2) правила изменились. Теперь безналичные платежи должны проходить под типом оплаты «1» («Электронно» или «Безналичными»).

Посмотрим на пример реализации логики выбора типа оплаты внутри обработки обслуживания ККМ:


// В обработке обслуживания ККТ в процедуре закрытия чека
ТипОплатыКартой = 3; // Значение по умолчанию для старых версий

Если Объект.ЕстьПоддержка54ФЗ = 1 Тогда     
    ТипОплатыКартой = 1; // Поддержка 54-ФЗ (1 - Электронно)
КонецЕсли;

Если ТипОплаты = 0 Тогда        
    Объект.TypeClose = 0; // Наличные
ИначеЕсли ТипОплаты = 1 Тогда
    Объект.TypeClose = ТипОплатыКартой; // Безналичные
КонецЕсли;

Объект.Payment();

Если на предприятии практикуется сложная оплата (когда клиент часть суммы платит наличными, а часть — картой), мы можем разделить платежи по типам закрытия чека следующим образом:


// Пример сложного закрытия чека с разделением типов оплат
Если ОплатаКартой > 0 Тогда
    Объект.Summ = ОплатаКартой; 
    Объект.TypeClose = 1; // Карта
    Объект.Payment();  
КонецЕсли;
        
СуммаОстаток = СуммаЧека - ОплатаКартой; 
        
Если СуммаОстаток > 0 Тогда
    Объект.Summ = СуммаОстаток;
    Объект.TypeClose = 0; // Наличные  
    Объект.Payment();
КонецЕсли;
        
Объект.ЗакрытьЧек();

Шаг 4. Решение проблем со скидками и округлением под 54-ФЗ

При переходе на новые фискальные форматы (ФФД 1.05 и 1.2) программисты 1С 7.7 часто сталкиваются с тем, что кассовый аппарат отказывается бить чек со скидками, выдавая ошибку несоответствия сумм. Это связано с тем, что налоговые органы жестко контролируют математическое правило: Цена * Количество = Сумма.

При использовании драйверов (например, АТОЛ ДТО 8 или ДТО 10) встроенные механизмы передачи скидок часто вызывают ошибки округления на одну копейку. Чтобы избежать этого, настоятельно рекомендуется передавать в фискальный регистратор позиции уже со скидкой. То есть в коде 1С мы делим итоговую сумму строки с учетом скидки на количество товара, получаем чистую цену и передаем ее в ККТ:

Вычисляем цену позиции программно: ЦенаСоСкидкой = СуммаСтрокиСУчетомСкидки / Количество.
Передаем полученную цену напрямую в параметр драйвера.
Для информирования покупателя выводим текстовую информацию о размере скидки в виде нефискальной строки (методом печати текста драйвера), чтобы не ломать математический расчет ККТ.

Шаг 5. Переход на современный драйвер АТОЛ ДТО 10

Поскольку старый драйвер АТОЛ ДТО 8 давно снят с поддержки и не обеспечивает полноценную работу с маркировкой и новыми реквизитами ФФД 1.2, для стабильной работы 1С 7.7 рекомендуется использовать интеграцию через **ДТО 10** (`addin_fptr10_x86.dll`).

В ДТО 10 типы оплаты задаются через специальные константы. Для безналичного расчета используются следующие параметры:

LIBFPTR_PT_CASH (значение 0) — Наличные.
LIBFPTR_PT_ELECTRONIC (значение 1) — Безналичные.

Использование современных обработок обслуживания, адаптированных под ДТО 10, позволит вашей системе 1С 7.7 бесперебойно работать со всеми современными моделями онлайн-касс и соблюдать все требования законодательства.