Привет.

Занимаюсь инициализацией 2LIS_03_BX, планирую задачи через MCNB. В общем, всё плохо. Инициализация выполняется долго, и, что хуже, точное время предсказать невозможно. Пожалуйста, ответьте на вопросы.

1. Как правильно поставить задачи в несколько потоков? Сейчас делю по заводам. Но время получается неравномерное. Попробовал оттолкнуться от количества записей в MSEG для данного завода - всё равно. В любом случае, мониторю вот потоки - один что-то делает, другие просто ждут анлока от таблицы.

2. Нужна ли кнопка "new run" ("новый прогон") при параллельной обработке?

3. Достаточно ли перед прогоном почистить LBWG, application 03 или нужно что-то ещё?

4. Правильно ли я понимаю, что если окно для инициализации остатков нужно слишком большое, и бизнес не может предложить такое окно, то SAP предлагает в такие компании модуль MM на BW не внедрять?

P.S. Кстати, скажите мне, а зачем вообще нужна вот эта штука, и почему нельзя было перенести всё это на BW? Почему нельзя было сделать нормальную систему, которая перекачала бы проводки из MSEG-MKPF, обработала их бы на BW, и дальше просто качала бы по метке времени? Почему нужно планировать задания которые валятся в дамп, потом непонятно как собирать дельту, ставить кучу неочевидных галок в мутных транзакциях, шаманить с бубном? Может, есть какие-то люди которые просто написали Z экстрактор по движениям и отказались от 2LIS?

читаем RTFM How To…Handle Inventory Management Scenarios in BW. Обратите внимание на выделенный текст.

Initialization of the current stock (opening balance) in the R/3 source system with
DataSource 2LIS_03_BX (transaction code in R/3: MCNB). For example, you can
make restrictions to materials or plant, providing not all balances are relevant. This
provides also the possibility to schedule the report several times. In such cases the
data is added to the setup table MC03BX0SETUP.5 Note: No material postings must
be carried out during this process, since material movements influence the current
stock. This run is not very time-intensive because the system does not read the
individual documents from the very large MSEG table. Instead, it accesses the
substantially smaller tables MARC, MARD and so on. Only if you use the option
"Zero stock to be transferred" runtime increases rapidly.

п.4. Очень маловероятно. В сети есть презентация, когда данные остатков снимаются со standby, при этом бизнес во время инициализации работает в online.
Давай еще уточним методологию. Модуль MM и BW совсем разные модули, и лучше если они находятся на разных серверах. В модуле BW есть кубы материальных движений, которые можно использовать дополнительно. Целью использования такого куба - получение отчетов за большие периоды времени, которые в R/3 в модуле MM получить практически невозможно.

п.P.S. Да нормально там все. Во первых, в BW не нужны все проводки, а только сжатые итоги по дню, т.е. данных уже получается значительно меньше. Во вторых, там достаточно простая программа переноса, изучить ее не сложно, суть такая, что количество и сумма по виду движения передается в разные показатели BW.
Почему нужно планировать задания которые валятся в дамп - c дампом надо разобраться, может нот каких либо не хватает.
С неочевидными галками - согласен, SAP надо перевести на русский язык How to ...
потом непонятно как собирать дельту - с дельтой там все хорошо , поддерживается повтор дельты, что очень полезно в аварийных ситуациях. Не каждый экстрактор для BW имеет повтор дельты. Метки времени там тоже используются.
просто написали Z экстрактор по движениям и отказались от 2LIS - это очень плохой путь. Расширить стандартный экстрактор можно, а вот переписать - зачем??? Не вижу смысла, честное слово.

Я вас не очень понял.

У нас "This run is not very time-intensive" занимает, по факту, 13 часов, а иногда - 15 часов (планировали, тестировали). А бизнес даёт ночное окно в 8 часов. То есть, в документации написано [censored], реальность документации не соответствует.

Кстати, качать в BW что-то сжатое, по опыту, означет создать себе кучу и кучу гемороя. Потому что в один момент у вас не сойдутся данные по отчёту и по исходным данным, и вы ничего ни с чем не сможете сверить. Найти, где ошиба (в отчёте, не загрузились какие-то данные, или функциональщик отчёта просчитался) можно только сверив по первичке. Не имеем первички в BW - нет возможности сверить - боль, унижение, взаимные упрёки, ад. Плавали, знаем.

Ну конечно лучше иметь максимально подробные данные. Но мы, в аналогичных ситуациях (с агрегированными данными) сначала находили день когда произошло расхождение и основные измерения. А потом сравнивая дельту и первичку угадывали в чем может быть расхождение. Иногда доходило до дебага - но удовольствия, конечно, мало.

Опция "Zero stock to be transferred" установлена или нет?
Если такая опция установлена, то время выполнения увеличивается многократно.

По поводу сжатия - логика cжатия идет от структуры куба. Если никому в анализе не надо номера первичных документов, то зачем их туда тащить?
Создавать на стороне BW вторую R/3 только для целей отладки?

"отчёту и по исходным данным, и вы ничего ни с чем не сможете сверить. Найти, где ошиба (в отчёте, не загрузились какие-то данные, или функциональщик отчёта просчитался) можно только сверив по первичке. "
Какие то панические настроения - есть PSA , куда все попадает из R/3, есть монитор качества в BW, в котором все прекрасно видно про ошибки передачи. И зачем рыться в первичке, если итоги по дню не идут?

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

Галка о нулевых запасах не стоит. Всё, больше предложений нет?

Нота 728360, а также, как вариант:

If the runtime of the RMCBINIT_BW report is too long, even with restriction of the plant (for example), you can also use the following workaround:

- Do not use 2LIS_03_BX (this is possible if all material movements are in the source system)
- In this case, execute a delta initialization for 2LIS_03_BF/UM
- You have the option of compressing this request with an update of the stock marker
Then load delta movements/revaluations
- You then have the option of compressig this request with an update of the stock marker

Хорошая идея, времени много не займет, потом потихоньку догружать историю.

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

В транзакции MCNB задаётся "имя прогона", "Name of run". Так вот, оно должно быть уникальным, или процессы не побегут в параллель между собой.

Дело в том, что оно пытается писать в таблицу MCSLOGDIR и если два процесса начнут туда писать одно и то же, они сдохнут. Такая ситуация не наблюдается, если процессы стартуют не в одну секунду, но проблема в том, что они часто стартуют в одну секунду из планировщика.

По умолчанию имя прогона заполняется именем пользователя. Добавьте к нему цифру, например.

Об этом написано в самих курсах TBW42_1 (думаю, что в 350 тоже есть), причем, с картинками:

The initialization is set up from the OLTP side. A restructuring fills
restructuring tables that are then read during initialization. In order to enable
the restructuring to be restarted after termination, assign a name to each
background run of a restructuring. If a restructuring terminates then or when
a restructuring from archived documents is to be terminated, the status of the
restructuring is saved under this run name. When there is a restart with the
same name, you continue from the saved intermediate status. After a run has
terminated successfully, the saved intermediate status is deleted.

Там и другие вопросы снимаются, если внимательно прочитать

(вздыхая) у меня такое ощущение, что я читаю как-то по-другому.

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

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

(вздыхая) у меня такое ощущение, что я читаю как-то по-другому.

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

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

Что же тут непонятного! Предположим, что вы запланировали два задания с одинаковым именем прогона - одно разграничили по заводу 1001, а другое по 1002, указали время терминации - например, вам отвели окно в 8 часов. Если одно из заданий будет прервано по терминации, а другое корректно завершено, то как вы запустите прерванное, если имя прогона у вас было только одно?! Следовательно, имя прогона должно быть уникальным

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

Я, например, вообще пока не очень понимаю смысл терминации. Если после отмены задания по таймауту будут проведены проводки, то разве есть смысл его продолжать?

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