FRGSX 하나로 갈리는 PR vs PO 승인 #shorts #SAP #MM

📖 이 글에서 다루는 것

SAP MM 구매 프로세스에서 승인(Release Strategy)을 구매요청(PR)에 걸 것인지 구매오더(PO)에 걸 것인지는 결재 흐름 전체를 좌우하는 설계 결정입니다. S/4HANA 2023 FPS02를 기준으로 두 문서의 승인 구조 차이와 설정 절차, User Exit·CDS 확장까지 단계별로 살펴봅니다.

PR 승인과 PO 승인의 구조적 차이(품목 단위 vs 헤더 단위) 이해
Release Group·Code·Strategy와 특성(Characteristic) 설정 절차 습득
CEKKO/CEBAN 통신 구조 확장으로 커스텀 결재 조건 구현
승인 배치 기준(금액·시점·책임 주체)을 스스로 판단할 수 있는 기준 확보

📚 미리 알아두면 좋은 것

MM 구매 문서 흐름(PR → RFQ → PO → GR → IV)의 기본 개념, SPRO 진입 경험, ABAP 기초 문법을 알고 있으면 수월합니다. 분류 체계(Class/Characteristic, 클래스 타입 032)를 처음 접해도 절차를 따라오면 이해할 수 있습니다.

🔧 환경 · 버전 · 준비 사항

이 글의 예제는 다음 환경을 기준으로 작성되었습니다.

SAP S/4HANA 2023 (On-Premise, FPS02) — 클래식 Release Strategy 기준. ECC 6.0도 경로는 거의 동일합니다.
S/4HANA Cloud Public Edition은 Flexible Workflow가 일반적이며, 본문 후반에서 차이를 짚습니다.
필요 권한: SPRO, CT04/CL02/CL20N(특성·분류), ME51N/ME54N/ME21N/ME29N, SE38·SE80
가상 시나리오: 정밀부품 제조사 "한빛정밀"의 구매조직 HB01, 플랜트 HP10

💡 핵심 개념 — 승인은 왜 두 군데에 걸릴 수 있는가

PR과 PO의 승인을 비유하면 이렇습니다. PR 승인은 "이 물건이 정말 필요한가"를 묻는 수요 결재이고, PO 승인은 "이 조건(가격·공급사)으로 회사 돈을 써도 되는가"를 묻는 지출 결재입니다. 품의서와 지출결의서가 다른 문서인 것과 같습니다.

기술적으로 두 문서의 승인 구조는 비대칭입니다. 이 비대칭이 설계 기준의 출발점입니다.

구분	구매요청(PR)	구매오더(PO)
승인 단위	품목(Item) 또는 전체(Overall)	헤더(문서 전체)만 가능
분류 없이 승인	가능(품목 단위, 제한적 조건)	불가 — 반드시 분류(032) 사용
통신 구조	CEBAN	CEKKO
승인 트랜잭션	ME54N(개별), ME55(집합)	ME29N(개별), ME28(집합)
상태 필드	EBAN-FRGKZ, FRGZU, FRGST	EKKO-FRGKE, FRGZU, FRGSX

승인전략의 동작 원리는 세 겹입니다. 문서 저장 시 시스템이 통신 구조(CEBAN/CEKKO)에 문서 값을 채우고, 분류 체계의 특성값과 대조해 일치하는 Release Strategy(FRGSX)를 결정합니다. 전략이 결정되면 소속 Release Code(FRGCO)들이 정의된 선행 조건(Prerequisite) 순서대로 승인을 요구하고, 모든 코드가 승인되어야 후속 처리(PO 전환, 출력·전송)가 풀립니다. 즉 전략 결정은 자동, 승인 행위는 수동(또는 워크플로)이라는 이중 구조입니다.

어디에 걸어야 하는가의 일반적인 판단 기준은 다음과 같습니다.

PR 승인이 유리한 경우: 구매부서가 소싱을 시작하기 전에 현업 수요 자체를 통제해야 할 때. 예산 부서가 초기에 개입해야 하는 조직에서 권장됩니다.
PO 승인이 유리한 경우: 실제 지출 금액과 공급사가 확정된 시점의 통제가 중요할 때. PR 단계 금액은 추정치라 결재 실효성이 떨어진다는 관점입니다.
이중 승인: 고액 건에 흔한 패턴이지만, 동일 인물이 두 번 결재하는 중복은 피하도록 금액 구간을 서로 다르게 잡는 것이 일반적입니다.

💻 실전 코드 — 3단계 예제

1단계: 기본 — 한빛정밀 PO 승인전략 설정과 상태 조회

한빛정밀은 "PO 500만 원 초과 시 구매팀장(코드 P1) → 재무이사(코드 P2)" 2단 결재를 설계했습니다. 커스터마이징 경로는 SPRO → 자재관리 → 구매 → 구매오더 → Release Procedure for Purchase Orders입니다.

CT04로 특성 생성: ZHB_PO_NETW(참조: 테이블 CEKKO, 필드 GNETW, 통화 KRW), ZHB_PO_EKGRP(CEKKO-EKGRP)
CL02로 클래스 ZHB_PO_REL 생성(클래스 타입 032), 위 특성 2개 할당
Release Group HG 정의 후 클래스 연결, Release Code P1, P2 등록
Release Strategy H2 생성 — 선행조건: P2는 P1 승인 후에만 가능하도록 체크
CL20N 분류값 입력: ZHB_PO_NETW > 5,000,000, ZHB_PO_EKGRP = H01

설정 후 상태를 코드로 확인하는 최소 예제입니다.

REPORT zhb_po_release_check.

PARAMETERS pv_ebeln TYPE ekko-ebeln OBLIGATORY.

SELECT SINGLE frgke, frgzu, frgsx, frggr
  FROM ekko
  WHERE ebeln = @pv_ebeln
  INTO @DATA(ls_rel).

IF sy-subrc = 0.
  WRITE: / |승인지시자(FRGKE): { ls_rel-frgke }|,   " R=차단, F=승인완료
         / |승인상태(FRGZU) : { ls_rel-frgzu }|,   " X 표시 자릿수 = 완료 코드 수
         / |전략/그룹       : { ls_rel-frgsx }/{ ls_rel-frggr }|.
ENDIF.

2단계: 실무 — CEKKO 확장으로 커스텀 결재 조건 만들기

표준 CEKKO에 없는 값(예: 자체 프로젝트 등급)으로 전략을 나누려면 CEKKO에 append 필드 ZZPRJ_GRADE를 추가하고, 확장점 M06E0004(EXIT_SAPLEBND_002)에서 값을 채웁니다.

*&----------------------------------------------------------
*& ZXM06U22 (EXIT_SAPLEBND_002 include) — PO 전략결정 직전 호출
*&----------------------------------------------------------
DATA lv_grade TYPE zhb_prj_grade.

" PO 첫 품목의 WBS로 자체 프로젝트 등급 판정
READ TABLE it_bekpo INTO DATA(ls_item) INDEX 1.
IF sy-subrc = 0 AND ls_item-ps_psp_pnr IS NOT INITIAL.
  SELECT SINGLE zz_grade FROM zhb_prj_master
    WHERE pspnr = @ls_item-ps_psp_pnr
    INTO @lv_grade.
  IF sy-subrc <> 0.
    " 마스터 미등록 → 보수적으로 최고 등급 처리 + 로그
    lv_grade = 'A'.
    CALL FUNCTION 'BAL_LOG_MSG_ADD_FREE_TEXT'
      EXPORTING i_log_handle = gv_log_handle
                i_msgty      = 'W'
                i_text       = |PRJ 등급 미등록: { ls_item-ps_psp_pnr }|.
  ENDIF.
ENDIF.

e_cekko           = i_cekko.       " 표준 값 복사 필수
e_cekko-zzprj_grade = lv_grade.    " 커스텀 특성값 주입

이후 CT04에서 특성을 CEKKO-ZZPRJ_GRADE에 연결하면 "A등급 프로젝트는 금액과 무관하게 임원 결재" 같은 전략을 분류값만으로 구성할 수 있습니다. PR 쪽은 CEBAN append와 M06B0002로 동일하게 적용됩니다.

3단계: 프로덕션 — 승인 모니터링 CDS와 안전한 일괄 승인

운영 단계에서는 미승인 문서의 체류 시간을 모니터링하고 권한·중복을 방어해야 합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '한빛정밀 미승인 PO 모니터'
define view entity ZHB_I_PoRelPending
  as select from ekko
{
  key ebeln              as PurchaseOrder,
      frggr              as ReleaseGroup,
      frgsx              as ReleaseStrategy,
      frgzu              as ReleaseState,
      ekgrp              as PurchasingGroup,
      aedat              as CreatedOn,
      dats_days_between(aedat, $session.system_date)
                         as PendingDays
}
where frgke = 'R'   -- 아직 차단 상태인 문서만
  and frgsx <> ''

승인 실행은 화면 재현 없이 BAPI로 처리하되, 권한 검사와 커밋 제어를 명시합니다.

METHOD release_po_safely.
  AUTHORITY-CHECK OBJECT 'M_EINK_FRG'
    ID 'FRGGR' FIELD iv_frggr
    ID 'FRGCO' FIELD iv_frgco.
  IF sy-subrc <> 0.
    RAISE EXCEPTION TYPE zcx_hb_release EXPORTING textid = zcx_hb_release=>no_auth.
  ENDIF.

  CALL FUNCTION 'BAPI_PO_RELEASE'
    EXPORTING purchaseorder = iv_ebeln
              po_rel_code   = iv_frgco
    TABLES    return        = rt_return.

  IF line_exists( rt_return[ type = 'E' ] ).
    CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
  ELSE.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = abap_true.
  ENDIF.
ENDMETHOD.

BAPI 호출부는 인터페이스로 감싸 단위 테스트에서 test double로 대체하고, 정상 승인·권한 없음·선행 코드 미승인 시나리오를 검증하는 구성이 권장됩니다. PR 일괄 승인은 BAPI_REQUISITION_RELEASE_GEN을 같은 패턴으로 감쌉니다.

⚠️ 흔한 실수와 트러블슈팅

전략이 아예 결정되지 않는다 — 분류값과 통신 구조 값이 하나라도 불일치하면 전략은 침묵합니다. CEKKO-GNETW는 문서 통화가 아닌 특성에 지정한 통화로 비교되므로, 다중 통화 환경에서는 특성 통화를 고정해야 합니다.
PO 변경 후 승인이 리셋된다 — Release Indicator의 Changeability(4/6)와 허용 변동률(%) 설정에 따라 승인 후 금액 변경 시 전략이 재결정됩니다. 값 6(초과 시 리셋)을 무심코 쓰면 결재 반복으로 현업 불만이 커집니다.
PR은 승인됐는데 PO 전환이 막힌다 — PR Release Indicator에 "RFQ/PO 허용" 플래그가 빠져 있으면 승인 완료 후에도 후속 문서 생성이 차단됩니다.

FAQ 1. PR·PO 양쪽에 승인을 걸면 결재가 두 배로 늘지 않나요? — 금액 구간을 다르게 설계하는 방식이 일반적입니다. 예: PR은 전 건 팀장 승인, PO는 1천만 원 초과만 임원 승인.

FAQ 2. PO에서 품목별 승인이 가능한가요? — 불가능합니다. PO 승인은 항상 헤더 단위이므로, 품목별 통제가 필요하면 PR 품목 단위 승인으로 앞단에서 걸러야 합니다.

FAQ 3. S/4HANA Cloud에서도 같은 방식인가요? — Public Cloud는 Flexible Workflow(Manage Workflows 앱) 사용이 권장되며, 클래식 전략과 동시 활성화하면 충돌하므로 하나만 선택해야 합니다.

🚀 이어서 살펴볼 주제

클래식 승인전략을 이해했다면 Flexible Workflow for Purchase Order(시나리오 WS300000200 계열)로 승인선을 코드 없이 구성하는 방법, My Inbox Fiori 앱 연동으로 넓혀가는 것을 권합니다. 계약(Outline Agreement)과 서비스 엔트리 시트의 승인전략도 같은 분류 체계 원리를 공유합니다.

🗂️ 함께 점검하면 좋은 체크리스트

PR·PO 어느 쪽에 걸지 조직 합의를 받았는가
다중 통화 거래 시 CT04 특성 통화가 일치하는가
Changeability 값에 따른 재승인 구간을 합의했는가
커스텀 확장 도입 시 전략 미결정 원인을 로그로 추적할 수 있는가
Cloud 전환 시 클래식 전략과 Flexible Workflow 중 하나만 활성화됐는가

댓글 0