SAP 자금 수지 계획 대비 실적 다차원 분석 — 은행 · 활동 · 통화로 돌려 보고 차이를 여섯 요인으로 쪼개는 자금 회의

Q: 계산 항목은 어떻게 만들어집니까?

식은 Flow[A]+Flow[B] 처럼 측정값과 활동 구분을 토큰으로 지정합니다. 서비스가 정의를 갖고 있어 화면은 식을 풀어 큐브에서 합산하고, 분모가 0 이면 값을 지어내지 않고 비웁니다. 새 계산 항목은 정의 한 줄을 더하는 일입니다.

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

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

자금 담당자가 월말과 분기말에 받는 질문은 대개 세 가지입니다. 계획 대비 얼마나 벗어났나, 왜 벗어났나, 그래서 누가 무엇을 해야 하나. 지금은 이 세 답이 은행 거래내역 엑셀, 자금 수지 계획표, 표준 현금 관리 화면, 회의록으로 흩어져 있어서 숫자를 맞추는 일이 분석보다 먼저 옵니다. 이 앱은 은행 거래 라인을 한 번 읽어 큐브로 묶고, 계획과 실적을 같은 차원으로 나란히 놓은 다음, 차이를 요인으로 가르고 그 요인을 원천 거래까지 따라갈 수 있게 해서 세 답을 한 화면에 붙입니다.

표준 현금 포지션과 유동성 예측 화면은 은행 계정별 잔액과 예측 라인을 정확히 보여 줍니다. 이 화면은 그 위에 “계획에 없던 입금이 얼마였나”, “입금 시기가 늦어서 생긴 차이가 얼마였나”, “환율 때문에 움직인 금액이 얼마였나” 같은 조회와 검증 관점을 더합니다. 법정·감사·세무 신고에 쓰는 실행은 표준 T-code 가 계속 담당하고, 여기서는 회의에 들고 갈 숫자를 같은 큐브에서 여러 모양으로 꺼냅니다. 이 글은 자금 수지·자금 예측 영역을 다루며 특정 회계기준서의 요구사항을 적용 대상으로 삼지 않습니다.

한 줄 요약 — 은행 입출금을 한 번 읽어 은행 · 활동 · 통화 · 거래처 어느 축으로든 돌려 보고, 계획과의 차이를 시기 · 금액 · 환율 · 계획 외 · 미실현 여섯 요인으로 쪼개 원천 거래까지 따라가며, 쪼갠 합이 총차이와 1원도 어긋나지 않는지 매번 스스로 검산합니다.

핵심 포인트 일곱 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 갈라지지 않는 피벗	은행 · 자금 항목 · 통화 · 거래처 그룹 · 활동 구분을 끌어다 놓아 행 3단계 · 열 2단계로 봅니다. 모든 축이 한 번 읽은 같은 큐브에서 나와 합계가 어긋날 자리가 없고, 축을 바꿔도 서버를 다시 부르지 않습니다.	은행별 · 항목별 · 통화별 시트를 따로 만들고, 합계가 다르면 시트를 맞추는 시간을 씁니다.
② 칸에서 은행 거래 라인까지	숫자를 누르면 그 칸을 이루는 원천 거래 라인이 열리고, 라인 합계가 칸의 값과 같은지 바로 표시됩니다. 의심은 그 자리에서 풀립니다.	리포트를 닫고 라인 아이템 화면을 다시 열어 조건을 손으로 맞춥니다.
③ 계획 대비 차이가 같은 표 안에서	비교 기준을 계획으로 두면 실적 · 계획 · 차이 · 차이율이 나란히 붙고, 금액과 비율 기준을 모두 넘는 칸만 색이 칩니다. 별도 차이 리포트를 운영하지 않습니다.	실적표와 계획표를 엑셀에서 붙여 차이 열을 직접 만듭니다.
④ 차이를 여섯 요인으로	회수 시기 · 지급 시기 · 금액 · 환율 · 계획 외 · 계획 미실현으로 가르고 합이 총차이와 같은지 검산 줄로 보여 줍니다. 늦게 들어온 것인지, 금액이 바뀐 것인지, 아예 안 들어온 것인지가 갈립니다.	차이 총액만 보고 원인은 담당자에게 메일로 되묻습니다.
⑤ 변동 사유가 행에 남는다	차이가 난 행에 사유를 적어 두면 조회 범위와 함께 저장되어 다음 달 같은 행에서 다시 보입니다. CSV 와 해설 근거에도 함께 실립니다.	같은 질문을 매달 다시 하고, 지난달 답은 메일함에서 찾습니다.
⑥ 숫자는 서비스가, 문장은 초안으로	금액과 비율은 서비스가 큐브에서 계산해 근거로 내고, 해설은 그 숫자를 읽어 쓴 초안입니다. 모델을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다. 결과는 파워포인트 보고서로 바로 내려받습니다.	해설에 쓰인 숫자가 어디서 왔는지 따져 보는 일부터 시작합니다.
⑦ 사람이 자리에 없어도 도는 점검	회수 시기 · 환율 영향 · 순흐름 미달 · 지출 비율 네 가지 규칙을 서비스가 하루 한 번 판정해 대기함에 올리고, 누가 언제 돌렸는지 활동 기록에 남깁니다.	숫자가 나빠진 날 아무도 화면을 열지 않으면 그대로 지나갑니다.

사례로 보는 효과

검증용 샘플 데이터(가상 회사 2개 · 가상 은행 4개 · 통화 5종 · 2026년 1월~9월)에서 회사 전체를 조회하면 입금 102,039.0백만원, 출금 97,896.1백만원, 순흐름 4,142.9백만원이 나옵니다. 계획은 5,760.4백만원이라 계획보다 1,617.5백만원(−28.1%) 모자랐습니다. 표준 화면은 여기까지 말해 줍니다.

이 앱은 같은 차이를 여섯 요인으로 가릅니다: 회수 시기 +162.5, 지급 시기 −84.6, 금액 −621.9, 환율 +347.0, 계획 외 발생 +145.5, 계획 미실현 −1,566.1(단위 백만원). 가장 큰 몫은 환율이나 금액이 아니라 “계획에는 있었는데 실적에 나타나지 않은 칸”이었습니다. 어느 칸이 그랬는지는 같은 표에서 계획 차이를 켜고 행을 눌러 보면 이어지고, 요인의 합과 총차이의 차이는 0입니다. 이 숫자들은 대사식 10종 · 8,821건을 전수로 돌려 차이 0건이었던 같은 자료에서 나왔습니다.

도입하면 달라지는 것

월말 자금 보고 — 은행별 · 항목별 · 통화별 표가 한 화면에서 나와 시트 취합과 캡처가 줄어듭니다.
회의의 주제 — “어느 숫자가 맞나” 대신 “계획 미실현 칸을 어떻게 할 것인가”를 이야기합니다.
다음 달로 이어지는 기록 — 변동 사유와 저장한 보기가 남아 같은 설명을 반복하지 않습니다.
놓치는 날이 없는 점검 — 규칙에 걸린 숫자가 담당자 대기함에 올라옵니다.

이런 회사에 맞습니다

여러 은행과 여러 통화로 입출금이 오가고, 월 단위 자금 수지 계획을 세워 두었지만 실적과의 차이를 엑셀로 맞추고 있는 회사에 맞습니다. 법인이 둘 이상이거나 수출입 대금으로 외화 비중이 있어 환율이 차이의 한 요인으로 따로 보여야 하는 곳, 자금팀 · 회계팀 · 경영지원이 같은 숫자를 서로 다른 시트로 들고 회의에 오는 조직이면 효과가 큽니다. 은행이 한두 곳이고 계획 없이 잔액만 확인하는 규모라면 표준 현금 포지션 화면으로 충분합니다.

실행 화면

실제 브라우저에서 찍은 화면 30종입니다. 순서는 처음 열었을 때 → 경영 요약 → 축 전환과 범위 → 칸에서 원천 거래까지 → 계산 항목 → 계획 대비 차이 → AI 분석과 보고서 → AI 에이전트 → 보기 저장과 복원 → 좁은 화면과 한계이며, 숫자는 모두 같은 검증용 샘플 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

사용 방법

조회 조건 입력 — 필수는 기간 시작 · 기간 끝입니다. 회사는 비우면 전체, 비교 기준은 계획 또는 없음을 고릅니다. 시작이 끝보다 늦으면 조회하지 않고 안내합니다.
조회 — 조건 영역 오른쪽 끝의 조회 버튼을 누릅니다. 조건 입력 칸에서 Enter 를 눌러도 같습니다. 조회하면 조건 영역이 접히고 한 줄 요약으로 바뀝니다.
요약 확인 — “보는 사람”(경영 · 재무 · 자금 · 회계)을 고르면 문장과 핵심 지표 카드의 초점이 달라집니다.
탭 · 축 이동 — 차원 보관함의 칩을 행 축 · 열 축으로 끌어다 놓거나 눌러 보냅니다. ✕ 로 뺍니다. 이미 읽은 큐브를 다시 묶으므로 서버를 부르지 않습니다. 행 축은 3단계, 열 축은 2단계까지입니다.
행 · 셀 클릭으로 상세 — 행을 누르면 오른쪽에 계획에서 실적까지의 워터폴과 요인 표가 나오고, 값 칸을 누르면 그 칸을 이루는 원천 거래 라인이 열립니다.
내보내기 — 표 오른쪽 위 CSV 로 현재 표를, 원천 보기 창의 CSV 로 원천 라인을 내려받습니다. 해설은 파워포인트 보고서로 내려받고, 짜 둔 축은 이름을 붙여 보기로 저장합니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤로만 짰고, 데이터는 OData V2 서비스를 모델로 읽습니다. 아래 표는 자리마다 무엇을 쓰고 왜 그렇게 두었는지를 정리한 것입니다.

자리	무엇	왜 그렇게 두었나
화면	OpenUI5 표준 컨트롤 — 트리 테이블(행 축 계층), 끌어다 놓기 칩, 다중 선택 창, 직접 그린 SVG 차트와 워터폴	외부 차트 라이브러리를 들이지 않아 반입 심사 대상이 없고, 차트가 표와 같은 자료를 읽어 어긋나지 않습니다.
큐브 다시 묶기	조회 때 실적 큐브와 계획 큐브를 한 번 읽고, 축 전환 · 필터 · 차이 모드는 브라우저가 그 자료로 다시 묶는 모델 파일	축을 바꿀 때마다 서버를 부르지 않아 응답이 즉시이고, 어느 축으로 봐도 같은 합계가 나옵니다.
집계 · 판정 로직	서비스 쪽 계산 파일 — 요인 분해, 해설 근거, 에이전트 규칙 판정, 하루 한 번 제한	금액과 판정을 화면이 아니라 서비스가 갖고 있어 화면 없이 배치로 같은 문을 두드릴 수 있습니다.
데이터 서비스	OData V2 서비스 한 개 — 엔티티셋 14개(큐브 · 계획 · 차원 · 측정값 · 계산 항목 · 기간 · 원천 라인 · 대사 · 변동 사유 · 보기 · 에이전트 3종)와 함수 3개(요인 분해 · 해설 · 에이전트 실행). 조회 조건만 서버에 필터로 보내고 나머지 차원 필터는 읽어 둔 큐브에서 거릅니다	운영 전환 때 서비스 주소만 바꾸면 화면은 그대로이고, 서비스 뒤의 원천은 CDS 로 교체합니다.
테마	sap_horizon	SAP 표준 화면과 같은 질감이라 현업이 낯설어하지 않습니다.

앱 정보

항목	내용
솔루션	자금(Treasury)
업무 영역	자금 수지 · 자금 예측
관련 기준서 · 대상 영역	해당 기준서 없음 · 자금 수지 · 자금 예측
SAP 표준 T-code	FF7A · FF7B · FF_5 · FEBAN · FBL3N
화면 성격	다차원 분석 리포트(피벗 · 요인 분해 · 해설 · 에이전트)
데이터 연동	OData V2
테마	sap_horizon

SAP 표준 기능을 그대로 이어받은 부분 — 은행 거래 라인의 전기일 · 통화 · 외화 금액 · 원화 금액, 회사 코드, 은행 키, 계획 라인의 기간 · 금액은 표준 데이터 구조를 그대로 이어받았습니다. 이 화면은 표준 실행을 대신하지 않고, 같은 데이터를 조회 · 검증 관점에서 한 번 더 꺼내 봅니다.

처음 열었을 때

조회 조건부터 피벗까지가 한 화면에 세로로 쌓입니다. 조건 영역은 접을 수 있어서 축을 짜는 동안에는 펼쳐 두고, 숫자를 볼 때는 접어 둡니다.

조회 전에도 빈 화면을 주지 않습니다. 조회 조건 · 차원 보관함 · 행 축 · 열 축 · 표 틀이 먼저 서 있고 값만 비어 있어서, 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 기간 시작과 끝, 회사, 비교 기준이 조건입니다.

**조회 직후 — 피벗 표와 차트** — 조회 직후의 요약 카드와 피벗, 그리고 같은 값을 그린 차트입니다.

조회를 누르면 요약 카드가 먼저 차고 그 아래로 피벗과 오른쪽 차트가 함께 뜹니다. 행 축과 열 축은 “보는 사람”에 맞춘 기본 배치로 놓이고 차트는 표와 같은 값을 그린 것이라 표를 읽기 전에 모양부터 눈에 들어옵니다. 금액 단위는 백만원이 기본입니다.

**레이아웃 보드 — 차원 보관함 · 행 축 · 열 축** — 차원 칩을 담은 보관함과 점선 테두리의 행 축 · 열 축 놓는 자리입니다.

차원 보관함에는 회계기간 · 회사 · 은행 · 자금 항목 · 통화 · 거래처 그룹 · 입출 구분 같은 칩이 놓여 있습니다. 칩을 행 축이나 열 축 영역으로 끌어다 놓거나 눌러서 보내고, ✕ 로 빼면 보관함으로 돌아옵니다. 점선 테두리가 놓을 수 있는 자리입니다.

**은행 칩을 행 축으로 끌어다 놓은 뒤 — 서버를 다시 부르지 않음** — 칩을 끌어다 놓자 서버 호출 없이 표가 다시 묶인 모습입니다.

은행 칩을 행 축으로 끌어다 놓자 표가 바로 은행별로 다시 묶였습니다. 이 순간 서버로 나간 요청은 없습니다 — 큐브를 이미 읽어 두었기 때문입니다. 합계 행의 값이 축을 바꾸기 전과 같은지 맞춰 보면 “축이 달라도 숫자는 하나”라는 뜻이 보입니다.

**조회 뒤 조회 조건 영역이 접힌 상태** — 조회 후 조건이 한 줄 요약으로 접혀 표에 자리를 내준 상태입니다.

조회하면 조건 영역이 한 줄 요약으로 접혀 표와 차트에 자리를 내줍니다. 요약줄에는 회사 · 기간 · 비교 기준 · 금액 단위가 남아 있어 지금 보는 범위를 잊지 않고, 앞쪽 화살표를 누르면 다시 펼쳐 조건을 고칩니다.

경영 요약 — 보는 사람에 따라 달라지는 첫 줄

같은 숫자도 읽는 사람이 다르면 보는 순서가 다릅니다. “보는 사람” 네 가지(경영 · 재무 · 자금 · 회계)가 처음 보이는 측정값과 행 · 열 축 배치, 그리고 안내 문장을 바꿉니다. 카드의 입금 102,039.0 · 출금 97,896.1 · 순흐름 4,142.9 · 계획 대비 차이 −1,617.5(−28.1%) · 지출 비율 95.9%는 네 경우 모두 같은 큐브에서 나옵니다.

**경영 요약 — 보는 사람 · 경영** — 경영 관점 — 활동별 순흐름을 분기별로 펼친 첫 화면입니다.

경영 관점은 현금 순증감을 활동 구분(행)과 분기(열)로 펼치고 “활동별 순흐름이 계획에서 얼마나 벗어났는지 봅니다”라고 안내합니다. 영업활동 7,413.3 · 투자활동 −6,383.6 · 재무활동 3,113.2(백만원)로 갈라 보이며, 계획 대비 차이 카드는 붉은색으로 불리함을 알립니다.

**경영 요약 — 보는 사람 · 재무** — 재무 관점 — 잉여 현금흐름과 지출 비율을 활동 · 항목별로 펼친 화면입니다.

재무 관점은 잉여 현금흐름과 지출 비율을 측정값으로, 활동 구분 › 자금 항목을 행 축으로 펼치며 환율 · 금액 요인을 함께 보게 안내합니다. 위의 다섯 카드 숫자는 그대로이고 달라지는 것은 아래 표의 배치와 안내 문장입니다.

**경영 요약 — 보는 사람 · 자금** — 자금 관점 — 입금액과 출금액을 통화 · 은행별로 펼친 화면입니다.

자금 관점은 입금액과 출금액을 측정값으로 두고 통화 › 은행을 행 축으로 펼쳐 은행과 통화별 입출금과 시기 · 환율 요인을 보게 합니다. 자금 담당자가 매일 묻는 “어느 은행에서 어느 통화로 얼마가 오갔나”에 맞춘 배치입니다.

**경영 요약 — 보는 사람 · 회계** — 회계 관점 — 순흐름과 원천 라인 수를 활동 · 항목별로 펼친 화면입니다.

회계 관점은 순흐름과 원천 라인 수를 측정값으로 두고 활동 구분 › 자금 항목을 행 축으로 펼치며 “활동 구분별 흐름과 원천 라인 합계가 맞는지 봅니다”라고 안내합니다. 마감 전에 숫자의 근거를 점검하는 사람의 순서입니다.

축 전환과 범위 — 보고 싶은 만큼만

열 축은 두 단계까지, 행 축은 세 단계까지입니다. 값 필터는 차원마다 여러 값을 고를 수 있고, 고른 범위는 표 · 차트 · 요인 분해에 함께 적용됩니다.

**열 축은 2단계까지 — 한도 안내와 측정값 열** — 열 축 두 단계 한도에 닿았을 때의 안내입니다.

열 축은 두 단계까지입니다. 한도를 안내하는 문구와 함께 측정값 열이 보이며, 읽을 수 없는 표를 그리느니 단계를 제한하는 쪽을 택했습니다.

**값 필터 — 차원별 다중 선택 창** — 차원마다 여러 값을 고르는 값 필터 창입니다.

값 필터 창은 차원 이름 아래에 값 목록이 있고 여러 개를 체크해 고릅니다. 목록은 큐브에 실제로 있는 값과 이름으로 채워지며, 은행 · 통화 · 자금 항목 · 거래처 그룹처럼 조회 조건에 없는 차원도 여기서 거릅니다.

**값 필터 — 두 값을 고른 상태** — 은행 두 곳을 체크해 둔 필터 창입니다.

은행 두 곳을 고른 상태입니다. 값을 고르고 적용하면 표와 차트가 그 범위로 다시 묶이며, 이 단계에서도 서버에는 요청이 가지 않습니다.

**필터로 좁힌 결과 — 은행 2개** — 필터를 적용해 은행 두 곳으로 좁혀진 표입니다.

필터를 적용한 결과 표에 은행 두 곳만 남았습니다. 합계는 전체 합계가 아니라 고른 범위의 합이고, 필터를 풀면 전체 합계로 돌아옵니다.

칸에서 원천 거래까지

숫자를 의심할 때 가장 빠른 방법은 그 숫자를 만든 거래를 보는 것입니다. 값 칸을 누르면 행 경로와 열 조합이 그대로 조회 조건이 되어 원천 라인이 열립니다.

**칸에서 원천 문서까지 — 원천 라인과 합계 일치 점검** — 칸 하나를 누르자 열린 원천 거래 라인과 합계 일치 점검입니다.

열린 창 맨 위에 라인 수와 합계가 있고 그 옆에 “칸의 값과 일치” 표시가 붙습니다. 일치하지 않으면 점검 필요로 바뀝니다. 라인은 전기일 순으로 500줄씩 읽고, 같은 창에서 CSV 로 내려받을 수 있습니다. 날짜 필터는 서비스가 직접 처리합니다.

계산 항목 — 자주 쓰는 합과 비율을 식으로

활동별 흐름의 합이나 입금 대비 출금 비율처럼 자금 회의에서 반복해 계산하는 값은 계산 항목으로 둡니다. 식은 Flow[A]+Flow[B] 처럼 활동 구분을 꺾쇠로 지정하는 토큰 표현입니다.

**측정값 목록 — 계산 항목 포함** — 기본 측정값과 계산 항목이 함께 나오는 측정값 목록입니다.

측정값 목록에 기본 측정값 네 가지 다음으로 계산 항목 일곱 가지가 나옵니다 — 영업 · 투자 · 재무활동 현금흐름, 현금 순증감, 잉여 현금흐름, 지출 비율, 일평균 순흐름. 여러 개를 함께 고를 수 있습니다.

**계산 항목 결과 — 잉여 현금흐름과 지출 비율** — 잉여 현금흐름과 지출 비율을 분기별로 본 결과입니다.

잉여 현금흐름(영업 + 투자)과 지출 비율을 함께 골라 열 축 분기별로 본 결과입니다. 비율은 단위가 퍼센트이고, 분모가 0 이면 값을 지어내지 않고 표시하지 않습니다.

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

비교 기준을 계획으로 두고 계획 차이 스위치를 켜면 칸마다 실적 · 계획 · 차이 · 차이율이 붙습니다. 색은 금액 기준과 비율 기준을 둘 다 넘을 때만 칠하며, 기준값은 입력 칸에서 바꿉니다.

**계획 차이 모드 — 실적 · 계획 · 차이 · 차이율** — 계획 차이 스위치를 켠 표 — 실적 · 계획 · 차이 · 차이율이 나란히 붙습니다.

합계 순흐름은 실적 4,142.9 대 계획 5,760.4로 −1,617.5(−28.1%)이고, 내수 매출 수금은 43,636.0 대 43,535.4로 거의 같으며 유형자산 처분은 +195.5(+17.3%)로 유리하게 칠해집니다. 같은 활동 안에서도 항목마다 방향이 달라 합계만 보면 묻히는 차이가 보입니다. 입금은 +, 출금은 −로 읽습니다.

**워터폴과 요인 분해 — 계획에서 실적까지** — 행을 누르자 나타난 계획 → 실적 워터폴과 요인 표입니다.

행을 누르면 오른쪽에 활동별 계획 · 실적 막대와 함께 계획에서 실적까지 요인이 이어지는 워터폴이 나옵니다. 선택한 행의 계획이 어떤 요인을 거쳐 실적이 되는지를 막대로 보여 주고, 아래의 검산 줄은 계획 + 요인 합 − 실적이 0 인지 매번 적습니다.

**변동 사유 입력 창** — 차이가 난 행에 변동 사유를 적는 창입니다.

차이가 난 행을 골라 사유를 적는 창입니다. 사유는 조회 범위와 행 경로에 묶여 저장되고, 저장한 사유는 같은 창에서 고치거나 지울 수 있습니다.

**변동 사유를 저장한 행(✎ 표시)** — 사유를 저장한 행에 ✎ 표시가 붙은 표입니다.

사유를 저장한 행에는 ✎ 표시가 붙어 어느 행에 설명이 달려 있는지 한눈에 보입니다. 축을 바꾸거나 다음에 같은 범위로 다시 열어도 같은 행이면 사유가 따라옵니다.

AI 분석과 보고서 — 숫자는 서비스, 문장은 초안

해설 버튼은 지금 보고 있는 범위를 읽어 요약, 점검이 필요한 항목, 근거 표를 보여 줍니다. 금액과 비율은 서비스가 큐브에서 계산하고 문장은 그 숫자를 풀어 쓴 초안입니다.

**해설 — 규칙 기반 문장 초안과 점검 필요 항목** — 규칙 기반 문장 초안과 점검 필요 항목을 보여 주는 해설 창입니다.

해설 창은 보는 사람의 관점에 맞춘 문장 초안과 점검 필요 항목, 그리고 문장이 기댄 근거 표로 되어 있습니다. 기본은 규칙으로 만든 문장이라 모델을 쓰지 않아도 같은 숫자가 나오며, 초안이므로 근거 표와 원천 거래를 확인한 뒤 쓰도록 안내합니다.

**보고서 내려받기 — 해설을 담은 파워포인트** — 해설을 담은 보고서를 내려받는 단계입니다.

해설을 담은 보고서를 파워포인트 파일로 내려받는 단계입니다. 표와 차트, 요약, 근거가 한 파일에 들어가고 파일은 브라우저 안에서 만들어집니다. 바깥으로 숫자를 보내지 않습니다.

AI 에이전트 — 규칙이 곧 받을 사람

에이전트는 켜 둔 감시 규칙을 하루 한 번 판정해 걸린 항목을 대기함에 올립니다. 판단과 기록은 화면이 아니라 서비스에 있어, 사람이 자리에 없는 시간에는 스케줄 잡이 같은 함수를 부를 수 있습니다.

**에이전트 — 감시 규칙** — 네 가지 감시 규칙과 임계값, 받을 사람입니다.

규칙은 네 가지입니다 — 회수 시기 요인이 −300백만원 이하(자금 담당), 환율 요인 절대값이 20백만원 이상(재무), 순흐름이 계획보다 500백만원 이상 나쁨(경영), 지출 비율 97% 이상(회계). 임계값과 받을 사람이 규칙마다 붙어 있습니다.

**에이전트 — 대기함에 올라온 항목** — 규칙에 걸려 대기함에 올라온 항목입니다.

규칙에 걸린 항목이 대기함에 올라옵니다. 항목마다 어떤 규칙이 걸렸고 어떤 숫자 때문인지 적혀 있어, 담당자는 대기함에서 시작해 요인 분해와 원천 거래로 내려갑니다.

**에이전트 — 같은 날 두 번째 실행은 서버가 막음** — 같은 날 두 번째 실행을 서버가 막은 안내입니다.

같은 날 두 번째 실행은 서버가 막고 내일 다시 실행하라고 안내합니다. 제한을 화면이 아니라 서버 기록이 판정하므로 화면을 여러 번 열어도, 잡으로 불러도 하루 한 번이 지켜집니다.

보기 저장과 복원

짜 둔 축 · 필터 · 측정값에 이름을 붙여 저장하고, 기본 보기와 “열면 바로 조회”를 정해 두면 다음에는 화면을 여는 순간 그 배치로 조회된 채 시작합니다.

**보기 저장 — 이름 · 기본 · 열면 바로 조회** — 축 · 필터 · 측정값에 이름을 붙여 저장하는 창입니다.

저장 창에서 이름을 적고 기본으로 둘지, 열면 바로 조회할지를 고릅니다. 저장되는 것은 축 배치와 필터와 측정값이고 조회 범위는 따로 남습니다.

**저장한 보기 관리** — 저장한 보기를 불러오고 지우는 관리 창입니다.

저장한 보기를 목록으로 보고 불러오거나 삭제합니다. 기본 보기는 표시가 붙고, 하나만 둘 수 있습니다.

**기본 보기로 열면 바로 조회된 채 시작** — 기본 보기로 열자 바로 조회된 채 시작한 화면입니다.

기본 보기가 “열면 바로 조회”로 저장되어 있으면 화면을 여는 순간 조건이 채워지고 조회가 끝난 표가 보입니다. 매번 같은 축을 다시 짜는 수고가 사라지는 자리입니다.

좁은 화면과 한계

창 폭이 줄어도 차트를 감추지 않고 표 아래로 내려 같은 리포트를 봅니다. 한계는 숨기지 않고 화면에 안내합니다.

**좁은 화면(390px) — 차트가 표 아래로 이동** — 390px 폭에서 차트가 표 아래로 내려온 모습입니다.

390px 폭에서는 표가 위에, 차트가 아래에 놓입니다. 조회 조건과 카드도 세로로 쌓이고 표는 가로로 스크롤됩니다. 같은 기능을 같은 순서로 쓸 수 있습니다.

**행 축 단계 상한 안내** — 행 축 단계 상한에 닿았을 때의 안내입니다.

행 축은 세 단계까지이며 그 이상 쌓으려 하면 상한을 안내합니다. 트리가 지나치게 깊어져 표를 읽을 수 없게 되는 것을 막기 위한 한계이고, 더 필요한 분석은 필터로 범위를 줄이거나 저장한 보기로 나누어 보시면 됩니다.

화면 뒤에서 일어나는 일

화면에서 일어나는 일은 세 층으로 나뉩니다. 읽기는 조회 때 한 번 — 조회 조건(회사 · 기간 시작 · 기간 끝)만 서버에 필터로 보내 실적 큐브와 계획 큐브를 읽습니다. 다시 묶기는 브라우저 — 축 전환 · 차원 값 필터 · 계획 차이 모드 · 계산 항목은 이미 읽은 큐브를 다시 합산하므로 서버를 부르지 않습니다. 판단은 서비스 — 요인 분해 · 해설 근거 · 에이전트 규칙 판정과 하루 한 번 제한은 서비스가 계산하고 기록합니다. 화면이 계산을 갖지 않기 때문에 같은 숫자를 화면 밖(배치 · 다른 앱)에서도 똑같이 얻을 수 있습니다.

기간 시작과 끝은 하나의 AND 조건으로 묶어 보냅니다. 같은 필드에 두 조건을 따로 넣으면 UI5 가 OR 로 합쳐 모든 기간이 통과하는 일이 생기므로, 조회 결과가 기간을 무시하는 것처럼 보일 때 먼저 보는 자리입니다.

차이 요인 분해와 점검 규칙

계획 대비 순흐름 차이를 여섯 요인으로 가르며 합은 항상 총차이와 같습니다. 아래 판정은 점검을 돕는 표시이며 원인을 단정하지 않습니다.

요인	조건	사용자 조치
회수 시기 차이	실적 입금이 계획보다 늦거나 이른 칸의 (실적 − 계획)	거래처 그룹 · 자금 항목별 회수 일정을 점검
지급 시기 차이	실적 출금이 계획보다 늦거나 이른 칸의 (실적 − 계획)	지급 일정 변경 사유를 확인
금액 차이	계획대로 실현된 칸에서 외화 금액 차이 × 계획 환율	계약 · 청구 금액 변경을 확인
환율 변동	계획대로 실현된 칸에서 환율 차이 × 실적 외화 금액(나머지 값이라 합이 항상 맞음)	통화별 차이를 확인
계획 외 발생	실적에만 있고 계획에 없던 칸	계획에 반영되지 않은 건인지 점검
계획 미실현	계획에만 있고 실적에 없는 칸	취소 · 이월 여부를 확인

규칙	조건	결과 상태	사용자 조치
차이 색칠	금액 기준과 비율 기준을 모두 넘는 칸	불리하면 빨강 · 유리하면 초록	변동 사유를 입력
원천 검산	원천 라인 합계와 칸의 값을 비교	일치 · 불일치 표시	불일치면 점검 필요
요인 검산	계획 + 요인 합 − 실적	0 이면 일치	0 이 아니면 점검 필요
에이전트 규칙 1	회수 시기 요인이 −300백만원 이하	경고(WARN)	회수 일정 점검
에이전트 규칙 2	환율 요인 절대값이 20백만원 이상	경고(WARN)	통화별 차이 확인
에이전트 규칙 3	순흐름 차이가 −500백만원 이하	경보(ALERT)	요인 분해로 원인 확인
에이전트 규칙 4	지출 비율(출금 ÷ 입금)이 97% 이상	정보(INFO)	점검 필요
하루 한 번	같은 날 두 번째 실행	서버가 LIMIT 으로 판정	내일 다시 실행

산출과 대사 순서

실적 큐브와 계획 큐브를 한 번 읽어 브라우저에서 다시 묶고, 서비스가 요인 분해 · 해설 · 에이전트 판정을 계산합니다. 큐브 합계는 원천 라인 합계와 맞춰 보고, 요인 합은 총차이와 맞춰 봅니다.

순서	산출 · 대사식	검사 건수
1	큐브 합계 = 원천 라인 합계(측정값 · 기간별)	36
2	큐브 점검 결과 NG 건수	36
3	순흐름 = 입금 − 출금(큐브 셀)	1,089
4	영업 + 투자 + 재무 활동 흐름 = 순증감(기간별)	9
5	요인 합 = 총차이, 계획 + 요인 = 실적(기간 범위 × 회사 조합)	135
6	은행별 요인 합 = 전체 요인	5
7	시기 이탈 칸의 부호(입금 +, 출금 −)	2
8	원화 칸의 외화 금액 = 원화 금액	656
9	외화 칸 평균 환율이 가정 환율 범위 안	433
10	엔티티 키 중복	6,420

조회조건

조건	필수	기본값	$filter · 처리
회사	선택	전체(비움)	비우면 전체 회사 · 서버 필터 Bukrs
기간 시작	필수	2026년 01월	Period ge — 끝보다 늦으면 조회하지 않고 안내
기간 끝	필수	2026년 09월	Period le — 시작과 하나의 AND 조건으로 전송
비교 기준	선택	계획(P0)	없음이면 계획 차이 스위치가 꺼짐
금액 기준 · 비율 기준	선택	10백만원 · 5%	차이 색칠 기준 — 둘 다 넘을 때만 칠함(브라우저에서 처리)
차원 값 필터	선택	전체	은행 · 통화 · 자금 항목 등 여러 개 선택 — 읽어 둔 큐브에서 거름

결과 컬럼

컬럼	의미	산출식
입금액	원화 환산 입금 합	Σ 입금 원화 금액
출금액	원화 환산 출금 합(양수로 표시)	Σ 출금 원화 금액
순흐름	자금 영향 방향의 순 흐름	입금 − 출금
원천 라인 수	은행 거래 라인 건수	라인 수 합
차이 · 차이율	실적과 계획의 차이	실적 − 계획 · 차이 ÷ 계획(계획 0 이면 표시 안 함)
지출 비율	입금 대비 출금	출금 × 100 ÷ 입금(입금 0 이면 표시 안 함)
잉여 현금흐름	영업 + 투자활동 순흐름	Flow[A] + Flow[B]
일평균 순흐름	기간 일수로 나눈 순흐름	순흐름 ÷ 기간 일수

좁은 화면에서 달라지는 것

창 폭이 600px 안팎으로 줄면 조회 조건과 카드가 세로로 쌓이고, 표 오른쪽에 있던 차트가 표 아래로 내려옵니다. 표는 가로로 스크롤되며 차트는 감추지 않습니다. 끌어다 놓기가 어려운 터치 화면에서는 칩을 눌러 행 축 · 열 축으로 보내는 방법을 씁니다. 같은 기능을 같은 순서로 쓸 수 있고, 달라지는 것은 배치뿐입니다.

파일 구성

index.html · Component.js · manifest.json
controller/   Main.controller.js · BaseController.js
view/         Main.view.xml · fragments/ (값 필터 · 원천 보기 · 변동 사유 · 해설 · 에이전트 · 보기 저장 · 보기 관리)
model/        cube.js(다시 묶기) · chart.js · pptx.js · layout.js · formatter.js · ErrorHandler.js
i18n/         i18n.properties · i18n_ko.properties
css/          style.css
odata/        metadata.xml · service.js(서비스 로직) · calc.js(요인 분해 · 해설 · 에이전트 판정) · json/(엔티티셋별 데이터 14개)
readme.html

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

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

하고 싶은 일	표준 화면이 해 주는 것	이 앱이 더하는 관점
은행 계정별 현금 포지션 확인	표준 현금 포지션 화면(FF7A)이 계정 · 기간별 잔액을 정확히 보여 줍니다.	계획과 실적의 차이를 요인으로 가르는 일은 하지 않습니다.
예측 라인의 기간별 흐름	유동성 예측 화면(FF7B)이 계획 라인을 관리합니다.	실적과 같은 차원으로 맞붙여 차이를 보는 일은 별도 작업입니다.
은행 거래내역 가져오기 · 후처리	FF_5 와 FEBAN 이 전자 은행 거래내역을 가져와 전기합니다.	가져온 거래를 여러 축으로 돌려 보는 일은 표준 범위 밖입니다.
계정 라인 아이템 조회	FBL3N 이 은행 계정의 라인 아이템을 보여 줍니다.	집계 숫자에서 그 라인으로 내려가는 연결은 사용자가 조건을 다시 넣어야 합니다.
차이의 원인 구분	표준에는 계획 대비 차이를 시기 · 금액 · 환율 · 계획 외 · 미실현으로 나누는 화면이 없습니다.	이 앱이 여섯 요인으로 가르고 합계를 검산합니다.

T-code 별 연계 지점

T-code	이름	연계 — 같은 데이터 · 대사 지점 · 오가는 길 · 표준에 남길 일
FF7A	현금 포지션	은행 계정별 현금 포지션의 합계를 이 앱의 입금 · 출금 · 순흐름과 견줘 봅니다. 오가는 길: 이 앱 결과의 합계가 다르면 FF7A 에서 같은 기간 · 계정을 열어 원천을 확인하고, FF7A 값은 이 앱에서 은행 축 · 기간 축으로 다시 봅니다. 표준에 남길 일: 잔액 확정과 현금 포지션 보고.
FF7B	유동성 예측	예측 라인의 기간별 흐름을 이 앱의 계획 큐브가 이어받습니다. 대사 지점: 계획 큐브 합계와 예측 라인 합계. 표준에 남길 일: 예측 라인의 입력 · 수정.
FF_5	전자 은행 거래내역 가져오기	가져온 거래내역이 원천 라인의 출발점입니다. 대사 지점: 가져온 건수와 원천 라인 수. 표준에 남길 일: 가져오기 실행과 오류 처리.
FEBAN	은행 거래내역 후처리	후처리가 끝난 거래의 전표를 원천 라인에서 확인합니다. 대사 지점: 후처리 대기 건이 이 앱 숫자에 들어 있는지. 표준에 남길 일: 후처리 전표 생성.
FBL3N	G/L 계정 라인 아이템	은행 계정 라인 아이템과 원천 라인을 대조합니다. 오가는 길: 원천 보기 창의 전표 키로 FBL3N 에서 같은 전표를 찾습니다. 표준에 남길 일: 감사 · 법정 대응용 원장 조회.

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

S/4HANA 의 분석 스택(CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office)과 이 앱은 경쟁하지 않고 같은 원천 위에 놓입니다. 아래 “CDS 구성”의 큐브 · 분석 쿼리는 표준 분석 쿼리와 같은 어휘(@Analytics · @AnalyticsDetails)로 짜서, 같은 큐브를 Analysis for Office 나 표준 분석 앱에서도 읽을 수 있게 둡니다. 이 앱이 더하는 것은 요인 분해 · 변동 사유 · 하루 한 번 도는 점검 같은 업무 흐름입니다. 구매 · 판매 · 현금 관리 쪽 개별 Fiori 앱의 이름과 범위는 이 글에서 확인하지 못했으므로 적지 않았고, 도입 때 현재 릴리스 기준으로 확인이 필요합니다.

운영 전환 시 기존 리포트를 없애야 하나요? 없애지 않습니다. 현금 포지션 보고와 법정 · 감사 대응은 표준 화면에 두고, 이 앱은 회의용 분석과 차이 점검을 맡습니다. 두 화면의 합계가 같은지를 운영 대사로 정해 두면 서로를 검증하는 관계가 됩니다.

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

자리	무엇을 정하나	누가
자금 항목 → 활동 구분 매핑	자금 항목이 영업 · 투자 · 재무 중 어디에 속하는지를 매핑 테이블에 둡니다. 회사가 쓰는 자금 항목 체계가 바뀌면 이 표만 고칩니다.	운영 구성 · 자금팀
계획 그룹 → 계획 큐브 매핑	계획 라인을 어느 계획 그룹 · 버전으로 읽을지 정합니다.	자금팀 · 기획팀
거래처 그룹 규칙	은행 거래 라인의 상대방을 고객 · 공급사 · 은행 · 관계사 등으로 묶는 기준입니다.	자금팀 · 회계팀
환율 기준	계획 환율과 실적 환율을 어느 환율 유형 · 환산 시점으로 잡을지 정합니다. 환율 요인이 나머지 값으로 계산되므로 기준이 바뀌면 요인 배분이 바뀝니다.	자금팀
확장 필드 · BAdI	고객사가 라인에 붙이는 확장 필드(예: 프로젝트 · 계약 번호)는 차원 후보가 됩니다. 값 도출은 BAdI 나 확장 필드에서 정합니다.	SAP 개발
권한	회사 코드 · 은행 계정 단위 접근 제한은 집계 단계(DCL)에 겁니다. 드릴스루에만 걸면 합계 뺄셈으로 새어 나갑니다.	보안 · 권한

분석 지표 정의

지표	산식 · 판정 기준	대응 기능	원천 데이터	비고
입금 · 출금	원화 환산 입금 합 · 출금 합(양수)	KPI · 피벗 열	은행 거래 라인 원화 금액	외화는 원화 환산 후 합산
순흐름	입금 − 출금	KPI · 피벗 기본 측정값	은행 거래 라인	입금 +, 출금 −
계획 대비 차이	실적 − 계획 · 차이율 = 차이 ÷ 계획	계획 차이 모드	계획 큐브 · 실적 큐브	분모 0 이면 표시 안 함
지출 비율	출금 ÷ 입금 × 100 · 97% 이상이면 정보	계산 항목 · KPI · 규칙 4	입금 · 출금 합	입금 0 이면 표시 안 함
잉여 현금흐름	영업활동 흐름 + 투자활동 흐름	계산 항목	활동 구분별 순흐름	활동 구분은 자금 항목에서 정함
일평균 순흐름	순흐름 ÷ 기간 일수	계산 항목	기간 마스터 일수	샘플 데이터 기준 일수
여섯 요인	요인 분해 표 참조	워터폴 · 요인 표 · 해설	계획 · 실적 큐브	합 = 총차이 검산 줄

CDS 구성

아래 코드는 구조를 보이기 위한 스케치이며, 원천 테이블 · 필드는 운영 구성에 따라 달라지므로 ‘확인 필요’로 표시했습니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	ZFPL_ITEMMAP · ZI_FundFlowBase	자금 항목 → 활동 구분 · 계획 그룹 매핑과, 은행 거래 라인(실적)과 계획 라인을 같은 모양으로 맞춘 기준 뷰	실적과 계획의 열 구성이 다르면 큐브에서 조인 조건이 흩어집니다
차원	ZI_FundBank · ZI_FundItem	은행 · 자금 항목 · 거래처 그룹 · 활동 구분의 키와 텍스트	화면의 값 필터 목록이 같은 텍스트를 읽게 하려고
큐브(실적)	ZI_FundFlowCube	기간 × 회사 × 은행 × 자금 항목 … 단위로 입금 · 출금 · 순흐름 집계	화면이 읽는 가장 가는 단위를 한 번에 만들어 두려고
큐브(계획)	ZI_FundPlanCube	같은 모양의 계획 버전 셀	계획과 실적을 같은 차원으로 맞붙이려고
쿼리	ZC_FundFlowQuery	분석 쿼리 — 필수 필터 · 기본 행 · 열 · 측정값	표준 분석 도구에서도 같은 큐브를 읽게 하려고
권한	ZC_FundFlowQuery(DCL)	회사 코드 · 은행 단위 접근 제한	집계 단계에서 걸어야 합계로 새지 않습니다
서비스	ZUI_FundFlow_O2(Definition · Binding)	OData V2 로 큐브 · 쿼리를 게시	화면이 읽는 엔티티셋 이름을 고정하려고

① 매핑 테이블 — 자금 항목을 활동 구분 · 계획 그룹에 묶는 기준

이 표에서 결정되는 것은 “어떤 거래가 영업이고 어떤 거래가 투자인가”입니다. 잉여 현금흐름 같은 계산 항목과 활동별 요인 분해가 모두 이 값에 기대므로, 값을 코드에 박지 않고 현업이 고치는 테이블로 둡니다.

" ─────────────────────────────────────────────────────────
" ZFPL_ITEMMAP : 자금 항목 매핑
" 역할  : 자금 항목(회사별) → 활동 구분(A 영업 · B 투자 · C 재무) · 계획 그룹
" 이유  : 활동 구분은 회사의 자금 항목 체계에서 정해지므로 코드가 아니라 데이터로 둔다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '자금 항목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zfpl_itemmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key item       : abap.char(4) not null;
  activity       : abap.char(1);     " A 영업 · B 투자 · C 재무
  planning_group : abap.char(10);    " 확인 필요: 운영 계획 그룹 체계
  direction      : abap.char(1);     " I 입금 · O 출금
}

② 기준 뷰 — 실적 라인을 한 모양으로

실적(은행 거래 라인)과 계획(예측 라인)은 원천이 다릅니다. 이 뷰가 둘을 같은 열 이름으로 맞춰야 큐브가 한 번의 집계로 둘을 다룹니다. 원천 테이블 · 필드는 운영 구성에 따라 달라지므로 확인이 필요하며, 아래는 구조를 보이기 위한 스케치입니다.

" ─────────────────────────────────────────────────────────
" ZI_FundFlowBase : 실적 기준 뷰(은행 거래 라인)
" 역할  : 전기일 · 통화 · 금액 · 은행 · 자금 항목을 큐브가 읽는 이름으로 통일
" 이유  : 실적과 계획이 같은 열 구성이어야 한 번에 맞붙인다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '자금 실적 기준'
define view entity ZI_FundFlowBase
  as select from acdoca as j
  inner join zfpl_itemmap as m
    on  m.bukrs = j.rbukrs
    and m.item  = j.rassc                      " 확인 필요: 자금 항목을 담는 필드
{
  key j.rldnr,
  key j.rbukrs      as CompanyCode,
  key j.gjahr,
  key j.belnr       as DocNo,
  key j.docln       as ItemNo,
      j.budat       as PostDate,
      substring(j.budat, 1, 6) as Period,
      j.rhcur       as LocalCurrency,
      j.hsl         as AmountLocal,
      m.activity    as Activity,
      m.direction   as Direction,
      m.item        as FundItem
}

③ 차원 뷰 — 값 필터의 목록

화면의 값 필터는 큐브에 실제로 있는 값과 이름으로 채워집니다. 이름을 큐브에 박지 않고 차원 뷰에서 association 으로 가져오면, 은행 이름이 바뀌어도 큐브를 다시 집계하지 않습니다.

" ─────────────────────────────────────────────────────────
" ZI_FundBank : 은행 차원
" 역할  : 하우스 뱅크 키와 이름 — 값 필터와 행 축 라벨
" 이유  : 이름을 큐브에서 떼어 두면 이름 변경이 집계에 영향을 주지 않는다
" ─────────────────────────────────────────────────────────
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'HouseBank'
@EndUserText.label : '은행(하우스 뱅크)'
define view entity ZI_FundBank
  as select from t012
{
  @ObjectModel.text.element : ['HouseBankName']
  key bukrs  as CompanyCode,
  key hbkid  as HouseBank,
      @Semantics.text : true
      text1  as HouseBankName                  " 확인 필요: 텍스트 출처(T012T)
}

④ 큐브 — 기간 · 회사 · 은행 · 자금 항목 단위 집계

화면이 한 번에 읽는 가장 가는 단위입니다. 입금 · 출금 · 순흐름을 한 번에 집계해 두고, 통화는 원화로 환산한 금액과 외화 금액을 함께 둡니다. 여기서 부호 규칙(입금 +, 출금 −)이 확정되므로 운영에서 가장 먼저 합의할 곳입니다.

" ─────────────────────────────────────────────────────────
" ZI_FundFlowCube : 실적 큐브
" 역할  : 기간 × 회사 × 은행 × 자금 항목 × 통화 단위로 입금 · 출금 · 순흐름 집계
" 이유  : 화면이 이 한 단위만 읽고 나머지 축은 브라우저에서 다시 묶는다
" ─────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '자금 실적 큐브'
define view entity ZI_FundFlowCube
  as select from ZI_FundFlowBase as b
  association [0..1] to ZI_FundBank as _Bank on _Bank.CompanyCode = b.CompanyCode
{
  key b.Period,
  key b.CompanyCode,
  key b.FundItem,
  key b.Activity,
  key b.Direction,
      @Semantics.currencyCode : true
      b.LocalCurrency,
      @DefaultAggregationDirect: #SUM
      @Semantics.amount.currencyCode : 'LocalCurrency'
      sum( case b.Direction when 'I' then b.AmountLocal else 0 end ) as Inflow,
      @DefaultAggregationDirect: #SUM
      @Semantics.amount.currencyCode : 'LocalCurrency'
      sum( case b.Direction when 'O' then abs( b.AmountLocal ) else 0 end ) as Outflow,
      @DefaultAggregationDirect: #SUM
      @Semantics.amount.currencyCode : 'LocalCurrency'
      sum( case b.Direction when 'I' then b.AmountLocal
                            else 0 - abs( b.AmountLocal ) end )     as Flow,
      _Bank
}
group by b.Period, b.CompanyCode, b.FundItem, b.Activity, b.Direction, b.LocalCurrency

⑤ 계획 큐브 — 같은 모양의 계획

계획 큐브는 실적 큐브와 열 이름이 같아야 화면이 두 큐브를 같은 키로 맞붙입니다. 계획 라인의 원천 테이블과 금액 필드는 운영의 계획 체계에 따라 달라지므로 확인이 필요합니다.

" ─────────────────────────────────────────────────────────
" ZI_FundPlanCube : 계획 큐브(버전 P0)
" 역할  : 계획 라인을 실적 큐브와 같은 열 구성으로 집계
" 이유  : 계획 대비 차이와 요인 분해가 같은 키로 맞붙어야 한다
" ─────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '자금 계획 큐브'
define view entity ZI_FundPlanCube
  as select from fdes as p                      " 확인 필요: 계획 라인 원천
  inner join zfpl_itemmap as m
    on m.bukrs = p.bukrs and m.planning_group = p.grupp
{
  key p.bukrs                       as CompanyCode,
  key m.item                        as FundItem,
  key substring(p.dispw, 1, 6)      as Period,
      m.activity                    as Activity,
      @Semantics.currencyCode : true
      p.waers                       as LocalCurrency,
      @DefaultAggregationDirect: #SUM
      @Semantics.amount.currencyCode : 'LocalCurrency'
      sum( p.wrshb )                as PlanFlow   " 확인 필요: 금액 필드와 부호
}
group by p.bukrs, m.item, substring(p.dispw, 1, 6), m.activity, p.waers

⑥ 분석 쿼리 — 화면이 읽는 문

쿼리 뷰는 큐브 위에 필수 필터와 기본 배치를 얹습니다. 회사와 기간을 필수 필터로 두면 운영 데이터가 클 때 무조건 전량을 읽는 호출을 막을 수 있습니다.

" ─────────────────────────────────────────────────────────
" ZC_FundFlowQuery : 분석 쿼리
" 역할  : 회사 · 기간을 필수 필터로 두고 기본 행 · 열 · 측정값 지정
" 이유  : 전량 조회를 막고, 표준 분석 도구에서도 같은 배치로 연다
" ─────────────────────────────────────────────────────────
@Analytics.query : true
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '자금 수지 분석 쿼리'
define view entity ZC_FundFlowQuery
  as projection on ZI_FundFlowCube
{
  @AnalyticsDetails.query.axis : #ROWS
  Activity,
  @AnalyticsDetails.query.axis : #COLUMNS
  Period,
  @Consumption.filter : { mandatory : true, selectionType : #SINGLE }
  CompanyCode,
  FundItem,
  Inflow,
  Outflow,
  Flow
}

⑦ 권한 — 집계 단계의 DCL

권한은 드릴스루 창에만 걸면 안 됩니다. 합계에서 자기 몫을 빼는 방식으로 남의 숫자를 추정할 수 있기 때문입니다. 큐브의 집계 이전 단계에 걸어 두면 어느 축으로 돌려도 같은 범위만 보입니다.

" ─────────────────────────────────────────────────────────
" ZC_FundFlowQuery : 접근 제어(DCL)
" 역할  : 회사 코드 단위 접근 제한(필요하면 은행 단위 추가)
" 이유  : 집계 단계에서 걸어야 합계 뺄셈으로 새지 않는다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '자금 수지 쿼리 권한'
@MappingRole : true
define role ZC_FundFlowQuery {
  grant select on ZC_FundFlowQuery
    where CompanyCode = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

엔티티셋 이름은 화면이 읽는 계약입니다. 서비스 정의에서 노출 이름을 고정하고, 바인딩을 OData V2 로 게시한 뒤 화면 설정의 서비스 주소만 바꾸면 샘플 서비스가 운영 서비스로 교체됩니다.

" ─────────────────────────────────────────────────────────
" ZUI_FundFlow : 서비스 정의
" 역할  : 큐브 · 계획 · 쿼리를 화면이 읽는 이름으로 노출
" 이유  : 엔티티셋 이름이 화면과의 계약이다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '자금 수지 분석 서비스'
define service ZUI_FundFlow {
  expose ZI_FundFlowCube as CubeSet;
  expose ZI_FundPlanCube as PlanSet;
  expose ZI_FundBank     as BankSet;
}
" 바인딩: ZUI_FundFlow_O2 — 유형 OData V2 - UI(분석 소비용). 게시 후 서비스 활성화 확인

운영 시점에 해야 할 일

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

해야 할 일	무엇을 정하나	정하지 않으면	누가
자금 항목 → 활동 구분 매핑	어떤 자금 항목이 영업 · 투자 · 재무에 속하는가	잉여 현금흐름과 활동별 요인이 기존 보고서와 어긋납니다	자금팀 · 회계팀
계획 원천 · 버전	계획 그룹 · 버전 중 어느 것을 계획으로 읽는가	“계획이 왜 이 숫자냐”가 반복됩니다	자금팀 · 기획팀
환율 유형 · 환산 시점	계획 환율과 실적 환율의 기준	환율 요인이 사람마다 달라집니다	자금팀
부호 규칙	입금 +, 출금 −와 원천 필드 부호의 대응	순흐름이 뒤집혀 보입니다	회계팀
원천(실적 · 계획 · 예측) 확정	어느 테이블 · 필드를 원천으로 삼는가	대사 때 표준 화면과 숫자가 어긋납니다	SAP 개발 · 자금팀
차원 범위	쓸 차원과 확장 필드	나중에 늘리려면 뷰를 고쳐 다시 이송해야 합니다	현업 · SAP 개발
권한 설계	회사 · 은행 단위 접근 범위	합계 뺄셈으로 남의 숫자가 드러납니다	보안 · 권한
성능 기준	조회 기간 상한 · 필수 필터	운영 규모에서 전량 조회가 나옵니다	Basis · SAP 개발
대사 체계	표준 T-code 와 맞출 항목과 주기	숫자를 믿는 근거가 없어집니다	자금팀 · 회계팀
전송(TR) 순서	테이블 → 기준 뷰 → 큐브 → 쿼리 → 권한 → 서비스	활성화 오류로 전송이 되돌아옵니다	SAP 개발
서비스 활성화 · 서비스 주소 교체	서비스 활성화 확인(`/IWFND/MAINT_SERVICE` 또는 바인딩 게시)과 화면 설정의 서비스 주소 교체	화면이 샘플 서비스를 계속 읽습니다	Basis · SAP 개발
배치 등록	에이전트 실행을 사람이 아닌 잡으로 부를지(`SM36`)	사람이 화면을 열 때만 점검이 돕니다	Basis · 자금팀

위 열두 가지는 코딩이 아니라 합의입니다. 합의가 끝나면 기술 작업은 위 코드를 운영 원천에 맞춰 고치고 서비스를 게시하는 일입니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 만드는 쪽에서 대사식 열 가지를 먼저 세우고 전수로 돌렸습니다. 아래 표의 순흐름 4,142.9백만원과 요인 합 검산은 도입 포인트의 사례와 같은 숫자입니다.

대사식	검사 건수	차이
큐브 합계 = 원천 라인 합계(측정값 · 기간별)	36	0
큐브 점검 결과 NG 건수	36	0
순흐름 = 입금 − 출금(큐브 셀)	1,089	0
영업 + 투자 + 재무 활동 흐름 = 순증감(기간별)	9	0
요인 합 = 총차이, 계획 + 요인 = 실적(기간 범위 × 회사 조합)	135	0
은행별 요인 합 = 전체 요인	5	0
시기 이탈 칸의 부호(입금 +, 출금 −)	2	0
원화 칸의 외화 금액 = 원화 금액	656	0
외화 칸 평균 환율이 가정 환율 범위 안	433	0
엔티티 키 중복	6,420	0

합계 8,821건 검사, 차이 0건, 의도적 예외 0건. 화면 쪽은 별도 자동화로 축을 바꿔도 합계가 변하지 않는지, 칸의 값과 원천 라인 합계가 같은지, 날짜 조건(전기일 이후 453줄 · 이전 68줄 · 전체 4,372줄)이 맞게 걸리는지도 확인했습니다.

운영 데이터로 갈 때

운영 데이터는 은행 거래 라인이 월 수십만~수천만 건이 될 수 있습니다. 이 앱의 구조는 큐브를 한 번 읽고 브라우저에서 다시 묶으므로, 큐브 한 번 응답이 충분히 작아야 합니다. 그래서 첫째, 회사와 기간을 필수 파라미터로 두어 전량 조회를 막고, 둘째, 큐브는 일 단위가 아니라 기간 · 은행 · 항목 단위로 서버(HANA)에서 미리 집계해 수만 행 안쪽으로 줄이며, 셋째, 원천 라인은 칸을 누를 때 500줄씩 $top · $skip 으로 읽습니다. 응답 시간은 도입 때 “큐브 한 번 읽기”를 기준으로 합의하고, 인덱스는 전기일 · 회사 · 은행 키에 둡니다. 샘플은 큐브 1,089칸 · 계획 959칸 · 원천 4,372줄이라 이 한계를 보여 주지 않으므로, 운영 규모 성능은 이 글의 샘플로 판단하지 말고 실제 데이터로 확인해야 합니다.

자주 묻는 질문

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

숫자와 산식

요인 분해의 합은 항상 총차이와 같습니까?

같습니다. 환율 변동을 나머지 값으로 두어 합이 맞도록 했고, 화면의 검산 줄이 계획 + 요인 합 − 실적이 0 인지 매번 보여 줍니다. 샘플에서는 계획 5,760.4에서 실적 4,142.9까지 여섯 요인 합이 총차이 −1,617.5와 같았습니다.

환율을 나머지로 둔 만큼 환율 요인에는 계산상 오차 흡수분이 섞일 수 있어, 환율 요인이 클 때는 통화별 차이를 함께 보라고 안내합니다.

여섯 요인은 각각 무슨 뜻입니까?

회수 시기와 지급 시기는 계획 칸이 있고 실적 칸도 있되 시기가 어긋난 차이입니다. 금액은 계획대로 실현된 칸에서 외화 금액이 바뀐 몫, 환율은 같은 칸에서 환율이 바뀐 몫입니다. 계획 외 발생은 실적에만 있는 칸, 계획 미실현은 계획에만 있는 칸입니다.

여섯 요인은 점검을 돕는 분류이며 원인을 단정하지 않습니다. 담당자가 원천 거래와 사유를 확인한 뒤 판단합니다.

입금과 출금의 부호는 어떻게 됩니까?

순흐름은 자금에 미치는 방향으로 입금은 +, 출금은 −입니다. 입금액과 출금액 측정값은 각각 양수로 표시합니다. 지출 비율은 출금 ÷ 입금이므로 부호와 무관합니다.

외화는 어떻게 합산합니까?

큐브는 원화 환산 금액과 외화 금액을 함께 갖습니다. 합계와 차이는 원화 환산 금액으로 하고, 외화 금액은 금액 요인과 환율 요인을 가르는 데만 씁니다. 원화 칸에서는 외화 금액과 원화 금액이 같고, 이 등식은 656건 전수로 확인했습니다. 환율 유형과 환산 시점은 운영 시점에 정해야 하는 항목입니다.

계산 항목은 어떻게 만들어집니까?

식은 Flow[A]+Flow[B] 처럼 측정값과 활동 구분을 토큰으로 지정합니다. 서비스가 정의를 갖고 있어 화면은 식을 풀어 큐브에서 합산하고, 분모가 0 이면 값을 지어내지 않고 비웁니다. 새 계산 항목은 정의 한 줄을 더하는 일입니다.

화면과 조작

축을 바꾸면 서버를 다시 부릅니까?

부르지 않습니다. 조회 때 큐브를 한 번 읽고, 축 전환 · 차원 값 필터 · 계획 차이 · 계산 항목은 브라우저가 그 자료로 다시 묶습니다. 그래서 축을 몇 번 바꿔도 합계가 같고 응답이 즉시입니다. 서버를 다시 부르는 때는 조회를 다시 누를 때와 변동 사유 · 보기를 저장할 때뿐입니다.

행 축과 열 축에 단계 제한이 있는 이유는 무엇입니까?

행 축 3단계, 열 축 2단계입니다. 단계가 늘면 칸 수가 곱으로 늘어 표를 읽을 수 없게 됩니다. 한도에 닿으면 이유를 안내합니다. 더 보고 싶으면 값 필터로 범위를 줄이거나 저장한 보기로 나누어 봅니다.

칸을 눌렀을 때 나오는 원천 라인은 어디서 옵니까?

행 경로와 열 조합이 그대로 조회 조건이 되어 원천 은행 거래 라인을 전기일 순으로 읽습니다. 라인은 500줄씩 나누어 읽고, 맨 위에 라인 수와 합계 일치 여부가 표시됩니다. 같은 창에서 CSV 로 내려받을 수 있습니다.

휴대폰에서도 쓸 수 있습니까?

창 폭이 줄면 차트를 표 아래로 내려 같은 리포트를 봅니다. 터치 화면에서는 끌어다 놓기 대신 칩을 눌러 축으로 보내면 됩니다. 입력이 많은 작업은 큰 화면이 편합니다.

분석 기능

해설은 모델이 씁니까?

기본은 규칙으로 만든 문장 초안입니다. 금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고, 모델을 연결해도 모델은 그 숫자를 읽어 설명만 합니다. 모델을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다. 문장은 초안이므로 근거 표를 함께 확인해야 합니다.

결과를 그대로 보고에 써도 됩니까?

이 화면은 점검 도구이며 최종 판단은 회사와 감사인이 합니다. 점검 필요 항목은 원천 거래와 사유를 확인한 뒤 쓰셔야 하고, 세무 신고에 쓰는 숫자는 회사와 세무 대리인이 표준 절차로 확정합니다.

변동 사유는 어디에 저장됩니까?

서비스가 조회 범위와 행 경로를 키로 저장합니다. 축을 바꾸거나 트리를 다시 펼쳐도 같은 행이면 사유가 따라오고, CSV 와 해설 근거에도 함께 실립니다. 저장한 사유는 같은 창에서 고치거나 지울 수 있습니다.

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

켜 둔 감시 규칙(회수 시기 · 환율 영향 · 순흐름 미달 · 지출 비율)을 서비스가 판정해 걸린 항목을 대기함에 올리고 활동 기록에 남깁니다. 하루 한 번 제한을 서버 기록이 판정하므로 같은 날 두 번째 실행은 거절됩니다. 사람이 없는 시간에는 배치 잡이 같은 함수를 부르게 할 수 있습니다.

보고서(파워포인트)는 어디서 만들어집니까?

브라우저 안에서 만들어집니다. 표와 차트, 요약, 근거를 담은 파일을 외부 라이브러리 없이 지어 내려받으므로, 숫자가 화면 밖으로 전송되지 않습니다.

도입과 운영

어떤 회사에 효과가 큽니까?

여러 은행과 통화를 쓰고 월 자금 수지 계획이 있으며, 계획과 실적의 차이를 엑셀로 맞추는 회사입니다. 법인이 여럿이거나 외화 비중이 있어 환율이 차이의 한 요인으로 따로 보여야 하는 곳일수록 효과가 큽니다. 계획이 없고 잔액만 보는 규모라면 표준 현금 포지션 화면으로 충분합니다.

표준 T-code 를 없애야 합니까?

아닙니다. 현금 포지션(FF7A), 유동성 예측(FF7B), 거래내역 가져오기(FF_5)와 후처리(FEBAN), 라인 아이템(FBL3N)은 그대로 쓰고, 이 화면은 같은 데이터를 조회 · 검증 관점에서 한 번 더 꺼냅니다. 두 화면의 합계가 같은지를 운영 대사로 정해 두면 서로를 검증하게 됩니다.

운영 데이터는 어떻게 연결합니까?

화면은 샘플 서비스로 검증했고, 운영에서는 서비스 뒤의 원천을 CDS 로 교체한 뒤 화면 설정의 서비스 주소를 바꿉니다. 엔티티셋 이름이 계약이므로 화면 코드는 바뀌지 않습니다. 걸리는 시간은 원천 확정과 합의에 달려 있어 이 글에서는 일수를 약속하지 않습니다.

권한은 어떻게 겁니까?

회사 코드 · 은행 단위 접근 제한을 집계 단계(DCL)에 겁니다. 드릴스루 창에만 걸면 합계에서 자기 몫을 빼서 남의 숫자를 추정할 수 있으므로 큐브 단계에 거는 것이 원칙입니다. 변동 사유를 쓸 수 있는 사람은 별도 권한으로 나눌 수 있습니다.

데이터가 아주 크면 어떻게 됩니까?

큐브는 서버에서 기간 · 은행 · 항목 단위로 미리 집계하고, 회사와 기간을 필수 조건으로 두어 전량 조회를 막습니다. 원천 라인은 칸을 눌렀을 때만 500줄씩 읽습니다. 샘플 규모로는 이 한계가 드러나지 않으므로 운영 규모의 응답 시간은 실제 데이터로 확인해야 합니다.

자금 항목이나 계정 매핑이 바뀌면 어떻게 합니까?

매핑 테이블을 고치면 됩니다. 자금 항목이 어느 활동 구분에 속하는지, 어느 계획 그룹과 이어지는지가 데이터이므로 코드를 바꾸지 않습니다. 바뀐 뒤에는 대사식을 다시 돌려 표준 화면과 합계를 맞춥니다.

기존 엑셀 시트를 꼭 없애야 합니까?

없애라고 권하지 않습니다. 처음에는 두 방식을 병행하며 합계를 맞춰 보고, 신뢰가 쌓이면 엑셀의 역할을 줄이면 됩니다. 현업이 쓰던 시트의 항목 체계를 매핑 테이블에 옮겨 두면 전환이 쉽습니다.

이 글의 숫자는 실제 회사 자료입니까?

아닙니다. 가상 회사 · 가상 은행 · 가상 거래처로 만든 검증용 샘플 데이터입니다. 샘플이므로 숫자가 실제 업무의 규모나 효과를 뜻하지 않으며, 이 글의 효과 사례도 샘플에서 실제로 나온 값만 적었습니다.

어떤 점검 항목을 먼저 확인해야 합니까?

도입 때는 활동 구분 매핑, 계획 원천, 환율 기준, 부호 규칙, 대사 체계 다섯 가지를 먼저 합의하시길 권합니다. 이 합의가 서 있으면 나머지는 기술 작업입니다.