SAP를 운영을 하던 중이던, 프로젝트 구축 중이던 표준 테이블만으로는 아 이테이블에 이 정보가 필요한데 하면서 부족한 순간이 꼭 옵니다. 회사 고유의 참조번호나 구분값을 전표 라인마다 남기고 싶은데, 표준 필드엔 그런 자리가 없거든요. 오늘은 이럴 때 쓰는 코딩 블록(Coding Block) 확장, 그리고 그 핵심인 CI_COBL과 OXK3 얘기를 실제 저희 쪽에 적용된 사례를 가지고 풀어보려고 합니다.
Coding Block, 정확히 뭘 말하는 걸까요
“Coding Block”이라는 용어 자체가 좀 모호하게 느껴질 수 있는데요, 실무적으로는 SAP 표준 FI 전표 구조·테이블에 고객사 전용 Z필드(보통 ZZ 또는 YY 접두어)를 확장해서, 전표 입력·저장·조회 전 과정에서 쓸 수 있게 만드는 방식을 말합니다. SAP도 이걸 Classic Coding Block Extension이라고 부르고, OXK3와 CI_COBL 구조로 확장한다고 설명하고 있습니다.
표준 FI 전표에는 기본적으로 이런 필드들이 있죠.
회사코드 BUKRS
전표번호 BELNR
계정 HKONT
금액 WRBTR
코스트센터 KOSTL
오더 AUFNR
그런데 회사에서 “전표 라인마다 참조 정보나 구분값도 같이 남기고 싶다”고 하면, 표준에는 그런 필드가 없습니다. Z테이블을 별도로 만들어서 관리할 수도 있지만, 코딩 블록을 쓰면 전표의 Account Assignment 영역 자체에 고객 필드를 얹을 수 있습니다. 바로 이 확장이 코딩 블록 확장입니다.
왜 그냥 BSEG에 Z필드를 추가하면 안 될까요
이게 사실 가장 중요한 부분입니다. ABAP 개발자 입장에서는 처음 보면 “BSEG에 Append Structure 하나 만들어서 필드 추가하면 되는 거 아닌가?” 싶을 수 있어요. 그런데 SAP FI 전표 처리는 BSEG 하나만 움직이는 구조가 아닙니다. 전표를 입력하는 순간부터 여러 내부 구조를 거치거든요.
FB01 / FB50 / FB60 / BAPI
↓
전표 입력 구조
↓
COBL
↓
FI Accounting Interface
↓
BSEG
↓
FI Document
그래서 BSEG에만 필드를 만들어 놓으면 이런 문제가 생길 수 있습니다.
FB01에서는 안 보입니다.
FB50에서는 값 전달이 안 됩니다.
Validation/Substitution에서 못 씁니다.
BAPI에서는 값이 사라집니다.
CO 쪽으로 전달되지 않습니다.
그래서 SAP가 공식적으로 제공하는 확장 포인트가 바로 코딩 블록입니다. SAP 공식 문서도 고객 필드를 추가하려면 먼저 코딩 블록에 필드를 포함시켜야 한다고 설명하고 있습니다.
핵심 구조는 결국 CI_COBL
코딩 블록에서 핵심은 CI_COBL입니다. CI는 Customer Include를 뜻하고요, 저희 쪽에 실제 적용된 사례를 OXK3에서 조회하면 이런 트리 구조로 보입니다.
코딩 블럭
├─ SAP 표준 계정 지정
└─ 고객 정의 계정 지정
└─ 고객 Include 구조
└─ CI_COBL (코딩블럭 고객 include)
├─ ZZXREF4 참조4
├─ ZZXREF5 참조5
├─ ZZKUNNR G/L고객
├─ ZZLIFNR G/L 공급처
├─ ZZGLSEP 계정구분
├─ ZZWRBTR 참조금액
└─ ZZDATE 참조일자
└─ 고객 APPEND 구조
보시면 ZZKUNNR, ZZLIFNR처럼 이름만 봐도 용도가 짐작되는 필드도 있고, ZZXREF4, ZZXREF5처럼 범용 참조값으로 열어둔 필드도 섞여 있습니다. 실무에서는 이렇게 “당장 뭐에 쓸지 확정은 안 됐지만 나중에 참조용으로 쓸 자리”를 미리 몇 개 잡아두는 경우도 꽤 있습니다. 그래서 실제 코딩 블록 하나 뚫자는 말이 나오면, 대부분은 “CI_COBL에 고객 필드를 추가해서 FI 전표에서 쓸 수 있게 만들자”는 뜻으로 통합니다.
여기서 헷갈리시면 안 되는 게, CI_COBL은 어디까지나 “확장 포인트”이고 실제로 필드를 정의하고 생성하는 작업은 OXK3에서 이뤄집니다.
실제 실행화면
실제로 손대는 T-code는 OXK3
ECC EHP6 환경에서는 가장 먼저 기억하실 T-code가 OXK3 - Edit Coding Block입니다. 위 화면도 바로 이 OXK3에서 “필드 추가” 메뉴로 들어가서 확인한 결과고요.
SAP 공식 가이드에 따르면 Basic Mode에서 고객 필드는 보통 ZZ 또는 YY로 시작해야 하고, 데이터 타입과 필드 설명 등을 정의한 다음 생성 프로세스를 실행합니다. 예를 들어 위 목록의 ZZKUNNR 같은 경우는 이렇게 정의되어 있습니다.
항목
값
Field Name
ZZKUNNR
Description
G/L고객
이런 식으로 OXK3에서 하나씩 필드를 정의하면, 결과적으로 CI_COBL-ZZKUNNR처럼 코딩 블록 구조에 필드가 생성되는 겁니다.
확장하면 BSEG에도 실제로 연결됩니다
ECC 기준으로 이 부분이 꽤 중요합니다. 예를 들어 전표가 이렇게 생겼다고 해보죠.
항목
값
회사코드
1000
전표번호
1900001234
연도
2026
Line
001
계정
G/L 계정
ZZKUNNR
100001
ZZGLSEP
A
코딩 블록 확장이 정상적으로 되어 있다면 이 고객 필드 값들이 전표 데이터와 함께 전달됩니다. 그래서 SE16N으로 BSEG를 조회하면 개념적으로 이렇게 보이게 되는 거죠.
실제로 SAP Community 사례에서도 OXK3로 생성한 필드가 CI_COBL, CI_COBL_BI, BSEG 등에 연결되는 사례가 확인됩니다.
그래도 아무 필드나 만들면 안 됩니다
코딩 블록이 강력한 건 맞는데, 그렇다고 남용하면 안 됩니다. 위 화면에서 보신 것처럼 필드가 7개 정도만 있어도 트리가 꽤 길어지는데, 이게 계속 늘어난다고 생각해보세요.
ZZFIELD01
ZZFIELD02
ZZFIELD03
...
ZZFIELD30
이러면 FI 핵심 구조 자체가 계속 커집니다. 더 중요한 건, 코딩 블록 확장이 BSEG만 건드리는 게 아니라는 점이에요. SAP S/4HANA 공식 문서에서도 Classic Coding Block Extension은 BSEG뿐 아니라 MSEG, EBKN, EKKN 등 여러 관련 구조·테이블까지 확장될 수 있다고 명시하고 있습니다.
그래서 설계할 때는 항상 먼저 이 질문부터 던져야 합니다. “이 정보가 정말 회계전표 Line Item의 속성인가?” 단순히 조회 편의를 위한 정보라면 굳이 코딩 블록까지 갈 필요 없이 Z테이블로 관리하는 게 나을 수도 있습니다.
ECC EHP6에서는 특히 조심하셔야 합니다
만수님 환경은 SAP ERP 6.0 EHP6이라 S/4HANA와는 구분해서 생각하셔야 합니다. ECC에서는 BSEG가 핵심 전표 Line Item 저장소이고, 구조를 단순화하면 아래와 같은 흐름입니다.
구분
ECC
S/4HANA
확장 시작점
CI_COBL → ZZ Custom Fields
CI_COBL
중간 처리
COBL → FI Posting Logic
Coding Block → Journal Entry
최종 저장소
BSEG
ACDOCA (+ 일부 BSEG 연계)
그래서 ECC에서 잘 쓰던 코딩 블록 Z필드가 S/4HANA Conversion 이후 어디까지 그대로 전달되는지는 반드시 별도로 확인하셔야 합니다. SAP도 S/4HANA에서 Classic Coding Block Extension을 계속 지원하긴 하지만, Universal Journal ACDOCA와의 관계를 추가로 고려하도록 안내하고 있습니다. 이 부분은 나중에 S/4HANA Conversion 관련 글에서 SI-Check이랑 엮어서 좀 더 자세히 풀어보겠습니다.
정리하고 보니, 코딩 블록 하나 뚫는 게 별거 아닌 것 같아도 막상 설계 단계에서 이것저것 따져야 할 게 은근히 많더라고요. 특히 S/4 전환을 앞두고 계신 분들이라면, 지금 ECC에서 쓰고 있는 Z필드들이 전환 후에도 살아남을지 미리 한 번 점검해보시는 걸 추천드립니다.
