자금 솔루션 지급 수단·채널 이행 다차원 분석 — 은행·수단·채널별 지급액과 계획 차이를 한 화면에서

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

월말이 가까워지면 자금 담당자는 같은 질문을 되풀이해서 받습니다. 어느 은행으로 얼마가 나갔는지, 어떤 지급 수단과 채널에 몰렸는지, 계획한 지급은 제때 이행됐는지, 그리고 그 차이는 어디서 났는지입니다. 지금은 표준 지급 화면과 은행 포털, 엑셀을 번갈아 열어 묶음마다 따로 뽑고 합계를 맞추는 데 시간을 씁니다. 은행별 표와 수단별 표의 합이 달라지면 숫자를 의심하는 회의가 먼저 열립니다.

이 앱은 지급 라인을 한 번 읽어 아홉 개 축(지급 법인·은행·지급 구분·통화·지급 수단·결제 조건 구간·지급 채널·긴급 여부, 그리고 회계기간)으로 묶는 큐브를 만들고, 보는 사람이 행과 열을 끌어다 놓으면 브라우저가 같은 큐브에서 다시 묶습니다. 계획 지급(P0)을 같은 축으로 얹어 차이를 여섯 요인으로 나누고, 칸을 누르면 그 금액을 만든 원천 지급 라인까지 내려갑니다. 관련 기준서는 IAS 7 현금흐름표(K-IFRS 제1007호)와 IFRS 7 금융상품: 공시(K-IFRS 제1107호) 영역에 걸치는 자금 관리 업무이며, 이 앱은 기준서 문단을 판단하는 도구가 아니라 지급 이행을 점검하는 조회 도구입니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 계획 대비 +778.47 억원을 여섯 요인으로

검증용 샘플 데이터(가상의 4개 법인, 9개월, 지급 라인 3,391줄)로 보면 지급액은 40,674.03 억원이고 계획은 39,895.56 억원이라 계획 대비 +778.47 억원(+2.0%)입니다. 표준 화면은 여기까지 알려 줍니다. 이 앱은 그 778.47 억원을 여섯 요인으로 가릅니다 — 계획된 지급이 계획보다 커진 몫 +940.18 억원, 작아진 몫 −875.27 억원, 환율 −18.29 억원, 지급 시점 이동 +10.89 억원, 계획 없이 나간 지급 +1,239.10 억원, 지급되지 않고 넘어간 이월 −518.15 억원입니다. 계획 + 요인 합 − 실적은 0 으로 맞아 떨어지고, 이 검산은 범위 25개에서 모두 같았습니다. 같은 자료의 대사식 1,300건도 차이 0 이었습니다(통화별 원 단위 반올림 차이는 최대 150원, 허용 오차). 점검할 대상은 "계획 외 지급" 항목부터라는 것을 합계가 아니라 요인에서 읽을 수 있습니다.

도입하면 달라지는 것

• 지급 현황 보고 준비 — 은행별·수단별·채널별 표를 따로 뽑아 맞추던 일이 한 화면의 축 전환으로 바뀝니다.
• 회의의 질문 — "어느 표가 맞나"가 아니라 "계획 외 지급은 왜 늘었나"로 옮겨 갑니다.
• 수수료와 긴급 지급 점검 — 수단별 수수료율, 긴급 지급 비중, 기말 미지급 잔액을 같은 표에서 비교합니다.
• 기록 — 차이 사유가 행에 남아 다음 달에 같은 질문을 되풀이하지 않습니다.
• 사람이 열지 않은 날 — 하루 한 번 도는 점검 규칙이 걸린 항목을 대기함에 올립니다.

이런 회사에 맞습니다

법인이 여러 곳이고 외화 지급(USD·EUR·JPY 등)이 섞여 있으며, 지급 수단(이체·외화 송금·전자어음·카드)과 채널이 여러 가지인 제조·유통 기업의 자금팀과 회계팀에 맞습니다. 하우스 뱅크가 여러 곳이라 은행별 집중도와 수수료 부담을 보고 싶거나, 지급 계획 대비 이행률을 월 단위로 점검하는 조직이 대상입니다. 지급 건수가 적고 은행이 한두 곳뿐이라면 표준 화면과 엑셀로도 충분할 수 있습니다.

실행 화면

사용 방법

1. 조회 조건 입력 — 기간(부터)·기간(까지)은 필수이고 기본은 2026년 01월~09월입니다. 지급 법인은 비우면 전체, 비교 기준은 지급 계획(P0)과 비교가 기본입니다.
2. 조회 — 오른쪽 위 파란 [조회] 버튼을 누르거나 조건 칸에서 Enter 를 누릅니다. 저장한 기본 보기에 자동 조회를 켜 두면 화면을 열 때 자동으로 실행됩니다.
3. 요약 확인 — 위쪽 지표 다섯 개와 "보는 사람" 탭(경영·재무·자금·회계)을 봅니다. 탭을 바꾸면 먼저 보여 줄 축과 설명이 달라지고 숫자는 같습니다.
4. 탭·축 이동 — 차원 보관함의 칩을 끌어 행 축이나 열 축에 놓거나 칩을 눌러 행 축에 넣습니다. 서비스를 다시 부르지 않고 총합은 그대로입니다.
5. 행·칸 클릭 상세 — 행을 누르면 차트와 요인분해가 그 행 기준으로 바뀌고, 금액 칸을 누르면 원천 지급 라인이 열려 "표의 값과 일치"가 표시됩니다.
6. 내보내기 — 표 오른쪽 위 [CSV] 는 지금 보이는 표를, 원천 라인 창의 [CSV] 는 그 칸의 라인을 내려받습니다. [해설]에서 보고서(PPTX)도 받을 수 있습니다.

무엇으로 만들었나

처음 열었을 때 — 조회 전과 조회 직후

처음 열면 조건 줄과 비어 있는 레이아웃 보드가 보이고, 조회를 누르면 요약 지표와 표·차트가 한 번에 채워집니다. 여기까지가 서비스를 읽는 전부이고, 이후 축을 바꾸는 일은 브라우저 안에서 일어납니다.

기간(부터)·기간(까지)는 필수이고 기본은 2026년 01월~09월입니다. 지급 법인은 비우면 전체이고, 비교 기준은 지급 계획(P0)과 비교가 기본입니다. 표 자리의 안내 문구가 [조회]를 누르라고 알려 줍니다.

지급액 40,674.03 억원, 최대 지급 은행 비중 33.9%, 평균 지급 수수료율 0.18%, 긴급 지급 비중 16.7%, 계획 대비 +778.47 억원(+2.0%)이 먼저 보입니다. 기본 배치는 행 축이 지급 은행과 지급 구분, 열 축이 분기입니다.

점선 상자가 칩을 놓을 수 있는 자리입니다. 보관함의 칩을 끌어 행 축이나 열 축에 놓고, 축의 × 로 뺍니다. 칩을 눌러도 행 축에 들어갑니다.

이 과정에서 서비스 호출은 없고 총합은 그대로 40,674.03 억원입니다. 같은 칸이 어떻게 갈라지는지는 열 머리글을 보면 됩니다.

요약 지표는 접어도 남습니다. 좁은 노트북 화면에서 표를 크게 쓰고 싶을 때 씁니다.

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

같은 데이터를 경영·재무·자금·회계 네 시선으로 읽도록 "보는 사람" 탭을 두었습니다. 탭을 바꾸면 먼저 보여 줄 축과 설명이 달라지고 숫자는 같습니다.

가상 시중은행 A 가 33.9% 로 가장 크고, 계획 대비 +778.47 억원은 점검 필요 수준으로 표시됩니다. 은행 집중도 지수도 함께 적혀 있습니다.

원재료 대금이 가장 크고 평균 수수료율은 지급 구분마다 0.13~0.22% 사이로 나뉩니다. 수수료율 차이가 큰 구분을 찾는 데 쓰는 화면입니다.

기말 미지급 잔액은 마지막 기간 값만 쓰는 측정값이라 기간을 합쳐도 늘어나지 않습니다. 외화 지급은 통화별로 원화로 환산한 값입니다.

수수료율은 수단별 가정값에서 나온 값이라, 실제 청구 내역과 다른 수단이나 은행이 있는지 점검 필요 항목을 좁히는 용도입니다.

축 전환과 범위 — 다시 조회하지 않고 다시 묶기

축 바꾸기·값 필터·표 행 수는 모두 읽어 둔 큐브 안에서 일어납니다. 총합이 바뀌지 않는다는 것이 이 구조의 약속이고, 아래 화면이 그 모습입니다.

행에는 지급 은행과 지급 구분, 열에는 분기와 지급 수단이 놓여 있습니다. 표 행 수 12 는 한 번에 펼쳐 보일 행 상한이고, 넘으면 안내가 나옵니다.

값 옆의 숫자는 그 값의 원천 라인 수입니다. 적용하면 읽어 둔 큐브 안에서 바로 걸러지고 서비스는 다시 부르지 않습니다.

합계가 28,583.94 억원으로 줄고, 값 필터 버튼 옆에 걸린 필터 수가 표시됩니다. 조건을 지우면 40,674.03 억원으로 돌아옵니다.

막대는 표의 첫 행 축 기준으로 그려집니다. 손잡이를 끌어 표를 넓게 쓰거나 차트를 크게 키웁니다.

칸에서 원천 문서까지 — 숫자를 의심할 때 내려가는 길

금액 칸을 누르면 그 칸을 이루는 원천 지급 라인이 열립니다. 라인 합계와 칸 값이 같으면 "표의 값과 일치"가 표시되므로, 숫자를 믿을 수 있는지 그 자리에서 가립니다.

표의 값 4,734.94 억원과 원천 합계가 같아 "표의 값과 일치"가 뜨고 라인 수는 356건입니다. 지급 계획만 있고 지급되지 않은 이월 라인은 원천 목록에서 제외됩니다.

외화 라인은 환율을 곱한 원화 값이 오른쪽에 나옵니다. 오른쪽 아래 CSV 로 이 칸의 라인만 내려받을 수 있습니다.

기간별 요약과 계산항목

행 축을 회계기간으로 바꾸면 월별 지급 흐름이 보이고, 계산항목은 측정값 두 개 이상으로 만든 비율과 합계를 같은 표에 올려 줍니다.

같은 큐브로 행 축만 바꾼 화면입니다. 월마다 지급액이 4,000억원 안팎에서 움직이는 모양을 막대로 확인합니다.

측정값 선택에서 "수수료 포함 지급액(원)"을 고르면 표와 차트가 함께 바뀝니다. 계산항목은 서비스의 정의를 읽어 화면에서 계산합니다.

지급액과 수수료, 긴급 지급 비중 등을 같은 기간 열 옆에 나란히 둡니다. 비율 항목은 합계 행에서도 분자·분모를 다시 합쳐 계산합니다.

계획 대비 차이 — 같은 표가 점검표가 된다

계획 차이 스위치를 켜면 실적·계획·차이·차이율이 열로 붙습니다. 색칠은 금액 기준과 비율 기준을 둘 다 넘을 때만 입혀, 작은 차이에 눈이 흩어지지 않게 했습니다.

금액 기준 3,000 백만원과 비율 기준 5% 를 모두 넘는 칸만 붉게 표시되고 기준은 화면에서 바꿀 수 있습니다. 붉은 칸은 단정이 아니라 점검 필요 신호입니다.

행을 누르면 그 행의 계획 지급액에서 실적 지급액까지의 요인이 워터폴로 그려지고, 아래 검산 줄이 계획 + 요인 합 − 실적 = 0 인지 적습니다. 전체 합계 기준으로는 계획 39,895.56 억원에서 실적 40,674.03 억원까지가 이어집니다.

구분은 지급 시점·지급 금액·환율·계획 외 지급·일회성·기타 가운데서 고릅니다. 저장하면 표의 행 앞에 표시가 붙고 새로 고쳐도 남아 있습니다.

요인 이름은 계획 초과 지급, 계획 미달 지급, 환율, 지급 시점 이동, 계획 외 지급, 지급 이월입니다. 같은 행에서 요인 막대의 크기를 비교해 무엇부터 확인할지 정합니다.

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

해설은 서비스가 계산한 숫자를 읽어 규칙으로 문장을 만든 초안입니다. 모델이 연결되지 않아도 같은 근거로 규칙 기반 해설이 나오고, 사람은 근거 표로 숫자를 확인합니다.

"작성 방식: 규칙"이 표시되고, 문장은 점검 필요·확인 필요로 끝나 판단을 단정하지 않습니다. 이미 사유가 적힌 행은 해설에서 건너뜁니다.

문장의 숫자가 표의 숫자와 같은지 대조하는 자리입니다. 근거 표가 없는 문장은 해설로 쓰지 않습니다.

[보고서 PPTX] 를 누르면 "보고서를 내려받았습니다" 안내가 뜨고 파일이 내려옵니다. 외부 라이브러리나 서버 없이 브라우저가 파일을 직접 짓습니다.

AI 에이전트 — 하루 한 번 도는 점검

에이전트는 네 가지 규칙을 서비스에서 점검해 걸린 항목을 대기함에 올립니다. 하루 한 번 제한도 서버의 실행 기록이 판정하므로 화면을 여러 번 열어도 같은 날 두 번 돌지 않습니다.

"실행했습니다. 규칙 4개 중 2건이 걸렸습니다"처럼 결과가 나오고, 걸린 항목은 보는 사람(경영·재무·자금·회계)별로 대기함에 올라갑니다. 같은 날 다시 누르면 "오늘은 이미 실행했습니다"가 나옵니다.

첫 실행은 DONE, 같은 날 두 번째는 LIMIT 로 기록됩니다. 누가 언제 점검을 돌렸는지를 사람이 아니라 서버가 남깁니다.

레이아웃 저장과 복원

자주 쓰는 배치는 이름을 붙여 저장합니다. 기본 보기와 열면 바로 조회 옵션을 켜 두면 다음에 화면을 열 때 조회된 채로 시작합니다.

내용 칸에 행·열·측정값 요약이 보이고, "다음에 열 때 이 보기로 시작"과 "열면 바로 조회"를 체크할 수 있습니다.

기본으로 되돌리기는 [보기 저장] 메뉴의 "기본 배치로 되돌리기"에 있습니다.

조건을 다시 넣거나 [조회]를 누르지 않아도 지급 은행·구분 행, 분기 열, 계획 차이 모드가 그대로 나타납니다.

좁은 화면과 한계

열 조합이 36개를 넘으면 안내하고, 폭이 좁으면 차트를 표 아래로 내려 휴대폰에서도 같은 리포트를 봅니다.

"열 조합이 36개를 넘어 추가하지 않았습니다" 안내가 표 위에 나옵니다. 필터로 범위를 좁히거나 열 축을 줄이면 됩니다.

가로 스크롤 없이 같은 조건과 축 구성을 쓸 수 있습니다. 보관함 칩을 눌러 행 축에 넣는 방식이 터치에 맞습니다.

차트를 숨기지 않고 표 아래로 내려 같은 정보를 모두 봅니다. 표는 가로로 밀어 볼 수 있습니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 화면들이 어떤 규칙으로 움직이는지를 자리별로 적었습니다. 도입 검토에서 "그래서 이건 어떻게 되느냐"로 자주 되돌아오는 대목들입니다.

피벗이 만들어지는 여섯 단계

1. 큐브 받기 — 조회할 때 한 번 실적 큐브(와 계획 큐브)를 읽습니다.
2. 행 묶기 — 행 축 차원을 순서대로 적용해 트리를 만듭니다.
3. 열 만들기 — 열 축 값 조합을 뽑아 열을 세웁니다(조합이 36개를 넘으면 추가하지 않고 안내합니다).
4. 칸 채우기 — 행 묶음 × 열 조합마다 측정값을 더합니다.
5. 계산항목 — 수수료 포함 지급액, 평균 수수료율, 긴급 지급 비중 같은 항목은 분자와 분모를 다시 합쳐 계산합니다.
6. 차이 열 — 계획 차이 스위치가 켜져 있으면 실적·계획·차이·차이율을 붙입니다.

축을 바꾸면 2단계부터 다시 돌고 1단계는 다시 하지 않습니다. 외화 지급액은 통화별로 환율을 곱한 원화로만 합산하며 서로 다른 통화를 그대로 더하지 않습니다.

판정 규칙과 조치

이 화면은 판정을 단정하지 않고 점검 대상을 좁혀 줍니다. 기준값은 화면에서 바꿀 수 있습니다.

산출과 대사 순서

차이 요인분해 정의

검산식은 계획 + 계획 초과 + 계획 미달 + 환율 + 시점 이동 + 계획 외 − 이월 = 실적이며 요인 금액은 부호를 포함해 더합니다. 검산 줄은 0 이어야 하고, 0 이 아니면 원천 라인과 요인 정의를 확인해야 합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭이 좁아지면 요약 지표는 두 줄로 쌓이고 조회 조건과 차원 보관함이 세로로 놓이며, 차트는 숨기지 않고 표 아래로 내려갑니다. 칩을 끌어다 놓는 대신 눌러서 행 축에 넣는 방식이 터치에 맞습니다. 표는 가로로 밀어 볼 수 있고 가로 스크롤이 페이지 전체로 번지지 않습니다.

파일 구성

paymix/
  index.html            앱 시작 (sap_horizon)
  readme.html           앱 설명서
  Component.js · manifest.json
  controller/  Main.controller.js · BaseController.js
  view/        Main.view.xml · 대화상자 조각
  model/       cube.js(피벗) · chart.js(SVG 차트) · layout.js · pptx.js · formatter.js
  css/ · i18n/
  odata/       서비스 정의(metadata) · 서비스 로직 · 계산 모듈 · 샘플 데이터
  media/       소개 영상 · 포스터 · 재생 지점 목록

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

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

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

T-code 별 연계 지점

운영 전환 때 "기존 리포트를 없애야 하나"에 대한 답은 아니오입니다. 표준 실행·법정·감사·세무 신고 대응은 표준 T-code 와 회사 체계에 남기고, 이 화면은 조회·검증 관점을 더해 확장합니다. 화면 이름과 필드는 시스템 버전과 설정에 따라 다를 수 있어 운영 환경에서 확인이 필요합니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 앱은 그것들과 경쟁하지 않고, 같은 종류의 큐브·분석 쿼리 구조(CDS 큐브와 분석 쿼리, 권한 DCL)를 따라 설계해 두었습니다. 운영에서 CDS 큐브와 분석 쿼리를 만들어 두면 표준 분석 도구가 같은 쿼리를 그대로 열 수 있고, 이 앱은 그 서비스를 화면에 얹는 역할만 합니다. 어떤 표준 Fiori 앱이 어떤 쿼리를 쓰는지는 시스템 릴리스에 따라 달라 확인 필요 항목으로 남겼습니다.

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

분석 지표 정의표

CDS 구성 — 뷰 레이어부터 권한·서비스까지

아래 객체 이름과 필드는 운영 환경에 맞춰 다듬어야 하는 스케치이며, 표준 필드 이름 중 확인하지 못한 것은 "확인 필요"로 표시했습니다. 표준 실행은 SAP 표준 T-code 가 담당하고 이 CDS 는 조회·검증 관점을 더하는 층입니다.

뷰 레이어 구성

① 지급 수단·채널 매핑 테이블

지급 방법 코드와 하우스 뱅크가 어느 수단 묶음·채널·수수료율에 속하는지 정하는 테이블입니다. 이 표가 바뀌면 수단별·채널별 숫자가 바뀌므로 운영에서 가장 먼저 합의할 자리입니다. 필드와 키는 환경에 따라 달라 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZPAY_MAP — 지급 방법·하우스 뱅크 → 수단·채널 묶음 매핑 (투명 테이블)
"  코드에 박지 않는 이유 : 지급 방법과 은행은 늘 늘어나고,
"  늘어날 때마다 개발자를 부르면 리포트가 금방 낡는다.
"  수수료율도 여기 둔다 — 실제 청구 체계가 바뀌면 이 표만 고친다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '지급 수단·채널 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " 유지보수 뷰를 함께 만들어 둔다
define table zpay_map {
  key mandt      : mandt not null;
  key map_type   : abap.char(1) not null;   " M=지급 방법  B=하우스 뱅크  (확인 필요)
  key src_value  : abap.char(10) not null;  " 지급 방법 코드 또는 하우스 뱅크 ID
  mode_grp       : abap.char(4);            " 수단 묶음 : 이체/외화송금/어음/카드
  chan_grp       : abap.char(4);            " 채널 묶음 : 은행 포털/EDI/수기
  @Semantics.quantity.unitOfMeasure : 'PCT'
  fee_rate       : abap.dec(7,4);           " 수수료율(%) — 샘플은 가정값
  valid_from     : abap.dats;
}

② 하우스 뱅크 차원 뷰

은행 하나당 한 행입니다. 은행 이름과 국내외 구분이 여기서 결정되며, 큐브와 값 도움말이 이 뷰 하나를 보게 합니다. 하우스 뱅크 마스터(T012) 기반이며 필드명은 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PayBank — 하우스 뱅크 차원
"  은행 하나당 한 행. 은행명과 국내/해외 구분이 여기서 정해진다.
"  차원 뷰를 따로 두는 이유 : 큐브에서 join 을 한 번만 걸고,
"  값 도움말·텍스트가 이 뷰 하나를 보게 하기 위해서다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '하우스 뱅크 차원'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'HouseBank'
define view entity ZI_PayBank
  as select from t012 as Bank          " 하우스 뱅크 마스터 (필드는 확인 필요)
{
  key Bank.bukrs       as CompanyCode,
  key Bank.hbkid       as HouseBank,
      Bank.banks       as BankCountry,
      Bank.bankl       as BankKey,
      case when Bank.banks = 'KR' then 'D' else 'F' end as DomesticFlag
}

③ 지급 라인 뷰

지급 문서 라인을 원화로 환산해 한 줄씩 보여 주는 원천 뷰입니다. 환산 시점과 부호 규칙이 여기서 정해지므로, 표준 지급 화면과 숫자를 맞출 때 가장 먼저 확인할 자리입니다. 지급 런 테이블의 필드는 릴리스에 따라 다르므로 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PaymentLine — 지급 라인 (원화 환산)
"  라인 하나당 한 행. 외화 금액에 환율을 곱한 원화 금액을 여기서 만든다.
"  환산을 한곳에서 하는 이유 : 큐브와 원천 라인 화면이
"  같은 환산 결과를 읽어야 칸 금액과 라인 합계가 맞는다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '지급 문서 라인'
define view entity ZI_PaymentLine
  as select from bseg as Item
  inner join     bkpf as Head
    on  Head.bukrs = Item.bukrs
    and Head.belnr = Item.belnr
    and Head.gjahr = Item.gjahr
  association [0..1] to zpay_map as _ModeMap
    on  _ModeMap.map_type  = 'M'
    and _ModeMap.src_value = Item.zlsch          " 지급 방법 (확인 필요)
{
  key Item.bukrs                                   as CompanyCode,
  key Item.belnr                                   as DocNo,
  key Item.gjahr                                   as FiscalYear,
  key Item.buzei                                   as ItemNo,
      Head.budat                                   as PostingDate,
      substring( Head.budat, 1, 6 )                as PostingMonth,
      Item.hbkid                                   as HouseBank,
      Item.zlsch                                   as PayMethod,
      Item.waers                                   as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      Item.wrbtr                                   as ForeignAmount,
      @Semantics.amount.currencyCode : 'Currency'
      Item.dmbtr                                   as LocalAmount,
      _ModeMap.mode_grp                            as ModeGroup,
      _ModeMap.chan_grp                            as ChannelGroup,
      _ModeMap.fee_rate                            as FeeRate
}

④ 실적 큐브

차원 조합마다 한 행을 만들고 지급 라인을 DB 에서 더해 올립니다. 화면이 들고 묶던 일을 여기로 내리는 것이 운영 전환의 핵심입니다. 기말 미지급 잔액은 기간을 합쳐도 마지막 기간만 쓰는 측정값이라 집계 방식을 따로 정합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PaymentCube — 지급 실적 큐브
"  아홉 개 축(기간·법인·은행·구분·통화·수단·결제 구간·채널·긴급)마다 한 행.
"  기말 미지급 잔액은 기간을 합치면 마지막 기간 값만 쓴다(LAST).
"  통화 환산은 여기서 끝내 두고, 화면은 합산만 한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK      " ← DCL 을 반드시 붙인다
@EndUserText.label                   : '지급 실적 다차원 큐브'
@Analytics.dataCategory              : #CUBE
define view entity ZI_PaymentCube
  as select from ZI_PaymentLine as Ln
  association [0..1] to ZI_PayBank as _Bank
    on  _Bank.CompanyCode = Ln.CompanyCode
    and _Bank.HouseBank   = Ln.HouseBank
{
  key Ln.PostingMonth,
  key Ln.CompanyCode,
  key Ln.HouseBank,
  key Ln.Currency,
  key Ln.ModeGroup,
  key Ln.ChannelGroup,
      @Semantics.amount.currencyCode : 'KRW'
      @DefaultAggregation : #SUM
      sum( Ln.LocalAmount )                          as PaidKrw,
      @Semantics.amount.currencyCode : 'KRW'
      @DefaultAggregation : #SUM
      sum( cast( Ln.LocalAmount * Ln.FeeRate / 100 as abap.curr(15,0) ) )
                                                     as FeeKrw,
      count( * )                                     as LineCount,
      _Bank
}
group by Ln.PostingMonth, Ln.CompanyCode, Ln.HouseBank,
         Ln.Currency, Ln.ModeGroup, Ln.ChannelGroup

⑤ 계획 큐브

실적과 같은 키 모양으로 맞추는 것이 전부입니다. 키가 어긋나면 계획이 실적 옆에 붙지 않고 따로 뜹니다. 계획 원천 테이블은 환경마다 달라 확인 필요이며, 아래는 자금 계획 데이터를 읽는 개념 스케치입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PaymentPlanCube — 지급 계획(P0) 큐브
"  실적 큐브와 같은 키 모양으로 맞춘다. 키가 어긋나면 계획이 따로 뜬다.
"
"  ※ 계획 원천(자금 계획 테이블 또는 지급 계획 데이터)은
"     릴리스와 설정에 따라 다르다 — 확인 필요.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '지급 계획 다차원 큐브'
@Analytics.dataCategory              : #CUBE
define view entity ZI_PaymentPlanCube
  as select from zpay_plan as Pln       " 지급 계획 원천 (확인 필요)
{
  key Pln.plan_month     as PostingMonth,
  key Pln.bukrs          as CompanyCode,
  key Pln.hbkid          as HouseBank,
  key Pln.waers          as Currency,
  key Pln.mode_grp       as ModeGroup,
  key Pln.chan_grp       as ChannelGroup,
      @Semantics.amount.currencyCode : 'KRW'
      @DefaultAggregation : #SUM
      sum( Pln.plan_krw )  as PlanPaidKrw
}
where Pln.version = 'P0'
group by Pln.plan_month, Pln.bukrs, Pln.hbkid,
         Pln.waers, Pln.mode_grp, Pln.chan_grp

⑥ 분석 쿼리

이 뷰를 만들어 두면 표준 분석 도구가 같은 쿼리를 그대로 엽니다. 행·열 축의 기본 배치와 필터가 여기서 정해지며, 앱 없이도 축을 바꿔 볼 수 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_PaymentMixQuery — 분석 쿼리
"  이 뷰를 만들어 두면 표준 분석 도구가 같은 쿼리를 그대로 띄운다.
"  앱이 없어도 축은 바꿀 수 있다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED   " 큐브에서 이미 검사했다
@EndUserText.label                   : '지급 수단·채널 이행 분석'
@Analytics.query                     : true
@Metadata.ignorePropagatedAnnotations: true
define view entity ZC_PaymentMixQuery
  as select from ZI_PaymentCube
{
      @AnalyticsDetails.query.axis : #ROWS
      @AnalyticsDetails.query.displayHierarchy : #OFF
  key HouseBank,
      @AnalyticsDetails.query.axis : #ROWS
  key ModeGroup,
      @AnalyticsDetails.query.axis : #COLUMNS
  key PostingMonth,
      @Consumption.filter.selectionType : #RANGE
  key CompanyCode,
      @AnalyticsDetails.query.axis : #COLUMNS
      PaidKrw,
      @AnalyticsDetails.query.axis : #COLUMNS
      FeeKrw
}

⑦ 권한 (DCL)

집계 화면에서 권한을 드릴스루에만 걸면, 권한 없는 사람이 전사 합계와 자기 몫의 차이를 빼서 남의 법인·은행 숫자를 알아냅니다. 그래서 큐브를 읽는 자리에 겁니다. 권한 객체 이름은 환경 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZPAY_CUBE_AUTH — 권한 (DCL)
"  권한을 드릴스루에만 걸면 합계의 뺄셈으로 남의 숫자가 샌다.
"  그래서 큐브를 읽는 자리에 건다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '지급 큐브 권한'
@MappingRole       : true
define role ZPAY_CUBE_AUTH {
  grant select on ZI_PaymentCube
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' );
  grant select on ZI_PaymentPlanCube
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의

분석 쿼리를 OData 로 여는 서비스 정의입니다. 바인딩을 만들어 게시하면 화면이 이 서비스 하나만 부릅니다. 샘플의 서비스 주소를 운영 주소로 바꾸는 자리는 앱 설정의 서비스 주소 한 곳입니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_PaymentMix — 서비스 정의
"  화면이 부르는 단일 진입점. 바인딩(OData V2 - UI)을 만들어 게시한다.
"  큐브·계획·차원은 여기서 엔티티로 열고, 쓰기가 필요한 변동 사유·
"  저장한 보기·에이전트 기록은 별도 RAP 객체로 둔다(개념 — 확인 필요).
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '지급 수단·채널 이행 서비스'
define service ZUI_PaymentMix {
  expose ZC_PaymentMixQuery  as PaymentMix;
  expose ZI_PaymentCube      as CubeSet;
  expose ZI_PaymentPlanCube  as PlanSet;
  expose ZI_PayBank          as BankSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

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

검증용 샘플 데이터(지급 라인 3,391줄)로 대사식을 전수로 돌린 결과입니다. 도입 포인트의 사례와 같은 숫자입니다.

총 검사 1,300건(45 + 1,230 + 25), 차이 0건입니다. 통화별 외화 × 환율 대사에서 라인별 원 단위 반올림 차이가 최대 150원 있었고(총 지급액 4조 원대) 허용 오차로 보았습니다. 의도적 예외는 대사 차이와 따로 셉니다.

운영 데이터로 갈 때 — 지급 라인이 수천만 건이면

운영 지급 라인은 수천만 건이 될 수 있습니다. 샘플은 라인을 모두 읽어 브라우저에서 묶지만 운영에서는 그렇게 하지 않습니다. 집계는 큐브(DB)에서 끝내고 화면은 큐브 행만 읽습니다(아홉 개 축 조합이 수만 행 이하가 되도록 차원 범위를 정합니다). 기간은 조회 조건에서 필수로 받고, 법인·은행 조건이 없으면 안내합니다. 원천 라인은 칸을 눌렀을 때만 페이지 단위로 읽습니다. 인덱스는 전기일·법인·하우스 뱅크 순으로 두는 것이 출발점이며, 응답 시간 기준(예: 첫 조회 수 초 이내)은 도입 시 정해야 하고 현재는 확인 필요입니다.

자주 묻는 질문

도입을 검토할 때 자주 받는 질문 27개를 네 묶음으로 정리했습니다.

숫자와 산식

지급액과 수수료, 미지급 잔액, 차이는 어떻게 계산하나요? 어디서 계산하나요?

화면과 조작

조회 조건과 축 전환, 드릴스루, 저장한 보기에 대한 질문입니다.

분석 기능

해설, 변동 사유, 에이전트에 대한 질문입니다.

도입과 운영

도입 효과, 표준과의 관계, 권한, 성능, 책임에 대한 질문입니다.