단기 자금 예측 정확도 다차원 분석 — SAP 자금 솔루션, 예측이 어긋난 이유를 요인까지 한 화면에서 점검

Q: 차이는 어떻게 계산됩니까? 부호는 어떻게 읽습니까?

칸마다 차이 = 실적 − 예측, 차이율 = 차이 ÷ |예측| 입니다. 순현금흐름은 유입을 +, 유출을 −로 합친 값이라, 차이가 음수이면 실적이 예측보다 덜 들어왔거나 더 나갔다는 뜻입니다. 색은 부호가 아니라 자금 영향 방향으로 입힙니다. 현금 유출 칸에서 실적이 예측보다 작으면 차이는 음수지만 자금에는 좋은 쪽이라 초록입니다. 금액 차이와 비율 차이를 둘 다 기준(기본 10백만원 · 5%) 이상 넘을 때만 칠하므로, 색이 없는 칸은 ‘기준에 못 미쳤다’는 뜻이지 ‘맞았다’는 뜻은 아닙니다.

Q: 여섯 요인은 무엇이고 합이 정말 총차이와 같습니까?

입금 시기 · 지급 시기 · 금액(외화 기준) · 환율 가정 · 예측에 없던 흐름 · 실현되지 않은 예측입니다. 같은 키에 실적과 예측이 모두 있으면 시기 · 금액 · 환율로, 실적에만 있으면 ‘예측에 없던 흐름’으로, 예측에만 있으면 ‘실현되지 않은 예측’으로 가릅니다. 이 글의 샘플에서는 −13,920.2 · −11,151.6 · +2,168.1 · +79.6 · +8,420.2 · −4,210.6 을 더하면 총차이 −18,614.5 백만원과 같고, 화면은 이 검산을 조회할 때마다 다시 합니다. 합이 어긋나면 ‘점검 필요’로 표시되며, 그때는 범위 조건과 환율 설정을 확인해야 합니다.

Q: 예측 시점 W1 · W2 · W4 는 무슨 뜻입니까?

기간 시작 기준 1주 · 2주 · 4주 전에 확정한 예측입니다. 같은 기간의 실적을 세 예측과 각각 비교해 오차율을 구합니다. 샘플에서는 1주 전 1.48%, 2주 전 3.29%, 4주 전 4.43% 로 멀수록 오차가 커졌습니다. 이 비교가 되려면 확정 시점의 예측을 따로 보관해야 합니다. 표준 화면은 현재 예측만 보여 주는 경우가 많으므로, 운영 전환 때 스냅샷을 어떻게 쌓을지 먼저 정해야 합니다(확인 필요).

Q: 외화 금액과 환율은 어떻게 처리합니까?

화면의 금액은 원화 환산 값이고, 환산은 서비스(운영에서는 CDS 큐브)에서 합니다. 외화 금액 × 환율 = 원화가 되는지는 대사식으로 따로 검산합니다(샘플 4,631건, 5자리 반올림 허용). 환율 가정에서 생긴 몫은 여섯 요인 중 ‘환율 가정’으로 분리됩니다. 어떤 환율 유형을 어느 기준일에 쓸지는 회계팀과 합의해야 합니다. 표준 화면과 환율 유형이 다르면 같은 거래도 원화 금액이 달라질 수 있으므로, 운영 전환 때 가장 먼저 대조할 항목입니다.

Q: 칸의 금액과 원천 라인 합계가 정말 같습니까?

큐브가 라인을 더해 만든 값이라 같아야 합니다. 칸을 누르면 원천 라인 창이 열리고 맨 위에 건수와 합계가 적히며, 칸 금액과 같은지 ‘일치’ 또는 ‘점검 필요’로 표시합니다. 샘플에서는 칸 40개를 대조해 모두 같았습니다. 다만 이는 이 샘플 데이터에서의 결과입니다. 운영 데이터에서 같은지는 전환 때 다시 돌려 확인해야 합니다.

Q: 처음 쓰는 사람은 무엇부터 눌러야 합니까?

모든 조회 조건에 기본값이 있어 비워 둔 채 조회 버튼만 눌러도 됩니다. 조회하면 위쪽 카드, 트리 표, 오른쪽 차트가 한 번에 채워집니다. 그다음 차원 보관함의 칩을 행 축이나 열 축으로 끌어다 놓으면 표가 바로 다시 묶입니다. 예측과 비교하려면 예측 시점을 고르고 예측 차이 스위치를 켭니다.

Q: 축을 바꿀 때마다 서버를 다시 부릅니까?

아닙니다. 조회할 때 큐브를 한 번 읽어 두고, 축을 바꾸는 일은 그 자료를 화면에서 다시 묶는 일입니다. 그래서 축을 바꿔도 합계가 갈라질 자리가 없고 응답도 빠릅니다. 서버를 다시 부르는 때는 칸을 눌러 원천 라인을 읽을 때와 요인 분해 · 해설 · 에이전트 함수를 부를 때뿐입니다.

Q: 축이나 열을 몇 단계까지 쌓을 수 있습니까?

열 조합은 36개, 표의 행은 2,000개까지 그립니다. 그보다 크면 표가 읽히지 않으므로 화면이 그리지 않고 ‘범위를 줄이라’는 안내를 보입니다. 값 필터에서 여러 값을 골라 범위를 좁히면 다시 그려집니다. 한계에 걸렸다고 숫자가 틀린 것은 아닙니다.

Q: 휴대폰이나 좁은 화면에서도 쓸 수 있습니까?

창이 좁으면 카드가 줄바꿈되고 차트가 표 아래로 내려옵니다. 표는 가로로 스크롤됩니다. 같은 리포트를 보되 한 번에 보이는 양이 줄어드는 것이므로, 축을 짜는 작업은 넓은 화면이 편합니다.

Q: 짜 둔 축은 다음에도 남습니까?

이름을 붙여 보기로 저장할 수 있고, 기본 보기와 ‘열 때 바로 조회’를 지정하면 다음에 열 때 그 배치로 시작합니다. 변동 사유는 보기와 별개로 조회 범위와 행 경로에 묶여 저장되므로 축을 바꿔도 같은 행이면 사유가 따라옵니다.

소개 영상블로그 목차 순서대로 · 자막 포함

도입 포인트 — 이 앱을 사용해야 하는 이유

자금 회의의 질문은 늘 같습니다. 예측이 얼마나 빗나갔나, 왜 빗나갔나, 다음 주 예측에서 무엇을 고쳐야 하나. 지금 이 세 답은 표준 현금 포지션 · 유동성 예측 화면, 담당자가 가진 엑셀, 은행 명세 확인 메모로 흩어져 있습니다. 이 화면은 세 답을 한 화면에 붙여, 예측 정확도를 점검하는 손일을 줄입니다.

자금 포지션과 자금 예측은 회계기준서가 정한 요구사항이 아니라 자금 운용의 관리 영역이라, 이 글은 기준서를 붙이지 않고 대상 영역(자금 포지션 · 자금 예측)으로 설명합니다. 화면은 분류 · 집계 · 대사를 돕는 점검 도구이고, 최종 판단은 회사와 감사인이 합니다.

한 줄 요약 — 예측 대비 실적 표는 누구나 만듭니다. 이 화면의 값은 그 다음에 있습니다: 차이를 시기 · 금액 · 환율 같은 요인으로 가르고, 예측 시점별 오차를 나란히 놓고, 사유를 행에 남기고, 그 숫자가 원천 라인과 어긋나지 않는지 매번 검산합니다.

핵심 포인트 여덟 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 숫자가 갈라지지 않는 피벗	사업부 · 자금 항목 · 통화 · 거래처 그룹 · 기간을 끌어다 놓아 행과 열을 짭니다. 모든 축이 한 번 읽은 같은 큐브에서 나와 합계가 어긋날 자리가 없습니다.	축마다 시트를 따로 만들고, 합계가 다르면 시트를 맞추는 일부터 합니다.
② 예측 시점별 오차를 나란히	1주 · 2주 · 4주 전 예측을 같은 범위에서 비교해, 예측이 멀수록 얼마나 어긋나는지 오차율로 봅니다.	예측 파일을 시점마다 따로 보관하고 손으로 맞붙입니다.
③ 차이를 여섯 요인으로	입금 시기 · 지급 시기 · 금액 · 환율 가정 · 예측에 없던 흐름 · 실현되지 않은 예측으로 가르고, 합이 차이와 맞는지 검산합니다.	총차이만 보고 원인은 담당자에게 묻습니다.
④ 칸에서 원천 라인까지 한 번에	숫자를 누르면 그 값을 이룬 전표 · 은행 거래 라인이 열리고, 합계가 칸 값과 같은지 바로 보입니다.	표준 화면을 다시 열어 조건을 손으로 맞춥니다.
⑤ 차이 사유가 행에 남는다	사유가 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도 다음 달에도 따라옵니다.	같은 질문을 매달 다시 하고 지난 답은 메일에서 찾습니다.
⑥ 사람이 열지 않아도 도는 점검	감시 규칙 네 개가 보는 사람(자금 · 재무 · 경영 · 회계)별로 걸린 항목을 대기함에 올립니다. 하루 한 번 제한은 서비스가 지킵니다.	숫자가 어긋난 날 아무도 화면을 열지 않으면 그대로 지나갑니다.
⑦ 숫자는 서비스가, 문장은 초안으로	금액 · 비율은 서비스가 계산하고 해설 문장은 그 숫자 위에 규칙으로 만든 초안입니다. 근거 표로 숫자를 대조합니다.	문장과 숫자가 따로 놀아 다시 확인해야 합니다.
⑧ 결재용 보고서를 바로	지금 보는 범위로 표와 차트를 담은 PowerPoint 를 브라우저에서 만듭니다.	화면을 캡처해 붙이고 숫자를 옮겨 적습니다.

사례로 보는 효과 — 예측과 실적의 차이는 어디서 났나

검증용 샘플 데이터(가상 회사 두 곳 · 2026년 1~9월)에서 2주 전 예측을 기준으로 보면, 순현금흐름 실적은 −242,194.8 백만원, 예측은 −223,580.3 백만원으로 차이는 −18,614.5 백만원(−8.3%)입니다. 표준 화면은 여기까지 말해 줍니다.

여섯 요인으로 가르면 이야기가 달라집니다. 가장 큰 몫은 금액 차이(외화 기준) −13,920.2와 입금 시기 차이 −11,151.6이고, 지급 시기 +2,168.1 · 환율 가정 +79.6 · 실현되지 않은 예측 +8,420.2 가 일부를 되돌려 놓으며 예측에 없던 흐름이 −4,210.6 입니다. 합은 −18,614.5 로 총차이와 같고 검산은 0 입니다. 환율이 아니라 입금이 늦어지고 금액이 달랐다는 점이 다음 예측에서 고칠 자리입니다.

예측 시점별 오차율은 1주 전 1.48%, 2주 전 3.29%, 4주 전 4.43% 로 멀수록 커집니다. 이 글의 숫자는 모두 가상 회사의 샘플 값입니다.

도입하면 달라지는 것

예측 점검 준비 — 파일 취합과 캡처 대신 같은 화면에서 차이 · 요인 · 사유 · 보고서가 나옵니다.
회의의 주제 — “어느 예측 파일이 맞나”가 아니라 “입금 일정을 어떻게 더 정확히 받을까”를 이야기합니다.
다음 주로 이어지는 기록 — 사유와 보기가 남아 같은 설명을 반복하지 않습니다.
놓치는 날이 없는 점검 — 아무도 열지 않은 날에도 규칙에 걸린 항목은 대기함에 올라갑니다.

이런 회사에 맞습니다

여러 통화(원화 · 달러 · 유로 · 엔 · 위안)로 입출금이 오가고 법인이 둘 이상이며, 자금팀이 주간 · 월간 자금 예측을 엑셀로 관리하는 제조 · 무역 회사에 맞습니다. 사업부와 거래처 그룹별로 예측이 어긋나는 곳을 찾고 싶은 자금팀, 그리고 그 숫자를 설명해야 하는 경영지원 조직이 주 사용자입니다.

실행 화면

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

사용 방법

조회 조건을 정합니다. 맨 위 조회 조건 줄에 회사 · 기간(부터/까지) · 예측 시점 · 금액 단위가 있습니다. 모두 기본값이 있어 필수로 채울 칸은 없고, 회사(기본 전체 회사)와 예측 시점(기본 비교 안 함)이 선택 조건입니다.
조회합니다. 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 조건 칸에서 Enter 키를 누릅니다. 저장한 보기에 열 때 바로 조회를 지정했다면 화면을 열 때 자동으로 조회합니다.
요약을 확인합니다. 위쪽 카드(현금 유입 · 현금 유출 · 순현금흐름 · 실적 − 예측 · 지출 비율)로 전체 규모를 보고, 보는 사람 탭(경영 · 재무 · 자금 · 회계)으로 역할별 첫 화면을 바꿉니다.
축을 옮깁니다. 차원 보관함의 칩을 행 축이나 열 축으로 끌어다 놓습니다. 측정값과 값 필터로 볼 숫자와 범위를 고르고, 모두 펼치기 · 접기로 트리를 엽니다.
예측과 비교합니다. 예측 시점을 고르고 예측 차이 스위치를 켜면 칸마다 실적 · 예측 · 차이 · 차이율이 붙습니다. 금액 기준과 비율 기준을 둘 다 넘는 칸만 색이 입혀집니다.
행이나 칸을 누릅니다. 행을 누르면 오른쪽에 요인 분해가, 칸을 누르면 원천 라인 창이 열립니다. 변동 사유 · 해설 · 에이전트 · 기간별 요약은 도구줄 버튼으로 엽니다.
내보내고 저장합니다. CSV 버튼으로 표를 내려받고, 보기 저장으로 짜 둔 배치를 이름을 붙여 남깁니다. 해설 창의 보고서 버튼은 PowerPoint 를 만듭니다.

무엇으로 만들었나

화면은 OData V2 서비스 하나를 읽고, 서비스는 큐브 · 예측 · 차원 값 · 측정값 · 계산항목 · 기간 요약을 엔티티셋으로, 요인 분해 · 시점 비교 · 해설 · 에이전트를 함수로 내려 줍니다. 이 글의 화면은 가상 회사 샘플을 담은 서비스를 읽고 있으며, 운영에서는 아래 CDS 구성으로 만든 서비스로 주소만 바꿉니다.

자리	무엇	왜 그렇게 두었나
화면 컨트롤	표준 OpenUI5 컨트롤(sap.m · sap.ui.table 의 트리 표)과 직접 그린 SVG 차트	외부 차트 라이브러리 없이 사내망에서도 같은 화면이 뜹니다.
재묶음 로직	한 번 읽은 큐브를 브라우저에서 다시 묶는 모듈 하나(축 · 측정값 · 계산항목 평가)	축을 바꿀 때마다 서버를 부르지 않아 빠르고, 합계가 한 곳에서만 나옵니다.
집계 · 판정 로직	요인 분해 · 예측 시점 비교 · 해설 · 에이전트 판정은 서비스 쪽 계산 모듈이 맡음	화면은 값을 읽기만 하므로 계산 규칙을 서비스에서만 바꿀 수 있습니다.
데이터 연결	manifest 에 선언한 OData V2 서비스 하나(이름 없는 기본 모델)에 엔티티셋으로 바인딩	서비스 주소를 코드에 박지 않아 운영 서비스로 바꿀 때 선언만 고치면 됩니다.
쓰기 범위	변동 사유 · 저장한 보기 · 에이전트 기록만 서비스에 씀	나머지는 조회 전용이라 원천 숫자를 건드릴 수 없습니다.
테마	sap_horizon	SAP 표준 화면과 같은 시각 언어로 이어 보입니다.

앱 정보

항목	내용
솔루션	자금 솔루션
업무 영역	단기 자금 예측 · 유동성 관리
관련 기준서 · 대상 영역	- · 자금 포지션 · 자금 예측
SAP 표준 T-code	FF7A · FF7B · FEBAN · FBL3N
화면 성격	다차원 분석 리포트(조회 중심, 사유 · 보기 · 에이전트 기록만 쓰기)
데이터 연동	OData V2 서비스
테마	sap_horizon

SAP 표준 기능을 그대로 이어받은 부분 — 현금 포지션 · 유동성 예측의 데이터 구조와 은행 명세 · 계정 라인 같은 표준 데이터를 그대로 읽습니다. 이 화면은 그 위에서 예측 시점 비교와 요인 분해 같은 점검 관점을 더해 확장하고, 표준 실행은 SAP 표준 T-code 가 계속 담당합니다.

처음 열었을 때 — 한 화면에 모두

조회 조건 · 카드 · 레이아웃 보드 · 표와 차트가 한 화면에 올라옵니다. 처음 연 화면부터 조회 직후까지를 순서대로 보여 드립니다.

**조회 전 — 조건과 빈 틀** — 조건을 정하고 조회하기 전의 첫 화면입니다.

회사 · 기간(부터/까지) · 예측 시점 · 금액 단위 네 가지 조건이 맨 위에 있고 조회 버튼이 같은 줄 오른쪽 끝에 있습니다. 표와 차트는 비어 있으며, 조회를 누르면 채워진다는 안내만 보입니다. 모든 조건에 기본값이 있어 비워 둔 채 바로 조회해도 됩니다.

**조회 직후 — 카드 · 축 · 표 · 차트** — 조회하면 위쪽 카드, 축 영역, 트리 표, 오른쪽 차트가 한 번에 채워집니다.

카드는 현금 유입 495,509.5 · 현금 유출 737,704.4 · 순현금흐름 −242,194.8 · 실적 − 예측 −18,614.5(−8.3%) · 지출 비율 148.9% 이며 단위는 백만원입니다. 기본 배치는 행 축이 활동 구분 › 자금 항목, 열 축이 분기입니다. 조회 조건 줄은 접혀 한 줄 요약으로 남습니다.

**레이아웃 보드 — 차원 보관함** — 차원 보관함, 행 축, 열 축 세 칸이 레이아웃 보드입니다.

보관함에는 회계기간 · 회사 · 사업부 · 통화 · 거래처 그룹 · 입출 구분 · 예측 적중 구분 · 측정값 칩이 있고, 칩을 끌어 행이나 열 칸에 놓으면 표가 바로 다시 묶입니다. 칩의 × 는 축에서 빼는 버튼입니다. 측정값 선택과 값 필터, 예측 차이 스위치, 기준 금액·비율, 표 행 수, 금액 단위가 보드 아래 한 줄에 모여 있습니다.

**축을 끌어다 놓은 뒤** — 열 축에 사업부를 더하면 분기마다 사업부별 값이 한 단 더 생깁니다.

같은 큐브를 다시 읽지 않고 화면에서 다시 묶으므로 눈에 띄는 대기 시간이 없습니다. 합계 열은 축을 어떻게 바꿔도 그대로이며, 이 값이 달라지면 그것이 점검 신호입니다.

**조회 조건을 접은 모습** — 조회 후에는 조건 줄이 한 줄 요약으로 접혀 표가 넓어집니다.

요약 줄에는 회사 · 기간 · 예측 시점 · 금액 단위가 적혀 지금 보는 범위를 잊지 않게 합니다. 펼치면 같은 조건 칸이 다시 나타나 고쳐서 다시 조회할 수 있습니다.

보는 사람마다 먼저 보는 숫자 — 경영 · 재무 · 자금 · 회계

같은 큐브를 역할마다 다른 눈으로 읽도록 탭을 둡니다. 탭을 바꾸면 기본 측정값과 안내 문구가 바뀝니다.

**경영 요약** — 경영 탭 — 활동별 순흐름이 실제 유동성에 얼마나 닿았는지를 봅니다.

역할 탭을 바꾸면 안내 문구와 기본 측정값이 그 역할에 맞게 바뀝니다. 경영 탭은 활동 합계 기준의 현금 순증감을 먼저 보여 줍니다.

**재무 요약** — 재무 탭 — 잉여 현금흐름과 지출 비율이 예측과 얼마나 달랐는지를 봅니다.

측정값에 계산항목(잉여 현금흐름 · 지출 비율)이 함께 올라와 열이 두 줄 머리로 나뉩니다. 지출 비율은 퍼센트로, 금액은 선택한 단위로 표시됩니다.

**자금 요약** — 자금 탭 — 가용 자금을 흔드는 시기·금액 차이를 먼저 봅니다.

자금 담당 관점의 문구와 에이전트 규칙(입금 시기 임계)이 이 탭과 연결됩니다. 표 구성은 같고 먼저 보는 숫자만 달라집니다.

**회계 요약** — 회계 탭 — 표의 값과 원천 라인 합계가 맞는지, 예측과 대사되는지를 봅니다.

측정값에 원천 라인 수를 올리면 활동 구분별 라인이 몇 건인지(합계 4,631건) 같이 보입니다. 건수는 숫자가 어디서 왔는지를 가늠하는 가장 빠른 방법입니다.

축 전환과 범위 — 끌어다 놓고 좁힌다

행 축 · 열 축은 최대 몇 단계로 쌓을 수 있고, 값은 여러 개씩 골라 좁힙니다. 이 모든 조작이 서버를 다시 부르지 않고 화면에서 처리됩니다.

**열 축 두 단계** — 열 축에 분기와 사업부를 쌓아 두 단계 머리를 만든 모습입니다.

열 조합이 36개를 넘으면 표를 그리지 않고 줄이라는 안내를 보입니다. 한 번에 보여 줄 수 있는 범위를 화면이 스스로 지킵니다.

**값 필터 — 여러 값 한꺼번에** — 사업부 같은 차원은 값을 여러 개 골라 범위를 좁힙니다.

목록에는 값마다 원천 라인 수(소재 581 · 부품 492 …)가 붙어 있어 어느 값이 큰지 알고 고를 수 있습니다. 같은 차원 안에서는 또는, 다른 차원 사이에서는 그리고 로 묶입니다.

**좁힌 결과** — 사업부 둘로 좁히면 카드와 표, 차트가 모두 그 범위로 다시 계산됩니다.

필터가 걸린 동안 필터 버튼에 걸린 개수가 표시됩니다. 카드의 순현금흐름이 −147,187.2 로 바뀐 것에서 범위가 좁혀졌음을 바로 알 수 있습니다.

**표와 차트의 너비 손잡이** — 표와 차트 사이 손잡이를 끌어 너비를 나눕니다.

나눈 비율은 그 브라우저에 남아 다음에 열어도 유지됩니다. 숫자가 많은 표는 넓게, 흐름을 볼 때는 차트를 넓게 두는 식입니다.

칸에서 원천 문서까지 — 숫자를 의심할 때

표의 칸을 누르면 그 값을 만든 전표 · 은행 거래 라인으로 내려갑니다. 합계가 같은지 그 자리에서 확인합니다.

**칸을 누르면 원천 라인으로** — 표의 칸을 누르면 그 값을 이룬 원천 라인 창이 열립니다.

영업활동 2026-2Q 칸의 라인이 1,477건 나오고, 표의 값 −63,302.3 백만원과 원천 합계가 일치한다는 표시가 맨 위에 붙습니다. 라인에는 전기일 · 전표 · 예측 적중 구분 · 사업부 · 자금 항목 · 통화 · 외화 금액 · 환율 · 원화 금액이 있습니다.

**원천 라인 — 다른 칸** — 투자활동 2026-1Q 칸에서 연 원천 라인입니다.

라인 86건, 표의 값 −24,009.4 백만원과 원천 합계가 일치합니다. 외화 라인은 외화 금액에 환율을 곱한 원화 금액이 오른쪽에 있어 환산을 눈으로 확인할 수 있습니다.

**기간별 요약** — 기간별 요약은 월별 유입 · 유출 · 순현금흐름 · 예측 · 차이를 한 표에 보입니다.

1월 −46,096.7 대 예측 −31,969.3 처럼 월마다 차이와 차이율이 나옵니다. 값은 서비스가 큐브에서 계산해 돌려준 것이라 화면의 표와 같은 합계입니다.

계산항목 — 식으로 만든 행과 열

순흐름 합계 · 잉여 현금흐름 · 지출 비율 같은 파생 값은 서비스가 식을 내려 주고 화면은 그 식을 풀어 계산합니다.

**계산항목을 행으로** — 영업 · 투자 · 재무 순흐름과 현금 순증감, 잉여 현금흐름을 행으로 세웁니다.

계산항목은 서비스가 알려 주는 토큰 식(예: 영업 + 투자)을 그 칸의 줄들 위에서 풀어 계산합니다. 식을 화면에 박아 두지 않으므로 새 식은 서비스에서만 추가하면 됩니다.

**계산항목을 열로** — 지출 비율과 일평균 순현금흐름을 열로 세운 모습입니다.

분기별 지출 비율이 153.88% 처럼 퍼센트로 나오고, 일평균은 기간 일수로 나눈 값입니다. 계산이 불가능한 칸은 0 이 아니라 − 로 비워 둡니다.

예측 대비 차이 — 같은 표가 자금 회의 자료가 된다

예측 시점을 고르고 예측 차이를 켜면 같은 표가 예측 대비 점검표가 됩니다. 차이가 난 행에는 사유를 적어 둡니다.

**예측 차이 — 실적 · 예측 · 차이 · 차이율** — 예측 차이 스위치를 켜면 모든 칸에 네 값이 나란히 붙습니다.

거래처 그룹 › 통화를 행으로 두면 해외 계열사군이 −15,397.0(−22.8%)으로 가장 크게 어긋났다는 것이 한눈에 보입니다. 색은 금액과 비율이 둘 다 기준(10백만원 · 5%)을 넘을 때만 입혀집니다.

**변동 사유 — 숫자 옆에 이유를 적는다** — 차이가 난 행에 사유를 구분과 함께 적어 저장합니다.

사유의 키는 조회 범위와 행 경로이고 축 배치가 아닙니다. 그래서 축을 바꾸거나 트리를 다시 펼쳐도 같은 행이면 사유가 따라옵니다. 사유가 적힌 행에는 연필 표시가 붙습니다.

차이 요인분해 — 왜 어긋났는지

예측에서 실적까지의 순흐름 차이를 입금 시기 · 지급 시기 · 금액 · 환율 · 예측에 없던 흐름 · 실현되지 않은 예측 여섯 요인으로 나눕니다.

**차이 워터폴과 요인 표** — 행을 고르면 오른쪽에 예측에서 실적까지의 워터폴과 요인 표가 나옵니다.

투자활동의 예측 −76,789.9 가 입금 시기 −165.9 · 지급 시기 +1,212.5 · 금액 −1,042.1 · 환율 −78.7 · 예측에 없던 흐름 +443.5 · 실현되지 않은 예측 +1,280.7 을 거쳐 실적 −75,139.7 에 이릅니다. 아래 검산 줄이 합이 맞는지 보여 줍니다.

**요인 표와 예측 시점별 오차** — 요인 표 아래에 예측 시점별 오차가 함께 나옵니다.

1주 전 예측의 오차율 2.12%, 2주 전 2.83%, 4주 전 5.52% 로 예측이 멀수록 어긋남이 커지는 것이 한 표에 보입니다. 지금 조회에 쓴 시점에는 점이 붙고, 오차율은 여섯 요인의 절대값 합을 예측 흐름 규모로 나눈 값입니다.

해설과 보고서 — 숫자는 서비스가, 문장은 초안으로

지금 범위의 숫자를 문장으로 읽어 주고, 같은 범위의 PowerPoint 보고서를 만들어 줍니다.

**해설 창** — 해설 창은 지금 범위의 숫자를 문장 초안으로 읽어 줍니다.

묶는 기준과 보는 사람을 고르면 범위 요약과 핵심 발견이 나옵니다. 문장은 규칙으로 만든 초안이며 숫자는 서비스가 계산한 값이라는 안내가 맨 위에 있습니다. 이미 사유가 적힌 행은 건너뜀으로 표시됩니다.

**해설의 근거 표** — 근거 표를 펼치면 해설에 쓴 숫자가 그대로 나옵니다.

구분별 예측 · 실적 · 차이가 표로 나와 문장의 숫자를 하나씩 대조할 수 있습니다. 문장이 아니라 근거 표가 기준입니다.

**보고서 PPTX 내려받기** — 해설 창의 보고서 버튼은 같은 범위의 PowerPoint 를 브라우저에서 바로 만듭니다.

표지 · 요약 · 핵심 발견 · 표 · 워터폴 차트 · 근거가 담기며 서버에 파일을 남기지 않습니다. 내려받았다는 안내가 화면 아래에 잠깐 뜹니다.

AI 에이전트 — 사람이 열지 않아도 점검

감시 규칙에 걸린 항목을 받을 사람의 눈으로 적어 대기함에 올립니다. 판단과 기록은 서비스에 있습니다.

**에이전트 — 감시 규칙** — 에이전트 창에 감시 규칙 네 개가 보는 사람과 함께 적혀 있습니다.

입금 시기 어긋남은 자금, 예측에 없던 흐름은 재무, 순흐름 예측 오차는 경영, 환율 가정 차이는 회계가 받습니다. 아직 실행 전이면 대기함이 비어 있습니다.

**에이전트 — 지금 실행** — 지금 실행을 누르면 규칙을 판정하고 결과를 안내합니다.

규칙 4개 중 4건이 걸렸다는 안내와 함께, 같은 날 두 번째 실행은 서버가 막는다는 설명이 보입니다. 하루 한 번 제한은 화면이 아니라 서비스가 판정합니다.

**에이전트 — 대기함과 활동 기록** — 걸린 항목이 대기함에 올라가고 실행 이력이 남습니다.

입금 시기 차이 −111.52억원 · 예측에 없던 흐름 −42.11억원 · 순흐름 차이 −186.14억원 · 환율 가정 차이 +7,956만원이 각 규칙의 보는 사람 기준 문장으로 적혀 있습니다. 아래 활동 기록에는 첫 실행 완료와 두 번째 실행 제한이 남습니다.

보기 저장과 복원 — 짜 둔 축을 다음에도

축 배치를 이름을 붙여 저장하고, 기본 보기와 열 때 바로 조회를 지정합니다.

**현재 보기 저장** — 지금의 축 배치를 이름을 붙여 보기로 저장합니다.

이름과 함께 다음에 열 때 이 보기로 시작할지, 열면 바로 조회할지를 고릅니다. 내용에는 저장될 배치(행 · 열 · 측정값 · 예측 차이)가 한 줄로 적혀 있습니다.

**저장한 보기 관리** — 저장한 보기를 적용 · 기본으로 · 자동 조회 · 이름 바꾸기 · 삭제합니다.

목록에서 한 번에 바꿀 수 있고, 기본 보기는 화면을 열 때 그 배치로 시작합니다.

**보기 복원** — 저장한 보기를 고르면 그 배치로 표와 차트가 바로 돌아옵니다.

거래처 그룹 › 통화, 열 분기, 예측 차이 켬 상태가 그대로 복원되고 적용했다는 안내가 뜹니다.

**열 때 바로 조회** — 기본 보기에 자동 조회를 지정하면 화면을 열자마자 결과가 나옵니다.

정기 점검 화면으로 쓸 때 조회 버튼을 한 번 덜 누르게 됩니다.

좁은 화면과 한계

작은 화면에서도 같은 리포트를 보고, 너무 큰 범위는 화면이 먼저 막습니다.

**좁은 화면 — 차트가 아래로** — 창이 좁으면 차트를 감추지 않고 표 아래로 내려 보냅니다.

휴대폰 폭(390px)에서도 같은 카드와 표, 같은 차트를 위아래로 봅니다. 기능을 줄이는 것이 아니라 배치만 바꿉니다.

**범위 상한 안내** — 열이 너무 많거나 행이 너무 많으면 표 대신 줄이라는 안내를 보입니다.

열 조합 54개가 36개 상한을 넘으면 어느 축을 줄여야 하는지 알려 줍니다. 아주 큰 범위를 그리려다 화면이 멈추는 일을 막기 위한 상한입니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 위의 화면들이 어떤 규칙으로 움직이는지를 자리별로 적었습니다.

조회를 누르면 화면은 큐브 · 예측 · 차원 값 · 측정값 · 계산항목을 엔티티셋으로 한 번씩 읽어 둡니다. 이후 축 전환 · 값 필터 · 계산항목은 모두 이 자료를 화면에서 다시 묶어 처리하고, 서버를 다시 부르는 것은 칸을 눌러 원천 라인을 읽을 때와 요인 분해 · 해설 · 에이전트 같은 함수를 부를 때뿐입니다.

요인 분해는 선택한 범위의 실적과 선택한 예측 시점의 예측을 같은 차원 키로 맞붙입니다. 같은 키에 양쪽이 있으면 시기(입금 · 지급) · 금액 · 환율로, 실적에만 있으면 예측에 없던 흐름으로, 예측에만 있으면 실현되지 않은 예측으로 갈라, 여섯 요인의 합이 총차이와 같도록 구성합니다.

에이전트는 감시 규칙을 하나씩 평가해 걸린 항목을 대기함 엔티티셋에 쓰고 실행 기록을 남깁니다. 하루 한 번 제한은 기록의 날짜로 서비스가 판정하므로, 화면을 여러 개 열어도 같은 날 두 번 돌지 않습니다.

판정 규칙과 사용자 조치

화면이 어떤 조건에서 무엇을 보여 주고, 사용자가 무엇을 확인하면 되는지를 정리했습니다. 표시는 확인을 요청하는 것이지 최종 판정이 아닙니다.

처리	판정 조건	결과 상태	사용자 조치
예측 차이 칸 색	금액 차이와 비율 차이가 둘 다 기준(기본 10백만원 · 5%) 이상	지표 방향이 좋은 쪽이면 초록, 나쁜 쪽이면 빨강 · 한쪽만 넘으면 칠하지 않음	빨강 칸의 행을 눌러 요인을 확인
요인 검산	예측 + 여섯 요인 합 − 실적 = 0	0 이면 정상, 아니면 점검 필요	범위 조건과 환율 확인 필요
원천 일치	칸의 값 = 원천 라인 합계	일치 / 점검 필요 표시	계산항목 식과 단위 설정 확인 필요
에이전트 규칙	지표가 임계값을 넘음(입금 시기 ≤ −300백만원 · 미예측 흐름 절대값 ≥ 1,000백만원 · 순흐름 차이 절대값 ≥ 500백만원 · 환율 요인 절대값 ≥ 20백만원)	대기함에 주의 · 경고 항목	근거 숫자를 확인하고 변동 사유를 기록
실행 제한	같은 날 두 번째 실행	서비스가 막고 안내	다음 날 다시 실행

조회조건

필드	필수 · 기본값	의미	서비스 질의
회사	선택(기본 전체 회사)	회사 코드 — 다중 선택	`Bukrs eq …`
기간(부터/까지)	기본 2026년 1월~9월	회계기간 범위	`Period ge … and Period le …`
예측 시점	선택(기본 비교 안 함)	W1(기간 시작 1주 전) · W2(2주 전) · W4(4주 전)	`Version eq …`
금액 단위	기본 백만원	표시 단위만 바꿈(계산은 원화)	-

결과 컬럼

컬럼	의미 · 산출식
실적 · 예측 · 차이 · 차이율	칸마다 네 값. 차이 = 실적 − 예측, 차이율 = 차이 ÷ \|예측\|
순현금흐름	유입은 +, 유출은 −(자금 영향 방향)의 원화 환산 합
현금 유입 · 현금 유출	원화 환산 유입 · 유출(유출은 양수 표시)
원천 라인 수	칸을 이룬 은행 거래 · 전표 라인 건수
지출 비율	현금 유출 × 100 ÷ 현금 유입
일평균 순현금흐름	순현금흐름 ÷ 기간 일수

좁은 화면에서 달라지는 것

창이 좁으면 위쪽 카드가 줄바꿈되고, 표와 차트가 가로로 나란히 놓이지 않고 위아래로 쌓입니다. 표는 가로로 스크롤되며 도구줄 버튼은 한 줄씩 넘어갑니다. 열 조합이 36개를 넘거나 행이 2,000개를 넘으면 좁은 화면이든 아니든 표 대신 줄이라는 안내를 보입니다.

파일 구성

앱 폴더/
├─ index.html · Component.js · manifest.json
├─ controller/ · view/ (본체 + 팝업 8개)
├─ model/ (재묶음 · 차트 · 보고서 · 보기 · 서식 · 오류 안내)
├─ css/ · i18n/
├─ odata/ (서비스 정의 · 계산 모듈 · 엔티티셋 자료)
├─ media/ (소개 영상)
└─ readme.html

SAP 표준 기능 확장 포인트

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

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

하고 싶은 일	SAP 표준	이 앱이 더하는 관점
예측 현금 흐름을 보는 일	FF7A · FF7B 로 충분	예측과 실적을 같은 차원으로 맞붙여 어디서 어긋났는지 보는 관점
은행 입출금 근거 확인	FEBAN 등 표준 화면	칸에서 내려간 라인에서 같은 거래를 찾아 표준 화면으로 이동
계정 라인 조회	FBL3N	칸의 합계와 라인 합계의 일치 여부를 한 번에 표시
예측 정확도 분석	표준 화면에는 없음	예측 시점별 오차율과 여섯 요인 분해
차이 사유 기록	전표 적요 등 전표 단위	집계 행(범위 + 행 경로)에 사유를 붙임

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 리포트를 없애야 하느냐”는 질문이 꼭 나오는데, 없애지 않고 병행하는 것을 권합니다 — 법정 · 감사 대응은 표준 화면에 남겨 두는 편이 안전합니다.

T-code	이름	연계
`FF7A`	현금 포지션	예측 현금 흐름의 출발 숫자를 이어받음. 두 화면의 통화별 합계를 비교하는 것이 첫 대사 지점이며, 이 화면의 칸 → 표준 화면으로 원천 확인, 표준 화면 값 → 이 화면의 같은 기간 · 통화 행에서 다시 봅니다.
`FF7B`	유동성 예측	기간별 예측 값을 이어받는 원천. 예측 시점(W1 · W2 · W4)별 값은 확정 시점의 스냅샷을 따로 보관해야 하므로 운영 전환 때 보관 방식을 정해야 합니다.
`FEBAN`	은행 명세 후처리	입출금 라인이 어떤 전표로 후처리되었는지 확인하는 표준 화면. 이 화면에서 내려간 라인의 전기일 · 금액으로 찾아갑니다.
`FBL3N`	G/L 계정 라인 아이템	전표 라인을 계정 기준으로 보는 표준 화면. 칸의 합계와 같은 계정의 라인 합계를 맞춰 봅니다.

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

표준 CDS 분석 쿼리 · Fiori 분석 앱 · Analysis for Office 는 정해진 보고서 정의 안에서 축을 바꾸는 데 강합니다. 이 화면은 그 위에서 예측 시점 비교와 요인 분해, 행에 남는 사유, 규칙 점검처럼 자금 예측 정확도 점검에만 필요한 관점을 더합니다. 표준 Fiori 앱 이름 중 이 글에서 확인하지 못한 것은 적지 않았습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 운영 전환 뒤에도 기존 표준 리포트는 없애지 않고 함께 두는 것을 권합니다 — 법정 · 감사 · 세무 신고 대응은 표준 화면에 남깁니다.

분석 지표 정의

화면에 나오는 지표가 어떤 산식과 기준으로 만들어지는지 정리했습니다.

지표	산식	판정 기준	대응 기능	원천 데이터	비고
차이 · 차이율	차이 = 실적 − 예측 · 차이율 = 차이 ÷ \|예측\|	금액과 비율을 둘 다 기준(기본 10백만원 · 5%) 이상 넘을 때만 색을 입힘	예측 차이 스위치	실적 큐브 · 예측 큐브	기준은 화면에서 조정
예측 시점별 오차율	오차율 = 여섯 요인 절대값의 합 ÷ 예측 흐름 절대값의 합 × 100	시점(W1 · W2 · W4)을 나란히 두고 커지는지 점검	예측 시점 비교	예측 스냅샷	서비스가 계산 · 샘플 1.48% · 3.29% · 4.43%
여섯 요인	입금 시기 · 지급 시기 · 금액 · 환율 가정 · 예측에 없던 흐름 · 실현되지 않은 예측	예측 + 요인 합 − 실적 = 0 이 아니면 점검 필요	요인 분해	실적 · 예측 같은 키 맞붙임	적중 허용 일수는 자금팀과 합의
순현금흐름	유입(+) − 유출(−)의 원화 환산 합	음수 · 양수는 영향 방향으로만 색을 정함	카드 · 표 칸	실적 큐브	환율 유형은 회계팀과 합의
지출 비율	현금 유출 × 100 ÷ 현금 유입	100% 를 넘으면 유출이 유입보다 큼(점검 대상)	카드 · 계산항목	실적 큐브	통화 혼합 시 원화 환산 값
원천 일치	칸의 값 = 원천 라인 합계	일치 / 점검 필요	원천 라인 창	원천 은행 거래 · 전표 라인	대사 상대는 표준 라인 조회 화면

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

손대는 자리	무엇을 정하나	담당 · 확인
항목 매핑	은행 계좌 · 계정 → 자금 항목 · 활동 구분(영업 · 투자 · 재무)	현업(자금팀)이 관리
예측 스냅샷	시점(W1 · W2 · W4)별 확정 예측 보관	자금 예측 확정 절차 확인 필요
환율 유형 · 환산 시점	외화 → 원화 환산에 쓰는 환율 유형과 기준일	회계팀과 합의
예측 적중 구분 규칙	예정대로 · 늦게 · 일찍 · 예정에 없던 · 미실현 판정 기준(허용 일수)	자금팀과 합의
감시 규칙 임계값	네 규칙의 임계값과 받을 사람	경영지원 · 자금
권한	회사 코드 · 사업부 단위 조회 권한	보안 · 권한 담당

권한에서 흔히 놓치는 자리. 집계 화면은 권한이 없어도 합계가 보이는 수가 있습니다. 어떤 사업부 권한이 없는 사람이 전체 합계는 볼 수 있고 드릴스루만 막히면, 뺄셈으로 다른 사업부의 숫자를 알아낼 수 있어 점검이 필요합니다. 그래서 권한은 드릴스루가 아니라 큐브를 읽는 자리에 걸어야 합니다.

CDS 구성

이 글의 화면은 샘플 큐브 1,511행을 브라우저가 들고 묶습니다. 데모라서 되는 일이고, 운영 데이터에서는 집계를 CDS 로 내려야 합니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	`ZCFA_ITEMMAP (매핑 테이블)`	계정 · 은행 계좌를 자금 항목 · 활동 구분에 연결	매핑이 바뀌어도 뷰를 고치지 않으려고
차원	`ZI_CashItem · ZI_CashCounterpartyGroup`	자금 항목 · 거래처 그룹 이름과 정렬	화면의 값 도움말을 서비스가 채우도록
큐브(실적)	`ZI_CashFcstActualCube`	실적 라인을 차원 조합별로 합산	원천 라인에서 한 번만 합산
큐브(예측)	`ZI_CashFcstPlanCube`	예측 시점별 예측 라인을 같은 차원으로 합산	실적과 같은 키로 맞붙이려고
쿼리	`ZC_CashFcstAccQuery`	분석 쿼리 · 필터 · 표시 설정	화면이 읽는 단 하나의 입구
권한	`ZI_CASHFCSTACC (DCL)`	회사 코드 · 사업부 권한 적용	집계 단계에서 걸어 뺄셈으로 새지 않게
서비스	`서비스 정의 · 바인딩`	OData V2 로 게시	화면 선언의 서비스 주소만 바꾸면 되도록

① 항목 매핑 테이블

리포트의 모든 숫자가 이 표에서 갈립니다. 어떤 은행 계좌의 입출금을 영업 · 투자 · 재무 중 어디로 볼지, 어느 사업부와 거래처 그룹에 붙일지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 계좌 체계가 중간에 바뀌어도 지난 기간의 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZCFA_ITEMMAP — 계좌 · 계정 → 자금 항목 · 활동 구분 · 사업부 · 거래처 그룹
"  운영에서는 자금팀이 관리하는 분류표를 그대로 옮겨 담는다.
"  코드에 박지 않는 이유 : 계좌와 계정은 늘 늘어나고, 늘어날 때마다
"  개발자를 부르게 만들면 분류표가 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '자금 항목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " 유지보수 뷰를 함께 만들어 둔다
define table zcfa_itemmap {
  key mandt       : mandt not null;
  key bukrs       : bukrs not null;        " 회사 코드
  key hbkid       : hbkid not null;        " 하우스 뱅크
  key hktid       : hktid not null;        " 계좌 ID
  key valid_from  : abap.dats not null;    " 유효 시작일
  valid_to        : abap.dats;             " 유효 종료일
  cash_item       : abap.char(6);          " 자금 항목 코드
  activity        : abap.char(1);          " O 영업 · I 투자 · F 재무
  business_unit   : abap.char(4);          " 사업부
  cp_group        : abap.char(4);          " 거래처 그룹
}

② 예측 스냅샷 테이블

시점별 예측(1주 · 2주 · 4주 전)을 비교하려면 그때 확정한 예측을 그대로 보관해야 합니다. 예측은 매주 다시 만들어지므로 현재 값만 남기면 지난 시점의 예측을 되살릴 수 없습니다. 이 테이블은 시점 버전을 키에 넣어 확정 시점의 줄을 쌓아 두는 자리이며, 원천(표준 유동성 예측)에서 어떻게 복사해 올지는 운영 전환 때 정해야 합니다(확인 필요).

" ────────────────────────────────────────────────────────────────
"  ZCFA_PLANSNAP — 예측 스냅샷 (확정 시점별 줄)
"  snap_ver : W1 = 기간 시작 1주 전 · W2 = 2주 전 · W4 = 4주 전
"  이렇게 나누는 이유 : 예측은 매주 다시 만들어진다. 확정 시점의 줄을
"  따로 쌓아 두지 않으면 "4주 전에는 얼마로 보았나" 에 답할 수 없다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '자금 예측 스냅샷'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zcfa_plansnap {
  key mandt       : mandt not null;
  key snap_ver    : abap.char(2) not null;   " W1 · W2 · W4
  key bukrs       : bukrs not null;
  key plan_date   : abap.dats not null;      " 예측 대상일
  key line_no     : abap.numc(6) not null;
  cash_item       : abap.char(6);
  business_unit   : abap.char(4);
  cp_group        : abap.char(4);
  waers           : waers;
  @Semantics.amount.currencyCode : 'zcfa_plansnap.waers'
  amount          : abap.curr(15,2);         " 입금 + / 지급 −
  snapshot_on     : abap.dats;               " 스냅샷을 확정한 날
}

③ 자금 항목 차원 뷰

화면의 행 축과 값 도움말이 이 뷰 하나를 봅니다. 매핑 테이블에서 항목을 한 번만 뽑아 두면 큐브마다 같은 항목을 따로 풀지 않아도 되고, 이름이나 정렬이 바뀌어도 한 곳만 고치면 됩니다. 거래처 그룹 차원도 같은 모양으로 만듭니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CashItem — 자금 항목 차원
"  항목 하나당 한 행. 활동 구분(영업 · 투자 · 재무)이 함께 붙는다.
"  차원 뷰를 따로 두는 이유 : 큐브에서 join 을 한 번만 걸고,
"  값 도움말 · 이름 · 정렬이 이 뷰 하나를 보게 하기 위해서다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '자금 항목'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'CashItem'
@ObjectModel.usageType.sizeCategory  : #S
@ObjectModel.usageType.serviceQuality: #A
@ObjectModel.usageType.dataClass     : #CUSTOMIZING
define view entity ZI_CashItem
  as select distinct from zcfa_itemmap
{
  key cash_item as CashItem,
      activity  as Activity     " O 영업 · I 투자 · F 재무
}

④ 실적 큐브

실적 줄을 차원 조합별로 한 번에 합산하는 자리입니다. 원천은 은행 명세 라인이고, 외화는 여기서 원화로 환산해 화면이 환율을 만지지 않게 합니다. 입금 · 출금을 부호로 가르고 금액은 통화 키와 함께 노출합니다. 아래 원천 테이블 · 필드 이름은 릴리스와 환경에 따라 다르므로 그대로 붙여 넣기 전에 확인이 필요합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CashFcstActualCube — 실적 큐브 (차원 조합별 합산)
"  원천 : 은행 명세 헤더/라인 (필드 이름은 릴리스별 확인 필요)
"  환산 : 전기일 기준 · 환율 유형 M — 운영에서는 회계팀과 합의한 값으로 교체
"  이렇게 나누는 이유 : 원천 라인에서 한 번만 합산하고, 화면은
"  합산된 행만 읽게 하려는 것. 칸 합계와 원천 라인 합계를 맞춰 보는 대사는
"  원천 라인을 읽는 별도 경로로 한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '자금 예측 정확도 — 실적 큐브'
@Analytics.dataCategory              : #CUBE
@ObjectModel.usageType.sizeCategory  : #XL
@ObjectModel.usageType.serviceQuality: #D
@ObjectModel.usageType.dataClass     : #MIXED
define view entity ZI_CashFcstActualCube
  as select from febep as l
    inner join   febko as h on h.kukey = l.kukey
    inner join   zcfa_itemmap as m
      on  m.bukrs = h.bukrs
      and m.hbkid = h.hbkid
      and m.hktid = h.hktid
      and m.valid_from <= h.azdat
      and ( m.valid_to is null or m.valid_to >= h.azdat )
  association [0..1] to ZI_CashItem as _CashItem on _CashItem.CashItem = $projection.CashItem
{
  key h.bukrs                                    as CompanyCode,
  key substring( h.azdat, 1, 6 )                 as Period,          " YYYYMM
  key m.business_unit                            as BusinessUnit,
  key m.cash_item                                as CashItem,
  key m.cp_group                                 as CounterpartyGroup,
  key l.waers                                    as Currency,
  key case when l.kwbtr >= 0 then 'I' else 'O' end as Direction,     " I 유입 · O 유출

      @Semantics.currencyCode: true
      cast( 'KRW' as abap.cuky( 5 ) )            as ReportCurrency,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'ReportCurrency'
      sum( currency_conversion(
             amount             => abs( l.kwbtr ),
             source_currency    => l.waers,
             target_currency    => cast( 'KRW' as abap.cuky( 5 ) ),
             exchange_rate_date => h.azdat,
             exchange_rate_type => 'M',
             error_handling     => 'SET_TO_NULL' ) ) as AmountKRW,

      @DefaultAggregation: #SUM
      count( * )                                 as LineCount,

      _CashItem
}
group by h.bukrs, substring( h.azdat, 1, 6 ), m.business_unit,
         m.cash_item, m.cp_group, l.waers,
         case when l.kwbtr >= 0 then 'I' else 'O' end

⑤ 예측 큐브

실적 큐브와 같은 키 구성으로 예측 스냅샷을 합산합니다. 키가 같아야 화면이 두 값을 한 칸에 맞붙여 차이를 낼 수 있고, 같은 키에 한쪽만 있는 줄이 "예측에 없던 흐름" 또는 "실현되지 않은 예측"이 됩니다. 시점 버전(W1 · W2 · W4)은 키에 포함해 화면의 예측 시점 선택과 1:1로 이어집니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CashFcstPlanCube — 예측 큐브 (시점 버전별 합산)
"  실적 큐브와 키 구성을 맞추는 이유 : 같은 키에서 실적과 예측을
"  맞붙여야 요인 분해(시기 · 금액 · 환율 · 미예측 · 미실현)가 선다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '자금 예측 정확도 — 예측 큐브'
@Analytics.dataCategory              : #CUBE
@ObjectModel.usageType.sizeCategory  : #XL
@ObjectModel.usageType.serviceQuality: #D
@ObjectModel.usageType.dataClass     : #TRANSACTIONAL
define view entity ZI_CashFcstPlanCube
  as select from zcfa_plansnap as p
{
  key p.snap_ver                                 as Version,         " W1 · W2 · W4
  key p.bukrs                                    as CompanyCode,
  key substring( p.plan_date, 1, 6 )             as Period,
  key p.business_unit                            as BusinessUnit,
  key p.cash_item                                as CashItem,
  key p.cp_group                                 as CounterpartyGroup,
  key p.waers                                    as Currency,
  key case when p.amount >= 0 then 'I' else 'O' end as Direction,

      @Semantics.currencyCode: true
      cast( 'KRW' as abap.cuky( 5 ) )            as ReportCurrency,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'ReportCurrency'
      sum( currency_conversion(
             amount             => abs( p.amount ),
             source_currency    => p.waers,
             target_currency    => cast( 'KRW' as abap.cuky( 5 ) ),
             exchange_rate_date => p.plan_date,
             exchange_rate_type => 'M',
             error_handling     => 'SET_TO_NULL' ) ) as AmountKRW,

      @DefaultAggregation: #SUM
      count( * )                                 as LineCount
}
group by p.snap_ver, p.bukrs, substring( p.plan_date, 1, 6 ), p.business_unit,
         p.cash_item, p.cp_group, p.waers,
         case when p.amount >= 0 then 'I' else 'O' end

⑥ 분석 쿼리 — 화면이 읽는 입구

화면이 읽는 입구는 이 쿼리 하나입니다. 어느 차원을 행 · 열에 기본으로 놓을지, 어떤 필터를 필수로 둘지(기간)를 여기서 정합니다. 기간을 필수 필터로 두는 것이 대용량에서 가장 먼저 걸어야 할 안전장치입니다. 실적 큐브와 예측 큐브를 한 쿼리에서 맞붙일지, 쿼리를 둘로 두고 서비스에서 같은 키로 맞붙일지는 환경에 따라 정하므로 확인이 필요합니다.

" ────────────────────────────────────────────────────────────────
"  ZC_CashFcstAccQuery — 분석 쿼리 (Consumption)
"  기간을 필수 필터로 두는 이유 : 조건 없이 열면 전 기간을 읽는다.
"  예측 큐브와의 결합 방식(association / 별도 쿼리)은 확인 필요.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '자금 예측 정확도 쿼리'
@Analytics.query                  : true
@VDM.viewType                     : #CONSUMPTION
define view entity ZC_CashFcstAccQuery
  as select from ZI_CashFcstActualCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @AnalyticsDetails.query.displayHierarchy : #OFF
  BusinessUnit,

  @AnalyticsDetails.query.axis : #ROWS
  CashItem,

  @AnalyticsDetails.query.axis : #COLUMNS
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  Period,

  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true }
  CompanyCode,

  @Consumption.filter.hidden : false
  CounterpartyGroup,

  Currency,
  Direction,

  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '실적 금액(원화)'
  AmountKRW,

  @EndUserText.label : '원천 라인 수'
  LineCount
}

⑦ 권한 — 집계를 읽는 자리에 건다

집계 화면은 권한이 없어도 합계가 보이는 수가 있습니다. 어떤 회사 코드의 합계만 볼 수 있는 사람이 전체 합계를 보면 뺄셈으로 남의 숫자를 알아낼 수 있으므로, 권한은 드릴스루가 아니라 큐브를 읽는 자리에 겁니다. 회사 코드는 표준 권한 객체를 그대로 따르고, 사업부 단위 권한은 고객사가 정의한 객체에 맞춥니다(확인 필요).

" ────────────────────────────────────────────────────────────────
"  ZI_CASHFCSTACC — 큐브 읽기 권한 (DCL)
"  권한을 큐브에 거는 이유 : 드릴스루에만 걸면 합계 차이로 우회된다.
"  사업부 단위 권한 객체는 고객사 정의에 맞춰 추가한다 — 확인 필요.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '자금 예측 정확도 — 회사 코드 권한'
@MappingRole : true
define role ZI_CASHFCSTACC {
  grant select on ZI_CashFcstActualCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );

  grant select on ZI_CashFcstPlanCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리와 차원을 OData 서비스로 노출합니다. 서비스 정의에 올린 이름이 화면이 읽는 엔티티셋 이름이 되므로, 화면 쪽 이름과 맞춰 둡니다. 바인딩은 코드가 아니라 개발 도구에서 만들어 게시하며, 게시한 주소를 화면의 서비스 선언에 넣으면 샘플 서비스가 운영 서비스로 바뀝니다.

" ────────────────────────────────────────────────────────────────
"  ZSD_CashFcstAcc — 서비스 정의
"  바인딩 : 개발 도구에서 "OData V2 - UI" 유형으로 만들어 게시한다.
"  게시 뒤 : 화면의 서비스 선언(manifest)에 있는 주소를 교체한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '자금 예측 정확도 서비스'
define service ZSD_CashFcstAcc {
  expose ZC_CashFcstAccQuery      as CubeSet;
  expose ZI_CashFcstPlanCube      as PlanSet;
  expose ZI_CashItem              as ItemSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여섯 가지는 코딩이 아니라 합의이고, 정하지 않으면 해당 자리에서 막힙니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
은행 계좌 · 계정 → 자금 항목 매핑	계좌 · 계정이 영업 · 투자 · 재무 중 어디인지, 어느 사업부 · 거래처 그룹인지	어떤 입출금이 영업 · 투자 · 재무인지 분류가 달라 첫 회의에서 막힙니다	자금팀 · 회계팀
예측 스냅샷 보관 방식	시점(1주 · 2주 · 4주 전)별 예측을 언제 어떻게 복사해 쌓을지	시점별 예측을 비교할 수 없습니다	자금팀 · IT
환율 유형 · 환산 시점	외화를 어느 환율 유형으로 어느 기준일에 환산할지	외화 금액의 원화 환산이 표준 화면과 어긋납니다	회계팀
예측 적중 구분 허용 일수	예정대로 · 늦게 · 일찍를 가르는 허용 일수	늦음 · 일찍의 기준이 사람마다 달라집니다	자금팀
권한 기준	회사 코드 · 사업부 단위로 누가 어디까지 볼지	다른 사업부의 숫자가 보입니다	보안 · 권한
서비스 활성화와 서비스 주소 교체	서비스를 게시하고 화면의 서비스 주소를 운영 주소로 바꾸는 시점	화면이 운영 데이터를 읽지 못합니다	Basis · IT

위 여섯 가지는 코딩이 아니라 합의입니다. 합의가 끝나면 기술 작업은 CDS 뷰(큐브 · 쿼리 · 권한)를 만들고 서비스를 게시한 뒤 화면의 서비스 주소를 바꾸는 일입니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세우고 샘플 데이터에 전수로 돌렸습니다. 아래는 그 결과이며, 도입 포인트의 사례와 같은 숫자입니다.

대사식	검사 건수	차이
큐브 합계 = 원천 라인 합계(기간 × 측정값 4종)	36	0
큐브 칸 = 원천 라인 묶음	1,511	0
큐브 검산 행	36	0
유입 − 유출 = 순흐름(큐브 행)	5,933	0
영업 + 투자 + 재무 = 현금 순증감(월별)	9	0
외화 금액 × 환율 = 원화(5자리 반올림 허용)	4,631	0
예측 + 요인 합 = 실적(시점 3 × 범위 13)	39	0
피벗 총합 = 큐브 총합(축 배치 8가지)	15	0
칸 금액 = 드릴스루 라인 합계(칸 40개)	40	0
계산항목 = 식 결과(6종 × 10범위)	60	0
다중 선택 필터 합계	5	0
예측 시점이 멀수록 오차 증가(W1 < W2 < W4)	1	0
합계	12,316	0

12가지 대사식이 모두 차이 0 입니다. 이는 이 샘플 데이터에 대한 결과이며, 운영 데이터에서는 전환 때 같은 대사식을 다시 돌려 확인해야 합니다.

운영 데이터로 갈 때

지금 구조에서 가장 먼저 막히는 곳은 큐브를 한 번에 읽어 오는 크기입니다. 이 샘플은 큐브 1,511행 · 예측 4,422행이라 한 번에 읽어도 가볍지만, 운영에서 원천 라인이 수천만 건이면 큐브는 CDS 쪽에서 합산하고 화면은 합산된 행만 읽어야 합니다.

그래서 조회 조건에 기간을 필수로 두고(기본 9개월), 열 조합 36개 · 행 2,000개 상한을 화면이 지킵니다. 원천 라인은 칸을 눌렀을 때만 $top · $inlinecount 로 나눠 읽습니다.

운영 규모에서는 큐브의 키 순서에 맞춘 인덱스(또는 HANA 의 칼럼 저장 특성)와 예측 스냅샷의 보관 기간, 큐브 응답 시간 기준을 먼저 정하고, 에이전트는 배치(예: 야간 잡)가 같은 함수를 부르도록 둡니다.

자주 묻는 질문

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

숫자와 산식

차이는 어떻게 계산됩니까? 부호는 어떻게 읽습니까?

칸마다 차이 = 실적 − 예측, 차이율 = 차이 ÷ |예측| 입니다. 순현금흐름은 유입을 +, 유출을 −로 합친 값이라, 차이가 음수이면 실적이 예측보다 덜 들어왔거나 더 나갔다는 뜻입니다.

색은 부호가 아니라 자금 영향 방향으로 입힙니다. 현금 유출 칸에서 실적이 예측보다 작으면 차이는 음수지만 자금에는 좋은 쪽이라 초록입니다. 금액 차이와 비율 차이를 둘 다 기준(기본 10백만원 · 5%) 이상 넘을 때만 칠하므로, 색이 없는 칸은 ‘기준에 못 미쳤다’는 뜻이지 ‘맞았다’는 뜻은 아닙니다.

여섯 요인은 무엇이고 합이 정말 총차이와 같습니까?

입금 시기 · 지급 시기 · 금액(외화 기준) · 환율 가정 · 예측에 없던 흐름 · 실현되지 않은 예측입니다. 같은 키에 실적과 예측이 모두 있으면 시기 · 금액 · 환율로, 실적에만 있으면 ‘예측에 없던 흐름’으로, 예측에만 있으면 ‘실현되지 않은 예측’으로 가릅니다.

이 글의 샘플에서는 −13,920.2 · −11,151.6 · +2,168.1 · +79.6 · +8,420.2 · −4,210.6 을 더하면 총차이 −18,614.5 백만원과 같고, 화면은 이 검산을 조회할 때마다 다시 합니다. 합이 어긋나면 ‘점검 필요’로 표시되며, 그때는 범위 조건과 환율 설정을 확인해야 합니다.

예측 시점 W1 · W2 · W4 는 무슨 뜻입니까?

기간 시작 기준 1주 · 2주 · 4주 전에 확정한 예측입니다. 같은 기간의 실적을 세 예측과 각각 비교해 오차율을 구합니다. 샘플에서는 1주 전 1.48%, 2주 전 3.29%, 4주 전 4.43% 로 멀수록 오차가 커졌습니다.

이 비교가 되려면 확정 시점의 예측을 따로 보관해야 합니다. 표준 화면은 현재 예측만 보여 주는 경우가 많으므로, 운영 전환 때 스냅샷을 어떻게 쌓을지 먼저 정해야 합니다(확인 필요).

외화 금액과 환율은 어떻게 처리합니까?

화면의 금액은 원화 환산 값이고, 환산은 서비스(운영에서는 CDS 큐브)에서 합니다. 외화 금액 × 환율 = 원화가 되는지는 대사식으로 따로 검산합니다(샘플 4,631건, 5자리 반올림 허용). 환율 가정에서 생긴 몫은 여섯 요인 중 ‘환율 가정’으로 분리됩니다.

어떤 환율 유형을 어느 기준일에 쓸지는 회계팀과 합의해야 합니다. 표준 화면과 환율 유형이 다르면 같은 거래도 원화 금액이 달라질 수 있으므로, 운영 전환 때 가장 먼저 대조할 항목입니다.

칸의 금액과 원천 라인 합계가 정말 같습니까?

큐브가 라인을 더해 만든 값이라 같아야 합니다. 칸을 누르면 원천 라인 창이 열리고 맨 위에 건수와 합계가 적히며, 칸 금액과 같은지 ‘일치’ 또는 ‘점검 필요’로 표시합니다. 샘플에서는 칸 40개를 대조해 모두 같았습니다.

다만 이는 이 샘플 데이터에서의 결과입니다. 운영 데이터에서 같은지는 전환 때 다시 돌려 확인해야 합니다.

화면과 조작

처음 쓰는 사람은 무엇부터 눌러야 합니까?

모든 조회 조건에 기본값이 있어 비워 둔 채 조회 버튼만 눌러도 됩니다. 조회하면 위쪽 카드, 트리 표, 오른쪽 차트가 한 번에 채워집니다. 그다음 차원 보관함의 칩을 행 축이나 열 축으로 끌어다 놓으면 표가 바로 다시 묶입니다. 예측과 비교하려면 예측 시점을 고르고 예측 차이 스위치를 켭니다.

축을 바꿀 때마다 서버를 다시 부릅니까?

아닙니다. 조회할 때 큐브를 한 번 읽어 두고, 축을 바꾸는 일은 그 자료를 화면에서 다시 묶는 일입니다. 그래서 축을 바꿔도 합계가 갈라질 자리가 없고 응답도 빠릅니다. 서버를 다시 부르는 때는 칸을 눌러 원천 라인을 읽을 때와 요인 분해 · 해설 · 에이전트 함수를 부를 때뿐입니다.

축이나 열을 몇 단계까지 쌓을 수 있습니까?

열 조합은 36개, 표의 행은 2,000개까지 그립니다. 그보다 크면 표가 읽히지 않으므로 화면이 그리지 않고 ‘범위를 줄이라’는 안내를 보입니다. 값 필터에서 여러 값을 골라 범위를 좁히면 다시 그려집니다. 한계에 걸렸다고 숫자가 틀린 것은 아닙니다.

휴대폰이나 좁은 화면에서도 쓸 수 있습니까?

창이 좁으면 카드가 줄바꿈되고 차트가 표 아래로 내려옵니다. 표는 가로로 스크롤됩니다. 같은 리포트를 보되 한 번에 보이는 양이 줄어드는 것이므로, 축을 짜는 작업은 넓은 화면이 편합니다.

짜 둔 축은 다음에도 남습니까?

이름을 붙여 보기로 저장할 수 있고, 기본 보기와 ‘열 때 바로 조회’를 지정하면 다음에 열 때 그 배치로 시작합니다. 변동 사유는 보기와 별개로 조회 범위와 행 경로에 묶여 저장되므로 축을 바꿔도 같은 행이면 사유가 따라옵니다.

분석 기능

해설 문장은 누가 만듭니까? 숫자도 AI 가 만듭니까?

숫자는 서비스가 계산합니다. 해설 문장은 그 숫자 위에 규칙으로 만든 초안이고, 근거 표를 펼치면 문장에 쓰인 숫자를 대조할 수 있습니다. 모델 연결은 기본으로 꺼져 있고, 켜더라도 모델은 서비스가 넘긴 숫자를 읽어 설명만 하도록 구성합니다. 초안은 그대로 쓰지 말고 읽어 보고 고치는 것이 안전합니다.

에이전트는 무엇을 하고 얼마나 자주 돕니까?

감시 규칙 네 개(입금 시기 ≤ −300백만원 · 미예측 흐름 절대값 ≥ 1,000백만원 · 순흐름 차이 절대값 ≥ 500백만원 · 환율 요인 절대값 ≥ 20백만원)를 평가해 걸린 항목을 받을 사람(자금 · 재무 · 경영 · 회계)의 대기함에 올리고 기록을 남깁니다. 하루 한 번 제한은 서비스가 지키므로 화면을 여러 개 열어도 같은 날 두 번 돌지 않습니다.

임계값은 화면에서 고칠 수 있고, 걸렸다는 것은 ‘확인 필요’라는 뜻이지 문제가 있다는 판정이 아닙니다.

변동 사유는 어디에 저장되고 누가 볼 수 있습니까?

조회 범위와 행 경로를 키로 서비스에 저장됩니다. CSV 와 해설의 근거에 함께 실립니다. 조회 권한이 있는 사람이 같은 범위를 열면 같은 사유를 봅니다. 사유를 적는 권한을 별도로 둘지는 도입 때 정해야 합니다(확인 필요).

보고서는 어떻게 만들어집니까?

지금 보는 범위의 표와 차트를 담은 PowerPoint 를 브라우저에서 바로 만듭니다. 서버에 파일을 남기지 않습니다. 보고서의 숫자는 화면과 같은 경로로 만든 사본이므로, 결재에 올리기 전에 해설 초안과 사유를 읽어 보고 고치는 단계는 사람이 맡습니다.

표준 화면의 현금 포지션과 숫자가 다르면 어떻게 합니까?

먼저 통화별 합계를 비교합니다. 흔한 원인은 환율 유형 · 환산 기준일의 차이, 매핑 표에 없는 계좌, 예측 스냅샷의 확정 시점 차이입니다. 어느 쪽이 맞는지는 이 화면이 판정하지 않으며, 원천 라인으로 내려가 표준 화면과 대조해 점검해야 합니다.

도입과 운영

어떤 회사에 맞고, 누가 씁니까?

여러 통화로 입출금이 오가고 법인이 둘 이상이며 자금 예측을 엑셀로 관리하는 제조 · 무역 회사에 맞습니다. 주 사용자는 예측이 어긋나는 곳을 찾는 자금팀이고, 그 숫자를 설명해야 하는 재무 · 경영지원 조직이 결과를 봅니다. 예측이 한 파일로 단순하거나 통화가 하나뿐이면 얻는 것이 작을 수 있습니다.

표준 현금 포지션 · 유동성 예측 화면을 없애도 됩니까?

없애지 않고 병행하는 것을 권합니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 예측 시점 비교와 요인 분해 같은 점검 관점을 더해 확장합니다. 법정 · 감사 대응은 표준 화면에 남겨 두고, 두 화면의 통화별 합계를 맞춰 보는 것을 첫 대사로 둡니다.

최종 판단은 누가 합니까? 이 화면의 결과를 그대로 보고에 써도 됩니까?

이 화면은 분류 · 집계 · 대사를 돕는 점검 도구입니다. 예측 정확도를 어떻게 평가하고 어떤 조치를 할지의 최종 판단은 회사가 하고, 외부 감사와 관련된 사항은 회사와 감사인이 합니다. 화면이 ‘점검 필요’로 표시한 항목은 확인을 요청하는 것이고, 표시되지 않았다는 이유로 확인이 끝난 것은 아닙니다.

운영 시스템에 연결하려면 무엇이 필요합니까? 얼마나 걸립니까?

기술 작업은 CDS 뷰(큐브 · 쿼리 · 권한)를 만들고 서비스를 게시한 뒤 화면의 서비스 주소를 바꾸는 일입니다. 시간은 대부분 합의에 듭니다 — 은행 계좌 · 계정의 자금 항목 매핑, 예측 스냅샷 보관 방식, 환율 유형, 예측 적중 허용 일수, 권한 기준입니다. 걸리는 기간은 회사의 데이터 상태에 따라 달라 이 글에서 단정하지 않습니다.

권한과 보안은 어떻게 합니까?

권한은 드릴스루가 아니라 큐브를 읽는 자리에 겁니다. 회사 코드 단위는 표준 권한 객체를 그대로 따르고, 사업부 단위는 고객사가 정의한 객체에 맞춥니다. 화면은 표준 컨트롤과 직접 그린 차트만 써서 외부 라이브러리 반입 심사가 필요하지 않고, 쓰는 데이터는 서비스를 거쳐서만 읽습니다. 권한 설계는 보안 담당자와 함께 확인해야 합니다.

데이터가 아주 많으면 느리지 않습니까?

샘플은 큐브 1,511행이라 한 번에 읽어도 가볍습니다. 운영에서 원천 라인이 수천만 건이면 합산을 CDS 에서 하고 화면은 합산된 행만 읽도록 해야 합니다. 조회에 기간을 필수로 두고, 원천 라인은 칸을 눌렀을 때만 나누어 읽습니다. 응답 시간 기준과 인덱스는 운영 규모를 보고 정해야 합니다.

계좌나 계정 체계가 바뀌면 어떻게 합니까?

매핑 표에 유효기간이 있어서 새 체계를 새 행으로 추가하면 지난 기간 숫자는 그대로 유지됩니다. 매핑 표가 바뀌는 시점마다 두 체계의 합계가 이어지는지 대조하는 것이 좋습니다. 매핑을 누가 관리할지(자금팀)와 변경 절차를 미리 정해 두어야 합니다.

샘플 숫자를 우리 회사 숫자로 봐도 됩니까?

아닙니다. 이 글의 숫자는 모두 가상 회사 두 곳의 2026년 1~9월 샘플 값입니다. 검증 결과(대사식 12종 전수, 차이 0)도 이 샘플에 대한 것이며, 운영 데이터에서는 전환 때 같은 대사식을 다시 돌려 확인해야 합니다.

화면 구성이나 규칙을 회사에 맞게 바꿀 수 있습니까?

임계값과 받을 사람은 화면에서 고치고, 매핑과 적중 허용 일수 같은 기준은 서비스 쪽 설정으로 바꿉니다. 새 차원이나 계산항목을 더하려면 서비스가 내려 주는 정의를 늘리는 방식이라 화면 코드를 고치는 일은 비교적 적지만, 범위는 요구사항을 보고 확인해야 합니다.