К сожалению или к счастью пользователям практически никогда не выдают полномочий на транзакции SE*, поэтому для конечного пользователя статья вряд ли актуальна, а для консультанта работающего в области логистики, это узнается на первых шагах работы с ОЗМ и автоматической настройки выбора счета при движении материала.
 
Мое мнение для конечного пользователя более интересно было бы задав материал, класс оценки материала или группу материалов, получить информацию какие счета и для каких операций будут использоваться,а это стандартными средствами сделать нельзя, поэтому в свое время для конечных пользователей и различных проверяющих/аудиторов был написан небольшой отчет, который по группам/классам оценки и т.д. позволял получить информацию по присвоенным счетам в понятном разрезе.

Решение описанное в статье не учитывает такую вещь как несколько инстанций (серверов приложений) при подключении к серверу базы данных, что в принципе возможно и бывает (при использовании SolMan возможно реже), а при такой ситуации данный метода может давать не верные результаты, так как для нумерации скорее всего включена буферизация (без нее возможны проблемы производительности и конфликты при доступах к таблице интервалов). При включенной буферизации каждая инстанция берет по диапазону номеров в момент старта в локальный буфер и выделяет номера по требованию подключенных клиентов. Обычно буферизация настраивается на 10 номеров, следовательно имеем картину:
1 инстанция получит номера: 0001 - 0010
2 инстанция получит номера: 0011 - 0020
При запросе номера, по первой инстанции будет сгенерирована заявка с номером 1, а при запросе номера по второй инстанции будет получен номер 11. При этом если пользователи первой инстанции более активные, то их диапазон исчерпается раньше и они получат новый в интервале с 0021 - 0030, так что уже имеем погрешность в среднем на величину размера локального буфера номеров для инстанции. Далее при перезагрузке системы не использованные номера не возвращаются, т.е. система зафиксирует последний используемый номер, пусть это будет 0030 из первой инстанции, а во второй пусть были выбраны только 5 номеров с 0011 - 0015, так вот при загрузке инстанции получат номер с 0031 - 0040 и с 0041 - 0050, т..е. каждая получит по следующему десятку номеров.
 
В общем виде, я бы считал номера заявок используя SELECT COUNT(*) FROM <таблица> WHERE <Условия> в с каком-нибудь отчете. Все остальные способы исходя из реализации работы с диапазонами номеров в SAP, будут давать погрешности в оценке количества документов/записей.

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

Статья неплохая, но читается сложно.
Так же, было бы целесообразно, указать, какие из описываемых методов есть в ECC (как было замечено в комментарии ранее).
 
Как ни странно, в ECC возможно практически все, что описано выше используя стандартную функциональности или минимальные доработки.
 
1) Фиксированное количество страхового запаса так же поддерживается в ECC. Для этого необходимо просто указать поле Страховой запас (MARC-EISBE).
 
2) Обеспеченность запасами поддерживается в ECC. Для использования необходимо указать в поле "Страховое время/ФактОборЗап"(MARC-SHZET) в рабочих днях. Так же необходимо используя индикатор Страховое время(MARC-SHFLG) указать, какая потребность будет "отодвигаться" - первичная или все. Кстати, данная возможность не описана. Не думаю, что это нельзя реализовать в APO.
Альтернативно, можно использовать профиль страхового времни (MARC-SHPRO), который можно использовать для того, чтобы задавать страховое время с привязкой к жестким периодам по датам.
 
3) Максимальное количество из фиксированного количества и обеспеченности запасами. Данного метода в ECC нет.
 
4) Страховой запас, как прогноз/потребность. Данный способ можно так же аналогично реализовать в MRP. Например, используя ведение дополнительных первичных потребностей по данному материалу в отдельной версии. Это вообще универсальный способ сделать практически любую модель, т.к. всегда можно написать АВАР программу по формированию данной потребности по любому алгоритму, и просто запускать ее перед кажжым запуском ППМ.
 
5) Статистический метод. В ЕСС можно так же использовать уровень сервисного обслуживания (указывается в ОЗМ поле MARC-MARC-LGRAD - уровень обеспеченности поставками) используя который на основании исторически-прогнозных данных может рассчитываться страховой запас.
 
6) Гибкое, экономически выгодное поддержание запаса. Очень похожая функциональность есть в ЕСС - в ОЗМ можно указать профиль динамической обеспеченности (MARC-RWPRO), который так же определяет методы расчета средней дневной потребности и уровни поддержания запаса в днях. Чего нет в стандарте - это учета количество дней распределения страхового запаса. Но мне кажется, что похожего результата можно добиться "играясь" имеющимися настройками.

Никогда бы не стал искать решение в пользовательских параметрах. Для этой цели (только в контроллинге) как то делали вариант транзакции, в спецрегистрах писали query, а для пользователей попроще писали инструкцию по обраoению с динамическими условиями выбора.
Жаль, что описан только вариант с платежами. Поиск по пользовательским параметрам в SU3 с выборкой по запросу *date* выдал 76 вариантов, надо копать, наверняка найдется что-то подходящее

Не знаю ни одного внедрения (по крайней мере в России), где бы функциональность IM вошла стандартном. Планирование без разбивки на кварталы-месяцы общая беда всего модуля IM, а уж заявок и подавно. Сложно докопаться до формул расчета эффективности, изменить стандартом тоже нельзя (бесспорно, это неверно с точки зрения методологии, но хотя бы расширение на этот счет не помешало бы).
Не зря данный функционал считается динозавром и вместо него предполагается исопльзование cProjects,cFolders, XRPM.

Интересно, хотя с российской спецификой это вряд ли пригодится.

Полезно было просмотреть. Аналогичное есть в MM (по материалам тр. MM17) и PS (тр.CNMASS).

Достаточно полезная информация, особенно для консультанта поддержки.

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

Автор описывет использование функции IF в схеме расчёта, приводит понятный пример.
Знания, нужные любому консультанту.
 
Я бы добавил, что в конструкции IF ENDIF можно использовать функцию ELSE для случаев, если условие IF не выполняется.
IF ZE33
ACTIO Z001 *ZE33 вернуло T
ELSE
ACTIO Z002 *ZE33 вернуло F
ENDIF
 
Действительно, очень удобно использовать IF и вложенные конструкции IF-ELSE-ENDIF.
 
Мощную функцию IF можно использовать еще для такого интересного решения - мы знаем, что схемы расчёта не имеют временной привязки как, например, виды оплат.
Однако в течение года у нас может меняться бизнес логика и соответствующая обработка в схеме.
Возникает задача как обработку в первой половине года сделать по одному алгоритму, а во второй - по другому?
 
Для таких случаев можно использовать таблицу констант расчёта T511K и завести в ней константу, например ZALGO, которая будет с 01.01.2010 по 31.06.2010 равняться 1, а с 01.07.2010 - 2.
Функция IF вызывает правило расчёта, в котором считывается значение константы с помощью элементарной операции NUM=KZALGO. В зависимости от полученного значения будут использоваться различные алгоритмы.
Таким образом, во время выполнения обратного расчёта января 2010 в декабре 2010, то значение константы будет 1. Однако во время перерасчёта ноября 2010 значения константы будет 2.
Вот с помощью такого простого подхода можно придать схемам расчёта начало и конец срока действия.
 
Я бы обратил внимание на российскую специфику в определении организационного присвоения сотрудника.
Есть такая замечательная российская операция RUSPL, - RUSPL?L определяет уволен ли сотрудник в текущем расчётном периоде, подробности в HR-документации, транзакция pdsy.
Также САП предлагает замечательные операции TABLE/VARGB, с помощью которых можно строить условия по любым таблицам, например российских инфотипов, а также прекрасную операцию VAKEY.
 
Это полнейший инструментарий всевозможных условий выбора, которые можно использовать для построения гибких условий на базе функции IF.
 
Незначительная неточность перевода:
Employee Subgroup - это не \"подгруппа\", а \"категория сотрудников\" в терминологии САП.
Параметры EXPMT, EMPLR не используются в российской зарплате.

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

В принципе нормальный документ. Только всетаки для большей доходчивости неплохо было бы оперировать терминологией САП в наименовании  категорий сотрудников (вместо подгрупп).

Полезная статья, но ничего не сказано про Web Dynpro и про настройку анонимного содержимого

Представляет интерес, так как в хэлпе не описан процесс настройки.
Не был бы лишним, на мой взгляд, небольшой ликбез с формулами по рассчету показателей в вариантах.
Есть неточности перевода. Например, \"Для каждого из этих вариантов вводятся плановые значения, а вариант присваивается конкретной версии инвестиционной программы.\" - план присваивается версии контроллинга.

Отличная статья, которая вносит ясность в понимание назначения инструментов SAP BI.

Отличная статья, но желательно, чтобы в статье использовались примеры с реально существующими расширениями в системе SAP.

Статья будет интересна Специалистам по конфигурированию CRM, начинающим работать с web-интерфейсом системы. Материал изложен в простой и понятной форме. Особенно хочется отметить ссылки на курсы и ветки spro.

Статья носит исключительно ознакомительный характер. Полезна для первого шага в изучении преимуществ web 2.0 и их применения при настройке SAP CRM.  

В целом хорошая, понятная статья. Открыл её по ошибке. Тема для меня не актуальная. Занимался проектированием системы безопасности в ЗАО \"СПК\". Подход был не столь тщательный и глубокий, но аналогичный.