Почему не заполняется оплата платежными картами в Отчете о розничных продажах?

← На главную

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

Анализ программного кода и логических условий

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


Для каждого Чек Из Чеки Цикл  
    Если НЕ Чек.Oplacheno = 0 И Чек.NalichnayaOplata = 0 Тогда                
        СтрокаОПК = ОтчетОРозничныхПродажахОбъект.ОплатаПлатежнымиКартами.Добавить();
        СтрокаОПК.ВидОплаты = ВидОплаты;            
        СтрокаОПК.Сумма = Чек.beznalichnayaOplata;   
    КонецЕсли;
КонецЦикла;

Первое, на что мы должны обратить внимание, — это условие фильтрации. Если во второй базе данных формат входящих значений Чек.Oplacheno или Чек.NalichnayaOplata отличается (например, вместо числа приходит пустая строка или NULL), условие может не выполняться. Рекомендуем всегда использовать явное приведение типов и проверку на заполненность:


Для каждого Чек Из Чеки Цикл  
    СуммаБезнал = Число(Чек.beznalichnayaOplata);
    Если СуммаБезнал > 0 Тогда                
        СтрокаОПК = ОтчетОРозничныхПродажахОбъект.ОплатаПлатежнымиКартами.Добавить();
        СтрокаОПК.ВидОплаты = ВидОплаты;            
        СтрокаОПК.Сумма = СуммаБезнал;   
    КонецЕсли;
КонецЦикла;

Проверка справочника «Виды оплаты»

Если код отрабатывает без ошибок, но строки в документе не фиксируются или документ не проводится, причина часто кроется в данных. В 1С:УПП справочник ВидыОплаты (или ВидыОплатыЧека) имеет критическое значение. Выясним, что именно нужно проверить во второй базе:

Тип оплаты: Убедимся, что для элемента, на который ссылается переменная ВидОплаты, установлен тип «Платежная карта». Если в базе-приемнике этот элемент случайно настроен как «Наличные», логика проведения Отчета о розничных продажах может игнорировать такие строки.
Договор эквайринга: Это самая частая причина «тихого» невыполнения операций. Проверим, указан ли в карточке вида оплаты банк-эквайер и выбран ли действующий договор с ним. Без этих реквизитов УПП не сможет сформировать корректные движения по счетам учета расчетов с банком.
Статья движения денежных средств: Для корректного отражения в управленческом и бухгалтерском учете в виде оплаты должна быть заполнена статья ДДС.

Влияние настроек склада и учетной политики

Проанализируем настройки самого документа ОтчетОРозничныхПродажах. В УПП поведение документа сильно зависит от типа склада, выбранного в шапке:

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

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

Типизация данных и проблемы COM-соединения

Если обмен данными происходит между разными базами через COM-соединение, важно помнить о передаче типов. Объекты, полученные из другой базы, в текущей базе могут восприниматься как COMObject. Выясним, правильно ли передается ВидОплаты:

Если вы присваиваете СтрокаОПК.ВидОплаты = ДругаяБаза.Справочники.ВидыОплаты.НайтиПоКоду("001"), то в текущей базе это будет битая ссылка или пустой объект. Необходимо найти соответствующий элемент именно в текущей базе по уникальному идентификатору (GUID) или коду.

Методика отладки в «проблемной» базе

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


Для каждого Чек Из Чеки Цикл  
    // Добавим диагностическое сообщение
    Сообщить("Обработка чека: Оплачено=" + Чек.Oplacheno + ", Нал=" + Чек.NalichnayaOplata);
    
    Если Число(Чек.beznalichnayaOplata) > 0 Тогда                
        СтрокаОПК = ОтчетОРозничныхПродажахОбъект.ОплатаПлатежнымиКартами.Добавить();
        СтрокаОПК.ВидОплаты = НайтиНужныйВидОплаты(Чек.ИдентификаторВида);            
        СтрокаОПК.Сумма = Число(Чек.beznalichnayaOplata);
        Сообщить("Добавлена строка оплаты на сумму: " + СтрокаОПК.Сумма);
    КонецЕсли;
КонецЦикла;

Если в окне сообщений вы видите, что строки добавляются, но после сохранения документа они исчезают, значит срабатывает подписка на событие или код в модуле объекта ПередЗаписью, который очищает некорректно заполненные оплаты (например, если не указаны обязательные аналитики — проекты, подразделения или статьи).

Инициализация и заполнение реквизитов

При программном создании документа крайне важно вызывать стандартные обработчики. Посмотрим на правильную последовательность действий:

Создаем объект документа через Документы.ОтчетОРозничныхПродажах.СоздатьДокумент().
Заполняем основные реквизиты (Организация, Склад, Дата).
Вызываем метод Заполнить(Неопределено) — это позволит системе инициализировать значения по умолчанию из настроек пользователя и параметров учета.
Только после этого заполняем табличные части Товары и ОплатаПлатежнымиКартами.
Выполняем метод Записать(РежимЗаписиДокумента.Запись).

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

Подводя итог, если в одной базе ОРП заполняется, а в другой нет при идентичном коде — проблема на 99% кроется в настройках справочника «Виды оплаты» (отсутствие договора эквайринга или неверный тип оплаты) или в типе склада, указанном в документе.