리스제공자 리스료 수취 만기분석 점검 — IFRS 16 에서 운용리스·금융리스 할인 전 리스료를 받을 시기별로 다시 나눠 공시 초안과 맞춰 보는 화면

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

IFRS 16 리스(K-IFRS 제1116호)에서 리스를 빌려 주는 쪽, 곧 리스제공자는 리스료를 앞으로 받을 시기별로 나눠 보이는 만기분석을 주석에 밝힙니다. 운용리스는 할인하지 않은 리스료를, 금융리스는 할인 전 리스료와 리스순투자의 조정을 함께 보입니다. 표 하나지만 만들 때는 계약마다 지급 일정을 펼치고, 보고기간 말을 기준으로 1년 이내 · 1년 초과 2년 이내 같은 구간에 하나씩 넣어야 합니다. 구간 구성과 요구 범위는 원문 확인 필요이며, 이 화면은 회사가 정한 구간 틀을 점검 규칙으로 옮겨 쓴 것입니다.

지금은 이 표를 만들고 검토하려면 개별 항목 조회와 리스 계약 목록 엑셀, 계약별 지급 일정표를 번갈아 열어 건마다 손으로 맞춥니다. 일정표를 한 번 펼쳐 놓고 나면 “이 건이 왜 이 구간에 들어갔는가”를 설명할 근거가 흩어지고, 이미 받은 금액이나 변동리스료가 섞여 들어가도 합계만 봐서는 보이지 않습니다. 이 앱은 그 자료를 한 화면에 붙여, 지급 건마다 수취 예정일과 리스료 성격으로 다시 구한 구간(재계산 구간)을 공시 초안에 놓인 구간과 나란히 놓고, 다른 건과 판단 근거가 비어 있는 건을 점검 대상으로 보여 줍니다.

구간은 계약이 아니라 지급 건 하나하나의 날짜로 갈린다

한 계약의 리스료가 모두 같은 구간에 들어가는 것이 아닙니다. 5년짜리 계약이라면 1회차는 1년 이내, 2회차는 1년 초과 2년 이내에 놓이고, 계약 기간이 길면 남는 금액은 5년 초과로 묶입니다. 계약 단위로 구간을 한 번에 정해 두면 한 회차의 수취일이 밀리거나 당겨졌을 때 합계만 같고 구간별 금액은 틀어진 채 남습니다. 이 앱은 지급 건마다 수취 예정일을 읽어 구간을 다시 구하므로, 어느 회차가 어느 구간에서 빠졌는지 건 단위로 보입니다.

이미 받은 금액과 변동리스료는 앞으로 받을 리스료가 아니다

만기분석은 보고기간 말 이후에 받을 리스료를 보이는 표입니다. 그래서 보고기간 말 이전에 수취가 끝난 금액이 구간 안에 들어 있으면 점검 대상입니다. 지수나 요율에 연동되지 않는 변동리스료도 같은 이유로 확인합니다. 이 화면은 두 경우를 각각 점검 코드(M03 · M02)로 가려내 보여 줍니다. 어떤 금액이 리스료의 정의에 들어가는지는 계약 조건에 따라 달라 회사가 판단하고, 요건은 원문 확인 필요입니다.

구간에서 아예 빠진 금액이 가장 찾기 어렵다

구간이 다른 건은 합계가 같아서 구간별 표에서 서로 상쇄됩니다. 반대로 앞으로 받을 리스료인데 만기분석에 들어 있지 않은 건은 합계 자체가 줄어듭니다. 이 앱은 일정에는 있고 공시 초안에는 없는 금액을 따로 점검 코드(M04)로 모아, 합계 대사에서 누락분으로 설명되게 했습니다.

금융리스는 할인 전 리스료와 순투자가 이어져야 한다

금융리스는 구간표만 맞아서는 끝나지 않습니다. 할인 전 리스료에 무보증잔존가치를 더하고 미획득 금융수익을 빼면 리스순투자가 되는데, 이 조정이 장부의 순투자와 이어지는지를 같이 봐야 합니다. 이 앱은 금융리스 계약마다 이 계산을 다시 해서 장부 순투자와 견주고, 다르면 점검 코드(N01)로 알립니다. 기준서가 요구하는 조정표의 정확한 모양은 원문 확인 필요입니다.

일정이 비어 있으면 판단을 보류한다

점검 도구가 제일 조심해야 하는 일은 근거 없이 구간을 단정하는 것입니다. 수취 예정일이 아직 정해지지 않은 금액은 구간을 판단할 기준이 없으므로 이 앱은 임의로 구간을 채우지 않고 “확인 필요”로 표시해 판정 보류에 모읍니다. 회사가 일정을 정한 뒤 다시 조회하면 그 금액이 재계산 구간에 들어옵니다.

사용 방법

1. 회계연도를 입력합니다(필수, 4자리). 회사 · 리스 분류 · 공시 초안 구간 · 수취 예정일 · 계약명 · 점검 코드 · 점검 결과는 필요할 때만 고릅니다.
2. 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 조회 버튼은 조회조건 영역 안 입력칸들의 가장 오른쪽에 있고, 화면을 열면 회계연도 기준으로 한 번 자동 조회됩니다.
3. 위쪽 요약에서 점검한 지급 건수 · 점검 필요 항목 · 확인 필요 항목 · 구간 이동·정정 필요 금액 · 공시 초안에 담긴 할인 전 리스료 · 정합성 대사 차이 건수를 먼저 봅니다.
4. 탭을 계약별 만기분석 → 지급 건별 점검 → 만기 구간별 합계 → 금융리스 순투자 조정 → 대사 결과 순서로 옮겨 가며 봅니다.
5. 지급 건별 점검 탭에서 행을 누르면 상세가 열려 점검 근거와 같은 계약의 지급 일정 비교가 나옵니다.
6. CSV 내려받기 버튼으로 지금 보고 있는 탭을 UTF-8 파일로 내려받아 검토 자료에 붙입니다.

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

만기분석에서 가장 비싼 질문은 “이 합계 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 검증용 샘플 데이터 전체로 돌렸습니다. 아래는 그 결과입니다.

정합성 대사 여섯 식은 모두 차이 0 이고, 참고 대사 한 식(R07)에만 의도적으로 넣은 예외 한 건이 남아 있습니다. 점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 검증용 샘플 데이터에는 점검 필요 지급 건 6건(구간 불일치 3건 · 변동리스료 1건 · 기수취 1건 · 누락 1건), 확인 필요 1건, 금융리스 순투자 점검 필요 1건이 들어 있고, 이 숫자는 정합성 대사 차이 0건과 별개입니다. 이와 별도로 일정에서 구간과 순투자를 독립 재계산하는 검증 스크립트가 8개 검사 항목(검사 건수 합계 153건) 모두 차이 0건임을 확인했습니다.

무엇으로 만들었나

실행 화면

실제 사용 순서대로 화면 일곱 장을 싣습니다. 모든 화면은 검증용 샘플 데이터(회사 2곳 · 리스 계약 15건 · 지급 건 98건)로 열었습니다.

처음 열면 계약별 만기분석이 먼저 보인다

화면을 열면 회계연도를 기준으로 한 번 자동 조회되어, 입력 없이도 계약별 만기분석이 바로 채워집니다. 요약 지표 여섯 개를 먼저 읽고 표로 내려가는 순서가 기본입니다.

맨 위 파란 안내는 이 화면이 점검 도구이며 최종 판단은 회사와 감사인이 한다는 점을 먼저 밝힙니다. 요약의 ‘98’은 점검한 지급 건수, ‘6’은 점검 필요 항목, ‘1’은 확인 필요 항목이고, 구간 이동·정정 필요 금액은 1,140.1 백만 원, 공시 초안에 담긴 할인 전 리스료는 18,283.6 백만 원, 정합성 대사 차이는 0건으로 보입니다. 아래 표는 리스 계약 15건을 한 줄씩 보여 주며 재계산한 구간별 금액이 줄마다 나란히 놓입니다. 점검 결과 칸의 ‘정상’ · ‘점검 필요’ · ‘확인 필요’로 어느 계약부터 볼지 바로 가려집니다.

지급 건마다 점검하고, 조건으로 좁힌다

계약 단위에서 의심 가는 곳이 보이면 건별 탭으로 내려가 어느 회차의 구간이 다른지 확인합니다. 점검 코드로 좁히면 같은 사유의 건만 남습니다.

탭을 지급 건별 점검으로 옮기면 지급 건 98건이 한 줄씩 나옵니다. 건마다 계약, 리스료 성격(고정 · 변동 · 기수취), 수취 예정일, 금액, 공시 초안 구간, 재계산 구간, 이동 필요 금액, 점검 내용이 나란히 놓입니다. 점검 필요 건은 이동 필요 금액이 0이 아니게 표시되어 합계로 한눈에 훑을 수 있고, 건수가 많을 때는 아래 조회조건으로 좁히면 됩니다.

점검 코드를 구간 불일치(M01)로 고르고 조회하면 지급 건별 점검 탭에 3건만 남고, 요약의 점검한 지급 건수도 3으로 바뀝니다. 입력칸에서 Enter 키를 눌러도 같은 조회가 일어납니다. 조회조건을 비우고 초기화를 누르면 회계연도 기본값으로 돌아가며, 수취 예정일 시작이 종료보다 늦으면 조회하지 않고 안내 문구를 보입니다.

행을 눌러 근거를 본다

점검 필요로 나온 건은 이유를 설명할 수 있어야 의미가 있습니다. 한 줄을 누르면 근거 문장과 같은 계약의 지급 일정 비교가 열립니다.

지급 건별 점검 표에서 한 줄을 누르면 리스료 지급 건 상세가 열립니다. 위쪽에는 계약명, 금액, 자산 유형, 리스 분류, 리스료 성격, 수취 예정일, 공시 초안 구간, 재계산 구간이 나오고, 가운데에는 점검 근거 문장이 나옵니다. 아래 표는 같은 계약의 지급 일정을 회차별로 보여 주며 어느 회차에서 공시 초안과 재계산 구간이 갈라지는지, 이동이 필요한 금액이 얼마인지 읽을 수 있습니다. 닫기를 누르면 조회 결과 그대로 표로 돌아옵니다.

구간 합계와 순투자, 대사로 합계를 확인한다

건 단위 점검이 끝나면 구간별 합계로 어느 구간에서 차이가 생기는지 보고, 금융리스는 순투자 조정으로 장부와 맞춰 보고, 마지막으로 대사 결과로 합산 과정의 합계가 맞는지 확인합니다.

만기 구간별 합계 탭은 회사 · 리스 분류 · 구간 단위로 24줄이 나옵니다. 공시 초안 금액과 재계산 금액, 두 금액의 차이, 관련 지급 건수, 점검 필요 건수가 한 줄에 놓입니다. 회사 1000 의 운용리스에서는 1년 초과 2년 이내 구간의 공시 초안이 재계산보다 236,000,000원 크고 2년 초과 3년 이내 구간은 522,000,000원 작게 나타나, 구간 사이로 금액이 옮겨 놓인 위치를 바로 볼 수 있습니다.

금융리스 계약 5건이 한 줄씩 나오며 내재이자율, 할인 전 리스료, 무보증잔존가치, 할인 전 합계, 미획득 금융수익, 재계산 순투자, 장부 순투자, 차이, 점검 결과를 보여 줍니다. 한 건에서만 장부 순투자가 재계산보다 12,000,000원 크게 나오며, 이 건이 점검 코드 N01 로 올라옵니다. 순투자는 계약의 내재이자율로 현재가치를 다시 구해 확인한 값입니다.

대사 결과 탭에는 대사 번호 · 구분 · 대사 항목 · 좌변 · 우변 · 검사 건수 · 차이 건수 · 최대 차이 · 대사식이 한 줄씩 나옵니다. 정합성 대사 여섯 줄은 모두 차이 건수 0 이고 좌변과 우변이 같은 금액입니다. 참고 대사 한 줄(R07)만 차이 건수 1, 최대 차이 12,000,000원이며, 이것이 의도적으로 넣은 예외 건입니다. 요약의 정합성 대사 차이가 0건인 것은 이 참고 대사를 제외한 값입니다.

화면 뒤에서 일어나는 일

지급 건마다 수취 예정일과 리스료 성격으로 재계산 구간을 구하고 공시 초안 구간과 견주는 순서와 판정 결과는 아래와 같습니다. 이 순서는 화면의 점검 규칙이며, 보고기간 말은 회계연도 12월 31일로 둡니다.

처리 순서는 다섯 단계입니다. 먼저 지급 건마다 재계산 구간을 구해 점검 코드를 붙이고, 같은 건을 계약 단위와 구간 단위로 각각 합산하며, 금융리스는 순투자를 다시 계산하고, 마지막으로 대사 일곱 식으로 합계를 맞춥니다. 판정 규칙은 서비스 로직 한 곳에만 있어서 화면 · 합계 · 대사가 같은 숫자를 씁니다.

조회조건

결과 컬럼

금액은 원 단위로 보이고, 요약만 백만 원 단위로 보입니다.

좁은 화면에서 달라지는 것

화면 폭이 좁아지면 조회조건과 요약 지표는 한 줄에 다 담지 않고 줄을 바꿔 이어지며, 표는 가로로 스크롤해 열을 모두 읽습니다. 열을 숨기지 않으므로 좁은 화면에서도 같은 숫자를 읽을 수 있습니다.

파일 구성

앱 폴더/
├─ index.html · readme.html · Component.js · manifest.json
├─ controller/   화면 제어 2개
├─ view/         본 화면 · 상세 창
├─ model/        표시 형식 · 오류 처리
├─ css/ · i18n/  스타일 · 문구
├─ odata/        서비스 정의와 로직, 데이터(검증용 샘플)
└─ media/        소개 영상 · 표지 그림

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준 화면 사이에서 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 리포트를 없애야 하느냐”는 질문이 꼭 나오는데, 답은 없애지 않고 둔다입니다. 대사와 감사 대응, 법정 공시용 출력은 표준 거래가 맡는 편이 안전합니다.

표준에 남겨 둘 일은 공시 주석 자체의 작성과 법정 출력, 감사인에게 내는 원장 증빙입니다. 이 앱의 CSV 는 검토 자료를 보조하는 용도이며 공시 문서를 대신하지 않습니다.

요구사항 매핑표

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 계정과 기간 축으로 합계를 보는 데 강합니다. 이 앱은 그 위에서 쓰는 점검 화면이 아니라 지급 일정이라는 별도 축을 가진 점검 전용 서비스입니다. 표준 분석 앱으로 합계를 확인하고, 합계가 다른 이유를 건 단위로 설명할 때 이 앱을 쓰는 순서가 자연스럽습니다. 같은 CDS 뷰를 분석 앱에서도 읽을 수 있게 열어 두면 두 화면의 숫자는 같은 원천에서 나옵니다. 표준 뷰의 이름과 필드는 대상 릴리스에서 확인이 필요합니다.

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

CDS 구성

화면이 읽는 서비스의 뒤쪽을 S/4HANA 의 CDS 뷰로 옮긴다면 어떻게 짤지를 코드와 함께 적습니다. 원천은 유니버설 저널(ACDOCA)과 계약 지급 일정이고, 판단에 쓰는 값(리스료 성격 · 구간 틀 · 회사 설정)은 회사가 관리하는 매핑 테이블에 둡니다. 아래 코드는 구조를 보여 주는 참고안이며, 표준 뷰 이름과 필드는 대상 릴리스에서 확인이 필요합니다.

뷰 레이어 구성

① 매핑 테이블 — 리스료 성격과 지급 일정

점검의 출발점은 리스료가 어떤 성격(고정 · 변동 · 기수취)인지와 계약별 지급 일정입니다. 성격 구분은 회사가 정하는 판단이라 코드에 박지 않고 테이블로 둡니다. 수취 예정일이 비어 있는 일정은 판정 보류(확인 필요)로 올라오므로, 일정이 채워지는 만큼 보류가 줄어드는 구조입니다.

" ─────────────────────────────────────────────────────────────
" ZLSMT_PAYTYPE · ZLSMT_SCHED : 리스료 성격 구분과 지급 일정
" 역할 : 점검 판정의 입력값. 회사가 관리한다.
" 이렇게 나눈 이유 : 리스료 성격을 바꿔도 뷰 코드를 고치지 않게 하고, 일정과 원장 라인을 분리해 두려는 것이다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '리스료 성격 구분'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zlsmt_paytype {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key pay_code  : abap.char(2) not null;   " 계약 지급 코드
  pay_type      : abap.char(1);            " F 고정  V 변동(지수 비연동)  X 기수취
  valid_from    : abap.dats;
}

@EndUserText.label : '리스 계약 지급 일정'
@AbapCatalog.deliveryClass : #A
define table zlsmt_sched {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key lease_no  : abap.char(10) not null;
  key seq_no    : abap.numc(2) not null;
  pay_code      : abap.char(2);
  pay_date      : abap.dats;               " 비면 판정 보류
  @Semantics.amount.currencyCode : 'currency'
  pay_amt       : abap.curr(15,2);
  currency      : waers;
  booked_bucket : abap.char(3);            " 공시 초안에 놓인 구간(Y1..Y6, EXC)
}

② 리스 계약 차원 뷰

계약 번호와 계약명, 자산 유형, 리스 분류는 모든 뷰가 같은 이름으로 써야 하는 속성이라 차원 뷰로 한 번만 정의합니다. 부동산 리스는 계약 관리 거래의 계약을 읽고, 그 밖의 자산은 회사가 쓰는 리스 마스터를 읽도록 한 뷰 뒤에서 합칩니다.

" ─────────────────────────────────────────────────────────────
" ZI_LessorMatLease : 리스 계약 차원
" 역할 : 계약 단위 속성을 한 곳에서 제공한다.
" 이렇게 나눈 이유 : 건 · 합계 · 쿼리가 같은 계약 이름과 분류를 쓰게 하려는 것이다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스제공자 계약 차원'
@ObjectModel.representativeKey: 'LeaseNo'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_LessorMatLease
  as select from zlsmt_lease_mst            " 고객사 리스 마스터(확인 필요)
{
  key bukrs         as Bukrs,
  key lease_no      as LeaseNo,
      lease_name    as LeaseName,
      asset_type    as AssetType,
      lease_class   as LeaseClass,          " O 운용리스  F 금융리스
      end_date      as EndDate,
      impl_rate     as ImplRate             " 내재이자율(금융리스)
}

③ 지급 건 기본 뷰 — 일정에서 건 단위로

이 뷰는 지급 일정 한 줄을 지급 건 하나로 만들고, 공시 초안에 놓인 구간과 리스료 성격을 붙입니다. 일정과 1대1로 맞아야 표준 원장 조회와 대조할 수 있으므로 이 뷰에서는 줄을 늘리거나 합치지 않습니다. 보고기간 말은 파라미터로 받아 회계연도마다 바뀌게 합니다.

" ─────────────────────────────────────────────────────────────
" ZI_LessorMatLine : 지급 건 기본 뷰
" 역할 : 일정 한 줄 = 지급 건 하나. 성격과 공시 초안 구간을 붙인다.
" 이렇게 나눈 이유 : 줄 수를 바꾸지 않아야 원장 라인과 합계를 맞출 수 있다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스료 지급 건'
@Analytics.dataCategory: #FACT
define view entity ZI_LessorMatLine
  with parameters
    p_gjahr : gjahr
  as select from      zlsmt_sched   as s
    left outer join   zlsmt_paytype as t
      on  t.bukrs    = s.bukrs
      and t.pay_code = s.pay_code
  association [1..1] to ZI_LessorMatLease as _Lease
    on  _Lease.Bukrs   = $projection.Bukrs
    and _Lease.LeaseNo = $projection.LeaseNo
{
  key s.bukrs                as Bukrs,
  key s.lease_no             as LeaseNo,
  key s.seq_no               as SeqNo,
      $parameters.p_gjahr    as Gjahr,
      s.pay_date             as PayDate,
      coalesce( t.pay_type, 'F' ) as PayType,
      @Semantics.amount.currencyCode: 'Currency'
      s.pay_amt              as PayAmt,
      s.currency             as Currency,
      s.booked_bucket        as BookedBucket,
      _Lease
}

④ 재계산 구간과 점검 코드

판정 규칙이 모이는 뷰입니다. 수취 예정일과 보고기간 말의 차이로 구간을 구하고, 리스료 성격과 공시 초안 구간을 견줘 점검 코드를 붙입니다. 규칙을 바꾸는 일은 이 뷰 한 곳에서만 일어나므로, 화면과 합계와 대사가 항상 같은 숫자를 씁니다. 연도 경계는 점검용 단순화이며 회사 정책에 맞게 조정합니다.

" ─────────────────────────────────────────────────────────────
" ZI_LessorMatCheck : 재계산 구간 · 점검 코드
" 역할 : 지급 건마다 구간을 다시 구하고 공시 초안과 견준다.
" 이렇게 나눈 이유 : 판정 규칙이 두 군데 이상 있으면 화면과 합계가 어긋난다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '재계산 구간과 점검 코드'
define view entity ZI_LessorMatCheck
  with parameters
    p_gjahr : gjahr
  as select from ZI_LessorMatLine( p_gjahr : $parameters.p_gjahr ) as l
{
  key l.Bukrs, key l.LeaseNo, key l.SeqNo,
      l.Gjahr, l.PayType, l.PayAmt, l.Currency, l.BookedBucket,

      case
        when l.PayDate is initial                              then 'HLD'  " 판정 보류
        when l.PayType = 'X'                                   then 'PST'  " 기수취
        when l.PayType = 'V'                                   then 'VAR'  " 변동리스료
        when l.PayDate <= concat( l.Gjahr, '1231' )            then 'PST'
        when l.PayDate <= concat( cast( l.Gjahr + 1 as abap.char(4) ), '1231' ) then 'Y1'
        when l.PayDate <= concat( cast( l.Gjahr + 2 as abap.char(4) ), '1231' ) then 'Y2'
        when l.PayDate <= concat( cast( l.Gjahr + 3 as abap.char(4) ), '1231' ) then 'Y3'
        when l.PayDate <= concat( cast( l.Gjahr + 4 as abap.char(4) ), '1231' ) then 'Y4'
        when l.PayDate <= concat( cast( l.Gjahr + 5 as abap.char(4) ), '1231' ) then 'Y5'
        else 'Y6'                                                        " 5년 초과
      end as ExpectBucket,

      case
        when l.PayDate is initial                              then 'M09'
        when l.PayType = 'V' and l.BookedBucket <> 'EXC'       then 'M02'
        when l.PayType = 'X' and l.BookedBucket <> 'EXC'       then 'M03'
        else 'M00'
      end as CheckCode_Base
      " M01(구간 불일치) · M04(누락)은 위 ExpectBucket 식을 재사용해
      " BookedBucket 과 견주는 CASE 를 같은 방식으로 이어 붙인다(지면상 생략).
}

⑤ 계약 · 구간 합계 큐브

합산은 큐브에서 한 번만 합니다. 같은 지급 건을 계약 단위와 구간 단위로 각각 합산하고, 이 두 합계가 대사식 R02 · R03 의 좌변과 우변이 됩니다. 금액 항목에는 통화 코드를 붙여 합계가 통화 단위로만 더해지게 합니다.

" ─────────────────────────────────────────────────────────────
" ZI_LessorMatCube : 계약 · 구간 큐브
" 역할 : 지급 건을 계약 단위와 구간 단위로 합산한다.
" 이렇게 나눈 이유 : 합산 위치를 하나로 해야 대사식의 좌변과 우변이 같은 원천에서 나온다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '계약 · 구간 합계 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_LessorMatCube
  with parameters
    p_gjahr : gjahr
  as select from ZI_LessorMatCheck( p_gjahr : $parameters.p_gjahr ) as c
{
  key c.Bukrs,
  key c.LeaseNo,
  key c.ExpectBucket,
      c.Currency,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( c.PayAmt )                                          as ExpAmt,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when c.BookedBucket = c.ExpectBucket
               then c.PayAmt else 0 end )                      as MatchedAmt,

      @DefaultAggregation: #SUM
      count( * )                                               as LineCnt
}
group by c.Bukrs, c.LeaseNo, c.ExpectBucket, c.Currency

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

화면이 직접 읽는 것은 쿼리입니다. 필수 파라미터(회계연도)와 필터 항목을 여기서 정하고, 컬럼 이름은 화면이 쓰는 프로퍼티와 같게 맞춥니다. 화면 요구가 바뀌어도 이 레이어만 고치면 아래 뷰는 그대로입니다.

" ─────────────────────────────────────────────────────────────
" ZC_LessorMatQuery : 화면용 분석 쿼리
" 역할 : 필터 · 컬럼 · 필수 파라미터를 정한다.
" 이렇게 나눈 이유 : 화면 요구 변경을 이 레이어에서 끝내려는 것이다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스제공자 만기분석 점검 쿼리'
@Analytics.query: true
@ObjectModel.usageType: { serviceQuality: #X, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZC_LessorMatQuery
  with parameters
    @Consumption.derivation: { lookupEntity: 'I_FiscalYearForCompanyCode' }
    p_gjahr : gjahr
  as select from ZI_LessorMatCube( p_gjahr : $parameters.p_gjahr )
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false, mandatory: false }
  Bukrs,

  @AnalyticsDetails.query.axis: #ROWS
  LeaseNo,

  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter.selectionType: #SINGLE
  ExpectBucket,

  @AnalyticsDetails.query.axis: #COLUMNS
  ExpAmt,
  MatchedAmt,
  LineCnt
}

⑦ 접근 제어(DCL)

합계만 읽을 수 있는 사람이 건 단위 조회와 합계의 차이로 다른 회사 숫자를 알아내는 일을 막으려면, 건 · 큐브 · 쿼리에 같은 제어를 걸어야 합니다. 회사코드 단위로 권한 오브젝트를 연결하는 예입니다.

" ─────────────────────────────────────────────────────────────
" ZC_LessorMatQuery : 접근 제어
" 역할 : 회사코드 단위 접근을 제한한다.
" 이렇게 나눈 이유 : 합계 뷰와 건 뷰의 권한이 달라지면 뺄셈으로 숫자가 드러난다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '리스제공자 만기분석 점검 접근 제어'
@MappingRole: true
define role ZC_LessorMatQuery {
  grant select on ZC_LessorMatQuery
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

마지막으로 쿼리와 건 뷰를 서비스로 내보냅니다. 서비스 이름은 화면의 서비스 주소에 쓰이므로 운영 전환 때 화면 설정만 바꾸면 됩니다.

" ─────────────────────────────────────────────────────────────
" ZUI_LessorMat : 서비스 정의
" 역할 : 쿼리와 지급 건을 OData 로 게시한다.
" 이렇게 나눈 이유 : 화면은 이 서비스 주소만 알면 된다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '리스제공자 만기분석 점검 서비스'
define service ZUI_LessorMat {
  expose ZC_LessorMatQuery as ContractSet;
  expose ZI_LessorMatCheck as LineSet;
}
"  서비스 바인딩: 이름 ZUI_LESSORMAT_O2, 바인딩 유형 OData V2 - UI
"  게시 후 /IWFND/MAINT_SERVICE 에서 활성화 상태 확인

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

지급 일정이 계약 수천 건 × 회차 수십 개로 늘어도 구조는 같지만, 집계 위치와 필수 조건이 성능을 좌우합니다. 회계연도와 회사코드는 쿼리의 필수 파라미터로 두고, 지급 일정 테이블의 회사 · 계약 키로 먼저 걸러 읽는 조건이 인덱스를 타는지 실제 데이터로 확인해야 합니다. 합산은 큐브에서 데이터베이스가 하도록 두고 화면이 지급 건을 모두 내려받지 않게 합니다. 응답 시간 목표는 고객사가 정할 일이며, 건별 탭은 건수가 일정 수를 넘으면 범위를 좁히라고 안내하는 편이 낫습니다. 구체 성능 수치는 운영 데이터 규모와 시스템 구성에 따라 달라 확인 필요입니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문들입니다. 네 묶음으로 나눠 적었습니다.

판정 규칙과 숫자

화면과 조작

표준 기능과의 관계

도입과 운영