그룹 내부 자금 거래 다차원 분석 — 내부 이자의 계획 대비 차이를 요인으로 가르고 원천 라인까지 따라가는 자금 분석

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

그룹 자금 담당자가 월마감 즈음 받는 질문은 늘 비슷합니다. 그룹 안에서 오간 내부 이자가 계획과 얼마나 달랐나, 왜 달랐나, 어느 법인의 무엇을 확인해야 하나. 내부 이자는 잔액, 금리, 이자일수, 환율이 곱해져 나오는 숫자라서 한 군데가 어긋나도 합계만 보면 이유가 보이지 않습니다. 지금은 이 답이 표준 라인 항목 조회, 법인별 엑셀, 메일로 받은 설명에 흩어져 있습니다.

이 앱은 그 세 가지를 한 화면에 모읍니다. 대여 법인 · 차입 법인 · 통화 · 금리 유형 같은 차원을 끌어다 놓으며 같은 숫자를 여러 각도로 보고, 칸을 누르면 그 금액을 이룬 원천 라인으로 내려가고, 계획과의 차이를 잔액 · 금리 · 이자일수 · 환율 같은 요인으로 나눠 합이 맞는지 매번 검산합니다. 업무 분석 앱이라 특정 기준서에 묶여 있지 않으며, 다루는 대상 영역은 그룹 내부 대여 · 캐시풀 · 한도 대출의 내부 이자와 외화 환산, 계획 대비 차이입니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 14.65억 차이는 어디서 났나

이 사례 자료(가상 법인 11곳, 2026년 1월~9월)에서 내부 이자 실적은 599.07억 원, 계획은 613.72억 원으로 1,465,029,705원(−2.4%) 모자랐습니다. 여기까지는 합계 리포트도 말해 줍니다. 이 앱은 그 다음을 답합니다. 전체 범위를 요인으로 가르면 이자일수 차이가 −33.69억으로 가장 컸고, 잔액 차이 −14.96억, 미실행 −4.22억이 이어졌으며, 계획 외 대여 +25.36억, 환율 +8.96억, 금리 +3.90억이 이를 일부 상쇄했습니다. 일곱 요인의 합은 총차이와 같고 검산 줄은 0입니다.

한 법인으로 내려가면 그림이 구체적이 됩니다. 국내 물류 자회사의 계획 대비 차이는 −172,586천원인데, 잔액 −105,224 · 금리 +49,885 · 이자일수 −318,110 · 환율 0 · 계획 외 대여 +226,127 · 미실행 −25,264(모두 천원)로 갈립니다. 합계 금액만 보면 “조금 모자랐다”에서 끝나지만, 요인으로 보면 이자일수 차이를 먼저 확인하고 계획에 없던 대여가 얼마나 상쇄했는지를 함께 보게 됩니다. 이 숫자는 샘플 자료의 가정값에서 나온 것이며, 실제 원인 판단은 법인별 확인이 필요합니다.

분해에는 조건을 걸었습니다. 계획 + 요인 합 − 실적이 0이 아니면 화면이 그 사실을 먼저 알립니다. 회의에서 “이 숫자 맞아?”라는 질문에 바로 답할 수 있다는 뜻입니다.

도입하면 달라지는 것

• 월마감 준비 — 차이 표 · 요인 · 사유 · 회의 자료가 한 화면에서 나오므로 법인별 엑셀 취합과 캡처 작업이 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”보다 “어느 법인의 이자일수를 확인할까”를 이야기하게 됩니다.
• 다음 달로 이어지는 기록 — 사유와 보기(축 배치)가 남아 같은 설명을 처음부터 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 규칙에 걸린 항목이 받을 사람 앞의 대기함에 올라갑니다.

이런 회사에 맞습니다

본사 자금센터나 지역 금융법인이 자회사에 대여하거나 캐시풀을 운영하고, 내부 이자를 월 단위로 인식하는 그룹에 맞습니다. 외화 대여가 섞여 환율 영향을 따로 보고 싶은 자금팀, 계획 대비 이자 차이를 설명해야 하는 재무 · 회계 담당, 그리고 AI 해설을 쓰고 싶지만 숫자의 출처는 서비스가 통제해야 하는 경영지원 조직이 대상입니다.

실행 화면

실제로 돌아가는 화면 34종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

사용 방법

1. 조회조건 입력 — 대여 법인, 기간(시작 · 끝), 비교 기준을 정합니다. 모두 선택 사항이며 비워 두면 전체 범위입니다.
2. 조회 — 조회 버튼이나 Enter를 누릅니다. 저장한 보기 중 기본 · 자동 조회로 지정한 것이 있으면 열자마자 조회됩니다.
3. 요약 확인 — 요약 카드 다섯 장과 피벗 표 · 차트를 봅니다. 보는 사람(경영 · 재무 · 자금 · 회계)을 누르면 앞세우는 측정값과 기본 배치가 바뀝니다.
4. 축 바꾸기 — 차원 칩을 행 축 · 열 축 칸으로 끌어다 놓거나 칩 메뉴로 옮깁니다. 행은 3단계, 열은 2단계까지이며 서버를 다시 부르지 않습니다.
5. 필터 · 단위 — 값 필터로 범위를 좁히고 표시 단위(원 · 천원 · 백만원 · 억원)와 차이 기준을 바꿉니다.
6. 칸 눌러 상세 — 표의 칸을 누르면 그 금액을 이룬 원천 라인이 열리고 합계 일치 여부가 표시됩니다.
7. 계획 대비 차이 — 계획 차이를 켜면 실적 · 계획 · 차이 · 차이율이 보입니다. 행을 고르면 요인 워터폴이 나타나고, 변동 사유 버튼으로 사유를 남깁니다.
8. 해설 · 보고서 · 에이전트 — 해설 버튼으로 근거 표가 붙은 해설을 읽고 PowerPoint 보고서를 내려받습니다. 에이전트는 걸린 항목을 대기함에 모으며 하루 한 번만 실행됩니다.
9. 보기 저장과 내려받기 — 현재 배치를 이름 붙여 저장하고, 표 위 CSV 버튼으로 현재 피벗을 내려받습니다.

무엇으로 만들었나

처음 열었을 때

조회조건부터 피벗까지가 한 화면에 세로로 쌓입니다. 조건 영역은 접을 수 있어서 축을 짜는 동안에는 펼쳐 두고 숫자를 들여다볼 때는 접어 둡니다.

조회조건 · 차원 보관함과 행 · 열 축 보드 · 피벗 틀이 먼저 서 있고 값만 비어 있어서, 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 기간은 2026년 1월~9월이 기본으로 들어 있고 비교 기준은 계획으로 잡혀 있습니다.

조회를 누르면 요약 카드 다섯 장(내부 이자 · 실효 금리 · 기준 금리 대비 스프레드 · 계획 대비 차이 · 기말 잔액)이 먼저 차고, 아래로 피벗 표와 같은 값을 그린 차트가 붙습니다. 기본 배치는 행 축 대여 법인 › 차입 법인, 열 축 분기입니다. 기준 금리는 샘플의 가정값이라 카드에도 그 사실을 적어 두었습니다.

조회가 끝나면 조건 영역은 한 줄 요약으로 접혀 표가 넓어집니다. 범위를 바꾸고 싶을 때는 조건 영역의 머리줄을 눌러 다시 펼칩니다. 대여 법인 · 기간 · 비교 기준은 모두 선택 사항이라 비워 두면 전체 범위입니다.

차원 보관함의 칩을 열 축 칸으로 끌어다 놓은 모습입니다. 큐브는 이미 브라우저에 있으므로 축을 바꾸는 일은 그 행들을 다시 묶는 일이고, 서버 호출은 일어나지 않습니다. 어느 배치에서도 총합은 같습니다.

긴 회의에서 숫자만 띄워 놓고 이야기할 때 쓰는 모습입니다. 조회 범위는 한 줄 요약으로 남아 있어 지금 보는 숫자가 어느 범위인지는 늘 확인됩니다.

보는 사람 — 자리마다 다른 첫 화면

같은 큐브에서 나온 같은 숫자인데, 보는 사람의 자리에 따라 먼저 보여야 할 지표가 다릅니다. 네 관점을 갈아 끼우며 다시 조회하지 않습니다.

경영 관점은 전사 유동성 흐름에서 그룹 내부 자금이 계획한 이자 흐름을 얼마나 벗어났는지를 앞세웁니다. 같은 큐브에서 나온 같은 숫자이고 앞세우는 측정값과 기본 배치만 달라집니다.

재무 관점은 기말 잔액과 실효 금리, 기준 금리 대비 스프레드를 앞세웁니다. 스프레드는 베이시스포인트로 표시하며 기준 금리는 샘플의 가정값입니다. 실제 기준은 운영 연동 때 정해야 합니다(확인 필요).

자금 관점은 차입 법인과 통화별로 잔액, 금리, 이자일수, 환율 요인을 먼저 볼 수 있도록 배치를 바꿉니다. 자금팀이 법인별 대여 현황을 점검할 때 쓰는 모습입니다.

회계 관점은 거래 성격(대여금 · 캐시풀 · 한도 대출)과 통화로 묶어 원천 라인과 맞춰 보기 좋게 배치합니다. 내부 이자의 회계 처리나 이자율 적정성은 이 화면이 판단하지 않으며 회사와 감사인, 세무 대리인의 확인이 필요합니다.

축을 바꾸고 범위를 좁힌다

리포트를 하나 더 만드는 대신 축을 바꿉니다. 값을 골라 범위를 좁히고, 표와 차트의 너비까지 그 자리에서 나눕니다.

열 축을 두 단계로 쌓은 모습입니다. 열 조합은 36개까지만 그립니다. 그 이상은 머리글이 먼저 무너져 표로서 읽히지 않기 때문이며, 넘으면 그리지 않고 줄이라는 안내가 나옵니다.

값 필터 창에는 차원마다 값 목록이 열립니다. 코드를 외우지 않아도 이름으로 찾아 체크하면 되고, 값마다 라인 수가 함께 보입니다. 같은 차원 안에서는 or, 차원끼리는 and 로 묶입니다.

차입 법인 두 곳을 골라 범위를 좁힌 상태입니다. 요약 카드와 차트, 해설에 넘기는 근거까지 모두 이 범위로 다시 계산되므로 화면은 좁혀 보는데 해설만 전체 숫자인 일이 없습니다.

좁힌 뒤에도 표의 합계와 카드, 차트가 같은 숫자를 가리킵니다. 필터를 풀면 전체 범위로 돌아가며, 이 과정에서도 서버를 다시 부르지 않습니다.

표와 차트 사이의 손잡이를 끌면 두 영역의 폭이 바뀝니다. 정한 폭은 그 브라우저에 남아 다음에 열 때도 이어집니다. 차트는 외부 라이브러리 없이 직접 그린 SVG라서 표와 차트의 숫자가 다른 경로로 만들어질 일이 없습니다.

칸에서 원천 라인까지

숫자를 의심하는 순간 다른 화면을 열지 않아도 됩니다. 칸 금액과 원천 라인 합계가 같은지가 맨 위에 적힙니다.

행의 차원 경로와 열 조합이 그대로 조건이 되어 원천 라인이 열립니다. 맨 위에 표의 값과 원천 합계가 같은지(일치 표시)와 라인 수가 적혀 있고, 라인마다 이자 인식일 · 문서 · 법인 · 통화 · 평균 잔액 · 환율 · 금리 · 이자일수 · 내부 이자가 보입니다. CSV로 내려받을 수 있습니다.

계산항목 — 차원으로는 나오지 않는 열

거래 성격별 이자나 스프레드는 전표에 들어 있는 값이 아니라 계산으로 만드는 값이라 차원이 아닌 계산항목으로 둡니다.

계산항목은 차원이 아니라 계산으로 만든 열입니다. 대여금 이자 · 캐시풀 이자 · 한도 대출 이자는 내부 이자를 거래 성격으로 한정한 값이고, 기준 금리 대비 이자 차이 · 실효 금리 · 스프레드도 있습니다. 측정값 선택에서 일곱 항목을 함께 고른 모습입니다.

계산항목 칸을 눌러도 그 값을 이룬 원천 라인이 열리고 합계가 맞는지 표시됩니다. 계산항목이라고 해서 검증에서 빠지는 자리를 만들지 않았습니다.

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

비교 기준을 계획으로 두면 표가 차이 표가 되고, 행을 고르면 요인으로 가르며, 사유를 남길 수 있습니다.

계획 차이를 켜면 칸마다 실적 · 계획 · 차이 · 차이율이 붙습니다. 금액 기준(기본 3백만 원)과 비율 기준(기본 5%)을 둘 다 넘는 칸만 색이 칠해집니다. 작은 법인의 큰 비율이나 큰 법인의 작은 흔들림까지 칠하면 정작 볼 곳이 묻히기 때문입니다.

행을 고르면 계획 이자에서 실적 이자까지를 잔액 · 금리 · 이자일수 · 환율 · 실행 상환 시점 · 계획 외 대여 · 미실행 순으로 보여 주는 워터폴이 나옵니다. 이 법인은 이자일수 −318,110천원이 가장 크고 계획 외 대여 +226,127천원이 일부 상쇄합니다.

차입 법인 아래에 거래 성격을 펼치면 대여금 · 캐시풀 · 한도 대출 단위의 차이가 보입니다. 요인 합계와 총차이가 같은지는 검산 줄이 매번 다시 적습니다.

사유는 행 경로와 조회 범위를 키로 저장됩니다. 서비스에 저장하므로 브라우저를 닫아도 남습니다.

사유를 저장하면 그 행에 연필 표시가 붙습니다. 축을 바꾸거나 트리를 다시 펼쳐도 같은 행이면 사유가 따라옵니다. 해설은 이미 사유가 적힌 행을 건너뛰고 아직 설명되지 않은 곳에 집중합니다.

AI 분석과 보고서

해설의 숫자는 서비스가 큐브에서 계산해 근거로 넘기고, 모델은 문장만 맡습니다. 모델을 쓰지 않는 기본 설정에서는 규칙 기반 해설이 같은 근거로 나옵니다.

해설 창은 묶는 기준과 보는 사람을 고를 수 있고, 지금 작성 방식(규칙)이 표시됩니다. 요약에는 범위 안 실적 · 계획 · 차이와 가장 큰 요인이 적히고, 아래 근거 표에 해설에 쓴 숫자가 그대로 있습니다. 점검이 필요한 항목은 근거 숫자를 확인하라고 안내합니다.

해설 창의 보고서 버튼으로 현재 범위의 PowerPoint가 브라우저에서 바로 만들어집니다. 서버에 파일이 남지 않고, 표와 요인 장은 화면의 숫자와 같습니다.

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

감시 규칙이 걸린 항목을 대기함에 모읍니다. 판정과 하루 한 번 제한은 서버가 기록으로 합니다.

스프레드 하한은 재무, 계획 차이 임계는 경영, 계획 외 대여는 회계, 무이자 대여 잔액 비중은 자금이 받습니다. 걸린 항목은 대기함에 올라가며 보내는 단계는 사람이 확인합니다.

지금 실행을 누르면 서비스가 규칙을 점검해 걸린 항목을 대기함에 올립니다. 이 사례에서는 국내 물류 자회사의 스프레드가 기준 금리보다 낮게 나온 건 등 6건이 올라왔고, 무이자 지원이나 금리 조건 변경 여부를 확인하라고 적혀 있습니다.

같은 날 다시 실행하면 서버가 막고 안내 문구가 나옵니다. 화면을 다시 열거나 버튼 상태를 바꿔도 우회되지 않도록 판정을 화면이 아니라 활동 기록에 두었습니다.

보기 저장과 복원

짜 둔 축은 이름을 붙여 저장해 두고, 기본으로 지정하면 다음에 열 때 그 배치로 시작합니다.

축 배치와 값 필터, 측정값, 단위, 차이 기준을 보기 하나로 저장합니다. 기본 보기와 자동 조회 여부도 지정할 수 있고 저장은 서비스에 남습니다.

저장한 보기 목록에서 기본 보기와 자동 조회를 지정하고 이름을 바꾸거나 지웁니다. 매일 같은 화면을 보는 사람에게는 이 한 단계가 큽니다.

기본과 자동 조회로 지정한 보기가 있으면 화면을 열자마자 그 배치가 복원되고 조회가 끝나 있습니다.

좁은 화면과 한계

같은 리포트를 휴대폰에서도 보고, 그릴 수 없는 범위에서는 그리지 않고 말합니다.

넓은 화면에서는 표와 차트를 가로로 나란히 둡니다. 회의실 화면에 띄우는 기본 모습입니다.

중간 폭에서는 요약 카드가 줄어든 폭에 맞춰 흐르고 표와 차트의 비율이 조정됩니다.

창이 좁아지면 차트를 감추지 않고 표 아래로 내립니다. 가로로 겹쳐 놓던 것을 세로로 쌓는 방식이라 휴대폰에서도 같은 리포트를 보며, 화면 가로 스크롤은 생기지 않습니다.

조합이 상한을 넘으면 반쯤 그린 표를 남기지 않고 무엇을 줄이면 되는지 적어 줍니다. 사진은 상한을 낮춰 실제로 걸리게 한 모습입니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 위의 화면들이 어떤 규칙으로 그렇게 움직이는지를 자리별로 적었습니다.

계획 대비 판정과 표시 규칙

화면은 조건에 따라 상태를 나누고, 상태마다 사용자가 할 일을 정해 두었습니다.

이 화면은 점검 도구입니다. 색 표시와 해설은 살펴볼 곳을 좁혀 줄 뿐이며 최종 판단은 회사와 감사인이 합니다. 내부 이자율의 적정성 판단은 세무 대리인과 확인이 필요하고, 기준 금리와 환율은 샘플 자료의 가정값입니다.

내부 이자 산출과 검산 순서

원천 라인은 계약 × 월별 명세 한 줄입니다. 내부 이자(원화) = 평균 잔액 × 환율 × 금리(%) × 이자일수 ÷ 36,500이며, 이 값을 월별로 원 단위로 반올림해 저장합니다.

1. 잔액 · 기간 가중액 — 평균 잔액 × 환율 × 이자일수 ÷ 365. 이자를 이 값으로 나누면 연 환산 금리가 됩니다.
2. 기준 금리 이자 — 같은 잔액 · 기간에 기준 금리(샘플 가정값)를 적용한 이자입니다.
3. 실효 금리와 스프레드 — 실효 금리 = 내부 이자 × 100 ÷ 잔액 · 기간 가중액, 스프레드(bp) = (내부 이자 − 기준 금리 이자) × 10,000 ÷ 잔액 · 기간 가중액.
4. 순 실행액과 기말 잔액 — 순 실행액(실행 − 상환)은 기간 합이고, 기말 잔액은 기간을 합쳐도 마지막 기간 값만 씁니다. 시점 값을 더하면 잔액이 부풀기 때문입니다.
5. 큐브 만들기 — 원천 라인을 9개 차원 단위로 집계해 실적 큐브와 계획 큐브를 만들고, 화면은 이를 한 번만 읽어 축 변경을 브라우저 안에서 다시 묶습니다.
6. 차이 분해 — 라인 단위로 한 항씩 바꿔 가며 잔액 → 금리 → 이자일수 → 환율 순으로 나누고, 계획 외 대여 · 미실행 · 실행 · 상환 시점 요인을 더해 일곱 요인으로 만듭니다. 반올림 단수는 환율 요인이 받아 계획 + 요인 합 − 실적 = 0이 되게 합니다.
7. 대사 — 큐브 합계와 원천 라인 합계를 기간 × 측정값 8종으로 맞춰 봅니다(72건).

조회조건

조회 범위는 짧은 조건 문법으로 서비스에 전달되고, 한 번에 읽는 큐브와 계획은 각각 최대 5,000행입니다(이 사례는 1,334행과 1,332행). 조건은 and로 묶은 비교만 쓰고 or는 쓰지 않습니다. 구현마다 괄호 조건의 해석이 갈리기 때문입니다.

결과 컬럼

좁은 화면에서 달라지는 것

표와 차트를 한 줄에 나란히 두던 배치가 좁아지면 위아래로 쌓입니다. 요약 카드는 폭에 맞춰 흐르고 화면 가로 스크롤은 생기지 않습니다. 행 · 열 조합이 상한을 넘으면 그리지 않고 안내만 띄우는 규칙은 화면 폭과 무관하게 같습니다.

파일 구성

앱 폴더
├─ index.html · Component.js · manifest.json
├─ controller/   화면 제어(기반 · 메인)
├─ view/         메인 뷰와 창(원천 라인 · 변동 사유 · 보기 저장 · 보기 관리 · 해설 · 에이전트 · 값 도움)
├─ model/        피벗 엔진 · 차트 · 보기 저장 · 서식 · 보고서 생성 · 오류 처리
├─ css/ · i18n/  스타일과 화면 문구
├─ odata/        서비스 정의 · 서비스 구현 · 계산 로직 · 샘플 자료
├─ media/        소개 영상
└─ readme.html   설명서

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준 화면 사이를 오가며 맞춰 봐야 하는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다. 표준 실행은 SAP 표준 T-code가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

표준 T-code마다 이 앱이 이어받는 데이터와 두 화면의 숫자를 맞춰 보는 지점, 오가는 방법, 표준에 남겨 둘 일을 적었습니다. 운영 연동 범위가 정해지기 전이라 대조 방법은 모두 확인 필요입니다.

기존 리포트를 없애야 하는지를 자주 묻습니다. 대부분 없애지 않습니다. 법정 보고와 감사 대응, 세무 신고용 자료는 표준 거래에 두는 편이 안전합니다. 이 앱이 맡는 일은 ‘축을 바꿔 가며 들여다보는’ 분석과 계획 대비 이자 차이 점검입니다.

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

운영 단계에서는 이 화면이 하는 집계를 CDS 큐브와 분석 쿼리로 내리게 됩니다(아래 CDS 구성). 분석 쿼리를 만들어 두면 표준 쿼리 조회 도구나 Analysis for Office 같은 표준 분석 도구에서도 같은 축으로 열 수 있습니다. 이 앱이 더하는 것은 칸에서 원천 라인으로 내려가는 경험, 집계 행에 남는 사유, 합이 검산되는 요인 분해, 사람 없이 도는 점검입니다. 이 넷이 필요 없다면 표준 분석 쪽이 유지보수가 가볍습니다. 특정 Fiori 분석 앱과의 대응은 환경 확인 전에는 단정하지 않습니다(확인 필요).

분석 지표 정의

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

CDS 구성

이 사례의 화면은 원천 라인 6,783행을 서비스가 들고 큐브 1,334행으로 묶어 브라우저에 내려 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 집계를 CDS로 내리는 것이 첫 작업입니다. 아래는 그때 만드는 뷰와 표를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 · 테이블의 세부는 릴리스와 환경에 따라 다르므로 그대로 붙여 넣기 전에 실제 정의를 확인해야 합니다. 확인이 필요한 자리는 주석에 확인 필요로 적어 두었습니다.

뷰 레이어 구성

① 계정 매핑 테이블

내부 이자가 어느 계정에 쌓이고 어느 계정이 대여금 잔액인지를 정하는 자리입니다. 리포트의 모든 숫자가 이 표에서 갈리므로 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 계정 체계가 바뀌어도 과거 숫자가 흔들리지 않게 하기 위해서입니다.

// ─────────────────────────────────────────────────────────────
// ZICF_ACCTMAP — 내부 자금 거래 계정 매핑
// 역할  : 계정 → 거래 성격(대여금·캐시풀·한도 대출) · 종류(이자·잔액) · 표시 부호
// 나눈 이유: 계정 추가를 코드 수정 없이 현업이 유지하도록(보통 SM30 유지보수 뷰와 함께)
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '내부 자금 거래 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zicf_acctmap {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;
  key racct    : racct not null;
  key valid_to : datbi not null;
  valid_from   : datab not null;
  txn_cat      : abap.char(1) not null;  // L 대여금 · P 캐시풀 · R 한도 대출
  acct_kind    : abap.char(1) not null;  // I 이자 · B 잔액
  sign_rule    : abap.char(1) not null;  // 표시 부호 규칙(1 그대로 · 2 반전)
}

② 대여 계약 테이블

대여 법인 · 차입 법인 · 통화 · 금리 유형 · 만기 구간 · 대여 목적은 전표에 들어 있는 값이 아닙니다. 운영 환경에서 이 정보가 금융 거래 모듈에 있는지 별도 마스터에 있는지는 환경마다 다르므로 확인 필요이며, 여기서는 계약 마스터를 한 표로 두는 스케치를 적었습니다.

// ─────────────────────────────────────────────────────────────
// ZICF_CONTRACT — 내부 대여 계약 마스터(스케치)
// 역할  : 계약번호별 법인 쌍과 분류 속성, 계약 금리
// 확인 필요: 계약이 다른 모듈에 있으면 이 표 대신 그 뷰를 읽는다
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '내부 대여 계약 마스터'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zicf_contract {
  key mandt      : mandt not null;
  key contract_id: abap.char(12) not null;
  lend_bukrs     : bukrs not null;          // 대여 법인
  borr_bukrs     : bukrs not null;          // 차입 법인
  txn_cat        : abap.char(1) not null;   // L · P · R
  waers          : waers not null;          // 계약 통화
  rate_type      : abap.char(1) not null;   // F 고정 · V 변동 · Z 무이자
  mat_band       : abap.char(1) not null;   // 1 3개월 이하 · 2 1년 이하 · 3 1년 초과
  purpose        : abap.char(2) not null;   // 운전자금 · 설비투자 · 경영 지원 · 단기 유동성
  int_rate       : abap.dec(7,4);           // 계약 금리(%)
  valid_from     : datab not null;
  valid_to       : datbi not null;
}

③ 법인 차원 뷰

대여 법인과 차입 법인이 같은 법인 마스터를 보게 해 이름 · 통화 · 지역이 한 곳에서 나오게 합니다. 지역은 국가 코드에서 파생하지만, 운영에서는 별도 매핑 표를 두는 편이 낫습니다.

// ─────────────────────────────────────────────────────────────
// ZI_IcFundCompany — 법인 차원
// 역할  : 회사코드 → 이름 · 통화 · 지역
// 나눈 이유: 값 도움말과 텍스트가 이 뷰 하나를 보게 한다
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '내부 자금 거래 법인 차원'
@ObjectModel.dataCategory: #DIMENSION
define view entity ZI_IcFundCompany
  as select from t001
{
      @ObjectModel.text.element: ['CompanyName']
  key bukrs as CompanyCode,
      butxt as CompanyName,
      waers as CompanyCurrency,
      land1 as Country,
      // 지역 파생은 예시. 운영에서는 매핑 표 권장
      case land1
        when 'KR' then 'KR'
        when 'DE' then 'EU'
        when 'PL' then 'EU'
        when 'US' then 'AM'
        else 'AS'
      end as Region
}

④ 라인 뷰

이자 인식 전표 라인과 계약을 잇는 자리입니다. 원천 라인 드릴스루가 이 뷰를 읽으므로 칸 금액과 라인 합계가 같다는 보장이 여기서 시작됩니다. 계약번호를 전표의 어느 필드에 싣는지는 운영 환경의 약속이므로 확인 필요입니다.

// ─────────────────────────────────────────────────────────────
// ZI_IcFundLine — 내부 이자 인식 라인
// 역할  : ACDOCA 이자 라인 + 계정 매핑 + 계약 연결
// 나눈 이유: 드릴스루와 큐브가 같은 라인 정의를 공유한다
// 확인 필요: 계약번호를 싣는 필드(예시는 배정 필드), 거래 상대 회사 필드 사용 여부
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '내부 자금 거래 이자 라인'
define view entity ZI_IcFundLine
  as select from acdoca as j
    inner join   zicf_acctmap as m
      on  m.ktopl     = j.ktopl
      and m.racct     = j.racct
      and m.acct_kind = 'I'
      and j.budat between m.valid_from and m.valid_to
{
  key j.rldnr                       as Ledger,
  key j.rbukrs                      as LendCompany,
  key j.gjahr                       as FiscalYear,
  key j.belnr                       as AccountingDocument,
  key j.docln                       as LedgerLine,
      j.poper                       as Period,
      j.budat                       as PostingDate,
      cast( j.zuonr as abap.char(12) ) as ContractId,   // 예시: 배정 필드에 계약번호
      m.txn_cat                     as TxnCategory,
      j.rwcur                       as TransactionCurrency,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      j.wsl                         as InterestTransAmount,
      j.rhcur                       as CompanyCurrency,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      j.hsl                         as InterestAmount
}
where j.rldnr = '0L'            // 선도 원장만(확인 필요)

⑤ 실적 큐브

라인을 9개 차원 단위로 묶습니다. 화면이 브라우저에서 하던 집계를 DB로 내리는 자리이며, 통화 금액은 반드시 통화 키와 함께 집계합니다. 통화가 다른 행은 더할 수 없으므로 통화를 차원으로 함께 올립니다.

// ─────────────────────────────────────────────────────────────
// ZI_IcFundActualCube — 실적 큐브
// 역할  : 라인 → (기간, 대여 법인, 차입 법인, 성격, 통화, 금리 유형, 만기, 목적, 지역)
// 나눈 이유: 축 변경마다 라인을 다시 훑지 않도록 집계를 한 번만 한다
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '내부 자금 거래 실적 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_IcFundActualCube
  as select from ZI_IcFundLine as l
    inner join   zicf_contract as c
      on c.contract_id = l.ContractId
    inner join   ZI_IcFundCompany as b
      on b.CompanyCode = c.borr_bukrs
{
  key l.FiscalYear                 as FiscalYear,
  key l.Period                     as Period,
  key l.LendCompany                as LendCompany,
  key c.borr_bukrs                 as BorrowCompany,
  key l.TxnCategory                as TxnCategory,
  key l.TransactionCurrency        as TransactionCurrency,
  key c.rate_type                  as RateType,
  key c.mat_band                   as MaturityBand,
  key c.purpose                    as Purpose,
  key b.Region                     as Region,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      @Aggregation.default: #SUM
      sum( l.InterestAmount )      as InterestAmount,
      l.CompanyCurrency            as CompanyCurrency,
      @Aggregation.default: #SUM
      count( * )                   as LineCount
}
group by l.FiscalYear, l.Period, l.LendCompany, c.borr_bukrs, l.TxnCategory,
         l.TransactionCurrency, c.rate_type, c.mat_band, c.purpose, b.Region,
         l.CompanyCurrency

⑥ 계획 큐브

계획은 실적과 같은 키 모양이어야 같은 표에서 나란히 놓입니다. 계획이 법인 쌍 단위로만 있는지 계약 단위까지 있는지, 계획 범주와 버전 필드가 무엇인지는 환경마다 다르므로 확인 필요입니다. 그리고 계획에 평균 잔액과 금리, 일수가 함께 있어야 요인 분해에서 잔액 · 금리 · 이자일수를 가를 수 있습니다.

// ─────────────────────────────────────────────────────────────
// ZI_IcFundPlanCube — 계획 큐브
// 역할  : 계획 이자를 실적 큐브와 같은 키로 집계
// 확인 필요: 계획 범주·버전 필드명, 계약 단위 계획 여부, 계획 잔액·금리·일수 보유 여부
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '내부 자금 거래 계획 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_IcFundPlanCube
  as select from acdocp as p
    inner join   zicf_contract as c
      on c.contract_id = cast( p.zuonr as abap.char(12) )
    inner join   ZI_IcFundCompany as b
      on b.CompanyCode = c.borr_bukrs
{
  key p.ryear                      as FiscalYear,
  key p.poper                      as Period,
  key p.rbukrs                     as LendCompany,
  key c.borr_bukrs                 as BorrowCompany,
  key c.txn_cat                    as TxnCategory,
  key p.rwcur                      as TransactionCurrency,
  key c.rate_type                  as RateType,
  key c.mat_band                   as MaturityBand,
  key c.purpose                    as Purpose,
  key b.Region                     as Region,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      @Aggregation.default: #SUM
      sum( p.hsl )                 as PlanInterestAmount,
      p.rhcur                      as CompanyCurrency
}
where p.rldnr = '0L'
  and p.version = '000'          // 계획 버전(확인 필요)
group by p.ryear, p.poper, p.rbukrs, c.borr_bukrs, c.txn_cat, p.rwcur,
         c.rate_type, c.mat_band, c.purpose, b.Region, p.rhcur

⑦ 분석 쿼리

행 · 열 기본 배치와 계산 측정값을 정의합니다. 쿼리를 만들어 두면 표준 분석 도구가 같은 축으로 열고, 이 앱이 하는 피벗의 기본 배치도 같은 정의를 따릅니다.

// ─────────────────────────────────────────────────────────────
// ZC_IcFundQuery — 분석 쿼리
// 역할  : 기본 배치(행 대여 법인 › 차입 법인, 열 분기)와 측정값
// 나눈 이유: 표준 분석 도구와 이 앱이 같은 정의를 보게 한다
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '내부 자금 거래 분석 쿼리'
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
define view entity ZC_IcFundQuery
  as select from ZI_IcFundActualCube as a
  association [0..*] to ZI_IcFundPlanCube as _Plan
    on  _Plan.FiscalYear = a.FiscalYear
    and _Plan.Period     = a.Period
    and _Plan.LendCompany   = a.LendCompany
    and _Plan.BorrowCompany = a.BorrowCompany
    and _Plan.TxnCategory   = a.TxnCategory
    and _Plan.TransactionCurrency = a.TransactionCurrency
{
  @AnalyticsDetails.query.axis: #ROWS
  @AnalyticsDetails.query.displayHierarchy: #ON
  a.LendCompany,
  @AnalyticsDetails.query.axis: #ROWS
  a.BorrowCompany,
  @AnalyticsDetails.query.axis: #COLUMNS
  a.Period,
  a.TxnCategory,
  a.TransactionCurrency,
  a.RateType,
  a.MaturityBand,
  a.Purpose,
  a.Region,
  @AnalyticsDetails.query.axis: #COLUMNS
  @EndUserText.label: '내부 이자(원)'
  a.InterestAmount,
  @EndUserText.label: '원천 라인 수'
  a.LineCount,
  // 계획 차이·실효 금리 같은 계산 측정값은 쿼리에서 정의(확인 필요: 연결 방식)
  _Plan
}

⑧ 권한 (DCL)

회사코드 권한을 큐브를 읽는 자리에 겁니다. 권한을 드릴스루에만 걸면 집계 합계는 보이고 상세만 막혀, 합계에서 자기 몫을 빼 다른 법인의 숫자를 알아낼 수 있기 때문입니다.

// ─────────────────────────────────────────────────────────────
// ZR_IcFundActual — 접근 제어
// 역할  : 대여 법인 회사코드 권한을 따른다(조회 권한 ACTVT 03)
// 나눈 이유: 표준 권한 객체를 그대로 써서 별도 권한 체계를 만들지 않는다
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '내부 자금 거래 실적 권한'
@MappingRole: true
define role ZR_IcFundActual {
  grant select on ZI_IcFundActualCube
    where ( LendCompany ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 시점에 해야 할 일

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

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

분석 화면에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 만드는 쪽에서 대사식을 먼저 세우고 전수로 돌렸습니다. 도입 포인트에서 본 숫자와 같은 자료의 결과입니다.

모든 대사식이 차이 0입니다. 이와 별도로 화면 쪽은 브라우저 자동화로 확인했습니다 — 축을 바꿔도 총합이 변하지 않는지, 칸 금액과 원천 라인 합계가 같은지, 요인 합이 총차이와 같은지를 매번 다시 잽니다. 의도적으로 허용한 예외는 없으며, 운영 원천 연동 범위 · 기준 금리와 환율의 실제 값 · 표준 화면과의 숫자 대조 방법은 확인 필요로 남겨 두었습니다.

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

한 가지 더. 드릴스루는 집계가 아니라 조회입니다. 한 칸에 수십만 건이 걸려 있으면 그 화면이 열리지 않으므로, 건수를 먼저 세고 범위를 좁히게 하는 편이 낫습니다. 이 앱도 조합이 상한을 넘으면 그리지 않고 안내합니다.

자주 묻는 질문

도입 상담과 데모에서 자주 나오는 질문을 네 묶음으로 적었습니다.

숫자와 산식

화면과 사용

AI 분석과 에이전트

도입과 운영