Граждане дорогие, не поможете советом как быть.
В Оргменеджменте был настроен собственный вектор анализа для ведения структуры. Фишка его в том, что можно в некоторых случаях привязывать человека не по пути O-S-P, а по пути O-S-S-P (вид связи S-S собственный, добавлен в стандартный ракурс ведения). И все бы хорошо, да только вот беда - при проведении приема на работу или орг. изменения не подхватывается оргединица. Для устранения этого были сделаны следующие вещи:
1) В PBO-логике экрана поставлена проверка (Экран пришлось "сломать") и перезапись в p0001-orgeh "правильного значения" (попутно оно перезаписывается в cprel и в PSYST-orgeh просто на всякий случай)
2) Активировано и протестировано.

Результат плохой. Все благополучно попадает в таблицу операций updat'a (PS - внутренная таблица модуля PA, в которую все падает до нажатия SAVE), но тут вдруг запускается проверка интергации PO & PA и все портит. Почему-то она не находит в стандартном пути анализа связей к О в цепочке O-S-S-P. Интеграция честно пишет нуль в поле orgeh и отправляет все на commit. В связи с этим вопросы:
1) Где бы так все настроить чтобы все увиделось правильно? Должен же быть вектор анализа интеграции (отчет SAPFP50P - подпрограмма INTEGRATION), хотелось бы верить что принимается не только текущий активный вариант плана но и вектор .
2) Можно конечно тупо подправить вызов указанной подпрограммы, но было бы небезынтересно знать где это сделать с минимальным гемороем.

Зря вы это, не надо было ломать стандарт, тем более в интеграции PA и PD, там на это много всего завязано, в том числе новый функционал. Зачем S-S? Какой-нибудь президент с вице-президентом?
Стандарт для определения ORGEH берет не путь анализа, а связь (008, кажется, не помню точно), поэтому в вашем случае ничего и не может определить.

В аналогичном случае все-таки пришлось переделать на S-O-S с добавлением нестандартной связи S-S. Если вы только в начале проекта, откатите все модификации, и сделайте на стандартеЮ будет лучше...

Дак блин, если бы на эту связь уже не было сделано куча всего - поменяли бы . В тот то и фокус, что это единственное место, где неправильно отрабатывает созданный нами путь анализа. Вставка промежуточного звена в цепочку S-S --> S-O-S приведет к огромной переработке кода. А если просто добавить еще одну связь, то юзверю придется постоянно следить чтобы у него ничего не двоилось ... и есть подозрения, что ракурс нормально не отрисуется в этом случае ...
Остается еще вариант получить таблицу результата INTEGRATION и ее повторно обработать. Это нормально сработает?

Насчет S-O-S был неправ... Оргединицу не привязывали к S, а просто делали еще один уровень О.
Вообще, делали в том числе и параллельную оргструктуру на своих объектах, но опять же - не трогая стандартную интеграцию.

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

Риски у вас очень большие: потеря поддержки SAP, невозможность внедрения новых решений, "вечное" сопровождение...

Дак в том то и штука, что альтернативная структура не будет автоматически подхватываться стандартными отчетами.

Понятно. Бум думать. А потом бум делать. Кто ни разу не получал двойку на экзамене - не студент. Кто ни разу не ломал стандарт - не абапер .

Главное, чтобы это в привычку не вошло