Как исправить распределение сумм по наличному расчету и эквайрингу в 1С:Бухгалтерия 3.0 при ошибках кассиров

← На главную

В розничной торговле часто возникает ситуация, когда кассир ошибается при выборе типа оплаты на кассе: пробивает «Наличные» вместо «Безналичных» или наоборот. Если кассовый аппарат не интегрирован с банковским терминалом, 1С:Бухгалтерия предприятия 3.0 (БП 3.0) начинает некорректно закрывать задолженность по счету 57.03 (Продажи по платежным картам). Из-за заложенного в программу механизма распределения оплат по принципу FIFO (первый пришел — первый ушел), «хвосты» от старых ошибок тянутся в новые документы, создавая путаницу в учете.

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

Причина проблемы: как 1С работает с эквайрингом

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

Решение 1. Использование нескольких эквайринговых терминалов

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

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

Поскольку 1С ведет учет на счете 57.03 в разрезе терминалов (если это настроено в учетной политике или через субконто), программа не увидит «хвосты» по другим терминалам, и распределение пройдет только по текущим суммам.

Решение 2. Корректировка взаиморасчетов через «Корректировку долга»

Если «хвосты» уже накопились и мешают работать, их необходимо «схлопнуть». Выясним, как это сделать без изменения старых документов:

Проанализируем оборотно-сальдовую ведомость по счету 57.03 в разрезе договоров и терминалов.
Создадим документ Корректировка долга с видом операции «Прочие корректировки».
В качестве дебитора и кредитора выберем наш банк-эквайер.
На закладке «Дебиторская задолженность» выберем документы ОРП, по которым зависли ошибочные суммы.
На закладке «Кредиторская задолженность» (или используя счет 91.02 / 94, в зависимости от решения руководства о списании недостач) закроем эти суммы.

Это позволит обнулить сальдо по счету 57.03 и начать учет «с чистого листа».

Решение 3. Техническое ограничение прав и доработка интерфейса

Чтобы исключить человеческий фактор без полной интеграции эквайринга, рассмотрим вариант программной доработки рабочего места кассира (РМК) или формы чека в 1С:

Разделение полей ввода. Можно модифицировать форму так, чтобы при выборе безналичной оплаты кассир был обязан ввести RRN (номер операции) или код авторизации. Это заставит кассира посмотреть на слип-чек терминала и убедиться, что оплата действительно прошла по карте.

Автоматический расчет остатка. Если кассир вводит общую сумму чека, можно добавить кнопку «Распределить», которая будет предлагать остаток суммы после ввода наличных отправить в безнал, минимизируя ручной ввод цифр.

Решение 4. Исправление ошибок в ОФД (Юридический аспект)

Важно помнить, что просто поправить цифры в 1С недостаточно. Данные в ОФД должны соответствовать учету. Проанализируем порядок действий при обнаружении ошибки:

Если кассир пробил «Наличные» вместо «Безналичных», необходимо пробить Чек возврата прихода по типу оплаты «Наличные».
Затем пробить новый Чек прихода с верным типом оплаты «Безналичные».

Если используется ФФД 1.1 или выше, рекомендуется использовать Чек коррекции. В 1С:БП 3.0 это реализуется через создание документа Чек коррекции на основании ошибочного чека. Это единственный законный способ избежать штрафов по статье 14.5 КоАП РФ.

Пример программного анализа остатков по 57.03

Для программиста, который хочет автоматизировать поиск таких расхождений, приведем пример запроса, который поможет быстро найти «подвисшие» суммы на счете 57.03, не закрытые отчетами эквайринга:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ХозрасчетныйОстатки.Субконто1 КАК Банк,
    |	ХозрасчетныйОстатки.Субконто2 КАК Договор,
    |	ХозрасчетныйОстатки.Субконто3 КАК Терминал,
    |	ХозрасчетныйОстатки.СуммаОстатокДт КАК СуммаДолга
    |ИЗ
    |	РегистрБухгалтерии.Хозрасчетный.Остатки(&Период, Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.ПродажиПоПлатежнымКартам), , ) КАК ХозрасчетныйОстатки
    |ГДЕ
    |	ХозрасчетныйОстатки.СуммаОстатокДт > 0";

Запрос.УстановитьПараметр("Период", ТекущаяДата());
Результат = Запрос.Выполнить();

Этот код позволяет получить список всех незакрытых транзакций. Если сумма висит слишком долго (больше 3-х дней), это верный признак ошибки кассира, которую нужно исправлять либо корректировкой долга, либо исправлением первичных документов.

Заключение

Подводя итог, отметим: автоматизация «бардака» в виде бесконечных правок в 1С — путь тупиковый. Рассмотрим оптимальный алгоритм действий:

Максимально стремиться к интеграции терминалов с 1С (это исключает 99% ошибок).
Использовать разные аналитики (терминалы/договоры) для разделения потоков данных.
Регулярно (раз в неделю) проводить сверку данных 57.03 с банковскими выписками и оперативно делать чеки коррекции.
Обучить персонал работе с чеками возврата сразу после совершения ошибки.

Такой комплексный подход позволит поддерживать базу 1С в чистоте, а отчетность — в актуальном состоянии.