안녕하세요. 아는 형입니다.
신규로 생성한 권한을 가지고 테스트를 하는데 AP 지급방법을 변경하려고 ZSAPBRO_001 프로그램을 돌렸는데, 화면상으로 붉은 색으로 처리가 안되었다는 오류메세지가 뜨는 겁니다. ZSAPBRO_001은 저희가 쓰는 CBO(Customer Built Object) 프로그램인데, 자금담당자가 지급 전 AP 내역을 조회하고, 필요하면 그 자리에서 지급방법을 바로 변경할 수 있게 만들어놓은 프로그램입니다. 지급 직전에 마지막으로 한 번 걸러내는 용도라 실무에서 꽤 자주 쓰이는 화면이에요.
신규 법인에서도 사용을 하게 되어 확장된 회사코드를 기반으로 기존 Role을 복사하여 동일하게 만들고 테스트를 진행하는데 오류가 나는 거였습니다.
처음엔 프로그램 버그인가 싶었습니다. 그런데 로그를 까보니 원인이 좀 다른 데 있더군요.
증상: BDC는 도는데 상태가 안 바뀐다
내역을 확인해보니 문제는 이거였습니다. BDC(Batch Data Communication) 처리 과정에서 지급방법 필드가 변경 상태로 되어있어야 입력하는 값이 입력이 되면서 넘어가게 되는데 에초에 Screen에 화면이 모두 조회 상태로 되어있으면서 입력이 안되는 문제가 발생하고 있었습니다. 즉 화면 상태 전환 자체가 안 되고 있었던 겁니다. 그러다보니 BDC를 통해 데이터를 입력하는 시점에 아래와 같이 처리가 안되고 있었던 것이었지요.
혹시나 하여 기존 회사코드 권한을 사용자에게 부여하여 진행을 해보니 똑같은 프로그램, 똑같은 로직으로 멀쩡하게 잘 돌아가는 걸 확인했습니다. 그래서 프로그램 로직 문제는 아니고, 신규로 할당된 Role 쪽 권한 문제일 가능성이 높다고 판단했어요. 이 프로그램을 새로 배정받은 사용자한테서만 증상이 재현됐거든요.
여기서 팁 하나. 분명 다른 사용자·다른 회사코드에서는 잘 도는 프로그램인데 특정 Role에서만 이상하게 동작한다면, 일단 권한 문제부터 의심하고 들어가는 게 시간을 아끼는 길입니다.
SU53, 권한 오류를 만났을 때 가장 먼저 여는 트랜잭션
SAP에서 권한 부족 오류가 뜨면 제일 먼저 찾는 T-code가 SU53입니다. 방금 실패한 AUTHORITY-CHECK 내용을 그대로 보여주는 화면인데요, 예를 들면 이런 식으로 결과가 나옵니다.
- 권한 오브젝트:
F_BKPF_BUK - 회사코드:
BUKRS = 2000 - Activity:
ACTVT = 03 - 결과: 권한 없음
이렇게 나오면, 해당 사용자 Role에 이 권한값이 실제로 들어있는지 PFCG에서 확인해보면 됩니다. 원리 자체는 간단해요.
주의할 점: SU53은 기본적으로 “가장 최근에 실패한 권한 체크” 하나만 보여줍니다. 그래서 오류가 난 직후 다른 트랜잭션을 이것저것 만지지 말고, 바로 SU53부터 열어야 정확한 정보를 잡을 수 있습니다. 딴 짓 좀 하고 나서 열면 이미 다른 체크 결과로 덮여있는 경우가 많아요.
저도 이번 건에서 오류 발생 직후 바로 SU53을 열었습니다. 그런데 여기서부터가 좀 애매해지기 시작했어요.
SU53만으로는 안 잡히는 경우도 있다
SU53 결과를 보고 PFCG에서 해당 Role을 확인했는데, 뭔가 딱 떨어지게 “이거다!” 싶은 게 안 나왔습니다. 신규 Role이다 보니 여러 오브젝트가 얽혀 있었고, SU53 한 화면만 보고 판단하기엔 확신이 서지 않더라고요.
혹시 다른 Role 어딘가에 필요한 값이 빠져있는 건 아닐까 싶어서, 이번엔 SUIM(사용자 정보 시스템)을 열었습니다. SUIM은 특정 권한 오브젝트를 가진 Role들을 역으로 찾아주는 기능이 있는데, 이게 이런 상황에서 꽤 쓸모가 있습니다.
SUIM으로 권한 오브젝트 역추적하기
경로는 사용자 정보 시스템 > 역할 > 복합 선택 기준별 역할입니다. 여기서 오브젝트 1란에 F_BKPF_FKB를, 값 필드에는 02를 입력하고 조회를 돌렸습니다.
이게 진짜 웃긴 게, 이렇게 역으로 뒤져보니 결과가 명확하게 나오더군요. 자금 관련 업무에 쓰이는 Role들 중에는 이 값을 가진 게 하나도 없었습니다. 즉, 애초에 F_BKPF_FKB의 ACTVT = 02 값 자체가 그 어떤 자금 관련 Role에도 부여되어 있지 않았던 거예요.
원인 확정: Role에 02가 아예 빠져있었다
이 프로그램이 실제로 사용하는 Role을 다시 열어서 권한 오브젝트 목록을 확인했습니다.
확인해보니 정말 02 값이 통째로 빠져있었습니다. 신규로 만든 Role이다 보니 기존 Role을 참고해서 카피했을 텐데, 이 과정에서 조회(03)만 들어가고 변경(02)이 누락된 거였죠. 화면 조회는 되니까 겉으로는 멀쩡해 보이는데, 실제 BDC 처리에서 상태를 변경하는 시점에서만 조용히 막히고 있었던 겁니다.
바로 02를 추가하고 Role을 저장했습니다.
이후 다시 ZSAPBRO_001을 실행해보니, BDC 처리 시점에 지급방법이 정상적으로 변경 상태로 바뀌고 처리까지 잘 끝나는 걸 확인했습니다.
SU53 vs SUIM, 언제 뭘 써야 할까
이번 건을 겪고 나니 두 트랜잭션의 역할이 좀 더 명확하게 정리가 되더군요.
| 구분 | SU53 | SUIM |
|---|---|---|
| 확인 방향 | 사용자 → 방금 실패한 권한 체크 1건 | 권한 오브젝트/값 → 해당 값을 가진 Role 목록 |
| 언제 쓰나 | 오류 발생 직후, 바로 원인 후보를 잡을 때 | SU53만으로 확신이 안 서거나, 여러 Role을 역으로 뒤져야 할 때 |
| 한계 | 가장 최근 실패 건만 보여줌 (딴 짓하면 덮임) | 직접 오브젝트/값을 알고 있어야 검색 가능 |
신규 Role 배정 시 체크리스트로 써먹기
혹시 여러분도 이런 경험 있으신가요? 분명 잘 도는 프로그램인데 신규 Role로 넘어가면 이상하게 안 되는 경우요. 저는 이번 건 이후로 신규 Role을 배정할 때는 SU53만 믿지 않고, 관련 오브젝트를 SUIM으로 한 번씩 역추적해보는 습관을 들이게 됐습니다.
특히 이번처럼 화면 조회(03)는 되는데 실제 변경(02) 처리만 막히는 경우는 사용자 입장에서 체감하기가 애매해서 더 오래 헤매게 됩니다. 겉으로는 에러가 안 나는 것처럼 보이니까요. 다음에 비슷한 권한 이슈를 다룰 기회가 있으면, PFCG에서 Role을 설계할 때 놓치기 쉬운 부분도 한번 다뤄보겠습니다.