Коллеги!
Давайте обсудим варианты решения задачи о дебиторах и кредиторах.
В наши стандартные решения мы обычно включаем куб "Взаиморасчеты", который показывает дебиторскую и кредиторскую задолженность не используя сальдовые таблицы из OLTP-систем.
MS AS имеет в распоряжении только проводки, через MDX считаются сначала балансы контрагентов на каждый день во всех разрезах, затем из них через другой MDX вычисляются значения дебиторки и кредиторки.
Определенную сложность представила задача по расчету дебиторки и кредиторке от уровня договора. MS AS стал проседать по производительности из-за слишком большого кол-ва вычислений. Однако это удалось решить тюнингом системы.

Теперь следующая задача. Произвольный анализ глубины дебиторки и кредиторки. К сожалению получается слишком тяжелый MDX и производительность сильно проседает.
Конечно можно перейти к накопительным данным в регистрах самой OLTP-системы, но этого бы не хотелось. В общем, какие мысли? Кто как делает?

Как делается тюнинг MS AS написано в MSDN, точнее там даны основы, советую всем прочитать, повторятся нет смыла.
Интересно мнение тех, кто решал задачи о дебиторах и кредиторах на практике в том числе на других OLAP-серверах.
Трудно поверить, что данную задачу решаем только мы.

Юр, динамику мы тоже считаем. С глубиной проблемы, т.е. с интервалом времени от возникновения задолженности. Ты это считал?
Если даже нет, мысли есть?

Юр, динамику мы тоже считаем. С глубиной проблемы, т.е. с интервалом времени от возникновения задолженности. Ты это считал?
Если даже нет, мысли есть?

Юр, еще. Я раньше замечал, что у тебя считались именно балансы, а не дебиторка и кредиторка. Это разные вещи. Например, при анализе по группе контрагентов может быть ненулевая и дебиторка и кредиторка, т.к. в группе есть и дебиторы и кредиторы. В случае балансов, так быть не может
Баланс по группе = сумма балансов по членам

В случае дебиторки и кредиторки от договора, очень запросто один и тот же клиент может быть и дебитором и кредитором.
Иными словами, эта задача совсем не аналог остатков по складам, а гораздо сложнее.

"Очучение" не верное.
В случае 1С нам придется залезать в ее кривые накопительные регистры, это-то делать и не хочется. Хотя в моем случае у меня более приличная OLTP-система (Scala) и там хоть есть подневные остатки.
Регистры бухгалтерий максимум 5 уровневые (я не говорю о фиктивных эмуляциях через оборотные аналитики), а нужен произвольный анализ, 5 уровней мало.
PS. В ТНК вроде сделали, вероятно придется съездить посмотреть. Переросли консультанта, блин. :)

2OR. Мне кажется ваш метод по своей концепции самый правильный. Примерно также решали задачу наши коллеги из Тюмени.
DHW построенные на технике "перепроведения" документов надо сказать гораздо более живые чем можно подумать. Если алгоритм построен на "пакетном проведении", т.е. проводится много документов в 1й SQL-операции, то такой метод еще живет на DWH в 1-2 млн. проводок, что в принципе может быть достаточно.
Производительное решение на MDX для данной задачи к сожалению получается только на накопительных регистрах.
Меня заинтересовала ваша реализация, хотелось бы ее купить/обменять. Я напишу вам письмо.

2Юра. Поясни как ты работаешь с просрочкой по складам. Интересует сама концепция, а не детали.