Здравствуйте, уважаемые!
Подскажите, пожалуйста, конструкцию в Query-запросе для такого случая:

В ПР описано множество строкк для отчёта.
Одна из них допустим строка 999 с таким алгоритмом:

"Анализируем документы, попавшие в строку 230
Отбираем из таблицы BSEG данные по следующим условиям - <здесь перечисление условий>. И заносим в отчет сумму BSEG-DMBTR.

строка 230 - итоговая и содержит в формуле много разных других строк.

Вопрос: как должна выглядеть конструкция для строки 999? Как в неё отобрать документы из 230 строки и затем применить к ним дополнительные условия?

Подскажите, пожалуйста.

Формулой. Предварительно настроить показатели, соответствующие, данным из другой таблицы. В формуле суммируешь требуемое. Технические показатели на уровне отчета можно спрятать.

fedo, что-то не понял про настройку показателей.
у меня 50 строк с разными ограничениями. Они отбирают разные документы. В конструируемой строке 999 я должен ВСЕ эти отобранные документы из 50 строк взять и к ним применить ещё доп.условия. и сумму вывести.

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

levi, а зачем это все в отчете делать? Разве такое ТЗ не подразумевает обработку данных на уровнях ниже (на уровне исходной системы в экстракторе, трансформациях ХД и т.д.)?!

Да, полагаю 50 ограниченных показателей в формулу и т.д.
Или действительно пересмотреть логику, можно ли произвести агрегацию на уровне хранения данных, но это тогда может помешать использовать чисто исходные данные, то есть на уровне документов.

12ozmdm, дело в том, что Проектное Решение могут изменить. Добавить какие-то новые счета, Виды документов и другие ограничения. Придётся останавливать продуктив, изменять модель и по-новой загружать десятки миллионов записей. Сделать изменения на уровне BEx проще. Ну.. моё мнение такое. Может, не прав)

Наверное, придётся делать как посоветовал fedo - через ограниченные показатели и формулу.

Но ведь наверняка такое ТЗ встречалось и как-то его реализовывали..

Поэтому я и говорю, что это тогда может помешать использовать чисто исходные данные, то есть на уровне документов.
Можно еще сделать так, грузить "чистые" исходные данные в bw. Создать дополнительные инфо-провайдеры и уже туда загружать модифицированные данные из самого bw. Таким образом, у тебя остаются и исходные данные на уровне документов, и данные сформированные для определенной предметной области.

Надо соблюдать баланс. От всех изменений не защитишся.

levi, вам приходилась работать с BSEG и вытаскивать из неё данные? Если нет - поищите на форуме инфу по этой таблице. Я конечно не знаю насколько у вас табл. BSEG большая, насколько критичен отчет и т.д., но тянуть её 1 к 1 в BW, а ещё и на всем множестве этих данных отчеты строить с огромным количеством показателей, это смутная затея.
Я думаю тут на уровне экстракторов ERP (возможно даже стандартных) и первого уровня объектов ХД нужно сделать основное. Или как выше предложил fedo.
Все это ИМХО.

По поводу подходов к построению ХД вообще, можно глянуть "Подход SAP LSA к построению хранилища данных и его составляющие"