Непросто сформулировать вопрос, так как тут и частично разработчикам адресовано, частично консультантам
Может кто-нибудь наводящими вопросами направит в нужное русло для решения проблемы

Через тр. BP создали бизнес партнеров (БП) и в роли BUP003 связали БП с системными учетными записями пользователей, прописав на вкладке "Идентификатор" - "Имя пользователя" соответствующие логины.

Это было необходимо, чтобы в функциональности Audit Management корректно определялись роли участников аудита
Определяются они в стандартном коде с помощью ФМ BP_CENTRALPERSON_GET

Толи кто-то что-то поломал, толи сразу не заметили, но со временем когда систему начали сдавать в эксплуатацию некоторые БП "поломались", решение которых и является сутью данной темы:
- у некоторых БП в имени пользователя пропал указанный там логин и повторно введенный логин пропадает при сохранении
- у других, несмотря даже на наличие введенного логина в поле "Имя пользователя", вызов ФМ BP_CENTRALPERSON_GET не возвращает GUID БП

Из того, что выяснил для последней проблемы - алгоритм ФМ работает по следующему алгоритму:
1. определяет персональный номер сотрудника (Person ID, тип PERSONID) по его логину (в HRP1001 это значение поля совпадает в поле OBJID)
2. по найденному номеру находит номер БП из инфо-типа 1001, подтип B207

Для всех проблемных БП номер сотрудника определяется некорректно, соответственно запись для подтипа B207 инфо-типа 1001 запрашивается для другого персонального номера, для которого БП не создавался
Либо наоборот, в 1-ом пункте номер определяется корректно, но для 2 пункта в подтип B207 для данного БП прописан некорректный персональный номер

Определение табельного номера сотрудника по его логину выполняется следующим образом:
CALL FUNCTION 'RH_STRUC_GET'
EXPORTING
act_otype = 'US'
act_objid = iv_username
act_wegid = 'A208'
act_plvar = l_plvar
act_tflag = space
act_vflag = space
authority_check = space
TABLES
result_tab = result_tab
EXCEPTIONS
no_plvar_found = 0
no_entry_found = 0
OTHERS = 0.
READ TABLE result_tab WITH KEY otype = 'CP'.
IF sy-subrc = 0.
ev_username = iv_username.
ev_person_id = result_tab-objid.
ENDIF.

Тут код привел для разработчиков из HR, может быть подскажут откуда эта информация запрашивается.
Для консультантов скажу, что параметр в который передается значение 'A208' называется "Путь анализа" - может знаете что это значит и подскажете где посмотреть информацию по его ведению для пользователя.

Информация запрашивается из таблиц HRP1000 "Объекты" и HRP1001 "Соединения".
Путь анализа - это правила, по которым осуществляется выбора объектов по соединениями. В данном случае используется просто одно соединение А208. Путь анализа можно потестить в транзакции PPSS.

Посмотреть какие соединения есть у объекта можно транзакции PP01 или в PPOSE.

А с диапазонами номеров ничего не делали?

Не. Это определение Центрального Лица (Central Person), объект CP. Это не табельный номер. Важно отличать эти понятия.

Да, я вначале думал, что табельный номер определяется, а потом понял ошибку и в сообщении поста сменил табельный на персональный. Здесь не заметил, что не исправил - речь идет о PERSONID

А какие диапазоны можно проверить?

В дополнение: реальная логика работы определения БП по логину отрабатывает в ФМ HR_CENTRALPERSON_GET_NUMBERS

тр.SNRO для CP - RP_PLAN , BP - BU_PARTNER, P - RP_PREL.
Попробуйте запустить отчет HRALXSYNC для проблемных.