SAP 현금성자산 이자수익 투자범주 점검 — IFRS 18, 예금·MMF·CMA에서 생긴 이자수익이 투자범주에 놓였는지 기대이자와 함께 장부와 맞춰본다

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

은행에 맡긴 돈에서 이자가 들어오면 월마감은 보통 “이자수익이 얼마인가”에서 끝납니다. IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호) 는 거기에 질문 하나를 더합니다. 현금및현금성자산에서 생긴 이자수익이 투자범주에 놓였는가. 손익을 영업·투자·재무·법인세·중단영업 다섯 범주로 나누어 표시하므로, 같은 이자라도 기타영업수익에 있으면 영업이익이 커지고 이자비용 순액에 섞여 있으면 재무범주가 달라집니다. 그래서 2027년 1월 1일 이후 개시하는 회계연도(조기 적용 허용, 비교기간 재작성)를 앞두고 이자수익 계정을 다시 묶는 회사가 늘고 있습니다.

지금 이 확인은 표준 화면 여러 개와 엑셀에 흩어져 있습니다. 계정별 개별 항목에서 이자 입금을 찾고, 은행 통보서에서 평균 잔액과 이율을 옮겨 적어 기대이자를 계산하고, 계정 묶음에 정해 둔 범주와 대조하고, 합계가 맞는지 따로 검산합니다. 어느 한 칸이라도 사람 손을 거치면 결산이 반복될수록 어긋난 곳을 찾는 데 시간이 듭니다. 표준에는 이 점검을 한 번에 보여 주는 화면이 없습니다.

이 앱은 그 자리를 메웁니다. 예금 항목마다 평균 잔액 × 연이율 × 기간 ÷ 12 로 기대이자를 다시 구해 장부 이자수익과 견주고, 이자수익이 놓여야 할 점검 기준 범주를 장부 범주와 견주며, 투자범주 구성과 범주별 합계가 서로 맞는지까지 한 화면에서 대사합니다. 화면은 신호를 줄 뿐이고, 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

이자는 들어왔는데 어느 범주인지는 계정이 정한 대로 흘러간다

가상의 두 회사(1000 · 2000)의 투자범주 장부 이자수익은 29.76억, 점검 기준 금액은 40.35억으로 10.59억 차이가 났습니다. 회사 1000 에서 9.50억, 회사 2000 에서 1.09억입니다. 합계만 보면 “투자 쪽 이자가 적다”로 끝났을 이야기가, 투자범주 구성 줄을 펼치자 세 줄로 풀립니다.

세 줄을 더하면 10.59억(5.8125 + 3.69 + 1.0875)으로 투자범주의 장부−점검 기준 차이와 정확히 같습니다. 이 이동은 이자수익의 총합을 바꾸지 않습니다. 범주별 장부 금액 합계도, 점검 기준 금액 합계도 항목 금액 합계 41.247억과 같고, 범주가 달라지면 영업 범주와 투자범주의 금액이 달라질 뿐입니다. 실제로 옮길지는 회사의 회계정책과 원문 문단, 감사인의 의견으로 정할 일입니다.

입금액이 맞는지는 잔액과 이율로 다시 계산해야 보인다

범주가 맞아도 금액이 틀릴 수 있습니다. 화면은 항목마다 평균 잔액 · 연이율 · 이자 산정 개월로 기대이자를 구하고, 장부 이자수익이 기대이자와 5퍼센트를 넘게 다르면 점검 필요(C03)로 띄웁니다. D은행 MMF 는 기대이자 3.60억에 장부 3.18억으로 0.42억(11.7퍼센트) 적고, H은행 MMF 는 기대이자 1.575억에 장부 1.41억으로 0.165억(10.5퍼센트) 적습니다. A은행 정기예금도 기대이자보다 180만 원 적지만 0.24퍼센트라 기준 안이어서 정상으로 둡니다. 5퍼센트는 점검용 가정이며 회사의 중요성 기준에 맞춰 조정합니다. 중도 해지한 예금은 해지월까지의 개월 수(6개월)로 계산하므로 해지한 달 이후의 이자를 기대하지 않습니다.

주된 사업활동 단위는 숫자가 아니라 정책으로 가려진다

자금운용센터처럼 이자수익이 그 단위의 주된 사업활동에 해당할 수 있는 경우에는 영업범주가 될 수 있는지 회사 정책으로 가려야 합니다. 화면은 이런 단위를 투자범주로도 영업범주로도 단정하지 않고 확인 필요(C09)로 따로 세웁니다. 샘플의 자금운용센터 보통예금 이자 0.90억이 그 경우입니다. 또 하나 화면이 보여 주는 값이 현금성자산 요건입니다. 취득일부터 만기 3개월 이내인지(K-IFRS 제1007호)를 Y/N 으로 표시하되, 요건을 채우지 않는 C은행 6개월 정기예금의 이자도 투자범주 이자수익으로 보아 정상으로 둡니다. 요건에 따른 투자범주 처리의 세부는 원문 확인이 필요합니다.

합계가 맞아도 어느 상품이 빠졌는지는 구성 줄에서 보인다

투자범주 구성 탭은 보통예금 · 정기예금 · MMF · CMA · 외화예금 줄로 장부상 금액과 점검 기준 금액을 나란히 둡니다. 회사 1000 에서는 MMF 가 −5.8125억, 외화예금이 −3.69억이고 나머지 줄은 0 입니다. 합계 줄의 차이(−9.5025억)가 어느 예금 종류 때문인지가 바로 읽히므로 합계가 다르다는 사실보다 어디가 다른지를 먼저 이야기할 수 있습니다. 각 행을 누르면 항목 금액을 이루는 분기별 전표 라인이 열리고 합계가 항목 금액과 같은지 그 자리에서 확인합니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도는 필수(기본 2026)이고 회사 · 예금 종류 · 장부 범주 · 점검 기준 범주 · 최근 전기일 · 항목명 · 점검 코드 · 점검 결과는 선택이며, 비워 두면 전체입니다.
2. 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 화면을 처음 열면 기본 조건으로 자동 조회됩니다.
3. 위쪽 요약에서 점검한 항목 수 · 점검 기준 투자범주 항목 · 점검 필요 · 확인 필요 건수와 금액 차이, 정합성 대사 차이 건수를 확인합니다.
4. 이자수익 범주 점검 · 범주별 합계 · 투자범주 구성 · 대사 결과 네 탭을 오가며 근거를 따라갑니다.
5. 항목 표의 행을 눌러 상세를 열고 기대이자 산식의 입력값과 전표 라인을 확인합니다.
6. 보고 있는 탭의 조회 결과를 CSV 내려받기 버튼으로 저장합니다.

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

화면이 만든 숫자는 아홉 가지 대사로 스스로 검산합니다. 앞의 일곱 건은 화면 안의 숫자끼리 맞는지 보는 정합성 대사라 차이가 0 이어야 하고, 뒤의 두 건은 장부와 기대이자 · 점검 기준의 차이를 일부러 세는 공시 점검 대사라 차이가 곧 찾은 대상입니다. 둘을 섞어 적지 않습니다.

공시 점검 대사의 두 건은 의도한 점검 대상입니다. 기대이자 차이 2건은 D은행 · H은행 MMF 이고, 투자범주 차이 2건은 회사 1000 (−9.5025억)과 회사 2000 (−1.0875억)입니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다. 자료는 가상의 두 회사(1000 · 2000)로 만든 검증용이며 실제 회사의 계정체계나 금액이 아닙니다.

처음 열었을 때

회계연도 2026 으로 열면 기본 조건으로 바로 조회됩니다. 위쪽에는 요약 지표 여섯 개, 아래에는 이자수익 범주 점검 탭의 항목 표가 놓입니다.

화면을 열면 기본 조건으로 바로 조회됩니다. 점검 결과 칸은 정상·점검 필요·확인 필요 세 색으로 갈라 보이므로 표를 위에서 아래로 읽지 않아도 다른 행이 눈에 들어옵니다. 숫자는 모두 가상의 두 회사로 만든 검증용 자료입니다.

점검 결과 좁혀 보기

점검 결과 또는 점검 코드를 골라 조회하면 다섯 건(C01 두 건 · C02 한 건 · C03 두 건)만 남습니다. 확인 필요 한 건(C09)은 점검 결과를 확인 필요로 고르면 따로 모입니다.

좁히는 일은 서비스에 $filter 로 전달됩니다. 화면이 받은 전체를 걸러 보여 주는 것이 아니라 서비스가 조건에 맞는 줄만 내려 주므로 항목이 수만 건으로 늘어도 같은 방식으로 동작합니다.

범주와 구성으로 근거 따라가기

항목 표에서 본 판정은 범주별 합계 탭에서 규모로, 투자범주 구성 탭에서 예금 종류별 원인으로 이어집니다. 두 탭은 같은 판정 결과를 다른 단위로 모은 것이라 합계가 어긋날 자리가 없습니다.

범주를 옮겨도 합계는 바뀌지 않습니다. 한 범주에서 빠진 금액이 다른 범주로 들어갈 뿐이므로 차이 열을 모두 더하면 0 이 됩니다. 이 성질은 뒤의 대사 결과에서 다시 검산됩니다.

합계 줄의 차이가 곧 투자범주의 장부−점검 기준 차이입니다. 어느 예금 종류에서 이자수익이 빠졌는지가 한눈에 보이므로 합계가 다르다는 사실보다 어디가 다른지를 먼저 이야기할 수 있습니다.

한 항목의 근거까지

항목 표의 행을 누르면 상세 창이 열립니다. 판정이 어떤 입력값에서 나왔는지 의심스러울 때 다른 화면으로 옮겨 가지 않고 그 자리에서 확인합니다.

숫자를 의심할 때 다른 화면으로 옮기지 않아도 됩니다. 항목 금액과 전표 라인 합계가 같은지도 이 창에서 바로 보이고, 표준 화면에서 더 보려면 FAGLL03 에 같은 조건을 넣으면 됩니다.

대사 결과

마지막 탭은 화면이 만든 숫자를 스스로 검산한 결과입니다. 정합성 대사와 공시 점검 대사를 구분 열로 나눠 놓았습니다.

두 대사는 뜻이 다릅니다. 정합성 대사는 화면이 만든 숫자가 서로 맞는지 보는 것이라 차이가 0 이어야 하고, 공시 점검 대사는 장부와 점검 기준의 차이를 세는 것이라 차이가 곧 찾은 대상입니다. 둘을 섞어 적으면 어느 쪽이 오류인지 헷갈리므로 따로 기록합니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터로 바꿔 서비스에 전달하고, 서비스가 항목마다 기대이자와 점검 기준 범주를 계산해 판정까지 붙여 돌려줍니다. 화면은 받은 값을 그리기만 합니다. 처리 순서는 아래와 같습니다.

1. 항목별로 장부 이자수익(ACDOCA 에서 합산한 값), 평균 잔액, 연이율, 이자 산정 개월을 모읍니다.
2. 기대이자 = 평균 잔액 × 연이율 ÷ 100 × 개월 ÷ 12 를 구하고 장부 − 기대이자 차이를 만듭니다.
3. 주된 사업활동으로 지정된 단위이면 점검 기준 범주를 확인 필요로, 그렇지 않으면 투자범주로 둡니다.
4. 장부 범주와 점검 기준 범주를 견주고, 같은 범주 안에서는 기대이자 차이가 5퍼센트를 넘는지 봅니다.
5. 범주별 합계, 투자범주 구성 줄, 대사 아홉 건을 같은 판정 결과에서 다시 모읍니다.

대사식은 두 갈래입니다. 정합성 대사는 Σ범주 장부금액 = Σ항목 금액, Σ범주 점검기준금액 = Σ항목 금액, Σ(장부−점검 기준) = 0, 구성 합계 줄 = 범주별 투자 금액, Σ전표 라인 금액 = 항목 금액, 기대이자 재계산이고, 공시 점검 대사는 |장부 − 기대이자| > 기대이자 × 5퍼센트 인 항목 수와 투자범주 장부상 − 점검 기준 금액입니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건 칸은 화면 폭에 맞춰 여러 줄로 나뉘고, 요약 지표 카드도 줄바꿈됩니다. 항목 표는 열이 많아 가로로 스크롤하며, 나머지 세 탭은 열이 적은 목록 표라 좁은 화면에서도 그대로 읽힙니다. CSV 내려받기와 상세 창은 넓은 화면과 같게 동작합니다.

파일 구성

앱 폴더
├─ index.html · Component.js · manifest.json     앱 진입과 서비스 선언
├─ view/        Main.view.xml · DetailDialog.fragment.xml
├─ controller/  BaseController · Main.controller
├─ model/       formatter · ErrorHandler
├─ css/ · i18n/ 스타일 · 한국어 문구
├─ odata/       서비스 정의(메타데이터)와 조회 구현
├─ media/       소개 영상
└─ readme.html  앱 설명서

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 맡기고 끊기는 자리만 이어 붙입니다. 표준 화면의 세부 동작은 릴리스와 설정에 따라 다르므로 아래 내용은 확인이 필요한 일반론입니다.

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

T-code 별 연계 지점

운영 전환 시 기존 리포트를 없앨 필요는 없습니다. 법정 · 감사 대응의 근거는 표준 T-code 에 그대로 두고, 이 화면은 결산 전에 범주와 금액을 점검하는 용도로 나란히 씁니다.

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

표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office 는 임의 조합으로 합계를 보는 데 강합니다. 이 화면이 다루는 일은 합계를 보는 것이 아니라 항목마다 기대값과 점검 기준 범주를 다시 구해 견주는 것입니다. 그래서 표준 분석 도구가 읽는 같은 유니버설 저널 위에 판정 뷰를 한 겹 얹고, 결과를 점검 전용 화면으로 보여 줍니다. 표준 분석 도구에서 자유 조합으로 보다가 문제가 되는 계정을 찾으면 이 화면의 항목으로 내려와 근거를 확인하는 흐름입니다.

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

요구사항 매핑표

CDS 구성 — 운영에서는 이렇게 짓습니다

이 사례의 화면은 가상의 두 회사에서 만든 이자수익 항목 14건, 전표 라인 40건을 서비스에서 받아 보여 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 항목 집계와 판정을 CDS 로 내리고 화면은 결과만 받습니다. 아래는 그때 만드는 객체의 스케치입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 평균 잔액 · 연이율의 출처와 범주 판정 조건은 회사 정책에 따라 달라지므로 확인이 필요합니다.

뷰 레이어 구성

① 매핑 테이블 — 계정을 항목 · 예금 종류 · 범주로 묶는다

이 객체에서 결정되는 것은 “이 계정의 이자가 어느 예금의 것이고 지금 어느 범주에 놓여 있는가”입니다. 이 표가 틀리면 이후 모든 판정이 틀리므로 운영에서 가장 먼저 정리해야 합니다.

@EndUserText.label : '현금성자산 이자수익 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcashint_map {
  key client       : abap.clnt not null;
  key gl_account   : abap.char(10) not null;   // 이자수익 계정
  item_id          : abap.char(3);             // 항목 번호
  item_name        : abap.char(60);            // 항목명
  dep_name         : abap.char(30);            // 예금처
  dep_type         : abap.char(3);             // SAV · TD · MMF · CMA · FCY
  cash_eq          : abap.char(1);             // 현금성자산 요건 Y/N
  main_act         : abap.char(1);             // 주된 사업활동 지정 Y/N
  book_cat         : abap.char(3);             // 장부 범주 OPR · INV · FIN
}

② 차원 — 예금 항목의 속성

속성(예금처 · 종류 · 요건 · 지정)을 금액과 분리해 두면 속성이 바뀌어도 금액 집계 뷰는 건드리지 않습니다. 분석 쿼리에서 이 차원으로 필터와 그룹을 걸 수 있습니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'GLAccount'
@EndUserText.label : '예금 항목 차원'
define view entity ZI_CashIntDeposit
  as select from zcashint_map
{
  key gl_account  as GLAccount,
      item_id     as ItemId,
      item_name   as ItemName,
      dep_name    as DepName,
      dep_type    as DepType,
      cash_eq     as CashEq,
      main_act    as MainAct,
      book_cat    as BookCat
}

③ 큐브 — 표준 저널 라인을 항목 단위로 모은다

여기서 장부 이자수익이 정해지고, 자금 쪽 자료의 평균 잔액 · 이율 · 기간이 같은 키로 붙습니다. 집계 위치를 DB 로 내리는 객체이므로 운영 성능은 대부분 이 뷰에서 갈립니다. 표준 뷰 이름과 필드명은 확인이 필요합니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '이자수익 항목 큐브'
define view entity ZI_CashIntItem
  as select from I_JournalEntryItem as J
  inner join      ZI_CashIntDeposit as D on D.GLAccount = J.GLAccount
  association [0..1] to ZCASHINT_TERM as _Term               // 평균 잔액 · 이율 · 기간(자금 쪽 자료)
    on  _Term.company_code = J.CompanyCode
    and _Term.fiscal_year  = J.FiscalYear
    and _Term.item_id      = D.ItemId
{
  key J.CompanyCode,
  key J.FiscalYear,
  key D.ItemId,
      D.ItemName, D.DepName, D.DepType, D.CashEq, D.MainAct, D.BookCat,
      @Semantics.amount.currencyCode : 'Currency'
      sum( J.AmountInCompanyCodeCurrency )  as BookAmt,       // 장부 이자수익
      max( J.PostingDate )                  as LastPostDate,
      J.CompanyCodeCurrency                 as Currency,
      _Term
}
group by J.CompanyCode, J.FiscalYear, D.ItemId, D.ItemName, D.DepName, D.DepType,
         D.CashEq, D.MainAct, D.BookCat, J.CompanyCodeCurrency

④ 판정 뷰 — 기대이자 · 점검 기준 범주 · 점검 코드를 한 곳에서

판정 조건은 이 객체 한 곳에만 둡니다. 화면 · 대사 · 집계가 모두 이 뷰의 결과를 읽기 때문에 규칙이 바뀌어도 한 곳만 고치면 됩니다. 5퍼센트 기준과 주된 사업활동 처리는 회사 정책에 따라 달라지므로 확인이 필요합니다.

/* ─── ZC_CashIntExpected ───
   역할 : 기대이자를 다시 계산하고 점검 기준 범주와 점검 코드를 정한다.
   이렇게 나눈 이유 : 판정 규칙이 화면 · 집계 · 대사에 흩어지면 같은 항목이 다른 판정을 받는다. */
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '이자수익 판정'
define view entity ZC_CashIntExpected
  as select from ZI_CashIntItem
{
  key CompanyCode, key FiscalYear, key ItemId,
      ItemName, DepType, CashEq, MainAct, BookCat, BookAmt, LastPostDate,
      _Term.avg_balance                                                       as AvgBal,
      _Term.rate_pct                                                          as RatePct,
      _Term.months                                                            as Months,
      cast( _Term.avg_balance * _Term.rate_pct / 100 * _Term.months / 12
            as abap.dec(23,0) )                                               as ExpInt,
      case when MainAct = 'Y' then 'CNF'            // 주된 사업활동 지정 — 단정하지 않음
           else 'INV' end                                                     as ExpCat,
      case when MainAct = 'Y'                       then 'C09'
           when BookCat = 'OPR'                     then 'C01'   // 영업에 남은 이자수익
           when BookCat = 'FIN'                     then 'C02'   // 재무 순액에 섞인 이자수익
           when abs( BookAmt - _Term.avg_balance * _Term.rate_pct / 100 * _Term.months / 12 )
                > _Term.avg_balance * _Term.rate_pct / 100 * _Term.months / 12 * 0.05
                                                    then 'C03'   // 기대이자와 5퍼센트 초과 차이
           else 'C00' end                                                     as CheckCode
}

⑤ 범주별 합계 — 장부 금액과 점검 기준 금액을 같은 키에 붙인다

범주 이동은 합계를 바꾸지 않으므로 이 뷰의 장부 금액 합계와 점검 기준 금액 합계는 모두 항목 금액 합계와 같아야 합니다. 같지 않으면 대사가 잡습니다.

/* ─── ZC_CashIntCat ───
   역할 : 영업 · 투자 · 재무 · 확인 필요 범주의 장부 금액과 점검 기준 금액.
   이렇게 나눈 이유 : 두 금액을 다른 기준(BookCat · ExpCat)으로 묶어 같은 CatCode 키로 맞춘다. */
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '범주별 합계'
define view entity ZC_CashIntCat
  as select from ZC_CashIntExpected as E
{
  key E.CompanyCode, key E.FiscalYear,
  key E.BookCat                                          as CatCode,
      count(*)                                           as ItemCnt,
      sum( E.BookAmt )                                   as BookAmt,
      sum( case when E.ExpCat <> E.BookCat then 1 else 0 end ) as DiffCnt
}
group by E.CompanyCode, E.FiscalYear, E.BookCat
/* 점검 기준 금액은 같은 뷰를 ExpCat 으로 묶은 결과를 CatCode 키로 맞춰 붙인다 */

⑥ 투자범주 구성 — 예금 종류 줄별로 장부상 금액과 점검 기준 금액

합계 줄의 차이가 어느 예금 종류 때문인지를 설명하는 객체입니다. 구성 줄을 모두 더하면 합계 줄과 같아야 하며, 이 등식이 정합성 대사의 한 줄입니다.

/* ─── ZC_CashIntCompose ───
   역할 : 예금 종류 줄별로 투자범주 장부 금액과 점검 기준 금액을 둔다.
   이렇게 나눈 이유 : 합계가 다르다는 사실보다 어느 상품이 빠졌는지를 먼저 보이려고. */
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '투자범주 구성'
define view entity ZC_CashIntCompose
  as select from ZC_CashIntExpected as E
{
  key E.CompanyCode, key E.FiscalYear,
  key E.DepType,
      count(*)                                                          as ItemCnt,
      sum( case when E.BookCat = 'INV' then E.BookAmt else 0 end )       as BookInInv,
      sum( case when E.ExpCat  = 'INV' then E.BookAmt else 0 end )       as ExpInInv
}
group by E.CompanyCode, E.FiscalYear, E.DepType

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

화면이 직접 읽는 뷰입니다. 조회조건으로 쓸 필드와 표에서 보일 순서를 주석으로 정해 두면 서비스와 화면의 약속이 한 곳에 모입니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '이자수익 범주 점검'
@Search.searchable : true
@OData.publish : false
define view entity ZC_CashIntQuery
  as projection on ZC_CashIntExpected
{
      @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key FiscalYear,
      @Consumption.filter.selectionType : #SINGLE
  key CompanyCode,
  key ItemId,
      @Search.defaultSearchElement : true
      ItemName,
      @Consumption.filter.selectionType : #SINGLE
      DepType,
      CashEq, AvgBal, RatePct, ExpInt, BookAmt,
      BookAmt - ExpInt           as IntDiff,
      BookCat, ExpCat, LastPostDate,
      @Consumption.filter.selectionType : #SINGLE
      CheckCode
}

⑧ 액세스 제어 — 회사 코드 단위 조회 권한

권한은 드릴스루에만 걸면 합계로 새어 나갑니다. 소비 쿼리의 집계 단계에 걸어 회사 코드 권한이 없는 사용자는 해당 회사의 합계도 보지 못하게 합니다.

@EndUserText.label : '이자수익 점검 - 회사 코드 권한'
@MappingRole : true
define role ZC_CashIntQuery {
  grant select on ZC_CashIntQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

화면 필드와 원천

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않고 서비스만 연결하면 화면은 열려도 숫자가 의미를 갖지 못합니다.

운영 데이터로 갈 때

이자수익 항목은 계정 묶음 수만큼이라 항목 자체는 많지 않지만, 원천인 전표 라인은 수천만 건일 수 있습니다. 집계는 큐브(③)에서 DB 로 내려 항목 단위 수백~수천 행만 화면에 올리고, 회계연도를 필수 파라미터로 두어 읽는 범위를 좁히며, 전표 라인은 항목을 눌렀을 때만 그 항목의 라인으로 한정해 읽습니다. 계정 · 회사 코드 · 전기일에 대한 인덱스와 파티션은 운영 환경에서 실측으로 정해야 하며, 응답 시간 기준은 회사의 서비스 수준에 맞춰 따로 정합니다.

자주 묻는 질문

도입 상담에서 자주 받는 질문들을 세 묶음으로 나눠 적었습니다. 모두 26개입니다. 기준서의 세부 사항은 원문 확인이 필요하다고 표시했습니다.

범위와 기준

점검 규칙과 숫자

화면과 도입