IW21 통지 vs IW31 오더 — 비용 어디로 #shorts #SAP #PM

이 글이 답하는 질문

SAP PM(Plant Maintenance, S/4HANA에서는 Asset Management) 모듈을 처음 운영하는 현장에서 가장 자주 발생하는 데이터 왜곡이 하나 있습니다. 정비 담당자들이 설비 통지(Maintenance Notification)는 성실하게 등록하는데, 월말에 설비별 보전 원가를 뽑아 보면 금액이 0원에 가깝게 나오는 현상입니다. 원인은 단순합니다. 통지는 원가 오브젝트가 아니고, 비용은 오직 보전오더(Maintenance Order)에만 집계되기 때문입니다. 이 글에서는 통지와 오더의 역할 분리 구조를 원리부터 짚고, 가상의 유압 프레스 설비 시나리오로 비용 흐름을 단계별로 따라가 봅니다.

• 통지(IW21)와 오더(IW31)의 책임 범위는 어떻게 다른가?
• 자재비·인건비·외주비는 각각 어떤 경로로 오더에 집계되는가?
• "통지만 있고 오더가 없는" 건은 어떻게 찾아내는가?
• 확인(Confirmation)과 정산(Settlement)까지 끝나야 원가센터에 비용이 도달하는 이유는 무엇인가?

이 글을 보기 전에

SAP GUI 기본 조작과 PM 마스터 데이터(설비 Equipment, 기능위치 Functional Location)의 개념을 알고 있으면 충분합니다. CO(관리회계) 쪽에서는 원가센터, 액티비티 유형, 정산(Settlement)이 무엇인지 정도의 감만 있으면 됩니다. ABAP 예제가 나오지만 SELECT 문을 읽을 수 있는 수준이면 따라올 수 있습니다.

테스트 환경

이 글의 화면 흐름과 테이블 구조는 SAP S/4HANA 2023 온프레미스 기준이며, ECC 6.0에서도 트랜잭션 코드와 핵심 테이블(QMEL, AUFK, AFIH, PMCO 등)은 동일하게 적용됩니다. 예제를 위해 다음이 준비되어 있다고 가정합니다.

• 통지 유형 Z1(고장 통지), 오더 유형 ZM01(돌발 정비)이 커스터마이징된 시스템
• 가상의 설비: 유압 프레스 EQ-PRS-4200, 기능위치 FL-P2-STMP-01, 담당 원가센터 CC-52100(프레스공정)
• 정비 작업장 WC-MECH1, 액티비티 유형 ZMH1(정비공수, KP26에서 시간당 단가 45,000원 유지)
• 권한: IW21/IW31/IW41 실행 권한과 테스트용 자재 SP-SEAL-88(유압 씰 키트) 재고

핵심 개념 — 신고서와 작업지시서, 그리고 지갑

통지와 오더의 관계는 병원에 비유하면 이해가 빠릅니다. 통지는 접수창구의 진료 신청서입니다. "언제, 어떤 설비가, 어떤 증상으로 멈췄다"라는 사실 기록이 목적이며, 여기에는 지갑이 달려 있지 않습니다. 반면 오더는 진료 차트이자 수납 계산서입니다. 어떤 처치(오퍼레이션)를 누가 몇 시간 했고, 어떤 부품을 썼는지가 전부 오더에 금액으로 쌓입니다.

테이블 관점에서 보면 구조가 명확합니다.

구분	통지	보전오더
대표 트랜잭션	IW21/IW22/IW23, 리스트 IW28/IW29	IW31/IW32/IW33, 리스트 IW38/IW39
헤더 테이블	QMEL (+ QMIH)	AUFK + AFIH + AFKO
담는 정보	현상·원인·손상 코드, 고장 시각, 가동중단 여부	오퍼레이션(AFVC), 자재예약(RESB), 실적(AFRU)
원가 집계	불가 — CO 오브젝트 아님	PMCO/COEP에 실제원가 집계 후 정산

비용이 오더에 도달하는 경로는 일반적으로 세 갈래입니다. 첫째, 인건비는 IW41 확인(Confirmation) 시 입력한 실적 시간 × 액티비티 단가로 계산되어 CO 내부 배부로 흘러듭니다. 둘째, 자재비는 오더 예약 자재를 이동유형 261로 출고(MIGO)하는 순간 재고 금액이 오더 차변에 기표됩니다. 셋째, 외주비는 오더에서 파생된 구매오더의 서비스 검수 시점에 귀속됩니다. 그리고 마지막 관문이 정산(KO88/KO8G)입니다. 오더에 모인 비용은 정산 규칙(COBRB)에 따라 원가센터 CC-52100 등으로 넘어가야 비로소 설비보전 원가 분석에 잡힙니다. 즉 "통지 등록 → 오더 생성 → 릴리스 → 출고/확인 → 기술적 완료 → 정산"이라는 사슬에서 오더 이후 단계가 하나라도 빠지면, 그 정비 활동은 회계적으로 존재하지 않았던 일이 됩니다. 정비팀은 분명 일을 했는데 경영층 보고서에는 "이 설비는 보전비가 거의 안 든다"라고 나오는 왜곡이 이렇게 만들어집니다.

실전 예제 3단계

1단계 — 기본: 통지에서 오더까지 연결하기

야간 조업 중 프레스 EQ-PRS-4200에서 유압 누유가 발생했다고 가정합니다. 교대 조장은 IW21에서 통지 유형 Z1을 선택하고 설비, 현상 코드(누유), 고장 시작 시각과 가동중단 플래그를 입력합니다. 여기까지가 통지의 역할 전부입니다. 다음 날 정비 계획자는 통지 화면(IW22)에서 직접 오더 생성 버튼으로 오더 유형 ZM01의 오더를 만들거나, IW31에서 통지번호를 참조해 생성합니다. 이때 QMEL의 AUFNR 필드에 오더 번호가 채워지며 두 문서가 연결됩니다. 연결 여부는 SQL로 바로 점검할 수 있습니다.

-- 최근 45일간 오더가 연결되지 않은 고장 통지 (원가 누락 후보)
SELECT q.qmnum   AS 통지번호,
       q.qmart   AS 통지유형,
       q.equnr   AS 설비,
       q.qmdat   AS 통지일,
       q.qmtxt   AS 현상요약
  FROM qmel AS q
 WHERE q.qmart =  'Z1'
   AND q.aufnr =  ''          -- 후속 오더 없음
   AND q.qmdat >= '20260630'
 ORDER BY q.qmdat DESC;

오더가 생성되면 계획자는 오퍼레이션 0010에 작업장 WC-MECH1, 액티비티 유형 ZMH1, 계획공수 3시간을 넣고, 구성품 탭에 SP-SEAL-88 1EA를 예약한 뒤 릴리스합니다.

2단계 — 실무: 출고·확인 처리와 미확정 오더 감시

릴리스만으로는 여전히 비용이 0원입니다. 창고에서 MIGO로 예약 참조 출고(이동유형 261)를 하면 씰 키트 금액이, 정비원이 IW41에서 실적 2.5시간을 확인하면 인건비가 오더에 쌓입니다. 실무에서 가장 흔한 누락은 "작업은 끝냈는데 IW41을 안 친" 경우입니다. 릴리스 후 일정 기간이 지나도 실제원가가 없는 오더를 찾아 로그로 남기는 점검 리포트를 걸어두면 효과적입니다.

REPORT zpm_check_zero_cost_orders.

PARAMETERS: p_days TYPE i DEFAULT 7.

DATA(lv_limit) = cl_abap_context_info=>get_system_date( ) - p_days.

" 릴리스됐지만 실제원가(PMCO 값구분 4)가 전혀 없는 ZM01 오더
SELECT a~aufnr, a~ktext, h~equnr, a~idat1
  FROM aufk AS a
  INNER JOIN afih AS h ON h~aufnr = a~aufnr
  WHERE a~auart  = 'ZM01'
    AND a~idat1 <= @lv_limit          " 릴리스일 경과
    AND a~idat3  = '00000000'         " 아직 종료 안 됨
    AND NOT EXISTS (
          SELECT aufnr FROM pmco
           WHERE aufnr = a~aufnr
             AND wrttp = '04' )       " 실제원가 레코드 없음
  INTO TABLE @DATA(lt_orders).

IF lt_orders IS INITIAL.
  MESSAGE '점검 대상 없음: 모든 릴리스 오더에 원가 존재' TYPE 'S'.
  RETURN.
ENDIF.

LOOP AT lt_orders INTO DATA(ls_ord).
  " 응용 로그(BAL)에 기록 후 담당 계획자에게 워크플로 통지 연계
  WRITE: / ls_ord-aufnr, ls_ord-equnr,
           '릴리스 후 원가 미발생 — 확인/출고 누락 의심'.
ENDLOOP.

이 리포트를 배치로 매일 아침 돌리면, "확인 누락 → 월말 원가 0원" 사고를 사전에 차단할 수 있습니다.

3단계 — 프로덕션: 정산 규칙과 마감 체계 굳히기

오더에 비용이 쌓여도 정산 전까지는 원가센터 보고서(예: S_ALR 계열 원가센터 리포트)에 나타나지 않습니다. 프로덕션 운영에서는 다음 설정을 점검합니다.

1. 오더 유형 설정(SPRO → 플랜트 정비 → 오더 유형 구성, ECC의 OIOA에 해당)에서 ZM01에 정산 프로파일과 계획 프로파일이 지정되어 있는지 확인합니다.
2. 정산 프로파일(OKO7)의 허용 수신자에 원가센터(CTR)가 포함되고, 기본 수신자 규칙이 설비의 원가센터를 자동 제안하도록 구성합니다. 오더 생성 시 정산 규칙이 CC-52100으로 자동 생성되는지 IW32의 정산 규칙 화면에서 검증합니다.
3. 월말 마감 배치로 KO8G(집단 정산)를 오더 유형 ZM01 변형으로 스케줄링합니다. 정산 전 사전 점검 스니펫 예시는 아래와 같습니다.

" 정산 대상 사전 점검: 기술적완료(TECO)됐지만 미정산 잔액이 남은 오더
AUTHORITY-CHECK OBJECT 'K_ORDER'
  ID 'AUFART' FIELD 'ZM01'
  ID 'ACTVT'  FIELD '03'.
IF sy-subrc <> 0.
  MESSAGE '오더 조회 권한 없음' TYPE 'E'.
ENDIF.

SELECT p~aufnr, SUM( p~wrt01 + p~wrt02 + p~wrt03 ) AS balance
  FROM pmco AS p
  INNER JOIN aufk AS a ON a~aufnr = p~aufnr
  WHERE a~auart = 'ZM01'
    AND a~idat2 <> '00000000'      " 기술적 완료됨
    AND p~wrttp = '04'
  GROUP BY p~aufnr
  HAVING SUM( p~wrt01 + p~wrt02 + p~wrt03 ) <> 0
  INTO TABLE @DATA(lt_unsettled).

정산이 끝나면 KOB1(오더 실제 라인아이템)로 오더 측 흐름을, 원가센터 리포트로 수신 측 도착을 교차 검증합니다. QA 시스템에서는 "통지→오더→출고→확인→TECO→정산" 전체 사슬을 하나의 통합 테스트 시나리오로 고정해 두는 것이 권장됩니다.

자주 만나는 함정

Q1. 통지에 비용 필드가 없는데, 통지 화면에서 본 '비용' 탭은 무엇인가요? 통지 화면에서 보이는 비용 정보는 연결된 오더의 값을 참조 표시하는 것입니다. 오더가 없으면 항상 비어 있으며, 통지 자체에 기표되는 금액은 없습니다.

Q2. 오더를 만들고 릴리스까지 했는데 PMCO에 실제원가가 없습니다. 릴리스는 계획원가 확정 단계일 뿐입니다. MIGO 출고(261)와 IW41 확인이 실제원가를 만드는 트리거이므로, MSEG/AFRU에 해당 오더 참조 레코드가 있는지 먼저 확인하세요. KP26에 액티비티 단가가 0이면 확인을 해도 인건비가 0원으로 잡히는 점도 주의해야 합니다.

Q3. 정산했더니 비용이 엉뚱한 원가센터로 갔습니다. 오더 생성 시점의 설비 마스터 원가센터(ILOA의 계정지정)가 정산 규칙 기본값으로 복사됩니다. 설비의 원가센터를 나중에 바꿔도 이미 생성된 오더의 정산 규칙(COBRB)은 자동으로 바뀌지 않으므로 IW32에서 수동 수정이 필요합니다.

Q4. 통지 없이 IW31로 바로 오더를 만들어도 되나요? 기술적으로 가능하지만, 고장 이력(MTBF/MTTR 분석의 원천)이 QMEL에 남지 않아 신뢰성 분석이 무너집니다. 일반적으로 돌발 정비는 통지 선행을 규칙으로 강제하는 편이 좋습니다.

핵심 한 줄

통지는 현상을 접수하는 신고서일 뿐이고, 비용을 만드는 것은 오더뿐입니다 — 통지만 등록하고 오더를 릴리스·확인·정산까지 끌고 가지 않으면 그 정비는 회계상 없었던 일이 됩니다.

이어서 보면 좋은 글

역할 분리 구조를 이해했다면, 다음으로는 예방정비 체계로 확장해 보세요. 정비 계획(IP41/IP42)과 일정 실행(IP30)이 통지·오더를 자동 생성하는 구조, 오더 유형별 원가 분석을 위한 값범주(Value Category) 커스터마이징, 그리고 S/4HANA의 Fiori 앱 기반 정비 프로세스(Perform Maintenance Jobs, 단계별 Phase 모델)와의 차이를 비교해 보면 설비보전 원가 관리의 큰 그림이 완성됩니다.