Добрый день, коллеги!
Мучаюсь с такой проблемой: пытаюсь загрузить инициализацию по 2lis_03_BF. Во время когда происходит сбор данных часть документов не попадает. Не знаю как с этим бороться, т.к. это продуктивная система, работает круглосуточно. Слышал что есть настройка интервалов безопасности, но в нете не нашел информации по этой настройке. Уверен, кто работает с логистикой сталкивались с подобной проблемой, поделитесь пожалуйста опытом.
Спасибо

инициализация делается через 2lis_03_BX. А потом сбор дельты мат.движений и переоценок через 2lis_03_bf и 2lis_03_um .
На время инициализации не должно проводиться материальных проводок!
Есть варианты, когда данные можно снимать со стенд-бая, тогда останова продуктива делать не надо.
Документ " How to .... material movement " хорошо изучили?

Добрый день!
Спасибо за ответ. Документ я изучил. В моем случае 2lis_03_BX мне не нужен, т.к перешли на новую ERP в 2012году и остатки занесли оборотами 31го числа.
Вопрос мой вот в чем: нельзя остановить завод на 3 часа, она работает 7*24. Как быть в этом случае??? Примерно каждые 10 сек создается документ движения.

Лучше конечно придерживаться how to minimize downtime и снять все со standby, но если нет standby и фабрику останавливать не хочется, то можно применить еще один " творческий- рукоприкладный" способ .
Загружается инициализация дельты без переноса данных, получаем новый ежедневный поток 2lis03bf, ничего пока не сжимаем и т.д. дня через 3 оговариваем, что никто не проводит старые документы и сначала выталкиваем все из дельты очереди в куб,
удаляем из куба данные за первый день и ниже, затем спокойно собираем историю с удаленного дня и ниже, делаем загрузки full update, сверяем остатки по отчетам. Разрешаем проводить документы со "старыми" датами.
Сложно,много возни, но теоретически должно работать.

Проблему решили, была плановая остановка завода. Но метод интересный, надо будет попробовать.

Мой метод должен работать только без 2lis_03_bx, иначе how to minimize downtime ...

можно немного пораскинуть мозгами и сделать DSO с уникальной комбинацией ключей, то есть то, что в трансформации "сжимается" надо вынести в ключи DSO. далее поставить куб как обычно.
идея простая - проинициализировать без данных дельту по движениям, собрать историю, загрузить FULL с пометкой "исправление" данные в DSO, а затем накатить дельту. в таком сценарии ничего останавливать не надо.
это будет работать 100%

Все прекрасно работало без одс. Все тоже самое, только сразу напрямую в куб

да не будет все "прекрасно работать") потеряете что-нибудь и не найдете никогда. потом пойдете с бизнесом договариваться или вас отведут)

если ради разовой загрузки лепить вспомогательный DSO , хорошо это или плохо?
Что с ним делать после обновления опорных точек в кубе? Вы ведь не будете всю жизнь копить запросы в кубе в необработанном состоянии.
Я не знаю, корректно ли разрулит или нет DSO ситуацию с некоммулятивными показателями с исправительными запросами.
Если так все хорошо, то почему SAP не грузит BF через DSO?
Не получитется ли потом проблем X2 при сопровождении куба?
Тогда уж легче дейстовать по how to ... , будет на кого свалить

DSO нужен для инициализации без остановки R/3, дальше его можно не использовать, просто переключаете DTP напрямую в кубик после синхронизации DSO->CUBE