수입 운임·보험 단가 다차원 분석 — 같은 입항도 단가·할증·예정 밖 선적에 따라 달라지는 운송비를 한 화면에서 쪼개 보는 리포트

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

수입 담당자가 운송비 마감에서 받는 질문은 세 가지입니다. 이번 분기 운송비가 예정보다 얼마나 늘었나, 어느 선사 · 어느 항로에서 늘었나, 단가가 오른 것인지 할증이 붙은 것인지 예정에 없던 선적인지. 지금은 선적 서류 · 포워더 청구서 · 보험 증권 자료가 흩어져 있어 이 세 답을 엑셀로 이어 붙이느라 마감 때마다 시간을 씁니다. 이 앱은 세 답을 한 화면에 붙입니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 28.65억원 차이의 진짜 이유

샘플 데이터(선적 라인 3,000건, 모두 가정값)에서 운송비는 예정 155.36억원 대비 실적 184.01억원으로 28.65억원(+18.4%) 많았습니다. 총 차이만 보면 “전반적으로 비싸졌다”로 끝납니다. 일곱 요인으로 가르자 가장 큰 몫(11.73억원)은 예정에 없던 선적 180건이었고, 그다음이 단가 변동(8.21억원), 할증(3.47억원), 운임률(2.71억원), 물량(1.81억원) 순이었습니다. 일곱 요인의 합은 28.65억원으로 총 차이와 1원도 어긋나지 않았습니다. 같은 샘플에서 기본 운임 153.47억원 위에 얹힌 할증 · 터미널 · 보험 비용은 30.54억원(19.9%)이었고, 스팟 운임이 적용된 선적은 287건이었습니다.

도입하면 달라지는 것

• 마감 자료 — 운임 표 · 요인 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합이 줄어듭니다.
• 회의의 주제 — “어느 표가 맞나” 대신 “어느 선사와 어느 항로를 손볼까” 를 이야기합니다.
• 협상의 근거 — 포워더 · 선사에게 단가 · 할증률 · 부대비를 금액으로 말할 수 있습니다.
• 놓치지 않는 감시 — 아무도 화면을 열지 않은 날에도 규칙에 걸린 건이 대기함에 올라옵니다.

이런 회사에 맞습니다

해상 · 항공 수입 비중이 크고 선사 · 포워더가 여럿이며, 운임 청구서의 항목 구성이 제각각이어서 마감마다 표를 맞추는 회사에 맞습니다. 반대로 수입 건수가 적거나 운임이 단일 계약으로 고정된 회사는 표준 화면만으로도 충분할 수 있어 도입 효과는 확인 필요입니다.

실행 화면

사용 방법

1. 회사코드 · 입항월 범위를 정하고 조회를 누르거나 Enter 를 칩니다.
2. 요약에서 역할을 고르고 앞세운 지표를 확인합니다.
3. 분석 축 보드에서 차원을 끌어다 놓아 행 · 열을 바꿉니다.
4. 피벗의 칸을 눌러 그 칸을 만든 선적 라인을 봅니다.
5. 비교를 예정 대비로 바꿔 차이와 요인 워터폴을 보고 큰 행에 사유를 적습니다.
6. AI 분석 · AI 에이전트 · 보고서 PPTX · CSV 로 내보내고, 자주 쓰는 배치는 레이아웃으로 저장합니다.

무엇으로 만들었나

처음 열었을 때 — 조회조건 · 축 보드 · 피벗

빈 화면을 주지 않습니다. 차원 목록과 측정값은 조회조건과 무관해 화면을 열 때 먼저 읽으므로 축을 미리 짜 두고 조회할 수 있습니다.

표시 항목의 기본은 운송비 합계입니다. 큐브는 한 번만 읽고 이후 축 변경은 브라우저에서 처리합니다.

칩을 끌어다 놓거나 화살표 버튼으로 옮깁니다. 행 축은 최대 3단계, 열 축은 최대 2단계입니다.

넓은 표를 볼 때 쓰는 기능입니다.

경영 요약 — 자리마다 다른 화면

각 지표 아래에 예정과 차이가 함께 나옵니다. 값은 가정값입니다.

구매 조건 협상에 쓰는 관점입니다.

항로 · 운송수단별 부대비를 비교합니다.

지수는 가정값이며 회사 기준 확인 필요입니다.

축을 바꾸고 범위를 좁힌다

열은 최대 두 단계까지 쌓입니다.

선택 범위로 표와 차트가 함께 다시 계산됩니다.

합계는 큐브 합계와 같은지 검산 줄이 비교합니다.

표와 차트의 숫자가 다를 수 없습니다.

칸에서 선적 라인까지

라인에는 선사 · 항로 · 입항지 · 금액 구성이 함께 나옵니다.

샘플에서 차이는 0 이었습니다.

월 요약은 큐브와 별도로 서비스가 만들어 대사에 씁니다.

계산 항목 — 합계로는 나오지 않는 행

행마다 단가를 평균내지 않습니다.

기준 비율은 가정값이며 점검 필요입니다.

예정 대비 차이 — 같은 표가 점검 자료가 된다

실적 표와 차이 표를 따로 운영하지 않습니다.

마지막 검산 행의 차이가 0 인지 확인합니다.

어느 항로에서 어떤 요인이 컸는지 바로 찾습니다.

사유는 조회 범위와 행 경로에 묶여 저장됩니다.

AI 분석과 보고서 — 숫자는 서비스가, 문장은 규칙이

숫자는 서비스 값만 쓰고 모델 연결은 꺼져 있는 것이 기본입니다.

어느 값에서 나온 문장인지 바로 대조합니다.

브라우저에서 파일을 직접 짓습니다.

AI 에이전트 — 사람이 열지 않아도 돈다

기준값은 가정값이라 회사 기준으로 점검이 필요합니다.

누구에게 올라갔는지 한눈에 보입니다.

실행은 하루 한 번으로 서버가 제한합니다.

레이아웃 저장과 복원

자주 쓰는 보기를 한 번에 엽니다.

조건을 다시 넣을 필요가 없습니다.

좁은 화면과 한계

가로 스크롤이 페이지 전체에는 생기지 않습니다.

일부만 그린 표는 합계를 오해하게 하므로 보여 주지 않습니다.

화면 뒤에서 일어나는 일

화면이 열리면 차원 · 측정값 · 계산 항목을 읽고, 조회하면 큐브를 한 번 읽어 브라우저에서 합산합니다. 예정 대비 모드는 예정 큐브를 같은 키로 읽어 합칩니다. 차이 요인 · AI 해설 · 에이전트는 서비스의 함수를 부르고, 화면은 돌려받은 값만 그립니다.

조회조건

결과 컬럼

파일 구성

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

표준 분석 앱이 이미 있는 영역(전표 목록 · 미지급 분석)은 그대로 쓰고, 이 앱은 운임 · 부대비를 선사 · 항로 관점으로 묶어 예정과 비교하는 자리를 맡습니다.

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

분석 지표 정의

CDS 구성

뷰 레이어 구성

예정 기준 테이블 → 선적 라인 뷰 → 실적 큐브 · 예정 큐브 → 통합 큐브 → 분석 쿼리 → 권한 순서로 쌓습니다. 아래 코드는 구조를 보이는 요약본이며 필드 이름과 연산은 운영 시스템에서 점검이 필요합니다.

① 예정 기준 테이블

예정 단가 · 운임률 · 할증률 · 보험요율은 계약에서 오지만 선적 단위 예정은 표준에 없는 경우가 많아 기준 테이블로 둡니다.

@EndUserText.label : '수입 운임 예정 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
define table zfrt_plan {
  key client   : abap.clnt not null;
  key supplier : lifnr not null;
  key carrier  : abap.char(10) not null;
  key route    : abap.char(4) not null;
  plan_qty     : abap.dec(13,3);
  plan_price   : abap.dec(13,2);
  plan_rate    : abap.dec(7,4);
  plan_sur_rate: abap.dec(5,2);
  plan_term_unit: abap.dec(11,2);
  plan_ins_rate: abap.dec(5,3);
}

② 선적 라인 뷰

구매오더 항목과 입고 · 송장 · 포워더 청구를 한 행으로 묶고, 운임 네 덩어리를 계산 필드로 만듭니다.

@AccessControl.authorizationCheck : #CHECK
define view entity ZFRT_I_LINE as select from ekpo
  inner join ekko on ekko.ebeln = ekpo.ebeln
{
  key ekpo.ebeln as po_no,
  key ekpo.ebelp as po_item,
  ekko.lifnr     as supplier,
  ekpo.werks     as plant,
  ekpo.menge     as qty,
  @Semantics.amount.currencyCode : 'Currency'
  cast( ekpo.menge * ekpo.netpr as abap.curr(15,2) ) as base_amt
}

③ 실적 큐브

@Analytics.dataCategory : #CUBE
define view entity ZFRT_I_CUBE as select from ZFRT_I_LINE
{
  supplier, plant,
  @DefaultAggregation : #SUM base_amt,
  @DefaultAggregation : #SUM sur_amt,
  @DefaultAggregation : #SUM term_amt,
  @DefaultAggregation : #SUM ins_amt
}

④ 예정 큐브

@Analytics.dataCategory : #CUBE
define view entity ZFRT_I_PLANCUBE as select from zfrt_plan
{
  supplier, carrier, route,
  @DefaultAggregation : #SUM plan_qty * plan_price * plan_rate as plan_base_amt
}

⑤ 실적 + 예정 통합 큐브

두 큐브를 합집합으로 묶고 버전 열로 구분합니다. 화면의 예정 대비 모드가 이 열을 읽습니다.

define view entity ZFRT_I_CUBEALL as
  select from ZFRT_I_CUBE    { 'A' as Version, supplier, plant, base_amt }
  union all
  select from ZFRT_I_PLANCUBE{ 'P' as Version, supplier, ''    as plant, plan_base_amt as base_amt }

⑥ 분석 쿼리

@Analytics.query : true
define view entity ZFRT_Q_ANALYSIS as select from ZFRT_I_CUBEALL
{
  @AnalyticsDetails.query.axis : #ROWS    supplier,
  @AnalyticsDetails.query.axis : #COLUMNS Version,
  base_amt
}

⑦ 권한 (DCL)

@EndUserText.label : '운임 큐브 권한'
define role ZFRT_DCL {
  grant select on ZFRT_I_CUBE
    where ( plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

운영 시점에 해야 할 일

1. 선적 라인 원천(구매오더 · 입고 · 송장 · 포워더 청구)의 키 결정
2. 단가 · 할증률 · 보험요율 기준 정리
3. 환율 유형 · 운임 지수 출처 결정
4. CDS 전송과 서비스 활성화
5. manifest 의 서비스 주소 교체
6. 권한 설계와 검증

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

운영 데이터로 갈 때

샘플의 금액 · 요율 · 지수는 모두 가정값입니다. 운영 데이터로 옮길 때는 위 검증을 같은 방식으로 다시 돌려 차이가 0 인지 점검이 필요합니다.

자주 묻는 질문

도입 전에 가장 자주 나오는 질문을 주제별로 모았습니다.

숫자와 산식

화면과 조작

AI 분석과 에이전트

도입과 운영