SAP 현금흐름표 총액·순액 표시 점검 — IAS 7, 순액으로 올린 투자·재무활동 현금흐름이 예외 요건을 채우는지 거래 명세로 다시 계산해 장부와 대조한다

개발 배경

결산을 앞두고 현금흐름표를 맞추는 팀이 매번 마주치는 질문이 있습니다. 이 항목은 총액으로 올려야 하나, 순액으로 올려도 되나. 투자활동과 재무활동의 현금유입과 현금유출은 원칙적으로 구분해 총액으로 표시하는 것이 기본이고, 고객을 대신해 받거나 준 돈이거나 회전이 빠르고 금액이 크며 만기가 짧은 항목에 한해 순액 표시가 허용되는 예외가 있습니다. 관련 요구사항은 IAS 7 현금흐름표(K-IFRS 제1007호)입니다.

문제는 그 예외를 "충족했다"고 말할 근거를 매 분기 다시 모아야 한다는 점입니다. 표준 화면은 전표 라인을 보여 주지만 회전 횟수나 평균 만기일수는 계산해 주지 않고, 그 계산은 보통 엑셀 시트에서 사람이 합니다. 이 앱은 그 시트가 하던 일, 곧 순액으로 올린 항목마다 요건을 다시 계산해 보고 총액으로 바꾸면 유입이 얼마나 늘어나는지까지 보여 주는 일을 한 화면에 옮겨 둔 것입니다. 이 화면은 분류·집계·대사를 돕는 점검 도구이고, 총액·순액 표시의 최종 판단은 회사와 감사인이 합니다.

순액 표시의 근거는 항목마다 따로 흩어져 있다

순액으로 올린 항목이 열 개라면 근거도 열 갈래입니다. 어떤 항목은 고객 대신 받은 돈이라는 사실이, 어떤 항목은 만기와 회전과 금액 세 숫자가 근거입니다. 이 근거들이 결산 파일 여러 곳에 흩어져 있으면 감사 대응 때 같은 질문에 매번 새로 답을 만들게 됩니다. 이 앱은 항목마다 근거를 같은 형식의 한 줄로 모아, 요건을 채운 항목과 다시 확인할 항목을 같은 표에서 나누어 보여 줍니다.

합계가 맞아도 층이 어긋나 있을 수 있다

활동별 순증감이 현금 증감과 맞는 것만 확인하면 항목 수준의 오류는 가려집니다. 항목 합계는 맞는데 명세 합계와는 어긋나 있는 경우가 대표적입니다. 이 앱은 명세 → 항목 → 활동의 세 층을 서로 다시 합산해 보는 대사식 일곱 개를 매번 돌려, 어느 층에서 어긋났는지 바로 좁힐 수 있게 합니다.

"점검 필요"가 많아질수록 설명 문장이 필요하다

점검 대상이 "요건 미충족" 한 줄로만 표시되면 담당자는 결국 근거를 직접 열어 봐야 합니다. 이 앱은 만기가 길어서인지, 회전이 부족해서인지, 금액이 작아서인지를 점검 내용에 문장으로 남기고, 그 항목의 거래 명세를 같은 창에서 열어 줍니다. 판단을 대신하지 않고 판단에 필요한 재료를 한 자리에 두는 것이 이 화면의 일입니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 넣고 필요하면 기간·활동 구분·항목·현재 표시 방식·기준일 범위·점검 결과를 고릅니다. 비워 두거나 "전체"를 고른 조건은 적용되지 않습니다.
2. 조회 — 조회 버튼을 누르거나 회계연도 칸에서 Enter 를 누릅니다. 화면을 처음 열 때는 기본 조건으로 자동 조회됩니다.
3. 요약 확인 — 판정 항목 수, 순액 표시 항목 수, 점검 필요 항목 수, 총액 환산 시 유입 증가분, 대사 차이 건수를 먼저 봅니다.
4. 탭 이동 — 항목별 판정 → 활동별 집계 → 거래 명세 → 정합성 대사 순서로 근거 쪽으로 내려갑니다.
5. 행 클릭 상세 — 항목 행을 누르면 판정 사유와 해당 항목의 거래 명세가 한 창에 열립니다.
6. 내보내기 — 현재 탭의 결과를 화면의 컬럼 이름과 표시 형식 그대로 UTF-8 CSV 로 내려받습니다.

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

화면에 나오는 숫자는 서비스가 계산하고, 그 계산을 서비스와 무관한 코드로 한 번 더 계산해 비교했습니다. 검사는 대사식 7종을 세 기간에 걸쳐 돌린 135건이며 차이는 0건입니다. 항목 판정 30건도 같은 규칙으로 다시 구해 불일치가 0건이었습니다.

샘플 데이터에는 점검 필요 항목이 일부러 5건 들어 있습니다(2026-07 단기차입금, 2026-08 단기매매증권·단기차입금·임대보증금, 2026-09 장기대여금). 이는 판정이 제대로 걸러내는지 보기 위한 의도적 예외이며 대사 차이와는 따로 기록했습니다. 금액·항목·거래처는 모두 가상이고 단위는 백만원입니다.

무엇으로 만들었나

실행 화면

아래 화면은 모두 검증용 샘플 데이터(가상, 단위 백만원)로 실제 렌더링한 것입니다. 화면 순서는 실제로 쓰는 순서를 따랐습니다.

처음 열었을 때와 점검 필요 항목 좁히기

조회조건과 요약, 첫 탭이 한 화면에 나오고, 점검 결과 조건 하나로 다시 확인할 항목만 남길 수 있습니다.

회계연도는 필수이고 기본값은 2026년·기간 전체입니다. 화면을 열면 자동으로 한 번 조회하므로 아무것도 누르지 않아도 30개 판정 행이 보입니다. 조회 버튼은 조회조건 오른쪽 끝에 있고 회계연도 칸에서 Enter 를 눌러도 같은 조회가 됩니다. 요약 지표 중 "점검 필요" 건수와 "총액 환산 시 유입 증가분"을 가장 먼저 보면 됩니다. 두 숫자가 0 이면 이번 조건 범위에서는 다시 확인할 순액 표시 항목이 없다는 뜻입니다.

샘플에서는 세 기간을 합쳐 5건이 남습니다. 행마다 회전 횟수·평균 만기일수·총유입이 나란히 있어 어느 요건이 걸렸는지 한눈에 읽힙니다. 점검 내용 칸에는 만기, 회전, 금액 중 무엇이 기준에 못 미쳤는지가 문장으로 적힙니다. "점검 필요"는 원인이나 위반을 단정하는 표시가 아니라 다시 확인하라는 신호이며, 기준값은 회사 정책으로 바꿀 수 있는 샘플 값입니다.

활동별로 접고 명세로 내려가기

항목 판정을 활동 단위로 접어 보고, 판정의 근거가 되는 전표 단위 명세까지 내려갑니다.

같은 활동 안에서 표시 방식이 총액이든 순액이든 순증감은 같아야 합니다. 이 탭은 그 사실을 합계로 확인하는 자리입니다. 표시 유입·표시 유출은 방식에 따라 달라지고, 그 차이가 "총액 환산 시 유입 증가분"으로 따로 집계됩니다. 점검 필요 항목 수가 있는 활동은 첫 탭으로 돌아가 해당 항목을 눌러 보면 됩니다.

항목 숫자를 의심할 때 가장 먼저 내려오는 탭입니다. 유입 건수가 곧 회전 횟수이고 유입 금액으로 가중한 만기일수가 평균 만기일수이므로, 명세만 있으면 판정을 손으로 다시 계산해 볼 수 있습니다. 명세의 전표번호는 표준 전표 조회로 원본을 확인할 때 그대로 입력하면 됩니다.

대사로 확인하고 상세로 사유 읽기

세 층의 합계가 서로 맞는지 확인하고, 점검 필요 항목은 상세 창에서 사유와 명세를 함께 읽습니다.

항목 합계와 명세 합계, 활동 합계와 항목 합계가 서로 맞는지를 화면이 스스로 매번 다시 잽니다. 차이 건수가 0 이 아닌 줄이 있으면 그 줄의 좌변·우변을 보고 어느 층에서 어긋났는지를 찾습니다. 샘플 데이터에는 이 대사가 모두 0 으로 나오도록 만들었고, 점검 필요 항목은 대사 차이와 분리해 따로 기록했습니다.

목록에서 이미 본 숫자를 창 안에서 다시 풀어 보여 주는 화면입니다. 판정 조건과 항목의 실제 값이 같은 창에 있어 "왜 점검 필요인가"가 바로 읽힙니다. 창을 닫으면 조회조건과 스크롤 위치가 그대로 남아 다음 항목으로 이어 갈 수 있습니다.

좁은 화면에서 본 모습

표는 컬럼을 줄이지 않고 가로 스크롤로 같은 내용을 보여 줍니다. 노트북 분할 화면이나 태블릿에서도 판정 컬럼이 빠지지 않는다는 점이 중요합니다. 조회 버튼과 초기화 버튼은 좁아져도 조회조건 바로 옆에 남습니다.

좁은 화면에서도 컬럼은 줄지 않고, 조회조건·요약 지표의 배치만 바뀝니다. 아래 장에서 설명하는 판정 규칙과 조회조건은 화면 폭과 무관하게 같습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 입력한 조건으로 표준 필터 객체를 만들어 서비스에 보내고, 서비스는 명세를 읽어 항목 단위로 접어 판정까지 끝낸 행을 돌려줍니다. 화면은 받은 행을 그대로 표에 연결하고, 정렬과 스크롤도 서비스가 처리합니다. 요약 지표 중 "총액 환산 시 유입 증가분"만 서비스의 함수를 한 번 더 불러 받아 옵니다.

순액 표시 요건 판정 규칙

아래 허용 기준(평균 만기 90일 이내, 회전 4회 이상, 총유입 1,000 이상)은 설명을 위한 샘플 값이며 회사 정책에 따라 조정해야 합니다. 기준서가 정한 구체 수치와의 대조는 확인 필요입니다.

산출 순서와 대사식

1. 총유입은 명세 중 방향이 유입인 금액의 합, 총유출은 방향이 유출인 금액의 합입니다.
2. 순액 = 총유입 − 총유출
3. 회전 횟수 = 유입 명세 건수, 평균 만기일수 = Σ(유입 금액 × 만기일수) ÷ 총유입(반올림한 정수)
4. 순액 표시 요건 부합 = 고객 대신 수취·지급이거나 (0 < 평균 만기일수 ≤ 90 이고 회전 횟수 ≥ 4 이고 총유입 ≥ 1,000)
5. 표시 유입·표시 유출은 총액 표시이면 (총유입, 총유출), 순액 표시이면 (max(순액, 0), max(−순액, 0))입니다.
6. 점검 결과는 순액 표시이면서 요건 부합이 아니면 점검 필요, 그 밖은 정상입니다.
7. 총액 환산 시 유입 증가분 = 순액 표시이면서 점검 필요인 항목의 (총유입 − 표시 유입)

금액 단위는 백만원이며 소수 첫째 자리까지 다룹니다. "고객 대신" 판정 방식과 만기·회전·금액 기준은 회사 정책으로 정하며 이 글에서는 확인 필요로 남겨 둡니다.

조회조건

대사 탭은 회계연도·기간만 조건으로 받고, 거래 명세 탭은 현재 표시 방식·점검 결과 조건을 적용하지 않습니다.

결과 컬럼

좁은 화면에서 달라지는 것

폭이 줄면 조회조건이 여러 줄로 나뉘고 요약 지표도 줄바꿈됩니다. 표는 컬럼 수를 줄이지 않고 가로 스크롤을 줍니다. 상세 창은 화면 폭에 맞춰 줄어들며 닫으면 이전 조회 상태가 그대로 남습니다.

파일 구성

화면 앱
├─ 시작 파일 · 앱 설정 · 컴포넌트
├─ 화면 정의(메인 화면 · 상세 창)
├─ 컨트롤러(조회·정렬·상세·내보내기)
├─ 모델 보조(표시 형식 · 오류 처리)
├─ 문구 · 스타일
└─ 서비스 구현(항목 판정 · 활동 집계 · 대사 · 총액 환산 함수)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 아래 표는 표준 화면으로 충분한 일과 이 앱이 더하는 관점을 나란히 놓은 것입니다.

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

T-code 별 연계 지점

운영 전환 시에도 기존 리포트를 없앨 필요는 없습니다. 표준 화면은 법정·감사 대응의 기록으로 그대로 두고, 이 앱은 결산 전에 순액 표시 항목을 다시 확인하는 용도로 나란히 씁니다.

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

이 앱의 계산은 CDS 큐브와 분석 쿼리로 옮길 수 있게 나뉘어 있습니다. 표준 Fiori 분석 앱이나 Analysis for Office 에서 같은 쿼리를 읽으면 같은 판정이 나오고, 이 앱의 화면은 그 위에서 점검 흐름(조회 → 점검 필요 좁히기 → 상세 → 대사)을 맡습니다. 표준 CDS 뷰의 이름과 필드는 릴리스마다 다를 수 있어 이 글에서는 원천 테이블 기준으로 쓰고, 표준 뷰 사용 여부는 확인 필요로 둡니다.

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

요구사항 매핑

CDS 구성

아래는 같은 판정을 S/4HANA 의 CDS 로 옮길 때의 구성안입니다. 샘플 앱의 서비스 로직과 같은 규칙을 뷰 단계로 나눈 것이며, 객체 이름은 설명을 위한 가상의 이름입니다. 표준 CDS 뷰의 이름과 필드는 릴리스별 확인 필요이고, 여기서는 원천 테이블을 직접 읽는 형태로 적었습니다.

뷰 레이어 구성

① 항목 배정표 — 계정이 어느 항목·활동에 속하는지를 정하는 자리

표준 계정 마스터에는 "이 계정을 현금흐름표의 어느 항목에, 총액으로 올릴지 순액으로 올릴지"에 대한 정보가 없습니다. 이 구분은 회사가 정하는 설계 자료이므로 코드에 묻지 않고 테이블로 뺍니다. 운영에서는 이 표가 비어 있거나 틀리면 판정 전체가 무의미해지므로 가장 먼저 합의해야 하는 객체입니다.

" ─────────────────────────────────────────────────────────────
"  ZCFNET_FLOWMAP — 현금흐름 항목 배정표
"  역할 : 계정이 어느 현금흐름 항목·활동에 속하는지, 현재 총액/순액 중 무엇으로
"         올리는지, 고객 대신 수취·지급 항목인지를 회사가 직접 적는 자리
"  이렇게 나눈 이유 : 표준 계정 마스터에는 이 구분이 없다. 코드에 묻어 두면
"         계정이 늘 때마다 이송이 필요하므로 현업이 고치는 테이블로 뺀다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '현금흐름 항목 배정'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcfnet_flowmap {
  key client   : abap.clnt not null;
  key bukrs    : bukrs not null;
  key saknr    : saknr not null;
  flow_no      : abap.char(3) not null;   " F01 ~ F10
  activity     : abap.char(3) not null;   " INV(투자) / FIN(재무)
  shown_basis  : abap.char(5) not null;   " GROSS(총액) / NET(순액)
  on_behalf    : abap_boolean;            " 고객 대신 수취·지급 여부
}

② 기준값 테이블 — 90일·4회·1,000 을 데이터로 두는 자리

순액 표시 예외의 구체 수치는 회사 정책과 감사인의 해석에 따라 달라질 수 있습니다. 샘플의 값을 뷰에 박아 두면 정책이 바뀔 때마다 이송이 필요하므로, 회사코드 단위로 값을 읽는 테이블로 분리합니다.

" ─────────────────────────────────────────────────────────────
"  ZCFNET_PARAM — 순액 표시 점검 기준값
"  역할 : 만기 일수 상한, 회전 횟수 하한, 총유입 하한을 회사 정책으로 보관
"  이렇게 나눈 이유 : 샘플 값(90일 · 4회 · 1,000)은 설명을 위한 값일 뿐이다.
"         기준을 바꾸는 일이 뷰 수정이 아니라 데이터 수정이 되도록 분리한다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '순액 표시 점검 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcfnet_param {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  mat_days_max  : abap.int4;                          " 평균 만기일수 상한
  turn_min      : abap.int4;                          " 회전 횟수 하한
  @Semantics.amount.currencyCode : 'zcfnet_param.waers'
  big_min       : abap.curr(18,1);                    " 총유입 하한 (백만원)
  waers         : waers;
}

③ 명세 기준 뷰 — 전표 라인에 항목을 붙이는 자리

이 뷰 하나가 항목 판정·활동 집계·대사의 공통 원천입니다. 방향(유입·유출)과 만기일수를 어디서 가져오는지가 여기서 결정되며, 이 부분의 원천은 확인 필요로 둡니다. 전표 수가 큰 회사에서는 이 뷰의 조건이 성능을 좌우합니다.

" ─────────────────────────────────────────────────────────────
"  ZI_CfFlowLine — 현금흐름 명세(전표 라인) 기준 뷰
"  역할 : 원장 전표 라인을 배정표에 붙여 항목·활동·방향·금액·만기일수를 한 줄에 모은다
"  이렇게 나눈 이유 : 항목 판정·활동 집계·대사가 모두 이 한 뷰를 읽게 해
"         명세 합계와 항목 합계가 서로 다른 원천에서 어긋날 자리를 없앤다
"  확인 필요 : 만기일수·방향 판정 필드는 회사 자료 원천에 따라 달라진다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '현금흐름 명세'
@ObjectModel.usageType : { serviceQuality : #X, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
define view entity ZI_CfFlowLine
  as select from acdoca as j
    inner join zcfnet_flowmap as m
      on  m.bukrs = j.rbukrs
      and m.saknr = j.racct
{
  key j.rldnr                          as Ledger,
  key j.rbukrs                         as CompanyCode,
  key j.gjahr                          as FiscalYear,
  key j.belnr                          as AccountingDocument,
  key j.docln                          as LedgerItem,
      j.poper                          as FiscalPeriod,
      j.budat                          as PostingDate,
      m.flow_no                        as FlowNo,
      m.activity                       as ActivityType,
      m.shown_basis                    as ShownBasis,
      m.on_behalf                      as OnBehalf,
      case when j.drcrk = 'S' then 'IN' else 'OUT' end   as Direction,
      @Semantics.amount.currencyCode : 'Currency'
      abs( j.hsl )                     as Amount,
      j.rhcur                          as Currency
}

④ 항목 판정 큐브 — 총유입·총유출·회전·평균 만기를 만드는 자리

case 와 sum 으로 방향별 합과 유입 건수를 만들고, 유입 금액으로 가중한 평균 만기일수를 정수로 맞춥니다. 샘플 앱의 서비스 계산과 같은 식이므로 두 결과를 서로 대조하는 것이 이관 검증의 출발점입니다.

" ─────────────────────────────────────────────────────────────
"  ZI_CfFlowJudge — 항목별 표시 방식 판정 큐브
"  역할 : 명세를 항목 단위로 접어 총유입·총유출·순액·회전 횟수를 만들고
"         순액 표시 요건 부합 여부와 점검 결과, 총액 환산 시 유입 증가분까지 계산
"  이렇게 나눈 이유 : 판정을 화면이 아니라 뷰에 둬야 서비스·배치·다른 화면이
"         같은 결론을 낸다. 화면은 이 뷰가 준 값을 보여 주기만 한다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '현금흐름 항목 판정'
define view entity ZI_CfFlowJudge
  as select from ZI_CfFlowLine as l
  association [0..1] to zcfnet_param as _Param
    on _Param.bukrs = $projection.CompanyCode
{
  key l.CompanyCode,
  key l.FiscalYear,
  key l.FiscalPeriod,
  key l.FlowNo,
      l.ActivityType,
      l.ShownBasis,
      l.OnBehalf,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when l.Direction = 'IN'  then l.Amount else 0 end )  as GrossIn,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when l.Direction = 'OUT' then l.Amount else 0 end )  as GrossOut,
      sum( case when l.Direction = 'IN'  then 1 else 0 end )         as TurnCount,
      cast( case when sum( case when l.Direction = 'IN' then l.Amount else 0 end ) = 0
                 then 0
                 else sum( case when l.Direction = 'IN' then l.Amount * l.MaturityDays else 0 end )
                      / sum( case when l.Direction = 'IN' then l.Amount else 0 end )
            end as abap.int4 )                                      as AvgMaturityDays,
      l.Currency
}
group by l.CompanyCode, l.FiscalYear, l.FiscalPeriod, l.FlowNo,
         l.ActivityType, l.ShownBasis, l.OnBehalf, l.Currency

⑤ 항목 점검 쿼리 — 요건 부합과 조회조건을 정하는 자리

분석 쿼리에서 어떤 필드를 필수 조건으로 노출할지, 어느 필드를 범위 조건으로 둘지가 결정됩니다. 판정식의 기준값은 운영에서 기준값 테이블을 읽도록 바꿔야 하며 여기서는 샘플 값을 주석과 함께 둡니다.

" ─────────────────────────────────────────────────────────────
"  ZC_CfFlowCheck — 항목 판정 분석 쿼리(화면이 읽는 뷰)
"  역할 : 큐브 위에 요건 부합·점검 결과·표시 유입/유출·증가분을 얹고
"         조회조건으로 쓸 필드를 지정한다
"  이렇게 나눈 이유 : 계산 로직(큐브)과 화면 노출 정의(쿼리)를 나눠 두면
"         화면 필드가 바뀌어도 판정 로직은 건드리지 않는다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '현금흐름 항목 점검'
define view entity ZC_CfFlowCheck
  as select from ZI_CfFlowJudge as j
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key j.FiscalYear,
  @Consumption.filter : { selectionType : #SINGLE }
  key j.FiscalPeriod,
  @Consumption.filter : { selectionType : #RANGE }
  key j.FlowNo,
      @Consumption.filter.selectionType : #SINGLE
      j.ActivityType,
      @Consumption.filter.selectionType : #SINGLE
      j.ShownBasis,
      j.TurnCount,
      j.AvgMaturityDays,
      j.GrossIn,
      j.GrossOut,
      @AnalyticsDetails.query.axis : #COLUMNS
      j.GrossIn - j.GrossOut                               as NetAmount,
      case when j.OnBehalf = 'X'
             or ( j.AvgMaturityDays > 0 and j.AvgMaturityDays <= 90
                  and j.TurnCount >= 4 and j.GrossIn >= 1000 )
           then 'X' else ' ' end                           as NetAllowed
      /* 90 · 4 · 1,000 은 샘플 기준값. 운영에서는 기준 테이블 값을 읽는다 */
}

⑥ 활동 집계 쿼리 — 항목 판정을 활동으로 접는 자리

활동 순증감이 소속 항목 순액의 합과 같아야 한다는 대사식이 뷰에서도 성립하도록 항목 쿼리를 그대로 합산합니다. 합계가 어긋나면 쿼리 정의가 아니라 항목 배정에서 원인을 찾아야 합니다.

" ─────────────────────────────────────────────────────────────
"  ZC_CfActivitySum — 활동별 집계 쿼리
"  역할 : 항목 판정을 투자활동·재무활동 단위로 접어 순증감과
"         표시 유입·표시 유출 합계, 점검 필요 항목 수를 낸다
"  이렇게 나눈 이유 : 표시 방식이 달라도 활동 순증감은 같아야 한다는 대사(R04)가
"         뷰 수준에서 바로 성립하도록 항목 판정을 그대로 합산한다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '현금흐름 활동 집계'
define view entity ZC_CfActivitySum
  as select from ZC_CfFlowCheck as f
{
  key f.FiscalYear,
  key f.FiscalPeriod,
  key f.ActivityType,
      count( * )                                           as FlowCount,
      sum( case when f.ShownBasis = 'NET' then 1 else 0 end ) as NetShownCount,
      sum( case when f.ShownBasis = 'NET' and f.NetAllowed = ' '
                then 1 else 0 end )                        as CheckCount,
      sum( f.GrossIn )                                     as GrossIn,
      sum( f.GrossOut )                                    as GrossOut,
      sum( f.NetAmount )                                   as NetTotal
}
group by f.FiscalYear, f.FiscalPeriod, f.ActivityType

⑦ 접근 제어 — 보는 범위를 정하는 자리

회사코드 단위 권한은 명세 기준 뷰 아래에서 한 번만 걸어도 위의 모든 쿼리에 적용됩니다. 권한을 쿼리 위쪽에 거는 것보다 합계에서 새어 나갈 틈이 적습니다.

" ─────────────────────────────────────────────────────────────
"  ZC_CfFlowCheck — 접근 제어(DCL)
"  역할 : 회사코드 단위로 조회 범위를 제한한다
"  이렇게 나눈 이유 : 명세·항목·활동이 같은 큐브에서 나오므로 권한도
"         큐브 아래에서 한 번만 걸면 모든 탭에 같은 범위가 적용된다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '현금흐름 점검 접근 제어'
@MappingRole : true
define role ZC_CfFlowCheck {
  grant select on ZI_CfFlowLine
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 쿼리를 OData 로 내보내는 자리

서비스 정의는 무엇을 노출할지, 바인딩은 어떤 프로토콜로 게시할지를 가릅니다. 바인딩 유형과 게시 절차는 릴리스에 따라 달라질 수 있으므로 확인 필요입니다.

" ─────────────────────────────────────────────────────────────
"  ZUI_CfFlowCheck — 서비스 정의와 바인딩
"  역할 : 위 쿼리 두 개를 OData V2 서비스로 노출한다
"  이렇게 나눈 이유 : 서비스 정의는 무엇을 내보낼지, 바인딩은 어떤 프로토콜로
"         내보낼지를 가른다. 화면 쪽은 바인딩 주소만 설정에 넣으면 된다
"  확인 필요 : 바인딩 유형(OData V2 - UI)과 게시 방법은 릴리스별로 다를 수 있다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '현금흐름 점검 서비스'
define service ZUI_CfFlowCheck {
  expose ZC_CfFlowCheck   as FlowCheck;
  expose ZC_CfActivitySum as ActivitySum;
  expose ZI_CfFlowLine    as FlowLine;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 일은 모두 코드가 아니라 합의에서 시작합니다.

운영 데이터로 갈 때

전표가 수천만 건이면 명세 기준 뷰의 읽기 범위가 가장 먼저 문제가 됩니다. 회계연도·기간을 필수 조건으로 두어 읽는 범위를 좁히고, 집계는 큐브에서 하며 화면은 접힌 행만 받게 합니다. 명세 탭은 항목을 고른 뒤에만 열리도록 조건을 요구하는 편이 안전하고, 응답 시간 기준은 사전에 합의해 둡니다. 샘플은 245행이라 이 문제가 드러나지 않으므로 운영 규모의 시험은 별도로 필요합니다.

자주 묻는 질문

도입을 검토하는 분들이 자주 묻는 내용을 네 묶음으로 정리했습니다.

숫자와 판정

화면과 조작

SAP 표준과 데이터

도입과 운영