Добрый день всем.
SSAS 2012

Данные идут по 20 филиалам (кое где с 2002 года )
Есть общий вопрос по архитектуре
думаю кто-то знаимался похожими вещами
Инетересует общий подход - любые замечания и предложения велком.

Имеем ТТН клиенту по к-м выставлются требования (+ там разовые требования )
(так же есть вовзраты брака по ТТН
к-е могут прийти и через N лет - и к-е учитываются по дате ТТН
т.е нужен пересчет ЗАДНИМ числом - это важно. )

Платежки (разных типов )

Debit (ТТН - возварты ) - Credit (Платежка)
Разноска между ними Debit2Credit по принципу FIFO
с пересчетом задним числом из за возвратов.

2 валюты (старые и новые )

1?) Если высчитать ДЗ на каждый день по каждой ТТН
то какую агрегацию использовать

1.01.2009 500
...
31.12.2024 500 - тот же самый остаток

Last Child ?



2?) Объем данных
сейчас есть старая версия куба с группировкой КЛИЕНТУ

Хотят видеть ДЗ на уровне документов (или возможно даже позиций по ТТН )
- резко возрастет объем данных
Есть опасения что вылезут большие объемы и тормоза.

может кто поделится идеями общего подхода к таким задачам.

Критик,
сорри - писал на автомате
ТТН клиенту по которым выставляются требования
там нет серебряной пули - но есть кой какие моменты не вписывающиеся в мое текущее понимание
как собрать куб

поэтому (понимая что вопрос получается абстрактный)
и писал про общий подход к такого рода задачам

Привет всем

ну вот обсуждалось
https://www.sql.ru/forum/75246/zadachi-o-debitorke-i-kreditorke?hl=???????

вот примерно тоже самое и хочу сделать

Я делал задачу о разбивке торговой деб задолженности по срокам.
Таб по взаиморасчетам готовится в хранилище на скл сервере на основе данных отгрузки/платежи (типа аналог накопительных регистров 1С),
отгрузка/требование "закрывается" оплатой по принципу fifo, т.е. пришедшие деньги закрывают первое незакрытое требование и т.д.
Потом для каждого незакрытого требования считается срок задолженности в днях от "Даты отчета" и все они сбрасываются в итоговую таблицу (ДатаОтчета, КодКлиента, №Накладной, СуммаДолга, ДнейПросрочки) , на основе которой стоится куб/делается отчет о просроченных долгах.
Делается 1 раз в день, исп DTS, работает достаточно быстро, "глубину обновления" данных стандартно - 1 день и раз в месяц - пересчет за месяц.
Объемы достаточно небольшие, ок 500клиентов, в среднем 300накладных/день.
Время обновления месячных данных втаблице на п4-2.4+512Мб - ок 1-2мин.


СуммаДолга = ДЗ или Сумма ДЗ (дебиторской задолженности )у меня.
отгрузка/требование = ТТН
Оплата = Платежки

1?) Агрегация по СуммаДолга не очевидна мне
Last - скорей всего
Last Not Empty - но тогда отчет на дату выдаст ДЗ с другой даты - что наверно не верно.


2?) Объем данных там явно меньше
я прикидывал каждый день по 10000 записей и это не по самому большому филиалу
и все это надо запихнуть с 2002 года (для некоторых).
И тут вопрос а надо ли - а нельзя ли ограничить как-то ну скажем последние 3 года.
Проблема в том что возвраты брака могут прийти сегодня а лечь на ТТН N-летней давности.
(почему так это отдельный вопрос.)
и поэтому возможен пересчет ДЗ задним числом.
т.е пришел возврат 3 летней давности - надо пересчитать 3 года.

Да и заказчик хочет видеть всю ДЗ от самого начала.


3?) как вариант писать в таблицу СуммаДолга не на все даты - а только на те когда она менялась
(т.е когда были или отгрузки или платежки )
по кр. мере выходные тогда наверно исключатся
Но тоже вопрос - а потом они выберут дату по которой не было изменений - и получат пусто.

bideveloper,

Реализация похожих таблиц есть.
я писал про это в 1-м посте.

У меня не складывается картина в кубе

вопрос был про
1) агрегацию суммы долга (предположиетльно LAST )

2) + про общую картину.
Мне сдается что надо высчитвать суммы долга
для КАЖДОЙ даты в календаре без пропусков.
а это предополагает большие объемы данных

потому и спрашиваю есть ли варианты

alexdr,
СПС за ответ - идея понятна
но вот у меня как раз уже есть куб остатки
и там как раз остатки расчитаны уже на каждое утро
(а месяц назад появилось требование остатки на день - расчитал положил -и показал)
но ваш подход имеет место


Если не трудно ссылку на ту эпохальную ветку лпз почитать - ибо я не нахожу сразу ее