리스 손익 범주 점검 — IFRS 18 에서 리스 손익 구성요소가 영업·투자·재무 범주 중 맞는 곳에 놓였는지 구성요소별로 다시 구해 장부와 맞춰 보는 화면

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서의 수익과 비용을 영업·투자·재무·법인세·중단영업 범주로 나누어 보이도록 요구합니다. 리스 계약은 이 구분에서 까다로운 자리입니다. 같은 리스 하나에서 사용권자산 상각, 리스부채 이자비용, 단기·소액자산 리스 비용, 변동리스료, 전대리스 수익, 판매후리스와 리스변경 손익이 한꺼번에 나오는데, 구성요소마다 놓일 범주가 다르기 때문입니다. 특히 리스부채 이자비용은 재무범주를 기준으로 보고, 사용권자산 상각과 단기·소액자산 리스·변동리스료는 영업범주를 기준으로 보며, 전대리스 금융수익은 회사의 주된 사업활동에 따라 영업범주 또는 투자범주를 기준으로 삼습니다.

지금은 이 질문에 답하려면 계정별 개별 항목 조회와 리스 계약 목록 엑셀, 구성요소를 적어 둔 별도 자료를 번갈아 열어 손익 건마다 손으로 맞춥니다. 이 앱은 그 자료들을 한 화면에 붙여, 손익 건마다 구성요소와 주된 사업활동으로 다시 구한 범주(재계산 범주)를 장부에 기록된 범주와 나란히 놓고, 다른 건과 판단 근거가 비어 있는 건을 점검 코드로 가려 줍니다. 기준서 도입 시기는 IFRS 18 이 2027-01-01 이후 개시하는 회계연도부터 적용이며 조기적용을 허용하고 비교기간은 재작성한다는 점까지만 확정 사실로 쓰고, 그 밖의 경과규정과 범주별 손익의 범위는 원문 확인 필요로 둡니다.

리스 손익의 범주는 계약이 아니라 구성요소로 갈린다

같은 리스 계약이어도 손익 한 줄 한 줄의 범주는 같지 않습니다. 건물 임차 계약 하나만 봐도 사용권자산 상각은 영업범주에, 리스부채에 쌓이는 이자비용은 재무범주에 놓이는 쪽이 이 화면의 점검 기준입니다. 계약 단위로 범주를 한 번에 정해 두면 이자비용이 영업범주로 섞여 들어가도 합계만 봐서는 보이지 않습니다. 이 앱은 손익 건마다 구성요소 코드를 붙여 재계산하기 때문에 그 질문에 건 단위로 답합니다. 판정 순서는 화면이 쓰는 점검 규칙이며, 각 범주에 들어가는 손익의 범위는 기준서 원문 확인 필요로 남겨 둡니다.

전대리스 금융수익은 회사의 성격에 따라 갈린다

전대리스에서 생기는 금융수익은 구성요소 코드만으로 범주가 정해지지 않습니다. 리스 제공이 주된 사업활동인 회사라면 영업범주가 점검 기준이 되고, 그렇지 않은 회사라면 투자범주가 점검 기준입니다. 이 앱은 회사마다 주된 사업활동이 리스 제공인지를 입력값으로 받아 건마다 다시 구합니다. 그 여부를 판단하는 일과 판단 요건은 회사의 몫이고 원문 확인 필요이며, 화면은 입력값에 따른 점검 결과를 보여 줄 뿐입니다. 이 값이 바뀌면 같은 금액의 점검 결과도 함께 바뀌므로, 입력값을 누가 언제 정했는지가 곧 점검 결과의 근거가 됩니다.

장부 범주와 전기 범주를 함께 봐야 한다

재계산 범주가 장부와 같아도 걸리는 일이 하나 더 있습니다. 계약 조건 변경이 없는데 전기와 다른 범주에 기록된 경우입니다. 비교기간 정보와 이어져야 하는 자리라서, 이 앱은 장부 범주와 전기 범주를 같은 줄에 두고 계약 조건 변경 여부를 함께 보여 줍니다. 계약 조건이 바뀐 건은 범주가 달라지는 것이 자연스러우므로 걸리지 않고, 변경 없이 달라진 건만 점검 코드 K03 으로 올라옵니다. 도입 전에 미리 이동 건을 한 번 가려 두면 회의가 “어느 건이 움직였나” 찾는 일에서 “움직인 이유가 있나” 확인하는 일로 바뀝니다.

구성요소가 비어 있으면 판단을 보류한다

점검 도구가 제일 조심해야 하는 일은 근거 없이 범주를 단정하는 것입니다. 구성요소가 아직 등록되지 않은 손익은 범주를 판단할 기준이 없으므로 이 앱은 임의로 범주를 채우지 않고 “확인 필요”로 표시한 뒤 그 금액을 판정 보류로 따로 모읍니다. 회사가 구성요소를 먼저 정하고 다시 조회하면 그 건의 재계산 범주가 채워지고 보류 금액은 줄어듭니다. 대사식에도 보류 금액이 들어 있어서, 판단을 미룬 금액까지 합쳐 순손익과 맞는지를 매번 검산합니다.

사용 방법

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

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

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

정합성 대사 여섯 식과 참고 대사 한 식이 모두 차이 0 입니다. 점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 검증용 샘플 데이터에는 점검 필요 10건(K01 2건 · K02 2건 · K03 2건 · K04 2건 · K05 2건)과 확인 필요 1건(K09)이 들어 있고, 이것은 대사 차이 건수 0 과 별개입니다. 점검 코드가 올라오는 것은 화면이 제대로 일하고 있다는 뜻이고, 대사가 어긋나는 것은 화면이 틀렸다는 뜻이므로 둘을 섞어 세지 않습니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤과 sap_horizon 테마만 씁니다. 데이터는 OData V2 서비스 하나에서 읽고, 화면은 서비스 주소를 코드에 적지 않고 앱 설정(manifest)에 선언한 상대 경로만 바라봅니다. 조회조건은 모두 필터로 서비스에 보내고, 정렬·건수·페이징도 서비스가 처리합니다.

실행 화면

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

처음 열면 판정 결과가 먼저 보인다

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

맨 위 파란 안내는 이 화면이 점검 도구이며 최종 판단은 회사와 감사인이 한다는 점을 먼저 밝힙니다. 요약의 ‘41’은 점검한 리스 손익 건수, ‘10’은 점검 필요 항목, ‘1’은 확인 필요 항목이고, 범주 이동 필요 금액은 517.0 백만 원, 재무범주로 놓인 장부 손익은 절대값으로 755.0 백만 원, 정합성 대사 차이는 0건으로 보입니다. 아래 표는 리스 계약 15건을 한 줄씩 보여 주며 순손익 합계와 장부 범주별 금액, 재계산 범주별 금액이 나란히 놓입니다. 조회 전에도 조회조건과 표 틀이 먼저 서 있어서 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 바로 압니다.

손익 건마다 점검하고, 조건으로 좁힌다

계약 단위 판정에서 의심 가는 곳이 보이면 건별 탭으로 내려가 어떤 건의 범주가 다른지 확인합니다. 점검 결과나 점검 코드로 좁히면 같은 사유의 건만 남습니다.

탭을 손익 건별 점검으로 옮기면 손익 41건이 한 줄씩 나옵니다. 건마다 리스 계약, 자산 유형, 회사의 주된 사업활동 여부, 손익 구성요소, 손익 금액, 장부 범주, 전기 범주, 계약 조건 변경 여부, 재계산 범주를 한 줄에서 견줍니다. 금액은 비용이 음수, 수익이 양수인 부호 있는 원 단위이고, 화면 위쪽 요약만 백만 원 단위로 줄여 보여 줍니다.

조회조건의 점검 결과를 “점검 필요”로 고르고 조회하면 손익 건별 점검 탭에 10건만 남고, 요약의 점검한 건수도 10, 이동 필요 금액은 517.0 백만 원으로 같은 조건에서 다시 계산됩니다. 조회 버튼은 입력칸들의 가장 오른쪽에 있고, 입력칸에서 Enter 키를 눌러도 같은 조회가 됩니다. 회사 · 손익 구성요소 · 장부 범주 · 기록일 · 계약명 · 점검 코드도 같은 방식으로 좁힙니다.

행을 눌러 근거를 본다

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

건별 점검 표에서 한 줄을 누르면 손익 건 상세가 열립니다. 위쪽에는 자산 유형 · 회사의 주된 사업활동이 리스 제공인지 여부 · 손익 구성요소 · 계약 조건 변경 · 전기 범주 · 장부 범주 · 재계산 범주 · 기록일과 점검 결과가 모입니다. 그 아래에는 점검 근거 문장과, 같은 계약에 속한 다른 손익 건의 장부 범주 · 재계산 범주 · 이동 필요 금액 비교 표가 이어져 한 계약의 구성요소를 한꺼번에 읽을 수 있습니다.

구성요소와 대사로 합계를 확인한다

건 단위 점검이 끝나면 구성요소별 합계로 어느 항목에서 범주가 갈리는지 보고, 대사 결과로 합산 과정의 합계가 맞는지 확인합니다.

구성요소별 합계 탭은 회사마다 사용권자산 상각 · 리스부채 이자비용 · 단기리스 · 소액자산 리스 · 변동리스료 · 전대리스 수익 · 판매후리스 처분손익 · 리스변경 손익으로 묶어 장부 범주 금액과 재계산 범주 금액을 나란히 보여 줍니다. 예를 들어 1000 회사의 리스부채 이자비용은 순손익 -506,000,000원 가운데 장부에서는 재무범주가 -366,000,000원이고 재계산하면 전액이 재무범주라는 점이 한눈에 보입니다.

대사 결과 탭에는 대사 번호 · 구분 · 대사 항목 · 좌변 · 우변 · 검사 건수 · 차이 건수 · 최대 차이 · 대사식이 한 줄씩 나옵니다. 정합성 대사(INT) 여섯 개와 참고 대사(REF) 한 개가 모두 차이 건수 0 이고, 좌변과 우변이 같은 금액으로 놓여 있어 합계가 맞는다는 것을 숫자로 바로 확인합니다. 요약의 대사 차이 건수 0 은 이 탭의 정합성 대사 차이 건수를 더한 값입니다.

화면 뒤에서 일어나는 일

손익 건마다 구성요소와 회사의 주된 사업활동으로 재계산 범주를 구하고 장부 범주·전기 범주와 견주는 순서와 판정 결과는 아래와 같습니다. 이 순서는 화면의 점검 규칙입니다.

처리 순서는 네 단계입니다. 먼저 손익 건마다 재계산 범주를 구해 점검 코드를 붙이고, 같은 건을 계약 단위와 구성요소 단위로 각각 합산하며, 마지막으로 대사 일곱 식으로 합계를 검산합니다. 대사식은 건별 합계와 계약별 합계, 장부 범주 세 종의 합계, 재계산 범주 세 종과 판정 보류의 합계, 구성요소별 합계, 이동 필요 금액, 점검 필요 건수가 서로 같은지를 확인하는 식이고, 마지막 한 식은 재무범주의 장부와 재계산 차액이 이동 필요 순액과 같은지를 보는 참고 대사입니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

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

파일 구성

앱 폴더/
├─ index.html · readme.html · Component.js · manifest.json
├─ controller/   화면 제어 2개
├─ view/         본 화면 · 상세 창
├─ model/        표시 형식 · 오류 안내
├─ css/ · i18n/  스타일 · 한글 문구
├─ odata/        서비스 정의와 서비스 로직, 데이터 파일 5개
└─ media/        소개 영상 · 표지 이미지

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

요구사항 매핑표

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 이미 있습니다. 이 앱은 그 도구와 경쟁하지 않고 범주 점검이라는 좁은 질문에 답하는 자리에 놓입니다. 계정 잔액을 자유롭게 잘라 보는 일은 표준 분석 도구가 잘하고, 구성요소와 주된 사업활동으로 재계산한 범주를 장부와 견줘 다른 건에 코드를 붙이는 일은 이 앱이 맡습니다. 같은 CDS 뷰를 분석 도구와 이 앱이 함께 읽을 수 있게 만들어 두면 두 화면의 숫자가 어긋날 자리가 줄어듭니다. 표준 CDS 뷰의 정확한 이름과 필드는 대상 릴리스에서 확인 필요이며, 아래 코드는 원천 테이블 기준으로 적었습니다.

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

CDS 구성

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

뷰 레이어 구성

① 매핑 테이블 — 계정과 회사 설정

점검의 출발점은 계정이 어느 구성요소이고 장부에서 어느 범주로 기록되는지입니다. 이 값은 회사가 정하는 판단이라 코드에 박지 않고 테이블로 둡니다. 구성요소가 비어 있는 계정은 판정 보류(확인 필요)로 올라오므로, 테이블이 채워지는 만큼 보류가 줄어드는 구조입니다.

" ─────────────────────────────────────────────────────────────
" ZLCAT_ACCT  : 리스 손익 계정 → 구성요소 · 장부 범주 매핑
" 역할        : 점검 판정의 입력값. 회사가 관리한다.
" 이렇게 나눈 이유 : 계정 번호만으로는 구성요소를 알 수 없고,
"                   매핑을 바꿔도 뷰 코드를 고치지 않게 하려는 것이다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '리스 손익 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zlcat_acct {
  key client    : abap.clnt not null;
  key ktopl     : ktopl not null;          " 계정과목표
  key saknr     : saknr not null;          " 계정
  comp_type     : abap.char(1);            " A I S L V X F G M, 비면 미등록
  booked_cat    : abap.char(4);            " OPR INV FIN
  valid_from    : abap.dats;
}

@EndUserText.label : '회사별 리스 설정'
@AbapCatalog.deliveryClass : #C
define table zlcat_company {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  main_biz      : abap.char(1);            " Y : 리스 제공이 주된 사업활동
}

② 리스 계약 차원 뷰

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

" ─────────────────────────────────────────────────────────────
" ZI_LeaseCatLease : 리스 계약 차원
" 역할            : 계약 번호 · 계약명 · 자산 유형 한 곳 정의
" 이렇게 나눈 이유 : 건 뷰와 큐브가 같은 계약 이름을 쓰게 하려는 것이다.
"                   원천(마스터)은 고객사마다 달라 확인 필요.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '리스 계약 차원'
@ObjectModel.representativeKey: 'LeaseNo'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_LeaseCatLease
  as select from zlcat_lease_mst            " 고객사 리스 마스터(확인 필요)
{
  @ObjectModel.text.element: ['LeaseName']
  key lease_no    as LeaseNo,
  key bukrs       as CompanyCode,
      @Semantics.text: true
      lease_name  as LeaseName,
      asset_type  as AssetType             " RE VEH EQP ITE
}

③ 손익 건 기본 뷰 — ACDOCA 에서 건 단위로

손익 건 뷰는 원천 라인을 건드리지 않고 구성요소와 장부 범주만 붙입니다. 금액은 원천의 부호를 그대로 쓰므로 비용은 음수, 수익은 양수이고, 이 뷰의 합계는 계정 잔액 조회의 합계와 같아야 합니다. 합계가 어긋나면 이 뷰에서 라인이 빠졌거나 겹친 것입니다.

" ─────────────────────────────────────────────────────────────
" ZI_LeaseCatLine : 손익 건 기본 뷰
" 역할           : ACDOCA 라인 + 구성요소 + 장부 범주
" 이렇게 나눈 이유 : 이 뷰의 합계 = 표준 계정 잔액이어야 하므로
"                   라인을 가공하지 않고 속성만 붙인다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스 손익 건'
define view entity ZI_LeaseCatLine
  as select from acdoca as j
    inner join   zlcat_acct as m
      on  m.ktopl = 'INT'
      and m.saknr = j.racct
    left outer join zlcat_company as co
      on  co.bukrs = j.rbukrs
{
  key j.rbukrs                       as CompanyCode,
  key j.gjahr                        as FiscalYear,
  key j.belnr                        as DocNo,
  key j.docln                        as DocLine,
      j.racct                        as GlAccount,
      j.budat                        as PostDate,
      @Semantics.amount.currencyCode: 'Currency'
      j.hsl                          as LineAmt,
      j.rhcur                        as Currency,
      m.comp_type                    as CompType,
      m.booked_cat                   as BookedCat,
      coalesce(co.main_biz, 'N')     as MainBiz
}
where j.rldnr = '0L'
  and m.booked_cat <> ''
"  ※ 계정과목표 값 'INT' 는 예시이며 실제 값은 고객사 구성에 따른다.

④ 재계산 범주와 점검 코드

판정 규칙은 이 뷰 한 곳에만 둡니다. 리스부채 이자비용은 재무범주, 사용권자산 상각과 단기·소액·변동리스료는 영업범주, 전대리스 금융수익은 주된 사업활동에 따라 영업 또는 투자, 구성요소가 비면 보류입니다. 이 순서는 화면의 점검 규칙이며 범주별 손익의 범위는 원문 확인 필요입니다.

" ─────────────────────────────────────────────────────────────
" ZI_LeaseCatCheck : 재계산 범주 · 이동 필요 금액 · 점검 코드
" 역할            : 판정 규칙의 유일한 위치
" 이렇게 나눈 이유 : 화면 · 분석 · 서비스가 같은 규칙을 읽어야 숫자가 같다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스 손익 재계산 범주'
define view entity ZI_LeaseCatCheck
  as select from ZI_LeaseCatLine as l
{
  key l.CompanyCode, key l.FiscalYear, key l.DocNo, key l.DocLine,
      l.CompType, l.BookedCat, l.LineAmt, l.Currency,

      case l.CompType
        when 'I' then 'FIN'
        when 'U' then 'NONE'
        when 'F' then case l.MainBiz when 'Y' then 'OPR' else 'INV' end
        else 'OPR'
      end                                       as ExpectCat,

      case
        when l.CompType = 'U'                                   then 'K09'
        when l.CompType = 'I' and l.BookedCat <> 'FIN'          then 'K01'
        when l.CompType in ('A','S','L','V') and l.BookedCat <> 'OPR' then 'K02'
        when l.CompType = 'F' and l.BookedCat <>
             case l.MainBiz when 'Y' then 'OPR' else 'INV' end  then 'K04'
        when l.CompType in ('G','M','X') and l.BookedCat <> 'OPR' then 'K05'
        else 'K00'
      end                                       as CheckCode
}
"  K03(전기와 불일치)은 전기 범주를 붙인 별도 뷰에서 계산한다.

⑤ 계약 · 구성요소 합계 큐브

합산은 큐브 한 곳에서만 합니다. 계약별 판정과 구성요소별 합계가 모두 이 큐브의 행을 다시 묶은 값이라, 대사식의 좌변과 우변이 같은 원천에서 나옵니다.

" ─────────────────────────────────────────────────────────────
" ZI_LeaseCatCube : 계약 · 구성요소 단위 합계
" 역할           : 장부 3범주 · 재계산 3범주 · 판정 보류 · 건수
" 이렇게 나눈 이유 : 합산 위치를 하나로 해야 R01~R06 이 의미를 가진다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '리스 손익 범주 큐브'
define view entity ZI_LeaseCatCube
  as select from ZI_LeaseCatCheck as k
{
  key k.CompanyCode,
  key k.FiscalYear,
  key k.CompType,
      @Semantics.currencyCode: true
      k.Currency,
      @Aggregation.default: #SUM
      sum(k.LineAmt)                                                  as NetAmt,
      @Aggregation.default: #SUM
      sum(case k.BookedCat   when 'OPR' then k.LineAmt else 0 end)    as BookedOpr,
      @Aggregation.default: #SUM
      sum(case k.BookedCat   when 'INV' then k.LineAmt else 0 end)    as BookedInv,
      @Aggregation.default: #SUM
      sum(case k.BookedCat   when 'FIN' then k.LineAmt else 0 end)    as BookedFin,
      @Aggregation.default: #SUM
      sum(case k.ExpectCat   when 'OPR' then k.LineAmt else 0 end)    as ExpectOpr,
      @Aggregation.default: #SUM
      sum(case k.ExpectCat   when 'INV' then k.LineAmt else 0 end)    as ExpectInv,
      @Aggregation.default: #SUM
      sum(case k.ExpectCat   when 'FIN' then k.LineAmt else 0 end)    as ExpectFin,
      @Aggregation.default: #SUM
      sum(case k.ExpectCat   when 'NONE' then k.LineAmt else 0 end)   as HoldAmt,
      @Aggregation.default: #SUM
      sum(case when k.CheckCode between 'K01' and 'K05' then 1 else 0 end) as FlagCnt
}
group by k.CompanyCode, k.FiscalYear, k.CompType, k.Currency

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

쿼리는 화면이 쓰는 필터와 컬럼만 노출합니다. 회계연도는 필수 필터로 걸어 두어, 조회 한 번에 읽는 범위가 한 해로 묶이게 합니다.

" ─────────────────────────────────────────────────────────────
" ZC_LeaseCatQuery : 화면용 쿼리
" 역할            : 필터(@Consumption.filter)와 컬럼 노출
" 이렇게 나눈 이유 : 화면 요구가 바뀌어도 판정과 큐브를 건드리지 않는다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스 손익 범주 점검 쿼리'
@Analytics.query: true
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZC_LeaseCatQuery
  as select from ZI_LeaseCatCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key FiscalYear,
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false }
  key CompanyCode,
  @AnalyticsDetails.query.axis: #ROWS
  key CompType,
  @AnalyticsDetails.query.axis: #COLUMNS
  NetAmt, BookedOpr, BookedInv, BookedFin,
  ExpectOpr, ExpectInv, ExpectFin, HoldAmt, FlagCnt
}

⑦ 접근 제어(DCL)

합계를 읽는 자리에 권한을 겁니다. 다른 회사 숫자가 합계 뺄셈으로 드러나는 일을 막으려면 건 뷰와 큐브, 쿼리 모두에 같은 회사코드 권한이 걸려야 합니다.

" ─────────────────────────────────────────────────────────────
" ZC_LeaseCatQuery(DCL) : 회사코드 단위 접근 제어
" 역할                 : 권한 오브젝트 F_BKPF_BUK(회사코드)로 읽기 제한
" 이렇게 나눈 이유     : 큐브 · 건 뷰에도 같은 역할을 걸어 우회 경로를 없앤다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '리스 손익 범주 점검 접근 제어'
@MappingRole: true
define role ZC_LeaseCatQuery {
  grant select on ZC_LeaseCatQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

마지막으로 쿼리를 OData V2 서비스로 게시합니다. 게시 뒤에는 화면 설정(manifest)의 서비스 주소만 바꾸면 되고, 화면 코드는 그대로입니다.

" ─────────────────────────────────────────────────────────────
" ZUI_LeaseCat : 서비스 정의 + 바인딩
" 역할         : 쿼리를 OData V2 로 게시
" 이렇게 나눈 이유 : 서비스 이름과 버전을 화면과 분리해 교체 가능하게 한다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '리스 손익 범주 점검 서비스'
define service ZUI_LeaseCat {
  expose ZC_LeaseCatQuery as CompSet;
  expose ZI_LeaseCatLine  as LineSet;
}
"  서비스 바인딩: 이름 ZUI_LEASECAT_O2, 바인딩 유형 OData V2 - UI
"  게시 후 /IWFND/MAINT_SERVICE 에서 활성화 상태 확인

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

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

자주 묻는 질문

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

판정 규칙과 숫자

화면과 조작

표준 기능과의 관계

도입과 운영