리스부채 유동·비유동 구분 점검 — IFRS 16, 12개월 기준으로 리스부채를 다시 나눠 장부의 유동·비유동 구분과 견주고 이자·원금 일정까지 확인한다

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

리스이용자는 IFRS 16(K-IFRS 제1116호)에 따라 리스부채를 인식하고, 재무상태표에서는 1년 안에 갚을 몫(유동)과 그 뒤에 갚을 몫(비유동)으로 나누어 보여 줍니다. 결산 때마다 부딪히는 질문은 단순합니다. 장부에 올라간 유동 리스부채가 정말 앞으로 12개월 안에 갚을 원금인가. 리스부채는 계약마다 이자율과 지급 일정이 달라서, 이 질문에 답하려면 계약 조건으로 잔액을 다시 계산해야 합니다.

지금은 이 일이 리스 계약 관리 목록, 계산 엑셀, 총계정원장 잔액 세 곳에 흩어져 있습니다. 담당자는 계약별 지급표에서 12개월 내 지급액을 합산하고, 그중 이자를 빼 원금만 가려내 장부 유동 계정과 견주는 작업을 달마다 손으로 반복합니다. 이 앱은 그 계산을 계약·월 한 줄에 모아 재계산한 유동액과 장부의 유동액을 나란히 놓고, 차이가 나는 줄만 점검 필요로 걸러 줍니다.

이자를 포함한 금액이 유동으로 올라가기 쉽다

월 840만 원씩 내는 사무실 임차가 있다고 하면 12개월 내 지급액은 1억 800만 원입니다. 그러나 그중 이자가 약 1,300만 원이라면 유동 리스부채는 약 8,775만 원이어야 합니다. 지급표의 합계를 그대로 유동 계정에 옮기면 이자가 섞여 유동부채가 부풀고 비유동부채는 줄어듭니다. 이 앱은 12개월 내 지급액과 이자를 따로 보여 주고, 장부 유동액이 할인 전 지급액에 가까우면 점검 코드 GROSS로 표시합니다.

한번 나눈 구분이 다음 달로 그대로 넘어간다

월이 바뀌면 12개월 창이 한 달씩 앞으로 가므로 유동·비유동 구분도 다시 나눠야 합니다. 월마감 때 이 재분류가 빠지면 장부의 유동액이 전월 값 그대로 남습니다. 잔액은 지급에 따라 줄었는데 유동액만 그대로이니 합계는 맞아 보이고, 눈으로는 잘 드러나지 않습니다. 장부 유동액이 전월 재계산액과 같은 계약·월은 점검 코드 STALE로 표시합니다.

종료가 가까운 계약은 남은 지급 전부가 유동이다

잔여 기간이 12개월 이내로 들어온 계약은 남은 지급이 모두 유동이어야 하고, 이때 유동액은 잔액과 같아집니다. 그런데 비유동 계정에 일부가 남아 있으면 재무상태표에서 비유동부채가 실제보다 크게 나옵니다. 복합기·사무기기 리스처럼 계약이 끝나 가는 건은 이런 누락이 반복되기 쉬워, 잔여 12개월 이내인데 유동 장부액이 잔액보다 작으면 SHORT로 표시합니다.

합계는 맞는데 구분이 어긋나는 일

유동 장부액과 비유동 장부액을 더한 값은 리스부채 잔액과 같아야 합니다. 이 합이 어긋나면 구분 이전에 계정 간 이동이나 전기 오류를 의심해야 합니다. 이 앱은 장부 유동 + 비유동에서 잔액을 뺀 총액 차이를 따로 계산해 어긋난 계약·월을 TOTAL로 표시하고, 요약 위쪽 숫자와 합쳐 보이지 않게 둡니다.

그래서 무엇을 보려는 점검인가

정리하면 네 가지입니다. 계약 조건으로 리스부채 잔액을 다시 구하고, 12개월 뒤 잔액과의 차이로 유동액을 재계산하고, 그 값을 장부의 유동·비유동 구분과 견주고, 12개월 내 지급을 이자와 원금으로 나눠 그 근거를 보입니다. 이 네 가지를 계약·월 한 줄과 상세 한 창에서 따라갈 수 있게 한 것이 이 앱입니다. 증분차입이자율을 어떻게 정했는지, 연장·해지 선택권을 어떻게 판단했는지는 회사의 판단이므로 화면이 대신하지 않습니다.

사용 방법

1. 회계연도(필수, 4자리)를 확인하고 조회를 누르거나 입력칸에서 Enter 키를 누릅니다. 화면을 열면 한 번 자동으로 조회됩니다.
2. 필요하면 전기 월 시작·종료, 계약, 자산 구분, 점검 결과로 범위를 좁힙니다. 비워 두면 전체입니다.
3. 위쪽 요약에서 선택 범위 마지막 월의 잔액·유동 재계산액·유동 장부액·유동 차이와 점검 필요 계약·월, 대사 차이 건수를 봅니다.
4. 계약별 구분 → 12개월 내 지급 일정 → 월별 합계 → 대사 결과 탭 순서로 옮겨 가며 근거를 확인합니다.
5. 행을 누르면 계약 정보와 그 달 기준 12개월 지급 일정이 한 창에 열립니다. 닫기 버튼으로 닫습니다.
6. 표 위 오른쪽의 CSV 내려받기로 현재 탭의 조회 결과를 UTF-8 파일로 저장해 결산 점검표에 붙입니다.

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

화면에 나오는 숫자는 가상의 리스 계약 12건(건물·차량·IT장비·기계, 월납·분기납·연납)을 1~6월 기준으로 만든 검증용 샘플 데이터를 전수로 대사한 결과입니다. 계약·월 71행, 지급 일정 566행, 월별 합계 6행이며, 정합성 대사 5건은 모두 차이가 없습니다.

의도적 예외 4종(점검 코드 GROSS 4건, STALE 2건, SHORT 4건, TOTAL 1건, 합계 11건)은 점검 화면의 동작을 보이려고 일부러 넣은 건입니다. 계약·월 71건 중 11건이 점검 필요로 나오는 것이 정상 동작이며, 정합성 대사의 차이 건수와는 섞지 않고 따로 기록합니다. 6월 기준 잔액은 2,842.0백만원, 유동 재계산액은 771.9백만원, 장부 유동액은 827.1백만원이고 유동 차이는 +55.1백만원(7.14%)입니다. 화면 요약과 월별 합계가 검증 스크립트 결과와 같음을 렌더링 상태에서 대조했습니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조회 한 번으로 계약·월 전체와 요약 수치가 나오고, 점검 결과로 좁혀 다시 볼 줄만 남깁니다.

처음 열면 기본 조건(회계연도 2026, 월·계약·자산 구분·점검 결과는 전체)으로 자동 조회됩니다. 요약 수치는 선택한 범위의 마지막 월 기준이라 6월의 잔액 · 유동 재계산액 · 유동 장부액 · 차이를 보여 주고, 점검 필요 계약·월과 대사 차이는 범위 전체의 건수입니다. 표에서는 한 줄에 잔액, 재계산한 유동·비유동, 장부 유동·비유동, 차이와 차이율이 이어집니다.

조회조건의 점검 결과를 점검 필요로 바꾸고 조회를 누르면 장부와 재계산이 다른 계약·월만 남습니다. 탭 머리의 건수도 71에서 11로 바뀝니다. 차이가 한 계약에 몰리는지, 여러 계약에 퍼지는지가 먼저 보이고, 점검 내용 열이 어느 방향을 다시 열어 봐야 하는지 알려 줍니다. 원인을 단정하지는 않습니다.

일정과 월 합계로 근거 보기

유동 재계산액이 어디서 나왔는지는 지급 일정에서, 달마다 차이가 어떻게 쌓이는지는 월별 합계에서 확인합니다.

지급일마다 기초 잔액, 리스료 지급액, 이자, 원금 상환, 기말 잔액이 한 줄에 놓입니다. 월납 계약은 열두 줄, 분기납은 네 줄, 연납은 한 줄로 나옵니다. 한 계약·월의 원금 상환을 모두 더하면 계약별 구분 탭의 유동 재계산액과 같아야 하며, 이 일치를 대사 R03이 71건 전수로 검산합니다.

월마다 계약 수, 잔액, 유동·비유동 재계산액, 장부 유동액, 유동 차이와 차이율, 점검 필요 계약 수를 한 줄로 합산합니다. 1·2월은 점검 필요가 0건이고 3월 2건, 4월 2건, 5월 3건, 6월 4건으로 늘어나는 흐름이 보입니다. 월별 합계 탭에는 계약·자산 구분 조건이 적용되지 않고 회계연도와 월 범위만 적용됩니다.

대사 결과와 상세

숫자를 믿어도 되는지는 대사 탭에서, 한 계약의 사정은 상세 창에서 봅니다.

대사 R01~R05는 화면 숫자끼리 맞는지를 보는 검산이라 차이 건수가 0이어야 합니다. R06~R09는 점검 코드별 건수(GROSS 4 · STALE 2 · SHORT 4 · TOTAL 1)를 따로 세어 두어 정합성 차이와 섞이지 않게 했습니다. 위쪽 요약의 대사 차이 건수는 정합성 대사의 차이만 센 값입니다.

계약 번호와 자산 구분, 지급 주기, 증분차입이자율, 개시·종료일, 다음 지급일, 잔여 개월 같은 계약 정보와 그 달 기준 12개월 일정이 같이 나옵니다. 계약별 구분·지급 일정·월별 합계 어느 탭에서든 행을 누르면 열리고, 닫기 버튼으로 닫습니다.

화면 뒤에서 일어나는 일

계약·월마다 아래 순서로 판정합니다. 차이 허용 폭은 1,000원이며, 점검 코드는 원인을 단정하지 않고 점검 방향만 알려 줍니다.

처리는 다음 순서로 이어집니다.

1. 월 할인율을 구합니다. r = (1 + 연 증분차입이자율)^(1/12) − 1
2. 리스부채 잔액을 구합니다. B(t) = Σ 리스료 ÷ (1 + r)^(지급월 − t). 보고월 말 지급분은 이미 지급한 것으로 보고 뺍니다.
3. 12개월 뒤 잔액 B(t+12)를 같은 식으로 구합니다.
4. 유동 재계산액 = B(t) − B(t+12), 비유동 재계산액 = B(t) − 유동 재계산액으로 나눕니다.
5. 지급 일정은 이자 = 기초 잔액 × ((1 + r)^(지급 사이 개월 수) − 1), 원금 상환 = 리스료 − 이자로 만듭니다.
6. 장부 유동·비유동 금액과 견주어 점검 코드를 붙이고, 아래 대사식을 전수로 검산합니다.

숫자로 확인하면 이렇습니다. 본사 사무실 임차 1월의 잔액은 317,610,496원, 12개월 내 지급액(할인 전)은 100,800,000원, 그중 이자는 13,046,475원이어서 유동 재계산액은 100,800,000 − 13,046,475 = 87,753,525원입니다. 장부 유동액이 같은 금액이므로 이 줄은 정상입니다.

조회조건

월별 합계 탭에는 계약·자산 구분 조건이 적용되지 않고, 대사 결과 탭에는 회계연도만 적용됩니다.

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조회조건이 여러 줄로 접히고, 요약 수치는 두 줄로 나뉘며, 표는 가로로 밀어 볼 수 있습니다. 맨 앞 열(전기 월·계약 번호·계약)은 고정해 옆으로 밀어도 어느 계약인지 놓치지 않습니다. 상세 창은 화면 전체를 쓰도록 넓어집니다.

파일 구성

앱 폴더
├─ 앱 시작 파일, 앱 설정(서비스 선언 포함), 컴포넌트
├─ controller/   기본 컨트롤러 · 메인 컨트롤러
├─ view/         메인 화면 · 상세 창
├─ model/        표시 형식 · 오류 처리
├─ css/ · i18n/  스타일 · 한국어 문구
├─ odata/        서비스 정의 · 메타데이터 · 데이터 제공 로직
└─ media/        소개 영상

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

표준 실행은 SAP 표준 T-code가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준 화면이 이미 잘하는 일은 그대로 두고, 표준 화면 사이에서 끊기는 자리만 이어 붙입니다.

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

T-code별 연계 지점

두 화면의 숫자가 다를 때는 먼저 리스부채 계정 매핑(어느 계정이 유동이고 어느 계정이 비유동인가)이 같은지 봅니다. 결산 보고와 감사 대응에 쓰는 보고서는 계속 표준 화면에 남깁니다. 이 앱은 그 보고서를 대신하지 않고, 마감 전에 장부 구분이 재계산과 맞는지 보는 점검 자료를 더합니다. 그래서 운영으로 옮겨도 기존 표준 보고서를 없앨 필요가 없습니다.

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

표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office는 계정 잔액을 여러 축으로 보는 데 강합니다. 이 앱이 다루는 것은 잔액 자체보다 그 잔액이 어떻게 유동과 비유동으로 갈라져야 하는가입니다. 그래서 장부 금액은 표준 저널 항목 뷰를 읽는 기본 뷰로 두어 분석 쿼리와 같은 원천을 공유하고, 재계산은 별도 뷰에서 계약 조건을 읽어 구합니다. 두 값은 계약·월 키로 만나 큐브에서 비교합니다.

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

요구사항 매핑표

IFRS 16은 2019-01-01 이후 개시하는 회계연도부터 적용합니다. 이 외의 경과규정과 문단별 요구사항은 원문을 확인한 뒤 적용하시기 바랍니다.

CDS 구성

운영 전환의 핵심은 화면이 아니라 CDS 뷰입니다. 화면이 부르는 서비스는 아래 뷰 레이어를 그대로 노출하는 얇은 껍데기입니다. 객체 이름은 이 글의 예시이며 고객사 명명 규칙에 맞게 바꿔 쓰시면 됩니다. 표준 CDS 뷰는 실재가 확인된 것만 썼고, 확인하지 못한 자리(리스 계약 원천)는 “확인 필요”로 적었습니다.

뷰 레이어 구성

① 계정 매핑 테이블

어느 G/L 계정이 유동 리스부채이고 어느 계정이 비유동인지를 담는 입력 기준입니다. 같은 리스부채라도 회사마다 계정을 다르게 쓰고, 자산 구분이나 계약 유형마다 계정을 나누기도 합니다. 이 표가 장부 금액의 출발점이라 담당자가 바꿀 때 변경 이력이 남아야 하고, 비어 있으면 장부 금액은 0으로 읽히지 않고 “매핑 없음”으로 드러나야 합니다.

" ─────────────────────────────────────────────
" ZLCNC_ACCMAP  리스부채 계정 매핑
" 역할 : 유동·비유동 리스부채 G/L 계정을 회사코드·자산 구분별로 지정
" 이유 : 계정 체계는 회사마다 달라 코드에 박지 않고 데이터로 둔다
" ─────────────────────────────────────────────
@EndUserText.label : '리스부채 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zlcnc_accmap {
  key mandt        : mandt not null;
  key bukrs        : bukrs not null;
  key asset_class  : abap.char(10) not null;   " 건물·차량·IT장비·기계
  key valid_from   : abap.dats not null;       " 유효 시작일
  cur_account      : saknr not null;           " 유동 리스부채 계정
  noncur_account   : saknr not null;           " 비유동 리스부채 계정
  changed_by       : syuname;
  changed_at       : timestampl;
}

② 계약 기본 뷰 — 계약 조건

재계산에 필요한 계약 조건(지급 주기, 회차 지급액, 증분차입이자율, 개시·종료일)을 한 번에 읽는 기본 뷰입니다. 리스 계약을 RE-FX로 관리하면 그 계약 원천을, 별도 대장으로 관리하면 그 테이블을 읽습니다. 어느 쪽인지는 고객 환경에서 확인해야 하므로 아래는 자리만 잡아 둔 스케치입니다.

" ─────────────────────────────────────────────
" ZI_LeaseContract  리스 계약 기본 뷰 (스케치)
" 역할 : 계약 조건을 한 곳에서 읽는다
" 이유 : 재계산·화면·분석 쿼리가 같은 이율과 지급 조건을 쓰게 한다
" 확인 필요 : 계약 원천(RE-FX 계약 뷰 또는 리스 대장 테이블)
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '리스 계약 조건'
@Metadata.ignorePropagatedAnnotations : true
define view entity ZI_LeaseContract
  as select from zlcnc_contract            " 확인 필요: 운영 원천으로 교체
{
  key bukrs                              as CompanyCode,
  key contract_no                        as LeaseContract,
      contract_name                      as ContractName,
      asset_class                        as AssetClass,
      pay_freq                           as PayFrequency,        " M 월 · Q 분기 · Y 연
      @Semantics.amount.currencyCode : 'Currency'
      pay_amount                         as PaymentAmount,
      currency                           as Currency,
      ibr_pct                            as IncrementalBorrowingRate,  " 연 %, 계약별
      start_date                         as StartDate,
      end_date                           as EndDate
}

③ 지급 일정 뷰 — 12개월 창

보고월마다 “지금부터 12개월 안에 지급되는가”를 지급일 단위로 판정하는 뷰입니다. 유동 재계산액은 이 창 안의 원금 상환분이므로, 창을 자르는 기준(보고월 말을 넘는 첫 지급일부터 12개월)을 한 곳에만 둡니다. 보고월 말에 지급하는 분은 이미 지급한 것으로 봐서 제외합니다.

" ─────────────────────────────────────────────
" ZI_LeaseSchedule  지급 일정과 12개월 창
" 역할 : 지급일별 리스료, 이자, 원금과 12개월 창 포함 여부
" 이유 : 창 기준을 한 곳에 두어 유동 재계산과 화면 일정이 같게 한다
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '리스 지급 일정'
define view entity ZI_LeaseSchedule
  with parameters
    p_report_month_end : abap.dats
  as select from zlcnc_paysched as s
    inner join   ZI_LeaseContract as c
      on  c.CompanyCode   = s.bukrs
      and c.LeaseContract = s.contract_no
{
  key s.bukrs                             as CompanyCode,
  key s.contract_no                       as LeaseContract,
  key s.seq_no                            as PaymentSeq,
      s.pay_date                          as PaymentDate,
      @Semantics.amount.currencyCode : 'Currency'
      s.payment                           as Payment,
      s.currency                          as Currency,
      " 보고월 말을 넘고 12개월 안이면 유동 창에 포함
      case
        when s.pay_date >  $parameters.p_report_month_end
         and s.pay_date <= dats_add_months( $parameters.p_report_month_end, 12, 'FAIL' )
        then 'X' else ' '
      end                                 as InCurrentWindow
}

④ 장부 기본 뷰 — 표준 저널 항목에서 읽기

대사의 한쪽은 장부에 실제로 올라간 금액입니다. 표준 저널 항목 뷰를 읽고, 매핑 테이블로 유동·비유동을 가려 계약·월 단위로 모읍니다. 전표에 계약 번호를 어디에 실을지(참조 키, 배정 필드, 오더 등)는 운영에서 합의해야 하므로 LeaseContractKey는 확인 필요 자리입니다.

" ─────────────────────────────────────────────
" ZI_LeaseBook  유동·비유동 리스부채 장부 금액
" 역할 : 표준 저널 항목에서 매핑 계정별 월말 잔액을 계약 단위로 모음
" 이유 : 장부를 표준 원천 그대로 읽어 대사의 한쪽을 정직하게 둔다
" 확인 필요 : 계약 번호를 싣는 전표 필드(LeaseContractKey)
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '리스부채 장부 금액'
define view entity ZI_LeaseBook
  as select from I_JournalEntryItem as j
    inner join   zlcnc_accmap       as m
      on  m.bukrs = j.CompanyCode
      and ( m.cur_account = j.GLAccount or m.noncur_account = j.GLAccount )
{
  key j.CompanyCode,
  key j.FiscalYear,
  key j.FiscalPeriod,
  key j.LeaseContractKey                  as LeaseContract,   " 확인 필요
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      sum( case when j.GLAccount = m.cur_account
               then j.AmountInCompanyCodeCurrency else 0 end )     as BookCurrent,
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      sum( case when j.GLAccount = m.noncur_account
               then j.AmountInCompanyCodeCurrency else 0 end )     as BookNonCurrent,
      j.CompanyCodeCurrency
}
where j.Ledger = '0L'
group by j.CompanyCode, j.FiscalYear, j.FiscalPeriod, j.LeaseContractKey, j.CompanyCodeCurrency

⑤ 큐브 — 재계산과 판정

계약·월 한 줄에서 재계산한 유동액과 장부 금액이 만나는 자리입니다. 점검 코드 판정 순서(TOTAL → SHORT → STALE → GROSS)와 허용 폭이 여기에 모이므로, 이 뷰를 바꾸면 화면과 분석 쿼리의 판정이 함께 바뀝니다. 잔액 B(t)와 B(t+12)는 증분차입이자율로 할인한 현재가치 함수에서 오며, 아래는 판정 부분을 중심으로 줄인 스케치입니다.

" ─────────────────────────────────────────────
" ZC_LeaseCurCube  계약·월 유동 재계산과 점검 판정
" 역할 : 재계산 유동액 vs 장부 유동액, 점검 코드
" 이유 : 판정 규칙과 허용 폭을 한 곳에 모은다
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '리스부채 유동 재계산 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZC_LeaseCurCube
  as select from ZI_LeaseBalance as b            " B(t), B(t+12), 12개월 내 지급·이자
    left outer join ZI_LeaseBook as k
      on  k.CompanyCode  = b.CompanyCode
      and k.FiscalYear   = b.FiscalYear
      and k.FiscalPeriod = b.FiscalPeriod
      and k.LeaseContract = b.LeaseContract
{
  key b.CompanyCode, key b.FiscalYear, key b.FiscalPeriod, key b.LeaseContract,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      b.BalanceNow                                   as LeaseLiability,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      b.BalanceNow - b.BalanceAfter12                as CurrentRecalc,   " B(t) - B(t+12)
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      b.BalanceAfter12                               as NonCurrentRecalc,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      k.BookCurrent                                  as BookCurrent,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      k.BookCurrent - ( b.BalanceNow - b.BalanceAfter12 ) as DiffCurrent,
      case
        when abs( k.BookCurrent + k.BookNonCurrent - b.BalanceNow ) > 1000 then 'TOTAL'
        when b.RemainingMonths <= 12 and k.BookCurrent < b.BalanceNow - 1000  then 'SHORT'
        when abs( k.BookCurrent - b.PrevCurrentRecalc ) <= 1000
         and abs( k.BookCurrent - ( b.BalanceNow - b.BalanceAfter12 ) ) > 1000 then 'STALE'
        when abs( k.BookCurrent - b.Gross12 ) <= 1000
         and abs( k.BookCurrent - ( b.BalanceNow - b.BalanceAfter12 ) ) > 1000 then 'GROSS'
        else 'OK'
      end                                            as CheckCode,
      b.Currency
}

⑥ 소비 쿼리 — 화면이 읽는 뷰

서비스가 노출하는 뷰입니다. 화면의 조회조건과 서비스 필터가 같은 이름으로 이어지도록 필터 주석을 달고, 기본 정렬을 지정합니다. 점검 결과(정상·점검 필요)는 점검 코드에서 파생해 필터로 쓸 수 있게 둡니다.

" ─────────────────────────────────────────────
" ZC_LeaseCurQuery  화면이 읽는 소비 뷰
" 역할 : 조회조건 필터 · 기본 정렬 · 점검 결과 파생
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '리스부채 유동·비유동 구분 점검'
@Metadata.allowExtensions : true
@VDM.viewType : #CONSUMPTION
define view entity ZC_LeaseCurQuery
  as projection on ZC_LeaseCurCube
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key FiscalYear,
  @Consumption.filter.selectionType : #INTERVAL
  key FiscalPeriod,
  @Consumption.filter.selectionType : #SINGLE
  key LeaseContract,
  LeaseLiability, CurrentRecalc, NonCurrentRecalc,
  BookCurrent, DiffCurrent,
  CheckCode,
  case when CheckCode = 'OK' then 'OK' else 'CHECK' end as CheckStatus
}

⑦ 권한 — DCL

리스부채는 회사 단위 숫자라 회사코드 권한을 겁니다. 요약 수치가 전체 합계를 보여 주면 권한 밖 회사의 숫자가 합계 차이로 드러날 수 있으므로, 요약과 표가 같은 권한 정의를 거치게 합니다.

" ─────────────────────────────────────────────
" ZC_LeaseCurQuery  DCL
" 역할 : 회사코드 권한 (회계 전표 조회 권한 객체와 연결)
" ─────────────────────────────────────────────
@EndUserText.label : '리스부채 점검 — 회사코드 권한'
@MappingRole : true
define role ZC_LeaseCurQuery {
  grant select on ZC_LeaseCurQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

화면이 바라보는 OData V2 서비스를 게시합니다. 서비스 이름과 경로는 소문자로 통일하고, 엔티티 이름은 화면의 바인딩과 맞춥니다. 게시한 뒤에는 화면 설정 파일의 서비스 주소만 운영 서비스로 바꾸면 됩니다.

" ─────────────────────────────────────────────
" 서비스 정의와 바인딩
" ─────────────────────────────────────────────
@EndUserText.label : '리스부채 유동·비유동 구분 점검 — 서비스'
define service ZUI_LeaseCur {
  expose ZC_LeaseCurQuery as ContractSet;
  expose ZC_LeaseSchedQuery as SchedSet;
  expose ZC_LeaseMonthQuery as MonthSet;
  expose ZC_LeaseReconQuery as ReconSet;
}

" 서비스 바인딩 : 유형 OData V2 - UI, 이름 ZUI_LEASECUR_O2
" 게시 후 서비스 활성화 확인(게이트웨이 서비스 관리) → 화면 설정의 서비스 주소 교체

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

리스 계약은 대개 수백에서 수천 건이고 지급 일정은 그 수십 배지만, 계약·월 큐브는 보고월을 필수 조건으로 두면 한 번에 읽는 양이 작습니다. 회계연도를 필수로 두어 전체 기간을 한 번에 읽지 않게 하고, 지급 일정은 계약·월을 지정했을 때만 펼쳐 읽습니다. 장부 금액은 저널 항목을 회사코드·원장·회계연도 순의 키로 읽어 먼저 집계한 뒤 계약 조건과 만납니다. 월마감 직후 한꺼번에 조회가 몰리면 큐브 결과를 월 단위로 저장해 두는 방법도 있습니다.

자주 묻는 질문

도입 상담과 데모에서 나온 질문 25개를 네 묶음으로 적었습니다.

판정과 해석

금액과 산식

데이터와 연계

범위와 도입