Почему в 1С:ERP этапы оплаты в документе Реализация товаров и услуг отличаются от Заказа клиента и как это исправить

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

Логика трансформации этапов оплаты при отгрузке

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

1. Аванс (до отгрузки) и Предоплата (до отгрузки) — эти этапы предполагают поступление денежных средств до того, как товар будет передан клиенту.
2. Кредит (после отгрузки) и Кредит (плановый) — эти этапы описывают дебиторскую задолженность клиента, которая возникает уже после факта реализации.

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

Причины «сворачивания» строк в реализации

Выясним основные причины, по которым детальный график из заказа превращается в одну строку в реализации:

• Настройки соглашения с клиентом: Если в соглашении выбран вариант «Список этапов оплаты» как «Аванс (до отгрузки) + Кредит (после отгрузки)», система будет принудительно группировать все платежи в эти две категории.
• Детализация расчетов: При настройке взаиморасчетов «По заказам» системе критически важна общая сумма задолженности по документу-основанию. Для упрощения контроля дебиторской задолженности алгоритмы заполнения могут объединять плановые показатели в одну дату погашения.
• Типовой алгоритм заполнения: В программном коде заложена логика: все, что должно было быть оплачено до отгрузки, при создании реализации суммируется в один этап «Кредит» с текущей датой.

Программный анализ механизмов переноса

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

ЭтапыОплатыСервер.ЗаполнитьЭтапыОплатыДокументаПоЗаказам(ПараметрыЗаполнения)

В этой процедуре система анализирует таблицу этапов оплаты заказа. Проанализируем, что происходит внутри:

1. Программа считывает все строки из Заказа клиента.
2. Если этап имеет тип «Аванс» или «Предоплата», он пересчитывается в тип «Кредит».
3. Происходит группировка по датам платежа и вариантам оплаты. Если логика системы определяет, что несколько этапов «сдвигаются» на одну и ту же дату (например, на дату отгрузки), они неизбежно объединяются в одну строку.

Способ 1: Настройка правил оплаты без изменения кода

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

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

Способ 2: Использование графиков оплаты

Вместо ручного ввода этапов в каждом заказе, мы рекомендуем использовать справочник Графики оплаты. Рассмотрим преимущества этого подхода:

• Вы один раз настраиваете логику (например, 20% аванс, 40% кредит через 5 дней, 40% кредит через 10 дней).
• При использовании эталонного графика система лучше понимает структуру платежей при создании подчиненных документов.
• Минимизируется риск человеческой ошибки при заполнении дат и сумм.

Способ 3: Программная доработка (для старых версий ERP)

В старых релизах конфигурации (например, ранние версии 2.4) поведение системы по «схлопыванию» этапов было зашито достаточно жестко. Если бизнес-процесс требует, чтобы в реализации сохранялись именно те строки, которые были в заказе (даже если они трансформируются из аванса в кредит), потребуется вмешательство программиста.

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

&После("ЗаполнитьЭтапыОплатыДокументаПоЗаказам")
Процедура Расш_ЗаполнитьЭтапыОплатыДокументаПоЗаказам(ПараметрыЗаполнения)
    // В данном месте можно переопределить таблицу этапов оплаты,
    // которая была сформирована стандартным механизмом.
    // Нам нужно обойти группировку, если даты платежей различны,
    // или принудительно разделить строки по идентификаторам строк заказа.
    
    ОбъектДокумента = ПараметрыЗаполнения.ДокументОбъект;
    Если ТипЗнч(ОбъектДокумента) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
        // Логика по восстановлению детальных строк из ЗаказаКлиента
        // ...
    КонецЕсли;
КонецПроцедуры

Важным моментом при доработке является сохранение связи между строкой этапа в реализации и соответствующей строкой в заказе. Это позволит корректно отслеживать платежи в отчетах по задолженности.

Резюме

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