SAP 자금 솔루션 자금 포지션 다차원 분석 — 은행·계좌·통화를 끌어다 놓고 기초에서 기말까지 롤포워드와 계획 대비 차이를 원천 전표까지

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

월말 자금 회의의 질문은 늘 비슷합니다. 지금 쓸 수 있는 돈이 얼마인가, 계획과 얼마나 벌어졌나, 왜 벌어졌고 무엇을 해야 하나. 지금은 이 세 답이 표준 현금 포지션 화면 · 은행 명세 · 엑셀 · 회의록으로 흩어져 있습니다. 이 화면은 세 답을 한 화면에 붙여, 보고용 표를 다시 만드는 손일을 줄이고 “어느 숫자가 맞나”를 따지는 시간을 “무엇을 할 것인가”로 돌립니다.

이 화면은 특정 회계기준서를 구현한 것이 아니라 자금 포지션·은행 계좌 잔액·입출금 흐름을 분석하는 업무 화면입니다. 그래서 표준 현금 포지션(FF7A)·유동성 예측(FF7B)·은행 계좌 명세 처리(FEBAN)·총계정원장 라인 항목(FBL3N)을 대체하지 않고, 그 숫자를 이어받아 축을 바꿔 보고 차이를 설명하는 쪽을 맡습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 4~6월 순현금흐름 −718.2백만원의 요인

검증용 샘플 데이터에서 4월~6월 범위를 조회하면 순현금흐름 실적이 2,461.5백만원, 계획이 3,179.8백만원으로 −718.2백만원 차이가 납니다. 표준 화면에서도 이 차이까지는 읽을 수 있습니다. 이 화면은 그 다음을 답합니다. 요인분해를 켜면 차이가 입금 시기(회수 지연) −644.6, 출금 시기(지급 앞당김) −693.0, 금액 차이 +23.4, 환율 +60.1, 계획 외 발생 +358.2, 계획 미실현 +177.7 으로 나뉘고, 요인의 합이 총차이와 맞는지 검산 줄이 0 으로 보여 줍니다. 금액 자체가 달랐다기보다 입출금 시점이 어긋난 몫이 컸다는 것이 한눈에 드러납니다(샘플 데이터 기준이며 운영 원인은 점검이 필요합니다).

숫자 검증도 같은 자리에서 합니다. 샘플 데이터 3,714개 원천 라인으로 대사식 7종 총 970건을 전수로 돌렸고 차이는 0건입니다(자세한 표는 CDS 구성의 검증 결과에 있습니다).

도입하면 달라지는 것

• 월말 자금 보고 준비 — 은행별 현황표, 계획 대비 차이, 사유 정리가 한 화면에서 나와 엑셀 취합과 화면 캡처가 줄어듭니다.
• 회의의 주제 — “어느 잔액이 맞나”가 아니라 “어느 계좌에서 무엇을 할 것인가”를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 저장한 보기가 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 규칙에 걸린 가용 자금·계좌 잔액·외화 비중이 대기함에 올라옵니다.
• 숫자를 의심하는 비용 — 칸을 누르면 원천 전표 라인이 열리고 합계 일치가 표시되어, 표준 화면을 다시 열지 않아도 됩니다.

이런 회사에 맞습니다

은행이 여러 곳이고 계좌가 열 개 안팎 이상이며, 원화와 함께 달러·유로·엔·위안 같은 외화 계좌를 운영하는 회사입니다. 자금팀이 월말마다 은행별·계좌별·통화별 현황표를 엑셀로 만들고, 계획 대비 차이를 설명해야 하는 경영지원 조직에 맞습니다. 본사와 판매법인처럼 회사코드가 둘 이상일 때 가용 자금을 회사별로 가르는 일에도 쓰입니다.

실행 화면

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

사용 방법

1. 조회 조건 입력 — 위쪽 조회 조건에서 회사(다중 선택), 기간 시작·끝, 비교 기준(없음 또는 계획)을 정합니다. 모두 선택 사항이며 비우면 전체 범위입니다.
2. 조회 — 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 저장한 보기 가운데 “열면 바로 조회”로 지정한 것이 있으면 열리자마자 조회됩니다.
3. 요약 확인 — 조회 뒤 조건 영역은 한 줄 요약으로 접히고 입금·출금·순현금흐름·계획 대비 차이·기말 잔액·가용 자금 카드와 피벗·차트가 나타납니다.
4. 보는 사람과 축 이동 — 경영·재무·자금·회계 버튼으로 관점을 바꾸고, 차원 칩을 행 축·열 축으로 끌어다 놓거나 X 로 뺍니다. 측정값·값 필터·표시 단위도 여기서 바꿉니다.
5. 칸 클릭 상세 — 표의 칸을 누르면 그 금액을 이루는 원천 라인 목록이 열리고 합계 일치가 표시됩니다. 행을 고르고 변동 사유·해설·에이전트를 이어서 씁니다.
6. 내보내기 — 표 상단의 CSV 로 현재 피벗을, 원천 라인 창의 CSV 로 라인 목록을, 해설 창의 보고서로 PowerPoint 를 내려받습니다.

무엇으로 만들었나

처음 열었을 때

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

조회 전에도 빈 화면을 주지 않습니다. 조건과 보드, 피벗 틀이 먼저 서 있고 값만 비어 있어서 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 기간은 2026년 1월~9월 전체가 기본이고, 비교 기준은 계획(P0)입니다.

조회를 누르면 요약 카드가 먼저 차고, 그 아래로 레이아웃 보드와 피벗이 함께 뜹니다. 기본 배치는 행 축 은행 › 계좌, 열 축 분기, 측정값은 순현금흐름입니다. 표 오른쪽 차트는 같은 값을 그린 것이라 표를 읽기 전에 모양부터 눈에 들어옵니다.

쓰지 않는 차원은 보관함에, 쓰는 차원은 행 축과 열 축에 놓입니다. 칩을 끌어다 놓으면 그 자리에서 다시 묶입니다. 행 축은 3단계, 열 축은 2단계까지 쌓이고 그 이상은 막습니다.

통화 칩을 행 축으로 끌어다 놓은 모습입니다. 다시 조회할 필요는 없습니다. 큐브는 이미 브라우저에 있고 축을 바꾸는 일은 그 행을 다시 묶는 일이기 때문입니다. 요약 카드의 합계가 그대로인 것이 이 점을 보여 줍니다.

접힌 머리글에는 회사·기간·비교 기준·단위가 한 줄로 남습니다. 긴 회의에서 숫자만 띄워 놓고 이야기할 때 쓰는 모습입니다. 조회를 누르면 이 줄로 자동으로 접힙니다.

경영 요약 — 자리마다 다른 화면

같은 큐브에서 나온 같은 숫자인데, 보는 사람의 자리에 따라 먼저 보여야 할 지표가 다릅니다. 경영·재무·자금·회계 네 관점으로 앞세우는 지표와 쪼개 보는 차원이 함께 바뀝니다.

경영 관점은 순현금흐름이 계획에서 얼마나 벗어났는지를 활동 구분별로 보는 자리입니다. 이 화면은 앞서 통화를 행 축에 올려 둔 상태이며, 관점을 바꿔도 요약 카드의 합계는 그대로입니다.

재무 관점은 쓸 수 있는 돈이 얼마인가가 첫 질문입니다. 가용 자금은 기말 잔액에서 질권 설정·사용 제한 금액을 뺀 값이며, 분기마다 회사와 은행별로 어떻게 움직였는지를 나란히 봅니다.

자금 담당자는 기초에서 출발해 입출금과 환율변동효과를 더하면 기말이 되는 흐름을 통화 › 계좌별로 읽습니다. 외화 통화는 환율변동효과 열이 0 이 아닌 값으로 채워집니다.

회계 관점은 숫자가 맞는지가 첫 질문입니다. 롤포워드 차이가 칸마다 0 인지, 그 칸을 이루는 원천 라인이 몇 건인지를 함께 보여 줍니다. 차이가 있으면 점검 필요로 봅니다.

축 전환과 범위

차원을 끌어다 놓고 값을 걸러 보는 동안 서버는 다시 불리지 않습니다. 열 조합과 행 조합에는 상한을 두었습니다.

열 축은 두 단계까지 쌓입니다. 분기별로 통화마다 열이 생겨 은행·계좌별로 어느 통화에서 움직였는지 한 번에 보입니다. 열 조합이 너무 많아지면 추가를 막고 안내합니다.

은행 다섯 곳 중 두 곳만 골라 본 모습입니다. 값마다 원천 라인 수가 함께 적혀 있어 어느 값이 큰지 알 수 있습니다. 필터를 걸어도 서버를 다시 부르지 않습니다.

필터를 건 상태는 값 필터 버튼에 개수로 표시됩니다. 요약 카드와 표, 차트가 모두 좁혀진 범위(순현금흐름 7,638.7백만원)로 다시 계산됩니다.

표가 좁아도 되는 회의에서는 차트를 넓게 키웁니다. 정한 너비는 그 브라우저에 남아 다음에 열 때도 그대로입니다.

칸에서 원천 전표까지

숫자를 의심할 때마다 다른 화면을 열 필요가 없도록, 칸을 누르면 그 금액을 이루는 원천 라인이 열립니다. 합계가 칸 금액과 같은지는 그 자리에서 확인합니다.

누리은행 3분기 순현금흐름 1,211.6백만원 칸을 누른 모습입니다. 원천 합계가 같은 1,211.6백만원이고 라인은 88건입니다. 목록에는 거래일·전표·은행·계좌·자금 항목·통화·외화금액·환율·원화금액이 보입니다.

잔액 칸은 흐름 칸과 다르게 열립니다. 기간 합이 아니라 기간 말 값이므로 그 기간의 잔액 라인을 보여 줍니다. 한빛 외화 수출대금 계좌의 USD 잔액 라인이 외화금액과 환율, 원화 환산액으로 나란히 놓입니다.

월별로 펼치면 전월 기말이 당월 기초가 되는 흐름이 눈에 들어옵니다. 같은 칸을 누르면 그 달의 원천 라인으로 내려갑니다.

계산 항목 — 기초에서 기말까지

기초 + 입출금 + 환율변동효과 = 기말. 이 등식이 칸마다 맞는지가 자금 포지션 숫자의 첫 번째 검산입니다.

롤포워드 차이는 기초 + 순현금흐름 + 환율변동효과 − 기말 입니다. 칸마다 이 값이 0 인지가 숫자가 맞는지의 첫 확인이고, 0 이 아닌 칸이 있으면 점검 필요로 봅니다.

기준 대비 차이 — 같은 표가 계획 대비 보고가 된다

비교 기준만 바꾸면 같은 표가 계획 대비 차이 보고가 됩니다. 색은 두 기준을 모두 넘는 칸에만 칠하고, 차이는 요인으로 가르며 사유는 행에 남깁니다.

계획(P0)과 실적을 같은 차원으로 나란히 놓습니다. 차이 금액과 차이율이 모두 기준(기본 10백만원 · 5퍼센트)을 넘는 칸만 색이 칠해지고, 하나만 넘는 칸은 칠하지 않습니다.

대상 행과 계획 대비 차이가 위에 보이고, 구분은 입출금 시점·금액·환율·계획 외·일회성·기타 가운데 고릅니다. 사유는 조회 범위와 행 경로를 키로 저장되어 축을 바꾸거나 다음에 열어도 그 행에 따라옵니다.

왼쪽 파란 막대가 계획, 오른쪽 파란 막대가 실적이고 그 사이를 요인이 잇습니다. 4~6월 범위에서 계획 3,179.8백만원이 회수 지연 −644.6, 지급 앞당김 −693.0, 금액 차이 +23.4, 환율 +60.1, 계획 외 발생 +358.2, 계획 미실현 +177.7을 거쳐 실적 2,461.5백만원이 됩니다.

행을 고르면 그 행의 차이만 요인으로 나뉩니다. 맨 아래 검산 줄은 계획 + 요인 합 − 실적 = 0 을 매번 보여 줍니다. 0 이 아니면 계획 버전이나 조회 범위를 먼저 확인합니다.

AI 분석과 보고서

숫자는 서비스가 계산하고 해설은 그 숫자를 읽어 쓰며, 근거는 표로 함께 보여 줍니다.

해설은 서비스가 큐브에서 계산한 숫자로 쓰며, 결론은 점검 필요 수준으로 적습니다. 묶음 차원과 보는 사람을 바꾸면 해설도 다시 쓰입니다.

해설이 어떤 숫자를 읽었는지 같은 창에서 확인합니다. 작성 방식(규칙)도 함께 표시되어 사람이 근거를 검증할 수 있습니다.

현재 범위의 표와 차트, 워터폴을 담은 보고서를 서버에 파일을 남기지 않고 브라우저에서 바로 만듭니다. 내려받았다는 알림이 아래에 뜹니다.

AI 에이전트

화면을 열지 않아도 정해 둔 규칙으로 자금 부족과 환율 노출을 점검하고 대기함에 올립니다. 하루 한 번만 실행됩니다.

규칙마다 지표·연산자·임계값과 보는 사람이 붙어 있습니다. 가용 자금 하한, 계획 대비 순현금흐름 차이, 계좌 잔액 하한, 외화 보유 비중 한도 네 가지입니다. 하루 한 번만 실행할 수 있습니다.

실행하면 규칙에 걸린 항목이 대기함에 올라가고 머리글의 에이전트 버튼에 건수가 표시됩니다. 같은 규칙에서 여러 대상이 걸리면 한 규칙이 여러 건이 될 수 있습니다.

제한은 화면이 아니라 서비스가 실행 기록으로 판단합니다. 그래서 브라우저를 바꾸거나 새로 고쳐도 같은 날 두 번째 실행은 막힙니다.

레이아웃 저장과 복원

자주 쓰는 배치를 이름으로 저장하고 다음에 그대로 이어서 씁니다.

자주 쓰는 배치를 이름으로 저장합니다. 다음에 열 때 이 보기로 시작하게 하거나, 열자마자 조회까지 하게 할 수 있습니다.

보기는 서비스에 저장되어 어느 브라우저에서 열어도 따라옵니다. 기본과 자동 조회 표식은 보기 하나에만 붙습니다.

축을 많이 바꾼 뒤에도 한 번에 처음 배치로 돌아갑니다. 저장한 보기는 그대로 남습니다.

좁은 화면과 한계

열·행 조합 상한과 휴대폰 폭의 배치입니다. 한계는 숨기지 않고 화면에 안내합니다.

열 축에 차원을 너무 많이 올리면 조합이 108개가 되어 표를 읽을 수 없게 됩니다. 이 경우 표를 그리지 않고 열 축을 줄이라고 안내합니다.

행 축을 회계기간 › 계좌 › 자금 항목처럼 깊게 쌓으면 조합이 474개가 됩니다. 화면은 300행까지만 그리고 필터나 축 조정으로 범위를 줄이도록 안내합니다.

휴대폰 폭에서는 요약 카드가 두 줄로 접히고 조건 영역이 한 줄 요약이 됩니다. 가로 스크롤은 생기지 않습니다.

좁은 폭에서는 표와 차트가 나란히 놓일 자리가 없어 차트가 표 아래에 놓입니다. 표는 가로로 넘겨 보고 차트는 그대로 읽습니다.

화면 뒤에서 일어나는 일

축을 바꾸는 일과 원천으로 내려가는 일은 서로 다른 경로를 씁니다. 큐브와 계획은 조회 때 한 번 읽고, 그 뒤의 축 변경은 모두 브라우저 안에서 다시 합산합니다.

롤포워드와 차이 판정 — 판정 조건에서 사용자 조치까지

색과 문구는 점검을 돕는 표시이며 결론이 아닙니다. 판정 조건과 결과 상태, 그에 따른 조치는 아래와 같습니다.

처리 순서는 이렇습니다. 원천 라인을 9개 차원 단위로 집계해 큐브와 계획을 만들고, 화면은 그 큐브를 한 번 읽어 와서 측정값을 더합니다. 흐름과 환율변동효과는 기간을 더하고, 기초는 범위의 첫 기간, 기말과 제한 자금은 마지막 기간 값을 씁니다. 계산 항목은 토큰 식으로 정의해 서버와 화면이 같은 식을 씁니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 요약 카드가 두 줄로 접히고 차트가 표 오른쪽이 아니라 표 아래로 내려옵니다. 조건 영역은 한 줄 요약으로 접히며 가로 스크롤은 생기지 않습니다. 표 안의 열이 많으면 표 영역만 가로로 넘깁니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ controller/  view/  model/  css/  i18n/
├─ odata/       메타데이터 · 서비스 로직 · 자료 파일(엔티티셋 14종)
└─ media/       소개 영상

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준 화면으로 충분한 일은 표준에 두고, 표준에서 이어지지 않는 자리만 이 화면이 잇습니다.

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

T-code 별 연계 지점

맞닿는 표준 T-code 마다 이어받는 데이터와 대사 지점을 아래에 적었습니다. 운영으로 옮긴 뒤에도 기존 표준 화면은 없애지 않습니다. 이 화면의 숫자와 표준 화면의 숫자를 맞춰 보는 용도로 함께 씁니다.

이 앱의 결과에서 표준 화면으로 가는 길은 위 표의 “오가는 방법”과 같습니다. 반대로 표준 화면에서 본 계좌 잔액은 이 앱의 계좌 행에서 같은 기간의 기말 잔액으로 다시 확인합니다. 법정·공시·감사·세무 신고용 보고는 표준에 남겨 둡니다.

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

S/4HANA 에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 수단이 이미 있습니다. 이 화면은 그것들과 경쟁하기보다, 같은 CDS 큐브 위에서 “끌어다 놓는 축 전환 · 칸에서 원천으로 · 계획 대비 차이 요인”을 한 화면에 모으는 자리를 맡습니다. 같은 쿼리를 Analysis for Office 에서 열어도 숫자는 같아야 하고, 그 차이가 0 인지를 대사 항목으로 둡니다. 특정 Fiori 분석 앱과의 기능 대응은 확인하지 못해 적지 않습니다(확인 필요).

분석 지표 정의표

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

CDS 구성

샘플 데이터로 돌던 화면을 운영 데이터로 옮기려면 같은 서비스 계약을 CDS 로 채웁니다. 아래 코드는 구조를 보여 주는 스케치이며, 원천 테이블과 필드는 고객사 시스템에서 확인이 필요합니다(확인 필요 표시).

뷰 레이어 구성

① 계좌·자금 항목 매핑 테이블

자금 포지션의 차원은 코드 사전에서 시작합니다. 어느 은행 계정이 어느 계좌이고, 어느 입출금 계정이 어느 자금 항목·활동 구분인지가 이 테이블 한 곳에서 정해집니다. 이 매핑이 바뀌면 큐브의 모든 합계가 바뀌므로 변경 관리를 가장 엄격하게 합니다.

" ───────────────────────────────────────────────
" ZCPOS_ACCTMAP : 은행 계정 → 계좌 · 자금 항목 · 활동 구분 매핑
" 역할  : 큐브가 차원 값을 읽는 유일한 기준표
" 이유  : 계정 체계가 바뀌어도 뷰를 고치지 않고 이 표만 고치도록
" ───────────────────────────────────────────────
@EndUserText.label : '자금 포지션 계정 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcpos_acctmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key saknr      : saknr not null;     " 은행 계정(G/L)
  acct_id        : abap.char(10);      " 계좌 식별
  bank_id        : abap.char(10);      " 은행
  item_id        : abap.char(10);      " 자금 항목
  activity       : abap.char(3);       " 영업 / 투자 / 재무
  cpty_grp       : abap.char(4);       " 거래처 그룹
  restricted     : abap_boolean;       " 질권 설정·사용 제한 계좌 여부
}

② 차원 뷰 — 은행·계좌

차원은 큐브에서 join 을 한 번만 걸도록 별도 뷰로 둡니다. 값 도움말과 텍스트가 모두 이 뷰를 보게 하면 이름이 바뀔 때 한 곳만 고치면 됩니다. 은행 계좌 마스터(T012K 등)는 후보이며 실제 필드는 시스템에서 확인합니다.

" ───────────────────────────────────────────────
" ZI_CashPosAccount : 은행 계좌 차원 (한 행 = 한 계좌)
" 역할  : 계좌 이름·은행·통화·계좌번호(마스킹)를 한 곳에서 제공
" 이유  : 큐브·쿼리·값 도움말이 같은 이름표를 쓰게 함
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '자금 포지션 계좌 차원'
@ObjectModel.dataCategory : #DIMENSION
@Analytics.dataCategory : #DIMENSION
define view entity ZI_CashPosAccount
  as select from t012k as k
    inner join   t012  as b on b.bukrs = k.bukrs and b.hbkid = k.hbkid  " 확인 필요
{
  key k.bukrs                           as CompanyCode,
  key k.hbkid                           as HouseBank,
  key k.hktid                           as AccountId,
      @Semantics.currencyCode: true
      k.waers                           as AccountCurrency,
      b.banka                           as BankName,
      concat('****', right(k.bankn, 4)) as AccountNoMasked
}

③ 원천 라인 뷰 — 입출금과 잔액 라인

큐브의 재료는 두 종류입니다. 은행 계정에 전기된 입출금 라인(거래 라인)과 기간 말 잔액 라인입니다. 둘을 한 뷰에서 라인 유형(T·B)으로 구분해 두면 큐브가 흐름은 T 만, 잔액은 B 만 집계할 수 있습니다. 전표 원천은 BKPF·BSEG 후보이며 표준 계정 잔액 뷰의 사용 여부는 확인 필요입니다.

" ───────────────────────────────────────────────
" ZI_CashPosItem : 은행 계정 입출금·잔액 라인
" 역할  : 전표 라인과 기간 말 잔액을 라인 유형(T/B)으로 구분해 제공
" 이유  : 흐름은 합산하고 잔액은 기간 말 값만 쓰기 위해 구분이 필요
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '자금 포지션 원천 라인'
define view entity ZI_CashPosItem
  as select from bseg as s
    inner join   bkpf as h on h.bukrs = s.bukrs and h.belnr = s.belnr and h.gjahr = s.gjahr
    inner join   zcpos_acctmap as m on m.bukrs = s.bukrs and m.saknr = s.hkont
{
  key s.bukrs, key s.belnr, key s.gjahr, key s.buzei,
      'T'                                   as LineType,
      h.budat                               as PostingDate,
      m.acct_id                             as AccountId,
      m.item_id                             as CashItem,
      m.activity                            as Activity,
      case s.shkzg when 'S' then 'I' else 'E' end as InOut,   " 차변=입금 / 대변=출금
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      case s.shkzg when 'S' then s.wrbtr else -s.wrbtr end   as FlowTc,
      h.waers                               as TransactionCurrency,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      case s.shkzg when 'S' then s.dmbtr else -s.dmbtr end   as FlowLc,
      h.hwaer                               as CompanyCurrency
}

④ 큐브 뷰 — 실적 집계

화면이 브라우저에서 하던 집계를 DB 로 내립니다. 기간·회사·계좌·통화·활동 구분·자금 항목·거래처 그룹·입출 구분 단위로 묶고, 흐름은 합산합니다. 기초와 기말은 기간 합산이 아니므로 별도 잔액 뷰에서 마지막·첫 기간 값만 읽습니다.

" ───────────────────────────────────────────────
" ZI_CashPosCube : 자금 포지션 실적 큐브
" 역할  : 입출금 흐름을 9개 차원 단위로 집계(기간 합산)
" 이유  : 기간 합산이 가능한 측정값만 큐브에 두고 잔액은 따로 둠
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '자금 포지션 큐브'
@Analytics.dataCategory : #CUBE
@ObjectModel.modelingPattern : #ANALYTICAL_CUBE
define view entity ZI_CashPosCube
  as select from ZI_CashPosItem as i
{
  key left(i.PostingDate, 6)  as Period,
  key i.bukrs                 as CompanyCode,
  key i.AccountId,
  key i.TransactionCurrency,
  key i.Activity,
  key i.CashItem,
  key i.InOut,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      sum(i.FlowLc)           as Flow,
      i.CompanyCurrency,
      count(*)                as LineCount
}
where i.LineType = 'T'
group by left(i.PostingDate, 6), i.bukrs, i.AccountId, i.TransactionCurrency,
         i.Activity, i.CashItem, i.InOut, i.CompanyCurrency

⑤ 계획 뷰 — 같은 키 모양

계획은 실적과 같은 키 모양으로 집계해야 나란히 붙습니다. 키가 하나라도 어긋나면 계획이 실적 옆에 붙지 않고 따로 뜹니다. 계획 원천(유동성 예측 계획 테이블 등)은 확인 필요이며, 버전 코드는 고객사가 정합니다.

" ───────────────────────────────────────────────
" ZI_CashPosPlan : 자금 포지션 계획 큐브 (버전별)
" 역할  : 계획 순현금흐름을 실적과 같은 키로 제공
" 이유  : 실적 ↔ 계획 조인이 키 일치로만 성립하도록
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
define view entity ZI_CashPosPlan
  as select from zcpos_plan as p      " 계획 원천 — 확인 필요
{
  key p.version                 as PlanVersion,
  key p.period                  as Period,
  key p.bukrs                   as CompanyCode,
  key p.acct_id                 as AccountId,
  key p.waers                   as TransactionCurrency,
  key p.activity                as Activity,
  key p.item_id                 as CashItem,
  key p.in_out                  as InOut,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      @Aggregation.default: #SUM
      p.plan_flow               as PlanFlow,
      p.hwaer                   as CompanyCurrency
}

⑥ 쿼리 뷰 — 행·열 기본 배치와 계산 측정값

쿼리는 화면의 기본 배치를 정의합니다. 행 축 은행 › 계좌, 열 축 분기, 측정값 순현금흐름이 기본이고, 차이는 여기서 한 번만 정의합니다. 같은 쿼리를 Fiori 와 Analysis for Office 가 그대로 띄웁니다.

" ───────────────────────────────────────────────
" ZC_CashPosQuery : 자금 포지션 분석 쿼리
" 역할  : 기본 행·열 배치, 필터, 계산 측정값(차이)을 한 곳에서 정의
" 이유  : 화면과 다른 분석 도구가 같은 정의를 쓰게 함
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '자금 포지션 분석'
@Analytics.query : true
@Metadata.allowExtensions : true
define view entity ZC_CashPosQuery
  as select from ZI_CashPosCube
  association [0..1] to ZI_CashPosPlan as _Plan
    on  $projection.Period = _Plan.Period
    and $projection.AccountId = _Plan.AccountId
{
  @AnalyticsDetails.query.axis: #ROWS
  @AnalyticsDetails.query.display: #KEY_TEXT
  key AccountId,
  @AnalyticsDetails.query.axis: #COLUMNS
  key Period,
  @Consumption.filter: { selectionType: #INTERVAL, multipleSelections: false, mandatory: false }
  CompanyCode,
  @AnalyticsDetails.query.axis: #FREE
  Activity,
  @DefaultAggregation: #SUM
  Flow            as NetFlow,
  _Plan.PlanFlow  as PlanFlow
}

⑦ 권한 — 회사코드와 계좌 범위

권한은 집계를 읽는 자리에 걸어야 합니다. 드릴스루에만 걸면 전사 합계와 자기 몫의 차이로 남의 숫자가 뺄셈으로 드러납니다. 회사코드와 은행 계좌 범위를 표준 권한 객체로 확인합니다.

" ───────────────────────────────────────────────
" ZC_CashPosQuery (DCL) : 회사코드 + 은행 계좌 범위 권한
" 역할  : 사용자가 볼 수 있는 회사코드·계좌 행만 반환
" 이유  : 집계 단계에서 걸어야 합계에서 남의 숫자가 새지 않음
" ───────────────────────────────────────────────
@EndUserText.label : '자금 포지션 권한'
@MappingRole : true
define role ZC_CashPosQuery {
  grant select on ZC_CashPosQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( AccountId )   = aspect pfcg_auth( ZF_CPOS_ACC, ACCID, ACTVT = '03' );   " 권한 객체 이름은 설계 필요
}

⑧ 서비스 정의 — OData 로 내보내기

마지막으로 쿼리를 OData V2 서비스로 노출합니다. 화면이 읽는 엔티티셋 이름과 키를 이 정의가 정하므로, 화면의 서비스 계약과 같은 이름으로 맞춥니다.

" ───────────────────────────────────────────────
" ZUI_CashPos : 서비스 정의 + 바인딩(OData V2 - UI)
" 역할  : 쿼리·원천 라인·차원을 엔티티셋으로 노출
" 이유  : 화면의 서비스 계약과 이름·키를 맞추기 위해
" ───────────────────────────────────────────────
@EndUserText.label : '자금 포지션 서비스'
define service ZUI_CashPos {
  expose ZC_CashPosQuery    as CubeSet;
  expose ZI_CashPosPlan     as PlanSet;
  expose ZI_CashPosItem     as ItemSet;
  expose ZI_CashPosAccount  as AccountSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

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

샘플 데이터 3,714개 원천 라인(거래 3,573 · 계획 33 · 잔액 108)으로 대사식을 전수로 돌린 결과입니다. 의도적 예외는 0건입니다.

운영 데이터로 갈 때

은행 입출금 라인이 수천만 건이면 집계는 브라우저가 아니라 DB 에서 해야 합니다. 큐브 뷰에서 기간·회사·계좌 단위로 미리 집계하고, 조회 조건에서 기간과 회사를 필수로 받아 한 번에 읽는 행을 줄입니다. 화면은 한 번에 5,000행까지만 읽고 행 조합은 300개까지만 그리도록 상한을 두었습니다. 응답 시간 기준은 고객사 데이터 규모로 실측해 정해야 하며 현재는 확인 필요입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

AI 분석과 에이전트

도입과 운영