В ODS будут данные, хорошо. Дальше с ними что делать?

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

А потом бац, поменяли поставщика задним числом у одного из материалов.

Если непонятно, могу картинку нарисовать.

несколько уточнений в ЛС

Я прямо тут отвечу на ЛС, там были вопросы по модели данных.

Есть куб с движениями материалов, среди прочих в кубе есть признаки 0MATERIAL, 0PLANT и 0COMP_CODE. Но вот 0MATERIAL создан без compounding с ними, то есть просто, сам по себе.

Сейчас у материала 0MATERIAL есть атрибут 0VENDOR, в который закачиваются поставщики. Если у какого-то материала меняется поставщик, это тотчас отражается во всех отчётах, что и требуется. И вот, "внезапно" оказалось, что нужно чтобы у материала был поставщик, который должен был бы зависеть еще и от завода 0PLANT.

Теперь, поступило задание. Озвучу:

* Связка Завод-БЕ-Поставщик-Материал берётся из таблицы EORD на источнике (для этого был написан отдельный экстрактор).
* Эти данные - времязависимые. Пока известно, что данные там сильно кривые. Поэтому, нужно чтобы поставщик просто брался из помеченого галочкой. Если галочку поменяют, данные в отчётах должны поменяться задним числом.

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

а если вирутальным признаком его считать на основе комбинаций, загнанных в dso? тока скорострельность будет не очень.. и если по нему ринутся фильтровать - трындец будет...

Есть хороший мануал по виртуальным признакам?

Я не очень представляю, как виртуальный признак, какой-нибудь ZVENDOR может "узнать" о значениях 0PLANT в запросе.

Вижу на вскидку 3 варианта
1. Как уже было сказано, грузить комбинации в dso, делать в кубе с запасами виртуальный признак. Мануал Implementing Virtual Key Figure or Characteristics Makes Query More Dynamic + на форуме уже обсуждалось
2. Грузить комбинацию в признак, какой-нибудь zmatplant с compound 0PLANT и атрибутом 0VENDOR зависимым от времени. Прийдется перегрузить данные, например через временный куб
3. Сделать инфо-набор для вытаскивания 0VENDOR из dso. Минус - отчет переделывать на инфо-набор

Первый вариант - понятно, ABAP, писанина.

Второй вариант - настроить ZMATERIAL как копию 0MATERIAL. С учётом того, что уже существует 0MATERIAL, придётся настраивать копирование основных данных, атрибутов, иерархий и текстов в признак, т.е. фактически дублировать всё, что уже есть. Кроме того, добавлять данные в куб, и перегружать их, но это можно. Хотя, конечно, модель данных получается дублированой и кривоватой...

Третий вариант - что такое инфо-набор И чем это грозит ?

2. Все перегружать не нужно. Не нужны тексты, не нужны иерархии, не нужны атрибуты кроме 0Vendor. загрузку атрибутов делать из EORD
3. Ну неприлично такие вопросы задавать... В вашем случае Инфо-набор = Select a.* b.vendor from куб a, dso b

Так, в третьем случае нам потребуется отчёты перенести на этот инфонабор?

Если отчеты были сделаны на мультике, то нет, вместо куба просто потребуется присоединить инфо-набор и переделать идентификацию признаков мульта. Если на кубе то да, потребуется переносить на инфо-набор. Хотя тут может помочь транзакция RSZC

"Инфонабор не поддерживает инфокубы с некомулятивными значениями". Там есть запас с приходом и расходом, и, похоже, вариант с инфонабором работать не будет.

в кубах используется только признак Материал? или там есть ещё завод, бе, вендор? в запросах для отчетов опять же данные тянутся с атрибутов или с признаков?

Я так понимаю, что сейчас в кубе и отчетах есть только материал, завод, бе как признаки. Тогда:

Если я правильно понял постановку задачи, можно создать ZVENDOR в котором соединение будет с заводом, БЕ и материалом (можно и время) и включать один атрибут 0vendor, залить туда корректные связки БЕ - завод - материал - вендор, (при этом вендор будет не ключем и его можно будет менять) . В куб добавить ZVENDOR и записать его на трансформации самого себя учитывая логику записей в кубе и тех ключей, которые введены в основных данных ZVENDOR. в квери теперь надо будет тянуть атрибуты вендора не с материала, а с zvendor, который будет включать в себя обычного вендора.

Не стоит городить огород, есть стандартный признак 0MAT_PLANT (атрибуты грузятся из табл. MARC). Добавить туда навигационный атрибут 0VENDOR, заполнять его "постоянным поставщиком" или по любой другой логике по бизнесу.
Сделать новые кубы, вставить в мультики. Если перезагрузка невозможна, то можно предусмотреть в отчетах двух поставщиков из материала и из материала-завода, разыменовав их в текстах. Поставщик из материала-завода будет в данных только с опред. времени.
С некуммулятивным кубом так не получится, только перезагрузка данных.
Судя по всему у вас retail. И то, что у вас сейчас возникло - это ошибка проектирования модели данных. Если модель проектировал консалтинг, то услугами такого подрядчика лучше больше не пользоваться.

Интересно - какое в итоге было принято решение и как этот запрос бизнеса был реализован?

З.Ы. Вообще я бы сказал, что можно анализировать компаунд значений материал-поставщик-завод, а можно говорить о том, что если у нас разные поставщики, то мы считаем материалы разными, а для целей анализа по взаимозаменяемым товарам (нам не обязательно интересно вместе анализировать только полностью одинаковые товары) используем либо дополнительный атрибут группировки, либо иерархию. Или нет?