SAP 리스료 지급 자금 다차원 분석 리포트 — 지급 계획 대비 차이를 요인으로 가르는 월 자금 점검

Q: 순지급액은 어떻게 계산합니까?

라인마다 고정 리스료 + 변동리스료 − 상계 · 차감으로 계산한 값을 원화로 환산해 더합니다. 검증용 데이터 7,288줄 전부에서 이 식과 라인 값의 차이는 0원이었습니다. 지급 건수와 건당 순지급액은 순지급액을 지급 문서 수로 나눈 값입니다.

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

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

월 자금 회의의 질문은 늘 비슷합니다. 리스료로 이번 달 얼마가 나갔나, 계획과 얼마나 달랐나, 왜 달랐고 누가 무엇을 확인해야 하나. 지금은 이 세 답이 표준 화면 · 은행 자료 · 엑셀 · 회의 메모로 흩어져 있고, 리스 계약이 법인 · 은행 · 통화에 걸쳐 있을수록 숫자를 맞추는 일이 회의보다 길어집니다. 이 화면은 세 답을 한 화면에 붙여, 지급 현황을 만드는 손일을 줄이고 점검할 곳을 먼저 가리킵니다.

표준 실행은 SAP 표준 화면이 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 지급 계획 대비 차이를 일곱 요인으로 나누고, 사유를 행에 남기고, 기준을 넘은 숫자를 사람이 열지 않아도 대기함에 올립니다. 그리고 그 숫자가 원천 지급 라인과 어긋나지 않는지를 매번 스스로 대사합니다. 리스 지급 자금 점검이 대상 영역이며, 회계 · 세무 판단은 이 화면이 아니라 회사와 감사인, 세무 대리인의 몫입니다.

한 줄 요약 — 조회 화면은 누구나 만듭니다. 이 화면의 값은 조회 다음에 있습니다: 차이를 요인으로 가르고, 사유를 행에 남기고, 사람이 열지 않아도 점검하고, 회의 자료까지 바로 만듭니다.

핵심 포인트 여덟 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 합계가 갈라지지 않는 피벗	지급 은행 · 리스 유형 · 지급 주기 · 통화 등 차원을 끌어다 놓아 행 3단계 · 열 2단계로 봅니다. 모든 축이 같은 큐브에서 나오므로 합계가 어긋날 자리가 없습니다.	은행별 · 리스 유형별 · 통화별 표를 따로 만들고, 총액이 서로 다르면 표를 맞추는 회의를 엽니다.
② 칸에서 원천 지급 문서까지	숫자를 누르면 그 금액을 만든 지급 문서 라인이 열리고 칸 금액과 합계가 같은지 바로 보입니다.	표를 닫고 라인 조회 화면을 다시 열어 조건을 손으로 맞춥니다.
③ 지급 계획 대비 차이를 일곱 요인으로	고정 리스료 변동 · 환율 · 변동리스료 · 상계 · 지급월 이동 · 계획 외 지급 · 계획 지급 미발생으로 가르고 합이 총차이와 맞는지 매번 검산합니다.	엑셀에서 계획과 실적을 붙여 차이를 나눠 보고, 합이 맞는지 다시 손으로 맞춥니다.
④ 차이 사유가 행에 남는다	사유가 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도, 다음 달에도 따라옵니다.	같은 질문을 매달 다시 하고 지난달 답은 메일함에서 찾습니다.
⑤ 사람이 열지 않아도 도는 점검	규칙마다 기준값과 받는 사람(자금 · 회계 · 재무 · 경영)이 붙어 걸리면 대기함에 보고가 올라갑니다. 하루 한 번만 돈다는 제한은 서버가 지킵니다.	숫자가 나빠진 날 아무도 화면을 열지 않으면 그대로 지나갑니다.
⑥ 보는 사람에 맞춘 경영 요약	경영 · 재무 · 자금 · 회계 중 하나를 고르면 앞세우는 지표와 기본 축이 그 사람의 질문에 맞게 바뀝니다.	관점마다 다른 표를 만들어 돌려 보게 됩니다.
⑦ 숫자는 모델에 맡기지 않는 해설과 보고서	금액 · 비율은 서비스가 큐브에서 계산하고 해설은 그 근거 표 위에서만 만듭니다. 같은 범위로 파워포인트 보고서도 바로 만들어집니다.	화면을 캡처해 숫자를 옮겨 적고, 그 숫자를 보고서에 써도 되는지부터 따집니다.
⑧ 표준 화면과 이어지는 대사 지점	자금 포지션 · 유동성 예측 · 은행 명세 후속 · 계정 라인 · 자동 지급 실행의 표준 화면과 맞춰 볼 지점을 정해 두었습니다. 표준을 없애지 않고 함께 씁니다.	표준 화면의 값과 엑셀의 값을 사람이 눈으로 맞춥니다.

사례로 보는 효과

검증용 샘플 데이터(2026년 1~9월, 법인 3개, 은행 5곳, 통화 5종)에서 순지급액은 1,542.87억 원, 지급 계획은 1,513.79억 원으로 총차이는 +29.07억 원(+1.9%)였습니다. 합계만 보면 ‘계획보다 조금 더 나갔다’에서 끝납니다. 일곱 요인으로 가르면 모습이 달라집니다. 계획에 없던 지급이 +33.09억 원, 계획만 있고 지급이 나오지 않은 몫이 −28.36억 원으로 서로 크게 반대로 움직였고, 그 사이에서 고정 리스료 변동 +10.99, 환율 효과 +8.35, 변동리스료 반영 +4.63, 상계 · 차감 +0.37, 지급월 이동 0.00(억 원)이 남았습니다. 합 +29.07은 총차이와 맞고 화면이 이 검산을 매번 보여 줍니다.

반대로 움직이는 두 큰 요인이 서로를 가리고 있다는 사실은 합계 표에서는 보이지 않습니다. 이 차이를 ‘계획 외 지급’과 ‘계획 지급 미발생’으로 나누어 놓았기 때문에 회의가 ‘왜 조금 더 나갔나’가 아니라 ‘계획에 없던 지급은 무엇이고, 나오지 않은 지급은 해지 · 면제 · 협의 이연 중 무엇인가’로 시작할 수 있습니다. 원인은 이 화면이 단정하지 않으며 점검할 곳을 가리킵니다.

도입하면 달라지는 것

월 자금 회의 자료 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
회의의 주제 — ‘어느 숫자가 맞나’ 대신 ‘무엇을 할 것인가’를 이야기합니다.
다음 달로 이어지는 기록 — 사유와 보기가 남아 같은 설명을 다시 하지 않습니다.
놓치지 않는 점검 — 아무도 화면을 열지 않아도 기준을 넘은 숫자가 대기함에 올라옵니다.

이런 회사에 맞습니다

부동산 · 차량 · 설비 · IT 장비 등 여러 유형의 리스료가 정기적으로 나가고, 법인과 지급 은행, 통화가 여러 개라 월 단위로 계획과 실적을 맞춰 보는 회사에 맞습니다. 특히 지급 계획과 실제 지급이 다른 이유를 자금팀 · 회계팀이 매달 따로 설명해야 하는 조직, 그리고 표준 화면은 유지하면서 분석 관점만 더하고 싶은 SAP 운영 조직에 맞습니다. 반대로 리스 지급이 몇 건 안 되고 한 은행 · 한 통화뿐이라면 표준 화면과 엑셀로 충분할 수 있습니다.

실행 화면

검증용 샘플 데이터(가상의 법인 · 은행 · 계약)를 실제 브라우저에서 찍은 화면 34종입니다. 그림을 누르면 크게 볼 수 있습니다.

사용 방법

조회조건 입력 — 법인(비우면 전체), 기간 시작 · 끝(필수), 비교 기준(지급 계획과 비교 · 없음)을 정합니다.
조회 — [조회] 단추를 누르거나 조건 칸에서 Enter 키를 누릅니다. 큐브는 이때 한 번만 읽고 이후 축을 바꿔도 다시 읽지 않습니다.
요약 확인 — 위쪽 지표 카드와 조건 요약 한 줄을 봅니다. 조건 영역은 접을 수 있습니다.
보는 사람 · 축 이동 — 경영 · 재무 · 자금 · 회계 중 관점을 고르고, 차원 칩을 쓰지 않는 차원 · 행 축 · 열 축 사이로 끌어다 놓습니다(행 최대 3단계, 열 최대 2단계).
행 · 칸 클릭 — 행을 펼쳐 하위 차원으로 내려가고, 칸을 눌러 원천 지급 문서 라인을 엽니다.
차이 · 사유 — [계획 차이]를 켜 실적 · 계획 · 차이를 보고, 행을 골라 요인분해를 확인하고, [변동 사유]로 사유를 적습니다.
해설 · 에이전트 · 보기 저장 — [해설]로 근거 표가 붙은 초안과 보고서를, [에이전트]로 점검 규칙 실행을, [보기 저장]으로 배치 저장을 합니다.
내보내기 — 오른쪽 위 [CSV]로 현재 표를 내려받습니다(UTF-8, 한글 파일명).

무엇으로 만들었나

화면은 SAP UI5 표준 컨트롤과 직접 그린 SVG 차트로 이루어져 있고, 데이터는 조회용 OData 서비스를 통해 가져옵니다. 서비스는 차원 · 측정값 · 큐브 · 지급 계획 · 원천 지급 문서 라인 · 큐브 검산 · 변동 사유 · 저장한 보기 · 에이전트 규칙 · 대기함 · 활동 기록 등 열네 가지 조회 대상과 세 가지 계산 호출(차이 요인분해 · 해설 근거 · 에이전트 실행)로 나뉩니다.

자리	무엇	왜 그렇게 두었나
화면 컨트롤	SAP UI5 표준 컨트롤, Horizon 테마	사내 보안 검토에서 반입 라이브러리를 따질 일이 없고 표준 Fiori 화면과 같은 모양으로 읽힙니다.
큐브 집계 로직	브라우저에서 큐브를 다시 묶는 계산 모듈	축을 바꿀 때마다 서버를 다시 부르지 않아 응답이 즉시이고, 모든 축이 같은 큐브에서 나와 합계가 갈라지지 않습니다.
차이 · 해설 계산	서비스 쪽 계산 모듈	금액 · 비율은 서비스가 계산하고 화면은 받아 그리기만 해 계산 위치가 한 곳입니다.
OData 서비스	조회 14종 + 계산 호출 3종, 쓰기는 사유 · 보기 · 에이전트 기록에 한정	조회 조건은 모두 표준 필터로 전달하고, 전체를 뜻하는 값은 조건에서 뺍니다.
차트 · 보고서	직접 그린 SVG 차트, 브라우저에서 만드는 파워포인트 파일	외부 라이브러리와 외부 전송이 없습니다.
테마	SAP Horizon	표준 앱과 시각적 일관성을 맞춥니다.

SAP 표준 기능을 그대로 이어받은 부분 — 지급 문서 라인의 필드 구조 · 회사코드 · 하우스 뱅크 · 통화와 환율 개념 · 자금 계획 그룹 개념은 표준 데이터 구조를 그대로 이어받고, 이 화면은 그 위에서 묶고 비교하고 점검하는 관점을 더합니다.

처음 열었을 때 — 조회 전에도 틀이 먼저 보입니다

화면을 열면 조회를 누르기 전에도 조회조건 · 보는 사람 · 차원 보관함 · 행 축과 열 축 · 피벗 틀이 먼저 뜹니다. 어디에 무엇이 놓이는지 눈으로 익힌 뒤 조회하게 하려는 구성입니다.

**처음 열었을 때 — 조회 전의 틀** — 조회조건과 레이아웃 보드, 비어 있는 피벗 틀이 먼저 보입니다.

조건을 넣고 [조회] 단추(또는 Enter)를 누르면 큐브를 한 번 읽어 옵니다. 기간은 읽을 수 있는 전체 기간이 기본으로 들어 있고, 법인을 비우면 전체 법인입니다. 조회 전에는 숫자가 없다는 점이 분명하도록 틀만 보여 줍니다.

**조회 직후 — 피벗과 차트가 함께** — 지표 카드 다섯 장, 행 축 리스 유형 · 열 축 분기와 측정값, 오른쪽 막대 차트가 한 번에 나옵니다.

기본 배치는 행에 리스 유형, 열에 분기와 측정값입니다. 위 카드는 순지급액 1,542.87억 원, 지연 지급 비중 15.8%, 계획 대비 지급 차이 +29.07억 원처럼 지금 범위의 요약입니다. 표와 차트는 같은 계산 결과를 그리므로 어느 쪽을 봐도 합계가 같습니다.

**조회조건을 펼친 모습 — 법인 · 기간 · 비교 기준** — 법인 · 기간(부터 · 까지) · 비교 기준을 정하고 [조회] 또는 [초기화]를 누릅니다.

법인을 비우면 전체 법인입니다. 기간은 읽을 수 있는 전체 기간이 기본이고, 비교 기준은 지급 계획과 비교가 기본입니다. 조건을 바꾼 뒤 [조회]를 눌러야 큐브를 다시 읽으며, 이후의 축 이동은 다시 읽지 않습니다.

**차원을 끌어다 놓은 뒤** — 지급 은행 · 지급 주기를 행으로, 측정값을 열로 옮긴 모습입니다.

칩을 끌어 놓는 순간 표와 차트가 다시 그려집니다. 서버를 다시 부르지 않고 이미 읽어 온 큐브를 브라우저에서 다시 묶기 때문에 응답이 즉시입니다. 합계는 어느 배치에서도 같아야 하며, 그 검산은 아래 검증 절에 있습니다.

**머리 영역을 접으면** — 조회조건 영역을 접어 표와 차트가 차지하는 면적을 키웁니다.

머리 영역은 접어 둘 수 있습니다. 접어도 조건 요약 한 줄은 남아 지금 어떤 범위를 보고 있는지 잊지 않게 합니다. 회의 때 화면을 크게 띄워 놓고 이야기할 때 쓰는 모습입니다.

경영 요약 — 보는 사람에 따라 앞세우는 숫자가 다릅니다

같은 큐브를 경영 · 재무 · 자금 · 회계 네 관점으로 읽을 수 있습니다. 관점을 고르면 첫 줄 안내와 앞세우는 지표, 기본 행·열 축이 그 사람의 질문에 맞게 바뀝니다.

**경영 관점 — 어느 리스 유형에 지급이 몰렸나** — 전사 리스 지급이 어느 유형에 얼마나 몰려 있는지, 계획에서 벗어난 유형이 어디인지를 봅니다.

행은 리스 유형, 열은 분기입니다. 부동산(사무실 · 창고)이 324.16억 원으로 전체의 63.6%라는 점이 한눈에 들어옵니다. 집중도 지수(4,845)가 카드에 함께 있어 한 유형에 쏠린 정도를 숫자로 말할 수 있습니다.

**재무 관점 — 리스 유형과 법인별 상계 · 변동리스료** — 재무 관점은 리스 유형 · 법인별 순지급액과 상계 · 차감, 변동리스료 비율을 앞세웁니다.

이 관점에서 지급 계획 대비 차이를 함께 보도록 안내합니다. 위 카드의 계획 대비 지급 차이 +29.07억 원(+1.9%)이 첫 단서이고, 아래 표에서 어느 유형 · 법인이 그 차이를 만들었는지 좁혀 갑니다.

**자금 관점 — 은행 · 지급 주기별 지연 비중** — 자금 관점은 은행 · 지급 주기별 순지급액과 기말 미지급 잔액, 지연 지급 비중을 봅니다.

약정 지급일을 넘긴 지급이 어느 은행 · 주기에서 많은지 15% 안팎에서 18%대까지의 비중으로 비교합니다. 은행 이름은 모두 가상입니다. 행을 펼치면 지급 주기별 값이 내려옵니다.

**회계 관점 — 처리 단계와 통화별 지급** — 회계 관점은 처리 단계(이견 보류 후 지급 포함)와 통화별 지급 건수 · 건당 순지급액을 봅니다.

기말 미지급 · 지급 대사 완료 · 이견 보류 후 지급의 세 단계로 나뉘어 합계가 같은 표에 놓입니다. 상계 · 차감과 환율 효과가 장부 정리에 어떻게 닿는지는 차이 모드로 확인합니다. 최종 처리는 표준 화면의 몫이라는 점이 안내에 적혀 있습니다.

축 전환과 범위 — 보고 싶은 단면으로 바로

열을 두 단계로 쌓고, 값을 여러 개 골라 좁히고, 차트 모양과 열 너비를 바꾸는 장면입니다. 모두 이미 읽은 큐브 위에서 일어나 서버를 다시 부르지 않습니다.

**열을 두 단계로 — 분기와 지급 주기** — 열 축에 분기와 지급 주기를 쌓고 측정값을 붙였습니다.

열 머리는 두 줄로 나뉘고 위 줄이 합쳐진 머리가 됩니다. 열이 너무 많아지면 한도를 알려 주므로 의도치 않게 화면이 넓어지는 일이 없습니다.

**값 필터 — 여러 값을 한 번에 고르기** — 차원을 고르고 값을 여러 개 체크해 범위를 좁힙니다.

값 옆에는 그 값이 가진 원천 라인 수가 함께 적혀 있어 어느 값이 큰지 알고 고를 수 있습니다. 한 차원 안에서는 또는, 차원 사이에서는 그리고로 겁니다. 은행 두 곳을 골랐을 때의 합계는 두 은행의 큐브 합계와 같아야 하며 그 검산도 돌려 두었습니다.

**좁힌 결과 — 은행 두 곳** — 필터를 건 뒤의 카드와 표 · 차트입니다.

카드도 좁힌 범위로 다시 계산되어 순지급액이 845.82억 원으로 바뀝니다. 필터가 걸려 있다는 표시가 도구줄에 남아 캡처만 봐도 전체 숫자가 아님을 알 수 있습니다. 필터를 풀면 같은 배치로 전체가 돌아옵니다.

**은행별 비교 — 표와 막대 차트** — 행을 지급 은행으로 놓고 은행 두 곳의 순지급액과 지급 건수를 비교합니다.

차트는 외부 라이브러리 없이 SVG로 직접 그립니다. 사내 보안 심사에서 반입 라이브러리를 따지지 않아도 되는 이유이며, 표의 숫자를 그대로 그린 것이라 표와 어긋날 수 없습니다.

**표와 차트 사이 손잡이** — 표와 차트 사이의 손잡이를 끌어 두 영역의 면적을 나눕니다.

숫자를 읽을 때는 표를, 모양을 볼 때는 차트를 넓게 둡니다. 손잡이 위치도 보기와 함께 저장할 수 있습니다.

칸에서 원천 지급 문서까지 — 숫자를 의심할 때의 길

피벗의 칸을 누르면 그 금액을 만든 지급 문서 라인이 열립니다. 숫자를 의심할 때 다른 화면을 열어 조건을 다시 넣는 일이 없도록 한 길입니다.

**칸을 누르면 — 원천 지급 문서 라인** — 부동산 · 2026년 1분기 칸을 눌러 그 금액을 만든 지급 문서 라인 905건을 엽니다.

머리에 칸의 값 324.16억 원과 원천 합계 324.16억 원, 일치 표시, 라인 수가 함께 적힙니다. 검증 때 14개 칸을 눌러 모두 일치함을 확인했습니다. 표는 CSV로 내려받을 수 있습니다.

**문서 라인 — 통화 · 환율 · 고정 리스료** — 다른 칸(월 지급 · 2026년 1분기)의 문서 라인 704건입니다. 거래통화 금액과 고정 리스료 열이 보입니다.

외화 지급은 거래통화 금액에 지급일 환율을 곱한 원화 값과 대사됩니다. 환율은 가정값이며 실제 고시값이 아닙니다. 지급일 대비(약정 지급일 · 반기 지급 등) 구분도 라인마다 보입니다.

**월별 흐름 — 회계기간별 순지급액과 건당 금액** — 행을 회계기간(지급월)으로 놓고 순지급액 · 지급 건수 · 건당 순지급액을 봅니다.

1월 155.10억 원에서 9월 179.98억 원까지 월별 막대가 함께 그려집니다. 어느 달에 지급이 몰렸는지 먼저 찾고 그 달로 좁혀 내려가는 순서에 맞춘 구성입니다.

**계산항목 — 건당 금액 · 변동리스료 비율 · 지연 비중** — 건당 순지급액, 변동리스료 비율, 지연 지급 비중이 열로 붙습니다.

계산항목은 차원이 아니라 식입니다. 비율은 합쳐서 나누고 평균은 건수로 나눈 값을 쓰기 때문에 행을 합쳐도 비율이 틀어지지 않습니다. 부동산(사무실 · 창고)이 변동리스료 비율 0.56%, 설비 · 기계가 0.71%처럼 유형별 차이가 드러납니다.

지급 계획 대비 차이 — 같은 표가 자금 회의 자료가 됩니다

비교 기준을 지급 계획으로 두면 같은 표에 실적 · 계획 · 차이 · 증감률이 나옵니다. 차이는 일곱 요인으로 나뉘고 사유는 그 행에 남습니다.

**차이 모드 — 실적 · 계획 · 차이 · 증감률** — [계획 차이]를 켜면 실적과 계획을 나란히 놓고 차이와 증감률을 주며 차트는 실적 · 계획 묶음 막대로 바뀝니다.

부동산(사무실 · 창고)의 차이 +16.46억 원(+1.7%)처럼 행마다 차이가 나옵니다. 색은 금액과 비율 임계를 모두 넘는 행에만 칠하며, 점검이 필요하다는 신호일 뿐 원인을 단정하지 않습니다.

**변동 사유 — 차이 난 행에 남기는 기록** — 차이가 난 행(부동산 · +16.46억 원)에 구분과 사유를 적는 창입니다.

구분을 고르고 사유를 적어 저장하면 조회 범위와 행 경로에 묶여 남습니다. 축을 바꿔도, 다음 달에도 따라옵니다. 글자 수 한도가 아래에 보이며 샘플 사유는 가상의 문장입니다.

**차이 워터폴 — 계획에서 실적까지** — 부동산 범위의 워터폴입니다. 계획 965.56억 원에서 요인을 거쳐 실적 982.02억 원에 이릅니다.

저장하면 사유가 있는 행에 연필 표시가 붙고 ‘변동 사유를 저장했습니다’ 알림이 뜹니다. 막대마다 요인 이름과 금액이 붙고 맨 끝 막대가 실적입니다. 행을 고르면 그 행의 범위로 워터폴이 다시 그려집니다.

**요인분해 표 — 총차이가 어디서 났는지** — 차이를 요인별로 가른 표와 아래의 검산 줄입니다(부동산 범위).

고정 리스료 변동 +7.16, 환율 효과 +2.92, 변동리스료 반영 +2.91, 상계 · 차감 +0.26, 지급월 이동 0.00, 계획 외 지급 +20.39, 계획 지급 미발생 −17.17(단위 억 원)입니다. ‘계획 + 요인 합 − 실적 = 0’ 검산 줄이 초록으로 맞음을 알립니다. 서로 반대로 움직이는 두 큰 요인이 가려져 있던 점이 이 표에서 드러납니다.

AI 분석과 보고서 — 숫자는 서비스가, 설명은 그 위에서

금액과 비율은 서비스가 큐브에서 계산하고, 해설은 그 근거 표 위에서만 만듭니다. 근거 표와 함께 보고서까지 한 번에 나옵니다.

**계획 대비 해설 — 현재 범위의 초안** — 기준 차원과 보는 사람을 고르면 범위 요약과 점검 필요 항목을 문장으로 정리합니다.

맨 위에 ‘숫자는 서비스가 계산한 값이며 문장은 규칙으로 만든 초안’이라는 안내가 붙습니다. 이미 사유가 적힌 행은 건너뛰고(‘사유 기재됨’), 설비 · 기계 +9.54억 원처럼 점검이 필요한 행만 짚습니다. 원인은 단정하지 않습니다.

**근거 표 — 문장마다 출처가 있습니다** — 해설 아래에 계획 · 실적 · 차이를 적은 근거 표가 이어집니다.

기타 자산 +1.54억 원, IT 장비 +1.03억 원 같은 문장이 어느 숫자에서 나왔는지 표로 확인할 수 있습니다. 근거가 없는 문장은 만들지 않으며, [보고서 PPTX] 단추로 같은 내용을 보고서로 내려받습니다.

**보고서 내려받기 — 알림과 전체 범위 요인** — 보고서를 내려받으면 ‘보고서를 내려받았습니다’ 알림이 뜹니다. 화면에는 전체 범위의 요인 표가 있습니다.

전체 범위에서는 고정 리스료 변동 +10.99, 환율 효과 +8.35, 변동리스료 반영 +4.63, 상계 · 차감 +0.37, 지급월 이동 0.00, 계획 외 지급 +33.09, 계획 지급 미발생 −28.36(억 원)이 합쳐 +29.07억 원이 됩니다. 외부 라이브러리 없이 브라우저가 파워포인트 파일을 만듭니다.

AI 에이전트 — 사람이 열지 않아도 도는 점검

역할별 규칙을 두고 걸린 것만 대기함으로 올립니다. 하루 한 번만 돌도록 서버가 판정하며, 활동 기록이 남습니다.

**감시 규칙 — 역할마다 지표 · 기준 · 받는 사람** — 규칙 한 줄은 번호 · 규칙 · 조건 · 받는 사람입니다. 대기함은 아직 비어 있습니다.

샘플 값으로 지연 지급 비중 15% 이상(자금), 이견 보류 비중 6% 이상(회계), 순지급액 계획 차이 5억 원 이상(재무), 기말 미지급 잔액 4억 원 이상(경영)을 두었습니다. 기준값은 운영에서 회사가 정합니다. ‘같은 날 두 번째 실행은 서버가 막는다’는 안내가 위에 있습니다.

**대기함 — 걸린 규칙이 올린 보고** — 처음 돌린 결과 3건이 대기함에 올라온 모습입니다.

지연 지급 비중 15.2%, 순지급액 계획 차이 +5.03억 원, 기말 미지급 잔액 4.48억 원이 각각 경고 · 정보 · 알림 수준으로 올라옵니다. 이견 보류 규칙은 걸리지 않았습니다. 아래 실행 이력에는 시각과 호출자, 완료 상태가 남습니다.

**활동 기록 — 같은 날 두 번째는 막힙니다** — 실행 이력에 완료 건과 ‘오늘은 이미 실행했습니다’ 제한 건이 함께 남습니다.

하루에 한 번만 도는 제한은 브라우저가 아니라 서버가 판단합니다. 같은 날 다시 눌러도 새 보고가 생기지 않고 제한 기록만 남아 몇 번 눌렀는지도 확인됩니다.

레이아웃 저장과 복원 — 회의마다 같은 모양으로

배치와 조건, 보기 설정을 이름 붙여 저장하고 기본 보기와 자동 조회를 정할 수 있습니다.

**보기 저장 — 이름을 붙여 남깁니다** — 현재 배치와 조건을 이름과 함께 저장하는 창입니다.

‘다음에 열 때 이 보기로 시작’과 ‘열면 바로 조회’를 고를 수 있고, 저장될 내용(행 · 열 · 측정값)이 요약돼 보입니다. 월 회의용, 은행 점검용처럼 용도별로 만들어 두면 매번 끌어다 놓을 필요가 없습니다.

**보기 관리 — 목록 · 기본값 · 삭제** — 저장한 보기의 목록과 [적용] · [기본으로] · [자동 조회] · [이름 바꾸기] · 삭제 단추입니다.

기본 보기는 하나만 둘 수 있습니다. 서버에 저장되므로 다른 기기에서도 같은 보기를 열 수 있습니다.

**보기 복원 — 저장한 배치로 돌아옵니다** — 보기를 적용하거나 기본 배치로 되돌리면 조건과 배치가 복원됩니다(‘기본 배치로 되돌렸습니다’ 알림).

보기가 담는 것은 설정이지 숫자가 아니어서 복원할 때마다 최신 큐브로 다시 계산합니다. 복원한 뒤의 표 합계는 저장하기 전과 같습니다.

좁은 화면과 한계 — 휴대폰에서 달라지는 것

폭 390px의 휴대폰에서도 표와 차트를 볼 수 있고, 화면이 감당할 수 없는 범위에는 억지로 그리지 않고 안내합니다.

**좁은 화면(390px) — 카드와 차원 보관함** — 조회조건은 한 줄로 접히고 지표 카드가 두 줄로 쌓입니다.

보는 사람 선택과 지표 카드, 차원 보관함이 위에서 아래로 이어집니다. 축 편집은 넓은 화면에서 하는 것을 권하고, 좁은 화면은 숫자를 읽는 용도에 맞췄습니다.

**좁은 화면(390px) — 표 아래에 차트** — 표는 가로로 밀어 보고, 차트는 표 아래로 내려가 한 줄 폭을 씁니다.

좁은 폭에서 표와 차트를 나란히 두면 둘 다 읽을 수 없어 위아래로 쌓았습니다. 표 머리는 고정되어 가로로 밀어도 행 이름이 남습니다.

**범위 상한 안내 — 열이 45개면** — 열 축이 너무 많으면 그리지 않고 줄여 달라고 안내합니다.

열이 45개를 넘으면 표와 차트가 읽을 수 없는 모양이 되어 그리지 않고 열 축을 줄이라는 안내를 띄웁니다. 운영 데이터에서도 같은 상한이 화면을 지킵니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 조건을 표준 필터로 바꿔 큐브와 지급 계획을 한 번씩 읽어 옵니다. 큐브는 서른 개 안팎의 조건 조합이 아니라 차원 조합별로 집계된 행(검증용 데이터에서는 3,112행)이고, 원천 지급 라인 7,288줄이 이 행들로 묶였습니다. 이후 축을 옮기면 화면이 이 행들을 브라우저에서 다시 묶습니다. 칸을 누를 때만 원천 지급 문서 라인을 따로 읽습니다.

차이 요인 판정

총차이(실적 − 계획)는 아래 일곱 요인으로 나뉩니다. 색은 지급이 계획보다 늘어난 방향을 기준으로 하며 금액 · 비율 임계를 모두 넘을 때만 칠합니다. 결과는 원인을 단정하지 않는 ‘점검 필요’ 표시입니다.

요인	판정 조건	결과 표시	사용자 조치
고정 리스료 변동	계획과 같은 지급인데 거래통화 금액이 다름	차이 발생	계약 변경 · 재협상 내용 확인 필요
환율 효과	외화 지급의 지급일 환율이 계획 환율과 다름	차이 발생	환율 기준 · 결제 시점 점검 필요
변동리스료 반영	지수 · 매출 연동 변동분이 지급에 반영됨	차이 발생	산정 기준 자료 확인 필요
상계 · 차감 효과	보증금 · 선급 · 면제 등으로 상계 또는 차감됨	차이 발생	상계 근거 문서 확인 필요
지급월 이동	계획월과 지급월이 다름(앞당김 · 이연)	차이 발생(합계 0 가능)	월간 자금 계획 점검 필요
계획 외 지급	계획에 없던 지급 라인	차이 발생	사유 기재 및 승인 경로 확인 필요
계획 지급 미발생	계획만 있고 실제 지급 없음(해지 · 면제 · 협의 이연)	차이 발생	이연 · 면제 확인 필요

처리 단계는 다음 순서입니다. 지급 라인마다 순지급액 = 고정 리스료 + 변동리스료 − 상계 · 차감을 산출하고, 외화 지급은 거래통화 금액 × 지급일 환율 = 원화 환산으로 통화별로 대사합니다. 서로 다른 통화의 외화 금액은 그대로 더하지 않습니다. 이어서 라인을 차원 조합으로 묶어 큐브를 만들고 큐브 합계와 라인 합계를 기간 × 측정값으로 검산한 뒤, 계획과 맞붙여 요인을 가르고 계획 + 요인 합 − 실적 = 0을 확인합니다.

조회조건

조건	필수	기본값	서비스로 전달
법인(회사코드)	선택	전체	전체면 조건을 만들지 않음 · 선택 시 해당 법인만
기간(부터 · 까지)	필수	조회 가능한 전체 기간	기간 범위 조건으로 전달
비교 기준	선택	지급 계획과 비교	지급 계획 버전을 읽음(없음이면 읽지 않음)
차원 값 선택(값 필터)	선택	없음	브라우저에서 차원 안은 또는, 차원 사이는 그리고로 거름(재조회 없음)
측정값 · 표시 행 수 · 금액 단위	선택	순지급액 · 12행 · 억 원	화면 표시 설정

결과 컬럼

컬럼	의미	산출식
순지급액	실제 지급된 순액(원화)	고정 리스료 + 변동리스료 − 상계 · 차감
고정 리스료 · 변동리스료 · 상계 · 차감	순지급액의 구성 요소	라인 합계
기말 미지급 잔액	마지막 기간 월말 기준 미지급액	마지막 값 사용(기간 합산 금지)
지급 건수 · 건당 순지급액	지급 문서 수와 평균	건당 = 순지급액 ÷ 지급 건수
변동리스료 비율	지급 중 변동분의 비중	변동리스료 ÷ 순지급액
지연 지급 비중	약정 지급일을 넘긴 지급의 비중	지연 순지급액 ÷ 전체 순지급액
실적 · 계획 · 차이 · 증감률	차이 모드의 네 열	차이 = 실적 − 계획, 증감률 = 차이 ÷ 계획

좁은 화면에서 달라지는 것

조회조건은 한 줄로 접히고 지표 카드는 두 줄로 쌓이며 차트는 표 아래로 내려갑니다. 표는 가로로 밀어 보고 머리는 고정됩니다. 열 축이 45개를 넘으면 그리지 않고 열 축을 줄이라고 안내합니다.

파일 구성

제품 폴더
├─ 화면 정의 · 조회조건 · 결과 표 · 차트 · 상세 창
├─ 집계 계산 모듈(큐브 · 계산항목 · 차이)
├─ 조회용 OData 서비스(서비스 정의 · 계산 모듈 · 데이터)
├─ 설명서와 소개 영상
└─ 검증용 샘플 데이터 설정

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 법정 · 감사 · 세무 신고 대응은 표준 화면에 그대로 두고, 이 화면은 월 자금 회의와 점검에 쓰는 분석 관점을 맡습니다.

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

하고 싶은 일	표준 화면으로 되는 일	이 화면이 더하는 관점
계좌별 현금 포지션 확인	자금 포지션 화면에서 계좌 · 일자별 잔액과 예정 지급을 봄	리스료 지급만 따로 묶어 유형 · 은행 · 통화별로 축을 바꿔 봄
유동성 예측과 비교	유동성 예측 화면에서 예측 항목을 봄	지급 계획과 실제 지급을 같은 표에서 비교하고 차이를 일곱 요인으로 가름
은행 명세 대조	은행 명세 후속 처리 화면에서 개별 항목을 처리	차이가 난 행에 사유를 남기고 다음 달로 잇는 기록
지급 문서 라인 조회	계정 라인 조회 화면에서 개별 라인을 봄	피벗의 칸에서 바로 그 칸을 만든 라인을 열고 합계를 대조
자동 지급 실행	자동 지급 프로그램으로 지급을 실행	지급 실행 결과와 지급월 이동 · 지연 비중을 점검

T-code 별 연계 지점

T-code	이름	연계
FF7A	현금 포지션	이 화면의 순지급액 · 기말 미지급 잔액과 자금 포지션의 예정 지급을 같은 기간으로 맞춰 대사합니다. 이 화면에서 칸을 눌러 원천 라인을 확인하고, 포지션 화면의 금액은 이 화면의 같은 은행 · 기간 칸에서 다시 봅니다. 포지션 관리는 표준에 남깁니다.
FF7B	유동성 예측	지급 계획 열과 예측 항목을 비교합니다. 계획 원천을 예측 항목으로 둘지는 도입 시 정하며 확인 필요입니다.
FEBAN	은행 명세 후속 처리	실제 지급 확인 행(이견 보류 후 지급 포함)을 대조합니다. 이 화면은 점검 후 표준 화면으로 이동해 처리하도록 안내하고, 처리 자체는 표준에서 합니다.
FBL3N	계정 라인 아이템	드릴스루로 연 지급 문서 라인을 표준 라인 조회와 같은 조건으로 맞춰 확인합니다. 두 화면의 합계가 같아야 합니다.
F110	자동 지급 실행	지급 실행 결과와 이 화면의 지급월 이동 요인을 맞춰 봅니다. 실행 설정 · 지급 제안은 표준에 남깁니다.

운영 전환 시 기존 표준 리포트를 없앨 필요는 없습니다. 법정 · 감사 대응에 쓰는 표준 리포트는 그대로 두고, 이 화면은 월 회의 · 점검용으로 병행합니다. 두 화면의 숫자가 다르면 먼저 이 화면의 대사 줄(큐브 = 라인 합계)을 보고, 표준 화면과 같은 조건인지 확인하는 순서를 권합니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 도구는 범용 분석에 강합니다. 이 화면은 그 옆에서 리스 지급 자금이라는 하나의 주제를 끝까지 파고드는 자리이며, 같은 CDS 큐브를 뷰 레이어로 두기 때문에 분석 스택과 중복되지 않고 이어집니다. 사용할 수 있는 표준 Fiori 앱의 이름과 범위는 운영 환경에서 확인 필요입니다.

표준 데이터 매핑 — 분석 지표 정의

지표	산식 · 판정 기준	대응 기능	원천 데이터	비고
순지급액	고정 리스료 + 변동리스료 − 상계 · 차감	피벗 · 지표 카드	지급 문서 라인	원화 환산 기준
지연 지급 비중	약정 지급일보다 늦은 지급 ÷ 전체	지표 카드 · 감시 규칙	지급일 대비 구분	점검 필요 기준은 샘플 값
변동리스료 비율	변동리스료 ÷ 순지급액	계산항목	리스 조건	-
기말 미지급 잔액	마지막 기간 월말 미지급	측정값(마지막 값)	미지급 라인	합산 금지
계획 대비 차이	실적 − 계획	차이 모드 · 요인분해	지급 계획 항목	계획 원천 확정은 확인 필요

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

자리	무엇을 손대나	비고
계획 원천	지급 계획을 자금 예정 항목의 어느 버전 · 계획 그룹으로 읽을지	확인 필요
은행 · 계획 그룹 매핑	하우스 뱅크와 자금 계획 그룹을 분석 차원에 연결하는 매핑 표	현업이 직접 관리
리스 유형 · 지급 주기	계약 분류를 분석 차원으로 쓸 필드(확장 필드 · 커스텀 필드)	BAdI 또는 확장 필드로 연결
상계 · 차감 구분	보증금 · 선급 · 면제 등을 상계 종류로 나누는 기준	회계팀과 합의
환율 유형 · 환산 시점	지급일 환율을 쓸지 월말 환율을 쓸지	표준 환율 유형 사용
권한	법인 · 하우스 뱅크 · 계정 단위 권한 오브젝트	집계 단계에 겁니다

CDS 구성 — 뷰 · 권한 · 서비스와 운영에서 할 일

화면이 읽는 데이터는 CDS 뷰 레이어에서 만들어집니다. 아래는 이 화면을 운영 시스템에 올릴 때의 뷰 레이어 설계와 코드 스케치입니다. 실제 필드와 표준 뷰 이름은 고객사 시스템에서 확인 필요이며, 코드는 구조를 보이기 위한 초안입니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	매핑 테이블	하우스 뱅크 · 계획 그룹을 분석 차원 값으로 바꾸는 기준	현업이 개발 없이 고치도록
기초	지급 문서 라인 뷰	헤더 · 라인 · 매핑을 합치고 라인 유형을 정함	큐브와 드릴스루가 같은 원천을 쓰도록
차원	은행 차원 뷰	값에 이름과 정렬을 붙임	코드가 바뀌지 않게 이름을 분리
큐브	실적 큐브 · 계획 큐브	차원 조합별 합계, 외화 환산	모든 축이 같은 합계에서 나오게
쿼리	분석 쿼리	필터 · 행 · 열 후보와 측정값 선언	화면 요구를 이 층에서만 바꾸게
권한	접근 제어(DCL)	회사코드 단위로 집계 전에 거름	남의 숫자가 합계로 새지 않게
서비스	서비스 정의 · 바인딩	OData 로 게시	화면 설정과 짝을 맞춤

① 매핑 테이블 — 하우스 뱅크와 자금 계획 그룹을 분석 차원에 잇는 기준

이 표가 은행 · 계획 그룹을 분석 차원으로 바꿉니다. 코드로 박아 두지 않고 표로 둔 이유는 매핑이 바뀔 때 개발이 아니라 현업이 고치기 위해서입니다. 매핑이 빠진 하우스 뱅크는 ‘미분류’로 떨어져 합계에는 남고 차원에서만 따로 보입니다.

"──────────────────────────────────────────────────────────────
" ZLPC_BANKMAP : 하우스 뱅크 → 분석 차원(은행 구분 · 자금 계획 그룹)
" 역할   : 분석 차원 값을 개발 없이 현업이 바꾸도록 표로 둔다
" 나눈 이유: 하우스 뱅크 코드는 회사마다 다르고 계획 그룹도 자주 바뀐다
"──────────────────────────────────────────────────────────────
@EndUserText.label : '리스 지급 은행 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zlpc_bankmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key hbkid      : hbkid not null;
  bank_group     : abap.char(10);   " 은행 구분(분석 차원 값)
  plan_group     : abap.char(10);   " 자금 계획 그룹
  valid_from     : abap.dats;
  valid_to       : abap.dats;
}

② 기초 뷰 — 지급 문서 라인을 한 줄 한 줄 정리

원천 지급 문서의 헤더와 라인을 이어 붙이고 매핑을 붙이는 층입니다. 이 층에서 라인 유형(정상 · 계획 외 · 지급월 이동 · 월말 미지급)과 약정 지급일 대비 구분을 정합니다. 집계는 하지 않으므로 라인 합계 = 원천 합계가 이 층에서 보장돼야 합니다. 원천 테이블 정확한 필드는 고객사 구성에서 확인 필요입니다.

"──────────────────────────────────────────────────────────────
" ZI_LeaseCashItem : 지급 문서 라인(집계 전)
" 역할   : 헤더 + 라인 + 매핑을 합치고 라인 유형 · 지급일 대비를 정한다
" 나눈 이유: 라인 단위 사실을 한 곳에 두면 큐브와 드릴스루가 같은 원천을 쓴다
"──────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스 지급 문서 라인'
define view entity ZI_LeaseCashItem
  as select from bkpf as h
    inner join   bseg as i  on  i.bukrs = h.bukrs
                            and i.belnr = h.belnr
                            and i.gjahr = h.gjahr
    left outer join zlpc_bankmap as m on  m.bukrs = i.bukrs
                                      and m.hbkid = i.hbkid
{
  key h.bukrs                  as CompanyCode,
  key h.gjahr                  as FiscalYear,
  key h.belnr                  as DocumentNumber,
  key i.buzei                  as ItemNumber,
      h.budat                  as PostingDate,
      i.hbkid                  as HouseBank,
      coalesce( m.bank_group, 'UNMAPPED' ) as BankGroup,
      coalesce( m.plan_group, 'UNMAPPED' ) as PlanGroup,
      h.waers                  as TransactionCurrency,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      i.wrbtr                  as FxAmount,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      i.dmbtr                  as LocalAmount,
      h.hwaer                  as CompanyCurrency,
      case when h.budat > i.zfbdt then 'LATE' else 'ON_TIME' end as TimingKind
}

③ 차원 뷰 — 이름과 정렬을 붙입니다

차원 값에 읽을 수 있는 이름과 정렬 순서를 붙이는 층입니다. 화면의 차원 값 필터와 칩 이름이 여기서 나옵니다. 텍스트 연결을 빠뜨리면 코드만 보이므로 운영에서 가장 먼저 확인합니다.

"──────────────────────────────────────────────────────────────
" ZI_LeaseCashBank : 은행 차원(코드 + 이름 + 정렬)
" 역할   : 은행 구분 값에 이름 · 순서를 붙인다
" 나눈 이유: 차원 값은 이름이 바뀌어도 코드는 바뀌지 않아야 한다
"──────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'BankGroup'
@EndUserText.label: '리스 지급 은행 차원'
define view entity ZI_LeaseCashBank
  as select distinct from zlpc_bankmap
{
      @ObjectModel.text.element: ['BankGroupText']
  key bank_group  as BankGroup,
      bank_group  as BankGroupText,
      plan_group  as PlanGroup
}

④ 큐브 — 차원 조합으로 묶고 원화로 환산합니다

화면 피벗의 원천입니다. 지급 라인을 차원 조합으로 묶어 순지급액을 합산하고, 외화는 지급일 환율로 원화 환산합니다. 이 합계가 원천 라인 합계와 어긋나지 않는지가 검증의 핵심입니다. 환산은 라인 단위로 한 뒤 더합니다. 합계를 먼저 더하고 환산하면 환율이 다른 라인이 섞여 값이 틀어집니다.

"──────────────────────────────────────────────────────────────
" ZI_LeaseCashCube : 리스 지급 큐브(실적)
" 역할   : 차원 조합별 순지급액 · 건수 · 환산 원화 합계
" 나눈 이유: 모든 분석 축이 같은 큐브에서 나오게 해 합계가 갈라지지 않게 한다
"──────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '리스 지급 큐브'
define view entity ZI_LeaseCashCube
  as select from ZI_LeaseCashItem as it
  association [0..1] to ZI_LeaseCashBank as _Bank on $projection.BankGroup = _Bank.BankGroup
{
  key it.CompanyCode,
  key substring( cast( it.PostingDate as abap.char(8) ), 1, 6 ) as Period,
  key it.BankGroup,
  key it.TimingKind,
  key it.TransactionCurrency,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      @DefaultAggregation: #SUM
      sum( currency_conversion(
             amount             => it.FxAmount,
             source_currency    => it.TransactionCurrency,
             target_currency    => cast( 'KRW' as abap.cuky ),
             exchange_rate_date => it.PostingDate,
             exchange_rate_type => 'M',
             error_handling     => 'SET_TO_NULL' ) )           as NetPaidKrw,
      cast( 'KRW' as abap.cuky )                                as LocalCurrency,
      @DefaultAggregation: #SUM
      count( * )                                                as DocumentCount,
      _Bank
}
group by it.CompanyCode,
         substring( cast( it.PostingDate as abap.char(8) ), 1, 6 ),
         it.BankGroup, it.TimingKind, it.TransactionCurrency

⑤ 계획 큐브 — 실적과 같은 차원으로

지급 계획을 실적과 같은 차원 조합으로 묶습니다. 차원이 하나라도 어긋나면 차이 계산이 틀어지므로 실적 큐브의 키와 이름까지 같게 둡니다. 계획의 원천(자금 예정 항목의 버전 · 계획 그룹)은 도입 시 정하며 확인 필요입니다.

"──────────────────────────────────────────────────────────────
" ZI_LeaseCashPlan : 리스 지급 계획 큐브
" 역할   : 계획 금액을 실적 큐브와 같은 키로 묶는다
" 나눈 이유: 실적과 계획의 키가 같아야 차이 · 요인분해가 한 줄로 이어진다
"──────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '리스 지급 계획 큐브'
define view entity ZI_LeaseCashPlan
  as select from fdes as f
{
  key f.bukrs                                      as CompanyCode,
  key substring( cast( f.datum as abap.char(8) ), 1, 6 ) as Period,
  key f.grupp                                      as PlanGroup,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      @DefaultAggregation: #SUM
      sum( f.wrshb )                               as PlanAmount,
      f.dispw                                      as LocalCurrency
}
group by f.bukrs, substring( cast( f.datum as abap.char(8) ), 1, 6 ), f.grupp, f.dispw

⑥ 분석 쿼리 — 화면이 읽는 모양

큐브를 화면이 읽는 모양으로 내놓는 층입니다. 어떤 필드가 필터이고 어떤 필드가 행 · 열 후보인지, 어떤 측정값을 쓸지를 선언합니다. 화면의 차원 보관함은 여기 선언된 차원을 기준으로 구성됩니다.

"──────────────────────────────────────────────────────────────
" ZC_LeaseCashQuery : 화면용 분석 쿼리
" 역할   : 필터 · 행 · 열 후보와 측정값을 선언한다
" 나눈 이유: 큐브는 재사용하고 화면 요구는 이 층에서만 바꾼다
"──────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스 지급 분석 쿼리'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZC_LeaseCashQuery
  as projection on ZI_LeaseCashCube
{
      @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
      @AnalyticsDetails.query.axis: #ROWS
  key Period,
      @Consumption.filter.selectionType: #SINGLE
      @AnalyticsDetails.query.axis: #FREE
  key CompanyCode,
      @AnalyticsDetails.query.axis: #FREE
  key BankGroup,
      @AnalyticsDetails.query.axis: #FREE
  key TimingKind,
      @AnalyticsDetails.query.axis: #FREE
  key TransactionCurrency,
      @AnalyticsDetails.query.axis: #COLUMNS
      NetPaidKrw,
      @AnalyticsDetails.query.axis: #COLUMNS
      DocumentCount
}

⑦ 권한(DCL) — 집계 단계에서 거릅니다

권한은 드릴스루에만 걸면 안 됩니다. 합계에서 자기 몫을 뺀 값으로 남의 숫자가 드러날 수 있기 때문에 큐브 단계에서 회사코드 단위로 걸어 집계 전에 거릅니다. 하우스 뱅크나 계정 단위 권한이 필요하면 같은 방식으로 조건을 더합니다.

"──────────────────────────────────────────────────────────────
" ZI_LeaseCashCube 의 접근 제어 : 회사코드 단위
" 역할   : 조회자의 회사코드 권한만 집계에 포함한다
" 나눈 이유: 집계 후 거르면 합계의 차이로 남의 숫자가 새어 나간다
"──────────────────────────────────────────────────────────────
@EndUserText.label: '리스 지급 큐브 권한'
@MappingRole: true
define role ZI_LeaseCashCube {
  grant select on ZI_LeaseCashCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩 — 화면이 부르는 주소

화면이 호출하는 서비스를 정의하고 OData V2 로 게시합니다. 서비스 활성화와 화면 설정의 서비스 주소 교체는 운영 이관 때 한 번 하는 일이며, 바인딩 종류(V2 · V4)는 화면과 맞춰야 합니다.

"──────────────────────────────────────────────────────────────
" ZUI_LEASECASH_SD / ZUI_LEASECASH_B : 서비스 정의와 바인딩
" 역할   : 분석 쿼리와 차원 · 계획 큐브를 서비스로 내놓는다
" 나눈 이유: 서비스 이름은 화면 설정(manifest)과 짝이어야 한다
"──────────────────────────────────────────────────────────────
@EndUserText.label: '리스 지급 자금 분석 서비스'
define service ZUI_LEASECASH_SD {
  expose ZC_LeaseCashQuery as CashQuery;
  expose ZI_LeaseCashPlan  as CashPlan;
  expose ZI_LeaseCashBank  as Bank;
}
" 바인딩: 이름 ZUI_LEASECASH_B · 바인딩 유형 OData V2 - UI · 게시 후 서비스 활성화

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영 연결 전에 합의해 둘 항목입니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
은행 · 계획 그룹 매핑	하우스 뱅크를 어느 은행 구분 · 계획 그룹으로 묶을지	미분류가 많아 은행별 표가 의미를 잃습니다	자금팀
계획 원천 확정	지급 계획을 자금 예정 항목의 어느 버전으로 읽을지	‘계획이 왜 이 숫자냐’가 반복됩니다	자금팀 · 기획팀
환율 유형 · 환산 시점	지급일 환율인지 월말 환율인지	표준 화면과 원화 금액이 어긋납니다	회계팀
상계 · 차감 구분 기준	보증금 · 선급 · 면제를 어떤 종류로 나눌지	상계 요인이 기타로 몰립니다	회계팀
리스 유형 · 지급 주기 필드	계약 분류를 가져올 확장 필드	차원이 비어 유형별 분석이 안 됩니다	IT · 회계팀
부호 규칙	지급을 양수로 볼지, 환입(반환)을 어떻게 볼지	차이 방향이 헷갈립니다	자금팀
권한 설계	회사코드 · 하우스 뱅크 단위 권한	남의 법인 숫자가 보입니다	보안 · 권한 담당
성능 기준	조회 기간 상한 · 큐브 집계 위치	조회가 느려 회의에서 못 씁니다	IT
대사 체계	표준 화면과 맞출 항목 · 주기	두 화면의 숫자가 다를 때 어디부터 볼지 모릅니다	회계팀 · 자금팀
전송(TR) 순서	매핑 → 뷰 → 권한 → 서비스 순	의존 오브젝트 오류로 이관이 막힙니다	IT
서비스 활성화 · 주소 교체	서비스 게시와 화면 설정의 서비스 주소	화면이 샘플 데이터를 읽습니다	IT
점검 규칙 기준값	지연 비중 · 계획 차이 · 미지급 한도	샘플 기준이 그대로 운영에 남습니다	자금팀 · 재무

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

리스 지급 점검에서 가장 비싼 질문은 ‘이 숫자 맞아?’입니다. 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌린 결과이며, 도입 포인트의 사례와 같은 숫자입니다.

대사식	검사 건수	최대 차이
지급 라인: 고정 리스료 + 변동리스료 − 상계 · 차감 = 순지급액	7,288줄	0원
외화 지급: 거래통화 금액 × 지급일 환율 = 원화 환산	6,767줄	1원 이내(환산 단수)
큐브 합계 = 원천 라인 합계(기간 × 측정값)	45건	0원
계획 + 요인 합 − 실적 = 0 (조회 범위 9개 조합)	9건	0원
어떤 축 배치에서도 피벗 총합 = 큐브 총합 (6가지 배치)	6건	0원
칸 금액 = 드릴스루 문서 라인 합계	14칸	0원
다중 선택 필터 후 합계 = 선택 값들의 큐브 합(은행 2곳)	1건	0원
워터폴: 계획 + Σ요인 = 실적	9건	0원

점검용으로 일부러 넣은 예외 구성은 아래와 같고, 화면은 이를 차이 요인과 미지급 잔액으로 따로 보여 줍니다.

의도적 예외(점검용 샘플 구성)	건수	설명
계획 외 지급	239줄	계획에 없던 지급 — 요인 ‘계획 외 지급’
계획 지급 미발생	207줄	계획만 있고 지급 없음 — 요인 ‘계획 지급 미발생’
지급월 이동	310줄	계획월과 지급월이 다름 — 요인 ‘지급월 이동’
월말 미지급	314줄	기말 미지급 잔액으로 별도 집계

운영 데이터로 갈 때

검증용 데이터는 원천 라인 7,288줄이지만 운영 데이터는 수십만 줄에서 수백만 줄이 될 수 있습니다. 큐브 집계는 CDS 단계에서 하고, 조회 기간을 필수 조건으로 두며, 하우스 뱅크 · 지급일 · 회사코드에 인덱스(또는 앞단 집계 테이블)를 검토합니다. 원천 라인은 칸을 눌렀을 때만 읽도록 하고 한 번에 읽는 수에 상한을 둡니다. 응답 시간의 목표는 큐브 조회 몇 초, 드릴스루 1초 안팎을 기준으로 시작하되 운영 환경에서 실측해 정합니다(확인 필요).

자주 묻는 질문

도입을 검토하시는 분들이 자주 물으시는 질문을 주제별로 정리했습니다.

숫자와 산식

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

라인마다 고정 리스료 + 변동리스료 − 상계 · 차감으로 계산한 값을 원화로 환산해 더합니다. 검증용 데이터 7,288줄 전부에서 이 식과 라인 값의 차이는 0원이었습니다. 지급 건수와 건당 순지급액은 순지급액을 지급 문서 수로 나눈 값입니다.

외화 지급은 어떻게 원화로 바꿉니까?

거래통화 금액에 지급일 환율을 곱해 라인마다 환산한 뒤 더합니다. 합계를 먼저 더하고 환산하면 환율이 다른 라인이 섞여 값이 틀어지기 때문입니다. 검증용 외화 지급 6,767줄에서 환산 차이는 최대 1원(환산 단수)이었고 환율은 가정값입니다.

운영에서는 어떤 환율 유형을 쓸지 먼저 정해야 하며, 표준 화면과 같은 유형으로 맞추는 것을 권합니다.

차이는 어떤 요인으로 나뉩니까?

고정 리스료 변동 · 환율 효과 · 변동리스료 반영 · 상계 · 차감 효과 · 지급월 이동 · 계획 외 지급 · 계획 지급 미발생 일곱 가지입니다. 검증용 데이터에서 전체 범위의 총차이 +29.07억 원은 +10.99, +8.35, +4.63, +0.37, 0.00, +33.09, −28.36(억 원)으로 나뉩니다. 계획 + 요인 합 − 실적은 항상 0이어야 하며 화면이 매번 보여 줍니다.

차이가 양수인데 색이 칠해지지 않는 행이 있습니다.

정상입니다. 색은 금액과 비율 임계를 모두 넘을 때만 칠합니다. 작은 차이에 눈이 가지 않게 하려는 장치이며 임계값은 조회 설정에서 바꿀 수 있습니다(금액 기준 · 비율 기준). 색은 점검이 필요하다는 신호일 뿐 원인을 단정하지 않습니다.

기말 미지급 잔액을 기간으로 합산해도 됩니까?

안 됩니다. 잔액은 시점 값이라 마지막 기간의 값을 씁니다. 화면은 이 측정값에 ‘마지막 값’ 규칙을 적용해 기간 열을 합쳐도 잔액이 부풀지 않게 합니다.

계획이 없는 기간에는 어떻게 보입니까?

계획이 없는 행은 계획을 0으로 두고 차이를 계산하므로 실적 전체가 차이가 됩니다. 이 경우 계획 원천이 비어 있는지 먼저 확인하는 것이 좋으며, 계획 원천 확정은 도입 때 정할 일입니다.

화면과 조작

조회하지 않으면 아무것도 안 보입니까?

조회 전에도 조회조건 · 보는 사람 · 차원 보관함 · 피벗 틀은 보입니다. 숫자는 [조회]를 눌러야 나옵니다. 조건을 바꾸고 조회하지 않으면 이전 결과가 남아 있으므로 조건 요약 줄로 어떤 범위의 숫자인지 확인하시기 바랍니다.

축을 바꿀 때마다 서버를 부릅니까?

부르지 않습니다. 조회 때 큐브를 한 번 읽고 이후에는 브라우저에서 다시 묶습니다. 응답이 즉시인 이유이며, 어느 배치에서도 합계가 같다는 것을 여섯 가지 배치로 검증했습니다.

행은 몇 단계까지 놓을 수 있습니까?

행 3단계, 열 2단계까지입니다. 한도를 넘기면 안내가 뜹니다. 열이 45개를 넘는 경우에는 표와 차트가 읽을 수 없게 되므로 그리지 않고 열 축을 줄이라고 안내합니다.

칸 금액과 원천 지급 문서 합계가 다르면 어떻게 합니까?

다를 수 없도록 큐브가 문서 라인을 더해 만든 값입니다. 화면은 칸 금액과 문서 합계의 일치 여부를 머리에 표시하고, 검증 때 14개 칸에서 모두 일치했습니다. 만약 운영에서 다르게 나오면 큐브 조건과 문서 조건이 같은지부터 확인합니다.

변동 사유는 누가 언제 적었는지 남습니까?

남습니다. 사유는 조회 범위와 행 경로에 묶여 저장되고 보는 사람 역할과 저장 시각이 함께 기록됩니다. 축을 바꿔도 같은 행에 따라오고 다음 달 조회에도 이어집니다.

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

폭 390px에서 표와 차트를 볼 수 있도록 구성했습니다. 조회조건은 접히고 지표 카드가 두 줄로 쌓이며 차트는 표 아래로 내려갑니다. 축 편집은 넓은 화면에서 하는 것을 권합니다.

분석 기능

해설은 숫자를 직접 만듭니까?

만들지 않습니다. 금액과 비율은 서비스가 큐브에서 계산하고 문장은 그 근거 표 위에서 규칙으로 만든 초안입니다. 모든 문장 뒤에 근거 표가 붙고 원인은 단정하지 않습니다. 언어 모델을 연결할지는 도입 때 정하며 확인 필요입니다.

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

역할별 규칙(자금 · 회계 · 재무 · 경영)을 하루에 한 번 점검해 걸린 항목을 대기함에 올립니다. 샘플 규칙은 지연 지급 비중 15% 이상, 이견 보류 비중 6% 이상, 순지급액 계획 차이 5억 원 이상, 기말 미지급 잔액 4억 원 이상이고 처음 돌린 결과 규칙 4개 중 3개가 걸렸습니다. 기준값은 회사가 정합니다.

에이전트가 같은 날 두 번 돌 수 있습니까?

돌 수 없습니다. 하루 한 번 제한은 브라우저가 아니라 서버가 판단하고, 두 번째 요청은 제한 상태로 기록됩니다.

파워포인트 보고서는 어떻게 만들어집니까?

브라우저가 표와 차트를 담은 파일을 만들어 내려받게 합니다. 외부 라이브러리와 외부 전송이 없습니다. 쪽 구성과 문구를 다듬는 일은 담당자가 하며, 결재용 자료의 최종 내용은 회사가 책임집니다.

저장한 보기는 무엇을 담습니까?

축 배치, 조회 조건, 측정값, 차트와 너비 설정을 담고 숫자는 담지 않습니다. 복원할 때마다 최신 큐브로 다시 계산합니다. 기본 보기와 자동 조회를 정할 수 있습니다.

도입과 운영

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

검증용 데이터 기준으로 합계 +29.07억 원의 차이가 계획 외 지급 +33.09억 원과 계획 지급 미발생 −28.36억 원이 서로 가리고 있었다는 점이 한 화면에서 드러났습니다. 시간 절감률 같은 효과 수치는 회사마다 달라 말씀드리지 않으며, 도입 전후 월 회의 준비 시간을 비교해 보시기를 권합니다.

누가 쓰는 화면입니까?

자금팀(지연 비중 · 은행별 점검), 회계팀(상계 · 환율 · 이견 보류), 재무팀(계획 대비 차이), 경영진(요약 지표)이 같은 큐브를 각자의 관점으로 봅니다. 관점마다 앞세우는 지표와 기본 축이 다릅니다.

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

표준 실행은 표준 T-code 가 담당합니다. 현금 포지션(FF7A) · 유동성 예측(FF7B) · 은행 명세 후속 처리(FEBAN) · 계정 라인 조회(FBL3N) · 자동 지급(F110)과 맞춰 볼 지점을 정해 두었으며 이 화면은 조회 · 검증 관점을 더합니다. 기존 표준 리포트를 없애실 필요는 없습니다.

운영 시스템에 연결하려면 무엇이 필요합니까?

CDS 뷰 레이어(큐브 · 계획 · 쿼리 · 권한) 생성, 은행 · 계획 그룹 매핑, 서비스 게시와 화면 설정의 서비스 주소 교체, 권한 설계가 필요합니다. 소요 기간은 매핑과 계획 원천 합의에 크게 좌우되며 코딩보다 합의가 오래 걸리는 경우가 많습니다. 구체적인 기간은 시스템을 본 뒤 정해야 하며 확인 필요입니다.

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

회사코드 단위 권한을 큐브 단계에서 겁니다. 드릴스루에만 걸면 합계 차이로 남의 숫자가 드러날 수 있어 집계 전에 거릅니다. 화면은 표준 컨트롤만 쓰고 외부 라이브러리를 반입하지 않습니다.

운영 데이터가 아주 많으면 어떻게 됩니까?

큐브 집계는 CDS 단계에서 하고 조회 기간을 필수로 둡니다. 원천 라인은 칸을 눌렀을 때만 읽고 읽는 수에 상한을 둡니다. 실제 응답 시간은 운영 환경에서 실측해야 합니다.

계정이나 매핑이 바뀌면 화면을 고쳐야 합니까?

매핑 표만 고치면 됩니다. 새 하우스 뱅크나 새 계획 그룹은 매핑 표에 한 줄을 더하면 차원에 나타납니다. 매핑이 없는 값은 ‘미분류’로 떨어져 합계에는 남습니다.

이 화면의 숫자로 회계 · 세무 처리를 해도 됩니까?

점검 도구이며 최종 판단은 회사와 감사인이 합니다. 세무 신고는 회사와 세무 대리인이 판단합니다. 이 화면의 ‘점검 필요’ 표시는 원인을 단정하지 않고 확인할 곳을 가리킵니다.

적용할 수 있는 기준서나 범위는 어디까지입니까?

이 화면은 리스료 지급 자금의 계획 대비 점검이 대상 영역입니다. 리스 회계 기준서의 요구사항과 어떻게 연결할지는 회사의 회계 정책에 따라 달라 확인 필요이며, 이 글은 기준서 조문을 인용하거나 해석하지 않습니다.