Добрый день!

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

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

Виртуальный признак я сразу отмел, т.к. при формировании отчета обрабатывается порядком 1 млн. записей, что сильно увеличит время формирования отчета. Поэтому пошел по пути зависимого от времени атрибута.

При загрузке основных данных сразу же наткнулся на такую проблему:
С инициализацией приходит запись
Key_1---01.06.2012---31.12.9999---Class_1
После этого в исходной системе изменяются данные (ограничивается срок действия классификации) и с дельтой приходит запись
Key_1---01.06.2012---30.09.2015---Class_1
В результате в основных данных вижу следующую картину:
Key_1---01.06.2012---30.09.2015---Class_1
Key_1---01.10.2015---31.12.9999---Class_1
что, по сути, эквивалентно предыдущему состоянию.

Конечно, можно синтетически добавить запись с 01.10.2015 по 31.12.9999 с пустым значением классификации, но считаю такой путь тупиковым, т.к. эта одна ситуация из сотен возможных, и все их обработать нереально.

Попробовал так же поиграться с новой настройкой для основных данных, поле 0recordmode

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

Учитывая вышеизложенное, прошу помочь в решении этой задачки.

Если вы собираетесь к финансовым документам добавлять некий признак, то от какого времени он будет зависеть?! Есть подозрение, что от даты проводки (или, например, от даты создания документа), а в этом случае никакими зависимыми от времени признаками тут и не пахнет. В этом случае можно признак на стадии загрузки рассчитывать.

Если же все-таки от даты проводки признак не зависит, а зависит действительно от некоторой контрольной даты, которую вы вводите с селекционного экрана, то говорить о том, что он привязан к финансовому документу некорректно. В этом случае непонятно о какой сотне возможных ситуаций идет речь?! Экстрактор для основных данных просто должен возвращать данные примерно в таком виде:
Key_1---01.06.2012---30.09.2015---Class_1---Active
Key_1---01.10.2015---31.12.9999---Class_1---Closed

Что касается виртуальных признаков и 1 млн. записей, то рассмотрим ситуацию, когда запрос возвращает 1 млн. записей (то есть после чтения из базы 1 млн. передается для обработки в OLAP) и предположим, что в отчете необходимо выводить ид. документа (что довольно странно):
ид.док Ид. признака
1 Key_1
2 Key_1
3 Key_2
4 Key_3
5 Key_2

Очевидно, что для разных фин. документов у вас повторяется ид. признака, а значит читать ид. признаков из DSO придется существенно меньше. Например, при соотношении 1:10 из DSO придется прочитать всего лишь 100.000 записей (если ключи сложить предварительно в хеш таблицу, то все 100 тыс. "форолэнтрятся" одним селектом)

От даты проводки не зависит. На примере покажу: финансовый документ это дебиторская задолженность, она имеет фиксированную дату проводки. А вот классификация это статус задолженности, например с 01.01.15 по 30.06.2015 - статус Мораторная, а с 01.07.2015 по 31.12.9999 - Судебная.

Ну например приходит запись с измененной начальной датой
Key_1---01.08.2012---31.12.9999---Class_1
или же с каким то пробелом
Key_1---01.06.2012---30.03.2015---Class_1
Key_1---01.07.2015---31.12.9999---Class_2
и т.д.
Тут фантазия пользователя безгранична, а функционал исходной системы позволяет делать такие вещи. Более того позволяет делать еще и с перекрывающимися датами
Key_1---01.06.2012---31.12.9999---Class_1
Key_1---01.07.2015---31.12.9999---Class_2
и такие записи приведут к прерыванию загрузки.
Все это усугубляется, тем, что САП не позаботился о создании стандартного экстрактора, а так же тем, что изменения нужно отслеживать в двух разных таблицах.

Записей будет 1 млн, т.к. классифицируется каждый документ

Мне непонятны проблемы, которые возникают при изменении начальной даты. Каким пробелом и где?! Непонятно

Ну так обеспечьте на стороне ERP необходимые проверки! Если пользователям разрешать вводить что угодно и как угодно в исходной системе, то никаких сил не хватит исправлять это в BW

САП позаботился о возможности расширять существующие экстракторы и создавать собственные.

Вы хотите сказать, что для каждого FI-ного документа будет строго уникальный KEY признака?! То есть признак FI-ного документа будет <= по размеру, чем признак с вашей классификацией (<=, так как он зависит от времени и на каждое значение ключа приходится несколько записей)?!

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

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

Да, именно так. В исходной таблице для каждого FI-ного документа записывается уникальный ключ.

Давайте все по порядку. Рассмотрим FI-документ. Ключом документа являются три поля BUKRS, BELNR, GJAHR.

Далее вы пишите
Из чего можно сделать вывод, что где-то есть справочник
KEY_1 Мораторная
KEY_2 Судебная
и т.п.

Теперь у вас должна быть таблица, которая связывает FI-документ со справочником. Предположим такой вариант
1000 0000000001 2015 KEY_1
Но, насколько я понял, каждый FI-документ может находиться в разных статусах. То есть таблица должна выглядеть примерно так
1000 0000000001 2015 KEY_1 01.01.15 30.06.2015
1000 0000000001 2015 KEY_2 01.07.2015 31.12.9999

1. Первый вариант, который напрашивается - в BW в признак FI-документа добавить навигационный атрибут, зависимый от времени атрибут "Статус задолженности" (ну или как-то там еще). Но этот вариант не пройдет, так как в признак FI-документ не включены признаки BUKRS и GJAHR в состав ключа (и включать их - зло). Таким образом этот вариант отпадает

2. Второй вариант - DSO и инфо-набор с временным соединением (я бы не стал так делать), но тут проблемы с производительностью будут скорее всего (особенно с учетом 1 млн. записей, хотя можно попробовать в качестве эксперимента, получится-нет - ХЗ)

3. Еще вариант DSO и виртуальный признак. (к вашему 1 млн. придется прочитать еще примерно 1 млн. записей).

4. Если же FI-экстрактор расширять и вычислять статус на стадии экстракции, то тогда FI-ные записи дробить надо - не вариант. Плюс надо добиваться, чтобы FI-ные документы считались измененными после правки вашей классификации

5. Если на стороне BW в загрузке соединять FI-DSO и DSO-классификации и формировать отдельный куб с детализацией до документа (не до позиции) и необходимыми признаками и показателями, то почему бы и нет

Короче: 3 или 5. Если третий не потянет по памяти, то тогда 5

Спасибо за варианты! Пошел думать....