SAP 기대신용손실 설정률 사후검증 — 적용한 연체 구간별 설정률이 이후 12개월 실제 손실과 맞았는지 한 화면에서 점검

개발 배경 — 이 앱을 사용해야 하는 이유

매 결산마다 같은 질문이 돌아옵니다. "작년 말에 우리가 쓴 설정률이 이후 1년 동안 실제로 일어난 손실을 감당했는가." IFRS 9(K-IFRS 제1109호)의 기대신용손실은 과거 사건·현재 상황·미래 전망에 관한 합리적이고 뒷받침될 수 있는 정보를 반영해 측정하도록 요구하고, 많은 회사가 매출채권에는 연체 구간별 설정률표를 씁니다. 표를 만드는 일은 공을 들이는데, 표를 쓴 뒤에 실제 손실과 맞대어 보는 일은 엑셀 한 장에 맡겨지는 경우가 많습니다.

그 엑셀은 보통 이렇게 만들어집니다. 고객 미결 항목(FBL5N)을 기준일로 받아 연체일수를 계산하고, 1년 뒤 제각·회수 전표를 FAGLL03 에서 따로 받아 붙이고, 구간별 충당금은 FS10N 의 계정 잔액과 맞춥니다. 세 번의 내려받기와 두 번의 VLOOKUP 이 지나야 겨우 첫 질문의 숫자가 나오고, 그 사이 누가 어떤 조건으로 받았는지는 파일 이름에만 남습니다. 이 앱은 그 자리를 메웁니다. 기준월을 고르면 채권 명세와 이후 12개월 결과가 한 번에 모이고, 설정률과 실현손실률이 구간·고객군별로 나란히 놓입니다. 판단은 점검 필요 · 확인 필요로만 표시하고, 설정률을 바꿀지는 회사와 감사인이 정합니다.

합계가 맞아도 구간이 맞는다는 뜻은 아니다

이 샘플의 기준월 합계를 보면 채권 64건, 기준일 잔액 14,595,477,000원에 장부 충당금은 1,738,552,524원(11.91%)이고 이후 12개월 실현 순손실은 1,712,376,000원(11.73%)입니다. 합계만 보면 0.18%p 차이라 잘 맞은 해로 읽힙니다. 그런데 구간으로 나누면 이야기가 달라집니다. 31~60일 구간은 적용 설정률 4.0% 에 실현손실률 8.2% 로 허용 상한 5.2% 를 넘고(충당금이 약 1.19억원 모자랐던 규모), 91~180일 구간은 설정률 25% 에 실현 13.0% 로 허용 하한 17.5% 아래입니다. 한 구간의 모자람과 다른 구간의 남음이 합계에서 서로 지워진 것입니다. 사후검증은 이 상쇄를 풀어 보는 일입니다.

"허용 범위"가 없으면 모든 차이가 이야기거리가 된다

설정률과 실현손실률이 똑같이 나오는 일은 없습니다. 어느 정도 어긋나야 점검 대상인지 기준이 없으면 모든 구간이 매번 논쟁거리가 되고, 반대로 기준이 없으면 눈에 띄는 구간만 훑고 끝납니다. 이 앱은 점검용 가정으로 적용 설정률 ± max(적용 설정률의 30%, 0.25%p) 를 허용 범위로 둡니다. 설정률이 0.5% 같은 낮은 구간에서 30% 만 쓰면 범위가 0.35%~0.65% 로 지나치게 좁아지므로 하한 폭 0.25%p 를 함께 둔 것입니다. 이 값은 회사의 정책이 아니라 점검의 출발점이며, 회사가 정하는 값으로 바꾸는 자리는 매핑 테이블에 둡니다.

판정을 사람이 읽을 수 있는 이유로 남겨야 한다

점검 필요라고만 뜨는 화면은 금방 외면받습니다. 이 앱은 채권 한 건마다 네 가지 점검 코드 중 하나를 붙이고(제각액이 장부 충당금을 넘음 · 미연체 구간 채권이 제각됨 · 재계산과 장부 충당금이 다름 · 장기 연체가 관측 종료까지 미회수), 해당하지 않으면 정상으로 둡니다. 구간과 고객군 화면은 같은 규칙으로 허용 범위 안팎을 가릅니다. 기준월 합계에서 점검 필요 채권은 17건, 점검 필요 구간은 3개입니다.

사용 방법

1. 설정 기준 연월을 고릅니다. 기본값은 가장 최근 기준월입니다. 연체 구간 · 고객군 · 점검 코드 · 제각일 범위로 좁힐 수도 있습니다.
2. 조회 단추를 누르거나 Enter 를 칩니다. 숫자 카드와 채권 명세가 같은 조건으로 바뀝니다.
3. 숫자 카드를 확인합니다. 채권 건수 · 기준일 잔액 · 장부 충당금 · 실현 순손실 · 점검 필요 채권 · 점검 필요 구간 · 정합성 대사 차이 일곱 가지입니다.
4. 탭을 옮겨 가며 봅니다. 채권 명세 → 구간별 사후검증 → 고객군별 사후검증 → 대사 결과 순으로 읽으면 총량에서 쏠림으로, 쏠림에서 숫자의 신뢰로 이어집니다.
5. 채권 행을 누릅니다. 기준일 잔액과 충당금, 이후 회수·제각·제각 후 회수 이력이 상세 창에 열립니다.
6. CSV 로 내려받습니다. 지금 열린 탭이 지금 조건 그대로 내려가며, 결재 자료나 감사 대응 파일에 붙입니다.

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

샘플 데이터(채권 64건 · 이력 포함, 두 개 기준월)로 대사식을 전수 돌렸습니다. 정합성 대사 7종은 검사한 모든 건에서 차이가 0이고, 장부 충당금 재계산은 의도적으로 넣은 예외 2건 때문에 차이가 2건 남도록 해 점검이 실제로 잡아내는지 확인했습니다. 화면의 숫자 카드는 이 검증 스크립트의 결과와 같습니다.

무엇으로 만들었나

실행 화면

처음 열었을 때와 조건 좁히기

첫 화면은 질문 하나에 답하도록 짰습니다. "이 기준월 채권의 충당금이 이후 12개월 실제 손실을 감당했는가." 숫자 카드가 총량을 먼저 보여 주고, 조건을 좁히면 같은 카드와 표가 함께 바뀝니다.

기준월 채권 64건의 기준일 잔액·장부 충당금·실현 순손실과 점검 필요 건수가 한 줄에 모입니다. 조회 버튼은 조건 입력란 오른쪽 끝에 있고 Enter 키로도 조회됩니다. 기본값은 가장 최근 기준월이며, 숫자 카드를 보고 그 아래 채권 명세 표로 내려가는 순서로 읽습니다.

구간과 점검 코드를 고르고 조회하면 숫자 카드와 표가 같은 조건으로 함께 바뀝니다. 이 화면에서는 제각액이 기준일 장부 충당금을 넘은 채권만 남습니다. 조건을 비우고 다시 조회하면 전체로 돌아갑니다.

구간별 · 고객군별 — 합계 뒤에 숨은 쏠림

전체 합계는 맞아 보여도 구간이나 고객군으로 나누면 한쪽은 모자라고 한쪽은 남는 일이 흔합니다. 두 화면은 같은 판정 규칙으로 구간과 고객군을 각각 비교합니다.

구간마다 적용 설정률, 허용 하한·상한, 이후 12개월 실현손실률, 편차, 충당금 과부족이 한 줄입니다. 실현손실률이 허용 상한을 넘으면 과소 설정 후보, 하한 아래면 과대 설정 후보로 점검 필요 표시합니다. 이 샘플에서는 31~60일 구간만 과소, 1~30일·91~180일 구간이 과대 후보입니다.

구간 표 하나로 모든 고객군을 묶어도 되는지 확인하는 화면입니다. 건수가 적은 고객군은 우연의 영향이 커서 판정을 그대로 믿기보다 건수와 함께 읽어야 합니다. 이 샘플의 특수관계자는 3건뿐이라 실현손실률 0% 를 곧바로 과대 설정으로 단정하지 않고 확인 필요로 읽습니다.

한 건으로 내려가고, 숫자를 서로 맞춰 본다

점검 필요로 뜬 채권은 이력으로 사정을 확인하고, 화면 전체의 숫자는 대사 결과로 서로 맞는지 확인합니다.

채권 명세 행을 누르면 기준일 잔액과 장부 충당금, 재계산 결과, 그리고 이후 회수·제각·제각 후 회수 이력이 한 창에 열립니다. 충당금이 모자랐던 채권이 어떤 사정으로 제각에 이르렀는지 이력으로 따라갑니다. 닫기 단추나 바깥 영역, Esc 키로 닫습니다.

정합성 대사 7건과 장부 점검 대사 1건의 좌변·우변·검사 건수·차이 건수·최대 차이를 보여 줍니다. 정합성 대사는 모두 차이 0건이어야 하고, 장부 충당금 재계산 차이는 의도적으로 넣은 점검 대상이라 따로 분리해 둡니다.

화면 뒤에서 일어나는 일

화면에서 조회를 누르면 서비스가 여섯 단계를 순서대로 밟습니다. 중간 결과가 다음 단계의 입력이 되는 구조라 어느 단계에서 어긋났는지 대사식으로 바로 찾을 수 있습니다.

1. 기준일 채권 모으기 — 기준월 말일에 열려 있던 고객 항목만 채권으로 잡고, 기준일에서 순수 만기일을 뺀 값을 연체일수로 둡니다.
2. 연체 구간 배정 — 미연체 · 1~30일 · 31~60일 · 61~90일 · 91~180일 · 181일 초과 여섯 구간 중 하나로 가르고 구간별 적용 설정률을 붙입니다.
3. 장부 충당금 연결 — 기준일 충당금 계정 잔액을 채권별로 배부한 값을 장부 충당금으로 둡니다. 배부 규칙은 회사 정책이라 확인이 필요합니다.
4. 이후 12개월 결과 붙이기 — 기준일 다음 날부터 12개월 안의 회수, 제각, 제각 후 회수를 채권별로 모읍니다.
5. 구간·고객군 집계 — 채권 명세를 구간과 고객군으로 합산하고 실현손실률 · 편차 · 허용 범위 · 충당금 과부족을 계산합니다.
6. 대사 — 위 다섯 단계의 합계가 서로 맞는지 여덟 개 식으로 확인해 결과 탭에 남깁니다.

판정 규칙 — 조건 → 결과 → 사용자 조치

한 채권이 여러 조건에 걸리면 위 표의 위쪽 코드부터 붙입니다. 구간·고객군 화면의 판정은 다음과 같습니다.

산출식

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

채권 명세는 컬럼이 열여덟 개라 좁은 화면에서는 오른쪽으로 스크롤됩니다. 숫자 카드는 한 줄에서 두 줄 이상으로 줄바꿈되고, 구간·고객군·대사 탭은 컬럼 수가 적어 휴대폰에서도 한 화면에 가깝게 보입니다. 상세 창은 화면 폭에 맞춰 줄어듭니다.

파일 구성

index.html · manifest.json · Component.js
controller/   BaseController · Main.controller
view/         Main.view.xml · DetailDialog.fragment.xml
model/        formatter · ErrorHandler
i18n/         i18n_ko.properties
css/          style.css
odata/        서비스 정의 · 서비스 로직 · 샘플 데이터(JSON)
media/        소개 영상 · 포스터
readme.html   앱 설명서

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 아래 표는 어디까지가 표준으로 충분하고 어디서부터 이 앱이 이어 붙는지 나란히 놓은 것입니다.

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

T-code 별 연계 지점

아래 표의 순서대로 쓰면 이 앱의 숫자를 표준 화면에서 거꾸로 확인하는 길이 됩니다. 이 앱은 표준 데이터를 그대로 읽는 조회·검증 화면이라 기존 표준 리포트나 법정·감사 대응용 출력을 없애지 않고 함께 둡니다.

기존 엑셀 점검표를 없애야 하는가에 대한 답은 "없앨 필요는 없지만 이 앱이 안정되면 그 표가 하던 일은 이 앱이 합니다" 입니다. 운영 전환 첫 두 분기는 엑셀 값과 이 앱의 구간별 실현손실률을 나란히 놓고 차이를 확인하는 병행 기간으로 두는 편이 안전합니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 가 있습니다. 이 앱은 그것들과 경쟁하지 않고 다음 한 가지를 맡습니다. 설정률표라는 회사 정책과 이후 12개월 실제 결과를 한 줄에 놓는 일입니다. 연령분석 자체는 표준 분석 앱으로도 볼 수 있지만 설정률과 허용 범위는 회사 정의라 표준 쿼리에는 들어 있지 않습니다. 그래서 설정률표를 매핑 테이블로 두고 CDS 큐브에서 읽어 오는 구조로 만들었습니다(CDS 구성 절 참조).

요구사항 매핑표

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

CDS 구성

이 절의 코드는 화면이 읽는 숫자를 SAP 쪽에서 만들 때의 구성을 보이는 스케치입니다. 표준 뷰 이름과 필드는 시스템 버전에 따라 다를 수 있어 도입 시 확인이 필요하며, 이름은 기능을 뜻하는 영문으로 지었습니다. 샘플 앱의 서비스는 같은 계산을 서비스 로직 한 파일로 구현해 두었고, 운영에서는 아래 구성으로 옮깁니다.

뷰 레이어 구성

① 설정률표와 전표 유형 매핑 테이블

이 표가 사후검증의 기준선입니다. 설정률이 이 테이블에 들어 있어야 "그때 무엇을 적용했는가"를 기준일마다 되살릴 수 있습니다. 유효 시작일을 키에 넣은 것은 설정률이 바뀌어도 과거 기준월의 점검 결과가 달라지지 않게 하려는 것입니다.

// ─────────────────────────────────────────────────────────────
// ZECLBK_RATE · ZECLBK_DOCMAP  (DDIC 테이블 2개)
// 역할  : 회사가 정하는 값 — 구간별 설정률과 제각·회수 전표 유형 —
//         을 코드가 아니라 테이블에 둡니다.
// 이유  : 설정률은 해마다 바뀌고, 전표 유형은 회사마다 다릅니다.
//         값이 바뀔 때 CDS 를 고쳐 이송하지 않도록 행만 추가합니다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '기대신용손실 설정률표'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zeclbk_rate {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key valid_from : abap.dats not null;   // 이 날짜 이후 기준일에 적용
  key bucket     : abap.char(2) not null; // B0 미연체 · B1 1~30 · B2 31~60 …
  rate_pct       : abap.dec(12,4);        // 적용 설정률(%)
  band_ratio     : abap.dec(5,4);         // 허용 비율, 예) 0.3000
  band_floor_pct : abap.dec(5,4);         // 허용 하한 폭(%p), 예) 0.2500
}

@EndUserText.label : '제각·회수 전표 유형 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zeclbk_docmap {
  key client   : abap.clnt not null;
  key bukrs    : bukrs not null;
  key blart    : blart not null;          // 회계전표 유형
  evt_type     : abap.char(1);            // C 회수 · W 제각 · R 제각 후 회수
}

② 기준일 채권과 연체 구간 뷰

운영에서 가장 먼저 부딪히는 질문은 "무엇을 채권으로 볼 것인가"입니다. 기준일에 열려 있던 고객 항목만 잡고, 기준일 이후에 청산된 항목은 그 시점에는 열려 있었으므로 포함합니다. 구간 경계는 이 뷰의 case 식 한 곳에만 둡니다.

// ─────────────────────────────────────────────────────────────
// ZI_EclBackOpen  (기준일 채권 + 연체 구간)
// 역할  : 기준일에 열려 있던 고객 항목을 채권으로 잡고
//         연체일수와 구간을 파생합니다.
// 이유  : 구간 경계가 이 뷰 한 곳에만 있어야 큐브·쿼리가 같은 구간을 씁니다.
// 확인  : 표준 뷰 이름·필드는 시스템 버전에 따라 다를 수 있어 도입 시 확인이 필요합니다.
// ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '기준일 채권과 연체 구간'
define view entity ZI_EclBackOpen
  with parameters
    p_BaseDate : abap.dats
  as select from I_OperationalAcctgDocItem as it
{
  key it.CompanyCode,
  key it.AccountingDocument,
  key it.FiscalYear,
  key it.AccountingDocumentItem,
      it.Customer,
      it.NetDueDate,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      it.AmountInCompanyCodeCurrency   as BaseAmt,
      it.CompanyCodeCurrency,
      dats_days_between( it.NetDueDate, $parameters.p_BaseDate ) as DueDays,
      case
        when dats_days_between( it.NetDueDate, $parameters.p_BaseDate ) <= 0   then 'B0'
        when dats_days_between( it.NetDueDate, $parameters.p_BaseDate ) <= 30  then 'B1'
        when dats_days_between( it.NetDueDate, $parameters.p_BaseDate ) <= 60  then 'B2'
        when dats_days_between( it.NetDueDate, $parameters.p_BaseDate ) <= 90  then 'B3'
        when dats_days_between( it.NetDueDate, $parameters.p_BaseDate ) <= 180 then 'B4'
        else 'B5'
      end                              as Bucket
}
where it.FinancialAccountType = 'D'
  and it.PostingDate <= $parameters.p_BaseDate
  and ( it.ClearingDate is initial or it.ClearingDate > $parameters.p_BaseDate )

③ 이후 12개월 결과 뷰

사후검증의 "사후"가 이 뷰입니다. 기준일 다음 날부터 12개월을 관측 기간으로 두고 전표 유형 매핑에 따라 회수 · 제각 · 제각 후 회수를 가릅니다. 관측 기간이 아직 끝나지 않은 기준월은 결과가 덜 쌓여 있으므로 점검 대상에서 제외하거나 "관측 중"으로 표시하는 규칙을 정해야 합니다(운영 시점에 해야 할 일 참조).

// ─────────────────────────────────────────────────────────────
// ZI_EclBackOutcome  (이후 12개월 결과 — 채권별)
// 역할  : 기준일 다음 날부터 12개월 동안의 회수·제각·제각 후 회수를
//         채권별로 한 줄에 모읍니다.
// 이유  : 전표 유형 해석(회사 정의)을 한 곳에 가둬 두면
//         유형이 바뀌어도 이 뷰만 손보면 됩니다.
// 확인  : 제각 전표 유형과 회수 전표 유형은 회사 정의라 확인이 필요합니다.
// ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '채권별 후속 12개월 결과'
define view entity ZI_EclBackOutcome
  with parameters
    p_BaseDate : abap.dats
  as select from I_OperationalAcctgDocItem as ev
    inner join   zeclbk_docmap             as mp
      on  mp.bukrs = ev.CompanyCode
      and mp.blart = ev.AccountingDocumentType
{
  key ev.CompanyCode,
  key ev.Customer,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( case mp.evt_type when 'C' then abs( ev.AmountInCompanyCodeCurrency ) else 0 end ) as CollAmt,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( case mp.evt_type when 'W' then abs( ev.AmountInCompanyCodeCurrency ) else 0 end ) as WoAmt,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( case mp.evt_type when 'R' then abs( ev.AmountInCompanyCodeCurrency ) else 0 end ) as RecvAmt,
      ev.CompanyCodeCurrency
}
where ev.PostingDate >  $parameters.p_BaseDate
  and ev.PostingDate <= dats_add_months( $parameters.p_BaseDate, 12, 'NULL' )
group by ev.CompanyCode, ev.Customer, ev.CompanyCodeCurrency

④ 구간별 큐브

큐브는 합계만 둡니다. 실현손실률을 큐브 안에서 구해 저장해 두면 구간을 다시 묶을 때(예: 61~180일을 하나로) 비율의 평균이 되어 값이 틀어집니다. 합계를 더한 뒤 마지막에 한 번 나누는 구조여야 어떤 축으로 묶어도 같은 값이 나옵니다.

// ─────────────────────────────────────────────────────────────
// ZI_EclBackCube  (구간별 큐브)
// 역할  : 채권 + 설정률 + 후속 결과를 합쳐 구간 단위의 합계를 만듭니다.
//         금액은 합계만 두고 비율은 소비 뷰에서 다시 계산합니다.
// 이유  : 비율을 큐브에 저장해 두면 구간을 다시 묶을 때 평균의 평균이 됩니다.
//         합계만 두고 나눗셈은 맨 마지막에 한 번만 합니다.
// ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '설정률 사후검증 큐브'
define view entity ZI_EclBackCube
  with parameters
    p_BaseDate : abap.dats
  as select from ZI_EclBackOpen( p_BaseDate: $parameters.p_BaseDate ) as op
    left outer to one join ZI_EclBackOutcome( p_BaseDate: $parameters.p_BaseDate ) as oc
      on  oc.CompanyCode = op.CompanyCode
      and oc.Customer    = op.Customer
    left outer to one join zeclbk_rate as rt
      on  rt.bukrs  = op.CompanyCode
      and rt.bucket = op.Bucket
{
  key op.CompanyCode,
  key op.Bucket,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      @DefaultAggregation: #SUM
      op.BaseAmt                                         as BaseAmt,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      @DefaultAggregation: #SUM
      cast( op.BaseAmt * rt.rate_pct / 100 as abap.curr(15,2) ) as AllowCalc,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      @DefaultAggregation: #SUM
      cast( oc.WoAmt - oc.RecvAmt as abap.curr(15,2) )   as NetLoss,
      rt.rate_pct                                        as RatePct,
      rt.band_ratio                                      as BandRatio,
      rt.band_floor_pct                                  as BandFloorPct,
      op.CompanyCodeCurrency
}

⑤ 구간별 사후검증 쿼리

허용 범위와 판정이 여기서 결정됩니다. 서비스 쪽 구현과 같은 식이어야 하므로 이 뷰의 식이 곧 서비스 계약의 일부입니다. 허용 범위는 적용 설정률의 비율과 하한 폭 중 큰 쪽을 쓰고, 판정은 UNDER · OVER · OK 세 값으로만 내보냅니다.

// ─────────────────────────────────────────────────────────────
// ZC_EclBackBucketQuery  (구간별 사후검증 — 소비 뷰)
// 역할  : 큐브 합계에서 실현손실률 · 편차 · 허용 범위 · 판정을 계산합니다.
// 이유  : 판정 규칙(허용 범위 밖이면 점검 필요)을 이 뷰 한 곳에만 둡니다.
//         화면은 이 뷰가 내보낸 판정을 읽기만 합니다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '구간별 사후검증'
@Metadata.allowExtensions: true
define view entity ZC_EclBackBucketQuery
  with parameters
    p_BaseDate : abap.dats
  as select from ZI_EclBackCube( p_BaseDate: $parameters.p_BaseDate ) as c
{
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false, mandatory: true }
  key c.CompanyCode,
  key c.Bucket,
      c.BaseAmt,
      c.AllowCalc,
      c.NetLoss,
      c.RatePct,
      division( c.NetLoss * 100, c.BaseAmt, 4 )          as RealRate,
      division( c.NetLoss * 100, c.BaseAmt, 4 ) - c.RatePct as Gap,
      c.RatePct - greatest( c.RatePct * c.BandRatio, c.BandFloorPct ) as BandLow,
      c.RatePct + greatest( c.RatePct * c.BandRatio, c.BandFloorPct ) as BandHigh,
      case
        when division( c.NetLoss * 100, c.BaseAmt, 4 )
             > c.RatePct + greatest( c.RatePct * c.BandRatio, c.BandFloorPct ) then 'UNDER'  // 과소 설정 후보
        when division( c.NetLoss * 100, c.BaseAmt, 4 )
             < c.RatePct - greatest( c.RatePct * c.BandRatio, c.BandFloorPct ) then 'OVER'   // 과대 설정 후보
        else 'OK'
      end                                                as Verdict
}

⑥ 접근 제어 (DCL)

권한은 집계 단계에서 겁니다. 드릴스루(채권 단위)에만 걸어 두면 구간 합계에서 다른 회사 숫자가 빠져나옵니다.

// ─────────────────────────────────────────────────────────────
// ZI_EclBackCube · ZI_EclBackOpen  접근 제어 (DCL)
// 역할  : 회사코드 단위로 조회 범위를 제한합니다.
// 이유  : 구간 합계는 한 회사 전체 채권의 요약이라
//         집계 단계에서 걸지 않으면 다른 회사 숫자가 합계로 새어 나옵니다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '설정률 사후검증 큐브 접근 제어'
@MappingRole: true
define role ZI_EclBackCube {
  grant select on ZI_EclBackCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

@EndUserText.label: '기준일 채권 접근 제어'
@MappingRole: true
define role ZI_EclBackOpen {
  grant select on ZI_EclBackOpen
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

화면이 읽는 서비스 계약을 고정하는 자리입니다. 엔티티 이름은 화면이 쓰는 이름 그대로 두고, 뷰 이름이 바뀌어도 서비스 이름과 엔티티 이름은 유지합니다.

// ─────────────────────────────────────────────────────────────
// ZSD_EclBack  (서비스 정의) + 서비스 바인딩
// 역할  : 소비 뷰를 OData V2 서비스로 내보냅니다.
// 이유  : 화면은 서비스 이름과 엔티티 이름만 알면 되고, 뷰가 바뀌어도
//         서비스 계약(경로·키)은 유지됩니다.
// 확인  : 바인딩은 'OData V2 – UI' 유형으로 만들고 게시한 뒤
//         /IWFND/MAINT_SERVICE 에서 활성화 상태를 확인합니다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '설정률 사후검증 서비스'
define service ZSD_EclBack {
  expose ZC_EclBackBucketQuery as BucketCheck;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때 — 채권이 수백만 건이면

샘플은 64건이라 구간 집계가 즉시 끝나지만 운영에서는 기준일 열린 항목이 수백만 건일 수 있습니다. 집계는 화면이 아니라 CDS 큐브에서 해야 하고, 기준일 · 회사코드는 필수 파라미터로 두어 전체 스캔을 막습니다. 큐브 단계 응답은 구간 여섯 개 · 고객군 네 개 수준의 몇 줄이라 가볍고, 비용은 채권 단위의 드릴스루에서 생깁니다. 그래서 채권 명세는 페이지 단위($top · $skip)로만 받고, 건수는 $inlinecount 로 숫자만 받습니다. 응답 시간 기준(예: 구간 요약 3초 안, 채권 명세 첫 페이지 5초 안)을 도입 전에 정해 두고, 넘으면 후속 12개월 결과 뷰를 미리 집계한 뷰(또는 배치 적재)로 바꾸는 순서로 대응합니다.

자주 묻는 질문

도입을 검토하는 분들이 자주 물어 오는 것을 숫자와 산식 · 화면과 조작 · SAP 연계와 데이터 · 도입과 운영으로 묶었습니다.

숫자와 산식

화면과 조작

SAP 연계와 데이터

도입과 운영