예금 만기 사다리·재예치 점검 — 만기가 몰린 구간과 소요에 못 미치는 구간을 가려 중도해지 검토안과 재예치 가능 금액까지 산출하는 자금 관리 화면

Q: 해지할 예금은 어떤 순서로 고릅니까?

더 늦게 만기가 오는 예금 가운데 약정이율이 있는 것만 후보로 두고, 중도해지 이자 손실 ÷ 원화 환산 금액 이 작은 순서로 부족액이 메워질 때까지 고릅니다. 금액이 큰 예금이 손실도 크게 보이는 왜곡을 줄이려고 손실을 원화 환산 금액으로 나눈 비율로 정렬했습니다. 이 순서는 제안일 뿐이며 계약 조건과 은행 협의 가능 여부는 회사가 판단합니다.

Q: 구간 비중은 무엇으로 나눕니까?

구간 만기 도래액을 회사 예치 총액 으로 나눕니다. 회사별로 따로 계산하므로 두 회사의 규모가 달라도 비중을 서로 비교할 수 있습니다. 샘플에서 회사 1000 의 31~90일 구간은 120.64억 원 ÷ 460.54억 원 = 26.20% 로 가정 기준 25% 를 넘어 집중으로 표시됩니다. 집중 기준 25% 는 샘플의 가정값이며 정책으로 정합니다.

Q: 점검 코드 D 와 B 는 무엇이 다릅니까?

D 로 시작하는 코드는 예금 한 건 의 판정이고 B 로 시작하는 코드는 구간 한 행 의 판정입니다. 점검 코드 조건에 D 코드를 고르면 예금별 판정 탭이, B 코드를 고르면 만기 구간 탭이 그 조건으로 좁혀지며 다른 탭에는 걸리지 않습니다.

소개 영상1분 40초8개 장면음성 안내·자막표지 → 처음 연 화면 → 조건 좁히기 → 만기 구간 → 해지·재예치 제안 → 예금 상세 → 대사 결과 → 정리

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

자금 담당자가 월말이면 부딪히는 질문은 늘 같습니다. 다음 한 달 안에 만기가 오는 예금이 얼마이고, 같은 기간에 나갈 돈보다 많은가 모자란가. 예금이 여러 은행과 여러 통화에 흩어져 있으면 이 질문 하나에 답하려고 은행 조회 화면과 엑셀 표를 오가며 만기일을 손으로 묶게 됩니다. 이 앱은 정기예금과 외화예금의 만기를 남은 일수 구간으로 모아 지급 예정 소요와 나란히 놓고, 만기가 한쪽 구간에 몰렸는지와 소요에 못 미치는 구간이 어디인지를 먼저 가려 보여 줍니다.

그 다음 질문은 “모자라면 어떤 예금을 깨야 하나” 입니다. 만기가 더 늦게 오는 예금 가운데 중도해지로 잃는 이자가 적은 것부터 골라 부족액을 메우는 안을 만들고, 해지하고도 남는 구간 잔여는 다시 예치할 수 있는 금액으로 보여 줍니다. 이 화면은 분류·집계·대사를 돕는 점검 도구이며, 해지와 재예치의 최종 판단은 회사가 하고 장부와 공시에 대한 판단은 회사와 감사인이 합니다. 화면에 나오는 환율·약정이율·중도해지이율·집중 기준·지급 예정 소요는 모두 샘플의 가정값입니다.

한 줄 요약 — 예금 잔액표는 “얼마 있나” 를 말해 주고, 이 앱은 “언제 돌아오고, 그때 쓸 돈에 모자란 곳이 어디이며, 어느 예금을 깨면 이자를 가장 덜 잃나” 를 말해 줍니다. 구간 합계와 예치 총액이 어긋나지 않는지는 화면이 대사 결과로 매번 보여 줍니다.

만기가 한 구간에 몰리면 같은 날 같은 결정을 여러 번 하게 된다

은행별로 만기일을 따로 관리하면 각 예금은 “재예치하면 됨” 으로 보입니다. 그런데 회사 전체로 모아 보면 예치액의 4분의 1 이상이 같은 석 달 구간에 몰려 있을 수 있습니다. 이 앱은 구간 만기 도래액을 회사 예치 총액으로 나눈 비중을 구하고, 가정값 25% 를 넘는 구간에 집중 표시를 붙입니다. 샘플 29건에서는 세 구간이 걸렸고, 그 구간의 예금은 재예치 시점을 나누는 안을 검토하라는 점검 코드가 붙습니다.

소요가 만기액보다 큰 구간은 잔액표에 보이지 않는다

예치 총액이 665억 원이어도 다음 7일 구간에 만기가 오는 금액이 그 주에 나갈 돈보다 작으면 자금은 모자랍니다. 잔액표는 총액만 보여 주므로 이 모자람이 드러나지 않습니다. 구간마다 만기 도래액과 지급 예정 소요를 견주어 부족액을 계산하고, 앞 구간에서 해지 대상이 된 금액까지 반영해 다음 구간으로 넘깁니다.

예금을 깨는 순서가 이자 손실을 정한다

부족액을 메우려고 가장 가까운 예금부터 깨면 손실이 커질 수 있습니다. 이 앱은 더 늦은 구간의 예금 가운데 “중도해지 이자 손실 ÷ 원화 환산 금액” 이 작은 것부터 고릅니다. 한 번에 예금 한 건을 통째로 해지한다고 가정하므로, 부족액보다 큰 예금이 뽑히면 남는 금액을 초과 해지분으로 따로 보여 줍니다. 일부 해지가 가능한 상품이면 회사가 금액을 줄여 판단할 수 있습니다.

외화 예금은 더하는 순간 의미가 사라진다

달러 예금과 유로 예금의 원금을 그대로 더하면 의미가 없습니다. 통화별 외화 원금은 더하지 않고 원화 환산 금액으로만 합산하며, 환산에는 샘플의 가정 환율을 씁니다. 운영에서는 환율 유형과 환산 시점을 정해 표준 환율 테이블에 연결합니다.

사용 방법

조회조건을 입력합니다. 회계연도와 기간(월)은 필수이며 기본값은 2026 · 09 입니다. 회사 · 은행(이름 일부) · 통화 · 만기 구간 · 만기일 시작/종료 · 점검 코드 · 점검 결과는 선택이고 비워 두면 전체입니다.
조회 버튼은 조회조건 영역 안 입력 필드들의 가장 오른쪽에 있고, 입력 필드에서 Enter 키를 눌러도 같은 조회가 실행됩니다. 처음 열 때는 기본 조건으로 한 번 자동 조회합니다.
위쪽 요약 여덟 칸을 읽습니다 — 점검한 예금 · 예치 총액 · 30일 내 만기 · 만기 집중 구간 · 해지 검토 합계 · 예상 이자 손실 · 확인 필요 예금 · 정합성 대사 차이. 만기·해지 금액은 백만원 단위입니다.
탭은 예금별 판정 → 만기 구간 → 해지·재예치 제안 → 대사 결과 순서로 봅니다. 앞 탭에서 점검 필요인 예금과 구간을 찾고, 다음 탭에서 부족액 충당안을 확인하고, 마지막 탭에서 숫자가 맞는지 대사합니다.
예금별 판정의 행을 누르면 상세 창이 열립니다. 외화 원금과 가정 환율, 개시일~만기일, 경과 이자와 중도해지 이자 손실, 점검 코드의 판정 근거, 그 예금과 관련된 제안이 나옵니다.
지금 보는 탭의 조회 결과는 CSV 내려받기 버튼으로 받습니다(UTF-8).

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

만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 아래 일곱 식은 모두 차이가 0 입니다. 이와 별도로 예금별 원화 환산 · 잔여일 · 경과 이자 · 손실을 독립 스크립트로 다시 계산해 116개 값이 모두 일치했습니다.

대사식	검사 건수	차이 건수	최대 차이
외화 원금 × 가정 환율 = 원화 환산 금액	29	0	0
구간별 만기 도래액 합계 = 예금 원화 환산 총액	2	0	0
구간별 예금 건수 합계 = 전체 건수	2	0	0
만기액 − 해지 제외분 + 충당액 − 소요 = 구간 잔여	12	0	0
해지 제안 금액 합계 = 구간별 해지 제외분 합계	3	0	0
충당액 합계 = 부족액 합계 − 충당 불가 금액	3	0	0
해지 제안 금액 − 초과 해지분 = 충당액	3	0	0

의도적 예외는 대사 차이와 분리해 따로 셉니다 — 만기 경과 미처리 2건(회사별 1건), 약정이율 미입력 1건, 충당 불가 구간 1개입니다. 점검 화면이 어떻게 보이는지 보여 주려고 일부러 넣은 건입니다. 모든 값은 검증용 샘플 데이터이며 은행과 계좌는 가상입니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면	OpenUI5 표준 컨트롤 — 조회조건 · 요약 여덟 칸 · 네 개 탭 · 상세 창	외부 라이브러리 없이 표준 컨트롤만 써서 사내망 반입 심사를 줄입니다.
데이터 연결	OData V2 서비스를 manifest 의 상대 경로로 선언하고, 예금 · 구간 · 제안 · 대사 네 종류의 데이터를 탭마다 바인딩	탭마다 필요한 만큼만 받고, 조회조건은 필터 객체로 보내 서버가 걸러 줍니다. 전체를 뜻하는 값은 조건에서 뺍니다.
판정·산출 로직	서비스 쪽 스크립트 한 곳에 구간 배정, 이자 손실, 해지 제안 선택, 대사 산출을 둠	화면은 받은 값을 보여 주기만 합니다. 판정 규칙을 바꿀 때 화면을 건드리지 않습니다.
요약 계산	예치 총액 · 해지 검토 합계 · 예상 이자 손실은 컨트롤러 한 곳에서 합산, 30일 내 만기와 집중 구간 수는 서비스 함수 호출	같은 값을 두 군데서 계산해 서로 달라지는 일을 막습니다.
오류 처리	메타데이터 실패 · 요청 실패 · 빈 응답을 구분해 안내	“안 나온다” 가 서버 문제인지 조건 문제인지 가려 줍니다.
테마	SAP Horizon	표준 Fiori 화면과 같은 결이라 사용자가 낯설어하지 않습니다.

SAP 표준 기능을 그대로 이어받은 부분

예금 계정의 잔액과 이자 수익은 총계정원장 전표 라인에서, 은행과 계좌는 하우스 은행·계좌 마스터에서, 환율은 표준 환율 테이블에서 이어받는 구조입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 만기 구조와 소요를 견주는 조회·검증 관점을 더해 확장합니다. 법정 보고와 감사 대응은 표준 거래에 그대로 둡니다.

실행 화면

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

처음 열었을 때

조회조건, 요약 여덟 칸, 네 개 탭이 한 화면에 세로로 쌓입니다. 처음 열 때 기본 조건으로 한 번 자동 조회하므로 빈 화면을 보지 않습니다.

**처음 연 화면 — 조회조건 · 요약 · 예금별 판정** — 처음 열면 기본 조건(2026년 9월)으로 한 번 자동 조회해 예금 29건이 만기일 순서로 보입니다. 조회조건 오른쪽 끝에 조회·초기화 버튼이 있고, 그 아래에 요약 여덟 칸과 네 개 탭이 이어집니다.

요약 칸은 왼쪽부터 점검한 예금, 예치 총액, 30일 내 만기, 만기 집중 구간 순입니다. 예치 총액은 665.49억 원이고 30일 안에 만기가 오는 금액은 153.8억 원입니다. 만기·해지 금액은 백만원 단위로 줄여 보여 줍니다. 점검 결과 열의 글자색이 정상·점검 필요·확인 필요를 구분하며, 행은 회사와 만기일 순서로 놓여 만기 흐름이 먼저 읽힙니다.

조건을 좁혀 보기

은행 몇 곳이나 점검 결과처럼 보고 싶은 범위가 정해져 있을 때는 조회조건을 채워 좁힙니다. 요약과 탭의 건수가 같은 범위로 함께 바뀝니다.

**회사·은행·점검 결과로 좁힌 조회** — 회사 1000, 은행 “가상은행 A”, 점검 결과 “점검 필요” 를 고른 뒤 조회한 모습입니다. 조건에 맞는 예금 3건만 남고 요약 칸도 같은 범위로 다시 계산됩니다.

요약은 예치 총액 125억 원, 30일 내 만기 94.3억 원, 집중 구간 2곳으로 바뀝니다. 은행은 이름 일부만 적어도 걸립니다(부분 일치). 전체를 뜻하는 값은 코드로 보내지 않고 해당 조건을 아예 빼기 때문에, 비워 두면 전체가 조회됩니다. 만기일은 시작과 종료를 둘 다 넣을 때만 범위 하나로 묶어 서버에 보냅니다.

만기가 어디에 몰렸고 어디가 모자란가 — 만기 구간

이 앱의 중심 화면입니다. 예금을 남은 일수로 여섯 구간에 모아 회사별로 만기 도래액과 지급 예정 소요를 견줍니다. 구간 비중이 가정 기준을 넘으면 집중, 소요에 못 미치면 부족액이 붙습니다.

**만기 구간 탭 — 구간별 만기액 · 소요 · 부족액 · 집중 판정** — 남은 일수로 만기 경과 · 1~7일 · 8~30일 · 31~90일 · 91~180일 · 181일 이상 여섯 구간을 회사별로 묶습니다. 구간마다 만기 도래액과 지급 예정 소요를 견주어 부족액과 구간 비중을 보여 줍니다.

회사 1000 의 31~90일 구간은 만기액이 120.64억 원으로 회사 예치 총액의 26.20% 라서 가정 기준 25% 를 넘어 집중 표시가 붙습니다. 같은 회사 1~7일 구간은 만기액 35억 원에 소요 40억 원이라 5억 원이 부족합니다. 소요는 샘플의 가정값이며, 운영에서는 유동성 예측의 지급 예정에서 가져옵니다.

그래서 어느 예금을 깨고 얼마를 다시 맡기나 — 해지·재예치 제안

부족한 구간은 더 늦게 만기가 오는 예금으로 메우고, 남는 구간은 재예치 가능 금액으로 보여 줍니다. 제안은 검토용 안이며 실행 여부는 회사가 정합니다.

**해지·재예치 제안 탭 — 부족액을 메우는 안과 재예치 가능 금액** — 부족한 구간마다 더 늦게 만기가 오는 예금 가운데 이자 손실이 작은 것을 골라 해지 검토 안을 만듭니다. 해지하고도 남는 구간 잔여는 재예치 가능 금액으로, 후보를 모두 써도 못 메우면 충당 불가로 따로 보입니다.

샘플에서는 해지 검토 3건(해지 금액 122억 원, 충당액 31.55억 원, 초과 해지분 90.45억 원), 충당 불가 1건(9억 원), 재예치 가능 6건(합계 223.04억 원)이 나옵니다. 해지 검토 3건의 예상 이자 손실은 합쳐 약 629만 원입니다. 초과 해지분이 큰 건은 예금 단위로 해지하는 가정 때문이므로, 일부 해지가 가능한지는 회사가 계약을 보고 판단합니다.

숫자가 맞는지 — 대사 결과

화면의 숫자끼리 서로 맞는지를 식 한 줄씩 보여 줍니다. 마감 회의에서 “이 합계가 어디서 나왔나” 를 묻기 전에 먼저 확인하는 자리입니다.

**대사 결과 탭 — 대사식과 의도적 예외 건수** — 구간 합계와 예치 총액, 해지 제안 합계와 해지 제외분 합계처럼 서로 맞아야 하는 숫자를 식 한 줄씩 보여 줍니다. 각 줄에 좌변 · 우변 합계, 검사 건수, 차이 건수가 붙습니다.

정합성 대사 일곱 식은 차이 건수가 모두 0 입니다. 아래쪽 세 줄은 의도적 예외로, 만기 경과 미처리 · 약정이율 미입력 · 충당 불가 구간처럼 점검 화면을 보여 주려고 넣은 건이라 대사 차이와 섞이지 않게 따로 셉니다. 요약의 “정합성 대사 차이” 칸에는 정합성 대사의 차이가 나오며 샘플에서는 0 입니다.

예금 한 건을 들여다보기

표에서 예금 행을 누르면 열리는 상세 창에서 이자 손실이 어떻게 나왔는지 따라갈 수 있습니다.

**예금 행 상세 — 이자 손실과 관련 제안** — 예금 행을 누르면 열리는 상세 창입니다. 외화 원금과 가정 환율, 개시일~만기일, 잔여일과 구간, 약정이율과 중도해지이율, 경과 이자와 중도해지 이자, 중도해지 이자 손실이 차례로 나오고 그 예금에 걸린 제안이 아래에 붙습니다.

경과 이자는 원화 환산 금액 × 약정이율 × 경과일 ÷ 365, 중도해지 이자는 같은 식에 중도해지이율(샘플은 약정이율의 40% 가정)을 넣고 두 값의 차이가 이자 손실입니다. 점검 코드의 판정 근거 문장도 함께 나와, 왜 점검 필요인지 표를 다시 찾지 않아도 됩니다. 이 예금(3,200,000,000원, 약정이율 3.85%)의 이자 손실은 2,025,205원이며, 약정이율이 비어 있는 예금은 손실을 산출하지 않고 확인 필요로 남깁니다.

좁은 화면에서 달라지는 것

창 폭이 줄면 조회조건이 여러 줄로 나뉘고 요약 칸이 네 칸씩 두 줄로 접힙니다. 표는 가로로 밀어 보며 앞의 두 열이 제자리에 남습니다.

**좁은 화면 — 휴대폰 폭에서도 같은 조회** — 화면이 좁아지면 조회조건이 여러 줄로 나뉘고 요약 칸은 네 칸씩 두 줄로 접힙니다. 이 그림은 점검 코드를 해지 검토 대상으로 고르고 조회한 모습입니다.

표는 가로로 밀어 보되 앞의 두 열(회사 · 예금번호)은 제자리에 남습니다. 가로 폭이 좁을 때도 탭과 조회 버튼의 순서는 그대로입니다. 외근 중에 만기 임박 건을 확인하는 정도의 용도를 염두에 두었고, 해지·재예치 판단처럼 숫자를 견주는 일은 넓은 화면에서 하는 편이 낫습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 조회조건이 필터 객체로 만들어져 서비스에 전달되고, 서비스가 구간 배정 → 원화 환산 → 경과 이자와 이자 손실 → 구간 집계 → 해지·재예치 제안 → 대사 순서로 산출한 결과를 탭마다 돌려줍니다. 화면은 계산하지 않고 받은 값을 보여 줍니다. 요약의 30일 내 만기와 집중 구간 수는 서비스 함수를 따로 불러 받습니다.

순서	산출·대사식	내용
1	잔여일 = 만기일 − 기준일(2026-09-30)	구간 배정 — 0 미만 만기 경과 · 0~7 · 8~30 · 31~90 · 91~180 · 181 이상
2	원화 환산 금액 = 외화 원금 × 가정 환율	통화별 원금은 더하지 않고 원화 환산 금액으로만 합산
3	경과 이자 = 원화 환산 금액 × 약정이율 × 경과일 ÷ 365	경과일은 개시일부터 기준일까지이며 약정 기간을 넘지 않음
4	중도해지 이자 손실 = 경과 이자 − 중도해지 이자	중도해지 이자는 같은 식에 중도해지이율(샘플은 약정이율의 40%, 가정값)
5	구간 비중 = 구간 만기 도래액 ÷ 회사 예치 총액	가정값 25% 초과 시 집중
6	구간 잔여 = 만기액 − 해지 제외분 + 충당액 − 소요	해지 제안이 반영된 구간별 최종 자금 상태
7	대사 — 구간 합계 = 예치 총액 · 해지 제안 합계 = 해지 제외분 합계	대사 결과 탭에서 건수·차이 확인

예금별 판정 — 점검 코드와 사용자 조치

예금 한 건에는 점검 코드가 하나 붙고, 위에서부터 먼저 해당하는 코드를 적용합니다.

점검 코드	판정 조건	결과 상태	사용자 조치
D05	약정이율이 비어 있거나 0 이하	확인 필요	예금 계약의 이율 조건을 회사가 먼저 확인합니다. 이자 재계산과 해지 손실은 산출하지 않습니다.
D01	만기일이 기준일보다 앞서는데 처리되지 않은 예금	점검 필요	재예치 또는 입금 여부를 확인하고 만기 경과 구간에서 따로 봅니다.
D04	구간 부족액을 메우려고 해지 검토 대상으로 뽑힌 예금	점검 필요	해지 이자 손실과 초과 해지분을 보고 해지할지 정합니다.
D02	구간 비중이 집중 기준(가정값 25%)을 넘는 구간에 속한 예금	점검 필요	재예치 시점을 나누는 안을 검토합니다.
D00	위에 해당하지 않음	정상	-

만기 구간 판정과 해지·재예치 제안 선택 규칙

점검 코드	판정 조건	결과 상태	사용자 조치
B04	해지 가능한 예금을 모두 써도 부족액이 남음(충당 불가)	확인 필요	다른 자금원을 회사가 확인합니다.
B02	구간 만기 도래액이 지급 예정 소요보다 작음(부족액 발생)	점검 필요	해지·재예치 제안 탭의 충당안을 확인합니다.
B01	구간 비중이 집중 기준(가정값 25%)을 넘음	점검 필요	만기가 몰린 구간의 재예치 시점 분산을 검토합니다.
B05	만기 경과 구간에 예금이 남아 있음	점검 필요	재예치 또는 입금 여부를 정리합니다.
B00	위에 해당하지 않음	정상	-

단계	규칙	결과
1	구간을 만기 경과 → 1~7일 → … → 181일 이상 순서로 훑는다	구간별 부족액 = 지급 예정 소요 − (만기 도래액 − 앞서 해지 대상이 된 금액)
2	부족액이 있으면 더 늦은 구간의 예금 가운데 약정이율이 있는 것만 후보로 둔다	후보 목록
3	후보를 해지 이자 손실 ÷ 원화 환산 금액이 작은 순서로 정렬해 부족액이 메워질 때까지 예금 단위로 고른다	해지 검토 제안, 충당액 · 초과 해지분
4	후보를 모두 써도 남는 금액이 있으면 충당 불가로 남긴다	충당 불가 제안, B04 확인 필요
5	해지 후에도 소요를 넘는 구간 잔여는 재예치 가능 금액으로 보여 준다(만기 경과 구간 제외)	재예치 가능 제안

조회조건

조회조건	필수	기본값	서비스로 가는 조건	걸리는 탭
회계연도	필수	2026	연도 일치(모든 탭, 대사는 연도만)	전체
기간(월)	필수	09	월 일치	예금 · 구간 · 제안
회사	선택	전체	일치 — 전체이면 조건 제외	예금 · 구간 · 제안
은행	선택	전체	이름 일부 포함	예금 · 제안
통화	선택	전체	일치	예금 · 제안
만기 구간	선택	전체	구간 번호 일치	예금 · 구간 · 제안
만기일 시작/종료	선택	전체	이상 · 이하(둘 다 있으면 범위 하나로)	예금
점검 코드	선택	전체	일치 — D 로 시작하면 예금, B 로 시작하면 구간	예금 · 구간
점검 결과	선택	전체	일치	예금 · 구간

결과 컬럼

탭	주요 컬럼	의미
예금별 판정	외화 원금 · 가정 환율 · 원화 환산 금액 · 만기일 · 잔여일 · 구간 · 약정이율 · 경과 이자 · 중도해지 이자 · 이자 손실 · 점검 코드	예금 한 건의 만기 위치와 이자 손실, 점검 결과
만기 구간	만기 도래액 · 지급 예정 소요 · 만기액 − 소요 · 비중 · 집중 · 부족액 · 해지 제외분 · 충당액 · 충당 불가 · 구간 잔여	구간별 자금 상태와 해지 반영 후 잔여
해지·재예치 제안	제안 구분 · 구간 · 예금번호 · 금액 · 예상 이자 손실 · 충당액 · 초과 해지분 · 제안 근거	해지 검토안과 재예치 가능 금액
대사 결과	좌변 합계 · 우변 합계 · 검사 건수 · 차이 건수 · 최대 차이 · 대사식	화면 숫자끼리의 일치 여부

파일 구성

앱 폴더
├─ index.html · Component.js · manifest.json
├─ controller/  BaseController.js · Main.controller.js
├─ view/        Main.view.xml · DetailDialog.fragment.xml
├─ model/       formatter.js · ErrorHandler.js
├─ css/ · i18n/
├─ odata/       서비스 선언 · 산출 로직 · 샘플 데이터 파일
├─ media/       소개 영상
└─ readme.html  설명서

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 예금의 만기 구조와 지급 소요를 견주는 자리만 이어 붙이는 쪽으로 만들었습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

하고 싶은 일	SAP 표준	표준에서 걸리는 자리	이 앱이 하는 일
계정별 현금·예금 잔액과 흐름	`FF7A`	잔액과 일자별 포지션이 중심이라, 예금 한 건씩의 만기를 구간으로 묶어 비중을 보는 관점은 따로 만들어야 합니다	예금 만기를 남은 일수 구간으로 묶어 비중과 집중을 보여 줍니다
지급 예정을 반영한 유동성 예측	`FF7B` · `FF63`	예측 항목은 일자·계획 수준이라 “어느 만기 구간의 예금으로 메울 것인가” 까지는 다루지 않습니다	구간별 지급 예정 소요와 만기 도래액을 견주어 부족액을 계산합니다
예금 계정 전표 확인	`FBL3N`	개별 전표를 열어 보는 화면이라 구간 합계와 맞추는 일은 사람이 합니다	구간 합계와 예치 총액이 맞는지 대사 결과로 보여 줍니다
외화 예금 기말 평가	`FAGL_FCV`	평가 실행과 전표 생성이 목적이라 만기 구간 점검용 환산과는 용도가 다릅니다	가정 환율로 원화 환산만 하며 평가는 표준에 남깁니다
중도해지 시 이자 손실 비교	표준에 없는 자리	예금 계약 조건을 보고 사람이 따로 계산합니다	약정이율과 중도해지이율(가정값)로 손실을 계산해 해지 순서를 제안합니다
만기 집중 점검	표준에 없는 자리	구간 비중을 계산하는 화면이 없어 엑셀로 만들게 됩니다	구간 비중이 기준을 넘으면 집중 표시와 점검 코드를 붙입니다

T-code 별 연계 지점

표준 T-code	이름	이 앱과의 연계
`FF7A`	현금 포지션	같은 현금·예금 계정의 잔액 흐름을 표준에서 확인하고, 이 앱 결과의 예치 총액과 맞춰 봅니다. 이 앱의 구간 합계가 맞지 않으면 먼저 계정 범위를 비교합니다. 법정·감사 대응은 표준에 남깁니다.
`FF7B`	유동성 예측	표준 유동성 예측의 지급 예정과 이 앱의 구간별 소요를 맞춰 볼 수 있습니다. 운영에서는 소요를 이 예측 항목에서 가져오도록 연결합니다.
`FF63`	유동성 예측: 개별 항목 입력	예측 항목을 입력하는 표준 화면입니다. 이 앱은 입력된 예정액을 구간 소요로 읽는 관점입니다. 소요가 바뀌면 이 화면에서 입력하고 이 앱에서 다시 조회합니다.
`FBL3N`	G/L 계정 라인 아이템 조회	이 앱의 예금 원금이 의심스러울 때 예금 계정의 개별 전표로 내려가 원천을 확인합니다.
`FAGL_FCV`	외화 평가	외화 예금의 기말 평가는 표준에서 실행합니다. 이 앱의 환산은 점검용 가정 환율이므로 평가 금액과 다를 수 있습니다.

운영 전환 때 “기존 리포트를 없애야 하나” 하는 질문에는 없애지 않습니다가 답입니다. 표준 화면은 잔액·예측·평가의 기준 화면으로 그대로 쓰고, 이 앱은 그 위에서 만기 구조를 점검하는 보조 화면입니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱은 잔액과 흐름을 여러 각도로 보는 데 강합니다. 이 앱은 그 옆에서 “예금 한 건의 만기와 이자 조건” 이라는 계약 단위 자료를 읽어 구간으로 묶는 점이 다릅니다. 표준 앱 가운데 어느 것이 같은 일을 하는지는 이 글에서 확인하지 못한 항목이므로 이름을 적지 않았고, 도입할 때 환경의 앱 목록과 견주어 보는 일이 먼저입니다. 같은 CDS 뷰를 표준 분석 도구가 그대로 읽게 만들 수 있도록 아래 CDS 구성에서는 분석 쿼리까지 나눠 두었습니다.

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

자리	무엇을 손대나	왜 고객사마다 다른가
예금 계약 정보	개시일 · 만기일 · 약정이율을 어디서 읽을지	금융거래 관리를 쓰는 회사는 거래 헤더·흐름에서, 쓰지 않는 회사는 별도 마스터나 확장 필드에서 읽습니다(확인 필요)
예금 계정 범위	어느 계정을 정기예금·외화예금으로 볼지	계정 체계가 회사마다 다릅니다
구간 경계와 집중 기준	구간 일수와 집중 기준 비율	샘플은 7 · 30 · 90 · 180일과 25%(가정값)이지만 정책으로 정합니다
지급 예정 소요	소요를 읽어 올 예측 항목과 구간 배분 방식	유동성 예측 항목 구성이 다릅니다(확인 필요)
중도해지이율	예금 상품별 중도해지 조건	샘플은 약정이율의 40% 가정이며 실제는 계약마다 다릅니다
환율	환율 유형과 환산 시점	기말 환율인지 거래일 환율인지는 회사 정책입니다
권한	회사코드 · 은행 계좌 단위 조회 권한	자금 정보는 담당자만 보도록 제한하는 곳이 많습니다

CDS 구성

이 사례의 화면은 예금 29건과 구간 12행을 서비스가 산출해 돌려줍니다. 데모라서 되는 일이고, 운영 데이터에서는 집계를 CDS 로 내려야 합니다. 운영으로 올릴 때 가장 먼저 하는 일이 구간 분류와 구간 집계를 DB 에서 하도록 뷰로 만드는 것입니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 예금 계약의 개시일·만기일·약정이율은 환경에 따라 읽을 곳이 달라 “확인 필요” 로 남겼습니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	`ZDLAD_POLICY`	구간 경계 · 집중 기준 · 중도해지이율 배율을 담은 정책 테이블	정책은 자금팀이 바꾸는 값입니다. 코드에 박으면 바뀔 때마다 개발자를 부르게 됩니다.
차원	`ZI_DepositContract`	예금 계약 한 행 + 은행 + 통화 + 약정이율	큐브에서 조인을 한 번만 걸고, 값 도움말도 이 뷰 하나를 보게 합니다.
큐브(예금)	`ZI_DepositLadderCube`	잔여일 · 구간 번호 · 원화 환산 · 경과 이자 · 해지 손실 산출	화면과 서비스가 하던 계산을 DB 로 내립니다.
큐브(구간)	`ZI_DepositBucketCube`	회사 × 구간으로 만기액 · 소요 · 부족액 · 비중 집계	부족액과 비중을 한 곳에서만 정의합니다.
쿼리	`ZC_DepositLadderQuery`	구간 행 · 측정값 기본 배치	표준 Fiori 와 Analysis for Office 가 그대로 띄웁니다.
권한	`ZI_DEPOSITLADDERCUBE` (DCL)	회사코드 단위 조회 제한	집계를 읽는 자리에 걸어야 합계로 새지 않습니다.
서비스	`ZUI_DepositLadder`	OData V2 서비스 정의와 바인딩	화면의 조회를 이 서비스 하나로 받습니다.

① 정책 테이블 — 구간 경계와 집중 기준

구간을 며칠로 자르고 몇 퍼센트부터 집중으로 볼지는 코드가 아니라 정책 값입니다. 운영 전환에서 가장 먼저 합의해야 하는 항목이며, 유효 기간을 두어 정책이 바뀌어도 과거 점검 결과가 흔들리지 않게 합니다.

" ────────────────────────────────────────────────────────────────
"  ZDLAD_POLICY — 만기 구간 정책 (투명 테이블)
"  구간 경계(일), 집중 기준(%), 중도해지이율 배율(%)을 담는다.
"  코드에 박지 않는 이유 : 정책은 자금팀이 바꾸는 값이고,
"  바꿀 때마다 개발자를 부르면 점검 기준이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '예금 만기 구간 정책'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdlad_policy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key bucket_no  : abap.numc(1) not null;   " 0 만기 경과 ~ 5 181일 이상
  valid_from     : abap.dats;               " 유효 시작일
  from_day       : abap.int4;               " 구간 시작 잔여일
  to_day         : abap.int4;               " 구간 끝 잔여일
  conc_pct       : abap.dec(5,2);           " 집중 기준(%), 샘플 가정값 25.00
  brk_rate_pct   : abap.dec(5,2);           " 중도해지이율 / 약정이율 (%), 샘플 가정값 40.00
}

② 예금 계약 차원 뷰

예금 한 건의 개시일·만기일·약정이율을 한 행으로 모으는 뷰입니다. 이 뷰가 어디서 읽느냐가 도입의 첫 질문입니다. 금융거래 관리를 쓰면 거래 헤더·흐름에서, 아니면 별도 마스터나 확장 필드에서 읽습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_DepositContract — 예금 계약 한 행
"  개시일 · 만기일 · 약정이율의 원천은 환경에 따라 다르다.
"  아래는 금융거래 관리(VTBFHA)를 쓰는 경우의 스케치이며
"  실제 필드와 조인 조건은 확인 필요.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '예금 계약'
@ObjectModel.usageType: { serviceQuality: #B, sizeCategory: #L, dataClass: #TRANSACTIONAL }
define view entity ZI_DepositContract
  as select from vtbfha as h
  association [0..1] to t012 as _HouseBank
    on _HouseBank.bukrs = h.bukrs
{
  key h.bukrs                       as CompanyCode,
  key h.rfha                        as DepositId,     // 금융거래 번호(확인 필요)
      h.dbLaufz                     as StartDate,     // 개시일 필드명 확인 필요
      h.dende                       as MaturityDate,  // 만기일 필드명 확인 필요
      _HouseBank.hbkid              as HouseBank,
      h.waers                       as Currency
}

③ 예금 단위 큐브 — 구간 분류와 이자 손실

화면과 서비스가 하던 계산을 DB 로 내리는 뷰입니다. 구간 분류는 정책 테이블을 조인해 case 가 아니라 범위 조건으로 하므로 구간이 바뀌어도 이 뷰는 그대로입니다. 외화는 환율 변환 함수로 원화 환산하며, 환율 유형과 환산 시점은 운영에서 정합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_DepositLadderCube — 예금 한 건의 잔여일 · 구간 · 원화 환산 · 이자 손실
"  구간은 ZDLAD_POLICY 의 from_day ~ to_day 범위로 찾는다.
"  경과 이자 = 원화 환산 × 약정이율 × 경과일 ÷ 365
"  중도해지 손실 = 경과 이자 × (1 − 중도해지이율 배율)
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '예금 단위 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_DepositLadderCube
  with parameters
    p_keydate : abap.dats
  as select from ZI_DepositContract as c
    inner join   zdlad_policy       as p
      on  p.bukrs     = c.CompanyCode
      and dats_days_between( $parameters.p_keydate, c.MaturityDate ) between p.from_day and p.to_day
    inner join   ZI_DepositBalance  as b      // 예금 계정 잔액 뷰 — ACDOCA 집계(확인 필요)
      on  b.CompanyCode = c.CompanyCode
      and b.DepositId   = c.DepositId
{
  key c.CompanyCode,
  key c.DepositId,
      p.bucket_no                                             as BucketNo,
      dats_days_between( $parameters.p_keydate, c.MaturityDate ) as DaysToMat,
      c.Currency,
      @Semantics.amount.currencyCode: 'Currency'
      b.Principal,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      currency_conversion( amount             => b.Principal,
                           source_currency    => c.Currency,
                           target_currency    => b.LocalCurrency,
                           exchange_rate_date => $parameters.p_keydate,
                           exchange_rate_type => 'M',            // 환율 유형은 정책으로 정함
                           error_handling     => 'SET_TO_NULL' ) as PrincipalLocal,
      b.LocalCurrency
}

④ 구간 큐브 — 만기 도래액 · 소요 · 부족액 · 비중

회사와 구간으로 묶어 만기 도래액을 더하고, 지급 예정 소요를 붙여 부족액과 비중을 계산합니다. 부족액과 비중의 정의는 이 뷰 한 곳에만 두어, 화면이 늘어도 숫자가 갈라지지 않게 합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_DepositBucketCube — 회사 × 구간 집계
"  부족액 = max( 소요 − 만기 도래액, 0 )   (해지 반영 전)
"  비중   = 구간 만기 도래액 ÷ 회사 예치 총액
"  소요(ZI_PayNeedPlan)는 유동성 예측 항목에서 가져온다 — 확인 필요
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '만기 구간 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_DepositBucketCube
  with parameters
    p_keydate : abap.dats
  as select from ZI_DepositLadderCube( p_keydate : $parameters.p_keydate ) as d
    left outer join ZI_PayNeedPlan as n
      on  n.CompanyCode = d.CompanyCode
      and n.BucketNo    = d.BucketNo
{
  key d.CompanyCode,
  key d.BucketNo,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( d.PrincipalLocal )                                  as MaturityAmount,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      max( coalesce( n.NeedAmount, 0 ) )                       as NeedAmount,
      count( * )                                               as DepositCount,
      d.LocalCurrency
}
group by d.CompanyCode, d.BucketNo, d.LocalCurrency

⑤ 분석 쿼리 — 구간 행과 측정값

구간 큐브 위에 행 축과 측정값의 기본 배치를 얹는 쿼리입니다. 표준 Fiori 분석 화면이나 Analysis for Office 가 이 쿼리를 그대로 읽습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_DepositLadderQuery — 만기 구간 분석 쿼리
"  행 : 회사 › 구간 / 측정값 : 만기 도래액 · 소요 · 부족액 · 비중
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '예금 만기 구간 쿼리'
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define view entity ZC_DepositLadderQuery
  with parameters
    @Consumption.derivation: { lookupEntity: 'I_CalendarDate', resultElement: 'CalendarDate' }
    p_keydate : abap.dats
  as select from ZI_DepositBucketCube( p_keydate : $parameters.p_keydate )
{
  @AnalyticsDetails.query.axis: #ROWS
  @AnalyticsDetails.query.displayHierarchy: #ON
  key CompanyCode,
  @AnalyticsDetails.query.axis: #ROWS
  key BucketNo,
  @AnalyticsDetails.query.axis: #COLUMNS
  MaturityAmount,
  @AnalyticsDetails.query.axis: #COLUMNS
  NeedAmount,
  @AnalyticsDetails.query.axis: #COLUMNS
  @EndUserText.label: '부족액'
  case when NeedAmount > MaturityAmount
       then NeedAmount - MaturityAmount else 0 end             as ShortAmount,
  @AnalyticsDetails.query.axis: #COLUMNS
  @EndUserText.label: '비중(%)'
  division( MaturityAmount * 100, 
            sum( MaturityAmount ) over( partition by CompanyCode ), 2 ) as SharePct
}

⑥ 권한 — 회사코드 단위 조회 제한

권한은 집계를 읽는 자리에 걸어야 합니다. 상세에만 걸면 구간 합계에서 남의 회사 금액을 빼서 알아낼 수 있기 때문입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_DEPOSITLADDERCUBE — 회사코드 단위 조회 권한 (DCL)
"  자금 정보는 담당 회사코드만 보도록 제한한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '예금 만기 큐브 권한'
@MappingRole: true
define role ZI_DEPOSITLADDERCUBE {
  grant select on ZI_DepositLadderCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
  grant select on ZI_DepositBucketCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

화면은 이 서비스 하나로 조회합니다. OData V2 로 게시해 앱의 manifest 에 서비스 주소를 바꿔 넣으면 연결이 끝납니다. 서비스 활성화는 게이트웨이 서비스 유지보수 트랜잭션에서 합니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_DepositLadder — 서비스 정의 + 바인딩
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '예금 만기 사다리 서비스'
define service ZUI_DepositLadder {
  expose ZI_DepositLadderCube   as Deposit;
  expose ZI_DepositBucketCube   as Bucket;
}

" 서비스 바인딩 : 유형 OData V2 – UI, 게시 후
" 서비스 URL 을 앱 manifest 의 mainService.uri 에 넣는다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
예금 계약 원천 확정	개시일 · 만기일 · 약정이율을 읽을 곳	구간 배정이 틀려 모든 숫자가 어긋납니다	자금팀 · 회계팀
예금 계정 범위	정기예금 · 외화예금으로 볼 계정	예치 총액이 원장과 맞지 않습니다	회계팀
구간 경계와 집중 기준	구간 일수와 집중 기준 비율(샘플은 가정값)	점검 코드가 의미 없는 기준으로 붙습니다	자금팀
지급 예정 소요 원천	유동성 예측의 어느 항목을 구간 소요로 볼지	부족액이 실제와 달라집니다	자금팀
환율 유형과 환산 시점	기말 환율 · 거래일 환율 중 무엇을 쓸지	외화 예금 원화 환산이 평가 금액과 어긋납니다	회계팀
중도해지 조건	상품별 중도해지이율 또는 약정	해지 손실이 실제와 달라 제안 순서가 바뀝니다	자금팀
부호 규칙	예금 잔액과 이자의 부호 처리	원장과 대사할 때 부호 때문에 어긋납니다	회계팀
권한 설계	회사코드 · 은행 계좌 단위 조회 범위	남의 회사 자금 정보가 보입니다	보안 · 권한 담당
대사 체계	표준 T-code 와 맞춰 볼 항목과 주기	숫자가 다를 때 어디부터 볼지 모릅니다	회계팀
전송과 활성화	TR 순서, 서비스 활성화, manifest 서비스 주소 교체	운영에서 앱이 데이터를 못 찾습니다	Basis

운영 데이터로 갈 때

예금은 건수가 많지 않지만 구간 큐브가 읽는 예금 계정 잔액은 전표 수천만 건에서 올라옵니다. 그래서 기준일 파라미터를 필수로 받고, 예금 계정 범위를 먼저 좁힌 뒤 집계하도록 만들고, 계정 · 회사코드 · 일자에 맞는 인덱스를 확인합니다. 구간 큐브처럼 결과가 수십 행인 뷰는 응답 시간이 문제가 아니라 원천 집계의 범위가 문제이므로, 성능 기준은 구간 큐브가 아니라 잔액 뷰에 두는 편이 맞습니다. 응답 시간의 목표 수치는 환경마다 달라 이 글에서 단정하지 않습니다.

자주 묻는 질문

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

숫자와 산식

초과 해지분은 왜 생기나요?

제안은 예금 단위로 해지한다고 가정하기 때문입니다. 부족액보다 큰 예금이 뽑히면 남는 금액이 초과 해지분으로 표시됩니다.

샘플에서는 6,000,000,000원짜리 예금 한 건이 5억 원 부족을 메우려고 뽑혀 초과 해지분이 55억 원으로 나옵니다. 일부 해지가 가능한 상품이면 회사가 금액을 줄여 판단할 수 있고, 불가능하면 이 초과분은 다시 맡기는 금액으로 따로 계획해야 합니다.

해지할 예금은 어떤 순서로 고릅니까?

더 늦게 만기가 오는 예금 가운데 약정이율이 있는 것만 후보로 두고, 중도해지 이자 손실 ÷ 원화 환산 금액 이 작은 순서로 부족액이 메워질 때까지 고릅니다.

금액이 큰 예금이 손실도 크게 보이는 왜곡을 줄이려고 손실을 원화 환산 금액으로 나눈 비율로 정렬했습니다. 이 순서는 제안일 뿐이며 계약 조건과 은행 협의 가능 여부는 회사가 판단합니다.

외화 예금은 어떻게 합산됩니까?

통화별 외화 원금은 더하지 않고 원화 환산 금액으로만 합산합니다. 화면의 환율은 샘플의 가정 환율(달러 1,350 · 유로 1,470 · 엔 9.2 · 위안 187)이며 실제 고시값이 아닙니다.

운영에서는 환율 유형과 환산 시점을 정해 표준 환율 테이블에 연결합니다. 이 환산은 만기 구간 점검용이라 기말 외화 평가 금액과 다를 수 있고, 평가는 표준 T-code FAGL_FCV 에서 실행합니다.

구간 비중은 무엇으로 나눕니까?

구간 만기 도래액을 회사 예치 총액으로 나눕니다. 회사별로 따로 계산하므로 두 회사의 규모가 달라도 비중을 서로 비교할 수 있습니다.

샘플에서 회사 1000 의 31~90일 구간은 120.64억 원 ÷ 460.54억 원 = 26.20% 로 가정 기준 25% 를 넘어 집중으로 표시됩니다. 집중 기준 25% 는 샘플의 가정값이며 정책으로 정합니다.

부족액은 앞 구간의 해지가 반영됩니까?

네. 구간을 가까운 쪽부터 훑으면서 앞 구간에서 해지 대상이 된 예금의 금액을 그 예금이 원래 속한 구간의 만기액에서 뺍니다. 이미 깨기로 한 예금이 뒤 구간의 만기액으로 다시 잡히면 같은 돈을 두 번 쓰게 되기 때문입니다.

그래서 구간 잔여는 만기액 − 해지 제외분 + 충당액 − 소요 로 계산하며, 이 식은 대사 결과 탭에서 12개 구간 모두 차이 0 으로 확인합니다.

충당 불가는 무엇을 뜻합니까?

후보 예금을 모두 써도 부족액이 남는다는 뜻입니다. 이 경우 제안으로 만들 수 있는 해지는 모두 만들고, 남는 금액을 충당 불가 제안으로 따로 남기며 해당 구간에 확인 필요를 붙입니다.

샘플에서는 회사 2000 의 181일 이상 구간 9억 원이 충당 불가입니다. 이 경우 다른 자금원(차입 한도, 다른 계좌의 여유 자금 등)을 회사가 확인해야 하며, 이 앱이 그 대안을 제안하지는 않습니다.

화면과 조작

조회 버튼은 어디에 있습니까?

조회조건 영역 안 입력 필드들의 가장 오른쪽, 초기화 버튼과 같은 줄에 있습니다. 입력 필드에서 Enter 키를 눌러도 같은 조회가 실행됩니다. 처음 열 때는 기본 조건(2026년 9월)으로 한 번 자동 조회합니다.

은행 조건은 이름을 다 적어야 합니까?

아닙니다. 이름의 일부만 적어도 조건에 걸립니다. 전체를 뜻하는 값은 코드로 보내지 않고 해당 조건을 아예 빼기 때문에, 비워 두면 전체가 조회됩니다. 통화·구간·점검 결과도 같은 방식입니다.

점검 코드 D 와 B 는 무엇이 다릅니까?

D 로 시작하는 코드는 예금 한 건의 판정이고 B 로 시작하는 코드는 구간 한 행의 판정입니다. 점검 코드 조건에 D 코드를 고르면 예금별 판정 탭이, B 코드를 고르면 만기 구간 탭이 그 조건으로 좁혀지며 다른 탭에는 걸리지 않습니다.

요약의 금액은 왜 백만원 단위입니까?

자릿수가 많은 금액을 한눈에 읽기 위해서입니다. 표 머리 위 안내에 “금액 단위 원(외화 원금은 해당 통화) · 요약의 만기·해지 금액은 백만원” 이라고 적혀 있고, 표 안의 금액은 원 단위 그대로입니다. 예상 이자 손실은 규모가 작아 원 단위로 보여 줍니다.

조회 결과를 내려받을 수 있습니까?

네. 표 오른쪽 위의 CSV 내려받기 버튼으로 지금 보고 있는 탭의 조회 결과를 UTF-8 CSV 로 받습니다. 요약 칸이나 상세 창은 포함되지 않으며, 파일 이름은 한글 기능명으로 지어집니다.

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

창이 좁아지면 조회조건이 여러 줄로 나뉘고 요약이 네 칸씩 두 줄로 접히며, 표는 가로로 밀어 봅니다. 만기 임박 건을 확인하는 정도는 휴대폰으로 충분하지만 구간과 제안을 견주는 일은 넓은 화면이 편합니다.

분석 기능

집중 구간은 어떻게 정합니까?

구간 비중이 집중 기준(샘플 가정값 25%)을 넘는 구간입니다. 집중 구간에 속한 예금에는 D02, 구간 행에는 B01 이 붙고 “재예치 시점을 나누는 안을 검토” 하라는 조치가 나옵니다.

샘플에서는 회사 1000 의 31~90일(26.20%) · 181일 이상(25.19%)과 회사 2000 의 91~180일(27.06%) 세 구간이 걸립니다. 요약의 “만기 집중 구간” 칸은 이 구간 수를 서비스 함수로 받아 보여 줍니다.

만기 경과 구간은 왜 따로 있습니까?

기준일보다 만기일이 앞서는데 처리되지 않은 예금은 이미 지나간 일이라 부족·집중 판정 대상이 아닙니다. 따로 구간을 두고 B05 로 표시해 “재예치 또는 입금 여부를 정리” 하도록 합니다. 만기 경과 구간은 재예치 가능 금액 계산에서도 뺍니다.

약정이율이 비어 있으면 어떻게 됩니까?

D05 확인 필요로 표시하고 경과 이자와 해지 손실을 산출하지 않습니다. 이 예금은 해지 후보에서도 빠집니다. 이율 조건은 회사가 계약을 보고 먼저 확인해야 하며, 확인되면 원천에 채운 뒤 다시 조회합니다.

재예치 가능 금액은 어떻게 나옵니까?

해지 제안을 반영한 뒤에도 구간의 만기 도래액이 소요를 넘으면 그 잔여를 재예치 가능 금액으로 보여 줍니다. 샘플에서는 6건, 합계 223.04억 원입니다. 구간 잔여를 전부 다시 맡기라는 뜻이 아니라, 소요를 채우고 남는 여유가 이만큼이라는 계산입니다.

30일 내 만기는 어디서 가져옵니까?

요약 칸은 서비스 함수가 기준일부터 30일 안에 만기가 오는 예금의 원화 환산 금액 합계를 계산해 돌려준 값입니다. 화면 표에서 더한 값이 아니라 서비스가 같은 조건으로 따로 계산해 주므로, 페이지에 보이는 행 수와 무관하게 정확합니다.

도입과 운영

도입하면 무엇이 달라집니까?

예금 만기를 모으는 손일이 줄고, 만기가 몰린 구간과 소요에 못 미치는 구간을 회의 전에 먼저 압니다. 해지 후보를 이자 손실이라는 같은 기준으로 비교할 수 있어 담당자마다 다른 결정이 나오는 일도 줄어듭니다. 다만 해지·재예치의 최종 결정은 이 화면이 하지 않습니다.

어떤 사용자에게 맞습니까?

예금을 여러 은행과 통화에 나눠 운용하며 월말·주간으로 만기와 지급 소요를 맞춰 보는 자금 담당자와 자금팀장입니다. 예금이 몇 건 안 되는 회사에는 엑셀 한 장이 더 간편할 수 있습니다.

적용 시기와 범위가 정해져 있습니까?

확인된 법령·기준서의 적용 시기가 있는 화면이 아닙니다. 회사의 예금 운용과 자금 계획을 점검하는 업무 화면이라 관련 기준서는 두지 않고 대상 영역을 자금 관리로 표기했습니다. 샘플의 환율·이율·집중 기준은 모두 가정값입니다.

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

표준 실행은 SAP 표준 T-code 가 담당합니다. 현금 포지션(FF7A), 유동성 예측(FF7B · FF63), 예금 계정 전표 조회(FBL3N), 외화 평가(FAGL_FCV)는 그대로 쓰고, 이 화면은 예금 만기 구조라는 관점을 더합니다. 기존 리포트를 없애지 않습니다.

데이터는 어디서 옵니까?

예금 계정 잔액과 이자는 총계정원장 전표 라인, 은행과 계좌는 하우스 은행·계좌 마스터와 은행 마스터, 환율은 표준 환율 테이블에서 이어받는 구조입니다. 예금 계약의 개시일·만기일·약정이율과 지급 예정 소요의 원천은 환경에 따라 다르므로 도입 때 확정해야 하는 항목입니다.

운영 시스템에는 어떻게 연결합니까?

CDS 뷰와 서비스를 만들고 게시한 뒤, 앱 manifest 의 서비스 주소만 바꿔 넣습니다. 화면과 판정 규칙은 그대로이고 데이터 원천만 바뀝니다. 연결 전에 계약 원천·계정 범위·소요 원천·환율 유형을 정해야 하며, 일정은 이 정함의 속도에 좌우됩니다.

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

자금 정보라 회사코드 단위로 조회를 제한하는 편이 좋습니다. 권한은 집계를 읽는 뷰에 걸어야 합니다. 상세에만 걸면 구간 합계에서 다른 회사 금액을 빼 알아낼 수 있습니다. 화면은 표준 컨트롤만 써서 외부 라이브러리 반입 심사가 필요 없습니다.

예금이 아주 많아지면 느려지지 않습니까?

예금 건수는 많아야 수천 건이라 문제가 되지 않습니다. 느려지는 곳은 예금 계정 잔액을 전표에서 집계하는 단계입니다. 기준일 파라미터를 필수로 받고 예금 계정을 먼저 좁힌 뒤 집계하며, 인덱스를 확인하는 것이 운영 전환의 성능 작업입니다.

구간 일수나 집중 기준을 바꾸려면 개발이 필요합니까?

필요하지 않습니다. 구간 경계와 집중 기준은 정책 테이블의 값이므로 자금팀이 유지보수 화면에서 바꿉니다. 바꾼 뒤 다시 조회하면 구간 배정과 점검 코드가 새 기준으로 다시 산출됩니다. 정책이 바뀐 시점을 알 수 있게 유효 시작일을 함께 둡니다.

판정 결과를 그대로 해지 결정에 써도 됩니까?

이 화면은 분류·집계·대사를 돕는 점검 도구이며 최종 판단은 회사와 감사인(세무 신고는 회사와 세무 대리인·관세사)이 합니다. 해지·재예치 제안은 이자 손실과 초과 해지분을 함께 보여 주는 검토용 안이며, 계약 조건과 은행 협의 가능 여부는 회사가 직접 확인해야 합니다.

계정 체계가 바뀌면 어떻게 됩니까?

예금 계정 범위가 정책으로 분리돼 있어 새 계정을 범위에 추가하면 됩니다. 추가하지 않으면 그 계정의 예금은 점검에서 빠져 예치 총액이 원장과 맞지 않게 되고, 이는 대사 결과에서 차이로 드러납니다.

숫자가 기존 보고서와 다르면 어떻게 확인합니까?

순서가 있습니다. ① 기준일과 회사를 같게 맞춥니다. ② 예금 계정 범위가 같은지 봅니다. ③ 외화라면 환율이 같은지 봅니다 — 가정 환율이면 표준 평가 금액과 다릅니다. ④ 예금 계정의 전표를 FBL3N 으로 열어 합계를 맞춰 봅니다. 대부분 ① 과 ② 에서 원인이 드러납니다.