전표유형 vs 전기키 — 계정은 누가 정하나 #shorts #SAP #FI

이 글이 답하는 질문

FI 전표를 처음 입력할 때 가장 헷갈리는 두 가지가 전표유형(Document Type)과 전기키(Posting Key)입니다. 둘 다 "계정과 관련된 무언가를 통제한다"고 배우는데, 정확히 무엇을 누가 결정하는지 경계가 모호하게 느껴집니다. 이 글에서는 실무 구매송장·판매전표 예시로 두 객체의 역할 분리를 명확히 구분합니다.

• 전표유형은 왜 헤더(BKPF)에, 전기키는 왜 명세(BSEG)에 저장되는가?
• 번호범위와 허용 계정유형은 누가 통제하는가?
• 차변/대변 방향과 필드 상태는 누가 결정하는가?
• FB60에서 전기키를 입력한 적이 없는데 전표에는 왜 31/40이 찍혀 있는가?
• 커스텀 전표유형을 도입할 때 무엇을 점검해야 하는가?

이 글을 보기 전에

차변/대변의 기본 개념(자산 증가는 차변, 부채 증가는 대변)과 총계정원장·고객·공급업체 계정의 구분 정도만 알고 있으면 충분합니다. SAP GUI 트랜잭션(FB60, FB03)을 한 번이라도 열어봤다면 더 빠르게 따라올 수 있고, ABAP 예제는 읽기만 해도 흐름이 이해되도록 작성했습니다. 난이도는 입문 수준입니다.

테스트 환경과 사용한 버전

이 글의 예제는 SAP S/4HANA 2023 On-Premise 기준으로 작성했으며, 개념 자체는 SAP ERP(ECC 6.0)에도 동일하게 적용됩니다. S/4HANA에서는 분개 데이터가 유니버설 저널(ACDOCA)로 통합되었지만, 전표 헤더 BKPF와 전기키 필드는 여전히 유지되므로 이 글의 내용은 두 환경 모두에서 유효합니다.

• 시스템: SAP S/4HANA 2023 FPS01 (On-Premise), 클라이언트 100
• 주요 트랜잭션: FB60(공급업체 송장), FB70(고객 송장), FB50(G/L 전표), FB03(전표 조회), OBA7(전표유형 설정), OB41(전기키 설정), FBN1(번호범위)
• 주요 테이블: BKPF(전표 헤더), BSEG(전표 명세), ACDOCA(유니버설 저널)
• 필요 권한: 전표 입력 권한(F_BKPF_BUK, F_BKPF_BLA), 설정 조회는 SPRO 표시 권한

핵심 개념 — 전표유형과 전기키의 역할 분리

비유로 시작하겠습니다. FI 전표를 하나의 서류 봉투라고 생각해 보세요. 전표유형은 봉투 겉면의 라벨입니다. 이 봉투에 어떤 종류의 서류(계정유형)를 담을 수 있는지, 그리고 봉투에 어떤 일련번호(번호범위)를 찍을지를 라벨이 결정합니다. 반면 전기키는 봉투 안 각 서류 줄마다 찍는 방향 도장입니다. 이 줄이 차변인지 대변인지, 그리고 이 줄에서 어떤 입력 칸을 반드시 채우고 어떤 칸을 숨길지를 도장이 결정합니다.

이 비유가 테이블 구조와 정확히 대응합니다. 전표유형(필드 BLART)은 전표당 하나이므로 헤더 테이블 BKPF에 저장되고, 전기키(필드 BSCHL)는 라인마다 다를 수 있으므로 명세 테이블 BSEG에 라인 번호(BUZEI)와 함께 저장됩니다.

역할을 표로 정리하면 다음과 같습니다.

구분	전표유형 (BLART, BKPF)	전기키 (BSCHL, BSEG)
적용 범위	전표 전체(헤더 레벨)	개별 라인(명세 레벨)
번호범위	결정함 (예: KR → 19번 범위)	관여 안 함
허용 계정유형	전표 전체에서 쓸 수 있는 계정유형 목록 (S/D/K/A/M)	해당 라인 하나의 계정유형 1개 확정
차변/대변	결정 안 함	결정함 (SHKZG = S 차변 / H 대변)
필드 상태	헤더 필드 일부(참조번호 필수 여부 등)	라인 필드 상태 (계정의 필드상태그룹과 결합)
설정 트랜잭션	OBA7, 번호범위는 FBN1	OB41

대표적인 조합 예시를 들면 이렇습니다. 공급업체 송장은 전표유형 KR(공급업체 K와 총계정원장 S 허용)에 전기키 31(공급업체 대변)과 40(G/L 차변)이 들어갑니다. 고객 송장은 DR에 01(고객 차변)과 50(G/L 대변), 순수 G/L 대체전표는 SA에 40/50 조합이 일반적입니다.

필드 상태에 관해 한 가지 더 짚어야 할 점이 있습니다. 라인 입력 화면에서 어떤 필드가 필수/선택/숨김인지는 전기키의 필드 상태와 G/L 계정 마스터에 지정된 필드상태그룹(Field Status Group)이 결합되어 결정됩니다. 우선순위는 일반적으로 숨김(Suppress) > 표시(Display) > 필수(Required) > 선택(Optional) 순이며, 한쪽이 숨김인데 다른 쪽이 필수이면 전기 시점에 충돌 오류가 발생합니다. 즉 "계정을 정하는" 주체를 굳이 하나 꼽으라면, 전표유형은 울타리(어떤 계정유형까지 허용할지)를 치고, 전기키는 그 울타리 안에서 각 라인의 방향과 입력 규칙을 정한다고 이해하면 됩니다.

실전 예제 3단계

1단계 — 기본: 구매송장 전표를 테이블로 해부하기

시나리오: 사무용품 공급업체 VN-2043에게 받은 1,100,000원 송장(소모품비 1,000,000 + 부가세 100,000)을 FB60으로 입력했다고 가정합니다. FB60 화면 어디에도 전기키 입력란이 없지만, 저장 후 FB03으로 열어보면 전기키가 자동으로 결정되어 있습니다. 생성된 전표를 쿼리로 확인해 봅니다.

-- 전표 헤더: 전표유형(BLART)은 여기에만 존재
SELECT bukrs, belnr, gjahr, blart, budat, waers, xblnr
  FROM bkpf
 WHERE bukrs = '1000'
   AND belnr = '1900004521'
   AND gjahr = '2026';
-- 결과: BLART = 'KR' (공급업체 송장), 번호 19000045xx → KR에 배정된 19번 번호범위

-- 전표 명세: 전기키(BSCHL)와 차/대 지시자(SHKZG)는 라인마다 존재
SELECT buzei, bschl, shkzg, koart, hkont, lifnr, wrbtr
  FROM bseg
 WHERE bukrs = '1000'
   AND belnr = '1900004521'
   AND gjahr = '2026'
 ORDER BY buzei;
-- 1행: BSCHL=31, SHKZG=H(대변), KOART=K, LIFNR=VN-2043, 1,100,000
-- 2행: BSCHL=40, SHKZG=S(차변), KOART=S, HKONT=53100000(소모품비), 1,000,000
-- 3행: BSCHL=40, SHKZG=S(차변), KOART=S, HKONT=13500000(부가세대급금), 100,000

여기서 역할 분리가 그대로 보입니다. 전표번호가 19로 시작하는 것은 전표유형 KR이 번호범위를 정했기 때문이고, 1행이 대변·2~3행이 차변인 것은 각 라인의 전기키 31/40이 방향을 정했기 때문입니다. FB60은 "공급업체 송장"이라는 업무 맥락에서 전기키를 자동 유도했을 뿐, 전기키가 사라진 것이 아닙니다.

2단계 — 실무: BAPI로 전표를 생성하며 오류를 잡아내기

월말에 물류비 미착 송장을 일괄 전기하는 인터페이스를 만든다고 가정합니다. 이때 전표유형과 전기키를 코드에서 직접 지정하게 되는데, 잘못된 조합(예: SA 전표유형에 공급업체 라인)을 넣으면 전기가 거부됩니다. 오류를 로그로 남기는 패턴까지 포함한 예제입니다.

DATA: ls_header  TYPE bapiache09,
      lt_ap      TYPE STANDARD TABLE OF bapiacap09,
      lt_gl      TYPE STANDARD TABLE OF bapiacgl09,
      lt_amount  TYPE STANDARD TABLE OF bapiaccr09,
      lt_return  TYPE STANDARD TABLE OF bapiret2.

" 헤더: 전표유형 KR 지정 → 번호범위와 허용 계정유형이 여기서 결정됨
ls_header-doc_type   = 'KR'.
ls_header-comp_code  = '1000'.
ls_header-doc_date   = sy-datum.
ls_header-pstng_date = sy-datum.
ls_header-username   = sy-uname.
ls_header-ref_doc_no = 'FRT-202608-0042'.   " 운송사 송장번호

" 공급업체 라인: BAPI가 내부적으로 전기키 31(대변)로 변환
APPEND VALUE #( itemno_acc = 1
                vendor_no  = 'VN-7810' ) TO lt_ap.

" G/L 라인: 전기키 40(차변)에 해당 — 물류비 계정
APPEND VALUE #( itemno_acc = 2
                gl_account = '0053200000'
                item_text  = '8월 해상운임 미착분' ) TO lt_gl.

" 금액: 부호로 차/대 표현 (음수 = 대변)
APPEND VALUE #( itemno_acc = 1 currency = 'KRW' amt_doccur = '-2750000' ) TO lt_amount.
APPEND VALUE #( itemno_acc = 2 currency = 'KRW' amt_doccur = '2750000'  ) TO lt_amount.

CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'
  EXPORTING documentheader = ls_header
  TABLES    accountpayable = lt_ap
            accountgl      = lt_gl
            currencyamount = lt_amount
            return         = lt_return.

" 오류 처리: E/A 메시지가 하나라도 있으면 롤백 + 로그
IF line_exists( lt_return[ type = 'E' ] ) OR line_exists( lt_return[ type = 'A' ] ).
  CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
  LOOP AT lt_return INTO DATA(ls_ret) WHERE type CA 'EA'.
    " 예: F5 243 "계정유형 K는 전표유형 SA에 허용되지 않음"
    MESSAGE ID ls_ret-id TYPE 'I' NUMBER ls_ret-number
      WITH ls_ret-message_v1 ls_ret-message_v2 ls_ret-message_v3 ls_ret-message_v4.
  ENDLOOP.
ELSE.
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'.
ENDIF.

doc_type을 실수로 'SA'로 바꿔 실행해 보면, 공급업체 라인이 있다는 이유로 "계정유형이 전표유형에 허용되지 않음" 계열의 오류가 반환됩니다. 허용 계정유형 검증이 헤더의 전표유형 레벨에서 걸린다는 것을 직접 확인할 수 있는 실험입니다.

3단계 — 프로덕션: 커스텀 전표유형 설계와 검증 자동화

실무에서 인터페이스 전표를 표준 KR과 분리 추적하려고 커스텀 전표유형(예: ZF = 물류 인터페이스 송장)을 만드는 경우가 많습니다. 프로덕션 도입 시 점검 순서는 다음과 같습니다.

1. OBA7에서 ZF 생성: 허용 계정유형을 K(공급업체)와 S(총계정원장)로만 제한해 오입력을 원천 차단
2. FBN1에서 회사코드·회계연도별 전용 번호범위(예: 95번, 9500000000~9599999999) 배정 — 번호범위 이관은 시스템 간 자동 이관이 되지 않으므로 운영 환경에서 별도 생성 필요
3. 권한: 전표유형별 권한 객체 F_BKPF_BLA에 권한 그룹을 지정해 인터페이스 사용자만 ZF로 전기 가능하도록 제한
4. 검증: OB28 검증(Validation)으로 "ZF 전표는 참조번호(XBLNR) 필수" 같은 추가 규칙 부여

운영 후에는 모니터링 쿼리를 걸어둡니다. S/4HANA라면 BSEG 대신 유니버설 저널 ACDOCA를 읽는 편이 성능상 유리합니다(BSEG는 클러스터 시절 구조를 잇는 미결관리 중심 테이블이고, 집계·분석성 조회는 ACDOCA가 적합합니다).

-- ZF 전표의 일자별 건수/금액 모니터링 (S/4HANA, ACDOCA 기준)
SELECT budat,
       COUNT( DISTINCT belnr )              AS doc_count,
       SUM( CASE WHEN drcrk = 'S' THEN hsl ELSE 0 END ) AS debit_total
  FROM acdoca
 WHERE rldnr = '0L'          -- 대표원장
   AND rbukrs = '1000'
   AND blart  = 'ZF'
   AND gjahr  = '2026'
 GROUP BY budat
 ORDER BY budat;

테스트 관점에서는 (1) 허용 계정유형 위반 케이스, (2) 번호범위 고갈 임박 경고(SNRO 잔여율 확인), (3) 전기키 필드상태와 계정 필드상태그룹의 충돌 케이스를 최소 시나리오로 잡는 것이 좋습니다.

자주 만나는 함정

• Q1. FB50/FB60에서는 전기키를 입력한 적이 없는데 어디서 정해지나요? — Enjoy 트랜잭션(FB50/FB60/FB70)은 화면의 차변/대변 지시자와 업무 맥락으로 전기키를 자동 유도합니다. FB50에서 차변 선택 시 40, 대변 선택 시 50이 배정되고, FB60의 공급업체 라인은 31이 됩니다. FB01 같은 클래식 화면에서만 전기키를 직접 타이핑합니다.
• Q2. 전표유형만 맞으면 아무 계정이나 쓸 수 있나요? — 아닙니다. 전표유형은 계정유형(K/D/S/A/M) 단위의 울타리만 칩니다. 개별 계정 단위 통제는 전기키의 계정유형 지정, 계정 마스터의 필드상태그룹, 필요 시 OB28 검증이 겹겹이 담당합니다.
• Q3. 필수 필드인데 화면에 아예 안 보이는 경우는 왜 생기나요? — 전기키 필드상태와 계정의 필드상태그룹이 결합될 때 한쪽이 숨김이면 일반적으로 숨김이 이깁니다. 숨김과 필수가 충돌하면 전기 시 오류가 나므로, OB41(전기키)과 OBC4(필드상태변형) 양쪽을 함께 확인해야 합니다.
• Q4. 운영 이관 후 "번호범위 없음" 오류가 납니다. — 번호범위 인터벌은 설정 이관 시 자동으로 따라가지 않는 것이 기본 동작입니다. 운영 환경에서 FBN1로 직접 생성했는지, 회계연도별 인터벌(연도 종속 설정 시)이 새 연도에 존재하는지 확인하세요. 연말·연초 장애의 단골 원인입니다.
• Q5. 역분개하면 전기키는 어떻게 되나요? — 전기키마다 역전기키(Reversal Posting Key)가 OB41에 정의되어 있습니다. 예를 들어 40의 역전기키는 50입니다. 전표유형 쪽에도 역분개 전표유형(예: KR의 역분개는 KA 등 설정에 따름)이 지정되어 두 객체가 각자의 층위에서 역분개를 처리합니다.

더 파볼 주제

이 글에서 다룬 역할 분리를 이해했다면, 다음 주제로 확장하면 좋습니다. 첫째, 필드상태그룹과 필드상태변형(OBC4) — 전기키와 결합되는 나머지 절반을 깊게 보는 주제입니다. 둘째, 특별 G/L 지시자(Special G/L Indicator) — 전기키 09/19/29/39가 선급금·보증금 같은 특수 거래를 어떻게 대체계정으로 우회시키는지 다룹니다. 셋째, S/4HANA 유니버설 저널(ACDOCA) — BKPF/BSEG 이원 구조가 단일 저널로 통합되면서 조회 전략이 어떻게 바뀌는지 살펴볼 만합니다.

더 읽어볼 자료

• SAP Help Portal — SAP S/4HANA On-Premise 제품 문서 (Finance 영역)
• SAP Help Portal — SAP ERP Financial Accounting (FI) 문서
• SAP Help Portal — General Ledger Accounting (FI-GL) 설정 가이드
• SAP Community — S/4HANA Finance 토픽 (전표유형/전기키 관련 실무 Q&A)
• SAP Business Accelerator Hub — 회계 전표 관련 API(Journal Entry) 명세
• SAP for Me — 번호범위/전기키 관련 SAP Note 검색

핵심 한 줄

전표유형(BKPF-BLART)은 전표 전체의 번호범위와 허용 계정유형이라는 울타리를 치고, 전기키(BSEG-BSCHL)는 각 라인의 차변/대변 방향과 필드 상태를 정한다 — 헤더는 울타리, 라인은 도장이다.