[УТ11] Дебиторка Фифо, вариант с внедрением нового регистра накопления (для значительного ускорения формирования отчета)

Опубликовал mxm2 mxm2 (mxm2) в раздел Отчеты - Бухгалтерские

Если в УТ11 взаиморасчеты ведутся по договорам, то очень удобно использовать принцип фифо для выяснения документов, по которым возникает долг, это в свою очередь приводит к достаточно "тяжелому" запросу при увеличении количества рассматриваемых документов. Есть несколько способов оптимизации данного отчета, которые иногда дают эффект, а иногда, могут наоборот увеличить время формирования отчета.
В тоже время удобно "поручить" базе данных хранить нужную информацию в удобном для отчета виде. В текущей реализации для этой цели используется регистр накопления остатков, в котором в нужном порядке хранится необходимая информация.

Начнем с общей упрощенной методики расчета:

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. Чтобы сформировались движения по уже проведенным документам, создана специальная обработка, которая дописывает нужные движения в новом регистре (во вложении).

Логика самого отчета (СКД), существенно упрощается, т.к. все данные есть уже в "готовом" виде.

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

 

Недостатком текущего метода является необходимость внедрения нового регистра, и необходимость изменения модулей конфигурации, для формирования движений в этом регистре, поэтому можно рекоменовать его, если конфигурация уже значительно изменена.

Скачать файлы

Наименование Файл Версия Размер
ВсеФайлыВОдномАрхиве.zip
.zip 17,13Kb
07.02.14
20
.zip 17,13Kb 20 Скачать
ДолгиКлиентовPХ.erf
.erf 15,23Kb
07.02.14
1
.erf 15,23Kb 1 Скачать
Proc.txt
.epf 6,68Kb
07.02.14
0
.epf 6,68Kb Скачать
СозданиеДвиженийПоРегиструДокументыУвеличенияДолгаРХ.epf
.epf 6,68Kb
07.02.14
0
.epf 6,68Kb Скачать

См. также

Комментарии
1. Александр Медведев (anig99) 2513 08.02.14 02:06 Сейчас в теме
По поводу 3 пункта из первой части статьи: пробовали на СКД или чистым запросом???? Столкнулся с тем, что СКД независимо от настроек что-то странное творит и увеличивает время выполнения отчета.
2. mxm2 mxm2 (mxm2) 1014 08.02.14 21:42 Сейчас в теме
(1) anig99, Вашу оптимизацию делал на СКД (где-то валяется отчет, попробую запросом в консоли). Обычное соединение для вычисления нарастающего итога пробовал и так и эдак - на больших объемах (визуально) одинаковые тормоза, На малых - субъективно СКД - быстрее.
3. Сергей (ildarovich) 4970 09.02.14 11:05 Сейчас в теме
Интересная тема. Но вот какой вопрос: - Вы же сами написали статью Сложные отчеты для управляемых форм с использованием СКД: просто. На примере отчета ABC анализ номенклатуры, клиентов для УТ11. Наверняка прочитали комментарий Якова http://forum.infostart.ru/forum24/topic91425/message963869/#message963869 (он там тремя плюсами отмечен). А почему не попробовали состыковать для решения данной задачи две СКД: в первой с помощью функции ВычислитьВыражение рассчитать нарастающий итог, а во второй - сделать все остальное? Эта идея вроде бы лежит на поверхности. Судя, например, по комментарию http://forum.infostart.ru/forum24/topic94658/message986776/#message986776 к моей статье Баттерфляй - метод быстрого расчета нарастающего итога в запросе. Дело в том, что из-за этого (из-за отсутствия данных по скорости решения на основе двухступенчатой СКД) я не пробую пока свой подход к этой задаче.
4. mxm2 mxm2 (mxm2) 1014 09.02.14 12:52 Сейчас в теме
(3) ildarovich, Если использовать "ВычислитьВыражение" в СКД, (хотя не соображу как конкретно), то можно обойтись стандартом СКД, без "прокладки" в виде языка 1С, но и в этом случае всеравно будет Вычисление нарастающего итога, а при использовании регистра накопления остатков, мы берем готовые значения (почти готовые).
Отчет с "прокладкой" - работает быстрее чем через соединение, но медленнее чем с использованием регистра (в общем то понятно почему).
5. Сергей (ildarovich) 4970 09.02.14 13:39 Сейчас в теме
(4) Нарастающий итог в первом СКД может вычисляться так
ВычислитьВыражение("Сумма(Значение)", "МояГруппировка" , , "Первая", "Текущая")
Собственно расчет должен выполняться ОЧЕНЬ быстро. Пусть этот подход съест 5 лишних секунд по сравнению с использованием регистра. Тогда будет не 20, а 25 секунд (очень хочется знать сколько именно). Но зато не придется менять конфигурацию! Это существенно расширит область применения отчета. Тут действует "правило ступеньки" - всего одна ступенька перед входом в магазин может отпугнуть до 70% потенциальных покупателей.
6. mxm2 mxm2 (mxm2) 1014 09.02.14 13:55 Сейчас в теме
(5) ildarovich, согласен, попробую на досуге.
7. Сергей (ildarovich) 4970 28.02.14 15:49 Сейчас в теме
(1) Тоже столкнулся с тем, что
СКД независимо от настроек что-то странное творит и увеличивает время выполнения отчета
- вроде бы разработчики обещали исправить это в ближайшем релизе платформы.
(6) Опубликовал свой "многообещающий" подход к этой задаче: Неоплаченные долги при распределении оплаты по правилу ФИФО одним запросом и намного быстрее, чем Вы думали. Правда, пример приведен пока только для УТ10.3, УПП, КА, но это очень просто и в самое ближайшее время сделаю для УТ11. Сравнение с СКД все еще любопытно.
8. vx_gas vx_gas (vx_gas) 17 14.05.14 14:16 Сейчас в теме
Не знаю за другие конфигурации, но в упп этот велосипед уже придуман, регистр называется "расчеты по реализации в условных единицах" ну и по приобретению где - то так же. На вскидку не помню, конфигуратор уже закрыл :)
Оставьте свое сообщение