UI5 모드
SAP

CO11N 확인 안 하면? 원가차이 왜곡 3가지 #shorts #SAP #ABAP

수정: 2026년 8월 13일 👁 0 · ♥ 0
▶ YouTube에서 보기

왜 실적확인 하나 빠졌다고 원가가 무너지는가

생산오더의 원가는 크게 두 갈래로 쌓입니다. 자재 출고가 만드는 재료비, 그리고 작업실적확인(Confirmation)이 만드는 가공비입니다. 재료비는 눈에 보이는 출고 전표가 있어 누락을 알아채기 쉽지만, 가공비는 작업자가 CO11N에서 활동수량을 입력해야만 오더에 전기되기 때문에 누락이 조용히 숨어 있다가 월말 차이분석에서 폭발합니다. 이 글은 S/4HANA(2022 이상 기준, ECC 6.0에도 대부분 동일하게 적용)의 실적확인-활동수량-가공비 전기 구조를 해부하고, 누락이 원가차이를 어떻게 왜곡하는지, 그리고 이를 탐지·예방하는 실무 방법을 다룹니다.

  • 실적확인이 활동유형 × 활동수량 × 단가로 가공비를 오더에 태우는 메커니즘
  • 표준원가(목표원가)와 실제원가가 갈라지는 지점과 차이 계산 로직
  • 실적확인 누락 시 KKS1 차이분석이 왜곡되는 구체적 흐름
  • 누락 오더를 잡아내는 CDS/ABAP 점검 도구 구현

이 글을 읽기 전에 알아두면 좋은 것

생산오더 라이프사이클(생성 → 릴리스 → 출고 → 실적확인 → 입고 → TECO → 정산)의 기본 흐름, CO 모듈의 원가요소(Cost Element)와 활동유형(Activity Type) 개념, 그리고 트랜잭션 CO11N·KKS1·KO88을 한 번이라도 실행해 본 경험이 있다면 이해가 훨씬 빠릅니다. ABAP 예제는 CDS 뷰와 클래식 리포트 수준이므로 SELECT 문법만 알아도 따라올 수 있습니다.

검증 환경과 사전 설정

예제는 S/4HANA 2023 FPS01 온프레미스 환경에서 검증한 구성을 기준으로 설명하며, S/4HANA Cloud Private Edition에서도 동일하게 동작합니다. 가상의 시나리오로 정밀기어 제조사 한빛정밀 수원공장(플랜트 HP01)을 사용합니다. 사전에 필요한 설정은 다음과 같습니다.

  • 작업장 WC_CNC01: CNC 가공 작업장. 코스트센터 CC_MACH1에 연결
  • 활동유형 3종: ZSET(셋업시간), ZMCH(기계시간), ZLAB(노무시간) — 각각 2차 원가요소 943100/943200/943300에 매핑
  • KP26 활동단가: ZMCH 시간당 42,000원, ZLAB 시간당 28,000원, ZSET 시간당 35,000원 (계획단가)
  • 자재 HB-GEAR-100: 표준원가 릴리스 완료(CK11N/CK24), 라우팅에 표준시간 등록
  • 오더유형 PP01, 확인 파라미터(OPK4)에서 실제활동 자동제안 활성화

실적확인이 가공비를 만드는 원리 — 티켓 게이트 비유

생산오더를 지하철 개찰구라고 생각해 보면 구조가 명확해집니다. 자재 출고(261 이동유형)는 앞문으로 들어오는 승객이고, 입고(101)는 뒷문으로 나가는 승객입니다. 그런데 가공비는 개찰구를 통과할 때 태그를 찍어야만 요금이 계산됩니다. 이 태그가 바로 실적확인이고, 요금 계산식이 활동수량 × 활동단가입니다.

CO11N에서 작업자가 "ZMCH 2.5시간"을 저장하면 시스템 내부에서는 다음 체인이 순차 실행됩니다.

  1. 확인 전표가 AFRU 테이블에 기록됩니다(오더번호, 작업번호, 활동수량 ISM01~ISM06).
  2. 작업장의 코스트센터/활동유형 조합으로 KP26 계획단가를 조회해 2.5h × 42,000원 = 105,000원을 산출합니다.
  3. 이 금액이 2차 원가요소 943200으로 코스트센터는 대변(credit), 생산오더는 차변(debit)에 동시 전기됩니다. CO 명세 항목은 COEP(S/4에서는 ACDOCA의 CO 라인)에 남습니다.
  4. 백플러시 설정이 있다면 자재 출고와 입고까지 같은 확인에서 연쇄 실행됩니다.

여기서 중요한 갈림길이 있습니다. 표준(목표)원가는 라우팅의 표준시간 × 계획단가로, 오더 생성 시점에 이미 계산되어 있습니다. 반면 실제원가는 확인된 활동수량 × 단가로만 쌓입니다. 즉 확인을 안 하면 실제 가공비는 0원인데 목표 가공비는 존재하는 비대칭이 생기고, 이 비대칭이 차이분석을 왜곡하는 씨앗이 됩니다.

누락 시나리오를 숫자로 따라가 보겠습니다. HB-GEAR-100 오더 100건 생산, 표준 가공비 300,000원, 재료비 700,000원이라고 합시다.

  • 정상: 차변 = 재료비 700,000 + 가공비 305,000(실제) / 대변 = 입고 1,000,000(표준) → 차이 +5,000원(가공비 초과)
  • 확인 누락: 차변 = 재료비 700,000만 존재 / 대변 = 입고 1,000,000 → 오더 잔액 −300,000원

누락 상태에서 KKS1을 돌리면 이 −300,000원이 수량차이(Quantity Variance)로 유리한(favorable) 차이처럼 계산됩니다. 실제로는 기계가 돌았고 코스트센터에는 비용이 쌓였는데, 오더는 "가공 없이 만들었다"고 주장하는 셈입니다. 정산(KO88/CO88)까지 실행되면 이 가짜 유리 차이가 손익으로 넘어가고, 코스트센터에는 회수되지 못한 비용이 부족흡수(under-absorption)로 남아 양쪽 장부가 동시에 왜곡됩니다. 월이 넘어간 뒤 뒤늦게 확인을 입력하면 이번엔 당월에 가공비만 잡혀 반대 방향 왜곡이 발생합니다. 기간 귀속까지 무너지는 것입니다.

단계별 실전 예제 — 확인 전기부터 누락 탐지 자동화까지

1단계: CO11N 확인과 원가 흐름 눈으로 검증하기

먼저 정상 흐름을 확인합니다. 생산오더 1000451(HB-GEAR-100, 100 EA)을 릴리스한 뒤 CO11N을 실행합니다.

  1. 오더 1000451, 작업번호 0020(CNC 가공) 입력 → 엔터
  2. 수율(Yield) 100 EA, 실제활동 탭에서 ZSET 0.5h / ZMCH 2.5h / ZLAB 2.0h 확인 — 표준값이 자동 제안되며, 실제와 다르면 반드시 수정
  3. 최종확인(Final Confirmation) 플래그 체크 후 저장

저장 후 CO03 → 이동 경로 원가 → 분석(Cost Analysis)에서 2차 원가요소 943xxx 라인이 차변에 생겼는지, KSB1로 코스트센터 CC_MACH1에 동일 금액이 대변 전기됐는지 교차 확인합니다. 이 대칭이 가공비 흡수 구조의 핵심입니다.

2단계: 누락 의심 오더를 찾는 CDS 뷰 — 실무 점검 시나리오

실무에서 가장 흔한 누락 패턴은 "입고는 됐는데 확인이 없는 오더"입니다. 입고수량(AFKO의 납품수량)과 확인수량(AFRU 합계)을 대조하는 CDS 뷰를 만듭니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '실적확인 누락 의심 오더'
define view entity ZI_MissingConfCheck
  as select from afko
    inner join   afpo on afpo.aufnr = afko.aufnr
    left outer join (
      select aufnr, sum(lmnga) as conf_qty
        from afru
        where stokz = '' and stzhl = '00000000'  -- 취소전표 제외
        group by aufnr
    ) as conf on conf.aufnr = afko.aufnr
{
  key afko.aufnr                as OrderNumber,
      afpo.matnr                as Material,
      afpo.wemng                as GoodsReceiptQty,
      coalesce(conf.conf_qty, 0) as ConfirmedQty,
      afpo.wemng - coalesce(conf.conf_qty, 0) as GapQty
}
where afpo.wemng > 0
  and afpo.wemng > coalesce(conf.conf_qty, 0)

핵심은 stokz(역확인 플래그)와 stzhl(취소 카운터)로 CO13 취소분을 걸러내는 부분입니다. 이를 빼먹으면 취소된 확인도 유효 수량으로 집계되어 누락을 놓칩니다. 이 뷰를 호출하는 점검 리포트에는 예외 처리와 로그를 넣습니다.

REPORT zpp_conf_gap_check.

PARAMETERS: p_werks TYPE werks_d DEFAULT 'HP01' OBLIGATORY.

START-OF-SELECTION.
  TRY.
      SELECT * FROM zi_missingconfcheck
        WHERE OrderNumber IN ( SELECT aufnr FROM aufk
                                 WHERE werks = @p_werks )
        INTO TABLE @DATA(lt_gap).

      IF lt_gap IS INITIAL.
        MESSAGE '확인 누락 의심 오더 없음' TYPE 'S'.
        RETURN.
      ENDIF.

      " 애플리케이션 로그(BAL)에 결과 적재 — 감사 추적용
      DATA(lo_log) = cl_bali_log=>create_with_header(
        header = cl_bali_header_setter=>create(
                   object = 'ZPP' subobject = 'CONFGAP' ) ).
      LOOP AT lt_gap INTO DATA(ls_gap).
        lo_log->add_item( cl_bali_free_text_setter=>create(
          severity = if_bali_constants=>c_severity_warning
          text     = |오더 { ls_gap-OrderNumber } 미확인 { ls_gap-GapQty } EA| ) ).
      ENDLOOP.
      cl_bali_log_db=>get_instance( )->save_log( lo_log ).

      cl_salv_table=>factory( IMPORTING r_salv_table = DATA(lo_alv)
                              CHANGING  t_table      = lt_gap ).
      lo_alv->display( ).
    CATCH cx_salv_msg cx_bali_runtime INTO DATA(lx).
      MESSAGE lx->get_text( ) TYPE 'E'.
  ENDTRY.

3단계: 프로덕션 운영 — 마감 전 게이트로 격상

점검 리포트를 사람이 돌리는 방식은 반드시 구멍이 납니다. 결산 프로세스에 강제 게이트로 넣는 것이 일반적으로 권장되는 방식입니다.

  1. 배치 자동화: 위 리포트를 SM36 배치잡으로 매일 06:00 실행, 결과가 있으면 메일/워크플로 발송. 마감 D-2일부터는 하루 2회로 상향
  2. 차이분석 전 순서 고정: 미결확인 처리 → COGI(오류 자재이동) 소진 → 실제활동단가 재계산(KSII, 실제단가 사용 시) → WIP 산정(KKAX/KKAO) → KKS1 → 정산(CO88). 이 순서가 깨지면 어떤 점검도 무의미합니다
  3. 성능: 오더 수만 건 환경에서는 CDS 뷰에 플랜트·기간 필터를 파라미터로 밀어 넣고, AFRU 서브쿼리 집계가 인덱스(AUFNR)를 타는지 SQL 트레이스(ST05)로 확인합니다. 위 뷰는 HP01 3만 오더 기준 1초 내 응답을 확인했습니다
  4. 권한/보안: 점검 리포트는 조회 전용 권한객체(C_AFRU_AWK 등)로 제한하고, CO13 역확인 권한은 별도 롤로 분리해 임의 취소로 인한 2차 왜곡을 막습니다
  5. 테스트: 품질계 클라이언트에서 "확인 없이 입고만 한 오더"를 의도적으로 만들어 리포트가 잡아내는지, 취소 확인이 제외되는지 회귀 테스트 케이스로 고정합니다

자주 겪는 문제와 해결 포인트

Q1. 확인은 했는데 오더에 가공비가 0원입니다. 가장 흔한 원인은 KP26 단가 미등록입니다. 새 회계연도에 코스트센터/활동유형 단가를 넘기지 않으면 수량은 기록되지만 금액이 0으로 전기됩니다. 확인 시점에 오류가 아니라 경고로만 뜨는 경우가 많아 놓치기 쉽습니다. KP26에서 해당 연도 단가를 확인하고, 이미 전기된 건은 MFN1(실제단가 재평가) 또는 확인 취소 후 재입력으로 보정합니다.

Q2. 마일스톤 확인을 쓰는데 중간 작업 가공비가 안 보입니다. 마일스톤 확인은 지정 작업만 확인하면 선행 작업이 자동 확인되는 방식입니다. 제어키(예: PP01 vs PP03)의 확인 설정이 잘못돼 자동 확인 대상에서 빠진 작업이 있는지 라우팅을 점검하세요. 자동 확인된 작업은 표준시간이 그대로 실제로 들어오므로, 실제 시간 편차가 큰 공정이라면 마일스톤 방식 자체를 재검토해야 합니다.

Q3. TECO 처리된 오더에 뒤늦게 누락을 발견했습니다. TECO 상태에서도 확인 입력은 가능합니다(오더 잠금 설정에 따라 다름). 다만 이미 정산·마감된 기간이라면 당기 전기가 되어 기간 왜곡이 생기므로, 금액이 중요하면 정산 취소(KO88 반전) 후 재정산까지 포함해 회계팀과 절차를 합의해야 합니다. 소액이면 당기 반영으로 처리하는 것이 일반적입니다.

Q4. KKS1에서 차이가 비정상적으로 유리하게 나옵니다. 이 글의 핵심 증상입니다. 목표원가 버전(0)의 가공비 대비 실제 가공비가 현저히 낮다면 확인 누락부터 의심하고, 2단계 리포트로 대상 오더를 추린 뒤 차이분석을 재실행하세요.

여기서 더 나아가려면

이 글의 구조를 이해했다면 다음 주제로 확장할 수 있습니다. 첫째, 실제활동단가(KSII)를 도입해 계획단가와 실제단가 차이까지 관리하는 방법. 둘째, 반복제조(REM)의 백플러시 기반 확인(MFBF)과 이산제조 확인의 원가 흐름 차이. 셋째, S/4HANA의 이벤트 기반 생산원가(Event-Based Production Cost Posting)로 월말 일괄 계산 없이 실시간 WIP/차이를 잡는 방식. 넷째, Fiori 앱 "Confirm Production Operation"과 API(API_PROD_ORDER_CONFIRMATION_2_SRV)를 이용한 MES 연동 자동 확인으로 누락을 원천 차단하는 아키텍처입니다.

댓글 0

아직 댓글이 없습니다.