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

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

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

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

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

한 줄 요약 — 은행·수단·채널별 지급 현황을 한 번 읽은 큐브 위에서 축만 바꿔 보고, 계획과의 차이를 여섯 요인으로 나눠 검산하며, 칸마다 원천 지급 라인으로 내려가 "이 숫자 맞아?"에 그 자리에서 답하는 자금 이행 분석 화면입니다.

핵심 포인트 일곱 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 합계가 변하지 않는 피벗	은행·지급 구분·통화·지급 수단·결제 조건 구간·채널·긴급 여부 등 아홉 개 축과 회계기간·분기를 끌어다 행과 열에 놓습니다. 모든 묶음이 같은 큐브 한 벌에서 나오므로 합계가 갈라질 자리가 없습니다.	은행별·수단별·채널별 지급 현황을 따로 뽑아 엑셀로 맞추고, 합계가 다르면 원인을 찾는 데 시간을 씁니다.
② 칸에서 원천 지급 문서까지	숫자 칸을 누르면 그 칸을 이룬 지급 라인이 열리고, 라인 합계가 칸 금액과 같은지 "표의 값과 일치"로 그 자리에서 확인됩니다.	표준 화면을 따로 열고 조회 조건을 손으로 다시 넣어 숫자를 맞춰 봅니다.
③ 계획 대비 차이를 여섯 요인으로	계획 초과·미달 지급, 환율, 지급 시점 이동, 계획 외 지급, 지급 이월로 총차이를 나누고, 계획 + 요인 합 − 실적이 0 인지 매번 검산합니다.	차이가 났다는 사실만 보고, 이유는 담당자에게 메일로 되묻습니다.
④ 수수료와 긴급 지급을 함께 보는 지표	수단별 수수료율, 수수료 포함 지급액, 긴급 지급 비중, 기말 미지급 잔액을 같은 표에서 비교합니다.	은행 포털·카드사 명세·지급 런 결과를 따로 모아 수수료 부담을 추정합니다.
⑤ 변동 사유가 행에 남는다	차이가 난 행에 구분과 사유를 적어 저장하면 다시 열어도 같은 행에 따라옵니다. CSV 와 해설 근거에도 함께 실립니다.	같은 질문을 되풀이하고 지난 답은 메일함에서 찾습니다.
⑥ 규칙 기반 해설과 하루 한 번 점검	금액과 비율은 서비스가 계산하고 해설은 그 숫자를 읽기만 합니다. 에이전트는 네 가지 규칙으로 하루 한 번 점검해 대기함에 올립니다.	점검은 사람이 화면을 열 때만 일어나고, 열지 않은 날은 지나갑니다.
⑦ 표준 지급 화면과 이어지는 구조	표준 지급 문서와 은행 계정 데이터를 그대로 이어받아 확장하므로, 이 화면과 표준 화면을 오가며 같은 숫자를 확인합니다.	표준 화면과 별도 리포트의 숫자가 달라 대사에 시간이 듭니다.

사례로 보는 효과 — 계획 대비 +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원, 허용 오차). 점검할 대상은 "계획 외 지급" 항목부터라는 것을 합계가 아니라 요인에서 읽을 수 있습니다.

요인(억원)	금액	읽는 법
계획 초과 지급	+940.18	계획된 라인에서 실적이 더 큰 부분
계획 미달 지급	−875.27	계획된 라인에서 실적이 더 작은 부분
환율	−18.29	월 환율과 계획 환율의 차이
지급 시점 이동	+10.89	계획월과 다른 달에 지급된 부분
계획 외 지급	+1,239.10	계획 없이 나간 지급 — 점검 필요
지급 이월	−518.15	계획만 있고 지급되지 않은 부분

도입하면 달라지는 것

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

이런 회사에 맞습니다

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

실행 화면

사용 방법

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

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면 컨트롤	OpenUI5 1.120 표준 컨트롤(TreeTable·Dialog·IconTabBar)과 직접 그린 SVG 차트	외부 라이브러리를 들이지 않아 보안 심사 부담이 없고, 차트는 표와 같은 값을 읽어 어긋날 자리가 없습니다.
집계·판정 로직	서비스 쪽 로직 파일(큐브 집계, 요인분해, 해설, 에이전트 판정)과 계산 모듈	금액과 판정은 서비스가 계산하고 화면과 해설은 읽기만 합니다. 같은 계산 모듈을 검증용 환경도 써서 결과가 같습니다.
OData 서비스 구성	OData V2 서비스 하나, 엔티티 14종(실적·계획 큐브, 차원·측정값·계산항목 정의, 기간 요약, 원천 라인, 대사 결과, 변동 사유, 저장한 보기, 에이전트 규칙·대기함·실행 이력)과 펑션 3종(요인분해·해설·에이전트 실행)	큐브는 조회할 때 한 번만 읽고, 이후 축 전환·값 필터·정렬은 브라우저가 처리합니다. 사유·보기·에이전트 기록만 서비스에 씁니다.
테마	sap_horizon	표준 Fiori 화면과 같은 모양과 색을 써서 현업이 낯설어하지 않습니다.

앱 정보	내용
기능명	지급 수단·채널 이행 다차원 분석
솔루션 / 영역	자금 솔루션 / 지급 이행 · 현금 흐름 관리
관련 기준서	IAS 7 현금흐름표(K-IFRS 제1007호), IFRS 7 금융상품: 공시(K-IFRS 제1107호) — 문단 번호는 확인 필요
맞닿는 표준 T-code	F110, FBL1N, FB03, FS10N, FF7A
앱 유형	업무 분석 앱(분석 지표 정의표 제공)
데이터	OData V2, 검증용 샘플 지급 라인 3,391줄 — 법인·은행·거래처 이름은 모두 가상

SAP 표준 기능을 그대로 이어받은 부분 — 지급 문서와 은행 계정 데이터, 지급 방법 같은 표준 구조를 그대로 이어받아 확장합니다. 지급 실행과 전표 처리는 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더합니다.

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

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

**조회 전 — 조건과 빈 보드** — 조회를 누르기 전에는 조건 줄과 빈 표·차트 영역만 보입니다.

기간(부터)·기간(까지)는 필수이고 기본은 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 억원은 점검 필요 수준으로 표시됩니다. 은행 집중도 지수도 함께 적혀 있습니다.

**재무 — 구분별 수수료 부담** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**자금 — 은행·통화별 미지급 잔액** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**회계 — 수단별 수수료 점검** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

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

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

**행·열 축 조합과 표 행 수** — 행 축 두 단계, 열 축 두 단계를 놓은 모습입니다.

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

**값 필터 — 여러 값 선택** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**차트와 너비 손잡이** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

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

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

**칸 → 원천 라인** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**원천 라인 목록** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

기간별 요약과 계산항목

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

**기간별 요약 — 월별** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**계산항목 — 수수료 포함 지급액** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**측정값을 열로 세우기** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

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

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

**워터폴과 요인분해** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**변동 사유 기재** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**다른 행의 요인** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

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

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

**해설 — 규칙 기반 초안** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**보고서 내려받기** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

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

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

**규칙과 대기함** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

레이아웃 저장과 복원

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

**현재 보기 저장** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**저장한 보기 관리** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**기본 보기로 조회된 채 열림** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

좁은 화면과 한계

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

**열 조합 상한 안내** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**390px 폭 — 상단** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

**390px 폭 — 표와 차트** — 상세 설명은 데모를 신청하신 고객께 보여 드려요.

화면 뒤에서 일어나는 일

데모를 신청하신 고객께 공개되는 내용입니다

CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.

데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.

데모 신청하기 Google 계정으로 로그인

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

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

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

판정 규칙과 조치

데모를 신청하신 고객께 공개되는 내용입니다

데모 신청하기 Google 계정으로 로그인

산출과 대사 순서

단계	처리	내용
1	원천 라인 수집	지급 문서 라인 3,391줄 — 지급일·은행·수단·채널·통화·외화 금액·환율
2	큐브 집계	라인을 9개 축으로 묶어 원화 지급액·수수료·수수료 부과 기준액·기말 미지급 잔액·라인 수 저장
3	큐브 ↔ 원천 대사	기간×측정값 45건을 원천 합계와 비교 — 차이 0 이어야 함
4	브라우저 피벗	큐브를 한 번 읽어 두고 축을 바꿀 때마다 브라우저에서 다시 묶음 — 재조회 없음
5	계산항목	수수료 포함 지급액 = 지급액 + 수수료 · 평균 수수료율 = 수수료 × 100 ÷ 부과 기준액
6	계획 대비 차이	실적 − 계획. 선택 범위의 요인분해로 계획 + 요인 합 − 실적 = 0 검산
7	원천 확인	칸 값 = 원천 라인 합계 확인(드릴스루)

차이 요인분해 정의

요인	의미
계획 초과 지급	계획된 라인에서 실적이 계획보다 큰 부분
계획 미달 지급	계획된 라인에서 실적이 계획보다 작은 부분
환율	같은 외화 금액에 월 환율이 계획 환율과 달라 생긴 원화 차이
지급 시점 이동	계획월과 다른 달에 지급된 부분(앞당김·지연)
계획 외 지급	계획 없이 지급된 라인
지급 이월	계획만 있고 지급되지 않은 라인

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

조회조건

조건	필수 여부	기본값	서비스 처리
지급 법인	선택	전체	법인 조건(여러 개는 or)
기간(부터)	필수	2026년 01월	기간 하한
기간(까지)	필수	2026년 09월	기간 상한
비교 기준	선택	지급 계획(P0)과 비교	같은 조건으로 계획 큐브를 추가 조회
금액 단위	선택	억원	화면 표시만 바뀜(서비스 호출 없음)
값 필터	선택	없음	읽어 둔 큐브 안에서 걸러짐(서비스 호출 없음)

결과 컬럼

데모를 신청하신 고객께 공개되는 내용입니다

데모 신청하기 Google 계정으로 로그인

좁은 화면에서 달라지는 것

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

파일 구성

데모를 신청하신 고객께 공개되는 내용입니다

데모 신청하기 Google 계정으로 로그인

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

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

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

하고 싶은 일	SAP 표준	표준에서 걸리는 자리	이 앱이 하는 일
지급 실행(지급 런)	F110	실행 결과가 지급 런 단위라 은행·수단·채널별로 다시 묶어 보기 어렵습니다	같은 지급 라인을 큐브로 묶어 축을 바꿔 봅니다
미지급 라인 확인	FBL1N	거래처 단위 조회라 은행·채널 관점이 없습니다	미지급 잔액을 은행·통화·구간별로 봅니다
전표 상세	FB03	전표를 하나씩 엽니다	칸에서 원천 라인을 합계와 함께 엽니다
은행 계정 잔액	FS10N	계정 잔액 중심이라 지급 수단·채널 구분이 없습니다	은행별 지급액과 수수료를 같은 표에서 봅니다
현금 포지션	FF7A	계획과 실적을 따로 봅니다	계획(P0) 대비 지급 차이를 한 표에 둡니다
차이의 원인 분해	없음	표준에 없고 보통 엑셀로 만듭니다	여섯 요인으로 가르고 합계를 검산합니다
차이 사유 기록	전표 적요	전표 단위라 집계 행에는 붙일 곳이 없습니다	조회 범위와 행 경로를 키로 남깁니다

T-code 별 연계 지점

T-code	이름	이어받는 데이터	오가는 방법과 대사 지점	표준에 남길 일
F110	자동 지급 프로그램	지급 런·지급 제안의 지급 방법과 은행 정보	이 앱의 지급 수단·은행 축과 지급 런 결과가 같은 합계인지 대사 / 이 앱 결과 → F110 에서 해당 런 확인	지급 실행과 은행 파일 생성은 표준에 둡니다
FBL1N	공급업체 라인 아이템	미지급 문서와 만기 정보	기말 미지급 잔액 대사 / 이 앱 칸 → FBL1N 에서 거래처별 라인 확인	거래처 원장 관리는 표준에 둡니다
FB03	전표 조회	원천 전표(지급 문서) 상세	드릴스루 라인의 문서 번호 → FB03 에서 전표 상세 확인	전표 수정·역분개는 표준에서 합니다
FS10N	G/L 계정 잔액	은행 계정 잔액	은행별 지급액과 계정 변동을 맞춰 봄 / 표준 잔액 → 이 앱의 은행 축으로 다시 보기	계정 잔액 마감 확인은 표준에 둡니다
FF7A	현금 포지션	자금 예측·계획 데이터	계획(P0) 대비 지급 비교의 계획 관점 확인	유동성 포지션 보고는 표준에 둡니다

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

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

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

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

자리	무엇을 손대나	비고
지급 수단·채널 매핑	지급 방법 코드와 하우스 뱅크를 수단·채널 묶음으로 옮기는 매핑 테이블	새 지급 방법이 생기면 어느 묶음인지만 적어 줍니다
수수료 체계	수단별 수수료율(샘플은 가정값)	실제 청구 체계로 교체 — 확인 필요
확장 필드	긴급 여부·결제 조건 구간·채널 구분 같은 필드	표준 필드나 고객 확장 필드로 채워야 하는지 확인 필요
환율 유형과 환산 시점	원화 환산에 쓰는 환율 유형과 기준일	회계 정책에 맞춰 결정
권한	법인·은행 범위 권한 객체	집계 단계(큐브)에 거는 것이 안전
BAdI·커스텀 필드	지급 라인 추가 속성이 필요할 때	고객사가 손대는 지점

분석 지표 정의표

지표	산식·판정 기준	대응 기능	원천 데이터	비고
지급액(원화)	당월 외화 지급액 × 지급일 월 적용 환율, 기간을 합치면 합산	큐브·피벗·요약 지표	지급 문서 라인(금액·통화·환율)	샘플 가정 환율
지급 수수료(원화)	지급액 × 수단별 수수료율	수수료 열·평균 수수료율	수단별 수수료율(가정값)	실제 수수료 체계는 확인 필요
수수료 부과 기준액	계획된 지급에 대해서만 잡는 수수료 부과 기준	평균 수수료율의 분모	지급 계획 라인	-
기말 미지급 잔액	월말 외화 미지급 잔액 × 월 적용 환율, 기간을 합쳐도 마지막 기간만 사용	자금 보기·요약 지표	미지급 문서 잔액	집계 방식 LAST
평균 지급 수수료율(%)	수수료 × 100 ÷ 수수료 부과 기준액	계산항목	-	-
긴급 지급 비중(%)	긴급 지급액 × 100 ÷ 지급액	요약 지표·에이전트 규칙 2	긴급 여부 필드	-
계획 대비 차이	실적 − 계획, 금액·비율 기준을 모두 넘으면 점검 필요	차이 모드·에이전트 규칙 4	계획(P0)과 실적 큐브	기준값은 화면에서 조정
요인분해	계획 + 요인 합 − 실적 = 0	워터폴·검산 줄	원천 라인(라인 유형별)	부호 포함

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

데모를 신청하신 고객께 공개되는 내용입니다

데모 신청하기 Google 계정으로 로그인

자주 묻는 질문

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

숫자와 산식

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

지급액은 어떻게 계산됩니까?

지급 라인의 외화 금액에 지급일 월의 환율을 곱한 원화 금액을 더합니다. 외화는 통화별로 원화로 바꾼 뒤에만 합산하고, 서로 다른 통화의 금액을 그대로 더하지 않습니다. 계산은 서비스가 하고 화면과 해설은 그 값을 읽기만 합니다. 같은 계산 모듈을 검증용 환경도 쓰기 때문에 두 환경의 결과가 같습니다.

기말 미지급 잔액은 기간을 합치면 왜 늘지 않습니까?

월말 시점의 잔액이라 더하면 의미가 없기 때문입니다. 이 측정값은 기간을 합쳐도 마지막 기간의 값만 씁니다(집계 방식 LAST). 그래서 분기나 연으로 묶어도 잔액이 부풀지 않습니다.

계획 대비 차이 +778.47 억원은 문제가 있다는 뜻입니까?

아닙니다. 이 화면은 판단을 단정하지 않고 점검 대상을 좁혀 줍니다. 금액 기준과 비율 기준을 둘 다 넘는 칸이 붉게 표시되지만 그것은 점검 필요 신호입니다. 원인은 요인분해에서 어느 요인이 큰지 보고, 근거 지급 라인을 확인해야 합니다.

요인분해의 검산 줄은 무엇입니까?

계획 + 계획 초과 + 계획 미달 + 환율 + 시점 이동 + 계획 외 − 이월이 실적과 같은지 매번 계산해 보여 줍니다. 요인 금액은 부호를 포함해 더하고 결과는 0 이어야 합니다. 0 이 아니면 원천 라인과 요인 정의를 확인해야 합니다. 샘플 자료에서는 범위 25개 모두 0 이었습니다.

샘플의 환율과 수수료율은 실제 값입니까?

아닙니다. 환율과 수수료율은 샘플 가정값입니다. 운영에서는 회사의 환율 유형과 실제 수수료 체계로 바꿔야 하며, 그 기준은 확인이 필요합니다. 법인과 은행, 문서 이름도 모두 가상입니다.

통화별 반올림 차이 150원은 무엇입니까?

외화 라인마다 원 단위로 반올림하는 과정에서 생기는 차이로, 총 지급액이 4조 원대인 자료에서 최대 150원이었습니다. 대사 차이 0건의 판정에서는 허용 오차로 보고 별도로 적었습니다.

화면과 조작

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

축을 바꿀 때 서비스를 다시 부릅니까?

아닙니다. 조회할 때 큐브를 한 번 읽어 두고 축 전환·값 필터·표 행 수·정렬은 읽어 둔 큐브에서 브라우저가 처리합니다. 그래서 총합이 바뀌지 않고 응답도 빠릅니다. 기간이나 법인 조건을 바꿀 때만 다시 조회합니다.

열 조합이 36개를 넘으면 어떻게 됩니까?

추가하지 않고 "열 조합이 36개를 넘어 추가하지 않았습니다" 안내가 나옵니다. 표가 가로로 너무 길어지는 것을 막기 위한 상한입니다. 값 필터로 범위를 좁히거나 열 축을 줄이면 됩니다.

칸을 누르면 무엇이 열립니까?

그 칸을 이룬 원천 지급 라인 목록이 열립니다. 라인 합계가 칸 값과 같으면 "표의 값과 일치"가 표시되고, 다르면 차이 금액이 표시되어 확인이 필요합니다. 계획만 있고 지급되지 않은 이월 라인은 원천 목록에서 제외됩니다.

보기를 저장하면 무엇이 저장됩니까?

행·열 축, 측정값, 계획 차이 모드 같은 배치가 이름과 함께 서비스에 저장됩니다. 기본 보기와 열면 바로 조회 옵션을 켜 두면 다음에 화면을 열 때 조회된 상태로 시작합니다. 기본 배치로 되돌리기는 [보기 저장] 메뉴에 있습니다.

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

폭이 좁아지면 요약 지표가 쌓이고 차트가 표 아래로 내려가며, 칩을 눌러 행 축에 넣는 방식으로 같은 리포트를 봅니다. 다만 칸이 많은 표는 가로로 밀어 보아야 하므로, 넓은 표 비교는 데스크톱이 편합니다.

CSV 로 무엇을 내려받을 수 있습니까?

표 오른쪽 위 [CSV] 는 지금 보이는 표를, 원천 라인 창의 [CSV] 는 그 칸의 지급 라인을 내려받습니다. 변동 사유가 있는 행은 사유도 함께 담깁니다.

분석 기능

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

해설은 AI 가 숫자를 만듭니까?

아닙니다. 금액과 비율은 서비스가 계산해 근거로 넘기고, 해설은 그 숫자를 읽어 문장으로 만든 초안입니다. 이 앱의 샘플은 규칙 기반 해설을 쓰며 모델이 연결되지 않아도 같은 근거로 해설이 나옵니다. 사람은 근거 표로 숫자를 확인합니다.

변동 사유는 어떻게 남습니까?

차이가 난 행에서 구분(지급 시점·지급 금액·환율·계획 외 지급·일회성·기타)과 사유를 적어 저장하면, 조회 범위와 행 경로를 키로 서비스에 남습니다. 축을 바꿔도 같은 행이면 따라오고 다음 달에도 남습니다. CSV 와 해설 근거에도 함께 실립니다.

에이전트는 무엇을 점검합니까?

네 가지 규칙입니다 — 단일 은행 지급 비중, 긴급 지급 비중, 계획 이행률, 계획 대비 지급 차이. 걸린 항목은 보는 사람별로 대기함에 올라가고 활동 기록에 실행 이력이 남습니다. 임계값은 서비스에 저장된 규칙 값이며 운영에서 정합니다.

에이전트가 하루에 두 번 돌 수 있습니까?

돌지 않습니다. 같은 날 두 번째 실행은 상태 LIMIT 로 기록되고 "오늘은 이미 실행했습니다"가 표시됩니다. 하루 한 번 제한은 화면이 아니라 서버의 실행 기록이 판정하므로 화면을 여러 번 열어도 같습니다.

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

해설과 표·차트를 담은 파일을 브라우저가 직접 만듭니다. 외부 라이브러리나 서버 전송이 없고 파일은 내려받는 순간에만 생깁니다. 보고서의 숫자는 화면의 숫자와 같습니다.

요인분해가 안 나뉘는 자리도 있습니까?

있습니다. 계획이 없는 행은 "계획 외 지급"으로, 지급되지 않은 계획은 "이월"로 세웁니다. 억지로 다른 요인으로 나누지 않고 별도 요인으로 보여 주는 것이 원칙입니다.

도입과 운영

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

이 앱을 도입하면 어떤 효과가 있습니까?

은행·수단·채널별 지급 현황을 따로 뽑아 맞추던 일이 한 화면의 축 전환으로 바뀌고, 계획 대비 차이를 요인으로 설명할 수 있습니다. 효과 크기는 회사마다 달라 이 글은 시간 절감률 같은 수치를 약속하지 않습니다. 현재 SAP 환경에서 어떻게 적용되는지 함께 확인해 드립니다.

누가 쓰는 화면입니까?

자금팀(지급 계획과 이행 점검)과 회계팀(수수료·환율·미지급 잔액 점검)이 주 사용자입니다. 경영진은 "보는 사람" 탭으로 요약을 봅니다. 권한은 법인·은행 범위로 나눌 수 있습니다.

언제부터 적용할 수 있습니까?

샘플 데이터로 동작을 확인하는 단계의 화면이며, 운영 적용 시점과 범위는 확인된 사실이 아직 없습니다. 운영 연결 시에는 원천 테이블 매핑과 서비스 연결이 먼저 필요합니다.

표준 T-code 와는 어떤 관계입니까?

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 지급 런은 F110, 미지급 라인은 FBL1N, 전표는 FB03, 계정 잔액은 FS10N, 현금 포지션은 FF7A 와 오가며 같은 숫자를 맞춰 봅니다. 기존 리포트를 없앨 필요는 없습니다.

운영 데이터와 연결하는 절차와 시간은 어떻게 됩니까?

매핑 테이블 합의, CDS 뷰와 DCL 작성, 서비스 게시, 앱 설정의 서비스 주소 교체, 표준 화면과의 대사 순서입니다. 소요는 환경과 합의 속도에 달려 있어 확인 필요이며, 개발보다 정하는 일이 많습니다.

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

법인·은행 범위 권한을 큐브를 읽는 자리(DCL)에 겁니다. 드릴스루에만 걸면 합계의 뺄셈으로 남의 숫자가 샐 수 있어서입니다. 화면은 표준 컨트롤과 직접 그린 차트만 쓰고 해설은 규칙 기반이라 외부로 데이터가 나가지 않습니다.

지급 라인이 수천만 건이면 어떻게 됩니까?

샘플은 라인을 읽어 브라우저에서 묶지만 운영에서는 집계를 큐브(DB)에서 끝내고 큐브 행만 읽습니다. 기간 조건을 필수로 받고 원천 라인은 칸을 눌렀을 때만 페이지 단위로 읽습니다. 응답 시간 기준은 도입 때 정해야 합니다.

은행이나 지급 방법이 새로 생기거나 계정 체계가 바뀌면요?

매핑 테이블에 새 코드가 어느 묶음인지만 적으면 됩니다. 화면이나 뷰를 고칠 필요가 없고, 변경은 전송으로 옮깁니다. 묶음을 바꾸면 과거 숫자의 묶음도 바뀌므로 변경 시점의 합의가 필요합니다.

이 화면의 결과를 회계 판단에 그대로 써도 됩니까?

아닙니다. 이 화면은 분류·집계·대사를 돕는 조회·점검 도구입니다. 점검 필요·확인 필요 항목을 좁혀 줄 뿐 최종 판단은 회사와 감사인이 하고, 세무 신고는 회사와 세무 대리인이 합니다. 관련 기준서(IAS 7, IFRS 7)의 요구사항 해석도 마찬가지입니다.