수출 클레임 비용 다차원 분석 — 계획 대비 차이를 여섯 요인으로 가르고 클레임 문서 라인까지 내려가는 수출 솔루션 한 화면

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

수출 담당자와 재경 담당자가 분기 회의에서 받는 질문은 비슷합니다. 클레임으로 나간 비용이 계획보다 얼마나 늘었나, 늘어난 몫이 물량인지 단가인지 환율인지 운임인지, 계획에 없던 클레임은 얼마나 되나. 지금은 이 답이 판매 오더·출하·청구·크레딧 문서 화면과 엑셀, 포워더 운임 자료에 흩어져 있어서 숫자 하나를 설명하려면 문서를 여러 번 열어 맞춰야 합니다.

이 화면은 크레딧 문서 라인을 기간·고객·국가·제품그룹·인코텀즈·클레임 사유 축으로 한 번에 돌려 보고, 클레임 충당 계획과의 차이를 여섯 요인으로 나눈 뒤 칸에서 원천 문서 라인까지 내려가 합계를 스스로 검산하는 점검 조회 도구입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

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

검증용 샘플 데이터 2026-01~2026-09 범위에서 총 클레임 비용은 125,944백만원, 클레임 충당 계획은 112,490백만원이어서 총 차이는 +13,454백만원(+12.0%)입니다. 표만 보면 "계획보다 많이 나갔다"에서 멈춥니다.

요인으로 가르면 물량 +8,192백만원이 가장 크고, 계획에 없던 클레임(미계획)이 +4,692백만원, 환율 +1,729백만원, 운임 +600백만원, 처리비 +258백만원, 단가는 −2,017백만원으로 줄여 줍니다. 여섯 요인을 모두 더하면 13,454백만원으로 총 차이와 같고, 대사 항목 13건은 모두 차이 0건입니다. 어디부터 확인할지가 한 화면에서 정해집니다.

도입하면 달라지는 것

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

이런 회사에 맞습니다

SAP S/4HANA 에서 수출 판매 오더·출하·청구·크레딧 문서 흐름을 운영하고, 클레임 비용을 엑셀로 모아 계획과 견주는 회사에 맞습니다. 통화가 여럿이고 인코텀즈 조건이 다양해 운임 부담이 건마다 다른 수출 비중이 큰 제조·유통 회사, 영업·물류·재경이 같은 숫자를 서로 다른 눈으로 보아야 하는 조직에서 효과가 큽니다.

실행 화면

사용 방법

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

무엇으로 만들었나

처음 열었을 때

조회 전의 빈 틀과 조회 직후의 표·차트를 먼저 확인합니다. 행·열 영역에 차원 칩이 놓이는 모습도 여기서 봅니다.

화면을 처음 엽니다. 조회조건과 행·열 영역의 빈 틀, 아직 조회 전이라는 안내가 보입니다. 조회를 누르기 전에는 숫자가 없는 것이 정상입니다.

조회를 누르거나 Enter 키를 누릅니다. 역할 요약 카드와 지역 › 국가 표, 비교 차트가 함께 나타납니다. 전체 합계와 계획 대비 증감을 먼저 확인합니다.

차원 칩이 놓이는 영역을 봅니다. 사용 안 함 · 행 · 열 세 영역과 차원 칩이 보입니다. 칩을 다른 영역으로 옮기면 표의 모양이 바뀝니다.

열 영역에 차원을 올립니다. 열 방향으로 값이 펼쳐지고 합계 열이 따라옵니다. 열 조합이 36개를 넘으면 안내가 나옵니다.

조회조건 머리를 접습니다. 조회 범위가 한 줄 요약으로 줄고 표 영역이 넓어집니다. 표를 크게 보며 작업할 때 사용합니다.

경영 요약 — 역할마다 같은 데이터를 다른 눈으로

CEO · CFO · 영업 책임자 · 물류 책임자 네 역할의 요약 카드와 기본 행 배치를 바꿔 봅니다.

역할을 CEO 로 바꿉니다. 국가별 클레임 비용과 계획에 없던 클레임 규모가 요약됩니다. 전사 부담이 어느 국가에 몰리는지 봅니다.

역할을 CFO 로 바꿉니다. 기간별 비용과 계획 차이가 요약됩니다. 차이가 특정 월에 몰리는지 확인합니다.

역할을 영업 책임자로 바꿉니다. 국가·고객별 물량 요인과 외화 단가 요인, 미계획 클레임이 요약됩니다. 물량과 단가 중 어느 요인이 큰지, 미계획 클레임이 큰지 점검합니다.

역할을 물류 책임자로 바꿉니다. 인코텀즈·국가별 회수·재선적 운임 차이와 운임 비중이 요약됩니다. 운임 비중이 높은 인코텀즈를 찾아 점검합니다.

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

차원을 행과 열로 옮기고, 값 도움말로 범위를 좁히고, 손잡이로 차트 너비를 조절합니다. 모두 브라우저에서 다시 집계합니다.

열에 차원을 두 개 올립니다. 열 머리가 두 단계로 묶여 표시됩니다. 차원을 늘려도 총합은 변하지 않습니다.

차원 칩의 필터 단추를 누릅니다. 값 목록과 각 값의 문서 줄 수, 검색 칸이 열립니다. 여러 값을 골라 범위를 좁힙니다.

값을 고른 뒤 표를 봅니다. 선택한 값만 남은 표와 합계가 보입니다. 필터 후 합계는 선택 값의 큐브 합과 같아야 합니다.

차트에서 막대를 보며 축을 바꿉니다. 표와 같은 범위의 막대 차트가 다시 그려집니다. 차트도 서버 호출 없이 갱신됩니다.

행 머리의 화살표로 하위 단계를 펼칩니다. 지역 › 국가 › 고객 순으로 내려갑니다. 단계마다 소계가 맞는지 확인합니다.

칸에서 원천 문서까지

금액 칸을 누르면 그 칸을 이루는 클레임 문서 라인이 열리고, 라인 합계가 칸 금액과 맞는지 바로 확인합니다.

금액 칸을 누릅니다. 그 칸을 이루는 클레임 문서 라인 목록과 위쪽 일치 안내가 열립니다. 라인 합계와 칸 금액이 일치하는지 안내 줄을 봅니다.

목록 아래의 더 보기를 누릅니다. 다음 문서 라인이 이어서 불러와집니다. 일부만 읽어도 합계 대조는 서버의 집계로 합니다.

계산항목과 기간별 요약

부대비용·클레임 비용률 같은 계산항목과 월별 요약 표를 확인합니다.

상단의 기간별 요약을 엽니다. 월별 문서 줄 수, 청구 금액, 클레임 비용, 계획, 요인이 표로 나옵니다. 특정 월에 쏠린 증감이 있는지 점검합니다.

보기 방식을 단계 보기로 바꿉니다. 청구 금액에서 클레임 비용률까지 계산 단계가 위에서 아래로 나옵니다. 단계별 값이 식과 맞는지 확인합니다.

분석 항목에 계산항목을 더합니다. 부대비용, 클레임 비용률, 단위 비용이 열로 추가됩니다. 식은 항목 이름 토큰으로 정의되어 있습니다.

기준 대비 차이 — 계획과 견주고 사유를 남긴다

클레임 충당 계획과 실적의 차이를 칸마다 보고, 차이를 요인으로 분해하고, 변동 사유를 저장합니다.

기준 대비 스위치를 켭니다. 칸마다 기준 금액과 차이가 작은 글씨로 함께 나옵니다. 금액과 비율이 둘 다 기준을 넘는 칸만 색이 바뀝니다.

차트 위의 차이 분해를 누릅니다. 기준 금액에서 실적까지 여섯 요인이 폭포 차트로 이어집니다. 요인 합계가 총 차이와 맞는지 아래 안내로 확인합니다.

표에서 행을 고르고 차트를 봅니다. 선택한 행의 요인 분해가 차트로 바뀝니다. 요인 합 = 실적 − 계획 이 성립합니다.

차이가 큰 행의 사유 단추를 누릅니다. 사유 코드와 설명을 적는 창이 열립니다. 저장하면 새로 고침 뒤에도 남습니다.

AI 분석과 보고서

현재 범위를 읽은 해설과 근거 표, 그리고 브라우저에서 만든 파워포인트 보고서를 확인합니다.

AI 분석을 엽니다. 현재 범위의 요약과 핵심 발견이 규칙 기반으로 작성됩니다. 숫자는 화면 집계 값을 그대로 씁니다.

근거 보기를 펼칩니다. 해설에 쓴 숫자의 근거 표가 보입니다. 이미 사유가 적힌 차이는 해설에서 건너뜁니다.

보고서 단추를 누릅니다. 현재 범위의 표와 차트가 담긴 파워포인트 파일이 내려받아집니다. 외부 라이브러리 없이 브라우저에서 만듭니다.

AI 에이전트 — 점검할 곳을 먼저 알려 준다

감시 규칙, 역할별 대기함, 실행 기록을 확인합니다. 실행은 하루 한 번만 허용됩니다.

AI 에이전트의 규칙 탭을 봅니다. 규칙, 지표, 기준값, 받을 역할, 사용 여부가 나옵니다. 기준값은 점검 목적에 맞게 조정합니다.

대기함 탭을 봅니다. 규칙에 걸린 항목이 역할별 보고로 쌓여 있습니다. 보고의 근거 금액을 확인하고 점검 대상을 정합니다.

실행 기록 탭을 봅니다. 실행 시각, 호출 주체, 결과, 걸린 건수가 나옵니다. 두 번째 호출은 하루 한 번 제한으로 건너뜁니다.

레이아웃 저장과 복원

자주 쓰는 배치를 이름 붙여 저장하고, 기본 레이아웃으로 지정하면 다음에 열 때 조회까지 끝낸 채 시작합니다.

레이아웃 메뉴에서 저장을 누릅니다. 이름과 기본 지정, 열 때 자동 조회 선택이 나옵니다. 자주 쓰는 배치만 저장해 둡니다.

레이아웃 관리를 엽니다. 저장된 목록과 기본 · 자동 조회 표시가 나옵니다. 이름 변경과 삭제도 여기서 합니다.

저장된 레이아웃을 불러옵니다. 축 배치와 항목이 저장했던 모양으로 돌아옵니다. 기본+자동 조회이면 열자마자 조회된 상태입니다.

좁은 화면과 한계

390px 폭의 세로 배치와, 행·열 조합 상한에 걸렸을 때의 안내를 확인합니다.

좁은 화면으로 엽니다. 조건, 표, 차트가 세로로 쌓이고 차트가 표 아래에 놓입니다. 폰 폭에서도 잘림 없이 읽혀야 합니다.

행 차원을 너무 많이 올립니다. 행이 500개를 넘으면 표를 그리지 않고 범위 안내가 나옵니다. 행 차원을 줄이거나 필터를 겁니다.

열 차원을 너무 많이 올립니다. 열 조합이 36개를 넘으면 토스트로 막습니다. 열 차원을 줄여 다시 시도합니다.

화면 뒤에서 일어나는 일

조회 한 번으로 큐브(실적)와 계획을 받아 오고, 표·차트·요약은 모두 그 큐브에서 브라우저가 다시 집계합니다. 그래서 축을 바꿔도 서비스를 다시 부르지 않고 합계가 갈라지지 않습니다.

금액·요인 계산은 서비스가 하고, 칸을 눌렀을 때만 원천 문서 라인을 쪽 단위로 읽어 옵니다. 대사 항목은 요청 시 큐브 합계와 원천 합계를 다시 견줍니다.

판정 조건과 조치

처리 단계와 대사식

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 조회조건, 표, 차트가 세로로 쌓이고 차트가 표 아래로 내려갑니다. 행이 500개를 넘거나 열 조합이 36개를 넘으면 표를 그리지 않고 줄이는 방법을 안내합니다.

파일 구성

<앱 폴더>/
  index.html · Component.js · manifest.json
  controller/  BaseController.js · Main.controller.js
  view/        Main.view.xml · fragments/(대화상자 조각)
  model/       cube.js · chart.js · pptx.js · layout.js · formatter.js · ErrorHandler.js
  css/         style.css
  i18n/        i18n_ko.properties
  odata/       OData 서비스(서비스 로직 · 메타데이터 · 데이터 파일)
  media/       소개 영상 · 포스터 · 목차 트랙
  readme.html

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

이 앱 결과에서 표준 T-code 로 원천을 확인하고, 표준 화면의 값은 이 앱의 해당 고객·제품 행에서 다시 봅니다. 운영 전환 뒤에도 기존 표준 리포트를 없애지 않습니다. 법정·감사·세무 신고에 쓰는 숫자는 표준 화면에 남기고, 이 화면은 점검 우선순위를 정하는 데 씁니다.

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

표준 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 표준 정의의 범위에서 강합니다. 이 화면은 클레임 비용을 계획과 견주고 요인으로 나누어 원천 문서까지 내려가는 한 흐름을 더합니다. 어떤 표준 앱이 같은 범위를 이미 덮는지는 고객사 환경에서 확인 필요이며, 확인하지 못한 앱 이름은 적지 않았습니다.

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

분석 지표 정의표

CDS 구성

뷰 레이어 구성

① 사유 매핑 테이블 — 클레임 사유를 요인에 연결

분류 규칙을 코드가 아니라 데이터로 둡니다. 회사마다 사유 코드가 달라도 이 표만 고치면 됩니다.

@EndUserText.label : '클레임 사유 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zexc_rsnmap {
  key mandt   : mandt not null;
  key reason  : abap.char(3) not null;   " 클레임 사유 코드
  factor      : abap.char(8);            " 연결할 요인(물량·단가·환율 …)
  text        : abap.char(40);
}

② 크레딧 문서 라인 기준 뷰 — 금액·수량·환율을 한 줄로

청구와 크레딧 문서 라인을 한 줄에 모아 두면 이후 큐브는 집계만 합니다. 클레임 사유를 읽는 필드는 고객사마다 달라 확인 필요로 남겼습니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '수출 클레임 라인 기준'
define view entity ZI_ExpClaimItem
  as select from vbrp
  inner join vbrk on vbrk.vbeln = vbrp.vbeln
{
  key vbrp.vbeln as CreditDoc,
  key vbrp.posnr as Item,
  vbrk.bukrs     as CompanyCode,
  vbrk.kunag     as Customer,
  vbrk.waerk     as Currency,
  vbrp.fkimg     as Qty,
  vbrp.netwr     as NetAmountFc,
  vbrk.kurrf     as ExchRate,
  vbrk.vbtyp     as DocCategory      " 크레딧 메모 여부 — 확인 필요
}
where vbrk.vbtyp = 'O'

③ 큐브 뷰 — 월 단위로 클레임 비용을 모은다

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

@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수출 클레임 큐브'
define view entity ZI_ExpClaimCube
  as select from ZI_ExpClaimItem
{
  key CompanyCode,
  key Customer,
  key Currency,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      NetAmountFc as ClaimFc,
      @DefaultAggregation : #SUM
      Qty
}

④ 계획 뷰 — 같은 키의 클레임 충당 계획

계획도 같은 차원으로 두면 기준 대비가 키 대응으로 끝납니다. 계획 테이블 이름과 버전 체계는 확인 필요입니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수출 클레임 계획'
define view entity ZI_ExpClaimPlan
  as select from zexc_plan
{
  key bukrs   as CompanyCode,
  key version as PlanVersion,
  key period  as Period,
  key kunnr   as Customer,
      @DefaultAggregation : #SUM
      plan_cost as PlanCost
}

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

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

@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '수출 클레임 쿼리'
define view entity ZC_ExpClaimQuery
  as select from ZI_ExpClaimCube
{
  @AnalyticsDetails.query.axis : #ROWS
  Customer,
  @AnalyticsDetails.query.axis : #COLUMNS
  ClaimFc,
  Qty
}

⑥ 권한 — 집계 단계에 건다

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

@EndUserText.label : '수출 클레임 권한'
@MappingRole : true
define role ZA_ExpClaim {
  grant select on ZC_ExpClaimQuery
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의 — 화면이 읽는 주소

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

@EndUserText.label : '수출 클레임 비용'
define service ZUI_ExpClaim {
  expose ZC_ExpClaimQuery as ClaimQuery;
  expose ZI_ExpClaimPlan  as ClaimPlan;
}

운영 시점에 해야 할 일

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

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

대사식별 검사 건수와 차이 건수입니다. 의도적 예외는 41개 키로 대사 차이와 분리해 기록했습니다.

대사 항목 13건 전부 차이 0건입니다. 의도적 예외(미계획 클레임)는 41개 키·4,692백만원이며 대사 차이와 분리해 기록합니다. 요인 합계 13,453,882,340원은 총 차이 13,453,882,340원과 같습니다.

운영 데이터로 갈 때

실데이터에서는 문서 줄이 수천만 건까지 늘 수 있습니다. 조회 때 기간과 회사코드를 필수로 받고 큐브를 서비스 쪽에서 집계해 화면이 받는 행 수를 줄입니다. 원천 문서 라인은 칸을 눌렀을 때 쪽 단위로만 읽고, 인덱스와 응답 시간 기준은 고객사 데이터량에서 확인 필요입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

분석 기능

도입과 운영