SAP 수입 통합 관리 점검 — 구매 계약부터 L/C · B/L · 통관 · 입고 · 부대비 · 마감까지 수입 건마다 단계를 추적하고, 단계 사이의 수량·금액을 대사해 멈춘 건과 어긋난 건을 가려 그 자리에서 처리하는 화면

도입 포인트 — 이 앱을 사용해야 하는 이유

수입 한 건은 구매 계약에서 시작해 L/C 개설, 선적(B/L), 송장(I/V), 수입 통관, 입고, 부대비 전기를 거쳐 미착 조정 → 납품 완료 → 계약 완료 순서로 마감됩니다. 단계마다 화면과 담당자가 다르다 보니, 지금 어느 건이 어디서 멈췄는지와 단계 사이의 수량·금액이 서로 맞는지를 한 번에 보기 어렵습니다. 이 화면은 수입 건마다 단계 진행을 계획일·실적일·문서 번호로 추적하고, B/L·I/V·입고 수량, I/V 금액 × 환율 = 물품대, 부대비 배분 합계 = 부대비 전표, 입고 원가 = 물품대 + 배분 부대비, 미착 잔액, 수입부가세(신고필증) = 부가세 전표를 단계 사이에서 대사합니다. 재고 취득원가에 관세·운송비·하역비·보험료 같은 매입 부대비를 포함하는 IAS 2 재고자산(K-IFRS 제1002호)과, 외화 거래를 거래일 환율로 기록하는 IAS 21 환율변동효과(K-IFRS 제1021호)를 점검 관점으로만 씁니다. 건 상세에서는 단계 등록 · 부대비 배분과 전기 · 수입부가세 처리와 재마감 · 마감 · 취소까지 처리할 수 있고, 처리 결과는 점검 코드와 대사식에 바로 반영됩니다. 화면은 진행 추적 · 대사와 처리를 돕는 도구이며 전표 번호는 시뮬레이션 값입니다. 관세·수입부가세 계산과 신고 실무 세부는 회사·관세사 기준(확인 필요), 원가와 회계 처리의 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 8가지

사례로 보는 효과

같은 달, 서로 다른 세 가지 멈춤 — 통관 누락 · 부족 입고 · 운송비 미배분 — 검증용 샘플에서 8월 계약 건 가운데 IM26-0015 는 통관(신고 수리) 실적 없이 9월 17일에 입고되어 단계 누락(S01)으로, IM26-0016 은 B/L 3,000개 가운데 2,980개만 입고되어 미착 잔액 1,708,806원이 남은 수량 차이(Q01)로 표시됐습니다. 회사 2000 의 IM26-0033 은 운송비 전표 1,308,000원 가운데 이 건 몫 1,244,175원이 배분되지 않아(C01) 입고 원가가 그만큼 작게 잡혔습니다. 세 건 모두 지금 단계는 "부대비 전기" 로 같아 보이지만, 이 화면은 단계 사이의 숫자를 맞춰 보아 마감 전에 서로 다른 조치가 필요하다는 것을 알려 줍니다. 같은 화면에서 통관 등록, 미착 조정, 운송비 배분 실행과 전기로 세 건을 바로 해소했고, 처리마다 점검 코드와 대사식이 다시 계산되어 점검 필요 건이 9건에서 3건(장기 미착 · 보세 체류)으로 줄었습니다.

도입하면 달라지는 것

• 점검에서 찾은 건을 같은 화면에서 처리하고, 처리 이력과 취소 사유를 남깁니다
• 수입 건마다 지금 단계와 다음 단계, 계획 대비 경과일을 한 화면에서 봅니다
• 마감 전에 단계 누락 · 역순 처리 건을 찾아 순서대로 정리합니다
• 부족 입고 · 환율 차이 · 부대비 미배분이 입고 원가에 남기 전에 바로잡습니다
• 월말 미착 잔액을 건 단위로 설명하고 장기 미착 · 보세 장기 체류 건을 따로 관리합니다
• 수입부가세 익월 처리와 재마감 여부를 대사 결과로 남깁니다

이런 회사에 맞습니다

해외 수입 비중이 큰 제조 · 유통 회사, 구매 계약 → L/C → 통관 → 입고 → 부대비 → 마감 흐름을 SAP 구매 · 재고 · 회계 화면에 나눠 처리하는 회사, 월말 GR/IR · 미착 잔액과 수입 원가를 감사 전에 스스로 설명하려는 구매 · 원가 · 결산팀에 맞습니다.

사용 방법

1. 회계연도를 넣습니다(필수). 계약월 · 회사 · 미착 기준월 · 현재 단계 · 공급처 · 인코텀즈 · 일자 · 점검 코드 · 점검 결과는 필요할 때만 고르며, 비워 두거나 "전체" 이면 그 조건은 걸리지 않습니다.
2. 조회 버튼은 조회조건 영역 입력 칸의 맨 오른쪽에 있습니다. 입력 칸에서 Enter 키를 눌러도 조회되며, 처음 열면 한 번 자동으로 조회합니다.
3. 요약에서 수입 건 · 진행 중 · 계약 완료 · 점검·확인 필요 건 · 미착 잔액 · 입고 원가 · 배분 부대비 · 미배분 부대비 · 수입부가세 · 정합성 대사 차이를 먼저 봅니다.
4. 탭은 수입 건 현황 → 단계 이력 → 부대비 배분 → 수입 원가 → 미착 잔액 → 보세창고 → 수입부가세 → 대사 결과 순서로 넘깁니다.
5. 어느 탭에서든 행을 누르면 그 수입 건의 상세 창이 열리고, 단계 타임라인에서 처리할 수 있는 단계만 "등록" · "처리" · "부대비" 버튼이 켜집니다.
6. 버튼을 누르면 입력 대화상자가 열립니다. 필수값을 넣고 처리를 누르면 확인 대화상자가 뜨고, 결과는 성공이면 짧은 알림, 거부되면 사유가 담긴 메시지 상자로 보입니다. 상세 창 위쪽의 부대비 처리 · 부가세 당월/익월 처리 · 재마감 · 물품대 환율 정정 · 마지막 처리 취소(사유 필수)도 같은 방식입니다.
7. 여러 건에 같은 처리를 하려면 수입 건 현황 표에서 건을 고르고 일괄 처리를 누릅니다. 결과는 건별 성공 · 실패와 사유로 보입니다. 처리할 때마다 점검 코드 · 대사식 · 요약이 다시 계산되고 처리 이력 탭에 남습니다.
8. CSV 내려받기를 누르면 지금 보는 탭의 조회 결과가 UTF-8 CSV 로 내려옵니다.

숫자를 믿을 수 있는가 — 검증 결과

검증용 샘플 데이터(가상 회사 두 곳, 2026년 6~9월 계약 수입 건 36건, 기준일 2026-09-30)를 서비스 데이터만 읽는 독립 스크립트로 처음부터 다시 계산한 결과입니다.

검사 건수 합계 1,072건, 차이 0건입니다. 판정이 일부러 걸리도록 넣은 예외 6건(통관 없이 입고 · 마감 역순 · 부족 입고 · 환율 적용 차이 · 운송비 미배분 · 부가세 재마감 없음)과 경과 점검 3건(장기 미착 2 · 보세 장기 체류 1)은 대사 차이와 따로 셉니다. 예외 금액은 대사식 안의 별도 항으로 들어가 있어 대사 차이는 0 으로 맞습니다.

처리 기능은 서비스와 같은 규칙 파일로 처리 시나리오 36단계를 자동 실행해 확인했고, 처리 뒤 데이터도 같은 독립 스크립트로 다시 계산했습니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 13종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나와 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

회계연도 2026 이 기본값이라 열자마자 두 회사의 수입 건 36건과 요약이 보입니다.

수입 건마다 점검 결과 · 현재 단계 · 다음 단계 · 계획 경과일 · 완료 단계 수가 앞에 오고, 공급처 · 품목 · 통화 · 인코텀즈 뒤로 계약 · B/L · 입고 수량, I/V 외화 금액과 환율, 물품대 · 배분 부대비 · 입고 원가 · 9월 말 미착 잔액 · 수입부가세가 이어집니다. 36건 가운데 18건이 계약 완료, 9건이 점검·확인 필요입니다. 미착 잔액 628.3 백만원은 9월 말 기준입니다.

단계를 한 줄씩

수입 건 하나의 진행은 단계 이력 탭에서 계획일과 실적일로 읽습니다.

IM26-0015 는 수입 통관 실적이 없는데 수입 입고가 9월 17일에 처리되어 입고 행이 P01(선행 단계 실적 없이 진행)로, 통관 행은 계획일 18일 경과(P08)로 보입니다. 아직 오지 않은 단계는 "예정" 으로 표시되고, 마감 3단계는 미착 조정 → 납품 완료 → 계약 완료 순서로 판정합니다.

부대비를 건마다 나누기

운송비 · 하역비 전표는 여러 수입 건에 걸칩니다. 배분 결과와 배분되지 않은 금액을 함께 봅니다.

운송비 전표 5105600042 의 1,308,000원은 물품대 비율로 나뉘어야 하는데, IM26-0032 에 63,825원만 배분되고 IM26-0033 몫 1,244,175원은 배분되지 않았습니다(C01). 관세는 신고필증 기준 건별 전표, 하역비는 수량 비율로 나뉩니다. 전표별 배분 합계 + 미배분 = 전표 금액 대사는 차이 0 입니다.

입고 원가를 구성으로

입고 원가는 물품대에 매입 부대비를 더한 값입니다(IAS 2 점검 관점).

입고 원가 합계는 1,842.4 백만원, 배분 부대비는 140.8 백만원입니다. 수입부가세는 매입세액이라 원가 제외 열에 따로 두었습니다. IM26-0003 은 물품대에 I/V 기준 환율보다 23원 높은 환율이 적용되어 환율 적용 차이 838,350원(A01)이 보이고, IM26-0033 은 미배분 부대비 1,244,175원이 원가에서 빠져 있습니다.

월말 미착 잔액

미착 잔액은 I/V 가 먼저 들어오고 입고가 아직 안 된 금액입니다. 기준월을 바꿔 가며 봅니다.

9월 말 미착 잔액은 9건 628,250,554원입니다. IM26-0008 · IM26-0009 는 B/L 후 70일 · 61일 지나도록 입고되지 않아 장기 미착(G01), IM26-0016 은 입고 후에도 부족 수량만큼 1,708,806원이 남아 수량 차이(Q01)로 표시됩니다. 미착 잔액 = I/V 반영 − 입고 반영 − 미착 조정 대사는 차이 0 입니다.

수입 건 하나를 끝까지

어느 탭에서든 행을 누르면 그 건의 단계와 부대비가 한 창에 모입니다.

IM26-0015 는 현재 단계가 부대비 전기인데 수입 통관 행만 실적이 비어 있습니다. 처리할 수 있는 단계만 버튼이 켜져 통관 행에 "등록" 이 보이고, 위쪽에는 부대비 처리 · 부가세 처리 · 재마감 · 물품대 환율 정정 · 마지막 처리 취소 버튼이 상태에 따라 켜집니다.

찾은 자리에서 처리하기

점검에서 찾은 건은 같은 화면에서 처리합니다. 서비스가 같은 규칙으로 다시 검증하고, 처리하면 점검 코드 · 대사식 · 요약이 바로 다시 계산됩니다.

필수값이 비면 칸이 붉게 표시되고, 처리를 누르면 확인 대화상자가 뜹니다. 통관 수리일을 입고일(9월 17일) 이전인 9월 16일로 등록하자 단계 누락(S01)이 풀리고, 신고필증 부가세가 미처리로 생겨 확인 필요(V02)로 바뀌었다가 당월 처리로 정상이 됐습니다.

운송비 전표 5105600042 를 금액 기준으로 다시 배분하자 IM26-0033 몫 1,244,175원이 채워져 "배분 완료 · 전기 대기" 가 됐습니다. 배분 합계와 전표 금액이 같아야 전기가 되고, 전기하면 시뮬레이션 전표 번호가 붙고 미배분(C01)이 해소됩니다.

IM26-0025 는 재마감되어 V01 이 풀렸고, 나머지 두 건은 "익월 처리한 수입부가세가 없어 재마감 대상이 아닙니다" 로 실패 사유가 표시됩니다. 일괄 처리도 건마다 같은 규칙으로 검증합니다.

처리 다섯 건 뒤 요약의 점검·확인 필요 건이 9건에서 6건으로, 미배분 부대비가 0원으로 바뀌었고 정합성 대사 차이는 0 그대로입니다. 처리자는 구매 · 무역 · 원가 · 세무 · 결산 담당 같은 가상의 역할명입니다.

보세창고와 수입부가세

통관 전후의 보세 체류와, 신고필증 세액이 어느 달 전표로 처리됐는지를 봅니다.

IM26-0010 은 8월 17일 평택 보세창고 2 에 반입된 뒤 9월 말까지 44일째 반출되지 않아 보세 장기 체류(B01)로 표시됩니다. 통관 없이 입고된 IM26-0015 는 반출 기록도 없어 같은 건이 두 탭에서 함께 드러납니다.

하순 신고분은 익월에 전표 처리하고 수입 재마감을 합니다. IM26-0025 는 7월 신고분 4,770,076원을 8월에 처리했지만 재마감 표시가 없어 V01 로 표시됩니다. 과세가격 · 과세표준 산식은 검증용 가상 산식이며 실무 세부는 확인 필요입니다.

숫자를 스스로 맞춰 본다

대사 결과 탭은 서비스가 계산한 대사식 12종입니다.

의도적 예외는 대사식 안의 별도 항(수량 차이 · 환율 적용 차이 · 미배분 · 미처리)으로 들어가 있어, 예외가 있어도 대사 차이는 0 으로 맞고 예외 금액은 따로 보입니다. 검증용 샘플에서는 12종 모두 차이 0 입니다.

업무 점검 — 수입 마감 전 단계 · 대사 점검표

구매 · 무역 · 원가 담당자가 수입 건을 마감하기 전에 확인할 항목을, 이 화면의 어디서 보는지와 검증용 샘플 결과로 정리했습니다. 관세 · 수입부가세 실무 세부는 회사 · 관세사 기준을 따르며 확인 필요입니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 수입 건 · 단계 이력 · 부대비 배분 · 수입 원가 · 미착 잔액 · 보세창고 · 수입부가세 · 처리 이력 · 대사 결과 아홉 엔티티셋을 각각 조건과 함께 부르고, 요약의 미착 잔액 · 점검 필요 건수 · 미배분 부대비는 서비스 함수로 받습니다. 단계 판정과 대사는 서비스 쪽 데이터에 이미 계산되어 있고, 처리 버튼은 처리 함수(POST)를 불러 서비스가 규칙 검증 → 반영 → 전체 재계산 → 처리 이력 기록을 한 번에 합니다.

1. 단계 판정 — 단계마다 선행 단계 실적 유무와 일자를 견줘 P00 · P01 · P02 · P08 · P09 를 정합니다(마감 3단계는 미착 조정 → 납품 완료 → 계약 완료 순서).
2. 수량 대사 — B/L 수량 = I/V 수량, B/L 수량 = 입고 수량 + 수량 차이 + 미입고 수량.
3. 물품대 — 반올림(I/V 외화 금액 × I/V 기준 환율) + 환율 적용 차이 = 물품대(입고 반영 원화).
4. 부대비 배분 — 운송비는 물품대 비율, 하역비는 수량 비율, 관세 · 적하보험료는 건별 전표. 배분액 = 전표 금액 × 기준값 ÷ 기준값 합계, 반올림 차이는 기준값이 가장 큰 건에 둡니다. Σ 배분액 + 미배분 = 전표 금액.
5. 입고 원가 = 물품대 + 관세 + 운송비 + 하역비 + 적하보험료 (수입부가세는 매입세액으로 원가에서 제외).
6. 미착 잔액(월말) = 입고 전 I/V 반영액 − 입고 반영액(I/V 금액 × 입고 수량 ÷ I/V 수량) − 미착 조정액.
7. 수입부가세 = 당월 전표 + 익월 전표 + 미처리, 신고필증 관세 = 관세 부대비 전표.
8. 건 판정 — 단계 · 수량 · 환율 · 부대비 · 부가세 · 보세 · 미착 점검 결과를 우선순위(S01 → S02 → Q01 → A01 → C01 → V01 → B01 → G01 → V02)로 정리해 대표 코드를 정합니다.

수입 건 판정 — 조건과 조치

단계 판정과 단계 정의

계획 일수 · 장기 미착 45일 · 보세 체류 30일은 검증용 샘플에 둔 회사 기준 예시이며, 운영에서는 단계 정의 · 파라미터 테이블에서 정합니다.

처리 기능 — 무엇을, 어떤 조건에서

처리는 건 상세에서 합니다. 화면은 처리할 수 있는 단계만 버튼을 켜고 필수값을 확인하며, 차단 판단은 서비스가 같은 규칙으로 다시 합니다. 처리하면 그 건의 판정 · 대사식 12종 · 요약이 바로 다시 계산되고 처리 이력에 남습니다. 부대비 전기에 붙는 전표 번호는 시뮬레이션 값입니다.

처리 차단 조건

아래 조건에 걸리면 서비스가 처리를 거부하고 사유를 돌려주며 데이터는 바뀌지 않습니다. 단계 누락(S01) · 마감 역순(S02) 같은 예외가 처리 과정에서 새로 생기지 않게 하는 장치입니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 폭에 맞춰 줄을 바꿔 쌓이고, 조회 버튼은 언제나 입력 칸 묶음의 맨 끝에 붙습니다. 표는 수입 건 열을 고정한 채 가로로 넘기며, 상세 창은 휴대폰 폭에서 화면 전체를 씁니다.

파일 구성

앱 폴더/
├─ index.html · manifest.json · Component.js
├─ controller/   BaseController · Main.controller
├─ view/         Main.view.xml · DetailDialog.fragment.xml
├─ model/        formatter · ErrorHandler
├─ css/ · i18n/
├─ odata/        서비스 정의 · 서비스 로직 · 엔티티셋별 데이터
└─ media/        소개 영상

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 구매오더 · 입고 · 송장 · GR/IR 정리는 표준 화면에서 그대로 처리하고, 그 결과를 수입 건 한 줄로 이어 단계 진행과 단계 사이 숫자를 맞춰 보는 자리를 더합니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

운영으로 옮길 때 기존 구매 · 입고 · 송장 처리 절차를 없앨 필요는 없습니다. 외상매입금 반제 같은 지급 처리와 세무 신고는 표준과 기존 절차에 두고, 이 화면은 수입 건 마감 전 점검 단계로 씁니다.

S/4HANA 분석 스택과의 자리

단계 판정 큐브와 미착 잔액 큐브를 분석 쿼리로 만들어 두면 표준 Fiori 분석 앱과 Analysis for Office 가 같은 숫자를 띄웁니다. 구매오더 이력과 GR/IR 표준 보고서 위에 수입 건 단위 진행 추적과 단계 간 대사를 얹는 자리입니다.

확장 포인트 — 운영에서 실제로 손대는 자리

분석 지표 정의표

CDS 구성

검증 화면은 수입 건 36건을 서비스 데이터로 들고 있지만, 운영에서는 구매오더 · 구매오더 이력 · 수입 문서를 CDS 로 이어 단계와 대사를 내립니다. 코드는 스케치이며 표준 필드명과 이력 유형 값은 릴리스 · 설정에 따라 다르므로 주석에 확인할 자리를 적었습니다.

뷰 레이어 구성

① 단계 정의 테이블

이 화면의 모든 단계 판정이 이 표에서 갈립니다. 단계 코드와 순서, 어떤 단계가 끝나야 다음 단계로 갈 수 있는지(선행 단계), 계약일 기준 계획 일수, 신용장 결제 건에만 있는 단계 같은 적용 조건을 적습니다. 운영 전환에서 구매 · 무역팀과 가장 먼저 합의할 항목입니다.

" ────────────────────────────────────────────────────────────────
"  ZIMP_STAGEDEF — 수입 단계 정의 (투명 테이블)
"  역할 : 단계 코드 · 순서 · 선행 단계 · 계획 일수 · 적용 조건
"  나눈 이유 : 단계 순서와 마감 순서(미착 조정 → 납품 완료 → 계약 완료)를
"             코드가 아니라 표로 관리한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '수입 단계 정의'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_stagedef {
  key mandt      : mandt not null;
  key stage_id   : abap.char(2) not null;   " CT LC BL IV CC GR CH C1 C2 C3
  stage_seq      : abap.numc(2);            " 표시 순서
  pre_stage_1    : abap.char(2);            " 선행 단계(필수)
  pre_stage_2    : abap.char(2);            " 선행 단계(있으면 함께 확인)
  plan_days      : abap.int2;               " 계약일 기준 계획 일수
  cond_payterm   : abap.char(2);            " LC = 신용장 결제 건에만 적용
  is_closing     : abap_boolean;            " 마감 3단계 표시
}

② 수입 문서 테이블

B/L · 수입신고 · 보세 반입과 반출 · 수입부가세 처리월 · 재마감 여부는 표준 구매 테이블에 없는 경우가 많습니다. 회사가 이미 별도 테이블이나 무역 솔루션에 두고 있다면 그 원천을 이 구조로 맞추면 됩니다(실제 원천은 확인 필요). B/L 번호는 인바운드 납품의 선하증권 칸에 두는 회사도 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZIMP_CUSTOMS — 수입 문서 (B/L · 수입신고 · 보세 · 부가세 처리)
"  주의 : 원천은 회사마다 다르다(무역 솔루션 · 별도 테이블) — 확인 필요
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '수입 문서'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zimp_customs {
  key mandt      : mandt not null;
  key ebeln      : ebeln not null;          " 구매오더
  key ebelp      : ebelp not null;
  bl_no          : abap.char(20);           " 선하증권 번호
  bl_date        : abap.dats;
  lc_no          : abap.char(20);           " 신용장 번호(신용장 결제 건)
  lc_date        : abap.dats;
  decl_no        : abap.char(20);           " 수입신고번호
  decl_date      : abap.dats;               " 신고 수리일
  @Semantics.amount.currencyCode : 'zimp_customs.waers'
  customs_value  : abap.curr(15,2);         " 과세가격 — 산식은 관세사 기준(확인 필요)
  @Semantics.amount.currencyCode : 'zimp_customs.waers'
  duty_amt       : abap.curr(15,2);         " 신고필증 관세
  @Semantics.amount.currencyCode : 'zimp_customs.waers'
  vat_amt        : abap.curr(15,2);         " 신고필증 부가세
  waers          : waers;
  bond_wh        : abap.char(10);           " 보세창고
  bond_in        : abap.dats;               " 반입일
  bond_out       : abap.dats;               " 반출일
  vat_post_month : abap.numc(2);            " 부가세 전표 처리월
  reclose_flag   : abap_boolean;            " 수입 재마감 수행
}

③ 수입 건 차원 뷰

수입 건 한 행은 구매오더 품목 하나에 공급처와 수입 문서를 붙인 것입니다. 단계 · 부대비 · 미착 큐브가 모두 이 정의를 연관으로 봅니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpCase — 수입 건 차원 (EKKO · EKPO · LFA1 + 수입 문서)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 건'
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'PurchaseOrderItem'
define view entity ZI_ImpCase
  as select from ekpo as i
    inner join ekko as h on h.ebeln = i.ebeln
    left outer join lfa1 as v on v.lifnr = h.lifnr
    left outer join zimp_customs as c on c.ebeln = i.ebeln and c.ebelp = i.ebelp
{
  key i.ebeln        as PurchaseOrder,
  key i.ebelp        as PurchaseOrderItem,
      h.bukrs        as CompanyCode,
      h.ekorg        as PurchasingOrg,
      h.lifnr        as Vendor,
      v.name1        as VendorName,
      h.waers        as Currency,
      h.inco1        as Incoterms,
      h.bedat        as ContractDate,
      i.matnr        as Material,
      @Semantics.quantity.unitOfMeasure: 'Unit'
      i.menge        as ContractQty,
      i.meins        as Unit,
      i.elikz        as DeliveryCompleted,      " 납품 완료 표시
      c.bl_no        as BillOfLading,
      c.decl_no      as CustomsDeclNo
}
where h.bsart = 'NB'     // 수입 오더 유형 · 해외 공급처 구분은 회사 기준 — 확인 필요

④ 단계 실적 큐브

흩어진 문서를 "단계" 축 하나로 모읍니다. 구매오더 이력(EKBE)의 입고와 송장, 수입 문서의 B/L · 신고 수리, 부대비 송장을 UNION 으로 이어 단계마다 실적일 · 문서 번호 · 수량 · 금액을 한 행으로 만듭니다. 이력 유형 값은 릴리스 · 설정에 따라 확인이 필요합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpStageEvent — 단계 실적 (UNION)
"  BEWTP : E 입고 · Q 송장 (그 밖의 유형은 확인 필요)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 단계 실적'
@Analytics.dataCategory: #CUBE
define view entity ZI_ImpStageEvent
  as select from ZI_ImpCase as k
{
  key k.PurchaseOrder, key k.PurchaseOrderItem, key cast( 'CT' as abap.char(2) ) as StageId,
      k.ContractDate as ActDate, k.PurchaseOrder as DocNo,
      cast( k.ContractQty as abap.quan(15,3) ) as Qty, cast( 0 as abap.dec(17,2) ) as AmtLc
}
union all select from zimp_customs as c
{
  key c.ebeln, key c.ebelp, key cast( 'BL' as abap.char(2) ),
      c.bl_date, c.bl_no, cast( 0 as abap.quan(15,3) ), cast( 0 as abap.dec(17,2) )
}
union all select from zimp_customs as c
{
  key c.ebeln, key c.ebelp, key cast( 'CC' as abap.char(2) ),
      c.decl_date, c.decl_no, cast( 0 as abap.quan(15,3) ), cast( c.duty_amt as abap.dec(17,2) )
}
union all select from ekbe as e
{
  key e.ebeln, key e.ebelp,
  key case e.bewtp when 'E' then cast( 'GR' as abap.char(2) )
                   when 'Q' then cast( 'IV' as abap.char(2) ) end,
      max( e.budat ), max( e.belnr ),
      sum( case e.shkzg when 'H' then - e.menge else e.menge end ),
      sum( case e.shkzg when 'H' then - e.dmbtr else e.dmbtr end )
}
where e.bewtp in ( 'E', 'Q' )
group by e.ebeln, e.ebelp, e.bewtp

⑤ 단계 판정 큐브

단계마다 선행 단계의 실적 유무와 일자를 견줘 판정합니다. 선행 단계가 없는데 실적이 있으면 P01, 선행 단계보다 이른 일자면 P02, 실적이 없고 계획일이 지났으면 P08 입니다. 판정 규칙을 이 뷰 한곳에 두면 단계 정의 테이블만 바꿔도 화면 판정이 따라옵니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpStageCheck — 단계 판정 (선행 단계 실적 · 일자)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 단계 판정'
define view entity ZI_ImpStageCheck
  with parameters P_KeyDate : abap.dats
  as select from ZI_ImpCase as k
    cross join zimp_stagedef as d
    left outer join ZI_ImpStageEvent as a  on  a.PurchaseOrder = k.PurchaseOrder
                                          and a.PurchaseOrderItem = k.PurchaseOrderItem
                                          and a.StageId = d.stage_id
    left outer join ZI_ImpStageEvent as p  on  p.PurchaseOrder = k.PurchaseOrder
                                          and p.PurchaseOrderItem = k.PurchaseOrderItem
                                          and p.StageId = d.pre_stage_1
{
  key k.PurchaseOrder, key k.PurchaseOrderItem, key d.stage_id as StageId,
      d.stage_seq                                        as StageSeq,
      dats_add_days( k.ContractDate, d.plan_days, 'INITIAL' ) as PlanDate,
      a.ActDate,
      a.DocNo,
      case
        when a.ActDate is not null and d.pre_stage_1 <> '' and p.ActDate is null then 'P01'
        when a.ActDate is not null and p.ActDate > a.ActDate                    then 'P02'
        when a.ActDate is null
         and dats_add_days( k.ContractDate, d.plan_days, 'INITIAL' ) < $parameters.P_KeyDate then 'P08'
        when a.ActDate is null                                                  then 'P09'
        else 'P00'
      end                                                as CheckCode
}
where d.cond_payterm = '' or d.cond_payterm = 'LC'   // 신용장 결제 여부 조건 — 결제조건 연결은 확인 필요

⑥ 부대비 배분 큐브

부대비 전표 금액을 수입 건마다 나눈 결과와 배분되지 않은 금액입니다. 운송비는 물품대 비율, 하역비는 수량 비율, 관세 · 적하보험료는 건별 전표입니다. 반올림 차이는 기준값이 가장 큰 건에 둡니다. 계획 부대비를 구매오더 조건으로 처리하는 회사는 구매오더 이력의 부대비 행(EKBZ)이 원천이 됩니다(확인 필요).

" ────────────────────────────────────────────────────────────────
"  ZI_ImpChargeAlloc — 부대비 배분 (전표 × 수입 건)
"  배분액 = 전표 금액 × 기준값 ÷ 기준값 합계, 반올림 차이는 최대 기준값 건
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 부대비 배분'
@Analytics.dataCategory: #CUBE
define view entity ZI_ImpChargeAlloc
  as select from zimp_chgalloc as a            // 배분 실행 결과(배분 프로그램이 기록)
    inner join ZI_ImpCase as k on  k.PurchaseOrder = a.ebeln
                              and k.PurchaseOrderItem = a.ebelp
{
  key a.charge_doc   as ChargeDoc,
  key a.ebeln        as PurchaseOrder,
  key a.ebelp        as PurchaseOrderItem,
      a.charge_type  as ChargeType,           // DUTY · FRT · HDL · INS
      a.base_type    as BaseType,             // DECL · AMT · QTY
      @Semantics.amount.currencyCode: 'Currency'
      a.doc_amt      as DocAmt,
      @Semantics.amount.currencyCode: 'Currency'
      a.alloc_amt    as AllocAmt,
      @Semantics.amount.currencyCode: 'Currency'
      a.round_adj    as RoundAdj,
      @Semantics.amount.currencyCode: 'Currency'
      a.miss_amt     as MissAmt,               // 이 건 몫인데 배분되지 않은 금액(C01)
      a.waers        as Currency
}

⑦ 미착 잔액 큐브

기준일을 파라미터로 받아 그날의 미착 잔액을 다시 구합니다. 입고 전에 들어온 송장 금액에서 입고 반영액과 미착 조정액을 뺍니다. 월말마다 같은 뷰를 기준일만 바꿔 부르면 되므로 스냅숏 테이블이 필요 없습니다. MB5S 의 GR/IR 잔액과 맞추는 자리입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpGitBalance — 기준일 미착 잔액
"  미착 잔액 = Σ 송장(Q) − Σ 입고(E) − Σ 미착 조정  (기준일까지)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 미착 잔액'
@Analytics.dataCategory: #CUBE
define view entity ZI_ImpGitBalance
  with parameters P_KeyDate : abap.dats
  as select from ekbe as e
{
  key e.ebeln as PurchaseOrder,
  key e.ebelp as PurchaseOrderItem,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when e.bewtp = 'Q' and e.shkzg = 'S' then e.dmbtr
                when e.bewtp = 'Q' and e.shkzg = 'H' then - e.dmbtr else 0 end ) as IvLc,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when e.bewtp = 'E' and e.shkzg = 'S' then e.dmbtr
                when e.bewtp = 'E' and e.shkzg = 'H' then - e.dmbtr else 0 end ) as GrLc,
      e.hswae as Currency
      // 미착 조정(GR/IR 정리) 반영 방식은 이력 유형 확인 후 추가 — 확인 필요
}
where e.budat <= $parameters.P_KeyDate
group by e.ebeln, e.ebelp, e.hswae

⑧ 모니터링 쿼리

수입 건별 현재 단계와 대사 결과를 한 행으로 두는 분석 쿼리입니다. 표준 Fiori 분석 앱과 Analysis for Office 가 같은 숫자를 띄우고, 이 화면의 수입 건 현황과 맞춰 볼 수 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_ImpStageMonitor — 수입 진행 모니터링 쿼리
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 통합 관리 점검'
@Analytics.query: true
define transient view entity ZC_ImpStageMonitor
  provider contract analytical_query
  with parameters P_KeyDate : abap.dats
  as projection on ZI_ImpStageCheck( P_KeyDate: $parameters.P_KeyDate )
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: false }
  @AnalyticsDetails.query.axis: #ROWS
  PurchaseOrder,
  @AnalyticsDetails.query.axis: #ROWS
  PurchaseOrderItem,
  @AnalyticsDetails.query.axis: #COLUMNS
  StageId,
  @AnalyticsDetails.query.axis: #FREE
  CheckCode,
  PlanDate,
  ActDate
}

⑨ 처리 동작 정의(RAP)

화면의 처리 버튼은 서비스 액션 하나씩에 대응합니다. 운영에서는 RAP 동작 정의에 액션과 검증(validation)을 두고, 실제 전기는 표준 처리(입고 · 송장 · GR/IR 정리)를 부르도록 구현합니다. 이 화면의 검증용 서비스는 같은 규칙을 시뮬레이션 전표 번호로 재현합니다(실제 전기 연결 방식은 확인 필요).

" ────────────────────────────────────────────────────────────────
"  ZI_ImpCase — Behavior Definition (처리 액션 · 검증)
"  주의 : 실제 전기는 표준 BAPI · 표준 처리 호출로 구현 — 확인 필요
" ────────────────────────────────────────────────────────────────
managed implementation in class zbp_i_impcase unique;
strict ( 2 );
define behavior for ZI_ImpCase alias ImportCase
lock master
authorization master ( instance )
{
  action ( features : instance ) registerStage parameter ZA_ImpStageInput result [1] $self;
  action ( features : instance ) allocateCharge parameter ZA_ImpAllocInput result [1] $self;
  action ( features : instance ) postCharge parameter ZA_ImpPostInput result [1] $self;
  action ( features : instance ) processVat parameter ZA_ImpVatInput result [1] $self;
  action ( features : instance ) reClose result [1] $self;
  action ( features : instance ) closeStep parameter ZA_ImpCloseInput result [1] $self;
  action ( features : instance ) cancelLast parameter ZA_ImpCancelInput result [1] $self;
  validation checkStageOrder on save { create; update; }   // 선행 단계 · 역순 · 마감 순서
  validation checkQtyAmount  on save { create; update; }   // B/L ≥ 입고 · I/V × 환율 허용오차
  validation checkChargeSum  on save { create; update; }   // 배분 합계 = 전표 금액
  validation checkGitZero    on save { create; update; }   // 계약 완료 전 미착 잔액 0
}

⑩ 권한(DCL)

회사코드와 구매 조직 권한을 수입 건 차원에 겁니다. 집계 단계에 걸어야 합계로 다른 회사 숫자가 드러나지 않습니다.

" ────────────────────────────────────────────────────────────────
"  DCL — 회사코드 · 구매 조직 권한
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 건 권한'
@MappingRole: true
define role ZI_IMPCASE {
  grant select on ZI_ImpCase
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( PurchasingOrg ) = aspect pfcg_auth( M_BEST_EKO, EKORG, ACTVT = '03' );
}

⑪ 서비스 정의

화면이 부르는 엔티티셋을 묶습니다. 운영 전환 시 서비스 바인딩을 게시하고 manifest 의 서비스 주소만 바꿉니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_IMPSTAGE — Service Definition
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 통합 관리 점검 서비스'
define service ZUI_IMPSTAGE {
  expose ZI_ImpCase         as CaseSet;
  expose ZI_ImpStageCheck   as StageSet;
  expose ZI_ImpChargeAlloc  as ChargeSet;
  expose ZI_ImpGitBalance   as GitSet;
  expose ZI_ImpActionLog    as ActionLogSet;     // 처리 이력(누가 · 언제 · 무엇을 · 전후 값)
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

운영 데이터로 갈 때

수입 건은 구매오더 품목 단위라 회계 전표 전체를 훑지 않습니다. 단계 실적은 구매오더 이력에서 품목별로 모으고, 미착 잔액은 기준일 파라미터로 DB 에서 집계하며, 수입 문서는 구매오더 키로 붙입니다. 회사 · 연도를 필수 조건으로 두고 원인 건만 상세로 내려가도록 나누면 응답 시간 목표(조회 2초 이내)를 지킬 수 있습니다.

자주 묻는 질문

도입 검토에서 나올 질문을 다섯 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

기준과 판정

처리 기능

도입과 운영