В процессе работы с 1С:ERP Управление предприятием (версии 2.5 и выше) многие пользователи сталкиваются с особенностью механизма онлайн-взаиморасчетов. Суть проблемы заключается в том, что при частичных отгрузках по заказу система автоматически дробит оставшуюся часть платежа (постоплату) пропорционально сумме каждой отгрузки. Рассмотрим ситуацию: по условиям договора клиент должен оплатить 50% авансом и 50% строго после того, как получит весь товар целиком. Однако, как только мы оформляем первую РеализацияТоваровУслуг на часть заказа, программа тут же выставляет по ней дебиторскую задолженность, не дожидаясь закрытия всего заказа. Разберем, почему так происходит и как мы можем решить эту задачу.
Для начала выясним причину такого поведения программы. В 1С:ERP реализован принцип оперативного отражения задолженности. Система проектировалась так, чтобы финансовый менеджер в любой момент видел в отчетах (например, в «Задолженность клиентов по срокам»), за какой именно объем фактически переданного товара клиент уже должен денег.
Когда мы используем детализацию расчетов По заказам, график оплаты в документе ЗаказКлиента является лишь предварительным планом. Как только проводится документ РеализацияТоваровУслуг, происходит следующее:
РасчетыСКлиентамиПоСрокам фиксируется дата возникновения задолженности, исходя из даты текущей реализации и количества дней отсрочки, указанных в графике.Таким образом, с точки зрения кода 1С, любая отгрузка — это факт передачи ценностей, который должен быть обеспечен оплатой в соответствии с пропорцией. Система «не знает», что вы планируете отгружать вторую часть завтра или через год, и фиксирует долг по факту уже совершенного действия.
Если мы хотим избежать доработок системы, проанализируем возможность использования ордерной схемы склада. Это один из наиболее чистых способов с точки зрения методологии 1С.
Посмотрим, как изменится схема работы:
РасходныйОрдерНаТовары.РеализацияТоваровУслуг на этом этапе не оформляется.РеализацияТоваровУслуг на всю сумму заказа.Важный нюанс: этот метод подходит только в том случае, если ваш клиент готов получать финансовые документы (счета-фактуры, УПД) только в конце полной поставки. Если же документы требуются на каждую машину/партию, этот способ не сработает.
Если бизнес-процесс требует оформления накладных на каждую часть отгрузки, но дебиторская задолженность должна «спать» до момента закрытия заказа, нам потребуется вмешательство в программный код. Проанализируем, какие объекты системы отвечают за это поведение.
Ключевым узлом является процедура распределения взаиморасчетов. В типовом решении заложен алгоритм пропорционального распределения. Чтобы реализовать «хотелку» о финальной отгрузке, нам нужно добавить в систему признак, который будет сообщать механизму распределения, что данная реализация является последней.
Представим примерное ТЗ для программиста:
РеализацияТоваровУслуг дополнительный реквизит (флаг) ФинальнаяОтгрузкаПоЗаказу (булево).ВариантыОплатыКлиентами) создать новый вариант отсчета: «От даты финальной отгрузки».ФинальнаяОтгрузкаПоЗаказу не установлен, то сумма плановой постоплаты не должна привязываться к текущей реализации, а должна оставаться «висеть» на заказе.Посмотрим на пример логики, которую можно внедрить в код (упрощенно):
// В процедуре распределения плановых оплат
Если Не ТекущаяРеализация.ФинальнаяОтгрузкаПоЗаказу Тогда
// Исключаем суммы постоплаты из распределения на этот документ
ОстатокКРаспределению = СуммаПредоплаты; // Разрешаем распределять только авансы
Иначе
// Если это финал - закрываем весь остаток графика
ОстатокКРаспределению = ВсегоПоЗаказу - СуммаУжеРаспределенныхОплат;
КонецЕсли;
Почему специалисты 1С часто говорят, что «так делать не нужно»? Проанализируем ситуацию со стороны финансового контроля. Если мы перенесем всю постоплату на последнюю отгрузку, которая случится через полгода, то в течение этих шести месяцев отчет «Платежный календарь» не будет показывать ожидаемое поступление денежных средств за уже отгруженные части товара.
С точки зрения ERP, это создает «информационный вакуум»: товар отдан, актив перешел к клиенту, но в финансовом планировании эти деньги не участвуют, так как срок их оплаты формально не наступил. Это может привести к кассовым разрывам, если объемы отгрузок велики.
Подведем итог нашему исследованию. Мы выяснили, что поведение 1С:ERP является системным и глубоко зашитым в логику РегистрНакопления.ДанныеПлановыхОплат и РегистрНакопления.РасчетыСКлиентамиПоСрокам.
Для решения вашей задачи выберите один из путей:
РеализацияТоваровУслуг в момент завершения обязательств по заказу.Выбор конкретного метода зависит от готовности вашей финансовой службы видеть «пустой» график поступлений до момента полной комплектации заказа клиента.