차입금 상환 이행 다차원 분석 — 약정 대비 상환 차이와 대주 쏠림, 금리 노출을 한 화면에서 점검하는 자금 리포트

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

차입금 상환 점검 회의의 질문은 늘 비슷합니다. 이번 달 상환은 약정 일정대로 나갔나, 어느 대주에게 원리금이 몰려 있나, 변동금리 이자가 얼마나 되나. 지금 이 세 답은 약정서의 상환 일정표, 은행 명세서의 실제 출금, 차입금 이자 계산 엑셀에 흩어져 있어서 회의 전에 사람이 붙여야 합니다. 이 앱은 세 답을 한 화면에 붙여, 상환 현황을 다시 만드는 손일을 줄이고 “어느 숫자가 맞나” 하는 확인 시간을 줄입니다.

관련 기준서는 두지 않았고 대상 영역은 자금입니다. 화면은 분류·집계·대사를 돕는 점검 도구이며, 금리 유형과 약정 일정은 검증용 샘플 데이터의 가정값입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(가상 차입 법인 4곳, 가상 대주 7곳, 차입 계약 350건, 2026년 1~9월)에서 상환 원금은 15,194.46억 원이고 약정 일정은 15,462.69억 원이어서 268.23억 원(1.7%) 적게 상환되었습니다. 이 차이를 요인분해로 가르면 약정 초과 상환 +163.22억, 약정 미달 상환 −410.61억, 환율 +21.58억, 상환 시점 이동 +2.87억, 계획 외 조기 상환 +1,014.05억, 상환 유예·연장 −1,059.33억이 나옵니다. 합계가 작아 보여도 안쪽에서는 1,000억 원이 넘는 두 요인이 서로 상쇄하고 있다는 것이 그 자리에서 드러납니다. 한편 한 대주(가상 시중은행 A)가 원리금의 37.8%를 차지해 대주 집중도 지수는 2,207이고, 이자의 46.6%는 변동금리 차입에서 나옵니다. 큐브와 원천 라인의 대사 45건, 대주×기간 셀 63건은 차이가 0건입니다.

도입하면 달라지는 것

• 상환 점검 자료 준비 — 약정 대비 차이·대주 쏠림·금리 노출이 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”보다 “어느 대주와 일정을 협의할까”를 이야기합니다.
• 다음 달로 이어지는 기록 — 변동 사유와 보기 배열이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 아무도 화면을 열지 않아도 감시 규칙에 걸린 항목이 대기함에 올라옵니다.

이런 회사에 맞습니다

여러 금융기관과 사채 투자자로부터 운영자금·시설자금·무역금융·매출채권 담보대출을 나눠 빌리고, 법인 여러 곳과 외화 차입을 함께 운영하며, 고정·변동금리가 섞인 차입 구성을 월 단위로 약정 일정과 맞춰 보고하는 자금 조직에 맞습니다. 대주가 수 곳 이상이고 통화가 둘 이상이며 상환 방식이 분할·만기 일시·수시로 섞여 있는 회사라면 효과가 커집니다.

실행 화면

사용 방법

1. 조회조건 입력 — 차입 법인(선택, 비우면 전체), 기간(부터·까지, 필수), 비교 기준(약정 일정 버전)을 고릅니다. 기본값은 전체 차입 법인, 2026년 01월~09월, 약정 일정(P0)과 비교입니다.
2. 조회 — 조건 오른쪽 위의 [조회] 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 조회 직후 조건 영역은 한 줄 요약으로 접힙니다.
3. 요약 확인 — 표 위 KPI 다섯 개(상환 원금, 최대 대주 원리금 비중, 평균 조달 금리, 변동금리 이자 비중, 약정 대비 상환 차이)를 먼저 봅니다.
4. 보는 사람과 축 이동 — 경영·재무·자금·회계 순서로 눌러 역할별 배열을 보고, 차원 보관함의 차원을 끌어 행 축·열 축에 놓습니다.
5. 칸·행 클릭 — 칸을 누르면 원천 상환 라인이 열리고, 약정 차이를 켠 상태에서 행을 고르면 요인분해 워터폴이 나옵니다.
6. 내려받기 — [CSV]로 현재 표를, 원천 라인 창의 [CSV]로 그 칸의 라인을, 해설 창의 [보고서 PPTX]로 검토 자료를 받습니다.

무엇으로 만들었나

화면은 실제 브라우저에서 검증용 샘플 데이터로 찍었습니다. 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 대주·법인·계약은 모두 가상 값입니다.

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

화면을 열면 조회조건과 차원 보관함, 행 축·열 축 틀이 먼저 보입니다. 조회를 누르면 같은 틀이 숫자로 채워지고 KPI와 차트가 함께 나타납니다.

차입 법인·기간·비교 기준을 고르는 줄과 [조회] 버튼이 맨 위에 있고, 표와 차트는 “조회 조건을 정하고 [조회]를 누르면 표가 채워집니다” 안내만 보입니다. 기본값은 전체 차입 법인, 2026년 01월~09월, 약정 일정(P0)과 비교이며, 행 축에는 대주·차입 유형, 열 축에는 분기가 미리 놓여 있습니다.

합계 상환 원금 15,194.46억 원이 분기별로 3,891.97 · 6,120.60 · 5,181.89억 원으로 나뉘고, 대주 일곱 곳이 행으로 펼쳐집니다. KPI는 최대 대주 원리금 비중 37.8%(가상 시중은행 A, 집중도 지수 2,207), 평균 조달 금리 4.09%, 변동금리 이자 비중 46.6%, 약정 대비 상환 차이 −268.23억 원(−1.7%)입니다. 금리 유형은 가정값이라 KPI 아래에 그렇게 적습니다.

차원 보관함의 알약을 끌어 행 축이나 열 축에 놓고 ×로 뺍니다. 행은 최대 세 단계, 열은 두 단계까지 쌓이고, 바꿔도 서버를 다시 부르지 않습니다. 표 행이 길면 [모두 펼치기]·[모두 접기]로 한 번에 여닫습니다.

경영 요약 — 보는 사람에 따라 달라지는 배열

같은 큐브를 경영·재무·자금·회계 관점으로 바꿔 보는 버튼입니다. 데이터는 그대로이고 행·열·측정값 배열과 한 줄 안내만 달라지므로, 회의에서 질문하는 사람이 바뀌어도 화면을 새로 만들 필요가 없습니다.

재무 관점을 누르면 차입 유형과 법인이 행으로, 상환 원금·이자 지급·평균 조달 금리가 측정값으로 놓입니다. 위쪽 KPI는 그대로라서 어느 관점에서 보든 같은 합계에서 출발한다는 것을 바로 확인할 수 있습니다.

대주와 통화를 행으로, 상환 원금·기말 잔액·변동금리 잔액 비중을 열로 놓은 배열입니다. 약정 차이가 켜져 있으면 실적·약정·차이·차이율이 함께 나옵니다. 기말 잔액 합계는 30,313.70억 원, 약정 일정 기준은 29,859.42억 원입니다.

상환 방식과 대주를 행으로 놓아 원금과 이자 지급이 원천 라인과 맞는지 보기 쉬운 배열입니다. 계획 외 조기 상환과 유예 건처럼 점검이 필요한 라인이 어느 방식에서 나오는지도 이 배열에서 먼저 보입니다.

축 전환과 범위 — 열 두 단계, 값 필터, 기간 축

열 축을 두 단계로 쌓고, 차원마다 값을 여러 개 골라 범위를 좁히고, 기간 축을 월로 바꿔 흐름을 보는 화면들입니다. 어떻게 바꿔도 위쪽 합계 15,194.46억 원은 범위가 같으면 그대로입니다.

행은 통화, 열은 상환 방식 아래 대주를 겹친 배열입니다. 통화별 합계는 KRW 11,438.93 · USD 1,492.62 · EUR 1,202.00 · JPY 1,060.92억 원이고 합치면 15,194.47억 원으로, 표시 반올림 때문에 합계 15,194.46과 0.01억 원 차이만 보입니다(원 단위로는 일치). 차트는 행 축 기준으로 그려집니다.

[값 필터]를 누르면 차원을 고르고 그 차원의 값을 체크박스로 여러 개 고르는 창이 열립니다. 값마다 이름·코드·원천 라인 수가 함께 보여서 라인이 많은 대주부터 좁힐 수 있습니다. [적용]을 누르면 서버를 다시 부르지 않고 큐브에서 다시 묶으며, [선택 지우기]로 되돌립니다.

열에 회계기간과 측정값을 놓아 1월 상환 원금 884.57억 원, 원리금 상환액 1,039.71억 원, 상환 비중, 평균 조달 금리 4.07%를 대주별로 봅니다. 1월에는 가상 시중은행 A가 상환 원금 508.77억 원으로 대주별 비중 57.52%를 차지합니다. 월을 하나씩 넘겨 가며 대주별 상환이 몰리는 달을 찾습니다.

칸에서 원천 상환 라인까지

표의 칸이나 행을 누르면 그 칸의 조건 그대로 월별 상환 라인이 창으로 열립니다. 창 위쪽에는 표의 값과 라인 합계가 나란히 보이고, 같으면 “표의 값과 일치”가 뜹니다.

가상 외국계은행 D의 매출채권 담보대출 칸을 누른 모습입니다. 표의 값 927.79억 원과 원천 합계 927.79억 원이 같아 “표의 값과 일치”가 표시되고 라인은 186건입니다. 라인마다 상환일·문서·차입 법인·대주·차입 유형·통화·외화 상환 원금·환율·금리·원화 상환 원금·이자 지급이 보이고, 외화 건은 상환일 월 환율로 원화 환산한 값이 더해집니다. [CSV]로 그 라인만 내려받습니다.

계산 항목 — 원리금 상환액과 평균 조달 금리

회계 장부에 전기되지 않는 단계는 계산 항목으로 정의합니다. 계산 항목은 측정값처럼 열로 세울 수 있고, 표와 차트가 그 단계만 보여 줍니다.

원리금 상환액은 상환 원금과 이자의 합, 평균 조달 금리는 이자 × 100 ÷ 잔액·기간 가중액, 변동금리 이자 비중은 변동금리 차입 이자 ÷ 전체 이자, 상환 비중은 대주의 상환 원금 ÷ 전체 상환 원금입니다. 1월 합계는 원리금 상환액 1,039.71억 원, 평균 조달 금리 4.07%이고, 한 대주의 값이 0이어도 나눗셈이 깨지지 않도록 서비스가 같은 식으로 처리합니다.

약정 대비 차이 — 같은 표가 점검 자료가 된다

[약정 차이] 스위치를 켜면 열이 실적·약정·차이·차이율로 바뀌고, 금액 기준(기본 3,000백만 원)과 비율 기준(기본 5%)을 모두 넘는 칸만 색으로 구분됩니다. 행을 누르면 아래에 약정 상환 원금에서 실적 상환 원금까지의 요인분해 워터폴이 그려집니다.

합계는 실적 15,194.46억, 약정 15,462.69억, 차이 −268.23억(−1.7%)입니다. 대주별로는 가상 시중은행 B −276.02억(−10.5%)과 가상 외국계은행 D −187.61억(−6.9%)이 약정에 못 미치고, 가상 지방은행 E +152.99억(+11.2%)은 약정을 넘었습니다. 가상 시중은행 A는 +42.98억으로 +0.7%에 그쳐 색이 붙지 않습니다. 합계가 작아도 대주별로는 크게 갈립니다.

15,462.69억에서 출발해 약정 초과 상환 +163.22, 약정 미달 상환 −410.61, 환율 +21.58, 상환 시점 이동 +2.87, 계획 외 조기 상환 +1,014.05, 상환 유예·연장 −1,059.33억을 거쳐 15,194.46억에 닿습니다. 약정 + 요인의 합 − 실적은 원 단위로 0이어야 하고, 합이 맞지 않으면 화면이 그 사실을 표시합니다. 행을 바꾸면 그 행의 워터폴로 바뀝니다.

행을 고르고 [변동 사유]를 누르면 대상 행과 약정 대비 차이(가상 시중은행 A는 +42.98억 원)가 보이고, 구분(상환 금액·환율·상환 시점·유예·연장·계획 외 조기 상환·일회성·기타 가운데 하나)과 사유(500자까지)를 적는 창이 열립니다. 사유는 현재 조회 범위와 행 경로를 키로, 적은 사람의 역할과 함께 서비스에 저장됩니다.

저장한 행 앞에는 연필 표시가 붙고, 축을 바꿔도 같은 행 경로이면 표시가 따라옵니다. 사유가 적힌 행은 해설에서 건너뛰므로 같은 설명을 두 번 읽지 않습니다. 표시된 사유는 CSV와 해설 근거에도 함께 실립니다.

AI 분석과 보고서 — 숫자는 서비스가, 문장은 규칙이

[해설]은 현재 범위를 읽어 요약과 핵심 발견을 씁니다. 기본은 규칙 기반 작성이고, 모델 연결은 서비스 안 설정 하나로 켜는 구조이며 기본은 꺼져 있습니다. 화면·설명서·글 어디에도 API 키는 두지 않습니다.

묶는 기준(대주)과 보는 사람(경영)을 고르면 범위 요약이 나옵니다. 가상 시중은행 A 범위의 상환 원금 5,824.03억, 약정 5,781.05억, 차이 +42.98억(이행률 100.7%)과 가장 큰 요인인 계획 외 조기 상환 +338.72억이 문장에 들어가고, 이미 사유가 적힌 차이는 “건너뜀”으로 표시됩니다. 해설에 쓴 숫자는 [근거 표]에 그대로 펼쳐지고, [보고서 PPTX]로 현재 범위의 표와 차트를 담은 PowerPoint를 브라우저에서 만듭니다. AI는 숫자를 만들지 않습니다.

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

감시 규칙(지표·연산자·임계값·주기·받을 역할)에 걸리면 받을 역할 관점의 보고를 대기함에 올립니다. 하루 한 번 제한은 서버가 판정하고, 걸린 것이 없어도 활동 기록은 남습니다. 실제 운영에서 배치(SM36 · cron)로 돌리는 방법은 설명만 합니다.

규칙은 네 개입니다. AG01 단일 대주 원리금 비중 20% 이상(경영), AG02 변동금리 이자 비중 45% 이상(재무), AG03 약정 상환 이행률 95% 이하(자금), AG04 상환 원금과 약정의 차이 50억 원 이상(회계)이며 임계값은 규칙 한 곳에서 바꿉니다. 화면을 연 뒤 20분마다 자동으로도 한 번 확인합니다.

[지금 실행]을 누르면 규칙 네 개 가운데 네 건이 걸려 대기함에 올라옵니다. 예를 들어 2026년 9월 가상 시중은행 B의 원리금 비중이 23.1%로 한도 20%를 넘어 알림이 뜨고, 받을 역할 관점의 문장이 함께 붙습니다. 안 읽은 보고 수는 [에이전트] 버튼 옆 숫자로 보입니다.

이미 실행한 날 다시 [지금 실행]을 누르면 “오늘은 이미 실행했습니다”가 나오고 대기함에는 새 항목이 쌓이지 않습니다. 막힌 시도도 시각·호출 주체(사람·화면 타이머·배치)와 함께 활동 기록에 남아, 누가 언제 돌렸는지 나중에 확인합니다.

보기 저장과 복원

자주 쓰는 행·열·측정값 배열에 이름을 붙여 저장하고, 기본 보기로 지정하거나 조회 때 자동 실행으로 걸 수 있습니다.

[보기 저장] 메뉴에서 현재 배열을 새 이름으로 저장하거나, 저장한 보기를 불러오고 이름을 바꾸고 지웁니다. 월말 점검용(대주 × 상환 방식, 약정 차이 켜짐)처럼 회의마다 쓰는 배열을 한 번에 불러옵니다.

브라우저를 새로 고친 뒤 같은 범위로 조회해도 사유 표시와 저장한 보기가 그대로 돌아옵니다. 두 가지 모두 브라우저가 아니라 서비스에 저장되어 있어, 다른 사람이 같은 범위를 열어도 같은 설명을 봅니다.

좁은 화면과 한계

휴대폰 폭에서는 표 아래로 차트가 내려가고 조회조건이 세로로 쌓입니다. 표시할 행이 너무 많아지면 행 축을 줄이거나 필터를 걸라는 안내가 나오고, 열도 상한을 넘기면 열 축을 줄이라는 안내가 나옵니다.

데스크톱의 두 칸 배치가 한 칸으로 접히고, 차원 보관함과 행·열 축도 위아래로 쌓입니다. 표는 좌우로 밀어 보고, 칸을 누르면 원천 라인 창은 화면 폭에 맞춰 열립니다. 상세 점검은 큰 화면에서 하는 것을 권합니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스가 큐브와 약정 큐브를 읽어 오고, 이후 행·열을 바꾸는 일은 브라우저의 큐브 엔진이 처리합니다. 칸을 누르면 그 칸의 조건으로 원천 라인을 읽고, 약정 차이 모드에서 행을 고르면 요인분해 함수를 부릅니다. 변동 사유·보기·에이전트 기록은 서비스에 쓰입니다.

판정 규칙 — 조건 → 결과 → 조치

모든 판정은 “점검 필요”·“확인 필요” 수준이며 최종 판단은 회사와 감사인이 합니다. 임계값은 감시 규칙 한 곳에서 바꿉니다.

처리 단계와 대사식

1. 차입 계약별 월별 상환 라인을 읽고, 외화 금액은 상환일 월 환율로 원화 환산합니다.
2. 기간·법인·대주·차입 유형·통화·상환 방식·잔존 만기·자금 용도·금리 유형 단위로 큐브를 만듭니다. 잔액은 기간 끝 값, 상환 원금·이자는 합계입니다.
3. 대사식 ① 큐브 합계 = 원천 라인 합계(기간 9 × 측정값 5 = 45건).
4. 행·열로 접고 계산 항목(원리금 상환액 = 상환 원금 + 이자, 평균 조달 금리 = 이자 × 100 ÷ 잔액·기간 가중액)을 계산합니다.
5. 대사식 ② 표의 칸 값 = 그 칸의 원천 라인 합계.
6. 약정 큐브를 같은 차원으로 맞춰 차이·차이율을 내고, 대사식 ③ 약정 + 요인 합 − 실적 = 0 을 검산합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

두 칸 배치는 한 칸으로 접히고 차트는 표 아래로 내려갑니다. 조회조건·차원 보관함·행 축·열 축은 세로로 쌓이며, 표는 좌우로 밀어서 봅니다. 원천 라인 창과 해설 창은 화면 폭에 맞춰 열립니다.

파일 구성

index.html          앱 진입
Component.js · manifest.json
i18n/               문구
view/               화면(XML 뷰와 조각)
controller/         화면 동작
model/              큐브 엔진(피벗)·서식·내보내기
css/                화면 스타일
odata/              서비스 정의·계산 모듈·샘플 데이터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 관련 기준서는 두지 않았고 대상 영역은 자금입니다.

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

T-code 별 연계 지점

운영 전환 후에도 기존 표준 조회를 없애지 않습니다. 법정·감사·공시 대응이 필요한 숫자는 표준에 남기고, 이 앱은 분석과 점검용으로 씁니다. 두 화면 숫자가 어긋나는 날은 이 앱의 원천 라인 창에서 어느 문서가 다른지부터 찾습니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 표준 데이터를 읽는 분석의 기본 도구입니다. 이 앱은 그 자리를 대신하지 않고, 차입금 상환이라는 한 주제에서 축 전환·원천 드릴스루·약정 비교·요인분해·변동 사유·감시를 한 화면에 묶는 점검용 소비 화면 역할을 합니다. 같은 큐브를 표준 분석 도구에서도 읽을 수 있도록 CDS 뷰에는 분석 주석을 달아 두었습니다. 확인하지 못한 표준 Fiori 앱 이름은 적지 않았습니다.

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

분석 지표 정의표

이 분석 지표 정의는 회계·세무 판단이 아니라 점검 관점의 정의입니다. 최종 판단은 회사와 감사인이 합니다.

CDS 구성 — 최대한 자세히

이 앱이 읽는 모양을 S/4HANA 의 CDS·DDIC 객체로 옮기면 어떻게 나뉘는지를 스케치한 것입니다. 객체 이름과 필드는 기능을 뜻하는 이름으로 지었고, 대상 시스템에서 확인해야 하는 부분은 코드 안에 “확인 필요”로 표시했습니다. 화면은 지금 이 구성과 같은 모양의 서비스 계약을 읽습니다.

뷰 레이어 구성

① 매핑 테이블 — 차입 계약을 대주와 유형에 묶기

어느 계약이 어느 대주·차입 유형·금리 유형에 속하는지는 상환 전표만으로는 나오지 않는 기준입니다. 운영에서 가장 먼저 정해야 하고, 화면의 대주 집중과 변동금리 비중이 여기서 결정됩니다. 계약 식별자를 전표의 어느 필드에 담을지는 회사가 정합니다.

" ─── ZRPY_LNMAP : 차입 계약 → 대주·유형·금리 유형 매핑 (DDIC 테이블 스케치)
" 이름 : 차입 계약 매핑   역할 : 상환 전표의 배정 번호를 계약·대주·차입 유형·금리 유형에 묶는다
" 나눈 이유 : 대주·유형 분류가 바뀌어도 하위 뷰를 고치지 않도록 테이블로 둔다
@EndUserText.label : '차입 계약 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zrpy_lnmap {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key loan_ref : abap.char(18) not null;   " 전표 배정 번호에 담은 계약 식별자 (확인 필요)
  lender       : abap.char(4);             " 대주 코드
  lender_grp   : abap.char(2);             " 시중은행 / 정책금융 / 외국계 / 지방은행 / 투자자단 / 캐피탈
  loan_kind    : abap.char(1);             " 운영 / 시설 / 무역금융 / 매출채권 담보 / 사채
  repay_mode   : abap.char(1);             " 분할 / 만기 일시 / 수시
  rate_type    : abap.char(1);             " F 고정 / V 변동
  maturity     : abap.dats;
  valid_from   : abap.dats;
}

② 기준 뷰 — 상환 라인 기준

통합 전표 항목에서 차입금 상환 라인만 골라 매핑을 붙입니다. 이 뷰에서 라인의 키가 정해지므로 하위 뷰는 모두 이 키를 따르고, 화면의 원천 라인 창도 이 키 단위로 열립니다.

" ─── ZI_RepayLoanBase : 상환 라인 기준 (확인 필요: 대상 시스템의 계정·배정 번호 사용 방식)
" 이름 : 상환 라인 기준   역할 : 통합 전표 항목에서 차입금 상환 라인만 골라 계약 매핑을 붙인다
" 나눈 이유 : 라인의 키와 매핑을 한 곳에서 정해 두면 큐브·약정 뷰가 같은 기준을 읽는다
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '차입금 상환 라인 기준'
define view entity ZI_RepayLoanBase
  as select from acdoca as lin
  inner join zrpy_lnmap as map
    on  map.bukrs    = lin.rbukrs
    and map.loan_ref = lin.zuonr
{
  key lin.rldnr    as Ledger,
  key lin.rbukrs   as CompanyCode,
  key lin.gjahr    as FiscalYear,
  key lin.belnr    as AccountingDocument,
  key lin.docln    as LedgerItem,
      lin.racct    as GLAccount,
      lin.budat    as PostingDate,
      lin.poper    as PostingPeriod,
      lin.rtcur    as TransactionCurrency,
      lin.wsl      as AmountInTransCurrency,
      lin.hsl      as AmountInCompanyCurrency,
      map.lender   as Lender,
      map.lender_grp as LenderGroup,
      map.loan_kind  as LoanKind,
      map.repay_mode as RepayMode,
      map.rate_type  as RateType,
      map.maturity   as Maturity
}
where lin.rldnr = '0L'            " 선행 원장 (확인 필요)

③ 차원 뷰 — 보관함이 읽는 목록

차원 보관함과 값 필터가 읽는 목록입니다. 값 이름과 원천 라인 수를 함께 내므로 화면은 큐브 전체를 읽지 않고도 “라인이 많은 대주부터” 좁힐 수 있습니다.

" ─── ZI_RepayDimension : 차원 뷰
" 이름 : 상환 차원 목록   역할 : 보관함과 값 필터가 읽는 차원 값·이름·라인 수
" 나눈 이유 : 화면이 큐브 전체를 읽지 않고도 값 목록을 만들 수 있도록
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '상환 차원'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_RepayDimension
  as select from ZI_RepayLoanBase
{
  key Lender,
  key LoanKind,
  key TransactionCurrency,
  key RepayMode,
  key RateType,
      LenderGroup,
      count(*) as LineCount
}
group by Lender, LoanKind, TransactionCurrency, RepayMode, RateType, LenderGroup

④ 큐브 뷰 — 기간별 상환 집계

상환 원금·이자 지급·라인 수를 기간·법인·대주·유형·통화·상환 방식·금리 유형 단위로 집계합니다. 집계는 여기서 한 번만 하고, 화면은 이 결과를 브라우저에서 다시 묶으므로 축을 바꿔도 서버를 다시 부르지 않습니다. 통화 금액에는 통화 코드를 의미 주석으로 달아 원화·외화가 섞이지 않게 합니다.

" ─── ZI_RepayCube : 상환 큐브 (실적)
" 이름 : 차입금 상환 큐브   역할 : 기간·법인·대주·유형·통화·상환 방식·금리 유형 단위 집계
" 나눈 이유 : 집계를 서버에서 한 번만 하고 화면은 같은 큐브를 여러 축으로 다시 묶는다
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '차입금 상환 큐브'
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_RepayCube
  as select from ZI_RepayLoanBase as b
  association [0..1] to ZI_RepayDimension as _Dim
    on  $projection.Lender = _Dim.Lender
{
  key b.CompanyCode,
  key b.FiscalYear,
  key b.PostingPeriod,
  key b.Lender,
  key b.LoanKind,
  key b.TransactionCurrency,
  key b.RepayMode,
  key b.RateType,

      @Semantics.currencyCode: true
      b.TransactionCurrency as Currency,

      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      cast( sum( case when b.GLAccount like '2%' then b.AmountInTransCurrency else 0 end ) as abap.curr(23,2) ) as RepayAmount,

      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      cast( sum( case when b.GLAccount like '5%' then b.AmountInTransCurrency else 0 end ) as abap.curr(23,2) ) as InterestAmount,

      @Aggregation.default: #SUM
      cast( count(*) as abap.int4 ) as LineCount,

      _Dim
}
group by b.CompanyCode, b.FiscalYear, b.PostingPeriod, b.Lender, b.LoanKind,
         b.TransactionCurrency, b.RepayMode, b.RateType
" 계정 범위(2%·5%)는 예시이며 고객사 계정 체계로 바꾼다. 원화 환산은 환율 유형과 기준일을 정한 뒤 확장한다(확인 필요).

⑤ 약정 큐브 — 같은 차원에 약정 일정 버전

약정 일정을 실적과 같은 차원 키로 맞춥니다. 약정 일정을 어디서 가져오는지가 도입의 핵심 결정이며, 위 코드는 자금 예정 항목을 쓰는 경우의 스케치입니다.

" ─── ZI_RepayPlan : 약정 큐브
" 이름 : 약정 상환 큐브   역할 : 같은 차원에 약정 일정 버전을 더한 약정 상환 집계
" 나눈 이유 : 실적과 같은 키를 쓰면 화면의 차이·차이율이 열 하나 덧붙이는 일이 된다
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '약정 상환 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_RepayPlan
  as select from fdes as p                         " 자금 예정 항목 (약정 일정 원천은 확인 필요)
  inner join zrpy_lnmap as map
    on  map.bukrs    = p.bukrs
    and map.loan_ref = p.zuonr
{
  key p.bukrs                       as CompanyCode,
  key p.dsart                       as PlanVersion,        " P0 : 약정 일정
  key substring( p.datum, 1, 6 )    as PostingPeriod,
  key map.lender                    as Lender,
  key map.loan_kind                 as LoanKind,
  key p.waers                       as TransactionCurrency,
  key map.repay_mode                as RepayMode,
  key map.rate_type                 as RateType,

      @Semantics.amount.currencyCode: 'TransactionCurrency'
      @Aggregation.default: #SUM
      sum( p.wrshb )                as PlanRepayAmount
}
group by p.bukrs, p.dsart, substring( p.datum, 1, 6 ), map.lender, map.loan_kind,
         p.waers, map.repay_mode, map.rate_type

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

큐브의 내부 키를 숨기고 필터·행·열 축 기본 배치와 계산 항목을 정합니다. 계산 항목(원리금 상환액)은 쿼리에 식으로 두어 화면과 표준 분석 도구가 같은 정의를 읽습니다.

" ─── ZC_RepayExecQuery : 분석 쿼리 (화면이 읽는 모양)
" 이름 : 상환 이행 쿼리   역할 : 화면 필터·측정값·계산 항목 이름을 정하고 서비스로 노출
" 나눈 이유 : 큐브의 내부 키를 숨기고 화면에 필요한 필드만 서비스 계약으로 남긴다
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '차입금 상환 이행 쿼리'
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define view entity ZC_RepayExecQuery
  as select from ZI_RepayCube
{
      @Consumption.filter: { selectionType: #RANGE, mandatory: true }
      @AnalyticsDetails.query.axis: #FILTER
  key PostingPeriod,

      @Consumption.filter.selectionType: #SINGLE
      @AnalyticsDetails.query.axis: #FILTER
  key CompanyCode,

      @AnalyticsDetails.query.axis: #ROWS
  key Lender,

      @AnalyticsDetails.query.axis: #ROWS
  key LoanKind,

      @AnalyticsDetails.query.axis: #COLUMNS
      @Semantics.amount.currencyCode: 'Currency'
      RepayAmount,

      @AnalyticsDetails.query.axis: #COLUMNS
      @Semantics.amount.currencyCode: 'Currency'
      InterestAmount,

      @AnalyticsDetails.query.formula: 'RepayAmount + InterestAmount'
      @EndUserText.label: '원리금 상환액'
      0 as DebtService
}

⑦ 권한(DCL)과 서비스 정의

권한은 집계 단계, 곧 쿼리 뷰에 겁니다. 드릴스루 창에만 걸면 합계에서 허용 범위의 합을 빼는 방식으로 다른 법인의 숫자를 알아낼 수 있기 때문입니다. 서비스는 읽기 전용 노출과 쓰기 객체를 나눕니다.

" ─── ZC_RepayExecQuery : DCL (권한) + 서비스 정의
" 이름 : 상환 이행 권한   역할 : 회사코드 권한 객체로 큐브 행을 걸러 낸다
" 나눈 이유 : 드릴스루가 아니라 집계 단계에 걸어야 합계 뺄셈으로 다른 법인 숫자가 새지 않는다
@EndUserText.label: '상환 이행 권한'
@MappingRole: true
define role ZC_RepayExecQuery {
  grant select on ZC_RepayExecQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

" ─── 서비스 정의 (RAP) : 읽기 전용 노출
@EndUserText.label: '상환 이행 서비스'
define service ZUI_RepayExec {
  expose ZC_RepayExecQuery as RepayCube;
  expose ZI_RepayDimension as RepayDim;
}
" 변동 사유·보기·에이전트 기록은 쓰기가 필요하므로 별도 관리 객체(RAP 관리형 BO)로 두고 서비스에 함께 노출한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목을 정하지 않으면 화면의 숫자가 맞아도 의미가 달라집니다.

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

계약 검증으로 서비스의 엔티티셋 14개와 함수 3개가 선언과 일치하고, 날짜 조건 필터와 쓰기도 동작함을 확인했습니다.

운영 데이터로 갈 때

상환 라인이 수천만 건이면 집계는 큐브 뷰에서 미리 하고, 화면은 기간·법인 필터를 필수로 받아야 합니다. 원천 라인 창은 칸 단위로만 열고 건수 상한을 둡니다. 인덱스는 기간·법인·계약 식별자에 먼저 걸고, 응답 시간 기준을 정해 표시 행·열 상한을 조정합니다.

자주 묻는 질문 — 도입 전에 많이 묻는 것

숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영 순서로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영