수출 납기 이행 다차원 분석 — 약정 납기월과 선적월의 매출 차이를 요인으로 나누는 한 화면

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

수출 담당자가 월말 회의에서 받는 질문은 늘 비슷합니다. 약정한 납기월과 실제로 선적한 달이 다르면 매출은 얼마나 옮겨 갔나, 왜 옮겨 갔나, 누가 무엇을 확인해야 하나. 지금은 이 답이 표준 화면 여러 개와 엑셀, 포워더·관세사 자료 대조에 흩어져 있어, 숫자 하나를 설명하려면 판매오더·납품·청구 화면을 오가며 조건을 다시 맞춰야 합니다.

이 화면은 청구 라인을 선적월·고객·제품·인코텀즈·국가 축으로 한 번에 돌려 보고, 약정 납기월 기준 매출과 선적 실적 매출의 차이를 고객 요청 조기 선적·합적 앞당김·생산·출하 지연·서류·통관 대기·선복 대기·환율 여섯 요인으로 나눕니다. 관련 기준서는 IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)이며, 이 화면은 수익 인식 시점을 점검하는 조회 도구입니다. 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 556백만원 차이는 어디서 났나

검증용 샘플 데이터 2026-01~2026-09 범위에서 선적 실적 매출은 30,212백만원, 약정 납기 기준은 29,656백만원으로 총차이는 556백만원(555,869,913원)입니다. 여섯 요인으로 가르면 생산·출하 지연 224백만원, 고객 요청 조기 선적 168백만원, 서류·통관 대기 104백만원, 선복 대기 31백만원, 합적 앞당김 30백만원, 환율 −0.7백만원이며 합은 총차이와 같습니다. 같은 달에 약정과 선적이 함께 일어난 정시 선적률은 77.45%(기준 78.9%)입니다.

표만 보면 "선적이 앞서 매출이 늘었다"에서 멈추지만, 요인으로 가르면 지연 요인(생산·출하·서류·선복 합 359백만원)이 조기 요인(198백만원)보다 크다는 점과 어느 고객·인코텀즈에서 큰지를 바로 짚을 수 있습니다. 감시 규칙은 같은 범위에서 7건을 올렸습니다. 이 값들은 샘플 데이터 값이며 원인을 단정하지 않습니다.

도입하면 달라지는 것

• 월말 점검 준비 — 차이 표·요인분해·사유·보고서가 한 화면에서 나와 엑셀 취합과 화면 캡처가 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나"보다 "어느 고객·요인부터 확인할까"를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 배치가 남아 같은 설명을 다시 하지 않습니다.
• 놓치지 않는 점검 — 화면을 열지 않아도 감시 규칙에 걸린 항목이 역할별 받은 보고로 올라옵니다.

이런 회사에 맞습니다

SAP S/4HANA에서 수출 판매오더·납품·청구 흐름을 운영하고, 약정 납기월과 선적월 차이를 엑셀로 점검하는 회사에 맞습니다. 인코텀즈가 여러 가지이고 통화가 여러 개인 수출 비중이 높은 조직, 영업·물류·재경이 같은 숫자를 서로 다른 화면으로 보고 있는 조직에서 효과가 큽니다. 수입 중심이거나 납기 개념이 없는 내수 위주 조직에는 맞지 않습니다.

실행 화면

사용 방법

1. 조회 조건 — 회사코드(필수), 시작 기간·종료 기간(필수)을 정합니다. 비교 기준은 약정 납기월 기준으로 고정되어 있습니다.
2. 조회 — 오른쪽 위 파란 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 자동 조회를 지정한 레이아웃은 화면을 열 때 바로 조회합니다.
3. 요약 확인 — 역할별 요약 탭(CEO·CFO·영업 책임자·물류 책임자)에서 선적 매출·이동분·이동 비율·정시 선적률을 봅니다.
4. 축·탭 이동 — 차원 칩을 사용 안 함·행·열로 옮기고 보기 방식(차원 보기·단계 보기), 분석 항목, 표시 행 수를 고릅니다.
5. 행·칸 클릭 — 행을 누르면 오른쪽 차트가 그 행 기준으로 바뀌고, 칸을 누르면 원천 청구 라인이 열립니다.
6. 기준 대비·분석 — 기준 대비를 켜 차이를 보고, 인공지능 분석과 에이전트, 기간별 요약, 보고서를 위쪽 버튼에서 엽니다.
7. 내보내기 — CSV 버튼으로 현재 표를 파일로 저장합니다.

무엇으로 만들었나

처음 열었을 때

조회 전에는 조건과 보드만 보입니다. 데이터를 부르지 않고 어떤 축 배치로 시작할지 먼저 정합니다.

왼쪽 위 보드에서 사용 안 함·행·열 세 칸에 차원 칩이 놓입니다. 기본 배치는 행에 지역과 국가가 올라가 있습니다. 조회 조건은 회사코드 1000, 2026-01~2026-09, 비교 기준은 약정 납기월 기준입니다. 조회를 누르기 전에는 데이터를 부르지 않습니다.

조회 결과와 역할별 요약

조회 한 번으로 표·차트·요약이 함께 채워집니다. 역할에 따라 먼저 볼 숫자가 다릅니다.

조회 버튼을 누르거나 입력 칸에서 Enter 를 누르면 표와 차트가 함께 채워집니다. 위쪽 요약은 CEO·CFO·영업 책임자·물류 책임자 역할별로 보는 지표가 다르며, 각 지표 아래에 기준 값과 기준 대비 비율이 붙습니다. 표 행을 누르면 오른쪽 차트가 그 행을 기준으로 바뀝니다.

축 전환과 범위

행과 열을 바꾸고 보고 싶은 값만 골라 범위를 좁힙니다. 합계는 어느 배치에서도 같습니다.

차원 칩을 끌어 다른 칸에 놓거나 칩을 눌러 메뉴에서 옮길 수 있습니다. 칸을 바꿔도 서비스를 다시 부르지 않고 이미 받은 큐브 데이터를 브라우저에서 다시 집계합니다. 열에 올린 차원이 있으면 첫 분석 항목만 열로 펼쳐 보이며, 이 사실은 표 위 안내 줄에 표시됩니다.

차원 이름 옆 필터 단추를 누르면 값 목록이 열립니다. 여러 값을 한 번에 고를 수 있고, 선택한 값은 표·차트·요약에 모두 같이 반영됩니다.

칸에서 원천 문서까지

숫자를 의심할 때 다른 화면을 열지 않고 그 자리에서 청구 라인으로 내려갑니다.

대화상자 위쪽에 칸 값과 원천 합계가 같은지 초록색 안내로 보여 줍니다. 아래 표에는 청구 문서, 선적일, 약정 납기일, 청구 전기일, 이동 사유, 수주번호, 고객, 국가, 제품이 줄마다 나옵니다. 줄이 많으면 더 보기로 이어서 읽습니다.

계산항목

조기 이동분·지연 이동분·이동 비율·정시 선적률처럼 서비스가 정의한 식을 항목처럼 고릅니다.

분석 항목 선택 상자에서 측정값과 계산항목을 함께 고를 수 있습니다. 계산항목은 서비스가 정의한 식(예: 이동 비율 = 이동분 ÷ 선적 매출)을 그대로 따릅니다. 단계 보기로 바꾸면 행 차원이 위에서부터 한 단계씩 펼쳐집니다.

기준 대비 차이 — 같은 표가 요인 분해가 된다

비교 기준만 켜면 같은 표가 납기 차이 리포트로 바뀌고, 행마다 요인 분해와 사유 기록이 이어집니다.

기준 대비 스위치를 켜면 선적 매출 아래에 기준 금액과 차이(금액·비율)가 한 줄로 붙습니다. 행을 누르고 차이 분해 탭을 고르면 기준 금액에서 선적 금액까지 요인별 증감이 막대로 이어집니다. 요인 합계와 총차이가 같은지 검사 문구가 함께 표시됩니다.

표의 사유 열 아이콘을 누르면 사유 구분(고객 요청·생산 지연·서류 대기 등)과 내용을 입력하는 창이 열립니다. 저장한 사유는 다음 조회에서도 그 행에 붙어 보입니다.

인공지능 분석과 보고서

숫자는 서비스가 계산하고 해설은 그 숫자를 읽어 씁니다. 결과는 보고서 파일로 내려받습니다.

분석은 규칙 기반이 기본이며 원인은 단정하지 않고 점검 필요 항목만 제시합니다. 항목마다 근거 수치(대상·선적 매출·기준·조기 이동분·지연 이동분·차이·등록된 사유)를 펼쳐 볼 수 있습니다. 같은 창의 보고서 단추로 발표용 PPTX 파일을 내려받을 수 있습니다.

인공지능 에이전트

사람이 열지 않아도 규칙에 걸린 항목을 찾아 역할별 보고로 올립니다.

에이전트 창에는 감시 규칙·받은 보고·실행 기록 세 탭이 있습니다. 역할 선택 상자로 받는 사람(CEO·CFO·영업·물류)별 보고를 걸러 볼 수 있습니다.

지금 실행을 누르면 규칙마다 기준값을 넘은 항목을 찾아 보고로 남깁니다. 하루 한 번만 실행하도록 제한해 같은 보고가 반복되지 않으며, 이미 실행한 날에는 건너뛴 사실이 실행 기록에 남습니다.

레이아웃 저장과 복원

자주 쓰는 배치를 이름을 붙여 저장하고 기본값·자동 조회를 지정합니다.

행·열 배치, 분석 항목, 보기 방식, 기준 대비 여부가 함께 저장됩니다. 기본 레이아웃으로 지정하면 화면을 열 때 바로 적용되고, 열 때 자동 조회를 켜면 조회까지 이어집니다.

레이아웃 관리 창에서 이름 변경·삭제·기본 지정을 할 수 있습니다.

좁은 화면과 한계

휴대폰 폭에서는 한 열로 쌓이고, 한도를 넘는 조합은 표를 그리지 않고 안내합니다.

표와 차트도 위아래로 나뉘어 한 열로 읽습니다.

열 조합 최대 개수와 행 최대 개수를 넘으면 표를 그리지 않고 줄일 방법을 안내합니다. 차트도 같은 범위에서는 그리지 않습니다.

화면 뒤에서 일어나는 일

조회 한 번에 서비스가 선적월·고객·제품·인코텀즈 단위 큐브와 기준 큐브를 돌려주고, 화면은 그 두 벌로 표·차트·요약을 모두 계산합니다. 칸을 누를 때만 원천 청구 라인을 쪽 단위로 읽습니다.

판정 조건과 사용자 조치

처리 단계와 대사식

1. 청구 라인 수집 — 선적일·약정 납기일·외화 금액·환율
2. 원화 환산 — 외화 금액 × 인식 환율
3. 이동 사유 분류 — 약정 납기월과 선적월 비교
4. 큐브 집계 — 선적월·고객·제품·인코텀즈
5. 기준 대비 — 총차이와 요인분해

대사식은 네 가지입니다. ① 큐브 합계 = 원천 라인 합계, ② 총차이 = 선적 실적 − 기준, ③ 요인 합계 = 총차이, ④ 칸 금액 = 드릴스루 합계.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회 조건·보드·요약·표·차트가 한 열로 쌓이고, 표와 차트는 위아래로 나뉘어 각각 가로로 밀어 볼 수 있습니다. 표시 한도는 같습니다.

파일 구성

index.html · Component.js · manifest.json
controller/   화면 동작
view/         화면 정의와 대화상자
model/        큐브 집계 · 차트 · 보고서 · 레이아웃
i18n/ · css/  문구와 스타일
media/        소개 영상
readme.html   설명서

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준을 없애지 않고 끊기는 자리만 이어 붙입니다.

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

T-code 별 연계 지점

이 앱 결과에서 표준 T-code 로 원천을 확인하고, 표준 화면의 값은 이 앱의 해당 고객·제품 행에서 다시 봅니다. 두 화면 숫자를 맞춰 보는 지점은 선적 매출 합계와 청구 문서 합계입니다. 법정 공시와 세무 신고 대응은 표준에 남겨 두므로 기존 리포트를 없앨 필요는 없습니다.

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

표준 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 표준 정의의 범위에서 강합니다. 이 화면은 납기월 이동 관점의 요인 분해와 사유 기록처럼 표준에 없는 관점을 같은 큐브 위에 더합니다. 확인하지 못한 Fiori 앱 이름은 적지 않았습니다.

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

분석 지표 정의표

CDS 구성

뷰 레이어 구성

① 이동 사유 매핑 테이블 — 사유 코드를 요인에 연결

사유가 요인으로 바뀌는 규칙을 코드가 아니라 데이터로 둡니다. 회사마다 사유 코드가 달라도 이 표만 고치면 됩니다.

@EndUserText.label : '이동 사유 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zexp_reasonmap {
  key client  : abap.clnt not null;
  key reason  : abap.char(5) not null;   " 사유 코드(고객 요청·합적·생산·서류·선복)
  factor      : abap.char(5);            " ADV · CONS · PROD · DOC · SPACE
  description : abap.char(40);
}

② 청구 라인 기준 뷰 — 선적일·약정 납기일·금액을 한 줄로

약정일·선적일·청구 금액을 한 줄에 모아 두면 이후 큐브는 월 비교만 합니다. 청구 전기일 필드는 확인 필요로 두고 청구일을 읽습니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '수출 청구 라인(기준)'
define view entity ZI_ExportBillingLine
  as select from vbrp as P
    inner join vbrk as K on K.vbeln = P.vbeln
    left outer join vbep as E on E.vbeln = P.aubel and E.posnr = P.aupos and E.etenr = '0001'
    left outer join lips as D on D.vbeln = P.vgbel and D.posnr = P.vgpos
    left outer join likp as H on H.vbeln = D.vbeln
{
  key P.vbeln as BillingDocument,
  key P.posnr as BillingItem,
  K.bukrs     as CompanyCode,
  K.kunag     as Customer,
  P.matnr     as Product,
  K.waerk     as TransactionCurrency,
  K.kurrf     as ExchangeRate,
  E.edatu     as DueDate,          " 약정 납기일(일정 라인)
  H.wadat_ist as ShipDate,         " 실제 선적일(납품)
  K.fkdat     as BillingDate,
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  P.netwr     as NetAmount
}

③ 큐브 뷰 — 월 비교로 정시·조기·지연을 가른다

합계는 모두 이 큐브에서 나옵니다. 외화 금액은 통화별로 따로 두고 원화 환산은 환율 유형을 정한 뒤 큐브 안에서 합니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수출 납기 큐브'
define view entity ZI_ExportDueCube
  as select from ZI_ExportBillingLine as L
{
  key L.CompanyCode,
  key substring( cast( L.ShipDate as abap.char(8) ), 1, 6 ) as ShipPeriod,
  key L.Customer,
  key L.Product,
  @Semantics.amount.currencyCode : 'LocalCurrency'
  sum( case when substring( cast( L.ShipDate as abap.char(8) ), 1, 6 )
                = substring( cast( L.DueDate as abap.char(8) ), 1, 6 )
            then L.NetAmount else 0 end ) as OnTimeAmount,
  @Semantics.amount.currencyCode : 'LocalCurrency'
  sum( case when L.ShipDate < L.DueDate then L.NetAmount else 0 end ) as EarlyAmount,
  @Semantics.amount.currencyCode : 'LocalCurrency'
  sum( case when L.ShipDate > L.DueDate then L.NetAmount else 0 end ) as LateAmount,
  L.TransactionCurrency as LocalCurrency
}
group by L.CompanyCode, L.Customer, L.Product, L.TransactionCurrency,
         substring( cast( L.ShipDate as abap.char(8) ), 1, 6 )

④ 분석 쿼리 — 화면이 읽는 모양

회사코드는 필수로, 기간은 구간으로 받아 대용량에서도 전체를 읽지 않게 합니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '수출 납기 이행 분석'
define view entity ZC_ExportDueQuery
  as select from ZI_ExportDueCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key CompanyCode,
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #INTERVAL }
  key ShipPeriod,
  @AnalyticsDetails.query.axis : #ROWS
  key Customer,
  @AnalyticsDetails.query.axis : #COLUMNS
  OnTimeAmount,
  @AnalyticsDetails.query.axis : #COLUMNS
  EarlyAmount,
  @AnalyticsDetails.query.axis : #COLUMNS
  LateAmount
}

⑤ 권한 — 집계 단계에 건다

집계 뒤에만 권한을 걸면 전체 합계와 자기 몫의 차이로 남의 숫자가 드러납니다.

@EndUserText.label : '수출 납기 권한'
@MappingRole : true
define role ZC_ExportDueQuery {
  grant select on ZC_ExportDueQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_VBRK_BUK, BUKRS, ACTVT = '03' );
}

⑥ 요인 분해용 사유 뷰 — 사유를 요인으로 묶는다

사유 코드를 읽는 필드는 고객사마다 다르므로 확인 필요로 남겼습니다. 읽는 위치만 바꾸면 요인 분해가 동작합니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
define view entity ZI_ExportShiftReason
  as select from ZI_ExportBillingLine as L
    left outer join zexp_reasonmap as M on M.reason = P.zzreason
{
  key L.BillingDocument,
  key L.BillingItem,
  M.factor as Factor     " 사유 코드 위치는 확인 필요 — 고객사 필드에 맞춰 교체
}

⑦ 서비스 정의

화면이 읽는 엔티티셋을 한 곳에서 게시합니다. 게시 뒤 화면의 서비스 주소만 교체합니다.

@EndUserText.label : '수출 납기 이행'
define service ZUI_ExportDue {
  expose ZC_ExportDueQuery;
  expose ZI_ExportDueCube;
  expose ZI_ExportBillingLine;
}

운영 시점에 해야 할 일

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

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

대사식별 검사 건수와 차이 건수입니다. 의도적 예외는 0건입니다.

검증용 샘플 데이터 기준으로 원천 청구 라인 3,104줄이 큐브 863행이 되었고, 요인 합계 555,869,913원은 총차이 555,869,913원과 같습니다.

운영 데이터로 갈 때

청구 라인이 수천만 건이면 집계는 큐브 뷰에서 하고 조회 때 회사코드와 기간을 필수로 받습니다. 원천 라인은 쪽 단위로만 읽고, 열 조합과 행 수 한도는 화면에서 유지합니다. 응답 시간 기준은 고객사 데이터 규모를 본 뒤 정하며 현재는 확인 필요입니다.

자주 묻는 질문

숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영 네 묶음으로 24문항을 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영