SAP

VKM1 모르면 수주 막히는 3가지 시점 #shorts #SAP #CreditManagement

▶ YouTube에서 보기

📖 개요: 여신 체크가 수주를 막는 순간

영업 담당자가 "수주가 갑자기 저장이 안 돼요"라고 말할 때, 원인의 상당수는 여신관리(Credit Management)입니다. 그런데 같은 여신한도 초과라도 수주 저장 시점에 막히는 회사가 있고, 납품 생성 시점 또는 출고(PGI) 시점에 막히는 회사가 있습니다. 이 차이는 우연이 아니라 Customizing으로 정한 설계 결과입니다. 이 글에서는 세 가지 차단 시점의 동작 구조를 분해합니다.

  • 여신노출(Credit Exposure)이 어떤 문서 값으로 합산되는지 이해
  • 수주·납품·출고 세 시점의 체크 그룹(Credit Group) 구조 파악
  • 차단(Error)과 경고(Warning) 반응의 설정 차이 구분
  • 차단 문서 모니터링용 ABAP/CDS 실전 예제 작성

📚 미리 갖추면 좋은 배경

SD 판매 프로세스(수주 → 납품 → 출고 → 대금청구)의 문서 흐름을 알고 있어야 하며, SPRO에서 Customizing 노드를 찾아가는 기본 조작에 익숙하면 좋습니다. ABAP 예제는 SELECT와 클래스 기초 수준이며, FI 채권(미수금) 개념을 알면 여신노출 계산을 더 빠르게 이해할 수 있습니다.

🔧 시스템 환경과 준비 사항

이 글은 두 환경을 함께 다룹니다. SAP ECC 6.0의 클래식 여신관리(SD-BF-CM)는 FD32로 한도를 관리하고 KNKK 테이블에 저장합니다. SAP S/4HANA(2022 이상 기준)에서는 클래식 방식이 제거되고 FSCM 기반 여신관리(FIN-FSCM-CR)만 사용 가능하며, 한도는 비즈니스 파트너 역할 UKM000(트랜잭션 UKM_BP)에서 관리합니다. 다만 두 환경 모두 SD 측 체크 시점 설정(OVAK, OVAD, OVA8)의 골격은 동일하게 유지되므로, 이 글의 구조 설명은 양쪽에 적용됩니다. 준비물은 SPRO 접근 권한, VKM1/VKM3 사용 권한, 그리고 테스트용 판매조직·고객 마스터입니다.

💡 핵심 개념: 여신노출과 세 개의 관문

여신관리를 공항 보안에 비유하면 이해가 빠릅니다. 승객(주문)은 체크인 카운터(수주 저장), 탑승구(납품 생성), 비행기 문(출고 PGI)이라는 세 관문을 지나는데, 어느 관문에 검색대를 세울지는 공항 운영자(여신 담당자)가 결정합니다. 검색대를 앞쪽에 세울수록 일찍 걸러내지만 오탐으로 인한 업무 지연이 늘고, 뒤쪽에 세울수록 영업 흐름은 매끄럽지만 재고가 이미 피킹된 뒤 멈추는 비용이 커집니다.

판정 기준인 여신노출(Credit Exposure)은 일반적으로 다음 네 가지의 합입니다.

  • 미결 채권(Open Receivables): 아직 수금되지 않은 FI 미수금
  • 미결 수주(Open Orders): 수주됐지만 납품되지 않은 금액
  • 미결 납품(Open Deliveries): 납품 생성 후 대금청구 전 금액
  • 미결 대금청구(Open Billing): 청구서 발행 후 회계전기 전 금액

이 합계가 여신한도(Credit Limit)를 넘는 순간, "어느 관문에서 어떻게 반응할지"를 결정하는 것이 세 가지 설정 축입니다.

  • 체크 그룹(Credit Group): 01=수주, 02=납품, 03=출고. OVAK에서 판매문서유형에, OVAD에서 납품유형에 할당하며, 할당된 시점에만 체크가 발동합니다.
  • 리스크 카테고리/리스크 클래스: 고객의 위험 등급. ECC는 FD32의 리스크 카테고리, S/4HANA는 UKM_BP의 리스크 클래스가 OVA8 판정 라인을 결정합니다.
  • 자동 신용관리(OVA8): 여신관리영역 + 리스크 등급 + 체크 그룹 조합별로 정적/동적 체크, 지평(Horizon), 반응(A=경고, B=오류, C/D=상태 설정 포함)을 정의합니다.

체크 결과는 VBAK-CMGST에 기록됩니다. 값 B는 차단, D는 담당자가 VKM3/VKM1로 해제한 상태입니다. 즉 "어디서 막히는가"는 체크 그룹 할당 위치가, "막히는가 경고만 뜨는가"는 OVA8의 반응 코드가 결정하는 이중 구조입니다.

💻 실전 예제 3단계

1단계 — 기본: 차단된 수주 조회

여신 담당자가 매일 아침 확인할 최소 단위 예제입니다. VBAK-CMGST가 B인 최근 문서를 조회합니다.

REPORT zcm_blocked_scan.

PARAMETERS: p_days TYPE i DEFAULT 30.

SELECT vbeln, kunnr, auart, netwr, waerk, erdat
  FROM vbak
  WHERE cmgst = 'B'
    AND erdat >= @( CONV d( sy-datum - p_days ) )
  ORDER BY erdat DESCENDING
  INTO TABLE @DATA(lt_blocked).

LOOP AT lt_blocked INTO DATA(ls_doc).
  WRITE: / ls_doc-vbeln, ls_doc-kunnr,
           ls_doc-netwr CURRENCY ls_doc-waerk,
           ls_doc-erdat.
ENDLOOP.

2단계 — 실무: 한도 대비 노출 판정과 로깅

S/4HANA 환경에서 여신 세그먼트별 한도와 노출을 비교해 위험 고객을 판정하고, 예외 처리와 애플리케이션 로그를 남기는 클래스 예제입니다. 야간 배치로 돌려 다음 날 수주 차단을 예측하는 용도로 씁니다.

CLASS zcl_cm_exposure_watch DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS check_partner
      IMPORTING iv_partner       TYPE bu_partner
                iv_segment       TYPE ukm_credit_sgmnt
      RETURNING VALUE(rv_over)   TYPE abap_bool
      RAISING   zcx_cm_watch_error.
ENDCLASS.

CLASS zcl_cm_exposure_watch IMPLEMENTATION.
  METHOD check_partner.
    " 세그먼트별 여신한도 조회 (BP 역할 UKM000 데이터)
    SELECT SINGLE credit_limit
      FROM ukmbp_cms_sgm
      WHERE partner        = @iv_partner
        AND credit_sgmnt   = @iv_segment
      INTO @DATA(lv_limit).
    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE zcx_cm_watch_error
        EXPORTING textid = zcx_cm_watch_error=>no_limit_data.
    ENDIF.

    " 노출 합산 (미결수주+미결납품+미결청구+채권 유형별 항목)
    SELECT SUM( amount )
      FROM ukm_item
      WHERE partner      = @iv_partner
        AND credit_sgmnt = @iv_segment
      INTO @DATA(lv_exposure).

    rv_over = xsdbool( lv_exposure > lv_limit ).

    " 애플리케이션 로그 기록 (SLG1 확인용)
    DATA(lo_log) = cl_bali_log=>create_with_header(
      header = cl_bali_header_setter=>create(
                 object = 'ZCM' subobject = 'WATCH' ) ).
    lo_log->add_item( cl_bali_free_text_setter=>create(
      severity = COND #( WHEN rv_over = abap_true
                         THEN if_bali_constants=>c_severity_warning
                         ELSE if_bali_constants=>c_severity_information )
      text     = |{ iv_partner } 노출 { lv_exposure } / 한도 { lv_limit }| ) ).
    cl_bali_log_db=>get_instance( )->save_log( lo_log ).
  ENDMETHOD.
ENDCLASS.

3단계 — 프로덕션: CDS 모니터링 뷰와 권한·테스트

운영에서는 차단 문서를 Fiori 리스트로 노출하는 편이 유지보수에 유리합니다. 아래는 차단 시점(수주/납품)을 구분해 보여주는 CDS 뷰 엔티티 예제입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '여신 차단 문서 모니터'
define view entity ZI_CM_BlockedDocMonitor
  as select from vbak
{
  key vbeln                as SalesDocument,
      kunnr                as SoldToParty,
      vkorg                as SalesOrganization,
      netwr                as NetAmount,
      waerk                as Currency,
      cmgst                as CreditStatus,
      case cmgst
        when 'B' then '차단'
        when 'D' then '해제됨'
        else          '기타'
      end                  as StatusText
}
where cmgst = 'B' or cmgst = 'D'

프로덕션 체크리스트는 세 가지입니다. 첫째, 성능: 배치 판정 클래스는 파트너 단건 루프 대신 FOR ALL ENTRIES 또는 CDS 집계로 묶어 UKM_ITEM 풀스캔을 피합니다. 둘째, 보안: CDS에는 판매조직 기준 DCL을 붙이고, 해제 권한(VKM1/VKM3)은 영업이 아닌 여신 담당 롤에만 부여하는 것이 일반적입니다. 셋째, 테스트: 리스크 등급별 대표 고객으로 "수주만 차단", "납품만 차단", "출고 차단" 세 케이스를 품질계에서 각각 재현한 뒤 이관하는 방식을 권장합니다.

🕳️ 자주 만나는 함정

Q1. 수주는 통과했는데 납품 생성에서 갑자기 막힙니다. 수주 시점 이후 다른 문서로 노출이 늘었거나, 동적 체크의 지평(Horizon) 밖이던 금액이 기간 안으로 들어온 경우입니다. OVA8에서 체크 그룹 02(납품) 라인이 별도로 활성화되어 있는지 먼저 확인하세요. 두 시점의 판정 조건이 다르면 이런 "뒤늦은 차단"이 정상 동작입니다.

Q2. 한도를 올렸는데(UKM_BP/FD32) 기존 수주가 여전히 차단 상태입니다. 한도 변경은 기존 문서 상태를 자동으로 바꾸지 않습니다. VKM1에서 재체크하거나 VKM3로 해제해야 CMGST가 D로 바뀌고 후속 문서가 진행됩니다.

Q3. 반응을 경고(A)로 설정했는데 문서가 막혀 있습니다. OVA8의 반응 코드와 별개로 "상태 설정(Status/Block)" 플래그가 켜져 있으면 경고여도 납품 차단 상태가 남을 수 있습니다. 또한 같은 조합에 정적·동적·최고금액 체크가 중복 활성화되어 다른 체크가 오류(B)로 걸렸을 가능성도 확인 대상입니다.

Q4. 여신노출 합계가 실제 미결 문서와 맞지 않습니다. ECC에서는 정보구조(S066/S067) 불일치가 원인인 경우가 많아 재구성 리포트(RVKRED77 계열) 실행이 일반적인 해결책입니다. S/4HANA에서는 UKM_ITEM 재계산(노출 재구축 도구)을 야간에 수행하는 운영 루틴을 권장합니다.

🚀 이어서 보면 좋은 글

세 관문 구조를 이해했다면, 다음으로는 지급보증 절차(Payment Guarantee)와 여신 체크의 상호작용, S/4HANA의 문서형 여신 케이스(Documented Credit Decision, DCD) 기반 해제 워크플로, 신용평가 점수 자동 산출을 위한 스코어링 공식과 BAdI 확장(UKM_R3_ACTIVATE 등)을 살펴보면 좋습니다. Fiori 앱 기반 차단 문서 해제 프로세스로의 전환도 S/4HANA 프로젝트에서 자주 다루는 주제입니다.

댓글 0

아직 댓글이 없습니다.