SAP 이자·배당·법인세 현금흐름 분류 점검 — IAS 7, 이자·배당·법인세 납부가 회사 정책대로 영업·투자·재무활동에 나뉘어 담겼는지 다시 계산해 장부와 대조한다

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

결산 때 현금흐름표를 만드는 팀이 매번 부딪히는 질문은 비슷합니다. 이자와 배당을 영업·투자·재무 중 어디에 넣었는가, 지난 기간과 같은 방식인가, 자본화한 이자와 투자·재무활동에 대응되는 세금은 나뉘어 있는가. 지금은 이 답이 원장 개별 항목 조회(FAGLL03 · FBL3N) · 지급 전표 확인(FBL1N · F110) · 엑셀 대사표로 흩어져 있어, 어느 숫자가 맞는지 맞춰 보는 데 결산 일정이 쓰입니다.

이 화면은 관련 기준서 IAS 7 현금흐름표(K-IFRS 제1007호) 의 요구사항 — 이자와 배당의 수취·지급 현금흐름을 각각 구분해 공시하고 영업·투자·재무활동 중 하나로 기간마다 일관되게 분류하며, 자본화한 지급이자는 투자활동으로, 법인세 납부는 원칙적으로 영업활동으로 분류하되 투자·재무활동에 대응되는 부분이 식별되면 그 활동으로 분류 — 를 장부 처리와 맞춰 보는 점검용 화면입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

방식은 단순합니다. 명세 한 건마다 회사 정책에 따른 기대 분류 금액을 다시 만들고, 장부가 실제로 반영한 분류 금액과 비교합니다. 차이가 나거나 직전 기간과 분류가 달라졌으면 점검 필요로 표시하고 이유를 적습니다. 회계 처리를 확정하지 않으며, 최종 판단은 회사와 감사인이 합니다.

이자와 배당은 한 번 정한 분류가 기간마다 지켜지는지가 문제다

분류를 영업으로 할지 투자·재무로 할지는 회사가 정합니다. 어려운 것은 정한 뒤입니다 — 기간마다 같은 방식으로 담겼는지는 계정 하나만 보아서는 알 수 없습니다. 이 화면은 명세마다 정책 분류와 직전 기간 분류를 같은 줄에 놓고, 둘이 다르면 K04 로 표시합니다. 이 자료에서는 9월 배당 수취 4건이 직전 기간에는 영업활동이었다가 투자활동으로 바뀐 것으로 잡힙니다. 금액은 맞아도 변경 사유와 비교정보 공시 여부는 사람이 확인해야 하기 때문입니다.

자본화한 이자는 영업이 아니라 투자로 갈라져야 한다

이자 지급 전표 한 장에는 비용으로 처리한 몫과 자산 원가에 산입한 몫이 함께 들어 있을 수 있습니다. 자본화분은 투자활동으로 나뉘어야 하는데, 전표 단위로 보면 한 줄로 합쳐져 재무활동에 통째로 올라가기 쉽습니다. 이 화면은 명세에 분리 대상 금액과 활동을 달고, 장부의 투자활동 금액이 그 금액과 다르면 K02 를 띄웁니다. 자본화 대상인지의 판정은 회사 몫이고, 화면은 그 판정이 장부에 반영됐는지만 봅니다.

법인세는 총액만 보면 대응 활동이 묻힌다

법인세 납부는 원칙적으로 영업활동이지만, 투자·재무활동에 대응되는 부분이 식별되면 그 활동으로 분류하고 총 납부액은 따로 공시합니다. 총액만 보면 이 구분이 보이지 않습니다. 식별된 몫이 있는데 장부의 해당 활동 금액이 그와 다르면 K03 이 뜹니다. 식별 가능 여부 역시 회사 판단이며, 화면은 판단 결과의 반영만 확인합니다.

사용 방법

1. 조회조건을 넣습니다. 기준 연월(6자리)은 필수이고, 현금흐름 항목 · 점검 코드 · 점검 결과는 고르지 않으면 걸리지 않습니다.
2. 조회 버튼을 누르거나 입력 칸에서 Enter 를 칩니다. 화면을 열면 기본 기준 연월로 한 번 자동 조회합니다.
3. 요약을 확인합니다. 명세 건수 · 금액 합계 · 재계산 영업·투자·재무활동 금액 · 점검 필요 건수 · 정합성 대사 차이 건수가 한 줄에 서 있습니다.
4. 탭을 옮겨 갑니다. 현금흐름 명세 → 항목별 집계 → 현금흐름표 표시 대사 → 대사 결과 순서가 읽는 순서입니다.
5. 행을 눌러 상세를 엽니다. 장부 분류 · 재계산 금액 · 점검 내용과 그 명세가 반영되는 현금흐름표 줄이 열립니다.
6. CSV 로 내려받습니다. 선택한 탭의 현재 조건 결과가 UTF-8 CSV 로 나옵니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 만드는 쪽에서 대사식을 먼저 세우고 두 달치 전체를 대상으로 돌린 결과입니다.

대사 5종 115건을 전수로 돌려 차이 0 입니다. 점검용 예외는 이와 별도로 8월 3건(K01 1 · K02 1 · K03 1), 9월 7건(K01 1 · K02 1 · K03 1 · K04 4)을 일부러 심어 두었습니다. 점검용 예외는 대사 차이와 별도로 집계합니다 — 화면이 걸러 내야 하는 건이 실제로 걸리는지를 보기 위한 것입니다.

무엇으로 만들었나

앱 정보는 아래와 같습니다.

실행 화면

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

처음 열었을 때

조회조건 · 요약 · 탭 · 표가 한 화면에 쌓입니다. 기본 기준 연월로 한 번 조회하므로 열자마자 숫자가 보입니다.

위쪽 안내 줄은 이 화면이 무엇을 점검하는지 적어 둔 것이고, 조회조건은 기준 연월(필수) · 현금흐름 항목 · 점검 코드 · 점검 결과입니다. 요약은 명세 20건, 금액 합계 2,874,000,000원, 재계산 영업 1,068,000,000 · 투자 637,000,000 · 재무 1,169,000,000원, 점검 필요 7건, 정합성 대사 차이 0건입니다. 화면을 열면 기본 기준 연월(202609)로 한 번 조회하고, 표는 전기일 순서로 이자 수취 · 배당 수취 · 이자 지급 명세를 보여 줍니다.

항목별로 묶고 현금흐름표 줄과 맞춘다

명세를 항목별로 묶어 보고, 표시 줄 금액을 재계산 금액과 맞춰 봅니다.

항목마다 건수와 금액, 점검 필요 건수가 한 줄씩 서고, 명세 탭의 합계와 같은 숫자여야 합니다(대사 R01). 항목별로 점검 필요가 몇 건인지 먼저 보고, 많은 항목부터 명세로 내려가면 확인할 자리를 빨리 좁힐 수 있습니다.

표시 줄은 항목과 활동의 조합입니다(예: 투자활동 — 배당 수취). 줄마다 표시 금액 − 재계산 금액이 0 이면 정상이고, 0 이 아니면 점검 필요로 표시됩니다. 표시 줄 합계가 장부 분류 금액 합계와 맞는지(R03)도 이 탭의 숫자로 확인합니다.

대사 결과와 점검 필요 건

숫자가 맞는지와 확인해야 할 건이 무엇인지를 따로 봅니다.

R01~R04 는 화면 숫자끼리 맞는지 보는 정합성 대사라 차이가 0 이어야 합니다. R05 · R06 은 장부와 정책을 비교하는 점검이라 차이 건이 곧 점검 필요 건입니다. 두 종류를 구분해 두었기 때문에 계산 오류와 장부 이슈가 섞이지 않습니다.

9월 기준으로 7건이 남고, 점검 코드(K01 · K02 · K03 · K04)별로 어떤 규칙에 걸렸는지 볼 수 있습니다. 점검 코드까지 고르면 같은 유형끼리 모아 처리할 수 있습니다.

명세에서 표시 줄까지

한 건이 어떻게 판정되고 어느 현금흐름표 줄에 올라가는지 끝까지 따라갑니다.

예로 배당 수취 명세(96,000,000원)는 장부가 투자활동에 반영했고 정책도 투자활동인데, 직전 기간 분류가 영업활동이라 K04(분류 정책 변경)로 잡혔습니다. 금액 자체는 맞고 표시 줄 차이도 0 이므로, 확인할 일은 변경 사유와 비교정보 공시입니다. 아래 표는 이 명세가 올라가는 표시 줄과 그 줄의 대사 결과입니다.

화면 뒤에서 일어나는 일

화면은 조회조건을 서비스에 조건으로 넘기고 돌려받은 결과를 보여 주기만 합니다. 판정과 대사는 서비스 쪽에 있습니다. 서비스는 명세 한 건마다 회사 정책 분류에 따른 기대 금액(재계산)을 만들고, 장부가 반영한 금액과 비교해 점검 코드를 붙인 뒤, 항목별 집계 · 표시 줄 대사 · 대사 결과를 같은 명세에서 다시 묶어 냅니다. 그래서 어느 탭을 보아도 숫자의 출처가 같습니다.

분류 점검 판정 규칙

위에서부터 먼저 걸리는 규칙을 점검 코드로 씁니다. 점검 필요는 확인할 자리를 가리키는 표시이며 회계 처리를 확정하지 않습니다.

산출·대사식

화면의 모든 소계와 합계는 아래 순서로 산출하고 대사합니다.

1. 기대 분류 금액(재계산) — 분리 대상 금액은 분리 대상 활동으로, 나머지 금액은 정책 분류 활동으로 배분합니다.
2. 분류 차이 금액 = Σ|장부 활동별 금액 − 재계산 활동별 금액| ÷ 2
3. 항목별 집계 = 같은 기간 · 같은 항목 명세의 합계
4. 표시 줄 금액 = 항목 · 활동별 장부 분류 금액 합계, 차이 = 표시 금액 − 재계산 금액

조회조건

조회조건은 모두 $filter 로 서비스에 전달됩니다. 전체를 고르면 그 조건은 필터에서 빠집니다.

결과 컬럼

좁은 화면에서 달라지는 것

표는 열이 많아 가로로 밀어 가며 봅니다. 이 글의 캡처는 폭 1440px 기준이며, 좁은 폭에서의 배치는 따로 캡처하지 않았습니다.

파일 구성

index.html · readme.html · Component.js · manifest.json
controller/   BaseController.js · Main.controller.js
view/         Main.view.xml · DetailDialog.fragment.xml
model/        formatter.js · ErrorHandler.js
css/ · i18n/  style.css · i18n_ko.properties
서비스 폴더/  metadata.xml · service.js · 조회 묶음별 데이터
media/        intro.mp4 · intro_poster.jpg

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 맡기고, 분류가 정책대로 담겼는지를 맞춰 보는 자리만 이어 붙이는 쪽으로 만들었습니다.

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

T-code 별 연계 지점

맞닿은 표준 T-code 마다 이 화면이 이어받는 데이터와 두 화면 숫자를 맞춰 보는 지점입니다. 오가는 방향은 두 가지입니다 — 이 화면 결과에서 표준 T-code 로 내려가 원천을 확인하고, 표준 화면의 전표 번호를 이 화면 명세에서 다시 봅니다. 법정·감사 대응은 표준에 그대로 남기며, 기존 리포트를 없애지 않고 함께 둡니다.

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

이 화면의 판정은 CDS 점검 큐브와 분석 쿼리로 내릴 수 있습니다. 쿼리는 표준 Fiori 분석 앱이나 Analysis for Office 가 그대로 띄울 수 있어, 이 화면과 같은 점검 결과를 그쪽에서도 볼 수 있습니다. 이 화면은 그 위에서 점검 필요 건을 좁혀 보고 명세에서 표시 줄까지 따라가는 자리를 맡습니다.

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

요구사항 매핑

CDS 구성

이 사례의 화면은 두 달치 샘플 명세를 서비스가 읽어 판정합니다. 데모라서 되는 일이고, 운영 데이터에서는 판정과 집계를 CDS 로 내립니다. 아래는 그때 만드는 객체를 레이어 순서로 정리한 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 분류 정책 매핑 테이블

리포트의 모든 판정이 이 표에서 갈립니다. 어느 계정이 어느 항목이고 항목을 어느 활동에 둘 것인지가 여기서 정해지므로 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 정책이 바뀌어도 과거 기간의 판정이 소급해서 달라지지 않게 하기 위해서입니다. 직전 기간 분류(K04)도 이 이력에서 나옵니다.

" ────────────────────────────────────────────────────────────────
"  Z_CFPOLICY — 계정 → 현금흐름 항목, 항목 → 정책 활동 (투명 테이블)
"  코드에 박지 않는 이유 : 정책은 바뀌고, 바뀔 때마다 개발자를
"  부르게 하면 점검 화면이 금방 낡는다. 유효기간으로 이력을 남겨
"  직전 기간 분류(K04)를 같은 표에서 꺼낸다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '현금흐름 분류 정책 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table z_cfpolicy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key ktopl      : ktopl not null;
  key saknr      : saknr not null;        " 계정
  key valid_from : abap.dats not null;
  flow_type      : abap.char(6);          " INTREC · DIVREC · INTPAY · DIVPAY · TAXPAY
  policy_cls     : abap.char(3);          " OPE 영업 · INV 투자 · FIN 재무
  valid_to       : abap.dats;
}

② 정책 차원 뷰

큐브에서 정책을 join 하는 자리를 한 곳으로 모읍니다. 활동 코드의 텍스트와 유효기간 판정(기준일에 유효한 행)을 여기서 끝내 두면, 아래 뷰들은 정책이 어떤 테이블에 있는지 몰라도 됩니다. 정책 테이블을 이력이 있는 다른 구조로 바꾸더라도 이 뷰만 고치면 됩니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfClassPolicy — 기준일에 유효한 정책 한 행
"  유효기간 판정을 이 뷰에서 끝내 아래 뷰가 이력 구조를 모르게 한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label : '현금흐름 분류 정책'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #CUSTOMIZING }
define view entity ZI_CfClassPolicy
  as select from z_cfpolicy as Pol
{
  key Pol.bukrs      as CompanyCode,
  key Pol.saknr      as GLAccount,
  key Pol.valid_from as ValidFrom,
      Pol.flow_type  as FlowType,
      Pol.policy_cls as PolicyCls,
      case Pol.policy_cls
        when 'OPE' then '영업활동'
        when 'INV' then '투자활동'
        when 'FIN' then '재무활동'
        else            '미정의'
      end            as PolicyClsText,
      Pol.valid_to   as ValidTo
}

③ 현금흐름 명세 뷰

ACDOCA 전표 줄에서 이자·배당·법인세 계정의 줄을 골라 한 건의 명세로 올립니다. 금액은 현금 계정 상대 줄의 절대값을 쓰고, 항목과 정책 분류는 ② 에서 가져옵니다. 이 뷰의 건수가 FAGLL03 에서 같은 계정 · 같은 기간으로 조회한 건수와 맞아야 하므로, 대사의 출발점입니다. 필드 이름은 릴리스마다 달라질 수 있어 View Browser(F2170)로 확인이 필요합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfFlow — 이자·배당·법인세 현금 줄을 명세 단위로
"  대사 : 이 뷰의 건수·합계 = FAGLL03 같은 계정·기간 조회 결과
"  확인 필요 : ACDOCA 필드명(racct · hsl · gkont)은 릴리스별로 확인
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label : '현금흐름 명세'
define view entity ZI_CfFlow
  as select from acdoca     as Acd
  inner join     ZI_CfClassPolicy as Pol
    on  Pol.CompanyCode = Acd.rbukrs
    and Pol.GLAccount   = Acd.racct
    and Pol.ValidFrom  <= Acd.budat
    and Pol.ValidTo    >= Acd.budat
{
  key Acd.rldnr                         as Ledger,
  key Acd.rbukrs                        as CompanyCode,
  key Acd.gjahr                         as FiscalYear,
  key Acd.belnr                         as AccountingDocument,
  key Acd.docln                         as LedgerItem,
      Acd.budat                         as PostingDate,
      substring( Acd.budat, 1, 6 )      as Period,
      Pol.FlowType                      as FlowType,
      Pol.PolicyCls                     as PolicyCls,
      @Semantics.amount.currencyCode: 'Currency'
      abs( Acd.hsl )                    as Amount,
      Acd.rhcur                         as Currency
}
where Acd.rldnr = '0L' 

④ 분리 판정 뷰

자본화한 이자와 투자·재무활동에 대응되는 세금의 분리 몫과 분리 활동을 정하는 자리입니다. 이 사례에서는 자산 원가 전표의 이자 산입분을 읽도록 스케치했지만, 어디서 식별할지는 고객사마다 다릅니다. 식별 원천이 확정되지 않으면 분리 몫이 0 으로만 읽혀 K02 · K03 이 비어 버리므로 운영 전환의 합의 항목입니다. 판정 자체는 회사가 하고, 이 뷰는 그 결과를 읽어 옵니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfSplit — 분리 대상 금액과 활동
"  원천은 고객사 결정 : 자산 원가 전표 · 확장 필드 · 세무 배분표 등
"  여기서는 확장 필드(활동 구분)를 읽는 것으로 스케치한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label : '분리 대상 금액'
define view entity ZI_CfSplit
  as select from ZI_CfFlow as Flw
{
  key Flw.Ledger, key Flw.CompanyCode, key Flw.FiscalYear,
  key Flw.AccountingDocument, key Flw.LedgerItem,
      @Semantics.amount.currencyCode: 'Currency'
      cast( 0 as abap.curr(23,2) )      as SplitAmount,   " 확인 필요 : 식별 원천에서 채운다
      cast( '' as abap.char(3) )        as SplitCls,
      Flw.Currency                      as Currency
}

⑤ 점검 큐브

이 화면의 심장입니다. 분리 몫을 분리 활동에, 나머지를 정책 활동에 배분한 기대 활동별 금액(재계산)을 만들고, 장부가 실제로 반영한 활동별 금액과 비교해 분류 차이와 점검 코드를 정합니다. 서비스 로직과 같은 순서(K02 → K03 → K01 → K04 → K00)로 먼저 걸리는 규칙을 씁니다. 판정을 화면이 아니라 이 뷰에서 한 번만 정의해 두어야 표준 Fiori 앱과 이 화면이 같은 결과를 냅니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfCheckCube — 재계산 vs 장부 분류, 점검 코드
"  순서 : K02 자본화 이자 → K03 대응 활동 세금 → K01 정책 불일치
"         → K04 직전 기간 분류와 다름 → K00 정상
"  분류 차이 = Σ|장부 − 재계산| ÷ 2
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '현금흐름 분류 점검 큐브'
define view entity ZI_CfCheckCube
  as select from ZI_CfFlow  as Flw
  left outer join ZI_CfSplit as Spl
    on  Spl.AccountingDocument = Flw.AccountingDocument
    and Spl.LedgerItem         = Flw.LedgerItem
{
  key Flw.CompanyCode, key Flw.AccountingDocument, key Flw.LedgerItem,
      Flw.Period, Flw.FlowType, Flw.PolicyCls,
      Spl.SplitCls,
      @DefaultAggregation: #SUM
      Flw.Amount,
      @DefaultAggregation: #SUM
      Spl.SplitAmount,
      // 재계산 : 분리 몫 → 분리 활동, 나머지 → 정책 활동
      case when Spl.SplitCls = 'INV' then Spl.SplitAmount else 0 end as ExpInvest,
      case when Flw.PolicyCls = 'OPE'
           then Flw.Amount - Spl.SplitAmount else 0 end              as ExpOperating,
      case
        when Flw.FlowType = 'INTPAY' and Spl.SplitAmount > 0 then 'K02'
        when Flw.FlowType = 'TAXPAY' and Spl.SplitAmount > 0 then 'K03'
        else 'K00'
      end                                                           as CheckCode
}

⑥ 분석 쿼리

큐브 위에 조회조건과 기본 정렬, 요약 측정값을 얹는 소비 뷰입니다. 이 쿼리를 Fiori 분석 앱이나 Analysis for Office 가 그대로 띄울 수 있어, 이 화면 없이도 같은 점검 결과를 볼 수 있습니다. 기준 연월은 필수 파라미터로 두어 전체 기간 조회로 성능이 무너지지 않게 합니다.

" ────────────────────────────────────────────────────────────────
"  ZC_CfClassCheckQuery — 점검 큐브 위의 조회 쿼리
"  기준 연월은 필수 : 기간 없이 열면 전체 기간을 훑게 된다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '현금흐름 분류 점검 쿼리'
@Analytics.query : true
@Metadata.ignorePropagatedAnnotations : true
define view entity ZC_CfClassCheckQuery
  with parameters
    @Consumption.derivation: { lookupEntity: 'I_CalendarMonth', resultElement: 'CalendarMonth' }
    P_Period : abap.char(6)
  as select from ZI_CfCheckCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key Period,
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter.selectionType: #MULTIPLE
  FlowType,
  @AnalyticsDetails.query.axis: #ROWS
  CheckCode,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Semantics.amount.currencyCode: 'Currency'
  Amount
}
where Period = $parameters.P_Period

⑦ 권한(DCL)

집계를 읽는 자리에 권한을 걸어야 합니다. 명세 상세에만 걸어 두면 항목별 집계와 합계 비교로 접근 제한 범위 밖의 금액이 드러납니다. 회사코드를 기본으로 걸고, 계정 범위가 필요하면 권한 오브젝트 값에 계정 범위를 추가합니다. 오브젝트와 필드는 고객사의 권한 설계에 따라 달라집니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CFCHECKCUBE — 점검 큐브 권한
"  명세에만 걸면 집계 합계로 새므로 큐브에 건다.
"  권한 오브젝트와 필드는 고객사 권한 설계에 맞춰 바꾼다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '점검 큐브 권한'
@MappingRole : true
define role ZI_CFCHECKCUBE {
  grant select on ZI_CfCheckCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리를 OData V2 서비스로 내보내는 마지막 단계입니다. 서비스 활성화(/IWFND/MAINT_SERVICE 또는 서비스 바인딩 게시) 뒤에, 화면 앱 설정의 서비스 주소를 이 바인딩 주소로 바꾸면 화면 코드는 그대로 운영 서비스를 씁니다. 활성화 전에 화면 설정을 바꾸면 빈 화면이 나오므로 순서를 지켜야 합니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_CfClassCheck — 서비스 정의 + 바인딩(OData V2 - UI)
"  전송 순서 : 테이블 → 뷰 → 쿼리 → DCL → 서비스 정의 → 바인딩 게시
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '현금흐름 분류 점검 서비스'
define service ZUI_CfClassCheck {
  expose ZC_CfClassCheckQuery as ClassCheck;
}

" 서비스 바인딩(ADT 에서 생성)
"   Binding Type : OData V2 - UI
"   Service Definition : ZUI_CfClassCheck
"   게시 후 : 화면 앱 설정의 서비스 주소를 게시된 주소로 교체

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

• 집계 위치 — 전표 수천만 건이면 브라우저나 서비스 로직이 아니라 점검 큐브(DB)가 합니다. 이 화면의 조회는 기준 연월 한 달로 끊기므로, 달마다 명세가 수백~수천 건이어도 부담이 크지 않습니다.
• 파라미터 필수화 — 기준 연월 없이 열면 전체 기간을 훑습니다. 쿼리에서 기준 연월을 필수 파라미터로 두어 막습니다.
• 인덱스 — ACDOCA 에서 계정·전기일로 줄이는 조건이 늘 걸립니다. 계정 범위를 정책 테이블에서 먼저 줄여 join 하면 읽는 줄 수가 줄어듭니다.
• 응답 시간 기준 — 한 달 조회가 수 초 안에 끝나는지, 총건수 조회가 따로 오래 걸리지 않는지 운영 규모 샘플로 먼저 잽니다.

자주 묻는 질문

도입 상담과 데모에서 받는 질문을 네 묶음으로 나누어 적었습니다.

숫자와 판정

화면과 조작

표준 T-code 와 운영

도입과 책임