IE 2016

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

Опубликовал 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
17
.zip 17,13Kb 17 Скачать
ДолгиКлиентов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 0 Скачать
СозданиеДвиженийПоРегиструДокументыУвеличенияДолгаРХ.epf
.epf 6,68Kb
07.02.14
0
.epf 6,68Kb 0 Скачать

См. также

Комментарии

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






IE 2016