Первые два способа известны всем консультантам, которые используют ABAP и зачастую они не дают результатов. Третий способ наиболее интересен и полезен, но и он не покажет всех точек входа. Одним словом название статьи соответствует наполнению, за что и получает высокие балы.
Есть полезные советы, но манера написания не понравилось. Как-то скомкано и как-будто без плана.
Не заметил в тексте на каком этапе происходит определение порядка загрузки данных. Не описана проблема ведения двух систем, при переходе это обычно случается. Проблема \"устаревания\" данных за время перехода на новую систему.
Полезность статьи для меня низкая, потому что я уже с этим работал. Но для тех, кто видит это впервые, непомешает добавить настроек для “Frame Program for Periodic Data Transfer”, но это не критично.
Статья оставила двоякое впечатление: начинается как неплохая \"вводная\" статья, а заканчивается \"тонкостями и хитростями\". Ощущение, что 2 статьи слилось воедино.
Вторая часть показалась интересной. Но, боюсь, в 90% случаев в продуктивной системе LSMW используется как средство загрузки после общей отладки в тестовой системе. Т.е. \"навороты\" излишни.
Крайне полезной для меня оказалась статья, все очень подробно и грамотно расписано. Хотелось бы еще описание ситуации не только последовательного изготовления на разных заводах, но еже и при возврате полуфабриката на исходный завод: завод1 -> завод2 -> завод1.
спасибо за статью.
абзац ШАГ2 я бы немного скорректировал для лучшего восприятия читателем:
Шаг 2.
(Общее описание процесса)На втором шаге выполняется вызов программы периодического переноса данных и сохранение варианта экрана выбора для объекта LSMW, который требуется выполнить.
(Наименование объекта) Техническое имя программы периодического переноса данных LSMW – /SAPDMC/SAP_LSMW_INTERFACE
(Детализация процесса): Вызов этой программы в целях данной статьи осуществляется на экране настройки LSMW “Frame Program for Periodic Data Transfer”. (рис.3)
(Указание конкретного действия) Создайте вариант экрана выбора для программы периодического переноса данных, для этого сохраните вариант экрана выбора с помощью кнопки “Save” в верхней области экрана. В результате откроется экран “Variant Attributes” (Рис. 4).
В принципе описано все понятно и доходчиво. Единственное, на что не обратили должного внимания, так это \"Activity Update Relevant to Price Determination = 2\" (т.е. ведение фактического тарифа работ в регистре материалов). В этом случае нарушается принятая последовательность закрытия периода в контроллинге, т.к. переоценка производственных заказов по фактическим тарифам не происходит, что соответственно ведет к тому, что по заказам отражаются только нормативные затраты по работам.
Основная цель, для чего используется повторная оценка НЗП - это предотвращение зависания многоуровневых отклонений по потребленным полуфабрикатам на производственные заказы, оставшиеся в НзП, а для данных целей совсем нет необходимости вести фактические тарифы работ в регистре материалов.
Рекомендации понятны. И скорее всего, действительно имеют место быть. Но, они как-то все вокруг ведения основных данных: пункты 1, 2, 6, 9 и 10 - это по сути все о ведении основных данных.
Пункт 3 - это понятно, но слишком очевидно чтобы быть дельной рекомендацией.
Пункт 5 - по сути частный случай пункта 3.
Пункты 4, 7 и 8 - рекомендации относительно производительности. Это полезные рекомендации, особенно для тех, кто не имел опыта продуктивных эксплуатаций.
К сожаление не описано ничего касательно именно самой функциональности SNP. Видимо это было за рамками того, что автор хотел описать в статье, но тем не менее - это по сути именно то, ради чего ставят АРО. Систему не ставят чтобы озадачиться ведением основных данных или оптимизацией быстродействия. Основная задача SNP - оптимизация долгосрочного и среднесрочного планирования. А особенности и рекомендации именно применение оптимизационных алгоритмов APO в данной статье не описаны.
Стаья написана достаточно простым и понятным языком. Понравилось, что заострено внимание на важных моментах процесса. Хорошо проиллюстрирована.
Хотя на практике такая необходимость встречается редко, но знать подобные возможности полезно.
Конечно в период кризиса все хотят уменьшить свои расходы и экономят на всем, это не новость. Только по-моему опасно отказываться от обновлений, которые содержат изменения в логике работы программы в соответствии с изменением законодательства.
Первые два способа имеют право на существование, но в моей практике ни разу не использовались, т.к. при изменении бизнес-логики приложения очень часто нужно знать не все BADI/USER-EXIT\'ы которые имеются в программе, а только те которые будут относиться к какому-то событию. Для этого больше всего подходит способ \"Поиск BAdI при помощи трассировки SQL\", но у него есть огромный недостаток, это наличие прав на запуск ST05. На некоторых проектах в которых участвовал я, базисники отказывались давать права на ST05. В таких ситуациях помогало наличие прав на запуск отладчика(у ABAP-разработчиков они практически всегда есть). На примере который привел УСМАН необходимо запустить отладчик(/h или /hs), непосредственно перед нажатием кнопки \"save\". Потом нажимаем кнопку \"save\" и в отладчике нажимаем F9 и вводим CALL CUSTOMER-FUNCTION для остановки на всех USER-EXIT\'ах и F9 на вкладке Method вводим
Class name: CL_EXITHANDLER
Method name: GET_INSTANCE
и нажимаем F8. Теперь мы будем останавливаться на каждом расширении и можно будет изучить передаваемые в расширение параметры. Так проще найти BADI, которые лучше всего подходят, для данного случая. Есть и другие способы, но использование отладчика помогает решить 90% проблем с поиском расширений.
Интересная статья. По сути небольшой и очень простой проект с технической точки зрения, т.к. нет интеграции с другими решениями, а для крупных проектов это почти всегда необходимо; также довольно простой воркфлоу без кучи согласований \"всех со всеми\":). В общем, почти Best Practice.
Комментарий от
Евгений Лифиренко
| 17 июля 2010, 19:21