Возникла следующая проблема.
На проекте в старой системе активно аналитика ведется по кодам должностей, подразделений и т.п.
При переходе на сапу есть две идеи
1. Оставить как есть и привязать штатные должности к ОКДПР, городу, где находится дожность и т.п. (в классификаторы уложить можно все должности). Проще говоря, код должности после этого будет выглядеть как ХХ(филиал).YYYYY(код по ОКДПР).ZZZ(еще пара аналитик). Аналогичная весчь планируется с разделами/подразделами
До этого проекта (сейчас концепт ваяем) делали по данному сценарию. Но пока go live ни на одном из проектов не было
2. Как альтернатива рассматривается идея привязывания аналитических признаков через инфотипы (возможно - свои) к должности, штатной должности и т.п. (в зависимости от разреза, в котором треба аналитику)

Из потенциальных джoппов в первом случае видится:
1. Нехватка кодов или появление чего-либо, не вписывающегося в стандартную концепцию конструкции.
2. Необходимость наличия naming conventions aka положений по обозначению любого объекта
3. Малое количество кодов аналитики и сложность добавления новых признаков

Во втором
1. Большая сложность настройки и разработки
2. Так еще не делали

По поводу аналитики в код объекта.
Тут я все равно вижу кучку разработок, для того чтобы разобрать этот код по "удобоваримым" значениям, чтоб в отчеты вывести. Так что без АБАПа не обойтись.
Да и нехватка длинны кода имеет место быть и перекодировка в случае чего достаточно сложна.
Также нужно писать кусок кода, который этот самый идентификатор будет правильно собирать из разных кусков при создании нового объекта. Вряд ли пользователь в состоянии адекватно нарисовать код из 10 цифр, чтоб все они правильными были.

Из моих предложений для аналитики воспользоваться ИТ1222 "Общее ведение атрибутов".
Если я не ошибаюсь, он как раз и приспособлен для ведения всего, что не попало в стандартные ИТ. Он достаточно просто настраивается, к нему стандартным образом привязываются справочники значений. Ну и в Query его можно вывести, вот и аналитика

Наверняка еще есть варианты

Собстно, на 1222 и сам нацеливаюсь. Основной вопрос - а его кто-то пользовал для этих целей? И к PPOME его можно прикрутить без особых проблем в 2005?
Но в общем и целом ABAP для целей разбора есть уже

Есть еще 1010 ИТ , посмотрите на него. Тоже можно пользовать для хранения всяких своих признаков.
По должностям - обычно как-то стараются их соотнести с государственным классификатором ОКДПР, поэтому наверное не должно быть отдельного набора должностей для каждого предприятия . Может имеет смысл сделать свой объект - типа группа должностей и сгрупировать через него должности в несколько деревьев, так чтобы каждая должность могла попадать в несколько деревьев, а деревья сделать по предприятиям-филиалам?

А можно филиалы поделить разделом или подразделом персонала. Загрузить ОКПТД в должности и привязать к штатным должнотсям.
У нас в ИТ1222 хранятся ВО со значениями для того что-бы их считать косвенной оценкой в 8 ит, количество дней отпуска по вредности для формирвания лимита отсутствия.

Данке schon, смотрю

Филиал в БЕ висит.

Основной вопрос - пыхать в код или в доп.признаки?

В должности по карте решения предлагается код по ОКДПТР пихать в SHORT.

А есть ли высокий смысл усложнять OM должностью только для одного ОКДПТР? Не проще ли повесить ОКДПТР в штатную должность?

Мне кажется что пользоателю легче, делая новую штатную должность, присоединить должность из списка, нежеле шифровать код объекта

Шифровать он ничего уже не будет. Идею с шифрами удалось закинуть подальше . На данный момент просто единственной аналитикой, которая сидит в C - получается код ОКДПТР. Вот и возник вопрос, а нафига нам тогда при структуре O-S-P это самое С. А ОКДПТР тогда проще в S упихать. Хотя бы посредством того же 1010
Тем более, что клиент, хоть и бьет себя пяткой в грудь, но ОКДПТРа ему не хватает местами.
Т.е. делаем ОКДПТР как аналитику на штатной должности, если юзер его выберет, то название должности подтянем из ОКДПТРа, если нет - пущай сам колбасит, что ему угодно.

У нас сначало в должностях был ОКДПТР, но потом снесли и закачали список профессий в рамках данного предприятия.
Но реально никто его так и не привязывает ... пока так смысл и не найден

Тогда точно нафих. В хелпе сапа пишет, что оно импользуется для группировок одноименных профессий, типа манагер - это должность, а манагер по персоналу - штатная должность. Но в случае с ОКДПТРом в должности весь смысл теряется.

Если ОКПДТР запихать все же как объект "должность", то будет достигнута большая гибкость при работе со стандартным инструментарием.