Начнем с общей упрощенной методики расчета:
1. Получаем Партнеров / Договора, по которым имеется долг перед нашей организацией на расчетную дату.
2. Отбираем документы, которые формируют этот долг (обычно нас интересуют реализации товаров)
3. Методом соединения двух одинаковых таблиц, полученных в пп 2, в запросе получаем "обратный нарастающий итог" с детализацией до документа реализации. Этот этап и занимает значительное количество времени при формировании отчета. Здесь возможны некоторые оптимизации, примененные / описанные:
[УТ11] Дебиторка fifo по долгам контрагентов (СКД, управляемый интерфейс) - оптимизация по времени возникновения долга
Нарастающие итоги в запросе и методы ускорения его выполнения. - методы ускорения
Отчет по просроченной задолженности/задолженность по интервалам (УПП УТ 8.1, СКД) - реализация одного из них (применение данного метода для УТ11 дало обратный эффект, отчет формируется раза в 2 дольше обычного без этой оптимизации))
Баттерфляй - метод быстрого расчета нарастающего итога в запросе - еще один метод оптимизации.
Есть варианты вычисления нарастающего итога на "языке 1С", скорее всего, на больших БД тоже будет преимущество.
4. Отбираем из таблицы, полученной в пп. 3, нужные документы и распределяем их а порядке убывания, до момента исчерпания суммы задолженности.
Время исполнения всех пунктов в запросе, за исключением третьего - линейно зависят от количества элементов. Продолжительность исполнения третьего пункта - пропорциональна квадрату количества элементов, и в больших базах формирование дебиторки по всем клиентам может занимать значительне время (у нас порядка 10 - 15 минут при ~ 2000 клиентов за ~ 2+ года).
Текущая реализация отчета по тому же объему информации формируется не более 20 секунд.
Что для этого сделано (УТ 11.0.9.15):
1. Добавлен регистр накопления "ДокументыУвеличенияДолга" с измерениями "АналитикаУчетаПоПартнерам", "ЗаказКлиента", Ресурсом "Сумма", движения в нем будет делать документ РеализацияТоваровУслуг. Структура этого регистра есть упрощение регистра накопления РасчетыСКлиентами
.
2. В модуль объекта документа "РеализацияТоваровУслуг", некоторое количество кода, для формирования движений по вышеописанному регистру.
Этот код просто формирует движение прихода в вышеописанном регистре:
В конце процедуры ИнициализироватьДанныеДокумента модуля менеджера, добавим вызов Процедуры ДополнитьДанныеДокументаДляДокументыУвеличенияДолга(ДокументСсылка, ДополнительныеСтойства.ТаблицыДляДвижений); (Реализация во вложении)
Ближе к концу процедуры ОбработкаПроведения модуля объекта (после вызова СкладыСервер.ОтразитьДвиженияСерийТоваров) добавим вызов процедуры ОтразитьДокументыУвеличенияДолга(ДополнительныеСвойства, Движения, Отказ); (Реализация во вложении)
3. Чтобы сформировались движения по уже проведенным документам, создана специальная обработка, которая дописывает нужные движения в новом регистре (во вложении).
Логика самого отчета (СКД), существенно упрощается, т.к. все данные есть уже в "готовом" виде.
В тоже время т.к. в регистре ДокументыУвеличенияДолга - учитывается только один вид документов, то оптимизированный отчет не сможет дать детальную информацию по движениям, сделанным не документом реализации (а это чаще всего и нужно, более того: при необходимости, можно в вышеуказанном регистре делать движения и другими документами, и, соответственно получать детальные записи, созданные этими документами). Внешний вид отчета практически не изменился:
Недостатком текущего метода является необходимость внедрения нового регистра, и необходимость изменения модулей конфигурации, для формирования движений в этом регистре, поэтому можно рекоменовать его, если конфигурация уже значительно изменена.
