версия 4.6с
support package SAPKA46C46.
Вопрос в следующем: при активации РМ история по производственным заказам за предыдущий период не отражается в РМ, не знаете ли вы какой нотой лечится эта трабла?

и плиз еси хто недавно подыскивал полезные ноты для РМ не могли бы вы их написать

никакой, смиритесь

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

Уточним!

Вы в этом месяце активировали РМ и что-то там за прошлые месяцы пропало?

Или Вы юзаете РМ уже несколько месяцев и что-то там не сохраняется?

И какая информация за прошлые периоды Вам нужна, чтобы осуществить закрытие?

да, история заказа до момента включения РМ, по типу того что нельзя закрыть заказы к-ые работали в предыдущем периоде... ну типа того что активировали в 7 периоде а закрываем 6 период

в информационной ноте 596558 нашел следующее изречение:

перед продуктивным запуском закройте все проиозводственные заказыи и создайте новые после активации РМ.


Типа того что незакрытые заказы не будут участвовать при многоуровневом исчислении. (:

нашел интересную ноту 353293 "Summarization of purchase order history with active ML" (транза МЕ87), то биж суммирование истории заказов на закупку, то есть я так понял что для заказов на закупку нужно запустить некую бадягу чтоб история заказов ДО активации и ПОСЛЕ соединились, а про РР-заказы никто ниё не слышал?

неужели так мало народу у кого активен Регистр материалов и факт.калькуляция?

наверное вот ответ на мой вопрос, заказы нужно пропустить через программку ZMLCCS_KO88_TREATMENT (Корректировка истории заказов)...

да блин....не помогло , как и прежде вылетает сообщение при попытке расчёта заказа НЕПОЛНАЯ ДИНАМИКА ЗАКАЗА со ссылкой на ноту 363601

совсем я запутался, может поможите советом: вообщем наткнувшись на ноту 363601 с последним изменением от 03.06.2005 обрадовался что вот решение моей проблемы, создал программу ZMLCC_KO88_TREATMENT , пропустил через неё пару закзаов - ни фига...

нахожу другую ноту 458592 и там в Corrections instructions нахожу ту же самую программу ZMLCC_KO88_TREATMENT но с другим текстом программы, попобовал этой программой восстанвоить историю - получилось, заказ рассчитвается вроде все нормально, но там released дата 06.08.2002, в в ноте 363601 Released 01.03.2004 , получается старая версию программы отрабатывает а более новая нет, ёлы палы... кто нить чё нить может подсказать? может я чё в нотах не догоняю?

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

мда...хорошо одному постить...
ну ладно задам ещё один вопрос:
на этапе 1-уровненвого исчисления ошибок нет но обновление прерывается и доставкой в личный ящик тучи экспресс-сообщений, не могу понять откуда ноги растут у проблемы?
на дворе физически 10 период, закрываю 9.

Главное было ж всё нормально, делал 1-но уровневое, многоуровневое, заключю проводку, потом сторнировал, работал с 8 периодом, потом 8 закрывал (принудительно естественно), возввращался к 9 периоду и тут вот полезло.... у 8 периода статус ЗАКЛЮЧИТЕЛЬНАЯ ПРОВОДКА ПРОИЗОШЛА

to doctor
Ну, чтоб ты не постился тут один, решила написать
У тебя в сообщениях что именно пишет? Случаем не нумерация документов СО поехала? У меня раз немного похожая ситуация была, правда при расчёте заказа, расчёт выполняется, но документ не создаётся и сообщения в почту приходило. Если что-то подобное - напишу как я справилась, если нет – извини

не, пишет что ОБНОВЛЕНИЕ ПРЕРВАНО и куча экспресс-сообщений по каждому материалу прогона, хоят ошибок нет, видно обновление статуса не разрешает. но почему?

Вот-вот у меня тоже было обновление прервано. Может всё же в документах дело?
Попробуй глянуть в тр. kank (диапазоны номеров) к какому интервалу относиться калькуляция, далее зайди в изменение статуса и измени текущий номер на больший.
Ну и ещё на всякий случай в тр. snro (хотя тут вряд ли у вас кто трогал) можешь посмотреть объект rf_beleg в «буферизации в ОЗУ» галка стоит и число номеров хорошо бы 100 (или больше)