수출 컨테이너 체류·반납 지연 비용 다차원 분석 — 선사·고객·월로 돌려 보고 계획 대비 차이를 요인으로 가르는 수출 물류비 리포트

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

수출 담당과 물류 담당이 마감 때마다 받는 질문은 비슷합니다. 컨테이너 체류 비용이 계획보다 얼마나 늘었나, 어느 선사·어느 고객에서 났나, 프리타임을 넘긴 이유가 무엇이고 누가 줄일 수 있나. 지금은 선사 정산서, 선적 문서 조회 화면, 엑셀 취합표에 답이 흩어져 있어 숫자를 맞추는 데 먼저 시간이 갑니다. 이 화면은 같은 원천을 한 큐브로 묶어 축을 바꿔 보고, 칸에서 선적 문서까지 내려가며, 계획과의 차이를 요인으로 설명합니다.

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 선적·청구 문서를 그대로 이어받아 선사·고객·월 단위로 집계하므로 물류·영업·재무가 같은 숫자를 각자의 지표로 읽을 수 있습니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터에서 2026년 1~9월 총 체류 비용은 6,000백만원으로 계획 4,963백만원보다 1,037백만원(20.9퍼센트) 많았습니다. 요인분해는 그 차이를 초과 발생 비율 +1,180백만원, 일 요율 +189백만원, 미계획 선적 +247백만원이 키웠고 초과 일수 −436백만원과 계획 미이행 −142백만원, 선적 건수 −60백만원이 줄였으며 건당 컨테이너 수 +15백만원, 보관·부대·반올림 +44백만원으로 설명했습니다. 합은 총차이 1,037백만원과 오차 0.00 으로 일치했고, 큐브와 원천을 맞추는 대사식 21건도 모두 차이 0건이었습니다. 총차이의 대부분이 선적 건수가 아니라 "프리타임을 넘기는 컨테이너가 계획보다 많았다"는 데서 나온다는 점이 한 화면에서 드러납니다.

도입하면 달라지는 것

• 체류 비용 보고를 만들 때 선사 정산서·엑셀 취합과 화면 캡처가 줄어듭니다.
• 회의 주제가 "어느 숫자가 맞나"에서 "어느 선사·고객의 초과를 줄일까"로 옮겨 갑니다.
• 사유와 레이아웃이 남아 같은 설명을 매달 반복하지 않습니다.
• 물류·영업·재무가 같은 표를 각자의 지표로 읽습니다.
• 감시 규칙에 걸린 대상이 담당 역할의 대기함에 먼저 올라옵니다.

이런 회사에 맞습니다

수출 비중이 높아 컨테이너 선적이 매월 수백 건 이상이고, 선사 두세 곳 이상과 거래하며 해상 운임과 별도로 디머리지·디텐션이 청구되는 회사에 맞습니다. 정산 통화가 여러 개이고 선사별 프리타임 계약이 다르며, 물류팀과 영업팀, 재무팀이 같은 체류 비용을 다른 표로 보고 있는 조직이라면 효과가 큽니다. 수출 물량이 적어 선적이 월 수십 건 이하이면 표준 화면과 엑셀로 충분할 수 있습니다.

실행 화면

사용 방법

1. 조회 조건 입력 — 필수는 회사코드와 시작·종료 기간이고 비교 기준과 저장된 레이아웃은 선택입니다. 기본값은 회사 1000, 2026-01~2026-09, 비교 기준은 체류 비용 계획입니다.
2. 조회 — 조회 조건 줄 오른쪽 위의 조회 버튼을 누르거나 입력란에서 Enter 키를 누릅니다. 자동 조회는 하지 않으며, 저장한 기본 레이아웃에 자동 실행을 켜 둔 경우에만 열자마자 조회됩니다.
3. 요약 확인 — 역할별 요약(CEO·CFO·영업 책임자·물류 책임자)에서 총 체류 비용과 기준 대비를 먼저 봅니다.
4. 탭·축 이동 — 차원 버튼을 행·열·사용 안 함으로 옮기고, 필터 버튼으로 값을 고르며, 분석 항목과 보기 방식(차원 보기·단계 보기)을 바꿉니다.
5. 칸 클릭 상세 — 숫자 칸을 누르면 원천 선적 문서 줄이 열리고 점검 문구가 일치 여부를 알려 줍니다. 상세 창에서 기간별 요약도 열 수 있습니다.
6. 내보내기 — 위쪽 CSV 버튼으로 현재 표를 내려받고, AI 분석 창에서 PowerPoint 보고서를 받습니다.

무엇으로 만들었나

앱 정보

처음 열었을 때 — 조회 조건과 선사·제품 그룹 표

조회 조건을 정하고 조회를 누르면 선사와 제품 그룹별 표와 막대 차트가 열립니다.

회사코드, 시작·종료 기간, 비교 기준(체류 비용 계획), 저장된 레이아웃을 고른 뒤 오른쪽 위의 조회 버튼을 누릅니다. 기본값은 회사 1000, 2026-01~2026-09, 행은 제품 그룹과 선사입니다. Enter 키로도 조회됩니다.

위쪽 요약 줄은 선택한 역할(CEO·CFO·영업·물류 책임자)에 맞춘 지표입니다. 표는 트리 모양이라 전체 합계에서 선사, 제품 그룹으로 펼칩니다. 집계 1,857건은 원천 6,111줄을 큐브로 묶은 행 수입니다.

경영 요약 — 같은 표를 네 가지 눈으로

같은 조회 결과를 역할만 바꿔 다른 지표 묶음으로 읽습니다. 물류는 초과 비율과 평균 초과 일수를, 재무는 월별 비용 항목을, 영업은 고객·국가별 부담을 봅니다.

운임 대비 체류 비용률은 총 체류 비용 ÷ 해상 운임 × 100 입니다. 같은 조회 결과를 역할만 바꿔 다른 지표 묶음으로 읽습니다.

월별 행으로 바뀌어 비용 항목이 어느 달에 몰렸는지 한눈에 보입니다.

영업 관점에서는 고객과 국가별로 체류 비용이 거래 조건과 어떻게 이어지는지 확인합니다.

프리타임 초과 컨테이너 비율과 초과 컨테이너당 평균 초과 일수가 운영 지표로 올라옵니다.

축 전환과 범위 — 끌어다 놓으면 표가 다시 짜인다

차원 버튼을 행과 열로 옮기고 필터로 값을 좁히면 큐브를 브라우저에서 다시 묶어 표가 바로 바뀝니다.

버튼을 끌어 행·열 영역에 놓아도 같은 결과입니다. 이동은 브라우저 안에서 큐브를 다시 묶는 일이라 서버 호출이 없습니다.

행 차원 수와 열 조합 수가 한도를 넘지 않는지 계속 검사합니다.

열 조합이 36개를 넘으면 표를 그리지 않고 경고를 보여 줍니다.

선택한 값만 표에 남고 합계도 그 범위로 다시 계산됩니다.

필터 개수가 조회 조건 줄에 표시되어 어떤 범위의 숫자인지 잊지 않게 합니다.

넓은 표를 볼 때는 차트를 줄이고, 발표할 때는 차트를 키웁니다.

칸에서 선적 문서까지

집계 숫자가 의심될 때 가장 먼저 필요한 것은 원천입니다. 칸을 누르면 그 칸의 조건 그대로 선적 문서 줄이 열립니다.

맨 위 점검 문구가 칸 값과 원천 합계의 일치 여부를 알려 줍니다. 계산 값(비율)은 원천 줄을 다시 계산해 맞춰 봅니다.

줄마다 디머리지 = 초과 컨테이너 수 × 항만 초과 일수 × 일 요율 × 환율 이 그대로 확인됩니다.

월별 계획 행 수와 금액이 같이 나와 계획 대비 흐름을 따로 읽을 수 있습니다.

계산항목 — 합계가 아닌 값은 분자·분모로

운임 대비 체류 비용률처럼 합계로 더할 수 없는 값은 분자와 분모를 각각 더한 뒤 나눕니다.

운임 대비 체류 비용률, 선적 1건당 비용, 초과 1일당 비용 등은 합계가 아니라 분자·분모를 합친 뒤 나눈 값입니다.

합계 행에서도 분자와 분모를 각각 더한 뒤 나누므로 행 평균과 다를 수 있습니다.

계획 대비 차이 — 같은 표가 체류 비용 차이 리포트가 된다

비교 기준을 켜면 칸마다 기준 값과 차이가 붙고, 차이 분해는 그 총차이를 여덟 요인으로 쪼갭니다.

전체 총차이는 +1,037백만원(+20.9퍼센트)입니다. 차이 방향이 불리하면 붉게 표시됩니다.

저장한 사유는 행 경로와 함께 보관되고 다음에 열어도 표시됩니다. AI 해설은 사유가 있는 차이는 건너뜁니다.

요인은 선적 건수, 건당 컨테이너 수, 초과 발생 비율, 초과 일수, 일 요율, 보관·부대 비용, 미계획 선적, 계획 미이행 8가지입니다.

전체 범위에서 요인 합계 1,037백만원, 총차이 1,037백만원, 오차 0.00 으로 일치합니다.

AI 분석과 보고서 — 숫자는 서버가, 설명은 규칙이

AI 분석은 현재 보이는 범위를 읽어 요약과 핵심 발견을 적습니다. 숫자는 서버가 계산한 값만 쓰고 근거 표를 펼쳐 보입니다.

기본은 규칙 기반 해설이며 숫자는 서버가 계산한 값만 씁니다. 모델 연결은 서비스 설정으로만 켜고 기본은 꺼져 있습니다.

AI 는 숫자를 만들지 않으므로 해설 문장의 모든 숫자는 이 표에서 찾을 수 있습니다.

외부 라이브러리 없이 브라우저가 파일을 만듭니다. 서버로 데이터를 보내지 않습니다.

AI 에이전트 — 규칙이 곧 받을 역할

감시 규칙마다 임계값과 받을 역할이 붙어 있고, 걸린 대상은 역할별 대기함에 쌓입니다.

임계값은 검증용 샘플 데이터 분포에서 정했으며 운영에서는 회사 기준으로 바꿉니다.

실행 한 번에 규칙 5개가 평가되어 걸린 건이 보고로 쌓입니다.

하루 한 번 제한은 서버가 판정하며 두 번째 호출은 건너뜀으로 기록됩니다.

레이아웃 저장과 복원

자주 쓰는 축 구성에 이름을 붙여 저장하고, 기본으로 지정하면 다음에 다시 불러옵니다.

기본으로 지정하면 다음 조회에서 자동으로 불러올 수 있습니다.

같은 이름은 중복 저장되지 않습니다.

변동 사유는 저장되어 그대로 남습니다.

좁은 화면과 한계

휴대폰 폭에서는 조회 조건이 세로로 쌓이고, 표가 너무 커지면 그리지 않고 안내합니다.

표는 가로로 넘기고, 조작 버튼은 그대로 사용할 수 있습니다.

행 차원을 줄이거나 필터를 걸어 범위를 좁힙니다.

화면 뒤에서 일어나는 일

판정 조건 → 결과 상태 → 사용자 조치

산출·대사 단계

1. 디머리지·디텐션·보관·수수료를 각각 계산합니다.
2. 네 항목의 합이 총 체류 비용과 같은지 점검합니다(항등식).
3. 큐브 합계가 원천 합계와 같은지 측정값마다 대사합니다.
4. 총차이(실적 − 계획)를 여덟 요인으로 나누고 합이 같은지 확인합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

• 조회 조건과 차원 영역이 세로로 쌓이고 표는 가로로 넘깁니다.
• 표 아래로 내려간 차트도 같은 값을 그립니다.
• 행이 500개를 넘으면 표를 그리지 않고 경고합니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ view/ · controller/ · model/ · css/ · i18n/
├─ 서비스 로직 폴더 — 서비스 로직 · 계산 엔진 · 서비스 정의 · 데이터 파일
├─ media/ — 소개 영상
└─ readme.html

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

이 화면 결과에서 표준 화면으로는 칸의 선적 문서 번호를 가지고 이동해 원천을 확인하고, 표준 화면의 값은 이 화면의 같은 선사·월 칸에서 다시 봅니다. 운영 전환 때 기존 리포트와 표준 화면을 없앨 필요는 없습니다. 법정·감사·세무 신고 대응은 표준에 남기고 이 화면은 원인 분석과 월 마감 설명에 씁니다.

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

• 표준 CDS 분석 쿼리와 Fiori 분석 앱은 회사가 이미 쓰는 표준 지표를 그대로 보여 주는 자리입니다. 이 화면은 같은 원천 위에서 선사·고객·월을 자유롭게 바꿔 보고 계획과의 차이를 요인으로 설명하는 자리를 맡습니다.
• Analysis for Office 같은 도구는 큐브를 엑셀에서 다룰 때 쓰고, 이 화면은 같은 큐브를 브라우저에서 바로 열어 사유와 감시까지 이어 줍니다.
• 확인하지 못한 표준 앱 이름은 적지 않았습니다. 고객사 환경에서 쓰는 표준 분석 앱이 있다면 이 화면과 숫자를 맞춰 보는 대사 지점을 정하면 됩니다.

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

분석 지표 정의

CDS 구성 — 최대한 자세히

뷰 레이어 구성

① 요율 기준 테이블 — 프리타임·요율을 고객사 계약대로 둔다

체류 비용 산식에서 가장 자주 바뀌는 것은 코드가 아니라 선사 계약입니다. 프리타임 일수와 일 요율을 테이블로 분리하면 계약이 바뀔 때 뷰를 건드리지 않습니다.

" ───────────────────────────────────────────
" ZDEM_RATE — 선사·컨테이너 유형·항구별 프리타임과 일 요율
" 이렇게 나눈 이유: 계약 변경을 데이터로만 처리하려고
" ───────────────────────────────────────────
@EndUserText.label : '체류 요율 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
define table zdem_rate {
  key client    : abap.clnt not null;
  key carrier   : abap.char(10) not null;
  key cont_type : abap.char(3) not null;
  key port      : abap.char(5) not null;
  free_port_day : abap.int1;
  free_ret_day  : abap.int1;
  dem_rate      : abap.dec(13,2);
  det_rate      : abap.dec(13,2);
  stor_rate     : abap.dec(13,2);
  adm_fee       : abap.dec(13,2);
  currency      : abap.cuky;
}

② 차원 뷰 — 선사 텍스트와 키를 한 곳에서

차원 뷰는 키와 텍스트만 가집니다. 화면의 선사·고객·컨테이너 유형 버튼과 값 도움말이 모두 이 뷰에서 나옵니다.

" ZI_Carrier — 선사 차원
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'Carrier'
define view entity ZI_Carrier
  as select from lfa1
{
  key lifnr as Carrier,
      @Semantics.text: true
      name1 as CarrierText
}

③ 원천 뷰 — 선적 줄과 반납 이벤트, 요율을 결합

체류 비용 산식은 이 뷰에서만 계산합니다. 큐브는 이 뷰의 금액을 더하기만 하므로 산식이 두 곳에 퍼지지 않습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
define view entity ZI_ExpCntrItem
  as select from ZI_ExpShipLine  as s
  inner join zdem_rate           as r
     on  r.carrier = s.Carrier and r.cont_type = s.ContType and r.port = s.Port
{
  key s.ShipDoc, key s.Item,
  s.Period, s.Carrier, s.ContType, s.ProdGroup, s.Customer, s.Incoterms,
  s.CntrN, s.DelayN, s.PortExcessDays, s.ReturnExcessDays,
  @Semantics.amount.currencyCode: 'Currency'
  cast( s.DelayN * s.PortExcessDays   * r.dem_rate  as abap.curr(15,2) ) as DemAmt,
  cast( s.DelayN * s.ReturnExcessDays * r.det_rate  as abap.curr(15,2) ) as DetAmt,
  cast( s.DelayN * s.PortExcessDays   * r.stor_rate as abap.curr(15,2) ) as StorAmt,
  cast( case when s.DelayN > 0 then s.DelayN * r.adm_fee else 0 end as abap.curr(15,2) ) as AdmAmt,
  r.currency as Currency
}

④ 큐브 — 차원 조합별 집계

큐브는 키 차원과 합계만 가집니다. 계산항목(비율·평균)은 합계로 더할 수 없으므로 여기서 계산하지 않고 쿼리에서 분자·분모로 둡니다.

@Analytics.dataCategory: #CUBE
@ObjectModel.modelingPattern: #ANALYTICAL_CUBE
define view entity ZI_ExpDemDetCube
  as select from ZI_ExpCntrItem
{
  key Period, key Carrier, key ContType, key ProdGroup, key Customer, key Incoterms,
  @Aggregation.default: #SUM
  @Semantics.amount.currencyCode: 'Currency'
  DemAmt + DetAmt + StorAmt + AdmAmt as TotalAmt,
  @Aggregation.default: #SUM DemAmt, @Aggregation.default: #SUM DetAmt,
  @Aggregation.default: #SUM CntrN, @Aggregation.default: #SUM DelayN,
  Currency
}

⑤ 계획 큐브 — 실적과 같은 차원

계획은 실적과 같은 키 차원으로 맞춰야 기준 대비가 칸마다 붙습니다. 계획 버전이 키에 들어 있어 여러 버전을 비교할 수 있습니다.

@Analytics.dataCategory: #CUBE
define view entity ZI_ExpDemDetPlan
  as select from zdem_plan
{
  key plan_version as Version, key period as Period, key carrier as Carrier,
  key cont_type as ContType, key prod_group as ProdGroup,
  key customer as Customer, key incoterms as Incoterms,
  @Semantics.amount.currencyCode: 'Currency'
  plan_total as PlanTotalAmt, currency as Currency
}

⑥ 분석 쿼리 — 화면이 쓰는 모양

쿼리는 필터와 표시 속성을 선언합니다. 회사코드와 기간은 필수 파라미터로 두어 대용량에서 전체 읽기를 막습니다.

@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define view entity ZC_ExpDemDetQuery
  with parameters
    @Consumption.defaultValue: '1000' P_Company : bukrs,
    P_PeriodFrom : abap.char(7), P_PeriodTo : abap.char(7)
  as select from ZI_ExpDemDetCube
{
  @AnalyticsDetails.query.axis: #ROWS    Carrier,
  @AnalyticsDetails.query.axis: #ROWS    ProdGroup,
  @AnalyticsDetails.query.axis: #COLUMNS Period,
  @UI.lineItem: [{ position: 10 }]       TotalAmt,
  @Consumption.filter.selectionType: #SINGLE Customer
}
where Period between $parameters.P_PeriodFrom and $parameters.P_PeriodTo

⑦ 권한 — 집계 단계에서 건다

드릴스루에만 권한을 걸면 합계에서 뺄셈으로 다른 사업부 숫자가 드러납니다. 큐브 집계 단계에서 회사·영업 조직을 걸어 둡니다.

@EndUserText.label: '수출 체류 비용 권한'
@MappingRole: true
define role ZR_ExpDemDetAuth {
  grant select on ZI_ExpDemDetCube
    where ( Company ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의·바인딩 — 화면이 읽는 문

서비스 정의는 큐브·계획·쿼리를 한 서비스로 노출합니다. 바인딩을 OData V2 로 게시하면 화면의 서비스 주소만 바꿔 운영으로 옮길 수 있습니다.

@EndUserText.label: '수출 체류 비용 서비스'
define service ZUI_ExpDemDetSrv {
  expose ZC_ExpDemDetQuery;
  expose ZI_ExpDemDetPlan;
  expose ZI_Carrier;
  expose ZI_Customer;
}
" 바인딩: ZUI_ExpDemDetSrv_O2 — 유형 OData V2 - UI, 게시 후 서비스 활성화

운영 시점에 해야 할 일

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

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

원천 6,111줄을 큐브 1,857행으로 묶은 검증용 샘플 데이터에서 대사식 21건을 전수로 돌렸고, 의도적 예외는 0건입니다. 요인 합계는 총차이 1,037백만원과 같습니다.

운영 데이터로 갈 때

선적 문서가 수천만 건이면 집계는 큐브(서버)에서 끝내고, 회사코드와 기간을 필수 파라미터로 두어 전체 읽기를 막습니다. 큐브 키 차원에는 인덱스 대상 필드를 우선 둡니다. 화면의 행 500개·열 36개 한도는 브라우저 보호용이며 운영에서는 서버 응답 시간 기준을 따로 정합니다.

자주 묻는 질문 — 최대한 자세히

숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영 순서로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영