В Оргменеджменте столкнулись с проблемой присвоения самодельных объектов большому количеству штатных должностей.
У нас на проекте есть несколько типов таких объектов, но для примера рассмотрим объект «Вредные факторы». Один объект «вредный фактор» может быть присвоен большому количеству штатных должностей в различных дочерних обществах Компании.
В результате наблюдаем следующую картину: в одном дочернем обществе пользователь ограничивает штатную должность, к которой привязан вредный фактор. Это действие естественно влечет за собой и ограничение записи ИТ 1001 объекта «вредный фактор». Это в свою очередь вызывает блокировку всех объектов, которые имеют соединение с данным вредным фактором. То есть блокируется большое количество штатных должностей по всей Компании. И эти блокировки висят до тех пор, пока в PPOME пользователь не нажмет кнопку «Сохранить» (а это может быть достаточно большой промежуток времени). Пользователи других дочерних обществ в это время ничего не могут сделать со своими штатными должностями.
Как стандартными средствами устранить такие блокировки не знаем. Объекты С (Должность) тоже присваиваются большому количеству штатных должностей, но в отличие от самодельных объектов такого явления не вызывают. Это происходит потому, что в стандартном коде SAP явно прописано, что соединения с объектом С не должны вызывать блокировок объектов.
Наверняка многие уже сталкивались с подобной проблемой. Буду очень признателен, если дадите совет, как корректнее выйти из этой ситуации.

Решение в лоб очевидно - добавить в стандартный код исключение и для своих объектов. Кстати, не подскажете, где этот стандартный код находится?

программа LRHOMBUFFERF02
FORM check_and_lock_rel_objects

Понятно, что можно внести изменения в стандартный код, но вот хотелось бы найти более корректное решение

Не очень красивое решение, но все же: сделать максимальное значение шагов например 2 или 3, чтобы пользователи почаще сохранялись.

Подскажите пожалуйста, может кто-то решил без модификации программы?

Та же ситуация как описана в первом посте. Есть объект CH на котором висит ВУТ. Список самих ВУТ небольшой, а корпорация большая, соответственно, когда в каком-то филиале начинают присвоение ВУТ к ШД, то его невозможно присвоить по другим филиалам, пока в первом не закончат обработку.
Как решение сделали возможность присвоения только через PP01, т.к. в PPOME пользователи могут "заиграться" с созданием подольше чем в PP01.
Настройками никак нельзя вырубить для определенного объекта проверку? Или может есть другие нетривиальные подходы без модификации?

Нет нельзя, это дизайн и архитектора системы. Блокировки автоматически снимаются если вы переходите на другой объект. К примеру, выбираем S к которому надо присвоить ВУТ, выбрали его, назначили ему ВУТ, сохранили и сто% блокировки снимутся. Проверяли не раз, показывали в такой же большой производственной корпорации и у сотрудников бизнеса проблемы после этого ушли как класс. Суть в том что если Вы работаете правильно с PPOME то и проблем не возникает.

Да это то как раз понятно. То же самое и относительно PP01. Принцип проверки один и тот же.
Проблема то как раз в пользователях. Вы же знаете какие они бывают. Начала вводить, тут позвонил ребенок/муж/сестра, позвали пить чай... да что угодно И тут никакие инструкции не помогут.
Ок, спасибо за камент, пойду проводить разъяснительную работу еще раз. А если не поможет, то конечно ABAP наше все

А если сделать задублировать справочник ВУТ, сделав для каждого филиала свой отдельный экземпляр? Каждый филиала будет пользоваться своим набором ВУТ, и при редактировании блокировка будет распространятся только объекты одного филиала.

А как потом соотносить, что ВУТ №12 и ВУТ № 123 это один и тот же ВУТ?
Сварганить свою Z-набивалку, чтобы она создавала быстро ВУТ и выходила с PP01 освобождая блокировки

Более 15 БЕ, да еще в некоторых по несколько филиалов... В рамках каждой БЕ это еще как-то решит вопрос. Но вот как сводить показатели на уровне всей корпорации?
Понятно, что можно сводную таблицу где-то в сторонке вести, но будет ли это для топовых управленцев удобное решение - вопрос.

Да ладно, никакого вопроса нет, кодировка у ВУТов должна быть одинаковая просто, по нему и меппить потом в отчетности.

транзакцию PFOM когда-нибудь долбили?

PFOM смысл ее долбить... PPOME гораздо мощнее

Предполагалось не создавать ВУТ №12 и ВУТ №123, а сделать два одинаковых объекта ВУТ №12 и ВУТ №12 и разнести их по иерархии. Кодировка одинаковая, просто это разные объекты.
Иерархия может либо:

либо

В первом варианте для консолидирования данных нужно использовать кодировку самого объекта, вместо его ИД.
В втором варианте можно использовать ИД объекта, нужно лишь брать ИД вышестоящего объекта.

то есть Вы даже умней индуса/немца, которые сделали почему-то 3 транзакции вместо одной мощной? уважуха. … а и правда! даешь пупсам одну мощную транзакцию, вводишь им расписание посещения этой транзакции, в каком-нибудь ЦК САП заводишь "хранителя транзакции" (как в Газпроме) … очень мощно.