자금 예측 유동성 갭 점검 — 앞으로 12주의 현금 유입·유출 예정을 현금화 예상일 기준으로 다시 모아 부족해지는 주차를 미리 가려 보는 화면

개발 배경 — 이 앱을 사용해야 하는 이유

자금 팀이 매주 월요일 아침에 묻는 질문은 단순합니다. 앞으로 열두 주 동안 통장에 돈이 모자라는 주가 있는가. 답은 매출채권 회수 예정, 매입채무 지급 예정, 급여 · 세금 · 차입금 상환 같은 전표 이전의 예정 항목을 주 단위로 모아 기초 잔고에서 더하고 빼 보면 나옵니다. 문제는 이 “주 단위로 모으는 일”에 있습니다. 대개 만기일 기준으로 주를 넣어 두기 때문에, 고객이 늘 열흘씩 늦게 내는 채권은 장부상 이번 주에 들어오는 돈으로 잡혀 있습니다.

이 앱은 그 자리를 메웁니다. 예정 항목마다 현금화 예상일이 속한 주차를 다시 구해 장부 주차와 견주고, 다시 모은 주차별 유입 · 유출로 기말 예상 잔고와 누적 갭을 계산해 최소 유동성 한도, 미사용 차입한도와 나란히 놓습니다. 모자라는 주에는 이유가 붙은 점검 코드를 답니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 점검 관점을 더해 확장합니다.

만기일로 넣은 주차와 현금이 들어오는 주차는 다르다

장부 주차가 틀렸다는 뜻이 아니라 기준이 다르다는 뜻입니다. 만기일 기준 주차는 계약대로의 약속이고, 현금화 예상일 기준 주차는 과거 지연 이력을 반영한 예상입니다. 이 앱은 둘을 나란히 두고 달라진 줄만 F01 로 올립니다. 어느 쪽이 맞는지 정하는 것은 자금 팀의 몫이고, 화면은 “이 줄을 옮기면 어느 주가 얼마나 달라지는가”를 보여 줍니다.

잔고가 한도 아래인 것과 차입한도를 써도 모자란 것은 다른 이야기다

한도 아래로 내려가도 미사용 차입한도로 메울 수 있는 주가 있고, 그마저 모자란 주가 있습니다. 앞은 조달 계획을 확인하면 되는 주(G02), 뒤는 지급 조정까지 검토해야 하는 주(G03)입니다. 이 앱은 둘을 코드로 가르고 상단 요약에서 부족한 주차 수와 최소 기말 예상 잔고를 먼저 보여 줍니다.

화면이 계산할 수 없는 것은 사람에게 돌려준다

확정 유입 비율이 낮은 주나 오래 연체된 채권을 확정으로 올린 줄은 계산으로 옳고 그름을 가릴 수 없습니다. 이런 줄을 오류로 몰면 현업이 화면을 믿지 않게 됩니다. 그래서 점검 필요가 아니라 확인 필요로 따로 세우고, 근거 자료를 회사가 확인하도록 안내합니다.

사용 방법

1. 조회조건 입력 — 회계연도는 필수(4자리, 예: 2026)입니다. 회사 · 방향 · 구분 · 기준일 구간 · 거래처 · 점검 코드 · 점검 결과는 선택이며 “전체”로 두면 그 조건은 쓰이지 않습니다.
2. 조회 — 조건 칸들의 가장 오른쪽에 있는 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 처음 열 때는 자동으로 한 번 조회합니다.
3. 요약 지표 확인 — 점검한 주차 수, 유동성 부족 주차, 최소 기말 예상 잔고, 주차 배정 차이 명세, 확인 필요 건수, 정합성 대사 차이 건수를 먼저 봅니다.
4. 탭 이동 — 주차별 유동성 갭 → 예정 항목 명세 → 구분별 집계 → 대사 결과 순서로 봅니다.
5. 행 클릭 상세 — 주차별 유동성 갭에서 행을 누르면 그 주에 현금화되는 예정 항목이 팝업으로 열립니다.
6. 내려받기 — 현재 탭의 조회 결과를 CSV(UTF-8)로 저장합니다.

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

점검 화면이 틀린 숫자를 보여 주면 점검 자체가 의미를 잃습니다. 그래서 화면에 올리기 전에 대사식을 세워 검증용 샘플 데이터 전수에 돌렸습니다.

검사 건수는 모두 237건이고 차이는 0건입니다. 이 숫자는 정합성 검사이고, 화면에서 점검 필요로 표시되는 건수와는 다른 이야기입니다. 점검 화면을 보여 주려고 일부러 어긋나게 만든 항목이 샘플에 들어 있습니다.

정합성 차이 0건과 점검 필요 건수는 서로 다른 층의 숫자입니다. 앞은 “화면이 계산을 제대로 했다”이고, 뒤는 “화면이 계산한 결과 다시 볼 줄이 이만큼 있다”입니다.

무엇으로 만들었나

앱 정보

실행 화면

실제 화면 6종입니다. 순서는 사용 순서를 따랐습니다. 처음 연 화면에서 시작해 주차별 갭, 명세, 구분별 집계, 대사 결과, 행 상세로 이어집니다. 화면 속 금액은 검증용 샘플 데이터이며 실제 회사의 숫자가 아닙니다.

처음 열었을 때 — 조회조건과 요약 지표, 주차별 유동성 갭

화면을 열면 2026 회계연도로 자동 조회됩니다. 맨 위 조회조건, 그 아래 요약 지표 여섯 칸(점검한 주차 수 · 유동성 부족 주차 · 최소 기말 예상 잔고 · 주차 배정 차이 명세 · 확인 필요 건수 · 정합성 대사 차이), 아래에 탭 네 개가 놓입니다. 조회 버튼은 입력 칸의 맨 오른쪽 끝에 있고 Enter 키로도 같은 조회가 됩니다.

회사 2000 의 주차별 유동성 갭 — 한도에 견준 기말 예상 잔고

한 줄이 한 주입니다. 기초 잔고에 그 주 유입을 더하고 유출을 뺀 기말 예상 잔고가 다음 주의 기초 잔고가 됩니다. 기말 예상 잔고가 최소 유동성 한도 아래로 내려간 주는 G02, 미사용 차입한도를 써도 모자라면 G03 으로 올라갑니다. 샘플에서는 회사 2000 의 후반부 주차가 여기에 걸리도록 일부러 넣었습니다.

예정 항목 명세 — 현금화 예상일 기준으로 주차를 다시 구한다

명세 한 줄이 예정 항목 하나입니다. 만기일에 지연 반영 일수를 더한 현금화 예상일이 속한 주차를 재계산 주차로 구하고, 장부에 넣어 둔 주차와 다르면 F01 로 올립니다. 만기 후 30일을 넘긴 채권을 확정 유입으로 올린 줄은 F02, 재계산 주차가 12주 밖인 줄은 F04 로 따로 세웁니다.

구분별 집계 — 어떤 종류의 현금이 움직이는가

매출채권 회수 · 환급 · 차입 실행 · 매입채무 지급 · 급여 · 세금 · 차입금 상환 · 설비투자 · 배당 아홉 구분마다 건수와 금액, 예상 금액, 지연 반영 금액을 모읍니다. 주차별 숫자가 어느 종류의 현금에서 나왔는지 거꾸로 짚을 때 씁니다.

대사 결과 — 정합성 대사와 참고 대사

정합성 대사 여섯 가지의 검사 건수와 차이 건수, 최대 차이를 보여 줍니다. 이 탭이 0 이 아니면 계산이나 데이터 연결을 의심해야 하고, 점검 필요 건수와는 다른 층의 숫자입니다.

주차 한 줄을 열어 본다 — 그 주에 현금화되는 예정 항목

주차별 유동성 갭 탭에서 행을 누르면 그 주차의 기말 예상 잔고와 한도 대비 판정, 같은 주차에 현금화되는 예정 항목이 팝업으로 열립니다. 어느 거래처의 어떤 항목 때문에 그 주가 모자라는지 바로 짚을 수 있습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 입력된 조건을 필터로 바꿔 서비스에 보냅니다. 서비스는 필터에 맞는 행만 정렬해 돌려주고, 요약 지표의 부족 주차 수와 최소 기말 예상 잔고는 별도 함수 호출로 셉니다. “전체”로 둔 조건은 필터로 만들지 않고, 기준일 구간은 시작 · 종료 날짜를 그대로 범위 조건으로 보냅니다.

점검 판정 규칙 — 조건에서 사용자 조치까지

주차는 G03 → G02 → G01 → G05 순서로 판정하고 앞 조건에 걸리면 뒤 조건은 보지 않으므로 한 줄에는 코드가 하나만 붙습니다.

산출 · 대사 순서

1. 주차 배정 — 명세마다 현금화 예상일이 속한 주차(재계산 주차)를 구합니다.
2. 주차별 유입 · 유출 — 같은 재계산 주차의 유입과 유출을 각각 더합니다.
3. 기말 예상 잔고 = 기초 잔고 + 유입 − 유출. 다음 주 기초 잔고는 직전 주 기말 예상 잔고입니다.
4. 누적 갭 = 주차별 순 갭의 누적 합.
5. 한도 대비 여유 = 기말 예상 잔고 − 최소 유동성 한도. 차입한도 후 부족액 = max(0, 한도 미달액 − 미사용 차입한도).
6. 정합성 대사 — 기초 + 유입 − 유출 = 기말, 주차 기초 = 직전 주 기말, 명세 합계 = 주차 합계 + 기간 밖, 구분별 합계 = 명세 합계, 마지막 주 기말 − 최초 기초 = 누적 갭.

조회조건

좁은 화면에서 달라지는 것

창 폭이 줄어들면 조회조건 칸이 한 줄에 하나씩 쌓이고 요약 지표는 두 칸씩 두 줄로 내려옵니다. 표는 가로로 밀 수 있고 앞 열이 고정됩니다.

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 점검 관점을 더해 확장합니다. 이 절은 어디까지가 표준이고 어디서부터가 이 앱인지, 두 화면의 숫자를 어디서 맞춰 보는지를 정리합니다.

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

T-code 별 연계 지점

오가는 방법은 두 갈래입니다. 이 앱에서 시작할 때는 부족한 주의 상세에서 거래처와 항목을 확인한 뒤 FBL5N · FBL1N 으로 원천을 열고, 표준 화면에서 시작할 때는 이상한 잔고를 찾은 뒤 이 앱의 예정 항목 명세에서 그 항목이 어느 주로 재배정되는지 봅니다. 정식 자금 계획과 지급 실행은 표준 화면에 그대로 남으므로 운영 전환 때 기존 리포트를 없앨 필요가 없습니다.

요구사항 매핑표

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

CDS 구성 — 코드와 운영 작업

아래 코드는 이 화면이 쓰는 데이터를 S/4HANA 의 미결 항목 테이블 위에 CDS 로 올릴 때의 스케치입니다. 객체 이름은 기능을 뜻하는 영문으로 지었습니다. 표준 필드명은 확인한 것만 쓰고, 확인하지 못한 자리는 “확인 필요”로 남겼습니다. 실제 시스템의 릴리스에 맞춘 검증은 구현 단계에서 거쳐야 합니다.

뷰 레이어 구성

① 기본 뷰 — 현금화 예상일과 재계산 주차를 한 곳에서

이 앱의 모든 숫자는 예정 항목이 어느 주로 들어가는지에서 출발합니다. 주차 배정 식이 화면과 배치에서 갈라지면 같은 항목이 다른 주에 잡히므로 한 뷰에서만 구합니다. 아래는 고객 미결 항목 쪽 스케치이고 공급업체 쪽은 같은 모양으로 유출을 만듭니다.

" ───────────────────────────────────────────────────────────────
" ZI_LiqFlowItem · 예정 항목 기본 뷰 (고객 미결 항목 쪽)
" 역할 : 현금화 예상일과 재계산 주차를 이 뷰 한 곳에서만 구한다.
" 이렇게 나눈 이유 : 주차 배정 식이 둘로 갈라지면 화면과 배치가 다른 숫자를 낸다.
" 스케치이며 지급조건 일수 처리와 필드명은 구현 단계에서 확인해야 한다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '유동성 갭 — 예정 항목(스케치)'
define view entity ZI_LiqFlowItem
  as select from bsid
{
  key bukrs                                              as Bukrs,
  key belnr                                              as Belnr,
  key buzei                                              as Buzei,
      'I'                                                as Direction,
      kunnr                                              as Partner,
      wrbtr                                              as Amount,
      dats_add_days( zfbdt, cast( zbd1t as abap.int4 ), 'FAIL' ) as DueDate
}

② 큐브 — 주차별 유입 · 유출과 기말 예상 잔고

유입과 유출을 재계산 주차로 모으고 기초 잔고를 이어 받아 기말 예상 잔고와 한도 대비 여유를 계산합니다. 잔고 이월은 주차 순서에 기대므로 윈도 계산 위치와 성능을 구현 단계에서 확인해야 합니다.

" ───────────────────────────────────────────────────────────────
" ZI_LiqWeekCube · 주차별 큐브
" 역할 : 재계산 주차별 유입·유출을 모으고 기말 예상 잔고를 구한다.
" 이렇게 나눈 이유 : 잔고 이월은 주차 순서에 기대므로 윈도 계산을 한 뷰에 가둔다.
" ───────────────────────────────────────────────────────────────
define view entity ZI_LiqWeekCube
  as select from ZI_LiqFlowWeek as w
{
  key w.Bukrs, key w.WeekNo, w.WeekStart,
      w.OpenBal,
      w.InAmt,
      w.OutAmt,
      w.OpenBal + w.InAmt - w.OutAmt                       as CloseCalc,
      w.MinBuffer,
      w.OpenBal + w.InAmt - w.OutAmt - w.MinBuffer        as Headroom
}

③ 쿼리 — 점검 코드를 판정한다

판정 순서 G03 → G02 → G01 → G05 와 임계값을 이 쿼리가 책임집니다. 회사가 임계값을 바꾸려면 이 뷰의 상수 하나를 고치거나 설정 테이블에서 읽도록 확장합니다.

" ───────────────────────────────────────────────────────────────
" ZC_LiqGapCheck · 주차별 점검 쿼리
" 판정 순서 : G03 → G02 → G01 → G05 → G00 (앞 조건에 걸리면 뒤는 보지 않는다)
" 임계값(확정 유입 비율 60) 은 이 뷰 한 곳의 상수다.
" ───────────────────────────────────────────────────────────────
define view entity ZC_LiqGapCheck
  as select from ZI_LiqWeekCube
{
  key Bukrs, key WeekNo, CloseCalc, Headroom,
      case
        when Headroom < 0 and ( 0 - Headroom ) > CreditLine then 'G03'
        when Headroom < 0                                      then 'G02'
        when InBook <> InAmt or OutBook <> OutAmt              then 'G01'
        when CertPct < 60                                      then 'G05'
        else 'G00'
      end                                                      as CheckCode
}

④ 권한과 서비스

주차 합계 화면에서는 보이지 않던 남의 회사 숫자가 거래처 단위 명세 화면에서는 줄마다 드러납니다. 그래서 쿼리 뷰에 회사코드 단위 권한을 걸어 줄 단위에서도 제한합니다. 서비스 정의에서는 노출할 뷰를 정하고 OData V2 바인딩으로 게시하며, 앱 설정의 서비스 주소만 교체하면 운영 서비스로 붙습니다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

미결 항목은 수만 건이 될 수 있습니다. 이 앱이 보는 것은 항목 전수가 아니라 주차와 구분으로 모은 합계이므로 집계는 반드시 데이터베이스 쪽(큐브 뷰)에서 끝내야 합니다. 화면이 항목을 받아 합산하는 구조로 가면 응답이 느려집니다. 회계연도를 필수 조건으로 두고 기준일 구간으로 범위를 좁히며, 접근 경로가 쓰이는지 실행 계획으로 점검합니다. 응답 시간 기준은 회사가 정해야 합니다.

자주 묻는 질문

도입을 검토할 때 자주 나오는 질문을 네 묶음으로 모았습니다.

숫자와 산식

화면과 조작

표준 T-code 와 데이터

도입과 운영