Добрый день!
Вопрос в следующем. Появилась необходимость создать новый отчёт в Query Designer, обратился к аналитикам в своей компании, они сказали что сделать это невозможно, поскольку данные, которые мне необходимо свести в этом отчёте относятся к разным инфопровайдерам. Насколько, мне хватает моих знаний в SAP, то получается что вся информация о клиентах (название, телефонный номер, активности выполняемые по клиентам) транслируется из системы CRM, а информация по заказам на этих клиентов выводится уже из ERP. Из-за этого и возникают проблемы с объединением данных!
Эту проблему вообще можно решить, а главное как?
Заранее спасибо за ответы.




P.S заранее извиняюсь за возможно ломаный язык изложения в SAP я не профи, просто стало интересно

Хранилище данных нужнО ровно для решения подобных задач.
Т.е. построить запрос можно. Но есть нюанс. Видимо, его Ваши аналитики и имели ввиду.
Речь идет о гомогенизации данных. Дело в том, что в разных системах одни и те же аналитики могут иметь разные названия, ключи, длины ключей, разную группировку и т.п. Т.е. в CRM клиент может иметь номер 000001, а в ERP FIN00110002123. Бывают более клинические случаи. Например в CRM работают с понятием "клиент", а в ERP "юрлицо", понятно, что у клиента может быть несколько юрлиц, а теоретически даже у разных клиентов может быть одно юрлицо.

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

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

...жесть

наверное у нас обучающие гуманее были .. просто сказали НЕЛЬЗЯ

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

А если раскрыть немножечко вопрос, то в чем именно проблема здесь: в консультантах, или в самом подходе "запрос на кубе"?
Если в самом подходе, то что в нем не так? И на чем тогда нужно строить запросы в таком случае, исключительно на признаках, инфоисточниках и ODS?

Проблема в подходе. И, наверное, невысоком качестве реализации транзакции RSZC.
Запросы нужно строить на мультипровайдере (я делаю исключение только для признаков, ввиду того что на них запросов мало и они очень простые и УА, ввиду того, что сами УА над мультипровайдерами).
Это связано с постоянным уточнением требований и корректировкой технической реализации, т.е. такая настройка является более гибкой.

G, идею понял, спасибо.

А что такое УА, хотелось бы уточнить, если можно.

Уровень агрегации

А где можно почитать про создание мультипровайдера подробнее?

Курсы 310, 330.
Вот эта дока будет полезной:
SAP Merchandise and Assortment Planning on BW Integrated Planning. Best Practice Guide for Performance tuning.

Большое всем спасибо за советы. Будем учиться))

Если есть отдельные самостоятельные кубы и в отчет не надо данных с других, то почему нельзя строить отчеты на них. Иногда даже надо.
RSZC я пользовался может всего 1 раз когда то.
А засовать все в мультик, считаю нехорошей идеей.
Пример надо получить остатки/приходы/возвраты/доход и т.д. по контрагентам за год. Представили мультик остатки по дням+ торговля по дням+документы в ритейле и как быстро он будет работать. ИМХО Надо по потребности.


Дилетант-самоучка.

Мультик - это ракурс данных, построение отчетов именно на нём практически не сказывается на быстродействии, а скорее всего и вообще не сказывается. Но если вдруг в будущем придется добавлять в отчет какие-то аналитики, а их в кубе не окажется - вот это огромная проблема, а если отчет на мультике то все отлично, подтянул туда данные из ещё одного кубика и отчёт готов.

Не надо .
И вопрос не в копировании между кубами RSZC и даже не столько в быстродействии.
Вопрос в том , что многое начинают ваять показатели прям на кубе ... потом при внесении этого куба в мульт , что как сказал уже Artyb необходимо для просмотра данных в нескольких ракурсах - вот тогда начинаются вопросы !