입고 한 건이 G/L 계정을 스스로 찾아가는 과정, 왜 알아야 하나
MIGO에서 입고를 저장하는 순간 재무 전표가 자동으로 생성되고, 차변에는 재고 계정, 대변에는 GR/IR 계정이 정확히 잡힙니다. 사용자는 계정번호를 한 글자도 입력하지 않았는데 말입니다. 이 글은 그 자동전기의 심장인 OBYC 계정결정을 다룹니다. 이동유형에 붙은 거래키와 자재의 평가클래스가 조합되어 G/L 계정이 결정되는 전체 경로를, 가상의 제조사 시나리오와 입고 전표 한 건으로 끝까지 추적합니다.
이 글을 끝까지 읽으면 다음을 할 수 있게 됩니다.
- 이동유형 → 거래키 → 평가클래스 → G/L 계정으로 이어지는 결정 체인을 순서대로 설명
- BSX와 WRX 거래키의 역할 구분 및 입고 전표의 차대변 매핑 해석
- OMWB 시뮬레이션으로 전기 전 계정결정 결과를 미리 검증
- M8147 계정결정 오류 발생 시 원인 테이블(T030)을 직접 추적해 해결
미리 갖추면 좋은 배경
FI 쪽에서는 차변/대변 개념과 계정과목표(Chart of Accounts)의 역할, G/L 계정 마스터 구조를 알고 있어야 합니다. MM 쪽에서는 구매오더(ME21N) → 입고(MIGO) → 송장검증(MIRO)으로 이어지는 조달 흐름과, 자재 마스터에 회계 뷰가 존재한다는 사실 정도면 충분합니다. IMG(SPRO) 화면을 열어 설정 노드를 찾아본 경험이 있으면 실습 속도가 훨씬 빨라집니다.
실습 환경과 가상 시나리오 정의
이 글의 화면과 설정 값은 SAP S/4HANA 2023 FPS01(온프레미스) 기준입니다. 계정결정 로직 자체는 ECC 6.0에서도 동일하게 동작하지만, S/4HANA에서는 자재원장(Material Ledger)이 기본 활성화되어 있어 전표 라인 구성이 일부 다를 수 있다는 점만 유의하면 됩니다.
예제 전반에서 사용할 가상 시나리오는 다음과 같습니다. 모든 값은 이 글을 위해 창작한 것입니다.
| 항목 | 값 | 설명 |
|---|---|---|
| 회사코드 | 7100 | 한빛정밀(가상 제조사) |
| 플랜트 | 7110 | 안산 공장 |
| 계정과목표 | ZKR1 | 한빛정밀 운영 계정과목표 |
| 평가그룹코드 | K710 | OMWD에서 플랜트 7110에 할당 |
| 자재 | RM-4471 | 베어링 하우징(원자재, 이동평균가 V) |
| 평가클래스 | Z310 | 원자재-기계부품 |
필요 권한은 OBYC·OMWB·MIGO 실행 권한과 SE16N 조회 권한입니다. OBYC는 운영 환경에서 직접 수정하지 않는 것이 일반적이므로, 개발기(DEV)에서 설정 후 트랜스포트로 이관하는 전제를 따릅니다.
계정결정 체인 — 네 개의 좌표가 만나 하나의 계정이 된다
OBYC 자동 계정결정은 택배 분류 시스템에 비유할 수 있습니다. 택배(자재 이동)가 터미널에 도착하면 송장에 찍힌 네 가지 정보 — 어느 권역인지(계정과목표), 어느 지역 허브인지(평가그룹코드), 어떤 종류의 처리인지(거래키), 어떤 상품군인지(평가클래스) — 를 조합해 최종 배송지(G/L 계정)를 결정합니다. 이 매핑 결과가 저장되는 곳이 테이블 T030입니다.
체인을 단계별로 풀면 이렇습니다.
- 이동유형이 거래키를 지목합니다. 이동유형 101(구매오더 대비 입고)에는 값 갱신(value string) 규칙이 연결되어 있고, 이 규칙이 "재고 계정에는 BSX, 상대 계정에는 WRX"라는 거래키 조합을 내놓습니다. 이 연결 정보는 T156 계열 테이블에 저장되며 OMJJ에서 확인할 수 있습니다.
- 자재가 평가클래스를 들고 옵니다. 자재 RM-4471의 회계1 뷰에 평가클래스 Z310이 입력되어 있습니다. 자재유형이 어떤 평가클래스를 허용하는지는 계정범주참조(OMSK)가 통제합니다.
- 플랜트가 평가그룹코드를 결정합니다. OMWD에서 평가영역 7110에 그룹코드 K710이 할당되어 있습니다. 여러 플랜트가 같은 계정 체계를 쓴다면 하나의 그룹코드로 묶어 T030 엔트리 수를 줄일 수 있습니다.
- 네 좌표로 T030을 조회합니다. ZKR1 + BSX + K710 + Z310 → 재고 계정, ZKR1 + WRX + K710 → GR/IR 계정이 반환됩니다.
거래키별 성격도 구분해 두어야 합니다. BSX는 재고 대차대조표 계정 전기, WRX는 GR/IR 정산 계정, GBB는 상쇄 전기(계정수정자 VBR·BSA 등으로 세분화), PRD는 가격차이 전기를 담당합니다. BSX는 평가클래스별 구분이 사실상 필수인 반면, WRX는 평가클래스를 공란으로 두고 하나의 GR/IR 계정으로 모으는 구성이 일반적입니다.
실전 예제 — 입고 전표 한 건을 세 단계로 추적한다
1단계: 기본 — 101 입고 전표의 계정결정 경로 확인
구매오더 6200001874(자재 RM-4471, 100 EA, 단가 12,500원)에 대해 MIGO로 입고(이동유형 101)를 전기하면 자재문서 5000442871과 함께 다음 회계전표가 생성됩니다.
-- 생성된 회계전표 라인 (개념적 표현)
-- 차변: 1131000 원재료-기계부품 1,250,000 (거래키 BSX, 평가클래스 Z310)
-- 대변: 2192500 GR/IR 정산계정 1,250,000 (거래키 WRX)
-- T030에서 이 결정을 재현하는 조회 (SE16N 또는 DB 조회)
SELECT ktopl, ktosl, bwmod, bklas, konts, konth
FROM t030
WHERE ktopl = 'ZKR1'
AND ktosl IN ('BSX', 'WRX')
AND bwmod = 'K710';
-- 결과:
-- ZKR1 | BSX | K710 | Z310 | 1131000 | 1131000
-- ZKR1 | WRX | K710 | (공란) | 2192500 | 2192500
OBYC 화면에서는 거래키 BSX를 더블클릭 → 계정과목표 ZKR1 입력 → 평가수정(K710)과 평가클래스(Z310)별 계정 행을 확인하는 순서입니다. 전기 전에 검증하고 싶다면 OMWB의 시뮬레이션 기능에 플랜트 7110, 자재 RM-4471, 이동유형 101을 넣으면 어떤 거래키에 어떤 계정이 잡히는지 표로 미리 보여줍니다. 운영 반영 전 검증 도구로 적극 권장됩니다.
2단계: 실무 — M8147 오류 재현과 원인 로깅
신규 평가클래스 Z340(반제품-가공품)을 만든 뒤 T030에 BSX 엔트리를 추가하지 않고 입고를 시도하면 오류 M8147("계정결정 ... 불가")로 전기가 차단됩니다. 어떤 좌표 조합이 비었는지 빠르게 진단하는 점검용 ABAP을 만들어 두면 유용합니다.
REPORT zmm_check_obyc.
" 평가클래스별 BSX/WRX 엔트리 존재 여부 점검 (오류 M8147 사전 진단)
PARAMETERS: p_ktopl TYPE t030-ktopl DEFAULT 'ZKR1',
p_bwmod TYPE t030-bwmod DEFAULT 'K710',
p_bklas TYPE t030-bklas DEFAULT 'Z340'.
START-OF-SELECTION.
SELECT SINGLE konts FROM t030 INTO @DATA(lv_bsx)
WHERE ktopl = @p_ktopl AND ktosl = 'BSX'
AND bwmod = @p_bwmod AND bklas = @p_bklas.
IF sy-subrc <> 0.
" 애플리케이션 로그(BAL)로 남겨 운영 모니터링과 연계
MESSAGE |BSX 엔트리 없음: { p_ktopl }/{ p_bwmod }/{ p_bklas }|
TYPE 'E'.
ELSE.
WRITE: / |BSX → G/L { lv_bsx } 확인됨|.
ENDIF.
실무에서 자주 만나는 변형이 가격차이입니다. 자재가 표준가(S) 관리이고 PO 단가가 표준가와 다르면, 차액이 BSX가 아닌 PRD 거래키로 빠집니다. 예를 들어 표준가 12,000원 자재를 12,500원에 100 EA 입고하면 차변 재고 1,200,000(BSX) + 차변 가격차이 50,000(PRD, 계정 5310100) / 대변 GR/IR 1,250,000(WRX) 구조가 됩니다. PRD 엔트리가 비어 있으면 이 경우에만 오류가 터지므로, 신규 평가클래스 생성 시 BSX·WRX·PRD·GBB(주요 수정자)를 한 세트로 점검하는 것이 안전합니다.
3단계: 프로덕션 — 이관·정합성 검증·권한 통제
OBYC 설정은 클라이언트 종속 커스터마이징이므로 운영 직접 수정 대신 트랜스포트 이관이 원칙입니다. 이관 전후로 개발기·운영기의 T030을 비교해 누락을 잡아내는 정합성 리포트를 배치로 돌리는 구성을 권장합니다.
" 프로덕션 정합성 점검 핵심 로직 (배치 스케줄링용)
" 사용 중인 모든 평가클래스에 대해 필수 거래키 엔트리 존재 검증
DATA(lt_required) = VALUE string_table( ( `BSX` ) ( `PRD` ) ).
SELECT DISTINCT bklas FROM mbew
WHERE bwkey = '7110' AND bklas <> ''
INTO TABLE @DATA(lt_bklas).
LOOP AT lt_bklas INTO DATA(ls_bklas).
LOOP AT lt_required INTO DATA(lv_key).
SELECT COUNT(*) FROM t030
WHERE ktopl = 'ZKR1' AND ktosl = @lv_key
AND bwmod = 'K710' AND bklas = @ls_bklas-bklas.
IF sy-dbcnt = 0.
" 결과를 스풀/메일로 발송 — 월마감 전 필수 점검 항목
WRITE: / |누락: { lv_key } / { ls_bklas-bklas }|.
ENDIF.
ENDLOOP.
ENDLOOP.
보안 관점에서는 OBYC 실행 권한을 FI-MM 통합 담당 소수에게만 부여하고, 테이블 감사 로깅(rec/client 설정)으로 T030 변경 이력을 남기는 구성이 일반적입니다. 테스트 관점에서는 이관 후 OMWB 시뮬레이션을 대표 자재유형별로 1건씩 수행하고, 품질기(QAS)에서 101/102(입고 취소)/561(기초재고) 등 주요 이동유형의 전표를 실제 전기해 차대변 계정을 확인하는 절차를 체크리스트화하면 사고를 크게 줄일 수 있습니다.
자주 터지는 지점과 문답 정리
Q1. M8147 오류인데 BSX 엔트리는 분명히 있습니다. 왜 실패하나요?
좌표 네 개 중 하나가 어긋난 경우가 대부분입니다. 특히 평가그룹코드를 놓치기 쉽습니다. OMWD에서 해당 플랜트의 그룹코드가 K710이 아닌 다른 값(또는 공란)이면, K710으로 등록한 T030 행은 조회되지 않습니다. OMWB 시뮬레이션이 실제 조회 좌표를 그대로 보여주므로 가장 빠른 진단 도구입니다.
Q2. 입고 취소(102)를 했는데 계정이 입고와 다르게 잡힐 수 있나요?
101과 102는 같은 값 갱신 규칙을 공유하므로 같은 거래키(BSX/WRX)로 역분개되는 것이 정상입니다. 다르게 잡힌다면 그 사이에 OBYC 매핑이나 자재의 평가클래스가 변경된 경우입니다. 재고가 있는 상태에서 평가클래스를 바꾸면 이런 불일치가 생기므로, 변경은 재고 0 시점 또는 정해진 절차를 거쳐 수행해야 합니다.
Q3. WRX에 평가클래스별 계정을 나눠도 되나요?
기술적으로 가능하며 OBYC의 "규칙(Rules)" 버튼에서 평가클래스 체크를 켜면 됩니다. 다만 GR/IR은 송장검증 시점에 반제되는 임시 계정이라 세분화 실익이 적고, MIRO와 MIGO의 결정 결과가 어긋나면 반제가 꼬일 수 있어 단일 계정 운영이 일반적으로 권장됩니다.
Q4. 이동평균가(V) 자재인데 PRD로 금액이 빠졌습니다.
재고 수량이 소진된 상태에서 송장 차액이 들어오는 등, 재고에 얹을 수량이 부족한 경우 이동평균가 자재도 차액이 PRD로 전기됩니다. 오류가 아니라 표준 동작이므로 PRD 계정은 V 자재만 쓰는 환경에서도 반드시 채워 두어야 합니다.
여기서 더 나아가면 만나는 주제들
이 글은 101 입고와 BSX/WRX 중심의 기본 경로를 다뤘습니다. 다음 확장 지점은 세 갈래입니다. 첫째, GBB 계정수정자 — 생산 출고(261, 수정자 VBR 계열)나 기초재고(561, BSA)처럼 상쇄 계정이 용도별로 갈라지는 구조. 둘째, 외주가공 계정결정 — BSV·FRL 거래키가 개입하는 543 이동의 전표 구조. 셋째, 자재원장(Material Ledger) — S/4HANA에서 실제원가계산 활성화 시 기말 차이 배부가 계정결정과 만나는 지점입니다. 분할평가(Split Valuation)를 쓰는 환경이라면 평가유형별 계정 분리도 함께 검토할 주제입니다.
댓글 0
아직 댓글이 없습니다.