SAP 수출 진행 단계 추적 지연 점검 — 수주부터 대금 회수까지 일곱 단계의 계획일과 실적일을 견줘 늦어진 단계를 찾는 수출 진행 관리 화면

소개 영상블로그 목차 순서대로 · 음성 안내와 자막 포함8개 장면수출 건 일곱 단계 → 처음 화면 → 점검 필요 조회 → 단계 명세 → 단계별 · 거래처별 → 대사 → 상세

주요 재생 지점

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

수출 담당자가 매주 받는 질문은 같습니다. 이 건은 지금 어디까지 왔나, 어느 단계에서 늦어졌나, 누구에게 물어야 하나. 판매 오더 · 출하 · 청구 · 고객 반제 항목은 표준 화면으로 각각 볼 수 있지만, 수출 한 건을 수주부터 대금 회수까지 한 줄로 이어 ‘계획보다 며칠 늦었는가’ 를 단계마다 계산해 주는 화면은 표준에 없습니다. 이 앱은 그 한 줄을 만들어, 지연이 쌓이기 전에 늦은 단계를 찾도록 돕습니다.

한 줄 요약 — 수출 건의 일곱 단계마다 계획일(앞 단계 실적일 + 표준 소요일)을 세우고, 실적일(없으면 기준일)과 견주어 허용 지연일을 넘으면 점검 필요로 표시합니다. 판정의 근거가 날짜 계산식으로 화면에 그대로 적혀 있고, 화면의 숫자가 맞는지 스스로 대사해 차이가 0 인지 매번 보여 줍니다.

핵심 포인트 여섯 가지

포인트	고객이 얻는 것	지금 방식이라면
① 수출 한 건을 일곱 단계로 잇는다	수주 · 출하 · 선적(B/L) · 수출통관 · 청구 · 네고·추심 · 대금 회수를 한 줄에서 봅니다. 현재 단계와 최대 단계 지연일이 건마다 붙습니다.	문서마다 화면을 열고 날짜를 옮겨 적어 엑셀에서 비교합니다.
② 계획일을 앞 단계에서 이어 세운다	계획일은 앞 단계 실적일에 표준 소요일을 더한 값입니다. 앞 단계가 늦으면 뒤 단계의 계획일도 같이 밀려, 늦은 단계만 정확히 집힙니다.	수주일 기준으로 모든 단계를 한꺼번에 재면 앞 단계 지연이 뒤 단계 지연으로 번져 책임 단계가 흐려집니다.
③ 판정 근거가 화면에 남는다	점검 필요마다 계획일 · 실적일 · 허용 지연일이 같은 줄에 나옵니다. “왜 걸렸나” 를 되묻지 않아도 됩니다.	걸린 이유를 담당자에게 되묻거나 메일 이력을 뒤집니다.
④ 건에서 단계로, 단계에서 건으로	단계별 · 거래처별 집계에서 행을 누르면 그 단계를 기다리는 건이 열립니다. 병목 단계와 문제 거래처가 한 번의 클릭으로 건 목록이 됩니다.	요약표와 건 목록이 따로 있어 두 숫자를 맞춰 보는 일이 생깁니다.
⑤ 스스로 검산한다	출하 수량 = 청구 수량 + 미청구 수량, 통화별 외화 × 환율 = 원화 환산, 단계별 건수 합계 = 전체 건수 같은 대사 8건을 화면 안에서 돌려 차이가 0 인지 보입니다.	숫자가 틀렸는지는 누군가 의심한 뒤에야 확인합니다.
⑥ 규정 값을 만들어 내지 않는다	표준 소요일과 허용 지연일은 회사가 정하는 기준값이고, 관세율 · 시행일 같은 규정 값은 다루지 않습니다. 확인하지 못한 값은 “확인 필요” 로 적습니다.	화면에 박힌 기준이 규정인지 관행인지 알 수 없게 됩니다.

이 샘플에서 보이는 것

샘플 자료는 가상 해외 거래처 12곳의 수출 64건(통화 USD · EUR · JPY · CNY), 단계 448행입니다. 보류 건 2건을 빼고 62건을 판정하면 30건이 점검 필요입니다. 건별 최대 단계 지연일은 평균 4.44일이고 가장 긴 것은 14일입니다. 평균만 보면 가벼워 보이지만, 단계로 묶으면 선적 · 선하증권(B/L) 단계 15.87%, 수출통관 단계 19.35% 가 기준(15%)을 넘고 나머지 단계는 넘지 않습니다. 지연이 고르게 퍼져 있지 않고 서류가 오가는 두 단계에 몰려 있다는 사실이 이 화면의 첫 번째 발견입니다.

이 화면이 하지 않는 일 — 점검 필요는 ‘계획일과 실적일의 차이가 기준을 넘었다’ 는 신호이며 원인을 단정하지 않습니다. 세관 신고나 세무 신고와 관련한 판단은 회사와 관세사 · 세무 대리인이 합니다. 최종 판단은 회사와 담당 부서가 합니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

**처음 연 화면** — 회계연도 2026 으로 수출 64건을 조회한 첫 화면입니다. 위쪽 요약에 수출 건수 · 판정 대상 · 점검 필요 건수 · 평균 최대 단계 지연일 · 진행 중 원화 환산 · 대사 차이 건수가 나오고, 아래 표는 수주일이 최근인 건부터 늘어섭니다.

조회조건은 회계연도(필수)와 거래처 · 통화 · 인코텀즈 · 현재 단계 · 수주일 범위 · 판정입니다. 앱을 열면 회계연도 2026 으로 바로 조회되어, 처음 여는 사람도 빈 화면을 보지 않습니다. 요약 여섯 칸은 아래 표와 같은 자료에서 다시 계산한 값이라 표와 어긋날 수 없습니다.

**점검 필요만 조회** — 판정을 점검 필요로 고르고 조회하면 허용 지연일을 넘긴 단계가 한 곳이라도 있는 수출 30건만 남습니다. 요약 숫자도 같은 조건으로 다시 계산됩니다.

판정 칸 하나로 ‘지금 들여다볼 건’ 만 추립니다. 보류 건은 판정에서 빠지므로 이 목록에 나오지 않습니다. 조건을 바꿀 때마다 요약이 같이 바뀌어서, 목록과 숫자를 따로 맞춰 볼 필요가 없습니다.

단계 명세로 내려가기

**단계 명세 탭** — 수출 건마다 일곱 단계를 한 줄씩 펼친 448행입니다. 계획일 · 실적일 · 지연일 · 허용 지연일 · 단계 상태와 판정 근거(날짜 계산식)를 함께 보여 줍니다.

“왜 점검 필요인가” 에 대한 답이 판정 근거 열에 날짜 계산식으로 적혀 있습니다. 끝나지 않은 단계는 실적일이 비어 있고, 기준일(2026-09-30)로 지연일을 셉니다.

**단계별 지연 탭** — 일곱 단계를 한 줄씩 묶어 완료 · 대기 중 · 보류 건수와 점검 필요 비율, 평균 · 최대 지연일을 견줍니다. 비율이 15.00% 이상인 선적 · 선하증권(B/L) 단계와 수출통관 단계가 점검 필요로 표시됩니다.

건별로 보던 지연을 단계별로 묶으면 병목이 보입니다. 이 샘플에서는 선적·선하증권(B/L) 15.87%, 수출통관 19.35% 가 기준을 넘고 나머지 단계는 넘지 않습니다. 전체 지연일 평균이 4.44일로 낮아도 특정 단계에 쏠린 지연이 있다는 뜻입니다.

거래처와 대사

**거래처별 탭** — 거래처마다 수출 건수와 점검 필요 비율, 원화 환산 합계를 모읍니다. 점검 필요 비율이 60.00% 이상이면 점검 필요로 표시합니다. 외화 금액은 통화가 달라 더하지 않고 원화 환산 금액만 더합니다.

12개 거래처 가운데 네 곳이 기준을 넘습니다. 한 거래처의 건수가 적으면 비율이 크게 흔들리므로, 비율 옆에 판정 건수를 함께 둡니다.

**대사 결과 탭** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**행 클릭 상세** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

하고 싶은 일	SAP 표준	표준에서 걸리는 자리	이 앱이 하는 일
수주 · 인코텀즈 · 통화 확인	`VA03`	오더 한 건씩 열어야 하고 수출 건 목록 단위의 단계 비교가 없습니다	수출 건 한 줄에 수주일 · 인코텀즈 · 통화 · 금액을 모읍니다
출하 문서와 출하일 확인	`VL03N`	출하 문서 단위라 수주 · 청구와 한 줄로 이어 보이지 않습니다	출하일을 출하 단계 실적일로 쓰고 계획일과 견줍니다
청구 문서 확인	`VF03`	청구 문서 단위입니다	청구일과 청구 수량을 청구 단계에 붙이고 미청구 수량을 대사합니다
고객 미결 · 반제 확인	`FBL5N` · `VF05`	대금이 들어왔는지는 보이지만 ‘언제까지 들어왔어야 하는지’ 는 보이지 않습니다	회수일을 마지막 단계 실적일로 쓰고 계획일과의 차이를 셉니다
단계별 지연 계산	—	표준에 없습니다. 보통 엑셀로 만듭니다	일곱 단계의 계획일을 앞 단계 실적일에서 이어 세워 지연일을 계산합니다
병목 단계 찾기	—	표준에 없습니다	단계별 점검 필요 비율을 한 표로 견줍니다
문제 거래처 찾기	`FBL5N` 연체 분석	대금 연체 기준이라 선적 · 통관 지연은 보이지 않습니다	거래처별 점검 필요 비율과 원화 환산 합계를 모읍니다

자료가 어디서 오는가

수출 한 건의 일곱 단계 일자는 한 테이블에 있지 않고 여러 문서에 흩어져 있습니다. 수주일은 판매 오더에서, 출하일은 출하 문서에서, 청구일은 청구 문서에서, 회수일은 고객 반제 항목에서 읽습니다. 반면 선적(B/L) 일자 · 수출통관 일자 · 네고 · 추심 일자는 고객사의 수출 구성(물류 모듈 · 무역 서류 연동 · 별도 테이블)에 따라 위치가 다르므로 이 글에서는 “확인 필요” 로 표시했습니다. 도입 때 가장 먼저 합의할 일이 이 세 일자의 출처입니다.

단계 정의와 기준값

단계 코드	단계	표준 소요일	허용 지연일	일자의 출처
10	수주	0	0	판매 오더 수주일
20	출하	14	2	출하 문서의 출하 일자
30	선적 · 선하증권(B/L)	5	2	출하 문서의 선적 일자 (B/L 일자는 확인 필요)
40	수출통관	3	1	확인 필요 (수출통관 자료)
50	청구	2	2	청구 문서의 청구일
60	네고 · 추심	5	3	확인 필요 (네고 · 추심 자료)
70	대금 회수	30	7	고객 반제 항목의 반제일

위 표준 소요일과 허용 지연일은 샘플에서 가정한 값입니다. 실제 값은 회사의 거래 조건과 업무 기준으로 정해야 하며, 이 글은 규정 값(관세율 · 신고 기한 등)을 다루지 않습니다.

판정 규칙

데모를 신청하신 고객께 공개되는 내용입니다

CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.

데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.

데모 신청하기 Google 계정으로 로그인

화면을 열기 전에 정할 것

기준일 — 끝나지 않은 단계의 지연일을 어느 날짜로 셀지 정합니다. 샘플은 2026-09-30 로 고정했고, 운영에서는 조회일이나 마감일 가운데 정해야 합니다.
보류 건의 범위 — 협상 중이거나 선적 지시가 내려오지 않은 건을 판정에서 뺄지 정합니다.
표준 소요일과 허용 지연일 — 단계별 숫자를 거래 조건(인코텀즈 · 운송 방식)에 따라 나눌지 정합니다.
점검 필요 비율의 기준 — 단계 15%, 거래처 60% 는 샘플 값입니다.

CDS 구성

데모를 신청하신 고객께 공개되는 내용입니다

데모 신청하기 Google 계정으로 로그인

자주 묻는 질문

도입 상담과 데모에서 실제로 받을 만한 질문들을 25개로 정리했습니다. 네 묶음으로 나눠 적었습니다.

업무 질문

이 화면은 어떤 업무에 쓰나요?

수출 건이 수주부터 대금 회수까지 일곱 단계 가운데 어디에서 계획보다 늦어지는지 찾는 점검 도구입니다. 수출 진행 관리 담당자가 지연이 쌓이기 전에 늦은 단계를 확인하는 용도이며, 최종 판단은 회사와 담당 부서가 합니다.

표준 SAP 화면으로 충분하지 않나요?

판매 오더 · 출하 · 청구 · 고객 개별 항목은 표준 T-code(VA03 · VL03N · VF03 · FBL5N)로 각각 조회할 수 있습니다. 이 화면은 같은 데이터를 수출 건 단위로 이어 단계별 지연일을 계산해 보여 주는 조회 관점을 더하며, 표준 화면을 대체하지 않습니다.

점검 필요가 나오면 잘못된 것인가요?

아닙니다. 점검 필요는 계획일과 실적일의 차이가 허용 지연일을 넘었다는 신호입니다. 원인을 단정하지 않으며, 세관 신고나 세무 신고와 관련한 판단은 회사와 관세사 · 세무 대리인이 합니다.

보류 건은 왜 판정하지 않나요?

보류는 지연이 아니라 ‘진행을 멈추기로 한 상태’ 이기 때문입니다. 보류 건까지 판정하면 일부러 멈춘 건이 지연으로 쌓여 병목 단계가 왜곡됩니다. 대신 대사 결과에 의도적 예외로 따로 세어 두어, 빠진 건이 몇 건인지는 항상 보입니다.

현재 단계는 어떻게 정하나요?

끝나지 않은 단계 가운데 가장 앞 번호입니다. 일곱 단계가 모두 끝났으면 ‘전 단계 완료’ 로 표시합니다. 앞 단계가 끝나지 않았는데 뒤 단계의 일자가 있는 경우는 운영 자료에서 드물지 않으므로, 이런 건을 따로 점검하는 기준을 도입 때 정하는 편이 좋습니다.

여러 번 나눠 출하한 건은 어떻게 보나요?

샘플에는 부분 출하 건이 들어 있습니다. 출하 수량과 청구 수량 · 미청구 수량이 대사식으로 맞는지 확인하고, 출하 단계의 실적일을 어떤 출하(첫 출하 · 마지막 출하)로 삼을지는 도입 때 정해야 하는 규칙이며 운영 기준은 확인 필요입니다.

계산 규칙

계획일은 어떻게 계산하나요?

앞 단계 실적일에 그 단계의 표준 소요일을 더한 값입니다. 예를 들어 출하일이 3월 10일이고 선적의 표준 소요일이 5일이면 선적 계획일은 3월 15일입니다. 수주일 기준으로 모든 단계의 계획일을 한 번에 세우지 않는 이유는, 앞 단계 지연이 뒤 단계 지연으로 번져 어느 단계가 늦었는지 흐려지기 때문입니다.

아직 끝나지 않은 단계의 지연일은 어떻게 세나요?

실적일이 없으면 기준일(샘플은 2026-09-30)을 실적일처럼 놓고 계획일과의 차이를 셉니다. 계획일이 기준일보다 뒤라면 아직 늦은 것이 아니므로 지연일은 0 입니다. 운영에서는 기준일을 조회일로 할지 마감일로 할지 정해야 합니다.

표준 소요일과 허용 지연일은 어디서 오나요?

샘플에서는 단계별로 가정한 값입니다(출하 14일 · 2일, 선적 5일 · 2일, 통관 3일 · 1일, 청구 2일 · 2일, 네고·추심 5일 · 3일, 대금 회수 30일 · 7일). 실제 운영에서는 회사의 거래 조건과 업무 기준으로 정해야 하며, 이 글은 시행일이나 관세율 같은 규정 값을 다루지 않습니다.

허용 지연일과 표준 소요일의 차이는 무엇인가요?

표준 소요일은 ‘정상이라면 이만큼 걸린다’ 는 기준이고, 허용 지연일은 ‘그보다 며칠 늦어도 점검하지 않는다’ 는 여유입니다. 둘을 나눠 두어야 소요일이 긴 대금 회수 단계(30일)에도, 소요일이 짧은 통관 단계(3일)에도 각자의 여유를 줄 수 있습니다.

단계별 비율 15%, 거래처별 비율 60% 는 어디서 왔나요?

샘플에서 정한 기준입니다. 처음에는 25% 로 두었는데 어느 단계도 걸리지 않아 판정 화면을 보여 줄 수 없었고, 15% 로 낮추어 두 단계가 걸리게 했습니다. 즉 이 값은 업무 규정이 아니라 데모용 기준이며, 운영에서는 과거 자료의 분포를 보고 정해야 합니다.

외화 금액은 왜 더하지 않나요?

통화가 다른 금액을 그대로 더하면 의미가 없습니다. 그래서 외화 금액은 건별로만 보여 주고, 합계는 원화 환산 금액으로만 냅니다. 환산은 샘플에서 가정한 환율을 쓰며, 운영에서는 환율 기준일과 환율 유형을 정해야 합니다.

화면과 서비스

요약 여섯 칸은 어디서 계산하나요?

진행 현황과 대사 결과를 읽은 뒤 화면 컨트롤러 한 함수에서 계산합니다. 같은 조건으로 표와 요약을 읽기 때문에 둘이 어긋나지 않습니다. 건수가 많아지면 이 계산을 서비스(CDS 집계)로 옮기는 것이 첫 번째 변경 사항입니다.

조회조건은 서버로 어떻게 전달되나요?

화면의 조건은 $filter 로 실립니다. 회계연도 · 거래처 · 통화 · 인코텀즈 · 현재 단계 · 판정은 같음(eq) 조건이고, 수주일 범위는 ge · le 로 나갑니다. 전체를 고르면 그 조건 자체를 만들지 않습니다.

서비스는 어떻게 구성되어 있나요?

엔티티셋 5개(진행 현황 · 단계 명세 · 단계별 요약 · 거래처 요약 · 대사 결과)와 펑션 2개(최대 지연일 · 평균 지연일)로 되어 있고, 모두 OData V2 의 표준 요청(조회 · 단건 · 정렬 · 페이징)으로 부릅니다. 서비스 경로는 앱 설정 파일에 상대 경로로 선언합니다.

같은 화면으로 수정이나 삭제도 하나요?

아닙니다. 이 화면은 조회 · 점검 전용입니다. 서비스 구현에는 생성 · 수정 · 삭제 함수가 갖춰져 있지만 화면은 부르지 않습니다. 점검 결과에 대한 조치 기록이 필요하면 별도 엔티티셋을 더하는 방식으로 확장합니다.

CSV 로 내려받으면 무엇이 담기나요?

지금 보고 있는 탭의 조건에 맞는 전체 행입니다. 화면에 보이는 열과 같은 순서로 내려가고, 판정 근거도 함께 담깁니다. 한 번에 내려받을 수 있는 행 수의 상한은 운영 환경에서 정해야 합니다.

수출 건이 수만 건이면 어떻게 되나요?

샘플은 64건이라 서비스가 전체를 돌려주고 화면이 요약을 계산합니다. 건수가 늘면 요약 계산을 서비스로 옮기고, 목록은 $top · $skip 으로 나눠 받아야 합니다. 이 글의 CDS 구성이 그 전환의 설계입니다.

도입과 운영

도입에서 가장 먼저 걸리는 것은 무엇인가요?

선적(B/L) · 수출통관 · 네고 · 추심 일자가 SAP 어디에 쌓이는지입니다. 판매 오더 · 출하 · 청구 · 반제 일자는 표준에서 읽을 수 있지만 나머지 세 일자는 고객사의 수출 구성에 따라 달라서, 이 글에서도 “확인 필요” 로 표시했습니다.

개발보다 합의가 더 많다는 말은 무슨 뜻인가요?

단계 기준값, 기준일, 보류 건 범위, 부분 출하 규칙, 비율 기준은 모두 코드가 아니라 업무 합의입니다. 합의가 끝나면 기술 작업은 CDS 뷰를 만들고 화면을 올리는 일입니다. 합의 없이 코드를 먼저 쓰면 첫 회의에서 “이 숫자는 왜 이런가” 로 막힙니다.

권한은 어떻게 거나요?

판매 조직과 거래처 권한을 집계 뷰에 겁니다. 상세에만 걸고 집계에 걸지 않으면 합계에서 뺀 값으로 다른 조직의 숫자가 드러납니다. CDS 구성의 마지막 코드가 그 예입니다.

매일 돌려서 알림을 받을 수 있나요?

가능합니다. 판정은 화면이 아니라 서비스(뷰)에 있으므로, 배치(SM36)에서 같은 조회를 호출해 점검 필요가 늘어난 날 담당자에게 알리는 구성을 붙일 수 있습니다. 샘플 화면에는 포함되어 있지 않습니다.

이 화면이 신고나 법정 보고에 쓰이나요?

아닙니다. 이 화면은 분류 · 집계 · 대사를 돕는 조회 · 점검 도구입니다. 세관 신고 · 세무 신고 · 공시와 같은 법정 보고는 표준 거래와 회사 · 전문가의 판단 아래 별도로 진행합니다.

숫자가 맞는지는 어떻게 확인했나요?

대사 8건을 화면 안에서 돌립니다 — 출하 수량 = 청구 수량 + 미청구 수량(64건), 단계별 건수 합계 = 전체 건수(64건), 통화별 외화 × 환율 = 원화 환산(USD 28 · EUR 16 · JPY 6 · CNY 14건), 지연일 재계산(370건) 모두 차이 0 입니다. 보류 건은 의도적 예외로 따로 셉니다.

도입 상담은 어떻게 받나요?

왼쪽 목차 아래 문의하기로 현재 SAP 환경(S/4HANA · ECC)과 궁금하신 점을 남겨 주시면 영업일 기준 1~2일 안에 회신드립니다. 같은 자리의 데모 열기로 실제 화면을 볼 수 있습니다.