수금·입금 자금 다차원 분석 — 입금 계획 대비 차이를 일곱 요인으로 가르는 자금 리포트

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

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

월말이 되면 자금 담당자는 같은 질문을 받습니다. “이번 달 들어온 돈이 계획과 얼마나 다른가, 그 차이는 어느 고객군·어느 은행·어느 통화에서 났는가, 연체이자와 공제·상계는 얼마나 섞여 있는가.” 표준 화면으로는 고객 항목 조회(FBL5N), 입금 전기(F-28), 은행 계좌 명세(FF_5), 현금 포지션(FF7A), 유동성 예측(FF7B)을 번갈아 열어 숫자를 엑셀로 옮겨 붙이는 일이 되기 쉽습니다. 계획과 실적을 읽는 화면이 따로 있고, 축을 바꿀 때마다 조건을 다시 넣어야 하기 때문입니다.

이 앱은 입금 원천 라인을 하나의 큐브로 묶어, 입금월·법인·입금 은행·고객군·입금 수단·통화·입금일 대비·처리 단계·공제 구분 같은 축을 끌어다 놓는 것만으로 바꿔 보게 합니다. 숫자 칸을 누르면 그 금액을 만든 원천 입금 라인이 열리고, 계획을 켜면 같은 표가 입금 계획 대비 차이 표가 됩니다. 현금흐름 보고의 기준(IAS 7, K-IFRS 제1007호)과 외화 환산 기준(IAS 21, K-IFRS 제1021호)이 요구하는 정보를 준비하는 쪽에서 보면, 입금을 계획·환율·공제와 함께 한 자리에서 점검할 수 있다는 점이 핵심입니다. 법정 신고와 감사 대응은 계속 SAP 표준 화면이 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

한 줄 요약 — 입금 원천 라인을 한 큐브로 묶어 축을 바꿔 보고, 칸에서 원천 문서까지 내려가고, 입금 계획 대비 차이를 일곱 요인으로 가르는 자금 분석 화면입니다.

핵심 포인트 여덟 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 합계가 같은 피벗	행·열 축을 끌어다 놓아 바꾸고, 어떻게 바꿔도 총합은 그대로입니다. 서버를 다시 부르지 않아 바로 그려집니다.	축마다 조건을 다시 넣고 엑셀로 옮겨 합계를 맞춥니다.
② 칸에서 원천 문서까지	숫자 칸을 누르면 그 금액을 이룬 입금 라인이 열리고, 칸 금액과 원천 합계가 같은지 화면이 확인해 줍니다.	리포트를 닫고 고객 항목 조회(FBL5N)를 열어 조건을 다시 넣습니다.
③ 입금 계획 대비 차이	비교 기준만 켜면 실적·계획·차이·차이율이 나란히 나오고, 금액과 비율 기준을 모두 넘는 칸만 색이 칠해집니다.	현금 포지션(FF7A)과 실적 화면을 따로 열어 눈으로 맞춰 봅니다.
④ 차이를 일곱 요인으로	청구 금액 변동·환율 효과·연체이자·가산 반영·공제·상계 효과·입금월 이동·계획 외 입금·계획 입금 미발생으로 가르고, 합이 총차이와 같은지 검산합니다.	엑셀로 요인을 직접 만들고, 산식은 담당자마다 다릅니다.
⑤ 변동 사유가 행에 남는다	차이가 난 행에 사유를 구분과 문장으로 남겨 두면 저장되어, 다시 열어도 같은 사유가 보입니다.	같은 질문을 매달 다시 하고, 지난달 답은 메일함에서 찾습니다.
⑥ 역할별 요약	경영·재무·자금·회계 네 역할마다 먼저 봐야 할 측정값과 축이 바뀝니다.	역할마다 다른 엑셀 양식을 따로 유지합니다.
⑦ 하루 한 번 도는 점검 에이전트	지연 입금 비중·가수금 보류 비중·계획 차이·기말 미회수 잔액 네 규칙을 점검해 걸린 항목을 대기함에 올리고 이력을 남깁니다.	숫자가 나빠진 날에도 아무도 화면을 열지 않으면 지나갑니다.
⑧ 보고서와 보기 저장	해설과 표, 폭포 차트를 모은 검토용 보고서를 내려받고, 자주 쓰는 축 구성은 이름을 붙여 저장해 열자마자 조회되게 합니다.	화면을 캡처해 문서에 붙이고, 매번 축을 다시 구성합니다.

사례로 보는 효과

검증용 샘플 데이터(2026년 1~9월 입금 가정 데이터, 원천 라인 8,356건)를 전체 범위로 조회하면 입금 계획은 32,054.41억원, 실적 순입금액은 32,721.80억원으로 +667.39억원(계획 대비 102.1%) 차이가 납니다. 이 차이를 일곱 요인으로 가르면 청구 금액 변동 +322.39억, 환율 효과 +67.09억, 연체이자·가산 반영 +7.09억, 공제·상계 효과 −48.97억, 입금월 이동 0, 계획 외 입금 +1,566.50억, 계획 입금 미발생 −1,246.71억이며 합계가 총차이와 정확히 같습니다(검산 0원).

눈여겨볼 점은 총차이 +667억이 “계획보다 잘 걷혔다”는 한 문장이 아니라, 계획에 없던 입금이 크게 들어오고 계획했던 입금이 그만큼 들어오지 않은 두 흐름의 순액이라는 것입니다. 숫자 자체는 샘플 데이터에서 나온 결과이며, 대사식 30건을 전수로 돌려 차이 0건을 확인했습니다. 시간 절감률 같은 효과 수치는 근거가 없으므로 싣지 않습니다.

도입하면 달라지는 것

자금 회의 자료 — 계획과 실적, 차이의 요인, 변동 사유가 한 화면에서 나와 엑셀 취합과 화면 캡처 단계가 줄어듭니다.
회의의 질문 — “어느 숫자가 맞나”보다 “계획에 없던 입금은 어디서 왔나”를 먼저 이야기하게 됩니다.
담당자 간 인수인계 — 저장한 보기와 남겨 둔 변동 사유가 다음 달로 이어집니다.
점검 시점 — 하루 한 번 점검 에이전트가 지연 입금 비중과 미회수 잔액을 먼저 올려 줍니다.
표준 화면과의 관계 — 원천 확인과 법정 신고는 표준 화면에서 계속하고, 이 화면은 분석과 대조를 맡습니다.

이런 회사에 맞습니다

고객 수가 많고 외화 입금이 섞여 있어 입금 계획과 실적을 매월 대조해야 하는 제조·무역·서비스 기업, 여러 법인과 여러 입금 은행(계좌)을 한 팀이 점검하는 자금팀과 채권 회계팀, 입금 수단(전신환·신용장·어음·추심 등)과 공제·상계가 많아 순입금액이 청구액과 달라지는 회사에 잘 맞습니다. 반대로 거래처가 소수이고 입금이 월 몇 건 수준이라면 표준 화면만으로 충분할 수 있습니다.

실행 화면

사용 방법

처음 열면 조회 전 상태로 시작합니다. 아래 여섯 단계가 기본 흐름입니다.

조회조건을 연다 — 법인(복수 선택 가능)과 입금월 기간, 비교 기준(입금 계획), 금액 단위를 정합니다. 기간은 필수입니다.
조회 버튼을 누르거나 Enter 를 누른다 — 요약 카드와 피벗 표, 차트가 한꺼번에 채워집니다.
요약을 읽는다 — 보는 사람(경영·재무·자금·회계)을 바꾸면 먼저 보이는 측정값과 축이 달라집니다.
축을 옮긴다 — 차원 칩을 행 축·열 축으로 끌어다 놓거나 값 필터를 겁니다. 서버를 다시 부르지 않습니다.
칸이나 행을 눌러 내려간다 — 숫자 칸은 원천 입금 라인으로, 행은 차이 요인과 변동 사유로 이어집니다.
내보낸다 — 해설과 표, 폭포 차트를 모은 보고서를 내려받고, 자주 쓰는 구성은 보기로 저장합니다.

무엇으로 만들었나

화면은 SAP 표준 UI 컨트롤로 구성하고, 숫자를 만드는 일은 서비스 쪽에 두었습니다. 화면은 읽기만 하고 금액을 새로 만들지 않습니다.

자리	무엇	왜 그렇게 두었나
화면 컨트롤	OpenUI5 표준 컨트롤(트리 표, 대화상자, 입력류)과 직접 그린 벡터 차트	외부 차트 라이브러리를 들이지 않아 사내망 반입 심사 부담이 없고, 표와 차트가 같은 데이터에서 그려집니다.
집계·판정 로직	요인분해·해설 문장·에이전트 점검·집중도 계산을 모은 계산 모듈	금액과 비율을 한 곳에서만 계산해, 화면이나 해설이 숫자를 따로 만들지 않게 합니다.
데이터 서비스 구성	OData V2 서비스 한 벌 — 실적·계획 큐브, 원천 입금 라인, 차원·측정값·계산항목 정의, 변동 사유·저장한 보기·에이전트 기록 등 열네 개 데이터 묶음과 계산 기능 세 개	조회와 쓰기를 같은 서비스로 처리하고, 운영 전환 때는 서비스 주소만 바꾸면 되도록 화면과 서비스를 분리했습니다.
브라우저 계산	축 전환·필터·계산항목·소계	한 번 받은 큐브를 브라우저에서 다시 접어 서버 요청 없이 즉시 반응합니다.
테마	sap_horizon	SAP 표준 화면과 같은 눈높이로 읽히도록 표준 테마를 썼습니다.

항목	내용
솔루션	자금 솔루션
업무 영역	수금·입금(현금 유입) 분석
관련 기준서·대상 영역	IAS 7 현금흐름표(K-IFRS 제1007호), IAS 21 환율변동효과(K-IFRS 제1021호) — 요구사항 명칭만 인용하며 문단 번호는 원문 확인 필요
SAP 표준 T-code	F-28, FBL5N, FF_5, FF7A, FF7B
화면 성격	다차원 분석(큐브·피벗·드릴스루·계획 대비 차이·요인분해·해설·에이전트)

SAP 표준 기능을 그대로 이어받은 부분 — 입금 전표와 청산 정보(F-28), 고객 미결·청산 항목(FBL5N), 은행 계좌 명세(FF_5), 현금 포지션(FF7A), 유동성 예측(FF7B)의 데이터 구조를 그대로 이어받아 확장했습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더합니다.

처음 열었을 때 — 조회조건과 보드, 그리고 첫 조회

조회 전에는 조회조건과 차원 보관함, 행·열 축 보드만 놓여 있습니다. 조회를 누르면 요약 카드와 피벗 표, 오른쪽 차트가 한 번에 채워집니다.

처음 열었을 때 — 조회 전 화면 — **조회 전 화면** — 조회조건과 보는 사람, 차원 보관함, 행·열 축이 한 화면에 놓여 있습니다.

조회 버튼은 조회조건 영역 오른쪽 끝에 있고 Enter 키로도 조회됩니다. 아직 숫자를 부르지 않은 상태라 서비스 요청은 한 건도 나가지 않았습니다. 보드에는 기본 행 축과 열 축이 미리 놓여 있어 바로 조회해도 의미 있는 표가 나옵니다.

처음 열었을 때 — 조회 직후 — **조회 직후** — 순입금액·최대 고객군 비중·연체이자 비율·지연 입금 비중·계획 대비 차이 카드와 피벗 표, 차트가 함께 그려집니다.

카드는 보는 사람(역할)에 따라 달라지고, 표는 행 축 단계별로 접었다 펼 수 있습니다. 금액은 기본 억원 단위로 나눠 보이며 서비스 값은 원 단위 그대로입니다. 기본 기간은 2026년 1월부터 9월까지입니다.

처음 열었을 때 — 레이아웃 보드 펼침 — **레이아웃 보드 펼침** — 조회조건 패널을 펼치면 법인·기간·비교 기준·금액 단위를 바꿀 수 있습니다.

기간은 입금월 기준이며 필수 조건입니다. 비교 기준을 비우면 계획 없이 실적만 보이고, 입금 계획을 고르면 차이 모드를 쓸 수 있습니다. 금액 단위는 화면 표시에만 쓰이고 서비스 값은 바뀌지 않습니다.

경영 요약 — 보는 사람에 따라 먼저 보이는 것이 달라진다

같은 큐브라도 경영·재무·자금·회계가 먼저 보고 싶은 숫자는 다릅니다. 역할을 바꾸면 측정값과 축이 바뀌고, 서버를 다시 부르지 않습니다.

경영 요약 — 경영 — 경영 — 어느 고객군에 입금이 몰려 있는지, 계획에서 벗어난 고객군이 어디인지를 먼저 보여줍니다.

첫 카드는 최대 고객군의 입금 비중이고, 표는 고객군을 행으로 둡니다. 집중도가 높을수록 한 고객군의 지연이 자금 수지에 미치는 영향이 커지므로 비중과 계획 차이를 함께 읽습니다. 역할을 바꿔도 조회 범위는 그대로입니다.

경영 요약 — 재무 — 재무 — 순입금액, 연체이자·가산, 공제·상계가 계획과 얼마나 달라졌는지를 먼저 보여줍니다.

가용 자금에 직접 닿는 세 숫자를 같은 줄에 놓았습니다. 순입금액은 청구 회수액에 연체이자·가산을 더하고 공제·상계를 뺀 값이라, 세 숫자를 함께 봐야 입금액이 계획과 다른 이유를 가늠할 수 있습니다.

경영 요약 — 자금 — 자금 — 은행·입금 수단별 순입금액과 기말 미회수 잔액, 지연 입금 비중을 먼저 보여줍니다.

행 축이 입금 은행과 입금 수단으로 바뀌어 어느 계좌로 어떤 수단의 돈이 들어왔는지 읽힙니다. 기말 미회수 잔액은 기간을 합쳐도 끝 기간 값만 쓰므로 월별로 더하지 않습니다.

경영 요약 — 회계 — 회계 — 가수금 보류·정리 입금과 공제·상계 처리, 통화별 환산 입금을 먼저 보여줍니다.

처리 단계 축으로 정리 전 보류분을 따로 볼 수 있어 대사가 끝나지 않은 입금이 어디에 남았는지 확인합니다. 통화별 입금은 입금일 환율로 환산한 원화 금액으로 보이며 통화를 그대로 더하지 않습니다.

축 전환과 범위 — 끌어다 놓으면 바로 다시 그려진다

차원 칩을 보드에 끌어다 놓는 것이 이 화면의 기본 조작입니다. 값 필터와 표·차트 너비 조절도 서버 요청 없이 브라우저에서 처리됩니다.

축 전환과 범위 — 차원을 끌어다 놓기 — **차원을 끌어다 놓기** — 차원 칩을 행 축·열 축으로 끌어다 놓으면 표와 차트가 바로 다시 그려집니다.

입금월·분기·법인·입금 은행·고객군·입금 수단·통화·입금일 대비·처리 단계·공제 구분 열 개 차원을 쓸 수 있습니다. 축을 바꿔도 총합은 변하지 않으며, 이는 대사식으로 매번 확인합니다.

축 전환과 범위 — 열 축 두 단계 — **열 축 두 단계** — 열 축에 분기와 입금일 대비를 겹쳐 두면 2단 머리글로 나뉩니다.

검증에서는 행 축 세 단계, 열 축 두 단계 구성을 썼습니다. 행 수와 열 수에는 상한이 있어 넘으면 표를 그리지 않고 안내가 뜹니다. 단계가 늘수록 칸이 잘게 나뉘므로 필요한 만큼만 겹치는 편이 읽기 좋습니다.

축 전환과 범위 — 값 필터 창 — **값 필터 창** — 차원별 값을 여러 개 고를 수 있고, 값 옆에 원천 라인 수가 함께 보입니다.

필터 창은 차원마다 값 목록을 보여 주고 체크한 값만 남깁니다. 라인 수는 그 값에 얼마나 많은 원천 입금이 쌓여 있는지를 알려 주는 참고값입니다.

축 전환과 범위 — 필터 적용 결과 — **필터 적용 결과** — 필터를 적용해도 서버 요청 없이 표가 다시 계산되고, 조건은 조회조건 아래에 요약됩니다.

필터를 건 표의 총합은 필터에 해당하는 원천 라인의 합과 같아야 하며, 이 일치도 대사식에 들어 있습니다. 조건을 풀면 원래 표로 돌아갑니다.

축 전환과 범위 — 표와 차트 너비 조절 — **표와 차트 너비 조절** — 가운데 손잡이를 끌어 표와 차트의 너비를 바꿉니다.

표가 넓어야 하는 때와 차트를 크게 봐야 하는 때가 다르므로 손잡이로 조절합니다. 바꾼 너비는 이 브라우저에 기억되어 다음에 열 때 그대로 나옵니다.

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

표의 숫자 칸을 누르면 그 칸을 이룬 원천 입금 라인이 열립니다.

칸에서 원천 문서까지 — 숫자 칸 드릴스루 — **숫자 칸 드릴스루** — 칸을 누르면 원천 입금 라인이 열리고, 표의 값과 원천 합계가 같은지 화면이 확인해 줍니다.

열린 창에는 입금일·전표 번호·고객군·은행·금액이 줄로 나오고 맨 위에 칸 금액과 원천 합계의 일치 여부가 표시됩니다. 서로 다른 12개 칸을 열어 모두 일치함을 확인했습니다. 표준 화면으로 이어 보려면 전표 번호를 들고 고객 항목 조회(FBL5N)에서 같은 전표를 찾으면 됩니다.

계산항목 — 측정값처럼 골라 쓰는 식

건당 순입금액이나 지연 입금 비중처럼 식으로 만드는 값을 측정값처럼 표에 넣습니다.

계산항목 — 계산항목 선택 — **계산항목 선택** — 평균 입금액·가산 비율·공제 비율·지연 입금 비중 같은 계산항목을 측정값처럼 골라 표에 넣을 수 있습니다.

계산항목은 모두 여섯 개로, 건당 순입금액·연체이자·가산 비율·공제·상계율·지연 입금 비중·조기 입금 비중·입금 비중입니다. 식은 서비스가 내려 주고 브라우저에서 각 칸마다 다시 계산하므로 소계 행에서도 비율이 맞게 나옵니다.

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

비교 기준을 입금 계획으로 두면 같은 표가 계획 대비 차이 표가 됩니다. 행을 고르면 차이를 일곱 요인으로 가르고, 사유를 남길 수 있습니다.

입금 계획 대비 차이 — 계획 차이 켜기 — **계획 차이 켜기** — 실적·계획·차이·차이율이 나란히 나옵니다.

금액 기준과 비율 기준을 모두 넘는 칸만 색이 칠해지며, 증가는 초록, 감소는 빨강입니다. 기준에 못 미치는 작은 흔들림은 칠하지 않아 눈이 큰 차이로 갑니다.

입금 계획 대비 차이 — 폭포 차트와 요인분해 — **폭포 차트와 요인분해** — 행을 고르면 계획에서 실적까지 요인별 증감이 폭포로 그려집니다.

일곱 요인의 합과 총차이가 같은지 검산 줄이 아래에 보입니다. 샘플 데이터 전체 범위에서는 계획 32,054.41억에서 실적 32,721.80억까지 청구 금액 변동 +322.39억, 환율 효과 +67.09억, 계획 외 입금 +1,566.50억, 계획 입금 미발생 −1,246.71억 등으로 나뉩니다.

입금 계획 대비 차이 — 변동 사유 입력 — **변동 사유 입력** — 선택한 행의 차이 원인을 구분과 문장으로 남깁니다.

사유는 담당자가 확인해서 적는 서술이며 화면이 대신 써 주지 않습니다. 구분을 고르고 문장을 적으면 조회 범위와 행 경로를 키로 저장됩니다.

입금 계획 대비 차이 — 변동 사유 저장 — **변동 사유 저장** — 저장하면 서비스에 기록되고 다시 열어도 같은 사유가 보입니다.

저장한 사유는 변동 사유 목록에 바로 반영되어, 같은 범위를 다시 열면 이어서 볼 수 있습니다.

해설과 보고서 — 숫자는 서비스가, 문장은 규칙이

해설은 서비스가 계산한 숫자를 근거로 문장을 만듭니다. 모델을 연결하지 않아도 규칙으로 같은 근거의 해설이 나옵니다.

해설과 보고서 — 해설 — 해설 — 서비스가 계산한 숫자를 근거로 만든 설명 초안입니다.

범위 요약과 고객군·은행별 주요 변동이 줄로 나옵니다. 금액과 비율은 모델이 만들지 않고 서비스가 계산해 문장에 끼워 넣습니다. 표시에 “규칙” 또는 “모델”로 근거가 구분됩니다.

해설과 보고서 — 근거 표 — **근거 표** — 해설에 쓴 숫자를 근거 표로 펼쳐 계획·실적·차이를 확인합니다.

문장을 읽다가 숫자를 의심하면 그 줄의 근거 행을 열어 계획·실적·차이가 같은 값인지 바로 확인합니다.

해설과 보고서 — 보고서 내려받기 — **보고서 내려받기** — 해설과 표, 폭포 차트를 모아 검토용 보고서 파일을 내려받습니다.

브라우저 안에서 파일을 만들어 내려받으며 외부로 전송하지 않습니다. 샘플 확인에서 슬라이드 4장, 약 135KB의 파일이 만들어졌습니다.

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

감시 규칙, 대기함, 실행 이력이 한 창에 있습니다. 규칙은 지연 입금 비중, 가수금 보류 비중, 계획 차이, 기말 미회수 잔액 네 가지입니다.

AI 에이전트 — 에이전트 창 — **에이전트 창** — 감시 규칙, 대기함, 실행 이력이 한 창에 있습니다.

규칙마다 지표·비교 연산·임계값·받을 역할이 표시됩니다. 임계값은 서비스가 가진 규칙값이며 운영에서는 회사 기준으로 조정합니다.

AI 에이전트 — 첫 실행 — **첫 실행** — 지금 실행을 누르면 규칙을 점검해 걸린 항목을 대기함에 올립니다.

샘플 확인에서 규칙 4개 중 3건이 걸렸고, 걸린 항목은 받을 역할의 눈으로 다시 적혀 대기함에 올라왔습니다. 실행은 이력으로 남습니다.

AI 에이전트 — 같은 날 두 번째 실행 — **같은 날 두 번째 실행** — 하루 한 번 제한을 서버가 판정해 막고, 이력에는 기록이 남습니다.

제한은 화면이 아니라 서비스가 판정합니다. 두 번째 눌러도 새 항목이 생기지 않고 “오늘은 이미 실행했습니다”라는 안내가 나오며 다음 날 다시 실행할 수 있습니다.

보기 저장과 복원 — 열자마자 내가 보던 자리

축·필터·측정값·역할을 이름 붙여 저장하고 불러옵니다.

보기 저장과 복원 — 현재 보기 저장 — **현재 보기 저장** — 축·필터·측정값·역할을 이름 붙여 저장합니다.

기본 보기로 지정하면서 자동 조회를 함께 켤 수 있습니다. 저장한 내용은 서비스에 기록되어 브라우저를 바꿔도 이어집니다.

보기 저장과 복원 — 저장한 보기 관리 — **저장한 보기 관리** — 적용·기본으로·자동 조회·이름 바꾸기·삭제를 할 수 있습니다.

목록에서 보기를 골라 바로 적용하거나 기본 보기를 바꿉니다. 이름 바꾸기와 삭제도 같은 창에서 합니다.

보기 저장과 복원 — 기본 보기 자동 조회 — **기본 보기 자동 조회** — 기본 보기에 자동 조회를 켜 두면 열자마자 조회된 상태로 시작합니다.

열 때 저장한 축 구성과 역할, 조회조건이 그대로 복원되고 조회까지 실행됩니다. 샘플 확인에서 저장 후 다시 열었을 때 같은 보기로 시작함을 확인했습니다.

좁은 화면과 한계 — 휴대폰에서, 그리고 너무 큰 표

폭이 좁아지면 차트가 표 아래로 내려갑니다. 축 조합이 너무 크면 표 대신 안내가 나옵니다.

좁은 화면과 한계 — 좁은 화면 — **좁은 화면** — 폭 390px 에서는 차트가 표 아래로 내려갑니다.

검증에서 문서 폭이 화면 폭 390px 과 같아 가로로 밀리지 않음을 확인했습니다. 차트는 표 아래에서 같은 데이터를 보여 줍니다.

좁은 화면과 한계 — 행 수 상한 안내 — **행 수 상한 안내** — 축 조합이 너무 크면 표를 그리지 않고 행 축을 줄이거나 필터를 걸라는 안내가 뜹니다.

행 수와 열 수의 상한은 브라우저가 한꺼번에 그릴 수 있는 크기를 지키기 위한 것입니다. 안내에 따라 축을 줄이거나 값 필터를 걸면 다시 표가 나옵니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 실적 큐브와 계획 큐브를 한 번씩 받아 오고, 이후의 축 전환·필터·계산항목은 받아 둔 큐브를 브라우저에서 다시 접어 처리합니다. 칸을 누르면 그 칸 조건으로 원천 입금 라인을 따로 불러오고, 차이 모드에서 행을 고르면 요인분해 계산을 서비스에 요청합니다. 변동 사유·보기·에이전트 실행은 서비스에 기록합니다.

판정과 집계 — 조건에서 결과, 사용자 조치까지

판정 조건	결과 상태	사용자 조치
입금일이 약정 입금일을 넘음	지연 입금으로 분류, 지연 입금 비중에 포함	비중이 임계 이상이면 점검 필요 — 고객군·은행별로 몰림 확인
입금일이 약정 입금일보다 앞섬	조기 입금으로 분류	현금할인·선수금 상계와 함께 입금 시기 이동 확인
처리 단계가 가수금 보류 후 정리	정리 전 보류분으로 표시	회계가 대사 완료 여부 확인 필요
계획 차이가 금액 기준과 비율 기준을 모두 초과	차이 칸에 색 표시(증가 초록·감소 빨강)	요인분해와 변동 사유로 원인 확인 필요
요인 합 + 계획 − 실적 ≠ 0	검산 줄에 오류 표시	서비스 계산 확인 필요(샘플 데이터에서는 0건)
칸 금액 ≠ 원천 라인 합계	드릴스루 창에 불일치 표시	원천 확인 필요
하루 한 번 점검 이력이 오늘 있음	에이전트 두 번째 실행은 제한 안내	내일 다시 실행 또는 이력 확인

차이를 일곱 요인으로 가르는 순서

범위 안 원천 라인을 입금 계획이 있는 줄과 실적이 있는 줄로 나눕니다.
계획과 실적이 모두 있는 줄은 거래통화 금액 차이에 계획 환율을 곱해 청구 금액 변동을, 나머지 청구 회수액 차이를 환율 효과로 둡니다.
같은 줄의 가산 차이는 연체이자·가산 반영, 공제 차이는 부호를 바꿔 공제·상계 효과로 둡니다.
실적만 있는 줄은 계획에 없던 입금이면 계획 외 입금, 다른 달 계획이 옮겨 온 입금이면 입금월 이동으로 분류합니다.
계획만 있는 줄은 회수가 미뤄졌거나 분쟁으로 안 들어온 계획 입금 미발생, 다른 달로 옮겨 간 계획이면 입금월 이동으로 분류합니다.
계획 + 일곱 요인 − 실적이 0인지 검산해 화면에 보여 줍니다. 원화 입금은 환율이 1이어서 환율 효과가 0입니다.

조회조건

조건	필수	기본값	처리
법인(복수 선택)	선택	전체(조건 없음)	선택한 법인만 남김
기간 시작·끝(입금월)	필수	2026년 01월 ~ 09월	입금월 범위로 조회
비교 기준	선택	입금 계획	없으면 계획 없이 실적만 표시
금액 단위	선택	억원	화면에서만 나눔(서비스 값은 원)

결과 컬럼

결과 컬럼	의미	산식
순입금액(원)	입금으로 들어온 순액	청구 회수액 + 연체이자·가산 − 공제·상계
청구 회수액(원)	공제 전 청구 대금 입금	거래통화 금액 × 입금일 환율
연체이자·가산(원)	약정일 초과로 더해진 금액	원천 라인 합
공제·할인·상계(원)	현금할인·수수료·선수금 상계	원천 라인 합
기말 미회수 잔액(원)	월말까지 입금되지 않은 청구	끝 기간 값(합산 아님)
계산항목	건당 순입금액·가산 비율·공제 비율·지연/조기 입금 비중·입금 비중	측정값 식으로 브라우저에서 계산
차이·차이율	실적 − 계획, 차이 ÷ 계획	계획 차이 모드

좁은 화면에서 달라지는 것

폭이 좁아지면 차트가 표 아래로 내려가고, 조회조건은 한 줄씩 쌓입니다. 같은 데이터를 같은 순서로 보여 주므로 휴대폰에서도 요약 카드와 표를 위에서 아래로 읽으면 됩니다.

파일 구성

화면 폴더/
├─ 첫 화면 · 설정 · 화면 정의(XML 뷰)
├─ 컨트롤러 · 모델 · 서식
├─ 스타일 · 다국어 문구
├─ OData 서비스 구현과 계산 모듈 · 서비스 정의 · 샘플 데이터(JSON)
└─ 설명서 · 소개 영상

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 아래는 맞닿은 표준 T-code 와 이어지는 자리입니다.

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

하고 싶은 일	SAP 표준	표준에서 걸리는 자리	이 앱이 하는 일
고객 입금 전표 기록	F-28	입력과 청산이 목적이라 분석 축이 없음	입금 전표 라인을 큐브로 묶어 분석
고객별 미결·청산 항목 보기	FBL5N	고객 단위 목록이라 은행·입금 수단·통화 축으로 접기 어려움	같은 항목을 축 전환 피벗으로
은행 계좌 명세 반영	FF_5	명세 가져오기가 목적	입금 은행별 순입금액과 지연 입금 비중
현금 포지션과 계획 대조	FF7A	계획과 실적을 읽는 화면이 갈라져 있음	계획과 실적을 같은 표에서 차이로
유동성 예측	FF7B	예측 항목과 실적 사이 차이의 원인을 가르는 기능은 별도 작업	차이를 일곱 요인으로 분해
차이의 원인 분해	없음	표준 화면에 같은 분해는 없어 보통 엑셀로 만듭니다	일곱 요인으로 가르고 합계를 검산

T-code 별 연계 지점

T-code	이름	연계
F-28	고객 입금 전기	이 앱이 이어받는 것: 입금일·금액·통화·청산 정보. 대사 지점: 칸의 원천 합계와 전표 금액. 오가는 방법: 이 앱의 원천 라인에서 전표 번호를 찾아 표준 전표 조회로 확인. 표준에 남길 일: 입금 전기와 청산 처리.
FBL5N	고객 항목 조회	이어받는 것: 미결·청산 항목과 기말 미회수 잔액. 대사 지점: 월말 미결 잔액. 오가는 방법: 드릴스루의 전표 번호 → FBL5N 에서 같은 전표. 표준에 남길 일: 고객 계정 정리와 독촉.
FF_5	전자 은행 계좌 명세 가져오기	이어받는 것: 입금 은행 계좌 명세. 대사 지점: 은행별 순입금액. 오가는 방법: 은행 축 칸 → 명세 항목 확인. 표준에 남길 일: 명세 반영 처리.
FF7A	현금 포지션	이어받는 것: 입금 계획과 실적 대조. 대사 지점: 계획 금액. 오가는 방법: 이 앱의 계획 대비 차이 → FF7A 에서 같은 기간 계획. 표준에 남길 일: 자금 포지션 관리.
FF7B	유동성 예측	이어받는 것: 예측 입금 항목과 계획 대조. 대사 지점: 예측 입금과 계획 금액. 오가는 방법: 요인분해 결과 → 예측 항목 재점검. 표준에 남길 일: 예측 확정과 보고.

기존 리포트를 없애야 하느냐는 질문에는 “아니요”라고 답합니다. 법정 신고와 감사 대응 자료는 표준 화면에 두고, 이 화면은 분석·점검에 쓰면서 두 화면의 숫자를 같은 기준으로 맞춰 봅니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 가 이미 있는 환경에서는 이 앱을 대체재가 아니라 보완재로 두는 편이 맞습니다. 표준 분석 도구가 다루지 않는 입금 계획 대비 일곱 요인 분해, 변동 사유 기록, 점검 에이전트를 이 앱이 맡고, 정형 리포트와 전사 공통 분석은 표준 도구가 맡습니다. 구체적인 표준 Fiori 앱 이름은 고객사 릴리스에서 확인이 필요해 싣지 않았습니다.

분석 지표 정의

지표	산식·판정 기준	대응 기능	원천 데이터	비고
순입금액	청구 회수액 + 연체이자·가산 − 공제·상계	피벗·카드	입금 전표 라인	원 단위 서비스 계산
지연 입금 비중	지연 입금 순입금액 ÷ 순입금액	계산항목·에이전트	약정일 대비 입금일	임계는 에이전트 규칙에서 조정
계획 대비 차이	실적 − 계획	차이 모드·폭포	입금 계획 라인	일곱 요인 분해
기말 미회수 잔액	월말 미입금 청구	카드·에이전트	고객 미결 항목	끝 기간 값
환율 효과	(입금일 환율 − 계획 환율) 영향	요인분해	거래통화 금액	환율은 가정값

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

자리	무엇을 손대나	비고
공제·상계 코드 매핑	현금할인·수수료·선수금 상계 등 조건 유형을 공제 구분으로 묶는 기준	회사별로 다름 — 확인 필요
고객 → 고객군 매핑	고객 마스터 기준으로 고객군을 정하는 표	고객군 정의는 자금·영업이 합의
은행 계좌 → 입금 은행	계좌 명세의 계좌와 입금 은행 이름 연결	계좌 변경 때 갱신
환율 유형·환산 시점	입금일 환율을 어떤 환율 유형으로 읽을지	운영 환율 유형 확인 필요
권한	법인·은행·고객군 범위 제한	집계 단계에 건다
에이전트 규칙	지표·임계값·받을 역할·주기	회사 기준으로 조정

CDS 구성

아래는 운영 환경 이식을 전제로 한 ABAP CDS 스케치입니다. 표준 CDS 뷰는 실재하는 I_OperationalAcctgDocItem 과 I_Customer 만 썼고, 계획 원천은 고객사 환경 확인이 필요하며, 계획 뷰가 읽는 중간 뷰(ZRCP_PlanSource)는 고객사의 자금 계획 항목 구성에 맞춰 따로 정의합니다. 필드 이름과 문법은 릴리스에 맞춰 조정해야 합니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	ZRCP_CUSTMAP · ZRCP_DEDMAP	고객군·공제 구분 매핑 표	분류 기준이 바뀌어도 코드를 건드리지 않게
차원·원천	ZI_ReceiptItem	고객 항목 입금 라인 정리	큐브와 드릴스루가 같은 라인을 보게
큐브	ZI_ReceiptCube · ZR_ReceiptPlan	실적·계획 집계	계획과 실적이 같은 차원에서 차이가 성립하게
쿼리	ZC_ReceiptCubeQuery	화면용 노출, 기본 축·필수 범위	큐브는 재사용, 모양은 쿼리가 결정
권한	DCL ZC_ReceiptCubeQuery	법인 범위 제한	집계 단계 권한으로 우회 차단
서비스	ZUI_ReceiptAnalysis	OData 노출	화면은 서비스 주소만 알면 됨

① 고객군·공제 구분 매핑 테이블 — 분류 기준을 데이터로 둔다

고객 마스터에서 고객군을, 공제·상계 코드에서 공제 구분을 정하는 기준표입니다. 코드로 박아 두면 기준이 바뀔 때마다 이송이 필요하므로 표로 분리했습니다. 분류 기준이 곧 분석 결과를 좌우하므로 운영에서 가장 먼저 합의할 대상입니다.

" ───────────────────────────────────────────────
" ZRCP_CUSTMAP — 고객 → 고객군 매핑
" 역할 : 고객 마스터(KNA1)의 고객을 분석용 고객군으로 묶는다.
" 나눈 이유 : 고객군 정의는 자금·영업이 합의해 바꾸는 값이므로
"             뷰 코드가 아니라 표로 둔다.
" ───────────────────────────────────────────────
@EndUserText.label : '고객군 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zrcp_custmap {
  key client   : abap.clnt not null;
  key customer : kunnr     not null;
  cust_group   : abap.char(2);
}

" ZRCP_DEDMAP — 공제·상계 코드 → 공제 구분 매핑
@EndUserText.label : '공제 구분 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zrcp_dedmap {
  key client   : abap.clnt not null;
  key ded_code : abap.char(4) not null;
  ded_kind     : abap.char(1);   " N 없음 · D 현금할인 · F 수수료 · O 기타
}

② ZI_ReceiptItem — 입금 원천 라인 뷰

표준 전표 라인 뷰에서 고객 항목만 골라 입금일·약정일·통화·금액을 한 줄로 모읍니다. 입금 전표와 청산 정보가 한 곳에서 나오고, 이 뷰가 큐브와 드릴스루의 공통 원천이 됩니다. 표준 뷰의 필드 이름은 릴리스마다 달라질 수 있어 고객사 환경에서 확인이 필요합니다.

" ───────────────────────────────────────────────
" ZI_ReceiptItem — 입금 원천 라인(기본 뷰)
" 역할 : I_OperationalAcctgDocItem 에서 고객 항목만 골라
"        입금 분석에 필요한 필드로 정리한다.
" 나눈 이유 : 큐브와 드릴스루가 같은 라인을 보게 해
"             칸 금액 = 원천 합계가 구조적으로 성립한다.
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '입금 원천 라인'
define view entity ZI_ReceiptItem
  as select from I_OperationalAcctgDocItem as it
  left outer join I_Customer          as cu on cu.Customer = it.Customer
  left outer join zrcp_custmap        as cm on cm.customer = it.Customer
{
  key it.CompanyCode,
  key it.AccountingDocument,
  key it.FiscalYear,
  key it.AccountingDocumentItem,
      it.PostingDate,
      it.NetDueDate,
      it.ClearingDate,
      it.Customer,
      cm.cust_group                        as CustGroup,
      it.TransactionCurrency,
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      it.AmountInTransactionCurrency       as TransAmount,
      it.CompanyCodeCurrency,
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      it.AmountInCompanyCodeCurrency       as LocalAmount,
      case when it.PostingDate > it.NetDueDate then 'L'
           when it.PostingDate < it.NetDueDate then 'E'
           else 'O' end                    as Timing   " 지연 · 조기 · 약정일
}
where it.FinancialAccountType = 'D'     " 고객 계정만

③ ZI_ReceiptCube — 입금월·은행·고객군별 집계 큐브

원천 라인을 입금월·법인·고객군·통화·입금일 대비로 집계하고, 거래통화 금액을 입금일 환율로 원화에 환산합니다. 환산은 큐브에서 한 번만 하고 화면은 다시 환산하지 않습니다. 환율 유형과 환산 기준일은 운영에서 합의해야 하는 값입니다.

" ───────────────────────────────────────────────
" ZI_ReceiptCube — 실적 큐브
" 역할 : 월·법인·고객군·통화·입금일 대비 단위로 순입금액을 집계.
" 나눈 이유 : 집계를 서비스가 아니라 DB 에서 하도록 내려,
"             대용량에서도 화면이 큐브만 받게 한다.
" ───────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@ObjectModel.usageType.serviceQuality : #D
@EndUserText.label : '입금 실적 큐브'
define view entity ZI_ReceiptCube
  as select from ZI_ReceiptItem as i
{
  key left( cast( i.PostingDate as abap.char(8) ), 6 ) as PostMonth,
  key i.CompanyCode,
  key i.CustGroup,
  key i.TransactionCurrency,
  key i.Timing,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      sum( currency_conversion(
             amount             => i.TransAmount,
             source_currency    => i.TransactionCurrency,
             target_currency    => i.CompanyCodeCurrency,
             exchange_rate_date => i.PostingDate,
             exchange_rate_type => 'M',
             error_handling     => 'SET_TO_NULL' ) )   as GrossLocal,
      i.CompanyCodeCurrency,
      @DefaultAggregation : #SUM
      count( * )                                       as LineCount
}
group by
  left( cast( i.PostingDate as abap.char(8) ), 6 ),
  i.CompanyCode, i.CustGroup, i.TransactionCurrency,
  i.Timing, i.CompanyCodeCurrency

④ ZR_ReceiptPlan — 입금 계획 뷰

자금 계획 항목에서 입금 계획을 같은 차원으로 모읍니다. 계획 버전을 키에 두어 계획 대비 차이를 버전별로 읽습니다. 계획 원천 테이블의 필드 구성은 고객사 환경에서 확인이 필요합니다.

" ───────────────────────────────────────────────
" ZR_ReceiptPlan — 입금 계획(원천 테이블 FDES 기준)
" 역할 : 입금 계획 금액을 실적 큐브와 같은 차원으로 맞춘다.
" 나눈 이유 : 계획이 같은 차원이어야 차이 모드에서
"             칸 단위로 실적 − 계획이 성립한다.
" 확인 필요 : FDES 의 필드 이름·버전 구분은 고객사 환경 기준.
" ───────────────────────────────────────────────
@EndUserText.label : '입금 계획'
define view entity ZR_ReceiptPlan
  as select from ZRCP_PlanSource as p
{
  key p.PlanVersion,
  key p.PlanMonth,
  key p.CompanyCode,
  key p.CustGroup,
  key p.TransactionCurrency,
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      sum( p.PlanAmountLocal ) as PlanLocal,
      p.CompanyCodeCurrency
}
group by p.PlanVersion, p.PlanMonth, p.CompanyCode,
         p.CustGroup, p.TransactionCurrency, p.CompanyCodeCurrency

⑤ ZC_ReceiptCubeQuery — 분석 쿼리

큐브를 화면에 노출하는 분석 쿼리입니다. 행·열 기본 배치와 필수 필터를 여기서 정하고, 입금월 범위를 필수 파라미터로 둡니다. 범위를 필수로 두면 전표가 많아도 한 번에 전체를 읽지 않습니다.

" ───────────────────────────────────────────────
" ZC_ReceiptCubeQuery — 분석 쿼리(Consumption)
" 역할 : 큐브를 화면용으로 노출. 기본 축·필터·필수 범위 지정.
" 나눈 이유 : 화면이 읽는 모양을 쿼리에서 정해, 큐브는 재사용.
" ───────────────────────────────────────────────
@Analytics.query : true
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '입금 분석 쿼리'
define view entity ZC_ReceiptCubeQuery
  as select from ZI_ReceiptCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @AnalyticsDetails.query.displayHierarchy : #OFF
  key PostMonth,
  @AnalyticsDetails.query.axis : #ROWS
  key CustGroup,
  @AnalyticsDetails.query.axis : #FREE
  key CompanyCode,
  @AnalyticsDetails.query.axis : #FREE
  key TransactionCurrency,
  @AnalyticsDetails.query.axis : #FREE
  key Timing,
  @AnalyticsDetails.query.axis : #COLUMNS
  GrossLocal,
  @AnalyticsDetails.query.axis : #COLUMNS
  LineCount,
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  PostMonth as PostMonthFilter
}

⑥ ZC_ReceiptCubeQuery 권한 — DCL

법인 범위로 읽기를 제한합니다. 집계 단계에 권한을 걸어야 전사 합계에서 자기 몫을 빼 남의 숫자를 알아내는 우회를 막습니다. 드릴스루에만 권한을 걸면 뺄셈으로 새어 나갑니다.

" ───────────────────────────────────────────────
" 권한 — 법인 단위로 읽기 제한(집계 단계)
" 나눈 이유 : 드릴스루에만 걸면 전사 합계 − 자기 몫으로 새어 나감.
" ───────────────────────────────────────────────
@EndUserText.label : '입금 분석 권한'
@MappingRole : true
define role ZC_ReceiptCubeQuery {
  grant select on ZC_ReceiptCubeQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

쿼리를 OData V2 서비스로 노출합니다. 운영에서는 이 서비스를 게시하고 화면 설정의 서비스 주소만 교체합니다.

" ───────────────────────────────────────────────
" 서비스 정의 — 화면이 부르는 서비스 구성
" ───────────────────────────────────────────────
@EndUserText.label : '입금 분석 서비스'
define service ZUI_ReceiptAnalysis {
  expose ZC_ReceiptCubeQuery as ReceiptQuery;
  expose ZI_ReceiptItem      as ReceiptItem;
  expose ZR_ReceiptPlan      as ReceiptPlan;
}

" 서비스 바인딩은 Service Binding 편집기에서 OData V2 – UI 로 만들어 게시한다.
" (게시 전 /IWFND/MAINT_SERVICE 에서 활성 여부 확인)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않으면 첫 회의에서 기존 보고서와 숫자가 어긋납니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
공제·상계 코드 매핑	어떤 조건 유형이 현금할인·수수료·선수금 상계인지	공제 구분 합계가 표준 화면과 어긋남	회계팀
고객군 정의	고객 → 고객군 기준	고객군 비중 해석이 부서마다 달라짐	자금·영업
환율 유형·환산 시점	입금일 환율을 어느 유형으로 읽을지	환율 효과가 계획 환율 가정과 섞임	자금팀
부호 규칙	입금을 양수로 볼지, 공제·상계의 부호	순입금액이 청구액과 어긋남	회계팀
실적·계획·예측 원천 확정	계획 버전과 예측 항목 범위	계획 대비 차이의 기준이 흔들림	자금팀
차원 범위·권한	쓸 차원과 법인·은행 권한	남의 숫자가 보이거나 늦게 확장해야 함	보안·권한
대사 체계	표준 T-code 와 맞출 항목과 주기	두 화면 숫자 차이의 원인을 못 찾음	회계·자금
성능 기준	허용 응답 시간과 필수 범위	대용량에서 화면이 느려짐	Basis
전송(TR) 순서	매핑 표 → 뷰 → 쿼리 → 권한 → 서비스	활성화 오류	Basis
서비스 활성화와 주소 교체	서비스 게시와 화면 설정의 서비스 주소	운영 연결 안 됨	Basis·IT

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

검증용 샘플 데이터에서 대사식 30건을 전수로 돌렸고 차이는 0건, 최대 차이 0원, 의도적 예외는 없습니다. 외화는 통화별로 따로 대사했습니다.

대사식	검사 건수	차이
큐브 순입금액 = 원천 라인 순입금액	1건(전체 합 32,721.80억원)	0
큐브 청구 회수액·가산·공제·입금 건수·라인 수 각각	5건	0
계획 큐브 = 원천 라인 계획	1건	0
축 구성을 바꾼 피벗 총합 = 전체 합	6건(5~39셀 구성)	0
범위별 요인분해 검산(계획 + 요인 − 실적 = 0)	12건	0
통화별 요인분해 검산(원화·달러·유로·엔·위안)	5건	0
드릴스루 칸 금액 = 원천 합계(별도 검사)	12개 칸	0

대사식은 모두 30건이고 모두 통과했습니다. 기능 확인은 브라우저를 실제로 조작해 서버 요청 수까지 확인했습니다. 표준 CDS 뷰의 실제 필드 구성, 공제 코드 매핑, 운영 환율 유형은 고객사 환경에서 확인해야 합니다.

운영 데이터로 갈 때

입금 전표가 수천만 건이면 집계 위치가 가장 중요합니다. 큐브를 DB 에서 집계하고 입금월 범위를 필수 파라미터로 두며, 드릴스루는 칸 조건과 건수 상한을 걸어 부릅니다. 필터가 자주 걸리는 입금월·법인·고객 컬럼에는 인덱스나 집계 캐시를 검토하고, 첫 화면 응답 시간 기준(예: 몇 초 이내)을 운영 합의 항목으로 정해 둡니다. 샘플 데이터의 속도는 운영 성능을 보장하지 않습니다.

자주 묻는 질문

도입 전에 가장 많이 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

이 화면의 숫자는 어디서 오나요?

입금 원천 라인을 서비스가 집계한 값입니다. 화면은 읽기만 하고 금액을 새로 만들지 않습니다. 운영에서는 표준 전표 라인 뷰에서 고객 항목을 읽어 같은 구조로 집계하게 됩니다.

순입금액은 어떻게 계산하나요?

청구 회수액에 연체이자·가산을 더하고 공제·할인·상계를 뺀 값입니다. 청구 회수액은 거래통화 금액에 입금일 환율을 곱해 원화로 환산합니다.

축을 바꾸면 합계가 달라지지 않나요?

달라지지 않습니다. 모든 축은 같은 큐브에서 접히므로 총합이 같고, 축 구성을 여섯 가지로 바꿔 총합이 전체 합과 같은지 매번 대사했습니다.

외화 입금은 어떻게 합산하나요?

거래통화 금액에 입금일 환율을 곱한 원화 금액을 쓰며 통화를 그대로 더하지 않습니다. 환율은 가정값이며 운영에서는 환율 유형과 환산 시점을 정해야 합니다.

기말 미회수 잔액은 왜 합산하지 않나요?

월말 시점의 잔액이어서 기간을 합쳐도 끝 기간 값만 씁니다. 월별 잔액을 더하면 같은 청구를 여러 번 세게 됩니다.

요인분해의 합은 왜 총차이와 같은가요?

계획이 있는 줄과 실적이 있는 줄을 빠짐없이 일곱 요인 가운데 하나에 넣기 때문입니다. 계획 + 요인 합 − 실적을 검산 줄로 매번 보여 주며, 샘플 데이터 범위 12곳과 통화 5곳에서 모두 0이었습니다.

화면과 조작

처음 열면 무엇부터 보면 되나요?

조회를 누르고 위쪽 요약 카드에서 순입금액과 계획 대비 차이를 읽은 뒤, 보는 사람(경영·재무·자금·회계)을 자기 역할로 바꿉니다. 그다음 표에서 숫자가 큰 행을 펼쳐 봅니다.

조회가 느리면 어떻게 하나요?

기간을 줄이거나 법인을 고르면 됩니다. 한 번 받은 큐브는 브라우저에서 다시 접으므로 축 전환은 서버를 다시 부르지 않습니다.

표가 너무 커서 안 그려집니다.

행과 열의 상한을 넘으면 표 대신 안내가 나옵니다. 행 축을 줄이거나 값 필터를 걸면 다시 표가 나옵니다.

칸의 숫자가 맞는지 어떻게 확인하나요?

칸을 누르면 원천 입금 라인이 열리고 칸 금액과 원천 합계가 같은지 화면이 보여 줍니다. 더 깊이 보려면 전표 번호로 표준 고객 항목 조회(FBL5N)에서 같은 전표를 찾습니다.

좁은 화면에서도 쓸 수 있나요?

쓸 수 있습니다. 폭이 좁아지면 차트가 표 아래로 내려가며, 폭 390px 에서 가로로 밀리지 않음을 확인했습니다.

저장한 보기는 어디에 남나요?

서비스에 기록되어 브라우저를 바꿔도 이어집니다. 기본 보기에 자동 조회를 켜 두면 열자마자 조회된 상태로 시작합니다.

분석 기능

해설은 AI 가 숫자를 만드나요?

아닙니다. 금액과 비율은 서비스가 계산하고 문장은 그 숫자를 끼워 만듭니다. 모델을 연결하지 않아도 같은 근거로 규칙 기반 해설이 나옵니다.

변동 사유는 누가 적나요?

담당자가 적습니다. 화면은 사유를 대신 만들지 않고, 적은 사유를 조회 범위와 행 경로에 묶어 저장합니다.

에이전트는 무엇을 점검하나요?

지연 입금 비중, 가수금 보류 비중, 계획 차이, 기말 미회수 잔액 네 규칙입니다. 걸린 항목은 받을 역할의 눈으로 다시 적어 대기함에 올리고 이력을 남깁니다.

에이전트를 하루에 여러 번 돌릴 수 있나요?

하루 한 번으로 제한됩니다. 제한은 화면이 아니라 서비스가 판정하므로 두 번째 실행은 새 항목 없이 안내만 나옵니다.

보고서에는 무엇이 들어가나요?

해설과 표, 폭포 차트가 들어갑니다. 브라우저 안에서 파일을 만들어 내려받으며 외부로 전송하지 않습니다.

도입과 운영

SAP 표준 T-code 를 대신하나요?

아닙니다. 표준 실행은 SAP 표준 T-code 가 담당하고 이 화면은 조회·검증 관점을 더합니다. F-28, FBL5N, FF_5, FF7A, FF7B 와 맞닿아 있으며 법정 신고와 감사 대응은 표준에 둡니다.

누가 쓰면 좋은가요?

입금 계획과 실적을 매월 대조하는 자금팀과 채권 회계팀, 순입금액의 구성을 보고 싶은 재무 책임자에게 맞습니다. 역할별 요약이 있어 경영진도 같은 화면을 읽습니다.

적용 시기와 범위는 어떻게 되나요?

샘플 데이터는 2026년 1~9월 가정 데이터입니다. 실제 적용 범위와 시기는 고객사 확인 필요입니다.

운영 데이터에 연결하려면 무엇이 필요한가요?

매핑 표(고객군·공제 구분)와 계획 원천을 정하고, 큐브·쿼리·권한 뷰를 만들어 서비스를 게시한 뒤 화면 설정의 서비스 주소를 바꿉니다. 소요는 환경에 따라 다르며 확인 필요입니다.

권한은 어떻게 거나요?

법인 단위 권한을 집계 단계에 걸어야 합니다. 드릴스루에만 걸면 전사 합계에서 자기 몫을 빼 남의 숫자를 알아낼 수 있습니다.

거래처나 계정 체계가 바뀌면 어떻게 하나요?

고객군·공제 구분 매핑 표만 고치면 됩니다. 뷰 코드를 바꾸지 않으므로 이송 부담이 작습니다.

이 화면이 낸 숫자로 최종 판단해도 되나요?

이 화면은 점검 도구이며 최종 판단은 회사와 감사인이 하고, 세무 신고는 회사와 세무 대리인이 합니다. 법정 보고 숫자는 표준 화면의 값을 기준으로 합니다.