SAP FI 인터페이스 13종 — 화면 없는 프로그램이 하는 일
카드사·은행·그룹웨어·인사·국세청과 주고받는 재무 인터페이스를 방향별로 나눠, 무엇을 받아 어디에 넣고 무엇을 돌려주는지 한 번에 정리했습니다.
소개 영상블로그 목차 순서대로 · 자막 포함
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
현대카드 사용내역, 환율정보, 결재 결과 등 외부 시스템 연동 데이터가 제때 반영되지 않아 핵심 재무 업무에 차질을 겪고 계신가요? SAP FI 인터페이스 13종은 이러한 눈에 보이지 않는 데이터 흐름을 자동화하고, 복잡한 업무 로직을 반영하여 재무 운영의 정확성과 효율성을 극대화합니다.
핵심 포인트 일곱 가지
| 핵심 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 수신 데이터 원본 보존 | 카드사 등 외부 시스템에서 수신된 데이터를 백업 테이블에 먼저 저장하여 원본을 안전하게 보존합니다. 운영 테이블의 데이터에 문제가 발생하면 원본과 대조하여 오류 원인을 신속하게 파악할 수 있습니다. | 외부 데이터 유입 시 원본 손실 우려, 데이터 불일치 발생 시 원인 추적 어려움. |
| ② 결재 연동 자동화 및 통제 | 그룹웨어 결재 상태(승인, 반려, 상신취소)를 SAP 전표 상태와 정확히 매핑하고, 반려·상신취소 시 관련 전표를 자동으로 취소하여 결재 프로세스 준수를 지원합니다. | 결재 상태와 전표 상태 불일치, 반려 전표 수동 취소 지연 및 누락으로 인한 업무 부담. |
| ③ 정확한 외화 환산 자동화 | 하나은행 고시환율 6종과 함께 환산단위(TCURF)를 반환하여 100단위 통화 처리 시 발생할 수 있는 환율 오류를 방지하고 정확한 외화 환산을 지원합니다. | 환율 수동 입력 오류 가능성, 100단위 통화 환산 시 금액 불일치 발생. |
| ④ 외부 시스템 맞춤 데이터 가공 | 외부 시스템이 바로 활용할 수 있도록 표준 테이블 데이터를 영업소별 집계, 부호 조정, 대사 키 정리 등 사전 가공 규칙을 적용하여 제공합니다. | 외부 시스템 요구사항에 맞춰 SAP 데이터를 수동으로 가공, 데이터 일관성 저하. |
| ⑤ 수신 데이터 무단 변경 방지 | 카드 마스터 등 외부 수신 데이터 중 핵심 항목은 화면에서 수정 불가(잠금) 처리하여 무단 변경을 방지하고, 원본 데이터의 정합성을 유지합니다. | 외부 수신 데이터의 임의 수정 가능성, 원본 데이터와의 불일치 발생. |
| ⑥ 특정 회계 규칙 자동 적용 | 인사 시스템 원천세 데이터는 집계 코드가 인사(Z1~Z3)인 경우만 처리하고, AP Commission은 특정 계정(21050551) 고정 및 차변 부호 반전 등 복잡한 회계 규칙을 자동 적용합니다. | 특정 조건에 따른 데이터 선별 및 복잡한 회계 처리 규칙을 수동으로 적용. |
| ⑦ 중복 방지 및 사전 오류 점검 | 카드번호와 승인번호 조합으로 중복 수신을 방지하고, Legacy 전표 인터페이스는 헤더·아이템 필수 항목을 사전 점검하여 오류 전표 생성을 예방합니다. | 외부 시스템 연동 시 중복 데이터 발생, 필수 항목 누락으로 인한 전표 생성 실패. |
도입하면 달라지는 것
- 외부 시스템 데이터 정확하고 자동으로 반영
- 그룹웨어 결재와 SAP 전표 상태 실시간 동기화
- 복잡한 회계 규칙 자동 적용으로 수작업 감소
- 데이터 불일치 및 오류 전표 발생 위험 감소
이런 회사에 맞습니다
외부 시스템과의 데이터 연동이 필수적이거나, 복잡한 결재 및 회계 처리 규칙의 자동화가 필요한 재무·관리회계·물류팀 및 CFO에게 적합합니다.
공통 파라미터
| 필드 | 필수 | 설명 |
|---|---|---|
EV_RETURN | 공통 | 처리 결과 — 성공 / 실패 또는 X / space |
EV_MSG | 공통 | 오류 사유 메시지 |
T_RETURN | 결재 연동 | BAPI_MTYPE·ID·NUMBER·MESSAGE 구조 |
IV_WFKEY · IV_WFSTATUS | 결재 연동 | 워크플로 키와 결재 상태 |
IV_DATE | 환율 | 조회 일자. 비면 오류 |
IV_BUKRS · IV_BELNR · IV_GJAHR | Legacy 조회 | 전표 키 3종 |
상태 코드 체계
| 컬럼 | 의미 · 표시 |
|---|---|
결재 상태 D | 기안 → CC 결재중 — 내역 갱신 |
결재 상태 C | 완료(승인) → FF 승인 — 내역 갱신 |
결재 상태 R | 반려 → DD 반려 — 전표 취소 |
결재 상태 W | 회수(상신취소) → EE 상신취소 — 전표 취소 |
| 카드상태 | 1 정상 · 3 유효정지 · 5 무효정지 · 7 취소 · 9 교체 |
| 카드 신청유형 | 1 신규 · 2 재발급 · 3 갱신 |
| 원천세 집계코드 | Z1~Z3 인사 · Z4~Z7 재무 — 인사 건만 수신 처리 |
보조 기능
| 컬럼 | 의미 · 표시 |
|---|---|
| 환율 종류 | M 매매기준 · CB 현찰매도 · CS 현찰매입 · TTB 전신환매입 · TTS 전신환매도 · EXD 미화환산 |
| 환산단위 | TCURF 의 FFACT · TFACT — 100단위 통화 보정 |
| 일자 변환 | CONVERSION_EXIT_INVDT_INPUT — GDATU 는 역순 일자 |
네임스페이스 구성
| 경로 | 역할 |
|---|---|
ZFIA_* | 카드·환율·결재·Legacy — 9종 |
ZFIB_* | 채권/입금 현황 — 1종 |
ZFIC_* | AP Commission — 1종 |
ZFIE_* | 임직원 원천세 — 1종 |
ZFIF_* | 이세로 대사 — 1종 |
ZSFIA* · ZSFIE* · ZSB_* | 파라미터 구조체 (Structure) |
ZSMMZ_RETRUN | 공통 반환 구조 — 메시지 유형·클래스·번호·본문 |
사양서 대조 결과
정리에 쓴 자료는 프로그램 사양서의 파라미터·처리 로직·연관 테이블입니다.
| 데이터 | 규모 | 구성 |
|---|---|---|
| 인터페이스 | 13종 | 수신 6 · 양방향 2 · 결재 2 · 제공 3 |
| 외부 시스템 | 6곳 | 현대카드 · 하나은행 · 그룹웨어 · 인사 · Legacy · 이세로 |
| 저장 테이블 | Z 테이블 10여 개 | 백업과 운영을 분리한 구조 |
| 검증 항목 | 결과 |
|---|---|
| 수신형 4종이 백업 테이블을 먼저 거치는 구조 | 사양서 일치 |
| 카드 마스터 수신분은 화면에서 잠금 (사용자·처리자·반납일만 수기) | 사양서 일치 |
| 결재 상태 D·W·R·C 가 CC·EE·DD·FF 로 매핑 | 사양서 일치 |
| 반려·상신취소 시 전표 취소 수행 | 사양서 일치 |
| 환율 I/F 가 6종 환율과 환산단위를 함께 반환 | 사양서 일치 |
| 환율 I/F 의 일자 필수 점검과 역순 일자 변환 | 사양서 일치 |
| 원천세 I/F 는 집계코드가 인사(Z1~Z3)인 건만 처리 | 사양서 일치 |
| AP Commission 은 계정 21050551 고정 · 차변은 부호 반전 | 사양서 일치 |
| Legacy 전표 I/F 의 헤더·아이템 필수항목 점검 | 사양서 일치 |
| 공통 반환 규약 EV_RETURN · EV_MSG / T_RETURN | 13종 전부 확인 |
테이블명과 코드 체계는 사양서 기준입니다.
실행 화면
설계 시 점검 순서
- 인터페이스를 방향으로 먼저 나눕니다. 받는 것, 주고받는 것, 주는 것.
- 수신형은 백업 테이블을 먼저 두고 운영 테이블로 옮기는 구조인지 확인합니다.
- 수신분을 화면에서 어디까지 고칠 수 있게 할지 정합니다. 카드사가 주는 항목은 잠그는 편이 안전합니다.
- 결재 연동은 상태 코드 매핑과 되돌림 처리를 함께 설계합니다.
- 제공형은 받는 쪽이 바로 쓸 수 있도록 집계·부호·키를 맞춰 넘깁니다.
- 모든 인터페이스가 EV_RETURN · EV_MSG 같은 공통 반환 규약을 따르게 합니다.
13종 처리 로직 요약
열세 개 인터페이스가 각각 무엇을 받아 어디에 넣고 무엇을 돌려주는지 정리했습니다.
인터페이스 13종 — 방향별 분류
【수신형 6종】 외부 → SAP
ZFIA_HCARD_MASTER_IF 현대카드 마스터
ZFIA_HCARD_APPR_IF 현대카드 승인내역
ZFIA_HCARD_PROC_IF 현대카드 매입내역
ZFIA_HCARD_BILL_IF 현대카드 청구내역 (월 단위)
ZFIA_EXCHANGE_RATE_IF 하나은행 고시환율
ZFIE_HR_WITHHOLDING_TAX_IF 인사시스템 원천세
【양방향 2종】 Legacy ↔ SAP
ZFIA_LEGACY_DOC_IF 전표 생성 요청 → 전표번호 회신
ZFIA_LEGACY_CHECK_CANCEL 전표 취소여부 조회
【결재 연동 2종】 SAP ↔ 그룹웨어
ZFIA_DOCUMENT_REQUEST 법인카드 경비 상신
ZFIA_DOCUMENT_FINAL 결재 완료 후 처리
【제공형 3종】 SAP → 외부
ZFIB_AR_STATUS 채권/입금 현황
ZFIC_AP_COMMISSION AP Commission 지급정보
ZFIF_GET_DOC_INFO_FOR_DTI 이세로 대사 데이터| 항목 | 산식 · 규칙 |
|---|---|
ZFIA_HCARD_MASTER_IF | 카드 마스터 수신 → ZTFIA0040 백업 후 ZTFIA0010 반영 |
ZFIA_HCARD_APPR_IF | 승인내역 수신 → ZTFIA0050 백업 후 ZTFIA0020 반영 |
ZFIA_HCARD_PROC_IF | 매입내역 수신 → ZTFIA0060 백업 후 ZTFIA0020 반영 |
ZFIA_HCARD_BILL_IF | 청구내역 수신 → ZTFIA0070 백업 후 ZTFIA0030 반영 |
ZFIA_EXCHANGE_RATE_IF | 일자 받아 TCURR·TCURF 조회 후 6종 환율 반환 |
ZFIE_HR_WITHHOLDING_TAX_IF | 집계코드가 인사(Z1~Z3)인 건만 ZTFIE0060 반영 |
ZFIA_LEGACY_DOC_IF | 헤더·아이템 필수 점검 후 전표 생성, 전표번호 회신 |
ZFIA_LEGACY_CHECK_CANCEL | BKPF 헤더로 취소 여부 판정 — X / space |
ZFIA_DOCUMENT_REQUEST | ZTFIA0020 조회 후 결재 HTML 본문과 결재요소 구성 |
ZFIA_DOCUMENT_FINAL | 결재 상태를 HSTATUS 에 반영, 반려·취소는 전표 취소 |
ZFIB_AR_STATUS | 당월매출·입금·미입금·어음을 영업소별로 집계 |
ZFIC_AP_COMMISSION | 계정 21050551 고정, Partial·Cleared 금액 합산 (차변은 −) |
ZFIF_GET_DOC_INFO_FOR_DTI | AR/AP·계산서 종류별 ERP 데이터를 대사용으로 반환 |
인터페이스를 방향으로 나눠 본 이유
이름만 보면 열세 개가 다 비슷해 보입니다. 그런데 받는 것과 주는 것은 설계 고민이 정반대입니다. 받는 쪽은 원본을 어떻게 보존하고 어디까지 화면에서 고치게 할지가 문제이고, 주는 쪽은 어떤 형태로 가공해서 넘길지가 문제입니다. 방향으로 나누면 각 인터페이스가 왜 그렇게 생겼는지 설명됩니다.
방향별 4갈래
이름은 비슷해 보여도 데이터가 흐르는 방향에 따라 설계가 달라집니다.
| 갈래 | 방향 | 데이터가 닿는 곳 | 설계 핵심 |
|---|---|---|---|
| 수신형 | 외부 → SAP | 백업 테이블 → 운영 테이블 | 원본 보존 · 화면에서 잠금 |
| 양방향 | Legacy ↔ SAP | 표준 전표 생성 · 조회 | 전표번호와 취소 여부 회신 |
| 결재 연동 | SAP ↔ 그룹웨어 | 상태 매핑 · 전표 취소 | 반려·취소 시 되돌림 |
| 제공형 | SAP → 외부 | 표준 테이블 읽기 | 집계·부호·키를 맞춰 반환 |
네 갈래로 나누면 각 인터페이스가 왜 그런 모양인지 설명이 됩니다.
연결되는 화면 프로그램
인터페이스가 쌓은 데이터는 결국 화면 프로그램이 꺼내 씁니다.
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
FB08 | 전표 역분개 | 결재 반려·취소 시 호출 |
운영 데이터 소스 매핑
| 항목 | SAP 원천 | 비고 |
|---|---|---|
| 카드 백업 | ZTFIA0040 · 0050 · 0060 · 0070 | 카드사 전송 원본 |
| 카드 운영 | ZTFIA0010 · 0020 · 0030 | 마스터 · 처리내역 · 청구내역 |
| Legacy 전표 | ZTFIA0080 · ZTFIA0090 | 헤더 · 아이템 |
| 원천세 | ZTFIE0060 · ZTFIE0030 | 신고자료 · 집계코드 |
| 환율 | TCURR · TCURF | 환율 · 환산단위 |
| 채권·채무 | BSID · BSAD · BSIK · BSAK · BSED | 미결·반제·어음 |
도입 시 확인이 필요한 부분
인터페이스는 실패했을 때가 문제입니다. 재전송 규칙과 중복 방지 키를 먼저 정해야 합니다. 카드 I/F 는 카드번호와 승인번호 조합이 키가 되는데, 같은 건을 두 번 받으면 덮어쓸지 건너뛸지 정해 두지 않으면 중복 전표로 이어집니다. 수신 이력을 남기는 로그 테이블도 함께 설계하는 편이 안전합니다.
화면 없는 프로그램 다루기
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 없음 | Function / Interface 유형은 Selection Screen 과 ALV 가 없다 |
| 호출 주체 | 외부 시스템 또는 배치 잡이 RFC 로 호출 |
| 결과 전달 | EV_RETURN · EV_MSG 로 성공 여부와 사유를 회신 |
| 데이터 확인 | 수신 결과는 연결된 화면 프로그램에서 조회 |
| 백업 활용 | 값이 이상하면 백업 테이블의 원본과 대조 |
| 잠금 연동 | 수신분은 화면에서 수정 불가로 처리해 덮어쓰기 충돌을 막음 |
| 테스트 | SE37 단건 호출 또는 인터페이스 테스트 도구 |
화면 없는 프로그램의 결과를 확인하는 법
인터페이스 자체는 볼 게 없지만 결과는 화면에 나타납니다. 그래서 수신형 인터페이스를 설계할 때는 어느 화면에서 결과를 확인할지를 함께 정해야 합니다. 이번 13종도 모두 대응하는 조회 화면이 있고, 수신분은 그 화면에서 잠기도록 맞춰 두었습니다.
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
자주 묻는 질문
수신형이 왜 백업 테이블을 먼저 거치나요?
카드사가 보낸 원본을 남겨 두기 위해서입니다. 운영 테이블은 화면에서 일부 항목을 고칠 수 있어 시간이 지나면 원본과 달라집니다. 값이 이상하다는 문의가 오면 백업 테이블과 대조해 카드사가 보낸 값이 그랬는지 우리가 고친 건지 가릴 수 있습니다.
반려와 상신취소만 전표를 취소하는 이유는?
결재중과 승인은 앞으로 진행될 건이라 전표가 살아 있어야 합니다. 반면 반려나 상신취소는 그 경비를 처리하지 않겠다는 뜻이므로 이미 만든 전표를 되돌려야 합니다. 사양서가 이 네 상태를 코드로 구분해 둔 것도 그 때문입니다.
환율 I/F 는 왜 환산단위까지 주나요?
환율값만으로는 금액을 못 구하는 통화가 있습니다. 엔화처럼 100단위로 고시하는 통화는 환율에 환산단위를 함께 적용해야 원화가 나옵니다. 받는 쪽이 이 값을 모르면 금액이 100배 어긋납니다.
제공형 함수는 왜 그냥 테이블을 안 주고 가공해서 주나요?
받는 쪽이 SAP 테이블 구조를 알아야 하는 부담을 없애기 위해서입니다. 채권 현황은 영업소별로 묶어서, AP Commission 은 차변 부호를 맞춰서, 이세로 대사 데이터는 승인번호 기준으로 정리해서 넘깁니다. 규칙을 함수 안에 두면 외부가 바뀌어도 기준이 흔들리지 않습니다.
화면이 없는데 문제가 생기면 어떻게 확인하나요?
연결된 화면 프로그램에서 결과를 봅니다. 카드 I/F 는 법인카드 처리현황에서, 환율 I/F 는 환율관리에서, 원천세 I/F 는 원천세 집계에서 데이터가 올라왔는지 확인합니다. 인터페이스 자체는 EV_RETURN 과 EV_MSG 로 성공 여부를 돌려주므로 호출한 쪽 로그에도 남습니다.