SAP 가용 자금 충당 점검 — 은행 계좌별 가용 자금을 다시 계산해 당일 지급 충당·이체 가능 여부·은행 통지와 견주는 자금 화면

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

지급 직전 자금 담당이 던지는 질문은 늘 비슷합니다. 오늘 이 계좌에서 실제로 쓸 수 있는 돈은 얼마인가, 그 돈으로 당일 확정 지급을 감당하는가, 모자라면 같은 통화의 다른 계좌에서 옮겨 올 여유가 있는가. 지금은 이 답이 장부 잔액, 제한 자금 목록, 미결제 지급, 은행의 한도 통지에 흩어져 있어 한 번에 맞춰 보기 어렵습니다. 장부 잔액만 보면 충분해 보이지만 제한 자금과 최소 유지 잔액을 빼면 지급액에 못 미치는 날이 생기고, 약정 한도에 기대어 겨우 충당하는 날도 있습니다.

이 앱은 계좌·일자마다 장부 잔액 − 제한 자금 − 미결제 지급 − 최소 유지 잔액 + 유효한 약정 한도로 가용 자금을 다시 구하고, 당일 확정 지급을 뺀 충당 후 잔여를 보여 줍니다. 부족한 계좌는 같은 통화의 다른 계좌 여유로 해소되는지 일자·통화 단위로 확인하고, 은행 통지 가용 잔액과 재계산 값이 허용 오차 안에서 맞는지도 함께 가립니다. 관련 기준서는 없고 대상 영역은 자금(은행 계좌 가용 자금·당일 지급 충당)입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다.

장부 잔액이 충분해도 쓸 수 있는 돈은 다르다

이 샘플의 한 당좌 계좌는 9월 초 장부 잔액이 5,200만 원이지만 최소 유지 잔액 1,000만 원을 빼면 4,200만 원이고, 약정 한도의 남은 2억 1,300만 원을 더해야 가용 자금이 2억 5,500만 원이 됩니다. 한도를 빼고 보면 같은 날 지급 1,100만 원도 한도 없이 충당할 수 있는지 달라집니다. 한도가 만료되었거나 한도 사용분이 늘면 숫자가 바로 달라지므로 건마다 다시 구해야 합니다.

부족은 계좌 단위가 아니라 일자·통화 단위로 풀린다

한 계좌가 모자라도 같은 날 같은 통화의 다른 계좌에 한도 없이 쓸 수 있는 여유가 있으면 이체로 해소됩니다. 이 화면은 일자·통화마다 부족액 합과 이체 가능 여유 합을 구해 이체로 해소되는 금액과 그래도 남는 부족을 나눠 보여 줍니다. 여유가 있어도 이체 수수료나 마감 시각 같은 실무 조건은 회사가 판단합니다.

은행 통지 가용 잔액과 재계산이 다르면 원인을 먼저 봐야 한다

통지서의 가용 잔액이 재계산과 다르면 미결제 지급이 반영되지 않았거나, 만료된 약정 한도가 통지에 계속 들어 있을 수 있습니다. 이 화면은 통화별 허용 오차를 넘는 경우만 확인 필요로 표시하고, 만료 한도가 포함된 경우는 따로 가려 줍니다. 원인을 단정하지 않고 확인할 자리를 좁혀 줍니다.

환율과 한도 기준은 회사가 정한다

원화 환산에 쓸 환율 유형과 적용일, 최소 유지 잔액과 제한 자금 기준, 약정 한도의 원천은 회사 정책으로 정할 일입니다. 샘플은 가정값을 쓰며, 이 화면은 그 선택을 대신하지 않고 선택한 기준에서 숫자가 어떻게 보이는지를 보여 줍니다.

사용 방법

1. 회계연도와 기간(월)을 확인하고 필요하면 회사·은행·통화·계좌 유형·기준일·점검 코드·점검 결과를 고릅니다. 처음 열면 2026년 09월이 채워져 자동으로 한 번 조회됩니다. 비워 두면 “전체”입니다.
2. 조회 버튼(조회조건 영역의 오른쪽 끝, 초기화 옆)을 누르거나 입력란에서 Enter 를 누릅니다.
3. 위쪽 요약에서 점검한 계좌·일자 건 · 일평균 가용 자금 · 충당 부족 건과 금액 · 한도에 기댄 건 · 이체 필요 일자·통화 · 확인 필요 · 정합성 대사 차이를 먼저 봅니다.
4. 계좌·일자 명세 → 일자·통화 집계 → 계좌 기준 → 대사 결과 순서로 탭을 옮겨 봅니다.
5. 계좌·일자 명세의 행을 누르면 가용 자금 구성 · 약정 한도 · 충당 결과와 같은 기준일·같은 통화의 다른 계좌가 상세 창에 열립니다.
6. CSV 내려받기 로 지금 보는 탭을 UTF-8(BOM) 파일로 받아 확인 자료로 씁니다.

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

자금 점검에서 가장 비싼 질문은 “이 합계 맞아?” 입니다. 그래서 대사식을 먼저 세우고 샘플 데이터 전체(8월 140건 · 9월 140건)에 돌렸습니다. 검증용 파일을 화면과 별개 코드로 다시 계산해 서비스 결과와 견준 값입니다.

정합성 대사식은 검사 1042건이 모두 차이 0 입니다. 점검 화면이 보여 주려고 일부러 넣은 예외는 대사 차이와 섞이지 않도록 따로 세었습니다.

화면 쪽은 별도로 브라우저 자동화로 확인했습니다 — 조회·초기화·Enter 조회, 기준일 조건, 탭별 건수, 행 클릭 상세, CSV 내려받기, 오류 안내를 실제로 돌려 보았습니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보고 무엇을 누르는 자리인지를 아래에 적었습니다. 숫자는 모두 같은 샘플 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다. 계좌 · 은행 · 환율은 검증용 가정값입니다.

2026년 09월이 채워진 채 한 번 자동 조회됩니다. 위쪽 요약 줄에서 점검한 계좌·일자 건수(140건), 일평균 가용 자금(2,710,150,470원), 충당 부족 9건과 228,795,857원, 한도에 기댄 9건, 이체가 필요한 일자·통화 8건(그중 이체해도 부족 3건), 확인 필요 10건, 정합성 대사 차이 0건을 먼저 읽습니다. 표에는 장부 잔액에서 가용 자금까지 구성 항목이 한 줄에 놓입니다.

조회조건에서 점검 결과를 점검 필요로 두고 조회 버튼을 누르면 해당 계좌·일자 18건만 남습니다. 충당 후 잔여가 마이너스인 줄(F01 9건)이 먼저 확인할 대상이고, 한도 제외 잔여가 마이너스인 줄(F02 9건)은 약정 한도에 기대 충당한 건입니다.

가용 자금 구성, 약정 한도와 유효기간, 충당 결과, 원화 환산, 은행 통지 가용 잔액과 재계산의 차이가 한 창에 나옵니다. 아래에는 같은 기준일·같은 통화의 다른 계좌가 이어져 이체로 메울 여유가 있는지 바로 견줄 수 있습니다.

일자와 통화마다 계좌별 부족액, 이체 가능 여유, 이체로 해소되는 금액, 이체해도 남는 부족이 한 줄에 놓입니다. 여유로 메워지는 부족(G01)과 그래도 남는 부족(G02)을 나눠 표시합니다.

계좌마다 최소 유지 잔액, 제한 자금, 약정 한도와 유효기간, 은행 통지 허용 오차가 한 줄씩 있습니다. 판정은 이 값을 기준으로 합니다.

가용 자금 구성, 충당 후 잔여, 일자·통화 집계, 부족액 분해, 원화 환산, 판정 건수 대사와 은행 통지 대사가 좌변·우변·검사 건수·차이 건수와 함께 나옵니다.

충당 판정 규칙

한 계좌·일자에는 점검 코드가 하나만 붙으며, 위에서부터 먼저 맞는 조건을 따릅니다.

일자·통화 집계는 G00(부족 없음), G01(부족하지만 다른 계좌 여유로 해소 가능), G02(이체해도 부족)로 판정합니다. 결과는 “점검 필요”·“확인 필요”로만 표시하며 원인을 단정하지 않습니다.

조회조건과 결과 컬럼

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다. 현금 포지션을 보고 은행 명세를 처리하고 계정 잔액을 확인하는 일은 모두 표준에 두고, 그 결과를 최소 유지 잔액·한도 같은 기준과 견주는 자리만 이어 붙였습니다.

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

T-code 별 연계 지점

법정 · 감사 보고에 쓰는 자료와 정정 전표는 표준에 그대로 둡니다. 따라서 운영 전환 때 기존 리포트를 없애지 않고, 한두 달 두 화면의 합계를 맞춰 본 뒤 쓰임새를 나눕니다.

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 두고 Fiori 분석 앱이나 Analysis for Office 로 읽는 구성이 흔합니다. 이 화면의 서비스도 같은 CDS 뷰 위에 놓이는 것을 전제로 하며, 가용 자금 재계산과 충당 판정을 뷰에서 계산해 화면 · 내려받기 · 대사가 같은 숫자를 읽도록 합니다. 아래 CDS 구성은 그 스케치입니다.

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

분석 지표 정의표

관련 기준서는 없으며 대상 영역은 자금(은행 계좌 가용 자금·당일 지급 충당)입니다. 이 화면은 점검 도구이며 최종 판단은 회사가 합니다.

CDS 구성 — 장부 잔액에서 서비스까지

샘플 화면은 서비스 로직이 계산하지만, 운영에서는 같은 계산을 CDS 뷰에 둡니다. 아래는 그 구성의 스케치입니다. 표준 CDS 뷰 이름은 확인된 것만 쓰고, 잔액 원천은 테이블 기준으로 적었으며 원천 필드는 도입 때 “확인 필요”로 맞춥니다. 뷰 이름은 고객 네임스페이스 규칙에 맞춰 정하면 됩니다.

뷰 레이어 구성

① 계좌 기준표 — 판정의 유일한 기준

최소 유지 잔액과 제한 자금, 약정 한도와 유효기간이 어디에 저장되는지가 곧 판정의 신뢰도입니다. 회사 · 계좌를 키로 두고 한도 유효기간을 함께 둡니다.

// ─────────────────────────────────────────────────────────────
// AvailFundAcct — 계좌 기준표 (고객 테이블)
// 역할 : 계좌별 최소 유지 잔액·제한 자금·약정 한도와 유효기간을 둔다.
// 이렇게 나눈 이유 : 기준이 바뀌어도 뷰·화면 코드를 고치지 않으려고.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '가용 자금 계좌 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
define table fund_acct_rule {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key acct_id    : abap.char(4) not null;
  waers          : waers;
  min_keep       : abap.curr(18,2);   // 최소 유지 잔액 — 회사 정책으로 확정
  restrict_amt   : abap.curr(18,2);   // 제한 자금
  line_limit     : abap.curr(18,2);   // 약정 한도 — 외부 자료, 확인 필요
  line_from      : abap.dats;
  line_to        : abap.dats;
}

② 장부 잔액 뷰 — 은행 계정 잔액을 한 행에

은행 계정의 장부 잔액을 기준일까지 합산해 통화별로 모읍니다. 환율 유형과 적용일 기준은 회사 정책으로 정하는 항목이라 도입 때 확인합니다.

// ─────────────────────────────────────────────────────────────
// AvailBookBase — 은행 계정 장부 잔액 (전표 라인 합계)
// 역할 : 계정·통화별 잔액을 기준일까지 모은다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 계정 장부 잔액'
define view entity AvailBookBase as select from acdoca
  association [0..1] to tcurr as _Rate on  _Rate.kurst = 'M'      // 환율 유형 — 확인 필요
                                       and _Rate.fcurr = acdoca.rwcur
                                       and _Rate.tcurr = acdoca.rhcur
{
  key rbukrs as Bukrs, key racct as GlAccount, key budat as PosDate, rwcur as Waers,
  @Semantics.amount.currencyCode : 'Waers' sum( wsl ) as BookAmt,
  _Rate
}
group by rbukrs, racct, budat, rwcur

③ 가용 자금 큐브 — 숫자가 만들어지는 유일한 자리

가용 자금, 충당 후 잔여, 한도 제외 잔여, 점검 코드가 여기서 결정됩니다. 화면 · 내려받기 · 대사가 모두 이 뷰의 값을 읽으므로 운영에서 가장 먼저 검증해야 하는 뷰입니다.

// ─────────────────────────────────────────────────────────────
// AvailFundCube — 가용 자금·충당 판정 (큐브)
// 역할 : 계좌·일자마다 가용 자금과 충당 후 잔여를 구하고 점검 코드를 붙인다.
// 이렇게 나눈 이유 : 판정을 뷰 한 곳에서만 계산해 화면·CSV·대사가 같은 숫자를 쓰게 한다.
// ─────────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '가용 자금 충당 판정'
define view entity AvailFundCube as select from AvailBookBase as b
  inner join fund_acct_rule as a
    on a.bukrs = b.Bukrs and a.waers = b.Waers
{
  key b.Bukrs, key a.acct_id as AcctId, key b.PosDate, b.Waers, b.BookAmt,
  a.min_keep as MinKeep, a.restrict_amt as RestrictAmt,
  // 가용 자금 = 장부 − 제한 − 미결제 지급 − 최소 유지 + 한도 가용
  cast( 0 as abap.dec(18,2) ) as AvailAmt,          // 미결제 지급·한도 사용은 외부 자료 — 확인 필요
  case when 1 = 0 then 'F01' else 'F00' end as CheckCode
}

④ 일자·통화 집계 뷰 — 부족과 여유를 한곳에서

계좌별 부족액과 이체 가능 여유를 일자·통화로 묶어 이체로 해소되는 금액을 구합니다. 화면의 집계 탭이 이 뷰를 읽습니다.

// ─────────────────────────────────────────────────────────────
// AvailFundDay — 일자·통화 집계 (Consumption)
// 역할 : 부족액 합과 이체 가능 여유 합, 이체로 해소되는 금액을 구한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '가용 자금 일자·통화 집계'
define view entity AvailFundDay as select from AvailFundCube
{
  key Bukrs, key PosDate, key Waers,
  sum( case when CoverAmt < 0 then 0 - CoverAmt else 0 end )  as ShortAmt,
  sum( case when OwnAmt  > 0 then OwnAmt   else 0 end )       as SurplusAmt,
  count( * ) as AcctCnt
}
group by Bukrs, PosDate, Waers

⑤ 접근 제어 — 회사코드 권한

집계 뷰까지 같은 권한을 상속해야 합계로 다른 회사의 금액이 드러나지 않습니다. 드릴다운에만 권한을 걸면 뺄셈으로 새어 나갈 수 있어 집계 단계에 겁니다.

// ─────────────────────────────────────────────────────────────
// AvailFundCube — 접근 제어 (DCL)
// 역할 : 회사코드 권한이 없는 회사의 잔액은 합계로도 보이지 않게 한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '가용 자금 권한'
@MappingRole : true
define role AvailFundRole {
  grant select on AvailFundCube
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑥ 서비스 정의와 바인딩 — 화면이 읽는 계약

노출 목록이 곧 화면과의 계약입니다. 바인딩을 게시한 뒤 서비스를 활성화하고, 앱 설정의 서비스 주소만 운영 주소로 바꿉니다.

// ─────────────────────────────────────────────────────────────
// AvailFundCheck — 서비스 정의와 바인딩 (OData V2)
// 역할 : 화면이 읽는 뷰를 서비스로 노출한다.
// 이렇게 나눈 이유 : 노출 목록이 곧 계약이므로 한 파일에 모아 두고,
//   바인딩을 게시한 뒤 앱 설정의 서비스 주소만 바꿔 운영에 연결한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '가용 자금 충당 점검 서비스'
define service AvailFundCheck {
  expose AvailFundQuery  as AvailSet;
  expose AvailFundDay    as DaySet;
  expose AvailFundAcct   as AcctSet;
}
// Service Binding : 유형 OData V2 - UI, 게시 후 서비스 활성화

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여섯 가지는 코딩이 아니라 합의이며, 합의가 끝나면 기술 작업은 뷰를 만들고 서비스를 게시하는 일로 줄어듭니다.

운영 데이터로 갈 때

계좌 수가 수백 개를 넘으면 조회조건(회사 · 기간)을 필수로 두고 계좌·일자 명세를 페이지 단위로 읽는 것이 기본입니다. 일자·통화 집계는 뷰에서 미리 묶어 응답 시간을 일정하게 유지하고, 환율은 기준일별로 한 번만 가져오도록 조인을 설계합니다.

자주 묻는 질문

숫자와 산식 · 화면과 조작 · 데이터와 표준 연계 · 도입과 운영 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

데이터와 표준 연계

도입과 운영