Как реализовать анализ продаж в разрезе товара с контролем факта оплаты в 1С?

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

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

Архитектурные ограничения и постановка задачи

Проанализируем базовую проблему учета: когда поступает частичная оплата по накладной (например, оплачено 50 000 руб. из 100 000 руб. по документу, содержащему 20 позиций), стандартный регистр взаиморасчетов фиксирует только уменьшение общего долга по документу. В типовой структуре данных не заложено правило, закрывает ли эта сумма первые строки реализации, самые дорогие товары или распределяется равномерно.

Выясним причину необходимости такой детализации. Чаще всего требование возникает в двух случаях:

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

Способ 1. Расчет коэффициента оплаты на лету в отчете (СКД)

Рассмотрим наименее инвазивный вариант, который не требует переделки структуры регистров и перепроведения документов. Логика строится на вычислении процента оплаты накладной и применении его к строкам продажи.

Разберем по шагам логику построения отчета:

1. В запросе СКД соединяем регистр накопления Продажи (или табличные части документов РеализацияТоваровУслуг) с остатками по регистру взаиморасчетов (например, ВзаиморасчетыСКонтрагентами или ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов).
2. Вычисляем сумму фактической оплаты по документу реализации: СуммаОплаты = СуммаДокумента - ОстатокДолга.
3. Рассчитываем коэффициент оплаты: Коэффициент = СуммаОплаты / СуммаДокумента.
4. Умножаем сумму выручки, себестоимости и маржи по каждой строке номенклатуры на полученный коэффициент.

Посмотрим на пример фрагмента вычисляемого поля или выражения в запросе:

ВЫБОР
    КОГДА ТаблицаПродаж.СуммаДокумента = 0 ТОГДА 0
    КОГДА ТаблицаОплат.СуммаОплаты >= ТаблицаПродаж.СуммаДокумента ТОГДА ТаблицаПродаж.СуммаВыручки
    ИНАЧЕ (ТаблицаОплат.СуммаОплаты / ТаблицаПродаж.СуммаДокумента) * ТаблицаПродаж.СуммаВыручки
КОНЕЦ

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

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

Способ 2. Пономенклатурный учет оплат через регистр накопления (FIFO)

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

Разберем структуру нового объекта конфигурации:

1. Создаем регистр накопления (остатков или оборотов) ОплаченныеТоварыПродаж.
2. Измерения: Номенклатура, ХарактеристикаНоменклатуры, ДокументПродажи, Покупатель.
3. Ресурсы: Количество, СуммаВыручки, СуммаОплаты.

При проведении платежных документов (ПлатежноеПоручениеВходящее, ПриходныйКассовыйОрдер) алгоритм считывает состав строк связанной накладной и последовательно закрывает строки по алгоритму FIFO.

Посмотрим на примерную структуру модуля проведения платежного документа:

ОстатокПлатежа = ДокументОплаты.СуммаДокумента;
ВыборкаСтрок = ПолучитьСтрокиНакладнойПоФИФО(ДокументРеализации);

Пока ВыборкаСтрок.Следующий() И ОстатокПлатежа > 0 Цикл
    СуммаКЗакрытию = Мин(ОстатокПлатежа, ВыборкаСтрок.НеоплаченныйОстаток);
    
    Движение = Движения.ОплаченныеТоварыПродаж.Добавить();
    Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
    Движение.Период = Дата;
    Движение.ДокументПродажи = ДокументРеализации;
    Движение.Номенклатура = ВыборкаСтрок.Номенклатура;
    Движение.СуммаОплаты = СуммаКЗакрытию;
    
    ОстатокПлатежа = ОстатокПлатежа - СуммаКЗакрытию;
КонецЦикла;

Способ 3. Отслеживание цепочки «Поставщик — Товар — Покупатель» (по аналогии с КУДиР/УСН)

В ситуациях, когда требуется контролировать сквозную цепочку (товар оплачен покупателем И товар оплачен поставщику), используется механизм контроля состояний партий, аналогичный учету расходов при УСН («Доходы минус расходы»).

Проанализируем 4 события, необходимые для признания товара полностью закрытым:

1. Поступление номенклатуры на склад (партия оприходована).
2. Оплата поставщику за соответствующую партию товара.
3. Реализация товара конечному покупателю.
4. Поступление оплаты от покупателя за данный документ продажи.

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

Скрытые проблемы и краевые случаи

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

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

Управленческая альтернатива: контроль на уровне сделок

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

В этом случае контроль ведется по правилу: сделка считается успешной, а товар оплаченным только тогда, когда общее сальдо расчетов по документу ЗаказПокупателя или РеализацияТоваровУслуг строго равно нулю. Наличие недоплаты даже в 1 копейку исключает продажу из расчета бонусов, что одновременно стимулирует менеджеров контролировать своевременное и полное закрытие дебиторской задолженности.