SAP 법인카드 처리현황 — 자동으로 들어온 건과 직접 넣는 건
카드사에서 수신한 사용내역과 직접 등록하는 내역을 한 목록에서 보되, 손대면 안 되는 건은 잠가 두는 화면입니다.
소개 영상블로그 목차 순서대로 · 자막 포함
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
법인카드 사용내역은 다양한 경로로 유입되어 수기 대사와 오류 식별이 어렵습니다. 카드사 연동 데이터, 수기 입력 데이터, 이미 전표 처리된 내역이 혼재되어 장부 불일치와 비효율적인 재작업을 초래할 수 있습니다. 이 앱은 모든 법인카드 거래를 한 화면에서 통합 관리하며, 데이터 원천과 회계처리 상태를 기준으로 자동으로 검증하고 통제하여 재무 데이터의 정합성을 확보하고 업무 효율을 극대화합니다.
핵심 포인트 일곱 가지
| 핵심 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 원천별 데이터 정합성 유지 | 카드사 연동(IF)으로 수신된 데이터와 이미 전표가 생성된 사용내역은 자동으로 잠금 처리되어 수정/삭제가 차단됩니다. 이는 다음 IF 수신 시 데이터 덮어쓰기나 원장과의 불일치를 방지하여 데이터 정합성을 유지합니다. | IF 수신 건을 잘못 수정하거나, 전표 처리된 건을 변경하여 장부 불일치와 재작업이 발생합니다. |
| ② 명확한 잠금 사유 안내 | 각 사용내역 줄마다 'IF 수신 건', '전표 생성 건' 등 구체적인 잠금 사유를 명확히 표시합니다. 이를 통해 담당자는 수정 불가능한 원인을 즉시 파악하고, 상황에 맞는 후속 조치를 효율적으로 취할 수 있습니다. | 단순히 '잠김'으로만 표시되어 담당자가 수정 불가 사유를 일일이 확인해야 합니다. |
| ③ 국내외 사용내역 자동 설정 | 사용자가 '해외 사용' 여부를 변경하면, 국내(국가 KR, 통화 KRW, 거래구분 '01' 승인, 과세구분 '01')와 해외(거래구분 '03' 매입, 과세구분 '99')에 맞는 기본값이 자동으로 설정되어 입력 오류를 줄입니다. | 국내외 건별로 거래 구분, 과세 구분, 가맹점 정보 등을 수기로 확인하고 입력해야 합니다. |
| ④ 승인번호 자릿수 자동 검증 | 국내 승인번호는 8자리 또는 10자리를, 해외 승인번호는 22~23자리를 준수하도록 저장 시 자동으로 점검하고, 유효하지 않은 경우 명확한 안내와 함께 저장을 막습니다. 이는 데이터 입력 단계에서 오류를 사전에 방지합니다. | 승인번호 자릿수 오류를 뒤늦게 발견하여 재작업하거나, 잘못된 데이터가 저장될 수 있습니다. |
| ⑤ 복잡한 금액 계산 자동화 | 국내 건은 승인금액을 공급가액과 부가세로 자동으로 분리하고, 해외 건은 현지 금액에 환율을 곱하여 원화로 환산합니다. 환가료 등 카드사 IF 수신분에만 존재하는 항목도 자동으로 처리합니다. | 국내외 건별 금액 분리 및 환산 계산을 수기로 처리하여 번거롭고 오류 발생 가능성이 높습니다. |
| ⑥ 직관적인 권한별 데이터 조회 | 재무팀 사용자에게는 전체 법인카드 사용내역 조회를, 그 외 사용자에게는 본인이 처리자인 카드 내역만 조회하도록 권한을 분리합니다. 이를 통해 민감한 재무 데이터에 대한 접근을 효과적으로 통제합니다. | 권한 설정이 미흡하여 불필요한 인원이 전체 데이터를 열람하거나, 필요한 데이터에 접근하기 어렵습니다. |
| ⑦ SAP 표준 프로세스와 연동 | 카드사 인터페이스를 통한 자동 수신과 SAP 표준 전표 생성(FB60 등) 프로세스 사이의 누락된 연결 고리를 제공합니다. 이 앱은 표준 구조를 유지하면서도 법인카드 처리의 고유한 요구사항을 보완합니다. | 카드사 데이터와 SAP 전표 처리 간에 수동 검증 및 조정 작업이 추가로 발생하여 비효율적입니다. |
도입하면 달라지는 것
- 법인카드 데이터 정합성 확보
- 수기 입력 및 검증 시간 단축
- 회계 전표 생성 오류 최소화
- 법인카드 관리 프로세스 투명화
이런 회사에 맞습니다
복수의 법인카드를 사용하며 카드사 연동 데이터와 수기 등록 데이터를 혼용하는 회사, 복잡한 국내외 법인카드 사용내역 처리 및 검증에 많은 시간을 들이는 재무·회계팀, 데이터 정확성과 통제 강화를 원하는 CFO에게 적합합니다.
건별 상태 3종
같은 목록이지만 줄마다 할 수 있는 일이 다릅니다.
| 상태 | 들어온 경로 | 입력칸 | 할 수 있는 일 |
|---|---|---|---|
| IF 수신 | 연계 카드사 | 항상 잠금 | 값 확인만 가능, 수정·삭제 불가 |
| 수기 · 미처리 | 담당자 직접 등록 | 열림 | 등록·수정·삭제 모두 가능 |
| 수기 · 전표생성 | 담당자 등록 후 회계처리 | 잠금 | 전표와 어긋나지 않도록 고정 |
세 상태가 목록에서 바로 갈리므로 고칠 수 있는 줄만 골라 작업하면 됩니다.
실행 화면
실제 화면 9종 둘러보기
조회하면 줄마다 잠금 사유가 보입니다 → 고칠 수 있는 건만 수정·등록하고 → 자릿수 점검을 거쳐 저장합니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
사용 방법
- 승인/매입일자를 확인합니다. 기본값은 최근 한 달입니다.
- 카드구분과 회계처리 라디오로 연계 건과 수기 건, 처리 여부를 갈라 봅니다.
- 목록에서 잠금 칸을 먼저 봅니다. IF 잠금과 전표 잠금은 대응 방법이 다릅니다.
- 등록으로 연계 대상이 아닌 카드의 사용내역을 추가합니다.
- 해외사용을 바꾸면 국가·통화·거래구분·과세구분이 자동으로 맞춰집니다.
- 저장 시 승인번호 자릿수와 필수값을 점검합니다. 국내는 8 또는 10자리입니다.
잠금·기본값·자릿수 규칙
잠금 판정과 국내·해외 기본값, 승인번호 자릿수가 이 화면의 뼈대입니다.
수정 가능 여부 (사양서)
BANK_CODE = '012' (연계 카드사 IF 수신 건)
→ 체크박스 및 모든 조회 필드 수정 불가
BANK_CODE ≠ '012'
BELNR 공란 → 체크박스 및 모든 필드 수정 가능
BELNR 존재 → 체크박스 및 모든 필드 수정 불가
해외사용 여부에 따른 기본값
FORE_USE = '1' 국내
국가코드 KR · 통화 KRW · 거래구분 '01' 승인
AQUI_WON = ACKAMOUNT
가맹점 사업자번호·상호·주소·업종 입력 (과세구분 01)
FORE_USE = '2' 해외
거래구분 '03' 매입 · 과세구분 '99'
가맹점 사업자번호 · 상호 · 주소 · 업종명 비활성
원화환산 = 현지 액면금액 × 적용환율
승인/매입번호 자릿수
국내 : 8 또는 10자리
11자리 이상이면 저장 불가
"승인번호 8 or 10자리를 수정하시거나 해외사용여부를 수정하세요."
해외 : 22~23자리| 항목 | 산식 · 규칙 |
|---|---|
| 잠금 판정 | 연계 카드사 IF 건이거나 전표가 생성된 건 |
| 조회 권한 | 재무팀 등록 사용자는 전체, 그 외는 본인이 사용자·처리자인 카드만 |
| 국내 기본값 | 국가 KR · 통화 KRW · 거래구분 01 · 원화환산 = 승인금액 |
| 해외 기본값 | 거래구분 03 · 과세구분 99 · 가맹점 정보 비활성 |
| 승인번호 자릿수 | 국내 8·10자리 / 해외 22~23자리 |
| 환가료·봉사료·할인 | 연계 카드사 IF 건에만 존재하는 항목 |
| 원천 구분 | IF 수신 / 수기 등록 |
잠금 사유를 나눠서 보여 주는 이유
둘 다 '못 고침'이지만 대응이 다릅니다. IF 건은 카드사에 요청해야 하고, 전표 생성 건은 역분개부터 해야 합니다. 그냥 잠김이라고만 하면 담당자가 어디로 가야 할지 모릅니다. 삭제를 막을 때도 몇 건이 어느 사유인지 나눠서 알려 줍니다.
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
| Company code | 필수 | 변경 못함. 로그인 사용자 → 사번 → 사원 Vendor 순으로 기본값 결정 |
| 승인/매입(취소)일자 | 필수 | 기본값 현재일자 −1개월 ~ 현재일자 |
| 카드번호 · 승인번호 | 선택 | 카드 마스터 목록에서 선택 |
| Fiscal Year · Document Number | 선택 | 회계처리된 건을 전표로 추적 |
| 해외사용 여부 | 필수 | 전체 / 국내 / 해외 |
| 카드구분 · 회계처리 | 선택 | 연계/수기, 처리완료/미처리 |
결과 컬럼
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
SAP 표준 기능 확장 포인트
SAP 표준 기능 매핑
카드사 수신은 인터페이스가, 전표 생성은 표준이 담당합니다. 이 화면은 그 사이를 맡습니다.
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
| 카드사 인터페이스 | 사용내역 자동 수신 | IF 건을 화면에서 잠가 덮어쓰기 충돌을 막음 |
FB60 관점 | 카드 비용 전표 | 전표 생성 후에는 이 화면에서 잠김 |
USR21 · ADCP · LFB1 | 사용자·사번·사원 Vendor | 회사코드 기본값 결정 |
운영 데이터 소스 매핑
| 항목 | SAP 원천 | 비고 |
|---|---|---|
| 사용내역 | ZTFIA0020 | CRUD 대상 테이블 |
| 카드 마스터 | ZTFIA0010 | 상태 '정상' 카드만 Search help 제공 |
| 재무팀 | ZTFIA0100 | 전체 조회 권한 판정 |
| 사업장 | J_1BBRANCH | 사업장 정보 |
| 첨부 | SRGBTBREL | GOS 첨부 관계 |
도입 시 확인이 필요한 부분
연계 카드사 코드가 회사마다 다르고 여러 곳일 수도 있습니다. 잠금 대상 카드사를 설정 테이블로 빼면 계약이 바뀌어도 프로그램을 고치지 않아도 됩니다. 재무팀 사용자 등록(ZTFIA0100)도 유지보수 뷰로 관리해야 인사이동 때 권한이 따라갑니다.
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
자주 묻는 질문
연계 카드사 건은 왜 아예 못 고치나요?
카드사가 매일 다시 밀어 넣기 때문입니다. 화면에서 고쳐도 다음 수신에 되돌아가는데 담당자는 고쳤다고 믿게 됩니다. 값이 틀렸다면 카드사에 정정을 요청하거나, 회계 처리 단계에서 조정해야 합니다.
전표가 생긴 뒤에는 왜 잠기나요?
사용내역이 전표의 근거이기 때문입니다. 금액이나 가맹점을 뒤에 바꾸면 전표와 근거가 달라져 부가세 신고나 감사에서 설명할 수 없게 됩니다. 고쳐야 한다면 전표를 역분개한 뒤 다시 처리하는 순서가 맞습니다.
해외 건은 왜 가맹점 정보를 안 넣나요?
해외 가맹점은 국내 사업자번호가 없고 매입세액공제 대상도 아닙니다. 입력해도 쓰이지 않는 값이라 사양서에서 비활성으로 지정했습니다. 대신 과세구분을 99로 넣어 국내 건과 구분합니다.
승인번호 자릿수를 왜 따지나요?
국내 승인번호는 8 또는 10자리, 해외 매입번호는 22~23자리로 체계가 다릅니다. 자릿수가 어긋났다는 건 해외 건을 국내로 넣었거나 번호를 잘못 옮겨 적었다는 뜻입니다. 저장 전에 걸러 두면 나중에 카드사 원본과 대조할 때 헤매지 않습니다.
SAP 표준 기능과 어떻게 이어지나요?
사용내역은 커스텀 테이블이고 카드 목록은 카드 마스터에서 가져옵니다. 여기서 정리한 내역이 비용 전표의 근거가 되고, 전표가 생기면 이 화면은 읽기 전용으로 바뀝니다. 같은 카드의 청구내역은 청구현황 화면에서 이어 봅니다.