При работе в конфигурациях 1С:ERP Управление предприятием 2, 1С:Комплексная автоматизация 2.4 и 1С:Управление торговлей 11.4 пользователи часто сталкиваются с вопросами контроля графиков оплат. Возникают две основные задачи: как с помощью типовых отчетов проанализировать плановые даты оплат и задолженность по документам, а также почему при создании документа реализации программа автоматически подставляет в качестве планируемой даты оплаты максимальную дату из графика заказа клиента (особенно если в заказе было указано несколько этапов оплаты).
Давайте подробно разберем эти вопросы, проанализируем доступные в системе инструменты и выясним причину такого поведения программы при расчете дат.
Для анализа графиков оплат и задолженности по конкретным документам в типовом функционале систем 1С предусмотрено несколько специализированных отчетов и обработок. Рассмотрим их подробнее.
Это основной оперативный инструмент казначея. Платежный календарь собирает данные о всех планируемых поступлениях и списаниях денежных средств на основе заказов, счетов на оплату и графиков платежей. Он позволяет наглядно увидеть кассовые разрывы и понять, в какие дни ожидаются оплаты по конкретным документам.
В стандартном виде этот отчет показывает общие суммы дебиторской и кредиторской задолженности, разбитые по временным интервалам (интервалы можно гибко настраивать в системе). Однако для нашей задачи его можно модернизировать. Зайдем в Расширенные настройки отчета, включим группировку по полю ОбъектРасчетов и добавим поле ДатаПлановогоПогашения. После такой настройки отчет начнет выводить максимально детальную информацию: какой именно документ (заказ или реализация) сформировал долг, когда по графику должна поступить оплата и сколько дней составляет просрочка. Для быстрого анализа расчетов с учетом условий договоров и плановых дат платежей можно использовать ведомость по долгам клиентов с анализом сроков оплаты.
При использовании новой архитектуры взаиморасчетов, где установлен режим Онлайн, этот отчет умеет четко разделять фактический долг и плановые движения денежных средств. В нем фиксируются плановые даты платежей, строго привязанные к конкретным заказам и накладным.
Найти его можно в разделе Казначейство - Отчеты по казначейству. Этот отчет позволяет вывести календарную таблицу плановых поступлений и списаний по дням за выбранный период в разрезе объектов оплаты. Для формирования готового реестра ожидаемых поступлений в разрезе менеджеров и документов расчетов можно использовать отчет по плановым и просроченным оплатам клиентов.
Этот контекстный отчет формируется непосредственно из самого документа ЗаказКлиента. Он очень удобен для локального анализа. Отчет наглядно показывает всю хронологию работы по сделке: плановые этапы оплаты (аванс, предоплата, кредит), плановые даты выполнения этих этапов, а также суммы — сколько фактически уже оплачено и сколько осталось доплатить.
Этот нюанс часто вызывает недоумение у менеджеров по продажам. Разберем логику работы программы. Описанное поведение является базовой логикой работы новой архитектуры взаиморасчетов (начиная с версий ERP 2.4.6, КА 2.4.6 и УТ 11.4.6).
Когда документ РеализацияТоваровУслуг создается на основании документа ЗаказКлиента, в котором было настроено несколько этапов оплаты (например, «Предоплата 30%» и «Кредит (после отгрузки) 70%»), в правила оплаты самой реализации переносится только кредитная (послеотгрузочная) часть.
Поскольку отгрузка товара уже совершается, система считает, что все этапы предоплаты (которые должны были произойти до отгрузки) уже выполнены или, по крайней мере, должны остаться привязанными к самому заказу клиента. Для самой же накладной (реализации) устанавливается одна плановая дата платежа — максимальная дата отсрочки. Эта дата рассчитывается исходя из кредитных этапов заказа. Программа считает эту дату финальным дедлайном, до которого клиент обязан полностью погасить оставшийся долг именно по данной накладной.
Если реализация вводится без заказа, но по договору, в котором зафиксирован график оплат, логика немного иная. Система анализирует текущее состояние расчетов по этому договору. Если имеющейся предоплаты от клиента хватает для полного покрытия суммы накладной, то в качестве даты платежа подставляется текущая дата (так как долга по сути не возникает, оплата уже произведена). Если же предоплаты не хватает, программа берет ближайшую плановую дату платежа из графика договора, которая больше даты накладной.
Проанализируем ситуации, когда стандартный расчет дат оплат не устраивает бизнес, и посмотрим, как можно скорректировать эти данные.
Если автоматически рассчитанная максимальная дата платежа в реализации не соответствует вашим договоренностям с клиентом, вы всегда можете скорректировать её внутри самой накладной. Для этого на закладке с правилами оплаты реализации предусмотрено специальное поле Сдвиг. Изменяя количество дней сдвига в этом поле, вы вручную меняете конечную плановую дату платежа. Именно от этой измененной даты система в дальнейшем будет рассчитывать просрочку дебиторской задолженности в отчетах.
На практике многие компании сталкиваются с системной проблемой: плановые даты оплат в заказах рассчитываются от плановой даты отгрузки. Однако по факту отгрузка часто происходит либо позже, либо раньше плана. Из-за этого графики платежей сбиваются, и казначейство видит некорректную картину ожидаемых поступлений денежных средств.
Для автоматизированного решения этой проблемы часто используют готовые расширения (их можно найти на профильных ресурсах для специалистов 1С). Логика таких доработок следующая: при проведении документа реализации расширение перехватывает событие и автоматически пересчитывает даты оплаты в родительском заказе клиента, отталкиваясь от даты фактической отгрузки (даты проведения накладной). Это избавляет менеджеров от необходимости ручной корректировки каждого заказа при малейшем смещении сроков поставки.
Таким образом, правильное понимание архитектуры онлайн-взаиморасчетов и использование описанных отчетов (с должной настройкой группировок) позволяет полностью контролировать графики оплат, отслеживать просроченную задолженность и управлять денежными потоками предприятия без потери данных.