Если в транзакции LBWE (в ERP-системе) для приложения логистики 03 стоит режим обновления "Дельта в очереди" или "Несериализавонное V3-обновление", то перед тем, как грузить BF-дельту из ERP в BW, нужно в транзакции LBWE (для приложения логистики 03) нажать на ссылку "Управление заданиями" и запустить фоновое задание, которое переместит дельта-записи из очереди логистики (тр. LBWQ - для "Дельта в очереди"; или тр. SM13 - для "Несериализавонное V3-обновление") в дельта-очередь для BW (тр. RSA7).

опечатка...
Правильно так: "BX грузит то, что собрали в транзакции MCNB"

У меня снова возник вопрос. Теперь уже по UM. Проверяю транзакцией RSA3 2LIS_03_UM, получаю 0 записей.
Делаю все по How to... - Источники активировал, установочные таблицы почистил.
Запускаю Inventory Management - Perform Setup -> Revaluation, заполняю поля Company Code, Name of run, Termination date.
Запускаю, выполняется моментально. Возвращает 0 записей. Key Figures активировал.
Подскажите пожалуйста, в чем дело?

а данные по такой Company code в таблице bseg есть? А не слишком ли скорое время прерывания Вы ставите?

База тестовая, по данной Company code в BSEG 74 записи. Время прерывания сутки.

Прошу помощи! Очень нужен совет, как заполнить 2LIS_03_UM?

А в R3-шных транзакциях переоценки эти видны? А BF нормально собирается?

Lench, спасибо за ответы!
BF собирается правильно. Подскажите, как увидеть переоценку? Может я неправильно ее оцениваю.

Точно уже не помню, возможно в транзакции MB52 можно посмотреть, или MB02(Кнопка RW - фин.док.)
А сборщиком пользуетесь OLIZBW?

Переоценка есть, OLIZBW запускаю, но транзакция отрабатывает моментально

В OLIZBW по привычке на автомате указывал неверный завод... Прошу прощения, идиотская ошибка.
Lench, спасибо за поддержку!

Какие слова... супер, блестящая мысль

Уточню - при сжатии записи "схлопываются" по признакам куба + по ID запроса. То есть если в кубе XXX в таблице фактов /BIC/FXXX было 3 загрузки и хранится что-то вроде
Номер запроса, Завод, Сумма
1, 1000, 100
2, 1000, 100
3, 1000, 1
то после сжатия таблица /BIC/FXXX станет пустой, а в /BIC/EXXX (таблица сжатых данных) появится одна запись -
Завод, Сумма
1000, 201

Таким образом, очевидны 2 вещи: первая - что сжатых данных может быть в разы меньше, особенно если в куб данные грузятся давно и по одним и тем же комбинациям признаков, и второе - что сжатые запросы нельзя откатить из куба (в моем примере - как мы можем удалить, например, запрос 3 после сжатия? Ведь истории-то уже не сохранилось). Еще можно ставить при сжатии галку "со скрытием нулей", тогда дополнительно удаляются записи, в которых все показатели = 0.

После Compression удалить данные по ID Request'a уже нельзя. Но что делать, если в отчеты попадают данные из ошибочного Request'a. Раз нельзя сделать Delete значит можно попробовать Reverse Posting (Проводка Сторно). Для того, чтобы это сработало необходимо наличие данных Requests в PSA.
В BW Monitor Update/Reversal => Request Reverse Posting.
И в отчете, мы получим после того как сторнировали запись 3-го Request. [Появится доп. запись = 1000,-1, Происходит умножение KF на "-1"]:

Завод, Сумма
1000, 200
Для non-cumulatives KF данный прием не пройдет.

Почему же нет? Если будут сторнированы Поступления и Расходы которые не некумулятивные, изменения распространятся и на сам некумулятивный KF