SAP 수입 L/G(화물선취보증서) 발급 비용 다차원 분석 — 예정 대비 비용 차이를 요인으로 가르고 원천 발급 문서까지 내려가는 리포트

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

원본 선적서류가 화물보다 늦게 도착하면 수입 담당은 은행에서 화물선취보증서(L/G)를 발급받아 화물을 먼저 찾아옵니다. 건마다 드는 돈은 작아 보여도 은행 발급 수수료, 서류가 도착할 때까지 묶이는 한도 비용, 서류 특송료가 쌓이면 한 달에 얼마가 나가는지 묻는 질문이 곧 따라옵니다. 예정한 만큼 나갔나, 더 나갔다면 어느 은행·어느 공급사에서 났나, 서류가 늦어서인가 한도 금리 때문인가. 지금은 이 질문마다 은행 청구서, 선적서류 도착 일지, 구매오더 화면, 엑셀을 번갈아 열어 손으로 맞춥니다.

이 앱은 L/G 발급 라인을 한 번 조회해 예정과 실적 큐브로 묶고, 보는 축을 바꾸고, 칸에서 원천 발급 문서까지 내려가고, 예정 대비 차이를 요인으로 나눠 보여 줍니다. 서류 지연 여부와 보증 일수는 비용의 원인으로 바로 이어서 봅니다. 이 화면은 특정 회계기준서의 공시 숫자를 만드는 도구가 아니라 수입 부대비용을 점검하는 업무 분석 화면이며, 관련 기준서는 해당하지 않아 표기하지 않습니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터(가정값)의 2026년 3월~8월 L/G 발급 라인 3,000건(발급 문서 1,340건)을 기준으로 보면, L/G 비용 합계는 예정 3.45억원에서 실적 4.39억원으로 +9,424만원(+27.3%) 늘었습니다. 요인으로 가르면 계획에 없던 미계획 발급이 +5,660만원으로 가장 크고, 보증 일수가 +1,687만원, 한도 점유 금리가 +653만원, 서류·특송 단가가 +588만원, 수수료율이 +353만원, 외화 단가가 +277만원, 적용 환율이 +223만원, 보증 물량이 −17만원입니다. 여덟 요인을 모두 더하면 총 차이와 같아 검산 줄이 0원으로 나옵니다.

표만 보면 "서류가 늦게 와서 더 나갔다"로 끝나기 쉽지만, 요인으로 가르면 예정에 없던 발급이 가장 큰 몫이고 보증 일수가 그다음임이 드러납니다. 또 큐브 합계와 원천 라인 합계를 축 11개 × 측정값 8종으로 맞춰 본 88건에서 차이는 0건이었습니다. 이 수치는 가정 데이터에서 나온 것이며 실제 회사의 값이 아닙니다.

도입하면 달라지는 것

• 월말 점검 준비 — 은행별·공급사별 표를 따로 만들던 일이 한 화면의 축 바꾸기로 줄어듭니다.
• 회의의 주제 — "어느 표가 맞나"가 아니라 "예정에 없던 발급을 어떻게 줄일까"를 이야기합니다.
• 구매와 물류의 대화 — 서류 지연율과 보증 일수가 비용으로 환산되어 공급사 서류 일정 협의의 근거가 됩니다.
• 자금 쪽 점검 — 은행별 수수료율과 한도 점유 비용을 같은 표에서 비교합니다.
• 숫자의 출처 — 칸의 값이 어느 발급 문서의 합인지 바로 확인할 수 있습니다.

이런 회사에 맞습니다

수입 물량이 많아 해상 운송 구간이 길고, 원본 선적서류가 화물보다 늦게 도착하는 일이 반복되어 L/G를 자주 발급하는 제조·유통 회사에 맞습니다. 여러 통화(USD·EUR·JPY·CNY 등)와 여러 은행을 쓰고, 서류 경로(특송·은행 경유·전자 선하증권)가 섞여 있어 L/G 비용의 원인을 매달 엑셀로 나누는 구매·물류·자금 조직이 대상입니다.

실행 화면 — 처음 연 화면부터 좁은 화면까지

사용 방법

1. 조회 조건 입력 — 회사코드(필수)와 시작·종료 기간(선택)을 정하고, 필요하면 차원 값 버튼에서 공급사·발급 은행 등의 값을 여러 개 고릅니다(선택).
2. 조회 — 조회 조건 패널 오른쪽 위의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 처음 열 때는 자동으로 조회하지 않습니다.
3. 요약 확인 — 임원 요약에서 L/G 비용, 비용률, 보증 대상 물대, 서류 지연율과 예정 대비 증감을 봅니다. 역할을 바꾸면 기준 축이 달라집니다.
4. 축 이동 — 칩을 행·열로 끌어 놓거나 화살표 버튼으로 옮깁니다. 행·열 바꾸기는 서버를 다시 부르지 않습니다.
5. 칸 클릭 상세 — 값 칸을 누르면 원천 L/G 라인이 열리고 칸 값과 라인 합이 같은지 표시됩니다.
6. 내려받기 — 피벗 표와 원천 라인 창의 CSV 버튼으로 내려받습니다.

무엇으로 만들었나

처음 열었을 때 — 조건과 보드가 한눈에

처음 열면 조회 조건, 분석 축 보드, 임원 요약, 피벗 영역이 위에서 아래로 놓입니다. 조회 버튼은 조회 조건 패널 오른쪽 위에 있습니다.

회사코드는 필수이고 기본값은 가정 데이터의 1000입니다. 기간은 2026.03~2026.08이 들어 있고, 차원 값 버튼은 "전체"로 시작합니다. 조회 버튼이나 Enter 키를 누르기 전에는 서버를 부르지 않습니다.

분석 축 패널 제목에 현재 축 배치(행: 발급 은행 › 대금 조건 / 열: 발급월)가 요약됩니다. 이후 축을 바꾸는 조작은 이미 읽어 온 큐브를 브라우저에서 다시 묶으므로 기다림이 없습니다.

경영 요약 — 역할이 바뀌면 보는 곳이 바뀝니다

임원 요약은 역할(CFO, 구매 책임자, 자금 책임자, 물류 책임자)에 따라 기준 축과 표시 항목이 달라집니다.

구매 책임자를 고르면 표시 항목이 서류 지연율, 행 축이 공급사로 바뀝니다. 상위 목록의 숫자는 예정 대비 증감이며, 가정 데이터에는 특정 공급사의 원본 서류 지연이 심어져 있어 점검 대상이 위쪽에 올라옵니다.

물류 책임자는 서류 경로(특송·은행 경유·전자 선하증권)별 평균 보증 일수와 서류·특송료 비중을 봅니다. 경로마다 보증 일수가 얼마나 다른지가 한눈에 보입니다.

축 전환과 범위 — 끌어 놓으면 바로 다시 묶입니다

사용 가능 칩은 분기, 공급사, 선적국, 자재그룹, 발급 은행, 입고 플랜트, 통화, 대금 조건, 서류 경로, 보증 일수 구간, 발급월입니다. 행 축은 최대 3개, 열 축은 최대 2개이며 넘으면 안내가 나옵니다. 끌기가 어려우면 칩의 화살표 버튼을 누릅니다.

표시 항목(L/G 비용 합계 등)과 금액 단위(원·천원·백만원 등)를 바꿀 수 있습니다. 칸 수(2,608)는 현재 축 조합으로 묶인 큐브 칸의 수이고, 표시 행 수와 원천 라인 읽는 단위는 아래 선택에서 바꿉니다.

열 축에 서류 경로를 더하면 월별 열 아래에 경로가 나뉘어 보입니다. 브라우저 검사에서 이 조작 동안 네트워크 요청이 0건이었습니다. 기본 축으로 되돌리는 버튼도 옆에 있습니다.

선택한 값은 조회 조건 제목에 요약되고, 큐브와 원천 라인 모두에 같은 조건이 적용됩니다. 값을 하나도 고르지 않은 축은 전체로 봅니다.

차원 값을 좁히면 큐브도 같은 조건으로 다시 묶여 표와 차트가 함께 줄어듭니다. 합계도 선택한 은행 기준으로 바뀝니다.

칸에서 L/G 발급 라인까지 — 칸의 값 = 라인 합

맨 위에 "칸의 값"과 "읽은 라인의 합"이 나란히 있고 같으면 확인 표시가 붙습니다. 예를 들어 2026.06, 한강은행 칸은 18.9백만원이고 137건의 라인 합과 같습니다. 라인에는 발급 문서 번호, 공급사, 발급 은행, 대금 조건, 서류 경로, 보증 일수, 입고 플랜트, 서류 상태가 함께 나옵니다.

검산 패널은 측정값 8종마다 큐브 합계와 원천 라인 합계를 나란히 보여 주고 차이가 0이면 정상입니다. 아래 월별 요약에서는 발급 문서 수, 보증 대상 물대, L/G 비용, 예정 L/G 비용, 서류 지연 건수를 봅니다.

계산 항목 — 비율과 평균도 칸 단위로

표시 항목에는 측정값 8종(발급 라인 건수, 수량, 보증 대상 물대, 발급 수수료, 한도 점유 비용, 서류·특송료, 서류 지연 건수, 보증 일수 합) 외에 계산 항목 8종이 있습니다. L/G 비용률 = (수수료+한도 비용+서류) ÷ 물대 × 100, 평균 보증 일수 = 보증 일수 합 ÷ 발급 라인 건수처럼 합계가 아니라 칸마다 다시 계산됩니다.

같은 표에서 표시 항목만 바꿔 평균 보증 일수를 보면 어느 은행·대금 조건에서 보증 기간이 길어지는지 보입니다. 단계 보기를 켜면 앞 열 대비 증감이 표시됩니다.

예정 대비 차이 — 같은 표가 점검 리포트가 됩니다

비교를 "예정 대비 차이"로 바꾸면 칸마다 차이가 나타납니다. 금액 임계(기본 1,000,000원)와 비율 임계(기본 10%)를 둘 다 넘을 때만 색이 들어갑니다. 임계는 입력칸에서 바꾸고, 붉은색은 예정보다 더 나간 방향입니다.

보증 물량 → 외화 단가 → 적용 환율 → 수수료율 → 한도 점유 금리 → 보증 일수 → 서류·특송 단가 → 미계획 발급 순서로 한 요인씩 실적 값으로 바꿔 차이를 구합니다. 검산 줄이 "요인 합 − 총차이 = 0원"으로 맞는 것을 확인합니다. 행 이름을 누르면 그 행의 범위로 워터폴이 다시 그려집니다.

사유는 조회 범위와 행 경로를 키로 저장됩니다. 같은 행이면 축을 바꾸거나 다시 열어도 따라오고, 행에는 "사유 있음" 표시가 붙습니다. 브라우저 검사에서 새로고침 뒤에도 사유가 남아 있었습니다.

AI 분석과 보고서 — 숫자는 규칙이, 설명은 읽기 좋게

기본은 모델 없이 규칙 기반 해설입니다(모델 연결은 꺼짐). 발견 사항마다 근거 표가 붙고, 금액·비율은 서버가 큐브에서 계산한 값입니다. 결과는 차이 사유로 옮기거나 PPTX 보고서로 내려받을 수 있습니다.

발견 사항을 누르면 그 행의 예정·실적·차이와 요인별 금액이 근거 표로 나옵니다. 근거 숫자가 요약 문장의 숫자와 같은지 바로 대조할 수 있습니다.

AI 에이전트 — 규칙 · 대기함 · 실행 기록

발급 은행 수수료율 상한 0.135%, 공급사 원본 서류 지연율 상한 60%, L/G 비용 예정 초과 11.2%, 한도 점유 금리 요인 200만원, 보증 일수 요인 300만원, 적용 환율 요인 70만원이 기본값입니다(모두 가정값). 임계는 화면에서 바꿀 수 있습니다.

가정 데이터에서는 6개 규칙 모두에서 보고가 올라옵니다. 열어 둔 동안 한 시간마다 실행하는 타이머 스위치도 있습니다.

실행 기록은 서버(RunAgent 펑션)에 남고 한도 판정도 서버가 합니다. 화면을 닫아도 같은 호출을 배치가 대신 부를 수 있도록 판단과 기록을 화면 밖에 두었습니다.

레이아웃 저장과 복원 — 짜 둔 축으로 다시 시작

축 배치, 표시 항목, 단위, 비교, 임계, 역할이 한 묶음으로 저장됩니다.

기본·자동 실행을 켜 두면 다음에 열 때 그 배치로 시작해 곧바로 조회합니다. 브라우저 검사에서 새로고침 뒤 저장한 축 배치(열: 발급월 › 통화)가 그대로 복원되었습니다.

좁은 화면과 한계 — 열 조합 상한과 390px 폭

열 조합이 36개를 넘거나 행 노드가 1,500개를 넘으면 표를 그리지 않고 열 축을 줄이거나 차원 값을 골라 범위를 좁히라고 안내합니다. 브라우저가 멈추지 않도록 둔 한계입니다.

가로 넘침이 없고 패널이 세로로 쌓입니다. 표는 가로 스크롤을 쓰며, 차트는 숨기지 않고 표 아래로 내려갑니다.

화면 뒤에서 일어나는 일

1. 한 번 읽기 — 조회하면 실적 큐브(CubeSet)와 예정 큐브(PlanSet)를 회사코드·기간 조건으로 한 번씩 읽습니다.
2. 브라우저 재묶음 — 축·필터·표시 항목이 바뀌면 브라우저의 model/cube.js 가 큐브를 다시 묶습니다. 이때 서버 호출은 없습니다.
3. 칸 클릭 — 선택한 칸의 차원 조건으로 원천 라인(ItemSet)을 $filter로 읽어 칸 값과 라인 합을 대조합니다.
4. 요인 분해 — 서버의 DecomposeVariance 펑션이 예정 값에서 한 요인씩 실적 값으로 바꾸며 차이를 구합니다.
5. 쓰기 — 차이 사유와 레이아웃만 생성·수정·삭제를 호출합니다. 나머지는 읽기 전용입니다.

판정과 처리 로직

조회 조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 패널이 한 열로 쌓이고, 표는 가로 스크롤을 쓰며, 차트는 숨기지 않고 표 아래로 내려갑니다. 조작 버튼은 줄어든 폭에서도 가려지지 않도록 줄바꿈됩니다. 열이 많은 피벗은 휴대폰에서 읽기 어려우므로 열 축을 한 단계로 줄여 보는 것을 권합니다.

파일 구성

(앱 폴더)/
  index.html · readme.html · Component.js · manifest.json
  controller/  view/ (fragment/)  model/ (formatter · ErrorHandler · cube · chart · pptx · layout)
  css/  i18n/i18n_ko.properties
  odata/(서비스 폴더)/ (metadata.xml · service.js · core.js · json/)
  media/ (소개 영상 · 표지 · 재생 지점)

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

표준 실행은 SAP 표준 T-code가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준 화면이 이미 잘하는 일은 표준에 두고, L/G 발급 비용을 여러 축으로 돌려 보며 예정과 비교하는 자리만 이어 붙였습니다.

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

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 아니요. 법정·감사·세무 신고에 쓰는 보고는 표준 화면에 그대로 두고, 이 화면은 L/G 발급 비용을 돌려 보는 분석과 점검에 씁니다.

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

S/4HANA에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 화면은 그것들을 대체하지 않고, 같은 CDS 큐브 위에 올릴 수 있는 OpenUI5 분석 화면의 한 가지 구성을 보여 줍니다. 구체적인 Fiori 분석 앱 이름은 확인하지 못해 적지 않았습니다(확인 필요).

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

분석 지표 정의

CDS 구성 — 운영 데이터로 갈 때의 뷰 레이어와 코드

화면이 읽는 큐브·예정·원천 라인·차원은 운영에서는 CDS 뷰로 만들고, 서비스는 OData V2로 노출합니다. 아래 코드는 구조를 보여 주는 참고용이며 필드명·애노테이션은 SAP 릴리스와 회사 환경에 맞춰 확인해야 합니다(확인 필요). L/G 발급 이력은 표준 테이블에 없을 수 있어 확장 테이블을 가정해 적었습니다.

뷰 레이어 구성

① 발급 차원 매핑 테이블

발급 은행, 서류 경로(특송·은행 경유·전자 선하증권), 대금 조건은 회사마다 코드가 다릅니다. 이 표 한 장이 코드를 차원 값으로 바꾸는 곳이라 가장 먼저 합의합니다.

" ─────────────────────────────────────────────
" ZIMP_LGMAP
" 역할 : 코드 → 차원 값 매핑
" 이렇게 나눈 이유 : 코드 체계를 뷰가 아닌 데이터로 두어 현업이 직접 고치게 하려고
" ─────────────────────────────────────────────
@EndUserText.label : '수입 L/G 차원 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_lgmap {
  key client    : abap.clnt not null;
  key map_type  : abap.char(8) not null;   " BANK / CHANNEL / PAYTERM
  key src_code  : abap.char(10) not null;  " 원천 코드
  dim_value     : abap.char(10);           " 차원 값
  dim_text      : abap.char(40);           " 화면에 보일 이름
}

② L/G 발급 원천 라인

발급 문서 한 건의 라인에 구매오더·송장·환율을 붙여 큐브와 드릴스루의 공통 원천을 만듭니다. 비용은 이 단계에서 산식으로 정해 두어 큐브와 라인이 같은 값을 쓰게 합니다.

" ─────────────────────────────────────────────
" ZI_ImpLgIssueItem
" 역할 : L/G 발급 라인(원천)
" 이렇게 나눈 이유 : 큐브 합계와 드릴스루 라인이 같은 뷰에서 나오게 하려고
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 L/G 발급 라인'
define view entity ZI_ImpLgIssueItem
  as select from zimp_lgdoc as lg                          " L/G 발급 문서(확장 테이블 가정)
    inner join ekpo as po on po.ebeln = lg.ebeln and po.ebelp = lg.ebelp
    left outer join zimp_lgmap as mb on mb.map_type = 'BANK' and mb.src_code = lg.bank
{
  key lg.bukrs                       as CompanyCode,
  key lg.lg_no                       as GuaranteeNo,
  key lg.lg_item                     as GuaranteeItem,
      lg.issue_date                  as IssueDate,          " L/G 발급일
      lg.doc_arrival_date            as DocArrivalDate,     " 원본 서류 도착일
      lg.plan_doc_date               as PlanDocDate,        " 예정 서류 도착일
      po.lifnr                       as Supplier,
      mb.dim_value                   as IssuingBank,
      lg.qty                         as GuaranteedQty,
      cast( lg.qty * lg.price * lg.rate as abap.dec(17,0) )              as GuaranteedGoodsAmount,
      cast( lg.qty * lg.price * lg.rate * lg.fee_pct / 100 as abap.dec(17,0) ) as LgIssueFeeAmount,
      cast( lg.qty * lg.price * lg.rate * lg.int_rate / 100 * lg.days / 365 as abap.dec(17,0) ) as LimitHoldCostAmount,
      cast( lg.qty * lg.doc_unit as abap.dec(17,0) )                     as DocCourierAmount,
      lg.days                        as GuaranteeDays,
      case when lg.doc_arrival_date > lg.plan_doc_date then 1 else 0 end as LateDocFlag
}

③ 차원 뷰

차원 값의 목록과 이름을 한 곳에서 내려 화면의 필터 목록과 큐브의 값이 같은 출처를 쓰게 합니다.

" ─────────────────────────────────────────────
" ZI_ImpLgDim
" 역할 : 차원 값·이름 제공
" 이렇게 나눈 이유 : 화면 필터와 큐브가 같은 값 목록을 쓰도록
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '수입 L/G 차원'
@ObjectModel.dataCategory : #VALUE_HELP
define view entity ZI_ImpLgDim
  as select from zimp_lgmap
{
  key map_type  as DimType,
  key src_code  as SourceCode,
      @Semantics.text: true
      dim_text  as DimText,
      dim_value as DimValue
}

④ 예정 큐브 원천

예정 값은 실적과 같은 차원 키로 만들어 같은 칸에서 결합되게 합니다. 예정에 없던 발급은 실적 쪽에만 있는 라인으로 남고 요인 분해에서 미계획 발급으로 모입니다.

" ─────────────────────────────────────────────
" ZI_ImpLgPlan
" 역할 : 예정 발급 라인
" 이렇게 나눈 이유 : 실적과 같은 키로 결합하고 예정 부재를 미계획 발급으로 드러내려고
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 L/G 예정 라인'
define view entity ZI_ImpLgPlan
  as select from zimp_lgplan as pl
{
  key pl.bukrs     as CompanyCode,
  key pl.lg_no     as GuaranteeNo,
  key pl.lg_item   as GuaranteeItem,
      pl.plan_qty  as PlanQty,
      cast( pl.plan_qty * pl.plan_price * pl.plan_rate as abap.dec(17,0) ) as PlanGoodsAmount,
      cast( pl.plan_qty * pl.plan_price * pl.plan_rate * pl.plan_fee_pct / 100 as abap.dec(17,0) ) as PlanLgIssueFee,
      pl.plan_days as PlanDays
}

⑤ 큐브 뷰

차원 조합별로 비용 세 가지와 물대·일수를 합산합니다. 화면의 큐브(CubeSet)가 이 뷰 한 장에서 나오고, 합계는 원천 라인 합계와 같아야 합니다.

" ─────────────────────────────────────────────
" ZI_ImpLgCube
" 역할 : 차원 조합별 합산
" 이렇게 나눈 이유 : 화면이 한 번 읽어 브라우저에서 재묶음하는 단위를 만들려고
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@Analytics.dataCategory : #CUBE
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 L/G 비용 큐브'
define view entity ZI_ImpLgCube
  as select from ZI_ImpLgIssueItem
{
  key CompanyCode,
  key substring( IssueDate, 1, 6 ) as PostingPeriod,
  key Supplier,
  key IssuingBank,
  @DefaultAggregation: #SUM  count( distinct GuaranteeNo ) as GuaranteeCount,
  @DefaultAggregation: #SUM  sum( GuaranteedGoodsAmount )  as GuaranteedGoodsAmount,
  @DefaultAggregation: #SUM  sum( LgIssueFeeAmount )       as LgIssueFeeAmount,
  @DefaultAggregation: #SUM  sum( LimitHoldCostAmount )    as LimitHoldCostAmount,
  @DefaultAggregation: #SUM  sum( DocCourierAmount )       as DocCourierAmount,
  @DefaultAggregation: #SUM  sum( LateDocFlag )            as LateDocCount,
  @DefaultAggregation: #SUM  sum( GuaranteeDays )          as GuaranteeDaysSum
}
group by CompanyCode, substring( IssueDate, 1, 6 ), Supplier, IssuingBank

⑥ 쿼리 뷰

화면이 필요로 하는 필터와 표시 애노테이션은 쿼리 뷰에 둡니다. 비용률·평균 보증 일수 같은 계산 항목은 큐브가 아니라 쿼리에서 정의해 칸마다 다시 계산되게 합니다.

" ─────────────────────────────────────────────
" ZC_ImpLgCostQuery
" 역할 : 화면용 분석 쿼리
" 이렇게 나눈 이유 : 큐브를 건드리지 않고 화면 요구를 받으려고
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 L/G 비용 분석'
@Analytics.query : true
@Consumption.ranked : true
define view entity ZC_ImpLgCostQuery
  as select from ZI_ImpLgCube
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key CompanyCode,
  @Consumption.filter: { selectionType: #INTERVAL }
  key PostingPeriod,
  key Supplier,
  key IssuingBank,
  LgIssueFeeAmount,
  LimitHoldCostAmount,
  DocCourierAmount,
  ( LgIssueFeeAmount + LimitHoldCostAmount + DocCourierAmount )                       as LgCostTotal,
  ( LgIssueFeeAmount + LimitHoldCostAmount + DocCourierAmount ) * 100 / GuaranteedGoodsAmount as LgCostRatePct,
  GuaranteeDaysSum / GuaranteeCount                                                    as AvgGuaranteeDays
}

⑦ 권한 정의(DCL)

드릴스루에만 권한을 걸면 합계에서 뺄셈으로 다른 조직의 값이 드러납니다. 권한은 큐브 단계에서 겁니다.

" ─────────────────────────────────────────────
" ZR_ImpLgCube
" 역할 : 회사코드·플랜트 권한
" 이렇게 나눈 이유 : 집계 단계에서 걸어야 합계에서 우회로가 생기지 않으므로
" ─────────────────────────────────────────────
@EndUserText.label : '수입 L/G 큐브 권한'
@MappingRole : true
define role ZR_ImpLgCube {
  grant select on ZI_ImpLgCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리 뷰를 OData V2 서비스로 노출합니다. 화면은 이 서비스 주소만 바꿔 연결합니다.

" ─────────────────────────────────────────────
" ZUI_ImpLgIssue
" 역할 : OData V2 서비스 노출
" 이렇게 나눈 이유 : 화면과 서비스 주소만 연결하도록
" ─────────────────────────────────────────────
@EndUserText.label : '수입 L/G 비용 서비스'
define service ZUI_ImpLgIssue {
  expose ZC_ImpLgCostQuery as CubeSet;
  expose ZI_ImpLgIssueItem as ItemSet;
  expose ZI_ImpLgDim       as DimValueSet;
}
" 서비스 바인딩: 유형 OData V2 - UI(또는 웹 API), 게시 후 서비스 주소를 화면의 서비스 주소로 교체

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 항목은 코딩이 아니라 합의가 먼저입니다.

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

가정 데이터에서 L/G 비용은 예정 3.45억원, 실적 4.39억원으로 +9,424만원(+27.3%) 차이가 났고, 여덟 요인의 합은 총 차이와 같아 검산 줄은 0원이었습니다.

운영 데이터로 갈 때

발급 라인이 수천만 건이면 큐브 집계는 CDS에서(필요하면 SAP HANA 집계 테이블이나 사전 집계로) 하고, 회사코드와 기간을 필수 파라미터로 둡니다. 드릴스루는 칸 조건으로 쪽 단위로 읽고, 차원 값 목록은 별도 서비스로 분리해 캐시합니다. 화면의 열 36개·트리 노드 1,500개 상한은 브라우저를 보호하는 값이므로 운영 규모에 맞게 다시 정합니다. 응답 시간 기준은 운영 데이터로 측정해 정해야 합니다(확인 필요).

자주 묻는 질문 — 숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영

현업 담당자와 IT 담당자가 가장 많이 묻는 것을 네 묶음으로 정리했습니다. 이 화면은 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영