수입 리드타임 자금 묶임 비용 다차원 분석 — 입고가 늦어진 만큼 묶인 돈을 공급사·입항지·단계별로 쪼개 보는 화면

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

수입 담당자가 자주 받는 질문은 세 가지입니다. 이번 분기 리드타임이 예정보다 얼마나 길어졌나, 어느 공급사 · 어느 단계에서 늘었나, 그 지연이 돈으로는 얼마인가. 지금은 구매오더 · 입고 · 선적 서류 · 포워더 자료가 흩어져 있어, 이 세 답을 엑셀로 이어 붙이느라 마감 때마다 시간을 씁니다. 이 앱은 세 답을 한 화면에 붙입니다.

핵심 포인트 여덟 가지

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

샘플 데이터(입고 라인 3,000건)에서 자금 묶임 비용은 예정 26.00억원 대비 실적 29.61억원으로 3.61억원(+13.9%) 많았습니다. 총 차이만 보면 “전반적으로 늦었다”로 끝납니다. 여덟 요인으로 가르자 가장 큰 몫(1.64억원)은 예정에 없던 입고 258건이었고, 그다음이 조달 금리(0.60억원), 생산·출하 준비(0.53억원), 선적 대기(0.25억원), 운송(0.24억원) 순이었습니다. 요인 여덟 개의 합은 3.61억원으로 총 차이와 1원도 어긋나지 않았습니다. 같은 샘플에서 허용 일수를 넘긴 건은 1,000건(33.3%)이었습니다.

도입하면 달라지는 것

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

이런 회사에 맞습니다

해외 공급사에서 자재를 들여오고 입고까지 수 주가 걸리는 제조 · 유통 회사에 맞습니다. 결제 통화가 여러 개이고 입항지 · 운송수단이 섞여 있어 리드타임 편차가 큰 곳일수록 효과가 큽니다. 구매 · 물류 · 자금 담당이 같은 숫자를 보고 싶은 조직이 대상 사용자입니다.

실행 화면

사용 방법

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

무엇으로 만들었나

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

화면은 조회조건, 분석 축 보드, 요약, 피벗과 차트의 순서로 쌓여 있습니다. 샘플은 가상 회사 1000 의 2026년 4월~9월 입고분 3,000라인입니다.

빈 화면을 주지 않습니다. 차원 목록과 측정값은 조회조건과 무관해서 화면을 열 때 먼저 읽기 때문에, 축을 미리 짜 두고 조회할 수 있습니다. 기간은 2026년 4월~9월, 회사코드는 1000 이 기본입니다.

표시 항목의 기본은 자금 묶임 비용(가정 금리)입니다. 큐브는 한 번만 읽고, 이후 축 변경은 브라우저에서 처리합니다. 머리 영역은 접을 수 있으며 접으면 요약 한 줄이 남습니다.

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

서버를 다시 부르지 않고 브라우저의 큐브를 다시 묶습니다. 총합은 축을 바꾸기 전과 같습니다. 이 일치를 축 배치 여섯 가지로 자동 검증했습니다.

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

같은 큐브라도 보는 사람에 따라 먼저 필요한 숫자가 다릅니다. 역할 네 가지를 고르면 앞세우는 지표와 쪼개 보는 차원이 바뀝니다.

역할을 바꾸면 앞세우는 지표와 쪼개 보는 차원이 함께 바뀝니다. 다시 조회하지 않습니다.

어느 공급사가 예정보다 자주 늦는지 상위 목록으로 보여 줍니다. 허용 일수는 예정 총 일수에 3일을 더한 가정값입니다.

입항지별 단계 일수가 예정과 얼마나 다른지 봅니다. 포워더 · 관세사 협의의 근거 숫자가 됩니다.

금리 가정이 결과에 얼마나 영향을 주는지를 요인으로 분리해 보여 줍니다. 실제 조달 금리는 확인 필요입니다.

축을 바꾸고 범위를 좁힌다

열을 두 단계로 세우고, 행을 펼치고, 차원 값을 골라 범위를 좁힙니다. 서버를 다시 부르지 않습니다.

열 조합이 36개를 넘으면 더 추가하지 못하게 막고 범위를 좁히라고 안내합니다.

표와 차트 사이 손잡이로 너비를 조절하며, 값은 브라우저가 기억합니다.

같은 차원 안에서는 또는, 차원 사이는 그리고로 묶입니다. 값마다 이름 · 코드 · 라인 수가 보이고 큐브에 있는 값만 올라옵니다.

칸에서 입고 라인까지

피벗의 숫자를 의심할 때 다른 화면을 열 필요가 없습니다.

머리에 칸 값과 라인 합계, 일치 여부, 읽은 조건이 표시됩니다. 기본 500행씩 읽고 페이징합니다.

차이는 0이어야 하며 기간별 요약도 같은 숫자와 맞춰 봅니다.

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

평균 리드타임이나 초과율처럼 식으로 정의되는 단계는 계산 항목으로 둡니다.

합계로 전기되는 값이 아니라 식으로 정의된 단계입니다. 계산 항목을 고르면 표와 차트가 그 항목만 보여 주고 열로 세울 수도 있습니다.

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

비교 기준을 예정으로 바꾸면 같은 표가 차이 표가 되고, 요인 워터폴과 변동 사유가 붙습니다.

색은 금액과 비율이 모두 임계를 넘을 때만 칠합니다. 자금 묶임 비용이 예정보다 많으면 불리한 방향으로 칠합니다.

사유는 조회 범위와 행 경로를 키로 서비스에 저장되어 새로 고침 뒤에도, 다음 기간에도 따라옵니다. AI 근거와 CSV 에도 실립니다.

물대 변동 · 조달 금리 · 준비 · 선적 대기 · 운송 · 통관 · 입고·검수 · 미계획의 순서이며, 아래에 요인 합 − 총 차이 = 0 검산 줄이 나옵니다.

공급사 한 곳 · 입항지 한 곳만 골라도 요인의 합이 그 범위의 총 차이와 맞습니다.

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

AI 분석은 서비스가 계산한 값을 문장으로 옮기고 근거 표를 함께 보여 줍니다.

기본은 규칙 기반 해설이며 서비스가 계산한 값만 문장으로 옮깁니다. 이미 사유가 적힌 차이는 건너뜁니다. 점검 필요 · 확인 필요로만 적고 원인을 단정하지 않습니다.

AI 는 숫자를 만들지 않으므로 문장의 모든 금액이 이 표의 값과 일치해야 합니다.

외부 라이브러리 없이 XML 을 짜서 zip 으로 묶습니다. 내려받은 파일이 열리는 것까지 확인했습니다.

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

감시 규칙에 걸린 건을 받을 역할의 관점으로 대기함에 올립니다.

샘플 규칙은 다섯 개입니다: 공급사 허용 일수 초과율, 입항지 대기·통관 일수, 자금 묶임 비용 예정 초과, 조달 금리 영향, 장기 리드타임 건.

실행은 하루 한 번만 허용되고 판정은 서버가 합니다. 두 번째 실행은 제한 안내만 받고 새 보고를 올리지 않습니다. 걸린 것이 없어도 활동 기록은 남습니다.

레이아웃 저장과 복원

자주 쓰는 배치를 이름 붙여 저장하고, 기본으로 지정하면 열자마자 조회됩니다.

기본 레이아웃과 자동 조회를 지정할 수 있고, 이름 바꾸기와 삭제도 됩니다. 기본 + 자동 조회면 열자마자 조회된 상태로 시작합니다.

좁은 화면과 한계

작은 화면과 범위 상한에서의 동작입니다.

가로 스크롤 없이 같은 기능을 쓰도록 배치만 바뀝니다.

샘플에서는 열이 68개가 되면 앞의 36개만 보여 주고 열 축을 줄이거나 차원 값을 고르라고 안내합니다.

화면 뒤에서 일어나는 일

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 차트가 표 아래로 쌓이고 머리 영역은 접힌 채 시작합니다. 열 조합이 36을 넘으면 표를 그리지 않고 범위를 좁히라는 안내를 띄웁니다. 샘플에서 열 68개가 되는 배치로 이 안내를 확인했습니다.

파일 구성

index.html · Component.js · manifest.json
controller/   Main.controller.js · BaseController.js
view/         Main.view.xml · fragment/ (Agent · Ai · Drill · Layout · Reason)
model/        cube.js · chart.js · layout.js · formatter.js · pptx.js · ErrorHandler.js
odata/        metadata.xml · service.js · core.js · ai.json · json/*.json
media/        소개 영상 · 포스터 · 목차 트랙

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

운영으로 옮길 때 기존 표준 리포트를 없앨 필요는 없습니다. 표준 리포트는 법정 · 감사 대응에 그대로 두고, 이 화면은 지연 점검과 협상 근거를 맡습니다. 각 표준 화면의 세부 필드 대응은 회사 설정에 따르며 확인 필요입니다.

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

S/4HANA 의 표준 CDS 분석 쿼리나 Fiori 분석 앱 위에 이 화면을 올려 같은 큐브를 읽게 할 수 있습니다. Analysis for Office 같은 도구는 같은 CDS 큐브를 엑셀 쪽에서 읽는 경로입니다. 구매 · 입고 영역에 어떤 표준 분석 앱이 있는지는 설치 버전에 따라 달라 확인 필요이며, 확인하지 못한 앱 이름은 적지 않았습니다.

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

분석 지표 정의

CDS 구성

뷰 레이어 구성

① 예정 기준 테이블

예정 일수 · 예정 금리 · 예정 물대는 구매오더 조건에서 오지만 단계별 예정 일수는 표준에 없는 경우가 많아 기준 테이블로 둡니다. 이 객체에서 비교 기준이 결정됩니다.

" ───────────────────────────────────────────────
" zimp_leadplan — 수입 리드타임 예정 기준
" 단계별 예정 일수와 예정 금리를 공급사 · 자재 · 입항지 단위로 둔다.
" 나눈 이유: 예정 값이 바뀌어도 큐브 뷰를 고치지 않기 위해서.
" ───────────────────────────────────────────────
@EndUserText.label : '수입 리드타임 예정'
@AbapCatalog.tableCategory : #TRANSPARENT
define table zimp_leadplan {
  key client   : abap.clnt not null;
  key supplier : lifnr not null;
  key material : matnr not null;
  key port     : abap.char(3) not null;
  plan_prep    : abap.int2;
  plan_wait    : abap.int2;
  plan_sea     : abap.int2;
  plan_cust    : abap.int2;
  plan_recv    : abap.int2;
  plan_fin_rate: abap.dec(5,3);
}

② 입고 라인 뷰

구매오더 항목과 입고 이력을 한 줄로 묶어 라인 단위의 일자와 물대를 만듭니다. 드릴스루의 원천입니다.

" ZI_ImportLeadItem — 입고 라인 (드릴스루 원천)
" 이름·역할·이유: 발주~입고를 한 줄로 두어 단계 일수를 라인에서 계산한다.
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_ImportLeadItem
  as select from ekko as h
  inner join ekpo as i on i.ebeln = h.ebeln
  inner join ekbe as g on g.ebeln = i.ebeln and g.ebelp = i.ebelp and g.vgabe = '1'
{
  key h.ebeln as PurchaseOrder,
  key i.ebelp as PurchaseOrderItem,
  h.lifnr     as Supplier,
  i.matnr     as Material,
  i.werks     as Plant,
  h.bedat     as OrderDate,
  g.budat     as ReceiptDate,
  @Semantics.amount.currencyCode: 'Currency'
  i.netwr     as CargoAmount,
  h.waers     as Currency,
  dats_days_between( h.bedat, g.budat ) as TotalDays
}

③ 실적 큐브

입고 라인을 차원 조합별로 합계로 묶습니다. 자금 묶임 비용은 가정 금리로 라인에서 계산해 합칩니다.

" ZI_ImportLeadCube — 실적 큐브
" 차원 조합별 물대 · 일수 · 자금 묶임 비용 합계
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_ImportLeadCube
  as select from ZI_ImportLeadItem as i
{
  i.Supplier, i.Material, i.Plant,
  substring( i.ReceiptDate, 1, 6 ) as Period,
  @Aggregation.default: #SUM
  cast( i.CargoAmount as abap.curr(18,0) ) as CargoAmount,
  @Aggregation.default: #SUM
  i.TotalDays as TotalDays,
  @Aggregation.default: #SUM
  cast( i.CargoAmount * 0.05 * i.TotalDays / 365 as abap.curr(18,0) ) as CarryCost,  " 금리 5% 는 가정값 — 확인 필요
  @Aggregation.default: #SUM
  1 as ItemCount
}
group by i.Supplier, i.Material, i.Plant, substring( i.ReceiptDate, 1, 6 )

④ 예정 큐브

같은 차원 키로 예정 일수와 예정 금리를 읽어 차이 모드의 비교 값을 만듭니다.

" ZI_ImportLeadPlanCube — 예정 큐브 (실적과 같은 키 + Version)
@Analytics.dataCategory: #CUBE
define view entity ZI_ImportLeadPlanCube
  as select from zimp_leadplan
{
  key supplier as Supplier, key material as Material, key port as Port,
  'PLAN' as Version,
  @Aggregation.default: #SUM
  plan_prep + plan_wait + plan_sea + plan_cust + plan_recv as PlanDays,
  plan_fin_rate as PlanFinRate
}

⑤ 실적 + 예정 통합 큐브

두 큐브를 한 키로 이어 차이 모드를 서비스 한 번 읽기로 만듭니다.

" ZI_ImportLeadAll — 실적 + 예정 통합 (union)
define view entity ZI_ImportLeadAll
  as select from ZI_ImportLeadCube
{ Supplier, Material, Period, 'ACTUAL' as Version, CargoAmount, CarryCost, TotalDays }
union all
  select from ZI_ImportLeadPlanCube
{ Supplier, Material, '' as Period, Version, 0 as CargoAmount, 0 as CarryCost, PlanDays as TotalDays }

⑥ 분석 쿼리

화면이 읽는 얇은 층입니다. 조회 파라미터와 필터 필드를 선언합니다.

" ZC_ImportLeadQuery — 분석 쿼리
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
define view entity ZC_ImportLeadQuery
  as select from ZI_ImportLeadAll
{
  @AnalyticsDetails.query.axis: #ROWS
  Supplier,
  @AnalyticsDetails.query.axis: #COLUMNS
  Period,
  @Consumption.filter: { selectionType: #RANGE, multipleSelections: true }
  Material,
  CargoAmount, CarryCost, TotalDays
}

⑦ 권한 (DCL)

공급사가 아니라 구매조직 · 플랜트 기준으로 범위를 제한합니다. 집계 단계에서 걸어야 합계로 새지 않습니다.

" ZI_ImportLeadAuth — 분석 권한
@EndUserText.label: '수입 리드타임 권한'
define role ZI_ImportLeadAuth {
  grant select on ZI_ImportLeadCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

운영 시점에 해야 할 일

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

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

의도적 예외: 예정 없는 라인 258건(자금 묶임 비용 164,341,435원)은 미계획 요인으로 분리했으며 위 차이 건수와 별개입니다. 도입 포인트의 사례와 같은 숫자입니다.

운영 데이터로 갈 때

입고 이력이 수천만 건이면 큐브 집계는 브라우저가 아니라 CDS 쪽에서 합니다. 조회조건(회사 · 기간)을 필수로 묶어 읽는 범위를 제한하고, 큐브 행 수가 수만을 넘으면 월 단위 사전 집계 뷰를 둡니다. 화면의 열 상한 36과 드릴스루 기본 500행은 그대로 둡니다. 응답 시간 기준은 조회 3초 안쪽을 목표로 잡되 실제 값은 시스템 규모에 따라 확인 필요입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

AI 분석과 에이전트

도입과 운영