왜 평가클래스 하나가 회계전표를 바꾸는가 — 이 글에서 다루는 것
구매 담당자가 MIGO로 입고를 저장하는 순간, SAP는 사람에게 계정과목을 묻지 않고 스스로 재고 계정을 골라 회계전표를 만듭니다. 이 자동 판단의 출발점이 자재유형(Material Type)이고, 실제로 계정을 지목하는 열쇠가 평가클래스(Valuation Class)입니다. 이 글은 자재유형 → 평가클래스 → 자동계정결정(OBYC) → 총계정원장으로 이어지는 연결고리를 실무 시나리오로 따라가며, 잘못 설정했을 때 재무제표가 어떻게 왜곡되는지까지 다룹니다. 읽고 나면 다음을 스스로 점검할 수 있습니다.
- 자재유형이 평가클래스 후보를 제한하는 원리(계정범주참조)를 설명할 수 있다
- OBYC에서 BSX/WRX/GBB 트랜잭션 키의 역할을 구분할 수 있다
- 입고 전표의 차변·대변 계정이 어디서 결정됐는지 역추적할 수 있다
- 평가클래스 오지정 사고를 예방·복구하는 절차를 세울 수 있다
읽기 전에 갖추면 좋은 배경
자재마스터(MM01/MM02)의 회계 뷰를 열어본 경험, 구매오더(ME21N)와 입고(MIGO)의 기본 흐름, 그리고 차변·대변으로 구성되는 회계전표의 기초 개념이 있으면 충분합니다. FI 결산 경험은 없어도 되지만, 재고자산이 재무상태표 항목이라는 감각은 필요합니다. IMG(SPRO) 화면을 처음 본다면 4번 섹션의 경로 설명을 천천히 따라오면 됩니다.
실습 환경과 버전 기준
이 글은 SAP S/4HANA 2023 온프레미스(FPS02)를 기준으로 작성했으며, 화면 구성 차이만 있을 뿐 ECC 6.0에서도 개념과 트랜잭션 코드는 동일하게 적용됩니다. 준비물은 다음과 같습니다.
- IMG 설정 권한이 있는 개발(DEV) 클라이언트 — 운영 환경에서 직접 실험하지 않는 것이 일반적으로 권장됩니다
- 주요 트랜잭션: OMS2(자재유형), OMSK(평가클래스), OBYC(자동계정결정), OMWD(평가그룹핑코드), MM01/MM02, ME21N, MIGO, FB03
- 테스트용 플랜트와 회사코드가 연결된 상태(OX18, OB62 확인)
참고로 S/4HANA에서는 자재원장(Material Ledger)이 필수 활성화 대상이므로, 평가 데이터는 MBEW 호환 뷰와 ACDOCA 양쪽에서 확인할 수 있습니다.
핵심 개념 — 자재유형에서 총계정원장까지 이어지는 세 개의 고리
이 구조를 아파트 우편함에 비유해 보겠습니다. 자재유형은 "몇 동 주민인지"를 정하고(1동 주민은 1동 우편함 구역만 사용 가능), 평가클래스는 그 구역 안에서 "몇 호 우편함인지"를 지목하며, OBYC는 우편함 번호와 실제 우편함(G/L 계정)을 연결한 배치도입니다. 집배원(MIGO, 생산오더 입고 등)은 배치도만 보고 우편물을 넣습니다.
고리 1 — 자재유형과 계정범주참조. ROH(원자재), HALB(반제품), FERT(완제품) 같은 자재유형은 OMS2에서 계정범주참조(Account Category Reference)라는 중간 키에 연결됩니다. 표준 기준으로 ROH은 0001, HALB는 0007, FERT는 0009입니다. 자재유형이 평가클래스를 직접 제한하는 것이 아니라, 이 중간 키가 허용 목록의 실체라는 점이 자주 오해되는 부분입니다.
고리 2 — 계정범주참조와 평가클래스. OMSK에서 각 계정범주참조에 어떤 평가클래스들이 속하는지 정의합니다. 예를 들어 0001에 3000·3001·3005를 묶어두면, ROH 자재의 회계 뷰에서는 이 세 가지만 선택할 수 있습니다. FERT용 7920을 입력하려 하면 시스템이 즉시 거부합니다. 즉 자재유형은 "선택지의 울타리"입니다.
고리 3 — 평가클래스와 G/L 계정(OBYC). OBYC에서는 업무 상황을 뜻하는 트랜잭션 키별로 평가클래스와 계정을 매핑합니다. 핵심 키는 세 가지입니다.
- BSX: 재고 계정 자체(재무상태표 항목). 입고 시 차변, 출고 시 대변
- WRX: 입고/송장 미착 정산 계정(GR/IR)
- GBB: 상대계정 묶음. 계정수정자(VBR=원가센터 소비, AUF=생산오더 입고 상대, VAX/VAY=판매출고)로 세분화
여기에 평가그룹핑코드(OMWD)가 평가영역들을 묶어 매핑 테이블의 행 수를 줄여주고, 모든 매핑은 계정과목표(Chart of Accounts) 단위로 관리됩니다. 결국 하나의 입고 전표는 자재유형이 허용한 평가클래스가 OBYC 배치도를 통과해 만들어진 결과물입니다.
실전 구성 3단계
가상의 스마트 도어락 제조사 "한빛시큐텍"의 사례로 진행합니다. 구리 코일(원자재) RM-CU-COIL, 제어 PCB 모듈(반제품) SF-PCB-CTRL, 완성품 도어락(완제품) FG-DLK300을 다룹니다.
1단계 — 기본 매핑 만들기. 먼저 자재유형별 허용 평가클래스와 재고 계정을 설계합니다.
| 자재유형 | 계정범주참조 | 평가클래스 | BSX 재고계정 | 계정 성격 |
|---|---|---|---|---|
| ROH | 0001 | 3000 / 3005(전자부품) | 13010100 / 13010200 | 원재료 |
| HALB | 0007 | 7900 | 13030100 | 반제품 |
| FERT | 0009 | 7920 | 13050100 | 제품 |
설정 순서는 OMSK에서 평가클래스 3005를 생성해 0001에 배정 → OBYC의 BSX에서 (평가그룹핑코드 H100, 평가클래스 3005) 행에 13010200을 입력 → MM01로 RM-CU-COIL의 회계1 뷰에 평가클래스 3005를 지정하는 흐름입니다. 검증은 구매오더 후 MIGO 입고 한 건이면 충분합니다. 단가 5,000원 × 100EA 입고 시 기대 전표는 다음과 같습니다.
-- 기대 회계전표 (FB03로 확인)
차변 13010200 원재료-전자부품 500,000 -- BSX + 평가클래스 3005
대변 21050100 GR/IR 미착정산 500,000 -- WRX
2단계 — 오지정 사고 시나리오와 추적. 실무에서 가장 흔한 사고는 완제품 FG-DLK300 생성 시 담당자가 평가클래스를 7900(반제품)으로 잘못 고르는 경우입니다. FERT와 HALB의 계정범주참조가 분리돼 있다면 시스템이 막아주지만, 만약 프로젝트 초기에 7900을 0009에도 배정해 두었다면 저장이 통과됩니다. 이후 생산오더 입고 시 제품 계정 13050100 대신 반제품 계정 13030100에 차변이 발생하고, 월말에 "제품 계정 잔액은 그대로인데 실물 완제품만 늘어나는" 불일치가 재무팀 결산에서 발견됩니다. 다음 점검 쿼리(또는 SE16N)로 오지정 자재를 정기적으로 걸러내는 것이 좋습니다.
-- 자재유형과 평가클래스 조합 점검 (개념 예시)
SELECT a.matnr, a.mtart, b.bwkey, b.bklas
FROM mara AS a
JOIN mbew AS b ON a.matnr = b.matnr
WHERE ( a.mtart = 'FERT' AND b.bklas <> '7920' )
OR ( a.mtart = 'HALB' AND b.bklas <> '7900' );
ABAP 검증 리포트로 만들 때는 예외 조합을 화이트리스트 테이블로 관리하고, 발견 건은 로그(BAL_LOG_CREATE 계열)로 남겨 감사 추적이 가능하게 합니다.
" 오지정 검출 시 처리 골격
LOOP AT lt_check INTO DATA(ls_chk).
IF ls_chk-bklas <> lv_expected.
MESSAGE i398(00) WITH ls_chk-matnr '평가클래스 불일치' ls_chk-bklas.
" 알림 큐 적재 후 담당 조직에 워크플로 통지
ENDIF.
ENDLOOP.
3단계 — 운영 반영과 통제. 재고가 이미 있는 자재의 평가클래스를 MM02로 바꾸려 하면 시스템이 오류로 저장을 막는 것이 기본 동작입니다(당기·전기 재고 및 미결 구매오더 존재 시). 정석 절차는 ① 미결 PO/생산오더 정리 → ② 이동유형으로 재고를 0으로 소진(예: 임시 소비 후 재입고) 또는 신규 자재코드로 전환 → ③ 평가클래스 변경 → ④ 재입고입니다. 이때 소진과 재입고의 차변·대변이 서로 다른 계정에 발생하므로 FI 담당자와 사전 합의가 필요합니다. 아울러 OBYC 변경 권한은 별도 권한 역할로 분리하고, 운영 반영 전 QAS에서 MB5L(재고-계정 잔액 대사)로 회계 정합성을 검증하는 절차를 이관 체크리스트에 포함하는 방식이 일반적으로 권장됩니다.
자주 겪는 문제와 해결법
Q1. MIGO 입고 시 "트랜잭션 키 BSX에 대한 계정을 결정할 수 없음(M8147 계열)" 오류가 납니다.
해당 자재의 평가클래스와 플랜트의 평가그룹핑코드 조합이 OBYC BSX 테이블에 없는 경우입니다. OMWD에서 평가영역의 그룹핑코드를 확인하고, OBYC에서 정확히 그 조합의 행을 추가하세요. 계정과목표를 잘못 고른 채 매핑을 입력하는 실수도 흔합니다.
Q2. 자재마스터에서 원하는 평가클래스가 드롭다운에 아예 안 보입니다.
자재유형에 연결된 계정범주참조에 그 평가클래스가 배정되지 않은 것입니다. OMSK에서 배정을 추가하면 되지만, "울타리를 넓히는" 결정이므로 오지정 위험이 함께 커집니다. 정말 그 자재유형에 필요한지 먼저 검토하세요.
Q3. 평가클래스를 바꿨는데 기존 재고 금액은 옛 계정에 남아 있습니다.
평가클래스 변경은 과거 전표를 소급 수정하지 않습니다. 변경 시점 이후의 이동만 새 계정으로 갑니다. 잔액을 옮기려면 재고를 소진 후 재입고하거나 FI 수동 대체 전표로 조정해야 하며, 후자는 MM-FI 대사(MB5L)가 깨질 수 있어 신중해야 합니다.
Q4. 원자재를 원가센터로 출고했는데 소비 계정이 이상합니다.
BSX가 아니라 GBB-VBR 매핑을 봐야 합니다. GBB는 계정수정자별로 행이 나뉘므로, 어떤 수정자가 쓰였는지 전표의 이동유형에서 역추적한 뒤 해당 행을 고치세요.
이후 확장해볼 주제
이 연결고리를 이해했다면 다음 순서로 넓혀가기를 권합니다. 첫째, 분할평가(Split Valuation)로 같은 자재를 원산지·품질등급별로 다른 평가유형·계정에 태우는 구성. 둘째, 가격결정 방식(표준가 S vs 이동평균가 V)과 PRD(가격차이) 계정의 관계. 셋째, S/4HANA 자재원장의 실제원가 결산이 평가클래스 기반 계정 결정과 만나는 지점. 넷째, 판매출고(GBB-VAX/VAY)와 매출원가 계정 흐름까지 이어 보면 MM-SD-FI 통합 그림이 완성됩니다.
운영 반영 전 점검 체크리스트
새 자재유형이나 평가클래스를 운영계에 반영하기 전, 아래 항목을 순서대로 확인하면 오지정 사고의 상당수를 사전에 걸러낼 수 있습니다.
- OMSK에서 신규 평가클래스가 의도한 계정범주참조 하나에만 배정돼 있는지 — 여러 참조에 중복 배정하면 "울타리"가 무너집니다
- OBYC의 BSX·WRX·GBB 세 트랜잭션 키 모두에 대해 (평가그룹핑코드, 평가클래스) 조합 행이 빠짐없이 등록됐는지
- 테스트 플랜트에서 입고(MIGO) → 회계전표 조회(FB03)까지 한 사이클을 직접 돌려 차변·대변 계정이 설계값과 일치하는지
- 기존 자재의 평가클래스를 바꾸는 경우, 대상 자재의 재고수량이 0인지(미결 PO·생산오더 포함) 사전 확인했는지
- OBYC 변경 권한과 자재마스터 변경 권한이 서로 다른 담당자에게 분리돼 있는지(직무분리 통제)
- 변경 내역을 이관 문서에 기록해, 추후 계정 불일치 발생 시 원인 추적이 가능한지
이 여섯 가지를 습관처럼 점검하면, 평가클래스 하나가 조용히 재무제표를 흔드는 사고를 결산 이후가 아니라 설정 단계에서 막을 수 있습니다.
댓글 0
아직 댓글이 없습니다.