В современных конфигурациях, таких как 1С:ERP Управление предприятием и 1С:Комплексная автоматизация 2, расчет просрочки по графику оплат часто вызывает затруднения у разработчиков и аналитиков. Особенно остро проблема проявляется при использовании режима «Онлайн-взаиморасчеты». Рассмотрим ситуацию, когда при наличии в заказе этапов «Аванс» и «Кредит», после оформления отгрузки данные о плановом авансе в регистрах фактически подменяются дебиторской задолженностью (кредитом), что мешает корректно вычислить дни просрочки по конкретному этапу. Разберем механизмы системы и способы решения этой задачи.
Регистр накопления ПлановыеОплатыКлиентов является основным источником данных для графиков. В нем фиксируются обязательства клиента, разделенные по вариантам оплаты (аванс до обеспечения, аванс до отгрузки, кредит и т.д.). Однако важно понимать особенность архитектуры: в режиме онлайн-взаиморасчетов система разделяет «планирование» и «факт».
Проанализируем ситуацию: до момента реализации авансовые платежи корректно закрывают плановые этапы аванса. Но как только мы проводим документ РеализацияТоваровУслуг, система технически «схлопывает» потребность в авансе. Для логики 1С аванс — это то, что должно быть оплачено до накладной. Как только накладная создана, обязательство по авансу трансформируется в общую задолженность по накладной (постоплату). В результате в регистрах накопления мы видим, что сумма реализации перекрывает план аванса, переводя его в категорию кредита. Именно поэтому попытка построить отчет только по оборотам одного регистра не дает желаемого результата после отгрузки.
Начиная с версий 2.4.11 и выше, в системе активно используется регистр накопления РасчетыСКлиентамиПоСрокам. Это специализированный регистр, который предназначен для учета задолженности в разрезе дат возникновения и, что самое важное, дат планового погашения.
Рассмотрим алгоритм работы с этим регистром:
ДатаПлановогоПогашения.ДатаПлановогоПогашения, и остаток суммы больше нуля, значит, имеет место просрочка.Посмотрим на пример структуры запроса к этому регистру:
ВЫБРАТЬ
Расчеты.ЗаказКлиента КАК Заказ,
Расчеты.ДатаПлановогоПогашения КАК ПлановаяДата,
СУММА(Расчеты.СуммаОстаток) КАК СуммаПросрочки,
РАЗНОСТЬДАТ(Расчеты.ДатаПлановогоПогашения, &ТекущаяДата, ДЕНЬ) КАК ДниПросрочки
ИЗ
РегистрНакопления.РасчетыСКлиентамиПоСрокам.Остатки(&Период, ) КАК Расчеты
ГДЕ
Расчеты.ДатаПлановогоПогашения < &ТекущаяДата
СГРУППИРОВАТЬ ПО
Расчеты.ЗаказКлиента,
Расчеты.ДатаПлановогоПогашения
Если нам необходимо видеть просрочку именно в разрезе вариантов оплаты (например, сколько просрочено именно по «Авансу»), а типовые регистры после реализации «смешивают» суммы, следует применить метод сопоставления плана и факта по суммам нарастающим итогом. Именно этот механизм используется в контекстном отчете «Состояние выполнения» в заказе клиента.
Разберем этот метод по шагам:
ПлановыеОплатыКлиентов по конкретному заказу (это наш План). Каждая запись имеет дату и сумму.РасчетыСКлиентами (это наш Факт), также отсортированные по дате.Проанализируем ситуацию на примере: по плану у нас аванс 100 руб. (до 01.05) и кредит 200 руб. (до 15.05). Всего поступило 80 руб. Несмотря на то, что реализация могла изменить движения в регистрах, математически мы видим: 80 руб. < 100 руб. Следовательно, по этапу «Аванс» имеется просрочка 20 руб., а по этапу «Кредит» — 200 руб.
Пример реализации логики сопоставления на языке запросов (схематично):
// 1. Получаем таблицу плановых платежей с накопленным итогом
// 2. Получаем общую сумму оплат по заказу
// 3. Сопоставляем
ВЫБРАТЬ
ТаблицаПлана.ВариантОплаты,
ТаблицаПлана.ДатаПлановогоПогашения,
ВЫБОР
КОГДА ТаблицаПлана.СуммаПланаНарастающим > &ОбщаяСуммаОплаты
ТОГДА ВЫБОР
КОГДА ТаблицаПлана.СуммаПланаНарастающим - ТаблицаПлана.СуммаЭтапа < &ОбщаяСуммаОплаты
ТОГДА ТаблицаПлана.СуммаПланаНарастающим - &ОбщаяСуммаОплаты
ИНАЧЕ ТаблицаПлана.СуммаЭтапа
КОНЕЦ
ИНАЧЕ 0
КОНЕЦ КАК ОстатокКПогашениюПоЭтапу
ИЗ
ТаблицаПлановыхПлатежей КАК ТаблицаПлана
Чтобы минимизировать расхождения в данных и облегчить расчеты, обратим внимание на следующие настройки:
Порядок зачета документов. В настройках НСИ (НСИ и администрирование — Казначейство и взаиморасчеты — Взаиморасчеты) установите вариант «По плановой дате платежа». Это заставит систему при распределении платежа в первую очередь закрывать те этапы графика, чья дата оплаты наступила раньше. Это критически важно для корректного заполнения регистра РасчетыСКлиентамиПоСрокам.
Актуализация расчетов. Расчет просрочки будет точным только в том случае, если выполнены все задания по распределению расчетов. В КА 2/ERP за это отвечает фоновое задание. Если вы пишете собственный отчет, рекомендуется добавить проверку наличия записей в регистре сведений ЗаданияКРаспределениюРасчетов. Если записи есть — данные в отчете могут быть неактуальны.
Использование типового API. Вместо прямого обращения к регистрам, изучите функции общего модуля ВзаиморасчетыСервер. В нем содержатся методы для получения задолженности, которые уже учитывают специфику онлайн-режима и корректно обрабатывают связку «Заказ — Реализация».
Мы выяснили, что основной причиной сложности расчета просрочки является трансформация аналитики «Вариант оплаты» после проведения реализации. Для решения этой задачи мы рекомендуем отказаться от анализа «сырых» движений регистра ПлановыеОплатыКлиентов и перейти к использованию регистра РасчетыСКлиентамиПоСрокам либо реализовать алгоритм сопоставления плана и факта нарастающим итогом. Это позволит получать достоверные данные о просрочке по каждому этапу оплаты, независимо от того, была ли уже произведена отгрузка товара клиенту.