예측 대비 실적 차이 점검 — 현금흐름 예측이 어디서 어긋났는지 금액·시기·미실현·예측 외로 나누어 보는 화면

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

자금 팀의 월간 점검에는 늘 같은 질문이 따라붙습니다. 지난 8주 동안 세운 현금흐름 예측이 얼마나 맞았나, 어디서 틀렸나, 다음 예측은 어디부터 고쳐야 하나. 지금은 표준 유동성 예측 화면과 은행 입출금 내역을 엑셀에 나란히 붙여 항목마다 손으로 견줍니다. 합계 차이는 금방 나오지만 그 차이가 금액이 달라서인지, 입금이 일주일 늦어서인지, 아예 예측에 없던 입출금인지는 엑셀 안에서 사람이 하나씩 가려야 합니다.

이 앱은 예측 항목과 실적 입출금을 항목마다 이어 붙인 뒤 차이를 네 가지 원인으로 나눕니다. 금액이 달랐던 몫, 주를 옮겨 간 몫, 실현되지 않은 몫, 예측에 없던 몫입니다. 네 몫을 더하면 총 차이와 정확히 같아지고, 그 등식을 포함한 대사식 여덟 개를 화면이 매번 검사해 결과를 보여 줍니다. 관련 기준서는 없으며, 대상 영역은 자금 예측 관리의 사후 점검입니다.

합계 차이만 보면 고칠 곳이 보이지 않는다

8주 예측 순현금흐름이 −1,550.6백만원, 실적이 −1,824.8백만원이면 총 차이는 −274.2백만원입니다. 이 숫자만으로는 “예측을 더 보수적으로 잡자”는 결론밖에 나오지 않습니다. 그런데 같은 기간 건별 절대 오차를 모두 더하면 1,565.0백만원으로 총 차이의 다섯 배가 넘습니다. 어떤 건은 위로, 어떤 건은 아래로 어긋나 서로를 상쇄하고 있다는 뜻입니다. 이 앱은 순차이와 절대 오차를 나란히 둡니다.

이 앱의 해결 — 순차이와 건별 절대 오차를 함께 보여 줍니다. 순차이는 작아도 건별 오차가 크면 주를 W04(건별 상쇄)로 따로 표시합니다.

늦게 들어온 돈과 틀린 돈은 다른 문제다

입금이 한 주 늦어졌을 뿐이라면 8주 합계에는 영향이 없습니다. 그러나 주별 잔고 예측은 어긋납니다. 반대로 금액이 틀렸다면 합계 자체가 움직입니다. 둘은 고치는 방법이 다릅니다 — 앞의 것은 입금·지급 시기를 잡는 가정을, 뒤의 것은 금액 산정 기준을 손봐야 합니다. 이 앱은 시기 효과를 따로 계산해 떠나는 주와 도착하는 주에 반대 부호로 올립니다. 그래서 조회 구간 안의 시기 효과 합계는 언제나 0이고, 이 사실도 대사식 하나로 검사합니다.

이 앱의 해결 — 시기 효과를 금액 효과와 분리해 주별로 보입니다. 시기 효과 합계가 0인지 대사식으로 검사합니다.

예측에 없던 돈과 실현되지 않은 돈은 따로 센다

실적에는 있는데 예측에 없는 입출금(예측 외)과, 예측에는 있는데 8주 안에 실현되지 않은 항목(미실현)은 둘 다 “차이”지만 원인이 반대입니다. 앞의 것은 예측 대상에서 빠진 거래이고, 뒤의 것은 구간 뒤로 넘어갔거나 취소된 거래입니다. 이 앱은 두 가지를 항목 단계에서 L03(미실현)과 L04(예측 외)로 갈라 표시하고, 주별로도 미실현 효과와 예측 외 효과로 따로 올립니다.

이 앱의 해결 — 미실현 효과와 예측 외 효과를 별도 열로 둡니다. 둘 중 어느 쪽이 큰지에 따라 주 판정 코드(W03)가 달라집니다.

분류마다 허용 오차가 다르다

급여·세금은 예측과 거의 같아야 하고, 설비투자 대금이나 기타 입금은 어느 정도 흔들려도 됩니다. 한 가지 기준으로 모든 분류를 판정하면 급여의 작은 오차는 놓치고 설비투자의 정상적인 흔들림은 경보로 처리합니다. 이 앱은 분류마다 오차율(WAPE)·편향·정시 실현율의 한도를 따로 읽어 판정하고, 한도를 정하지 않은 분류는 판정하지 않고 C04(확인 필요)로 남깁니다.

이 앱의 해결 — 분류별 한도를 정책 값으로 읽어 판정합니다. 한도가 없으면 판정을 보류하고 확인 필요로 남깁니다.

사용 방법

1. 회계연도와 기간(월)을 입력합니다(필수). 회사·현금 분류·기준일 기간·점검 코드·점검 결과는 필요할 때만 고르며, 비우면 그 조건은 걸리지 않습니다.
2. 입력 칸 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 초기화는 조건을 처음 값으로 되돌립니다.
3. 위쪽 요약 지표 여덟 개를 확인합니다. 점검한 예측 항목 수, 예측·실적 순현금흐름, 총 차이, 건별 절대 오차 합계, 한도를 벗어난 분류 수, 확인 필요 건 수, 정합성 대사 차이입니다.
4. 탭을 항목별 차이 → 주별 차이 분해 → 분류별 정확도 → 대사 결과 순으로 옮기며 차이의 위치를 좁혀 갑니다.
5. 항목별 차이 탭에서 행을 누르면 상세 창이 열립니다. 예측일에서 실적일로의 이동, 금액 차이, 같은 분류의 다른 예측 항목을 봅니다.
6. CSV 내려받기로 지금 보이는 탭의 조회 결과를 파일로 저장합니다.

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

예측과 실적을 견주는 화면에서 가장 비싼 질문은 “이 차이가 정말 맞나”입니다. 그래서 만드는 쪽에서 대사식을 먼저 세워 전수로 돌렸습니다.

대사식 8개, 검사 70건에서 차이는 0건입니다. 예측일이 없는 3건은 주를 정할 수 없어 집계에서 일부러 뺀 의도적 예외이며, 대사 결과 탭에 따로 표시됩니다.

무엇으로 만들었나

실행 화면

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

처음 열었을 때

조회조건부터 요약 지표, 탭 표까지 한 화면에 세로로 놓입니다. 점검 코드로 거르면 같은 화면이 원인별 목록이 됩니다.

조회조건 아래로 요약 지표 여덟 개가 먼저 보이고, 그 아래 탭이 항목별 차이를 보여 줍니다. 처음에는 회계연도 2026·기간 10이 들어 있고 나머지 조건은 비어 있어 두 회사 145건이 모두 나옵니다. 지표의 ‘정합성 대사 차이 0’이 맨 오른쪽에 있어, 숫자를 읽기 전에 계산이 맞는지부터 확인할 수 있습니다. 금액은 원 단위, 요약은 백만원 단위이며 입금은 +, 출금은 −입니다.

점검 코드 선택 상자에서 L02를 고르고 조회를 누른 결과입니다. 표 위 탭의 건수와 요약 지표 첫 칸이 모두 10건으로 바뀝니다. 이동(주) 열에 +1주 늦음, 1주 빠름처럼 옮겨 간 방향이 적혀 있어 같은 시기 차이라도 늦게 들어온 건과 일찍 들어온 건을 구분해서 볼 수 있습니다.

차이의 위치를 좁혀 가는 화면

주별 분해와 분류별 정확도는 같은 차이를 시간 축과 분류 축으로 나눠 보여 줍니다.

한 줄이 회사·주 하나입니다. 예측 순현금흐름과 실적 순현금흐름의 차이가 총 차이이고, 그 오른쪽 네 열을 더하면 총 차이와 같습니다. 3주차는 미실현 효과(−115.7백만원)와 예측 외 효과(−58.0백만원)가 크게 잡혀 주 판정이 미실현·예측 외 우세(W03)입니다. 순차이율이 한도 안인 주도 건별 오차가 크면 W04로 따로 표시됩니다.

매출채권 회수는 오차율 11.98%(한도 15%)·편향 −4.49%(한도 5%)로 모두 한도 안이라 정상이지만, 설비투자 대금은 오차율 12.32%가 한도 25% 안인데도 편향 −12.07%가 한도 10%를 넘어 점검 필요입니다. 한 분류가 세 지표 가운데 하나만 넘어도 점검 필요가 됩니다. 정시 실현율은 예측한 주에 실현된 비율이며, 평균 이동은 실현 항목이 평균 몇 주 움직였는지 보여 줍니다.

대사 결과와 항목 상세

숫자가 맞는지 확인하는 화면과, 한 건의 사연을 보는 화면입니다.

대사식 여덟 개 모두 차이 건수가 0이고 검사 건수 합계는 70건입니다. 마지막 줄은 예측일이 없어 주를 정할 수 없는 3건으로, 집계에서 빼는 것이 맞으므로 ‘의도적 예외’로 따로 보이며 차이 3건이 정상입니다. 이 줄이 0이 아니라고 오류로 읽으면 안 됩니다.

항목별 차이 탭에서 행을 누르면 열립니다. 위쪽에 예측일→실적일, 예측 금액→실적 금액(차이율), 예측 주차→실적 주차가 한 줄씩 적히고, 이 항목이 왜 정상 또는 점검 필요인지 판정 근거가 한 문장으로 붙습니다. 아래 표는 같은 회사·같은 분류의 예측 항목이라 같은 분류의 다른 건과 바로 견줄 수 있습니다. 닫기 버튼이나 Esc 키로 닫습니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 조회조건을 서비스 조건($filter)으로 바꿔 항목·주·분류·대사 네 목록을 받아 옵니다. 판정은 서비스가 하고, 화면은 받은 판정 코드를 글자와 색으로 바꾸기만 합니다. 판정 순서는 항목 → 주 → 분류입니다.

차이를 나누는 순서와 대사식

1. 항목 연결 — 예측 항목과 실적 입출금을 거래 상대·분류로 이어 실현·미실현·예측 외로 나눕니다.
2. 주 배정 — 예측일·실적일이 속한 주(월요일 시작)를 정합니다. 예측일이 없으면 주를 정하지 못하므로 집계에서 빼고 확인 필요로 남깁니다.
3. 총 차이 = 실적 순현금흐름 − 예측 순현금흐름 = 금액 효과 + 시기 효과 + 미실현 효과 + 예측 외 효과. 같은 주에 실현된 항목의 금액 차이가 금액 효과, 주를 옮긴 금액이 시기 효과(떠나는 주와 도착하는 주에 반대 부호), 실현되지 않은 예측의 음수가 미실현 효과, 예측에 없던 입출금이 예측 외 효과입니다.
4. 순차이율 = 총 차이 ÷ 예측 절대액 합계. 분류별 오차율(WAPE) = 건별 절대 오차 합계 ÷ 예측 절대액 합계, 편향 = (실적 − 예측) 합계 ÷ 예측 절대액 합계, 정시 실현율 = 예측한 주에 실현된 항목 수 ÷ 예측 항목 수입니다.
5. 잔고 — 기초잔고에 주별 순현금흐름을 더해 예측 기준 기말잔고와 실적 기준 기말잔고를 만들고, 둘의 차이가 총 차이의 누적과 같은지 대사합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

화면 폭이 줄면 조회조건이 여러 줄로 쌓이고 표는 가로로 넘겨 보며, 요약 지표도 줄을 바꿔 놓입니다. 상세 창은 화면 폭에 맞춰 줄어듭니다. 점검 판정과 숫자는 폭과 무관하게 같습니다.

파일 구성

앱 폴더/
├─ index.html            앱 진입점
├─ Component.js · manifest.json
├─ controller/           BaseController · Main.controller
├─ view/                 Main.view.xml · DetailDialog.fragment.xml
├─ model/                formatter · ErrorHandler
├─ css/ · i18n/
└─ odata/                서비스 정의 · 서비스 로직 · 엔티티셋별 데이터

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

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 예측과 실적을 견주는 사후 점검 관점을 더해 확장합니다. 표준 화면으로 충분한 일은 표준에 두고, 끊기는 자리만 이어 붙입니다.

T-code 별 연계 지점

운영 전환 시 기존 화면을 없애야 하나요? 없애지 않습니다. 표준 유동성 예측·현금 포지션 화면은 예측과 실적의 원천이고, 이 앱은 둘을 견주는 사후 점검입니다. 두 화면의 합계를 맞춰 보는 대사 지점을 운영 절차로 두면 됩니다.

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

표준 CDS 분석 쿼리나 Fiori 현금 관리 분석 앱이 보여 주는 값과 이 앱은 역할이 겹치지 않습니다. 표준 분석 앱은 현재의 현금 포지션과 예측을 보여 주고, 이 앱은 지난 예측이 얼마나 맞았나를 항목·주·분류로 되짚습니다. Analysis for Office 로 같은 CDS 큐브를 열어 피벗으로 보는 일도 가능하지만, 판정 코드와 대사 결과를 함께 보여 주는 화면은 이 앱 쪽에서 제공합니다. 표준 분석 뷰의 정확한 이름은 환경마다 달라 확인 필요로 남겼습니다.

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

분석 지표 정의

CDS 구성 — 코드와 운영 작업

아래 코드는 실제 환경에 맞추기 전의 구성 스케치입니다. 표준 테이블·필드 이름은 환경마다 달라 확인이 필요한 곳을 주석으로 표시했습니다. 객체 이름은 기능을 뜻하는 영문으로 지었습니다.

뷰 레이어 구성

① 분류 매핑과 한도 표 — 회사가 정하는 값은 코드 밖에 둔다

이 객체에서 결정되는 것은 “어떤 계획 그룹이 어느 분류인가”와 “분류마다 얼마까지 틀려도 되는가”입니다. 운영에서 가장 자주 바뀌는 값이라 뷰 안에 상수로 박지 않고 표로 둡니다. 한도가 비어 있으면 서비스는 판정하지 않고 확인 필요(C04)로 돌려줍니다.

" ─────────────────────────────────────────────────────────────
" ZFCV_CATMAP / ZFCV_CATLIM — 분류 매핑 · 분류별 한도 (DDIC 테이블)
" 역할   : 계획 그룹 → 현금 분류, 분류 × 회사 → 한도
" 나눈 이유: 회사가 정하는 값은 이송 없이 현업이 고칠 수 있어야 한다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '현금 분류 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zfcv_catmap {
  key mandt    : mandt not null;
  key grupp    : fdgrp not null;        " 계획 그룹 (필드 확인 필요)
  cat          : abap.char(3);          " COL PAY PRL TAX DBT CPX ETC
}

@EndUserText.label : '분류별 정확도 한도'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zfcv_catlim {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key cat      : abap.char(3) not null;
  wape_limit   : abap.dec(8,2);         " 오차율 한도(%)
  bias_limit   : abap.dec(8,2);         " 편향 한도(%)
  ontime_floor : abap.dec(8,2);         " 정시 실현율 하한(%)
}

② 현금 분류 차원 — 이름을 한 곳에서 정의한다

분류 코드와 화면에 보일 이름을 한 뷰에 모읍니다. 이름을 뷰마다 따로 쓰면 보고서마다 “매출채권 회수”와 “채권 회수”가 갈리는 일이 생깁니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '현금 분류'
@ObjectModel.representativeKey: 'Cat'
define view entity ZI_FcstCat
  as select distinct from zfcv_catmap
{
  key cat as Cat,
      case cat
        when 'COL' then '매출채권 회수'
        when 'PAY' then '매입채무 지급'
        when 'PRL' then '급여·퇴직급여'
        when 'TAX' then '세금·공과금'
        when 'DBT' then '차입 이자·상환'
        when 'CPX' then '설비투자 대금'
        else '기타 입금'
      end as CatName
}

③ 항목 기본 뷰 — 예측과 실적을 한 줄로 잇는다

예측 항목(계획 메모 레코드)과 실적 입출금(은행 전표 항목)을 거래 상대·분류·기간 키로 이어 한 줄로 만듭니다. 이 뷰에서 실현·미실현·예측 외가 갈리며, 항목 판정 코드(L00~L05)의 재료가 모두 여기서 나옵니다. 연결 키를 어떻게 잡느냐가 이 앱의 정확도를 좌우하므로 운영에서 가장 먼저 합의할 대상입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '예측-실적 항목'
define view entity ZI_FcstLine
  as select from fdes as plan                       " 계획 메모 레코드 (필드 확인 필요)
  left outer join febep as act                      " 은행 전표 항목 (필드 확인 필요)
    on  act.bukrs = plan.bukrs
    and act.cat   = plan.cat
  association [1..1] to ZI_FcstCat as _Cat on _Cat.Cat = plan.cat
{
  key plan.bukrs                         as Bukrs,
  key plan.idenr                         as LineNo,
      plan.cat                           as Cat,
      plan.datum                         as FcstDate,        " 예측일 (비어 있으면 L05)
      act.kwaer_date                     as ActDate,         " 실적일 (필드 확인 필요)
      @Semantics.amount.currencyCode: 'Currency'
      plan.wrshb                         as FcstAmt,
      @Semantics.amount.currencyCode: 'Currency'
      cast( coalesce( act.kwbtr, 0 ) as abap.curr(23,2) ) as ActAmt,
      plan.waers                         as Currency,
      case when plan.datum is initial     then 'NOFD'
           when act.kwbtr  is null        then 'UNREAL'
           else 'MATCH' end              as LineType,
      _Cat
}

④ 주 단위 큐브 — 총 차이 = 네 효과의 합을 한 곳에서 보장한다

회사·주 단위로 예측과 실적을 모으고 네 효과를 계산합니다. 금액 효과·시기 효과·미실현 효과·예측 외 효과를 같은 뷰 안에서 만들기 때문에, 합이 총 차이와 어긋나면 이 뷰의 정의가 잘못된 것입니다. 시기 효과는 떠나는 주와 도착하는 주에 반대 부호로 올려 조회 구간 합계가 0이 됩니다.

@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '주별 예측-실적 차이'
define view entity ZI_FcstVarWeek
  as select from ZI_FcstLine
{
  key Bukrs,
  key WeekNo,
      @Aggregation.default: #SUM
      sum( case when LineType = 'MATCH' and FcstWeek = ActWeek
               then ActAmt - FcstAmt else 0 end )       as AmtEffect,
      @Aggregation.default: #SUM
      sum( case when LineType = 'MATCH' and FcstWeek <> ActWeek
               then ActAmt else 0 end )                  as TimingIn,     " 도착하는 주
      @Aggregation.default: #SUM
      sum( case when LineType = 'UNREAL' then - FcstAmt else 0 end ) as UnrealEffect,
      @Aggregation.default: #SUM
      sum( case when LineType = 'UNFC' then ActAmt else 0 end )     as UnfcstEffect,
      @Aggregation.default: #SUM
      sum( ActAmt - FcstAmt )                                       as TotalDiff
}
group by Bukrs, WeekNo

⑤ 소비 쿼리 — 화면이 쓰는 필드만 연다

화면이 쓰는 필드와 필터를 선언하는 자리입니다. 조회조건 중 필수인 회계연도·기간은 필터로 필수화하고, 나머지는 선택 필터로 둡니다. 큐브의 내부 필드를 그대로 열지 않고 판정 코드와 사람이 읽을 문구까지 함께 내려 화면이 판정을 다시 계산하지 않게 합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '예측 대비 실적 — 항목'
@UI.headerInfo: { typeName: '예측 항목', typeNamePlural: '예측 항목' }
define view entity ZC_FcstVarLine
  as projection on ZI_FcstLine
{
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key Gjahr,
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key Monat,
  @Consumption.filter.selectionType: #SINGLE
  key Bukrs,
  key LineNo,
  @Consumption.filter.selectionType: #SINGLE
  Cat,
  @UI.lineItem: [{ position: 10 }] FcstAmt,
  @UI.lineItem: [{ position: 20 }] ActAmt,
  @UI.lineItem: [{ position: 30, criticality: 'CheckCrit' }] CheckText
}

⑥ 권한(DCL) — 집계 전에 항목 단계에서 건다

회사코드 단위 표준 권한 객체로 보이는 행을 제한합니다. 집계 결과에만 권한을 걸면 전사 합계와 자기 몫의 차이로 다른 회사 숫자가 드러나므로, 반드시 항목 단계 뷰에 걸어야 합니다.

@EndUserText.label: '예측 항목 — 회사코드 권한'
@MappingRole: true
define role ZC_FcstVarLine {
  grant select on ZC_FcstVarLine
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — 화면이 부르는 것만 공개한다

화면이 실제로 부르는 엔티티셋과 펑션만 공개합니다. 서비스 바인딩은 OData V2 UI 서비스로 게시하며, 앱의 manifest 서비스 주소를 이 바인딩 주소로 바꾸면 샘플 데이터에서 실제 데이터로 넘어갑니다.

@EndUserText.label: '예측 대비 실적 차이 점검'
define service ZUI_FcstVar {
  expose ZC_FcstVarLine as LineSet;
  expose ZC_FcstVarWeek as WeekSet;
  expose ZC_FcstVarCat  as CatSet;
  expose ZC_FcstVarRecon as ReconSet;
}
/* 바인딩: OData V2 - UI. 게시 후 서비스 주소를 앱 설정에 넣는다. */

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

예측 항목이 수백 건인 지금과 달리 운영에서는 항목이 수만 건까지 늘 수 있습니다. 집계는 큐브(회사·주 단위)에서 하고 항목 목록은 조회 구간과 회사를 필수 필터로 걸어 필요한 만큼만 받습니다. 항목·실적 연결 키 컬럼에는 인덱스를, 서비스에는 최대 건수 상한을 둡니다. 응답 시간 기준은 환경마다 달라 확인 필요로 남겼으며, 합의하기 전에는 구간을 8주로 제한한 기본값을 유지하는 편이 안전합니다.

자주 묻는 질문

도입 검토에서 자주 받는 질문들입니다. 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 조작

분석 관점

도입과 운영