SAP 수입 결제 만기 구조 다차원 분석 — 계획 대비 결제 총액 차이를 요인으로 가르고 원천 결제 라인까지 내려가는 리포트

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

수입 대금을 결제하는 날마다 자금 담당과 구매 담당이 같은 질문을 받습니다. 계획한 만큼 나갔나, 더 나갔다면 어디서 났나, 다음 결제 전에 무엇을 확인해야 하나. 지금은 이 세 답이 표준 화면 여러 개와 엑셀, 은행 통지서로 흩어져 있고, 물대에 은행 수수료와 금융 이자, 서류·전신료가 더해지는 수입 결제는 합계 하나만 봐서는 원인이 보이지 않습니다.

이 앱은 결제 라인을 한 번 조회해 계획과 실적 큐브로 묶고, 보는 축을 바꾸고, 칸에서 원천 결제 라인까지 내려가고, 계획 대비 차이를 요인으로 나눠 보여 줍니다. 환율 영향은 IAS 21 환율변동효과(K-IFRS 제1021호) 관점으로 읽을 수 있게 결제 환율 요인을 따로 세웠습니다. 본 화면은 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(가정값)의 2026년 4월~9월 결제 라인 3,000건을 기준으로 보면, 결제 원화 총액은 계획 2,123.37억원에서 실적 2,258.72억원으로 +135.36억원(+6.4%) 늘었습니다. 요인으로 가르면 미계획 결제 +81.93억원, 외화 단가 +27.97억원, 결제 환율 +19.33억원이 크고, 결제 물량 +4.31억원, 금융 금리 +0.99억원, 금융 일수 +0.41억원, 서류·전신 단가 +0.37억원, 수수료율 +0.05억원은 작습니다. 요인의 합과 총 차이의 차이는 0원입니다.

표만 보면 "환율이 올라서 더 나갔다"로 끝나기 쉽지만, 요인으로 가르면 계획에 없던 결제가 가장 큰 몫이고 환율은 그다음임이 드러납니다. 이 수치는 가정 데이터에서 나온 것이며 실제 회사의 값이 아닙니다.

도입하면 달라지는 것

• 결제 보고 준비 — 은행별·공급사별 표를 따로 만들던 일이 한 화면의 축 바꾸기로 줄어듭니다.
• 회의의 주제 — "어느 표가 맞나"가 아니라 "미계획 결제를 어떻게 줄일까"를 이야기합니다.
• 기록 — 차이 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 점검 — 에이전트 규칙이 하루 한 번 대기함에 점검 필요 항목을 올립니다.

이런 회사에 맞습니다

수입 대금을 여러 통화(USD·EUR·JPY·CNY 등)와 여러 은행으로 결제하고, 결제 조건(송금 사후, 인수도 조건 추심, 기한부 신용장, 선급금 등)이 섞여 있어 결제 총액의 원인을 매달 엑셀로 나누는 구매·자금·회계 조직에 맞습니다. 공급사가 10곳 이상이고 결제 은행이 3곳 이상이며 월 수백 건의 결제 라인이 쌓이는 회사에서 효과가 큽니다.

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

사용 방법

1. 조회 조건 입력 — 회사코드(필수)와 시작·종료 기간(선택)을 정하고, 필요하면 차원 값 버튼에서 공급사·은행 등의 값을 여러 개 고릅니다(선택).
2. 조회 — 조회 조건 패널 오른쪽 위의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 처음 열 때는 자동으로 조회하지 않습니다(저장한 레이아웃에서 자동 조회를 켠 경우만 예외).
3. 요약 확인 — 임원 요약에서 결제 총액, 부대·금융비용률, 지연 결제율과 계획 대비 증감을 봅니다. 역할을 바꾸면 요약 기준 축이 바뀝니다.
4. 축·표 이동 — 칩을 행 축(최대 3개)과 열 축(최대 2개)으로 끌어 놓고, 표시 항목·금액 단위·비교(실적만/계획 대비)를 바꿉니다.
5. 칸·행 클릭 — 값 칸을 누르면 결제 원천 라인이, 계획 대비에서 행 이름을 누르면 그 범위의 요인 워터폴이 열립니다. 사유 버튼으로 차이 사유를 적습니다.
6. 내보내기 — 피벗 표와 원천 라인 창의 CSV 버튼, AI 분석 창의 PPTX 보고서 버튼으로 내려받습니다.

무엇으로 만들었나

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

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

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

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

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

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

구매 책임자를 고르면 표시 항목이 지연 결제율, 행 축이 공급사로 바뀝니다. 상위 목록의 숫자는 계획 대비 증감이며, 가정 데이터에는 특정 공급사의 지연 결제가 심어져 있어 점검 필요 후보가 위에 올라옵니다.

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

사용 가능 칩은 분기, 공급사, 공급국, 자재그룹, 결제 은행, 플랜트, 결제 통화, 결제 조건, 결제 채널, 만기 구간, 결제월입니다. 행 축은 최대 3개, 열 축은 최대 2개이며 넘으면 안내가 뜹니다. 끌기가 어려우면 칩의 화살표 버튼을 누릅니다.

표시 항목(결제 원화 총액 등)과 금액 단위(원·천원·백만원 등)를 바꿀 수 있습니다. 칸 수(예: 2,674)는 현재 축 조합으로 묶인 큐브 칸의 수이고, 표시 행 수와 원천 라인 읽는 단위는 표 아래에서 고릅니다.

행·열 바꾸기 버튼을 누르면 브라우저가 큐브를 다시 묶습니다. 브라우저 검사에서 이 조작 동안 네트워크 요청이 0건이었습니다. 기본 축으로 되돌리는 버튼도 옆에 있습니다.

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

칸에서 결제 원천 라인까지 — 칸의 값 = 라인 합

은행 아래 결제 조건이 단계로 나뉘어 보이며, 단계 보기를 켜면 앞 열 대비 증감이 표시됩니다.

맨 위에 "칸의 값"과 "읽은 라인의 합"이 나란히 있고 같으면 확인 표시가 붙습니다. 예를 들어 2026.05, 새롬은행, 송금 사후 결제 칸은 3,966.7백만원이고 46건의 라인 합과 같습니다. 라인은 쪽 단위로 더 읽거나 CSV로 내려받습니다.

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

표시 항목에는 측정값 8종(결제 건수, 수량, 물대, 은행 수수료, 금융 이자, 서류·전신료, 지연 결제 건수, 금융 일수 합) 외에 계산 항목 8종이 있습니다. 부대·금융비용률 = (수수료+이자+서류) ÷ 물대 × 100, 지연 결제율 = 지연 건수 ÷ 결제 건수 × 100처럼 토큰 식을 칸마다 평가하므로, 어떤 축으로 묶어도 비율이 칸 기준으로 다시 계산됩니다(합계의 평균이 아닙니다).

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

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

결제 물량 → 외화 단가 → 결제 환율 → 수수료율 → 금융 금리 → 금융 일수 → 서류·전신 단가 → 미계획 결제 순서로 한 요인씩 실적 값으로 바꿔 차이를 구합니다. 검산 줄이 "요인 합 − 총 차이 = 0원"을 매번 보여 줍니다. 행 이름을 누르면 그 범위만 다시 분해합니다.

사유는 조회 범위와 행 경로를 키로 저장됩니다. 같은 행이면 축을 바꾸거나 다시 열어도 따라오고, 행에는 사유 버튼이 표시됩니다.

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

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

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

수수료율 상한 0.117%, 공급사 지연 결제율 상한 36%, 계획 초과 3.5%, 금융 금리 요인 2천만원, 금융 일수 요인 600만원, 환율 요인 5억원이 기본값입니다(모두 가정값). 임계는 화면에서 고치고 저장합니다.

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

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

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

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

기본·자동 실행을 켜 두면 다음에 열 때 그 배치로 시작해 곧바로 조회합니다. 브라우저 검사에서 새로고침 뒤 자동 실행으로 26행이 다시 그려졌고 저장한 사유도 남아 있었습니다.

좁은 화면에서 달라지는 것

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

화면 뒤에서 일어나는 일

1. 한 번 읽기 — 조회하면 실적 큐브(CubeSet)와 계획 큐브(PlanSet)를 회사코드·기간 조건으로 한 번씩 읽습니다.
2. 브라우저 재묶음 — 축·필터·표시 항목이 바뀌면 큐브를 다시 묶어 트리표를 만듭니다. 서버 요청은 없습니다.
3. 칸 클릭 — 행 경로와 열 조합을 조건으로 원천 라인(ItemSet)을 읽고, 합계가 칸 값과 같은지 비교합니다.
4. 요인 분해·분석·에이전트 — 펑션이 서버에서 계산해 돌려줍니다.
5. 저장 — 차이 사유와 레이아웃은 ReasonSet·LayoutSet에 생성·수정·삭제로 저장합니다.

판정과 처리 로직

조회 조건

결과 컬럼

파일 구성

(앱 폴더)/
  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 · service · core · json/)
  media/ (intro.mp4 · intro_poster.jpg)

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

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

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

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 아니요. 법정·감사·세무 신고에 쓰는 보고는 표준 화면에 그대로 두고, 이 화면은 결제 만기 구조를 돌려 보는 분석과 점검에 씁니다.

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

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

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

분석 지표 정의

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

화면이 읽는 큐브·계획·원천 라인·차원은 운영에서는 CDS 뷰로 만들고, 서비스는 OData V2로 노출합니다. 아래 코드는 구조를 보여 주는 참고용이며 필드명·애노테이션은 SAP 릴리스와 회사 환경에 맞춰 확인해야 합니다(확인 필요). 표준 CDS 뷰 이름 대신 원천 테이블을 직접 읽는 형태로 적었습니다.

뷰 레이어 구성

① 결제 차원 매핑 테이블

결제 조건(송금 사후, 인수도, 기한부 신용장, 선급금), 은행, 결제 채널은 회사마다 코드가 다릅니다. 이 표 한 장이 코드를 차원 값으로 바꾸는 곳이라 가장 먼저 합의합니다.

" ─────────────────────────────────────────────
" ZIMP_APMAP
" 역할 : 코드 → 차원 값 매핑
" 이렇게 나눈 이유 : 코드 체계를 뷰가 아닌 데이터로 두어 현업이 직접 고치게 하려고
" ─────────────────────────────────────────────
@EndUserText.label : '수입 결제 차원 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_apmap {
  key client      : abap.clnt not null;
  key map_type    : abap.char(10) not null;   " BANK | TERM | CHANNEL | BUCKET
  key source_val  : abap.char(10) not null;   " 원천 코드(하우스 뱅크, 지급 조건, 지급 방법)
  target_val      : abap.char(10);            " 차원 값
  target_text     : abap.char(40);            " 차원 값 이름
}

② 결제 원천 라인 뷰

드릴스루가 읽는 라인입니다. 청산 항목에 구매오더, 송장, 결제 환율을 붙이고, 만기 구간을 만기일과 결제일의 차이로 계산합니다. 칸의 값과 라인 합이 같아야 하므로 큐브는 반드시 이 뷰에서 집계합니다.

" ─────────────────────────────────────────────
" ZI_ImpApPayItem
" 역할 : 결제 라인 한 줄
" 이렇게 나눈 이유 : 큐브와 드릴스루가 같은 라인에서 나오도록
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 라인'
@ObjectModel.usageType: { sizeCategory: #XL, serviceQuality: #C, dataClass: #TRANSACTIONAL }
define view entity ZI_ImpApPayItem
  as select from bsak as k
    inner join   ekpo as po on  po.ebeln = k.ebeln
                            and po.ebelp = k.ebelp
    left outer join zimp_apmap as mb on  mb.map_type   = 'BANK'
                                     and mb.source_val = k.hbkid
    left outer join zimp_apmap as mt on  mt.map_type   = 'TERM'
                                     and mt.source_val = k.zterm
    left outer join zimp_apmap as mc on  mc.map_type   = 'CHANNEL'
                                     and mc.source_val = k.zlsch
{
  key k.bukrs                                   as CompanyCode,
  key k.belnr                                   as PaymentDoc,
  key k.gjahr                                   as FiscalYear,
  key k.buzei                                   as PaymentItem,
      k.lifnr                                   as Supplier,
      k.ebeln                                   as PurchaseOrder,
      k.ebelp                                   as PurchaseOrderItem,
      k.augdt                                   as PayDate,            // 청산일 = 실제 결제일
      k.zfbdt                                   as BaselineDate,
      dats_add_days( k.zfbdt, cast( k.zbd1t as abap.int4 ), 'NULL' ) as PlanPayDate,
      cast( concat( substring( k.augdt, 1, 4 ), substring( k.augdt, 5, 2 ) ) as abap.char(6) ) as Period,
      coalesce( mb.target_val, 'ETC' )          as Bank,
      coalesce( mt.target_val, 'ETC' )          as PayTerm,
      coalesce( mc.target_val, 'ETC' )          as Channel,
      k.waers                                   as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      k.wrbtr                                   as DocAmount,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      k.dmbtr                                   as GoodsAmount,
      cast( 'KRW' as waers )                    as LocalCurrency,
      case when k.augdt > dats_add_days( k.zfbdt, cast( k.zbd1t as abap.int4 ), 'NULL' )
           then 1 else 0 end                    as LateFlag
}
where k.bstat <> 'S'   " 특수 총계 전표 제외

③ 계획 라인 뷰

계획은 실적과 같은 차원 키를 가져야 같은 칸에서 비교됩니다. 계획 수량·단가·환율·수수료율·금리·일수를 라인 단위로 두어 단계 대입 요인 분해가 가능하게 했습니다.

" ─────────────────────────────────────────────
" ZI_ImpApPlan
" 역할 : 계획 결제 라인
" 이렇게 나눈 이유 : 계획과 실적을 같은 키로 맞춰 칸 단위로 비교하려고
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 계획 라인'
define view entity ZI_ImpApPlan
  as select from zimp_applan as p
{
  key p.bukrs        as CompanyCode,
  key p.plan_id      as PlanId,
  key p.plan_item    as PlanItem,
      p.supplier     as Supplier,
      p.bank         as Bank,
      p.pay_term     as PayTerm,
      p.period       as Period,
      p.currency     as Currency,
      p.plan_qty     as PlanQty,
      p.plan_price   as PlanPrice,
      p.plan_rate    as PlanRate,
      p.plan_fee_pct as PlanFeePct,
      p.plan_int_rate as PlanIntRate,
      p.plan_days    as PlanDays,
      p.plan_doc_unit as PlanDocUnit
}
where p.version = 'PLAN' 

④ 차원 뷰

화면의 축 칩과 값 목록이 읽는 뷰입니다. 차원 정의는 데이터로 관리하고 값 목록은 매핑 테이블과 마스터에서 가져옵니다.

" ─────────────────────────────────────────────
" ZI_ImpApDim
" 역할 : 차원 정의·값
" 이렇게 나눈 이유 : 축 칩과 값 선택 목록의 출처
" ─────────────────────────────────────────────
@EndUserText.label: '수입 결제 차원 값'
define view entity ZI_ImpApDim
  as select distinct from zimp_apmap
{
  key map_type   as Dim,
  key target_val as Value,
      target_text as Name
}
union all
select distinct from lfa1
{
  key cast( 'SUPPLIER' as abap.char(10) ) as Dim,
  key lifnr as Value,
      name1 as Name
}

⑤ 큐브 — 차원 조합 × 측정값

화면이 한 번에 읽는 큐브입니다. 라인에서 차원 조합별로 합계를 내며 측정값은 CNT, QTY, GOODS, FEE, INT, DOC, LATE, DAYS 여덟 가지입니다. 결제 통화가 달라도 원화(로컬 통화)로 모은 값을 쓰므로 통화 환산이 칸마다 어긋나지 않습니다.

" ─────────────────────────────────────────────
" ZI_ImpApPayCube
" 역할 : 차원 조합별 집계
" 이렇게 나눈 이유 : 화면이 읽는 단위를 가볍게 하고 합계가 라인과 같도록
" ─────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 큐브'
@ObjectModel.usageType: { sizeCategory: #XL, serviceQuality: #D, dataClass: #TRANSACTIONAL }
define view entity ZI_ImpApPayCube
  as select from ZI_ImpApPayItem as i
{
  key i.CompanyCode,
  key i.Period,
  key i.Supplier,
  key i.Bank,
  key i.PayTerm,
  key i.Channel,
  key i.Currency,
      @Aggregation.default: #SUM
      count(*)                                  as LineCount,
      @Aggregation.default: #SUM
      sum( i.GoodsAmount )                      as GoodsAmount,
      @Aggregation.default: #SUM
      sum( i.LateFlag )                         as LateCount
}
group by i.CompanyCode, i.Period, i.Supplier, i.Bank, i.PayTerm, i.Channel, i.Currency

⑥ 분석 쿼리(Consumption)

조회 조건(회사코드 필수, 기간 범위)과 표시 항목을 가진 쿼리입니다. 같은 쿼리를 Analysis for Office 등에서도 쓸 수 있도록 큐브 위에 얇게 얹었습니다.

" ─────────────────────────────────────────────
" ZC_ImpApPayQuery
" 역할 : 조회 조건·표시 항목
" 이렇게 나눈 이유 : 큐브는 재사용, 쿼리는 소비자별로
" ─────────────────────────────────────────────
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 만기 구조 분석'
@UI.headerInfo: { typeName: '결제', typeNamePlural: '결제' }
define view entity ZC_ImpApPayQuery
  as select from ZI_ImpApPayCube
{
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  @AnalyticsDetails.query.axis: #FREE
  key CompanyCode,
  @Consumption.filter: { selectionType: #INTERVAL }
  @AnalyticsDetails.query.axis: #COLUMNS
  key Period,
  @AnalyticsDetails.query.axis: #ROWS
  key Bank,
  @AnalyticsDetails.query.axis: #ROWS
  key PayTerm,
  @AnalyticsDetails.query.axis: #FREE
  key Supplier,
  @AnalyticsDetails.query.axis: #FREE
  key Currency,
  GoodsAmount,
  LateCount
}

⑦ 쓰기 객체 — 차이 사유(RAP)

차이 사유와 레이아웃은 읽기 큐브가 아닌 별도 객체에 저장합니다. 키는 조회 범위와 행 경로이며, 화면은 생성·수정·삭제를 호출합니다.

" ─────────────────────────────────────────────
" ZR_ImpApReason
" 역할 : 차이 사유 저장
" 이렇게 나눈 이유 : 읽기 큐브를 건드리지 않고 사용자 입력만 저장
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 차이 사유'
define root view entity ZR_ImpApReason
  as select from zimp_apreason
{
  key scope_key   as ScopeKey,
  key row_path    as RowPath,
      cause       as Cause,
      reason_text as ReasonText,
      @Semantics.systemDateTime.lastChangedAt: true
      changed_at  as ChangedAt,
      @Semantics.user.lastChangedBy: true
      changed_by  as ChangedBy
}

managed implementation in class zbp_imp_apreason unique;
define behavior for ZR_ImpApReason alias Reason
persistent table zimp_apreason
lock master
authorization master ( instance )
{
  create; update; delete;
  field ( readonly : update ) ScopeKey, RowPath;
}

⑧ 권한(DCL)

권한은 큐브에 겁니다. 드릴스루에만 걸면 합계에서 뺄셈으로 다른 조직의 값이 드러나므로 집계 단계에서 회사코드와 구매 조직 기준으로 거릅니다.

" ─────────────────────────────────────────────
" ZI_ImpApPayCube DCL
" 역할 : 회사코드 기준 권한
" 이렇게 나눈 이유 : 집계에서 걸러야 합계가 새지 않음
" ─────────────────────────────────────────────
@EndUserText.label: '수입 결제 큐브 권한'
@MappingRole: true
define role ZI_ImpApPayCube {
  grant select on ZI_ImpApPayCube
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의와 바인딩

" ─────────────────────────────────────────────
" ZUI_ImpApPay
" 역할 : OData V2 노출
" 이렇게 나눈 이유 : 화면이 부르는 서비스의 근거
" ─────────────────────────────────────────────
@EndUserText.label: '수입 결제 만기 구조 서비스'
define service ZUI_ImpApPay {
  expose ZI_ImpApPayCube   as CubeSet;
  expose ZI_ImpApPlan      as PlanSet;
  expose ZI_ImpApPayItem   as ItemSet;
  expose ZI_ImpApDim       as DimSet;
  expose ZR_ImpApReason    as ReasonSet;
}
" 서비스 바인딩: OData V2 - UI 로 만들고 게시(활성화)합니다.

운영 시점에 해야 할 일

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

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

큐브 합계와 원천 라인 합계는 결제 건수 3,000건, 수량 1,985,962, 물대 2,242.65억원 등 8개 측정값 모두 차이 0입니다. 가정 데이터에는 점검 필요 사례(특정 공급사의 단가 상승·결제 지연, 특정 은행의 수수료·금리 가산)를 일부러 심어 두었고, 에이전트 규칙 6개 모두에서 보고가 올라옵니다. 이 수치는 가정 데이터에서 나온 값입니다.

운영 데이터로 갈 때

• 집계 위치 — 결제 라인이 수천만 건이면 큐브 집계를 화면이 아닌 CDS(필요하면 SAP HANA의 집계 테이블)에서 합니다.
• 파라미터 필수화 — 회사코드와 기간을 필수로 두어 전체를 읽지 않게 합니다.
• 원천 라인 읽는 단위 — 드릴스루는 쪽 단위(기본 500건)로 읽습니다.
• 인덱스·응답 시간 — 청산일·회사코드·공급업체 기준 접근을 확인하고 응답 시간 기준을 먼저 정합니다.
• 브라우저 상한 — 화면은 노드 1,500개, 열 36개까지만 그려 상한을 넘기면 범위를 좁히도록 안내합니다.

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

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

숫자와 산식

화면과 조작

분석 기능

도입과 운영