수출 통관·검사 비용 다차원 분석 — 계획 대비 차이를 아홉 요인으로 가르고 신고 라인까지 내려가는 수출 솔루션 한 화면

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

월마감 때 통관 비용을 둘러싼 질문은 해마다 비슷합니다. 계획보다 얼마나 더 들었나, 왜 더 들었나, 누가 무엇을 줄여야 하나. 지금은 이 답이 청구 문서 조회 화면, 관세사 정산서, 보세 구역 보관료 청구서, 그리고 엑셀 대조표에 흩어져 있어서 한 번 맞추려면 여러 화면을 오가며 손으로 대조해야 합니다.

이 앱은 세 질문의 답을 한 화면에 붙입니다. 통관 세관 · 운송 방식 · 제품 그룹 · 고객 같은 축을 끌어다 놓고, 칸을 누르면 그 금액을 만든 신고 라인까지 내려가며, 계획과의 차이를 아홉 요인으로 가르고 합계가 총차이와 같은지 매번 검산합니다. 특정 기준서에 묶인 화면이 아니라 수출 통관 비용 · 검사 · 보세 보관 점검 영역의 분석 화면이라 관련 기준서는 없습니다. 표준 실행과 통관 · 세무 신고는 SAP 표준 T-code 와 관세사가 맡고, 이 화면은 조회 · 점검 관점을 더해 확장합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 5,343만 원 차이의 진짜 이유

통관 총비용이 계획보다 5,343만 원 많았다는 사실까지는 합계표도 말해 줍니다. 아홉 요인으로 가르자 큰 몫은 유료 보관일수(+2,185만 원)와 미계획 신고(+2,103만 원)였고, 신고 건수 요인(+740만 원)이 그 다음이었습니다. 수수료 단가나 검사 단가는 거의 움직이지 않았습니다. 금액만 보았다면 "통관 비용이 좀 늘었다"로 끝났을 회의가, 체류를 줄일지 계획에 없던 신고를 계획에 넣을지를 정하는 회의로 바뀝니다.

분해에는 조건을 걸었습니다. 아홉 요인의 합이 총차이와 1원도 어긋나면 안 됩니다. 화면이 매번 그 등식을 검산해 보여 주므로, 보고 자리에서 “이 숫자 맞아?” 라는 질문에 바로 답할 수 있습니다. 위 사례의 총차이는 53,430,495원이고 요인 합계도 같습니다.

도입하면 달라지는 것

• 월마감 통관 비용 보고 준비 — 차이 표 · 요인 분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나" 가 아니라 "체류와 검사를 어떻게 줄일 것인가" 를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 감시 — 아무도 화면을 열지 않아도 규칙에 걸린 항목이 대기함에 올라갑니다.

이런 회사에 맞습니다

수출 비중이 높고 신고 건수가 많아 관세사 수수료 · 검사 · 보세 보관 비용이 월마다 흩어져 들어오는 제조 · 수출 기업의 물류 · 관리회계 · 영업관리 조직에 맞습니다. 다통화 청구(USD · EUR · JPY · CNY)와 여러 세관 · 운송 방식을 함께 쓰는 회사일수록 효과가 큽니다.

실행 화면

실제로 돌아가는 화면 32종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 어떻게 읽는지를 아래에 적었습니다. 모든 숫자는 검증용 샘플 데이터이며 고객 · 요율 · 환율 · 신고 번호는 가정값입니다.

사용 방법

1. 회사코드와 시작 · 종료 청구월을 입력합니다. 비교 기준은 연초에 확정한 통관 비용 계획으로 고정돼 있고, 통관 세관 · 운송 방식 · 제품 그룹 · 고객 같은 차원 필터는 선택입니다.
2. 조회 단추를 누르거나 입력 칸에서 Enter 키를 누릅니다. 레이아웃에서 “기본 + 열 때 자동 조회” 로 저장해 둔 경우에만 화면을 열 때 한 번 자동으로 조회됩니다.
3. 요약 탭(CEO · CFO · 영업 책임자 · 물류 책임자)에서 통관 총비용 · 통관비용률 · 검사 · 검역 비용이 계획과 어떻게 다른지 먼저 봅니다.
4. 차원 칩을 끌어다 놓거나 칩 메뉴로 행 · 열 · 사용 안 함 칸에 옮깁니다. 행은 3단계, 열은 2단계까지 쌓입니다.
5. 궁금한 칸을 누르면 그 금액을 만든 신고 라인이 열립니다. 행 이름을 누르면 오른쪽 차트가 그 행의 요인 분해로 바뀝니다.
6. 비교 기준 대비를 켜면 같은 표에 차이가 붙습니다. 차이가 난 행에는 사유를 적어 둡니다.
7. 위쪽 단추로 AI 분석 · 에이전트 · 기간별 요약을 열고, AI 분석 창에서 PowerPoint 보고서를, 표 위 단추에서 CSV 를 내려받습니다.

무엇으로 만들었나

처음 열었을 때

조회 조건과 행 · 열 · 사용 안 함 세 칸의 배치 보드가 위에서부터 쌓이고, 조회를 누르면 요약 · 피벗 표 · 비교 차트가 한꺼번에 나타납니다. 머리 영역은 접을 수 있어 표를 넓게 볼 수 있습니다.

화면을 열면 조회 조건과 행 · 열 · 사용 안 함 세 칸의 배치 보드가 먼저 보입니다. 조회 버튼을 누르기 전에는 표가 비어 있고, 서비스도 부르지 않습니다. 시작·종료 청구월 기본값은 2026-01 ~ 2026-09, 비교 기준은 연초에 확정한 통관 비용 계획으로 고정돼 있습니다.

조회를 누르면 역할별 요약 · 피벗 표 · 비교 차트가 한 번에 나타납니다. 기본 배치는 행 제품 그룹 › 통관 세관이고, 맨 위 줄이 전체 합계입니다. 통관 총비용 848백만원, 통관비용률 0.17%, 검사 · 검역 비용 69백만원이 계획과 함께 붙습니다.

조회 조건 머리를 접으면 표와 차트가 화면을 넓게 씁니다. 접은 줄에도 회사코드 · 기간 · 행 · 열 · 항목 · 필터 수가 한 줄로 남아, 지금 어떤 조건의 숫자인지 잃지 않습니다.

역할별 요약 — 누가 보느냐에 따라 첫 화면이 달라진다

같은 큐브를 네 가지 관점으로 엽니다. 탭을 바꾸면 보여 주는 항목과 기본 행 차원이 함께 바뀌고, 합계는 어느 탭에서도 같습니다.

CEO 탭은 제품 그룹 › 통관 세관별 통관 총비용과 통관비용률, 검사 · 검역 비용을 보여 줍니다. 통관 비용이 수출 채산에 주는 부담을 한눈에 보려는 자리라, 통관비용률(총비용 ÷ 청구액)을 기본 항목에 둡니다.

CFO 탭은 청구월별로 통관 총비용의 구성(관세사 수수료 · 검사 · 보관 · 서류)과 계획 차이를 봅니다. 월마감 때 차이가 어느 달에 쌓였는지 찾는 용도입니다. 항목을 바꿔도 같은 큐브라 합계는 변하지 않습니다.

영업 책임자 탭은 수출 국가 · 고객별 통관 비용과 보류 · 장기 체류 건의 보관료를 확인합니다. 고객에게 설명하거나 인코텀즈 조건을 다시 볼 때 근거가 되는 숫자입니다.

물류 책임자 탭은 통관 세관 · 운송 방식별 검사 선별율과 유료 보관일수를 점검합니다. 같은 통관 비용이라도 검사 때문인지 보관 때문인지가 여기서 갈립니다.

축 전환과 범위 — 보고 싶은 순서로 다시 짠다

차원 칩 11개를 행 · 열 · 사용 안 함으로 옮기고, 값을 골라 범위를 좁힙니다. 배치를 바꾸는 동안에는 서비스를 부르지 않고, 필터와 기간을 바꿀 때만 다시 받아 옵니다.

차원 칩 11개는 행 · 열 · 사용 안 함 칸으로 끌어 놓거나 칩을 눌러 나오는 메뉴로 옮깁니다. 행은 최대 3단계, 열은 최대 2단계입니다. 칩을 옮기는 것만으로는 서비스를 부르지 않고 이미 받아 둔 큐브로 표를 다시 그립니다.

통관 세관과 운송 방식을 행으로 옮긴 모습입니다. 옮기는 동안 서비스 호출은 0건이며, 합계는 배치와 상관없이 같은 값입니다. 화면 위쪽 줄에서 행 축 · 열 축 요약을 확인할 수 있습니다.

열에도 차원을 두 개까지 올려 분기 × 운송 방식 같은 열 조합을 만듭니다. 열 조합이 상한(36열)을 넘으면 그리지 않고 안내 문구가 먼저 뜹니다.

차원 이름의 필터 단추를 누르면 값 선택창이 열립니다. 값마다 원천 신고 라인 수가 함께 보여, 어느 값이 큰 몫인지 알고 고를 수 있습니다.

인천공항세관과 인천세관(항)처럼 값을 여러 개 고를 수 있습니다. 적용을 누르면 선택한 값만 $filter 의 or 조건으로 묶여 범위가 좁아집니다.

필터를 적용한 결과입니다. 합계 · 요약 · 차트가 같은 범위로 다시 계산되고, 접은 머리 줄의 필터 수도 함께 바뀝니다.

표와 차트 사이 손잡이를 끌면 차트 폭이 바뀌고, 그 폭은 이 브라우저에 남습니다. 표를 넓게 보고 싶을 때와 차트를 크게 보고 싶을 때를 각자 정합니다.

칸에서 신고 라인까지 — 숫자의 출처를 바로 확인

표의 칸을 누르면 그 칸의 조건이 그대로 조회 조건이 되어 원천 신고 라인이 열립니다. 칸 값과 원천 합계가 같은지 맨 위 한 줄이 알려 줍니다.

표의 칸을 누르면 그 칸의 조건(회사코드 · 청구월 범위 · 행 경로 · 열 조합)이 그대로 조회 조건이 되어 원천 신고 라인이 열립니다. 맨 위 한 줄이 칸 값과 원천 합계가 같은지 알려 주며, 아래에 실제로 만든 OData 질의가 보입니다.

라인 표를 오른쪽으로 밀면 검사 건수 · 보관일수 · 관세사 수수료 · 검사 비용 · 보관료 · 서류비 열이 나옵니다. 열마다 합계를 직접 더해 보면 칸 값과 같습니다.

기간별 요약은 서비스가 원천 신고 라인을 청구월별로 다시 합산한 값을 계획과 나란히 보여 줍니다. 피벗의 월별 숫자와 이 표의 숫자가 같아야 하며, 다르면 큐브 점검이 걸립니다.

계산항목 — 합계끼리 다시 나눈 비율

통관비용률 · 검사 선별율처럼 어떤 필드에도 적혀 있지 않은 값은 계산항목으로 정의해 둡니다. 비율은 칸 비율의 평균이 아니라 항상 합계에서 다시 나눕니다.

분석 항목 목록에는 측정값과 계산항목이 함께 있습니다. 통관비용률 · 신고 1건당 비용 · 검사 선별율 · 검사 1회 평균 비용 · 신고 1건당 유료 보관일수 · 보관료 비중이 계산항목이며 비율은 항상 합계에서 다시 나눕니다.

단계 보기에서는 항목이 행으로 놓이고 행 차원이 위에서부터 한 단계씩 펼쳐집니다. 총비용에서 구성 비용으로 내려가는 순서를 따라 읽을 때 씁니다.

계산항목은 열 차원과 함께 쓰면 분기별 · 운송 방식별 비율로 펼쳐집니다. 합계 칸의 비율도 합계끼리 나눈 값이라 칸 비율의 평균과 다를 수 있습니다.

계획 대비 차이 · 변동 사유 · 요인 분해 — 같은 표가 월마감 자료가 된다

비교 기준을 계획으로 두면 칸마다 차이가 붙고, 차이가 난 행에는 사유를 적어 둡니다. 차트를 차이 분해로 바꾸면 계획에서 실적까지가 아홉 요인의 폭포로 그려지고 합계가 총차이와 같은지 매번 검산합니다.

기준 대비를 켜면 칸마다 계획값과 차이, 증감률이 붙습니다. 비용은 늘수록 불리하므로 계획을 넘는 차이가 붉게 표시되고, 금액과 증감률 두 기준을 함께 넘는 칸만 색이 입혀집니다.

차이가 있는 행의 사유 단추를 누르면 사유 구분(신고 건수 변동 · 수수료 · 검사 · 체류 · 요율 · 미계획 · 기타)과 내용을 적는 창이 열립니다. 사유의 키는 조회 범위와 행 경로입니다.

사유를 저장한 행에는 표시가 붙고, 축을 바꾸거나 다시 조회해도 같은 행이면 사유가 따라옵니다. CSV와 AI 분석 근거에도 함께 실립니다.

차트를 차이 분해로 바꾸면 계획에서 실적까지가 아홉 요인의 폭포로 그려집니다. 이 자료에서는 유료 보관일수(+22백만원)와 미계획 신고(+21백만원)가 큰 몫이고, 맨 아래 검산 줄이 요인 합 53과 총차이 53이 같음을 알려 줍니다.

행 이름을 누르면 그 행만의 요인 분해로 바뀝니다. 인천공항세관은 계획 192에서 실적 207로 15백만원 늘었고 요인 합계도 15로 맞습니다.

행 수가 500을 넘으면 표를 그리지 않고 차원을 줄이거나 필터를 걸라고 안내합니다. 화면이 멈추는 것보다 안내가 낫다는 판단으로 둔 상한입니다.

AI 분석과 보고서 — 숫자는 서비스가, 설명만 모델이

현재 범위의 숫자는 서비스가 큐브에서 먼저 계산해 근거로 만들고, 해설은 그 근거를 읽어 씁니다. 읽은 내용은 표와 차트를 담은 PowerPoint 보고서로 바로 내려받을 수 있습니다.

AI 분석은 현재 범위의 숫자를 서비스가 먼저 계산해 근거로 만들고, 그 근거를 읽어 요약과 주요 발견을 씁니다. 이미 사유가 적힌 차이는 건너뛰며, 모델을 끄면 같은 근거로 규칙 기반 해설이 나옵니다.

AI 에이전트 — 사람이 열지 않아도 도는 점검

감시 규칙에 걸린 항목이 받을 역할별 대기함에 올라갑니다. 판단과 기록은 화면이 아니라 서비스에 있어 배치나 타이머가 같은 문을 두드립니다.

에이전트 실행 기록에는 실행 번호 · 시각 · 실행 주체(사람 · 타이머 · 배치) · 결과가 남습니다. 하루 한 번 제한은 서비스가 판정하므로 두 번째 실행은 건너뜀으로 기록됩니다.

감시 규칙에 걸린 항목이 받을 역할별 대기함에 쌓입니다. 규칙은 총비용 계획 차이 · 통관비용률 · 검사 선별율 · 유료 보관일수 · 보류 건 보관료 다섯 가지이며 임계값은 화면에서 고칩니다.

레이아웃 저장과 복원

짜 둔 축은 이름을 붙여 저장해 두고, 기본으로 지정하면 다음에 열 때 그 배치로 시작합니다.

현재 행 · 열 · 항목 · 필터를 이름을 붙여 저장합니다. 기본으로 지정하면 다음에 열 때 그 배치로 시작하고, 열 때 자동 조회를 함께 켤 수 있습니다.

기본 + 자동 조회로 저장한 배치는 새로 고침 뒤에 조회된 채로 열립니다. 저장한 사유도 같은 방식으로 다시 보입니다.

좁은 화면과 한계

휴대폰 폭에서도 같은 리포트를 봅니다. 한편 행이 너무 많아지는 조합은 그리지 않고 안내합니다.

폭 390px 같은 좁은 화면에서는 조회 조건 칸이 위아래로 쌓이고 차트는 표 아래로 내려갑니다. 가로로 밀어 보는 표는 남아 있지만 화면 전체가 옆으로 넘치지는 않습니다.

화면 뒤에서 일어나는 일

화면의 숫자는 신고 라인의 상태에서 한 가지 방식으로만 만들어집니다. 아래 표는 라인이 어떤 상태일 때 비용이 어떻게 합산되고, 보는 사람이 무엇을 하면 되는지를 정리한 것입니다.

차이를 아홉 요인으로 가르는 순서

1. 실적 큐브와 계획 큐브를 같은 차원 조합(청구월 · 통관 세관 · 운송 방식 · 제품 그룹 · 고객 · 인코텀즈)으로 맞붙입니다.
2. 양쪽에 모두 있는 칸은 신고 건수 → 건당 수수료 → 검사 선별율 → 검사 1회 단가 → 신고당 유료 보관일수 → 일 보관료 → 서류비 순서로 계획값을 실적값으로 바꿔 가며 총비용이 움직인 만큼을 요인별로 적습니다.
3. 계획에만 있는 칸은 계획 미이행(계획 총비용을 뺌), 실적에만 있는 칸은 미계획 신고(실적 총비용을 더함)로 따로 세웁니다.
4. 반올림 잔차는 서류비 · 반올림 요인에 얹어 합계를 맞춥니다.
5. 아홉 요인의 합과 총차이를 비교해 차이가 0 원인지 화면 맨 아래에 적습니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

• 조회 조건 — 입력 칸이 위아래로 쌓이고, 머리 영역을 접어 표 자리를 넓힙니다.
• 차트 — 숨기지 않고 표 아래로 내려갑니다. 차트 폭 손잡이는 넓은 화면에서만 쓰입니다.
• 표 — 가로로 밀어 보되 화면 전체가 옆으로 넘치지는 않습니다.
• 상한 — 행 수 500, 열 조합 36을 넘으면 그리지 않고 차원을 줄이거나 필터를 걸라고 안내합니다.

파일 구성

(앱 폴더)
├─ 화면 진입 파일 · 구성 정의 · 문구 파일(i18n)
├─ controller/   화면 제어 — 조회 · 배치 보드 · 드릴스루 · 사유 · AI · 에이전트
├─ model/        큐브 재집계 · 차트(SVG) · 레이아웃 저장 · 보고서(PPTX) 생성 · 서식
├─ view/         화면 정의(XML) · 팝업 조각
├─ css/          화면 서식
├─ odata/        서비스 로직 · 공용 엔진 · 서비스 정의 · 샘플 자료(JSON)
└─ media/        소개 영상 · 첫 장면 · 재생 지점 목록

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 점검 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 리포트를 없애야 하나” 라는 질문에는 없애지 않고 둡니다 라고 답합니다. 대사와 감사 대응, 통관 · 세무 신고는 표준 거래와 관세사가 맡는 편이 안전합니다. 이 앱 결과에서 원천을 확인하려면 칸을 눌러 신고 라인을 열고 표 위의 금액을 아래 표준 화면의 값과 맞춰 보면 됩니다.

분석 지표 정의

화면에서 쓰는 지표가 무엇으로 계산되고 어디서 오는지를 한 표로 모았습니다. 원천이 환경마다 달라지는 자리는 “확인 필요” 로 적었습니다.

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

S/4HANA 의 표준 CDS 분석 쿼리나 Fiori 분석 앱은 표준 문서 흐름의 금액을 보는 데 쓰이고, 이 화면은 그 위에 통관 비용 차원(세관 · 운송 방식 · 검사 구분 · 체류일)과 계획 대비 차이 분해를 더하는 자리입니다. 표준 분석 앱과 겹치는 부분은 표준을 그대로 쓰고, 겹치지 않는 부분만 이 큐브로 보강합니다. 특정 Fiori 앱 이름과 기능은 환경 버전에 따라 달라 확인 필요입니다.

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

CDS 구성

이 사례의 화면은 신고 라인 6,110줄을 서비스가 큐브 652행으로 묶어 내려줍니다. 데모라서 되는 일이고, 운영 데이터에서는 그 묶기를 CDS 뷰가 맡습니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다. 각 뷰가 무엇을 결정하는지, 왜 나누는지를 코드 앞에 적었습니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 뷰 탐색기로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 기준 테이블 — 무상 보관일 · 일 보관료 · 세관 대응

무상 보관 3일과 일 보관료는 샘플 가정입니다. 운영에서는 보세 구역과 계약마다 달라지므로 코드에 박지 않고 설정 테이블에 둡니다. 이 값이 바뀌면 유료 보관일수와 보관료가 모두 달라지므로 변경 이력을 남기는 쪽을 권합니다.

" ──────────────────────────────────────────────────────────
" ZEXCLR_CFG — 무상 보관일 · 일 보관료를 담는 설정 테이블
" 이렇게 나눈 이유: 요율을 코드에 박지 않고 데이터로 두려고
" ──────────────────────────────────────────────────────────
@EndUserText.label : '통관 비용 기준 — 무상 보관일 · 일 보관료'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexclr_cfg {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key port       : abap.char(4) not null;     " 통관 세관 코드
  free_days      : abap.int2;                 " 무상 보관일(샘플 가정 3)
  @Semantics.amount.currencyCode : 'zexclr_cfg.waers'
  store_rate     : abap.curr(15,2);           " 일 보관료
  waers          : waers;
  valid_from     : abap.dats;
}

② 차원 뷰 — 세관 · 운송 방식 · 검사 구분

필터 값 선택창과 표의 행 이름이 같은 이름을 쓰게 하려는 뷰입니다. 코드값과 이름을 한 번만 정의해 두면 화면 · 쿼리 · 보고서가 같은 텍스트를 읽습니다.

" ──────────────────────────────────────────────────────────
" ZI_ExportClearancePort — 세관 차원 뷰
" 이렇게 나눈 이유: 필터 값 목록과 표의 행 이름을 한 곳에서 만들려고
" ──────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '통관 세관 차원'
@ObjectModel.usageType : { serviceQuality : #A, sizeCategory : #S, dataClass : #CUSTOMIZING }
@Analytics.dataCategory : #DIMENSION
define view entity ZI_ExportClearancePort
  as select from zexclr_cfg
{
  key bukrs as CompanyCode,
  key port  as CustomsPort,
      free_days as FreeDays
}

③ 신고 라인 뷰 — 청구 문서 품목에 비용을 붙인다

드릴스루가 닿는 가장 낮은 단계입니다. 청구 문서 품목(표준)에 통관 신고 결과 테이블을 붙이는데, 이 신고 결과의 원천은 환경마다 달라 확인 필요입니다. 비용은 전표 또는 요율 × 건수로 만듭니다.

" ──────────────────────────────────────────────────────────
" ZI_ExportClearanceItem — 신고 라인 뷰
" 이렇게 나눈 이유: 드릴스루가 닿는 가장 낮은 단계를 한 곳에 두려고
" ──────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수출 통관 신고 라인'
@ObjectModel.usageType : { serviceQuality : #C, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
define view entity ZI_ExportClearanceItem
  as select from I_BillingDocumentItem as Item
    inner join   I_BillingDocument     as Hdr  on Hdr.BillingDocument = Item.BillingDocument
    inner join   zexclr_decl           as Decl on Decl.billing_doc  = Item.BillingDocument
                                              and Decl.billing_item = Item.BillingDocumentItem   " 신고 결과(원천은 확인 필요)
    left outer join zexclr_cfg         as Cfg  on Cfg.bukrs = Hdr.CompanyCode
                                              and Cfg.port  = Decl.port
{
  key Item.BillingDocument        as BillingDocument,
  key Item.BillingDocumentItem    as BillingDocumentItem,
      Hdr.CompanyCode             as CompanyCode,
      Hdr.BillingDocumentDate     as BillDate,
      Hdr.SoldToParty             as Customer,
      Decl.port                   as CustomsPort,
      Decl.mode                   as TransportMode,
      Decl.insp_type              as InspectionType,
      Decl.stay_days              as StayDays,
      case when Decl.stay_days > coalesce( Cfg.free_days, 3 )
           then Decl.stay_days - coalesce( Cfg.free_days, 3 ) else 0 end as ChargeableDays,
      @Semantics.amount.currencyCode : 'Currency'
      Item.NetAmount              as GrossAmount,
      Item.TransactionCurrency    as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      Decl.broker_fee             as BrokerFee,
      @Semantics.amount.currencyCode : 'Currency'
      Decl.inspect_cost           as InspectCost
}

④ 실적 큐브 — 라인을 차원 조합으로 집계

서비스의 큐브 집합과 같은 단위(청구월 × 세관 × 운송 방식 × 제품 그룹 × 고객 × 인코텀즈)로 집계합니다. 통관 총비용은 네 비용의 합이고, 비율은 이 뷰에서 만들지 않고 쿼리에서 합계끼리 나눕니다.

" ──────────────────────────────────────────────────────────
" ZI_ExportClearanceCube — 실적 큐브
" 이렇게 나눈 이유: 화면이 들고 묶던 일을 데이터베이스로 내리려고
" ──────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '통관 비용 큐브(실적)'
@Analytics.dataCategory : #CUBE
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XL, dataClass : #MIXED }
define view entity ZI_ExportClearanceCube
  as select from ZI_ExportClearanceItem
{
  key CompanyCode,
  key cast( substring( cast( BillDate as abap.char(8) ), 1, 6 ) as abap.char(6) ) as BillPeriod,
  key CustomsPort,
  key TransportMode,
  key Customer,
      @Semantics.amount.currencyCode : 'Currency'
      sum( GrossAmount )                                            as Gross,
      @Semantics.amount.currencyCode : 'Currency'
      sum( BrokerFee + InspectCost )                                as BrokerAndInspect,
      sum( ChargeableDays )                                         as ChargeableDays,
      count( * )                                                    as DeclarationCount,
      Currency
}
group by CompanyCode, substring( cast( BillDate as abap.char(8) ), 1, 6 ),
         CustomsPort, TransportMode, Customer, Currency

⑤ 계획 큐브 — 실적과 같은 모양

차이 분해는 실적과 계획이 같은 차원 조합을 가져야 성립합니다. 계획에는 있는데 실적에 없는 칸이 계획 미이행, 실적에는 있는데 계획에 없는 칸이 미계획 신고로 잡힙니다. 계획 원천은 확인 필요입니다.

" ──────────────────────────────────────────────────────────
" ZI_ExportClearancePlan — 계획 큐브
" 이렇게 나눈 이유: 실적과 같은 키 모양이어야 차이 분해가 성립해서
" ──────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '통관 비용 큐브(계획)'
@Analytics.dataCategory : #CUBE
define view entity ZI_ExportClearancePlan
  as select from zexclr_plan                        " 연초 계획 테이블(원천은 확인 필요)
{
  key bukrs   as CompanyCode,
  key version as PlanVersion,
  key period  as BillPeriod,
  key port    as CustomsPort,
  key mode    as TransportMode,
  key partner as Customer,
      @Semantics.amount.currencyCode : 'Currency'
      plan_total as PlanTotal,
      plan_lines as PlanLines,
      currency   as Currency
}

⑥ 분석 쿼리 — 화면이 부르는 단일 진입점

조회 조건 필터와 정렬, 노출 항목을 정의합니다. 회사코드와 청구월은 필수 필터로 두어 전체 스캔을 막습니다. 통관비용률 같은 비율은 여기서 합계끼리 나눕니다.

" ──────────────────────────────────────────────────────────
" ZC_ExportClearanceQuery — 분석 쿼리
" 이렇게 나눈 이유: 화면이 부르는 단일 진입점으로 두려고
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '통관 비용 분석 쿼리'
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XL, dataClass : #MIXED }
@Metadata.allowExtensions : true
define view entity ZC_ExportClearanceQuery
  as projection on ZI_ExportClearanceCube
{
  @Consumption.filter : { mandatory : true, selectionType : #SINGLE }
  key CompanyCode,
  @Consumption.filter : { mandatory : true, selectionType : #INTERVAL }
  key BillPeriod,
  @Consumption.filter.selectionType : #MULTIPLE_OR_RANGE
  key CustomsPort,
  key TransportMode,
  key Customer,
  Gross,
  BrokerAndInspect,
  ChargeableDays,
  DeclarationCount
}

⑦ 권한 — 집계 단계에 건다

드릴스루 라인에만 권한을 걸면 합계 − 자기 몫 같은 뺄셈으로 남의 숫자가 드러납니다. 그래서 큐브 쿼리 단계에서 회사코드와 세관 기준으로 거릅니다. 권한 오브젝트와 필드는 고객사 설계에 따릅니다.

" ──────────────────────────────────────────────────────────
" ZC_ExportClearanceQuery (DCL) — 권한 정의
" 이렇게 나눈 이유: 집계 단계에 걸어야 합계로 새지 않아서
" ──────────────────────────────────────────────────────────
@EndUserText.label : '통관 비용 분석 권한'
@MappingRole : true
define role ZC_ExportClearanceQuery {
  grant select on ZC_ExportClearanceQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

서비스 정의에서 쿼리를 노출하고 바인딩을 OData V2 로 게시합니다. 게시 뒤 화면의 manifest 서비스 주소를 이 서비스로 바꾸면 같은 화면이 실제 데이터로 열립니다.

" ──────────────────────────────────────────────────────────
" ZUI_ExportClearance — 서비스 정의와 바인딩
" 이렇게 나눈 이유: 쿼리를 OData V2 로 게시하려고
" ──────────────────────────────────────────────────────────
@EndUserText.label : '통관 비용 분석 서비스'
define service ZUI_ExportClearance {
  expose ZC_ExportClearanceQuery as ClearanceCube;
  expose ZI_ExportClearancePort  as CustomsPort;
}
/* 바인딩: ZUI_ExportClearance_O2 — 바인딩 유형 OData V2 - UI, 게시 후 서비스 URL 을 manifest 에 반영 */

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

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

월마감 숫자에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 도입 포인트의 사례(총차이 53,430,495원)와 같은 자료입니다.

큐브 점검 18개 항목 전부 차이 0, 에이전트 하루 한 번 제한 확인, 범위 상한 안내 확인 — 모두 검증용 샘플 데이터 기준입니다.

운영 데이터로 갈 때

신고 라인이 수천만 건으로 늘면 먼저 막히는 곳은 라인 단계입니다. 큐브 집계는 데이터베이스에서 하고(화면에 라인을 내려받지 않음), 회사코드와 청구월을 필수 파라미터로 두고, 드릴스루는 칸 조건으로 좁힌 라인만 페이지로 가져옵니다. 화면에는 행 수 500 · 열 36 상한이 있어 범위가 넓으면 안내가 먼저 뜹니다. 응답 시간 목표와 인덱스는 실제 건수로 측정해 정해야 하며, 지금 숫자는 샘플 기준이라 확인 필요입니다.

자주 묻는 질문

도입 상담과 데모에서 자주 나오는 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영