계좌 간 자금 풀링 이행 점검 — 목표 잔액으로 규칙 이체액을 다시 구해 마스터 계좌와 실제로 오간 금액에 견주고 미이행·방향 오류·수신 불일치를 가리는 자금 화면

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

자금 담당자는 월말마다 같은 질문을 받습니다. '풀링 규칙대로 돈이 마스터 계좌로 모였나?', '안 모인 날은 얼마나 되고 그 비용은 얼마인가?', '마스터 계좌가 받은 금액은 맞나?' 표준 보고서는 계좌별 잔액과 거래명세를 정확히 보여 주지만, 목표 잔액에서 규칙 이체액을 다시 구해 실제 이체에 견주는 일은 대개 지시서와 명세를 펼쳐 놓고 손으로 합니다.

이 앱은 그 자리를 메웁니다. 참가 계좌마다 이체 전 잔액에서 목표 잔액을 빼 규칙 이체액을 구하고, 실제로 마스터 계좌와 오간 금액과 날마다 견주어 미이행·일부 이행·과다·방향 상이를 가린 뒤, 풀 단위로 마스터 수신액을 맞추고 마스터 밖에 머문 잔액의 기회비용을 원화로 보여 줍니다. 숫자는 대사식 6종이 서비스 안에서 다시 맞춰 봅니다.

핵심 포인트 여섯 가지

만기가 아니라 잔액이 밀리면 비용이 쌓인다

예시의 한 계좌는 9월 7일부터 10일까지 나흘 연속 집중 이체가 빠져 이체 전 잔액이 3억 480만 원에서 8억 5,320만 원까지 불어났습니다. 허용 폭 위에 남은 잔액의 평균은 7,835만 5천 원이고 기회비용은 113,776원입니다. 월말에 합계만 보면 이 흐름이 보이지 않습니다.

같은 "규칙과 다름"도 원인이 다르다

안 옮긴 날, 덜 옮긴 날, 더 옮긴 날, 반대로 옮긴 날은 확인할 사람도 조치도 다릅니다. 이 앱은 일별로 P01~P07 을 남기고 계좌 월에는 먼저 걸린 하나의 A 코드로 올립니다.

마스터가 받은 금액이 맞는지는 계좌가 아니라 풀에서 본다

참가 계좌마다 이체가 맞아도 마스터 계좌에 들어온 금액이 다를 수 있습니다. 예시의 원화 풀 9월은 참가 계좌 실제 이체 합계 1,713,800,000원 대비 마스터 수신액이 1,688,800,000원으로 25,000,000원 적습니다.

규칙이 비어 있으면 정상으로 보이지 않게 한다

목표 잔액이 비어 있는 계좌는 규칙을 구할 수 없습니다. 이 앱은 일별 P05, 계좌 A04, 풀 M02 로 확인 필요를 남기고 합계에는 0원으로 섞지 않습니다.

사용 방법

1. 조회조건 입력 — 회계연도와 기간(월)은 필수이고, 회사·풀·은행·잔액일 기간·점검 코드·점검 결과는 필요할 때만 고릅니다. 비우거나 "전체"이면 그 조건은 걸리지 않습니다.
2. 조회 — 입력 칸 맨 오른쪽 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다.
3. 요약 확인 — 위쪽 요약에서 미집중 평잔, 기회비용, 미이행 계좌, 수신 불일치 풀, 확인 필요 계좌를 먼저 봅니다.
4. 탭 넘기기 — 참가 계좌 판정 → 일별 이체 → 풀 수신 대사 → 대사 결과 순서로 봅니다.
5. 행 누르기 — 참가 계좌를 누르면 판정 근거와 일별 이체가 상세 창으로 열립니다.

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

자금 회의에서 가장 비싼 질문은 "이 금액 맞아?" 입니다. 만드는 쪽에서 먼저 대사식을 세우고 예시 데이터 전체를 돌려 보았습니다.

검사 합계 1,467건에서 차이는 0건입니다. 의도적으로 넣은 예외는 원화 풀 9월 마스터 수신 차이 25,000,000원 1건(검사 4건)이며 대사 결과에 별도 항목으로 남깁니다. 한계도 있습니다. 미이행일의 잔액이 다음 날 규칙에 다시 들어가므로 월 규칙 이체 합계는 금액보다 일수와 건수로 읽어야 합니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있습니다. 숫자는 모두 같은 예시 데이터에서 나와 화면끼리 맞춰 보셔도 됩니다.

처음 연 화면

조회조건 · 요약 · 참가 계좌 판정이 한 화면에 뜹니다.

참가 계좌 9개, 미집중 평잔 합계 87.3백만원, 기회비용 126,714원, 미이행 계좌 1개, 수신 불일치 풀 1개, 확인 필요 계좌 1개, 정합성 대사 차이 0건이 요약에 보입니다. 조회 버튼은 입력 칸 오른쪽 끝에 있습니다.

점검 코드로 거르기 — 점검 필요 계좌

점검 결과를 "점검 필요"로 고르면 규칙대로 이행하지 않은 계좌만 남습니다.

5개 계좌가 남고 일별 이체 탭 건수는 12건으로 줄어듭니다. 원화 풀 계좌와 달러 풀 계좌가 함께 있어 통화 열과 환율(가정값) 열이 같이 보입니다.

일별 이체

이체 전 잔액에서 목표 잔액을 뺀 규칙 이체액과 실제 이체액을 일자별로 견줍니다.

9월 180건(계좌 9 × 20영업일)이 일자순으로 열립니다. 이체 전 잔액·목표 잔액·허용 폭·규칙 이체액·실제 이체액이 한 줄에 있고, 오른쪽으로 넘기면 차이·이체 후 잔액·판정이 이어집니다.

풀 수신 대사

풀마다 참가 계좌 이체 합계와 마스터 계좌 수신액을 견줍니다.

원화 풀 9월은 참가 계좌 실제 이체 합계 1,713,800,000원에 마스터 수신액이 1,688,800,000원으로 25,000,000원 적어 점검 필요(M01)입니다. 달러 풀은 수신액이 일치하지만 목표 잔액이 빈 계좌가 있어 확인 필요(M02)입니다.

대사 결과

서비스가 계산한 대사식의 좌변·우변 합계와 검사·차이 건수입니다.

일반 대사 6종은 모두 차이 0건이고, 의도적으로 넣은 풀 수신 대사 예외 1건(검사 4건, 차이 1건, 최대 25,000,000원)은 별도 항목으로 기록합니다.

계좌 상세

행을 누르면 판정 근거와 그 계좌의 일별 이체가 한 창에 모입니다.

목표 잔액·허용 폭·마스터 운용 금리·참가 계좌 금리, 미이행일·일부이행일·과다일·방향상이일, 미집중 평잔과 기회비용, 판정 문장과 근거가 나오고 아래에 그 계좌의 일별 이체가 붙습니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 참가 계좌 판정 · 일별 이체 · 풀 수신 대사 · 대사 결과 네 블록을 각각 조회조건과 함께 부르고, 요약의 미집중 평잔 합계와 미이행 계좌 수는 서비스의 함수로 받습니다. 나머지 요약은 조회 결과에서 한 곳의 계산식으로 구합니다.

판정 조건과 사용자 조치

일별 판정은 목표 잔액 → 방향 → 이체 유무 → 크기 순으로 가리고, 계좌는 표의 위에서 아래 순서로 먼저 걸린 코드가 판정이 됩니다. 처리 순서는 ① 이체 전 잔액 ② 규칙 이체액 ③ 차이와 이체 후 잔액 ④ 잔여 초과·부족 ⑤ 계좌 월 집계 ⑥ 풀 수신 대사 ⑦ 대사식 계산입니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

좁은 화면에서는 조회조건이 여러 줄로 접히고 요약은 줄바꿈되어 이어집니다. 표는 고정 열을 둔 채 가로로 넘기며, 상세 창은 화면 폭에 맞춰 줄어듭니다.

파일 구성

앱 폴더/
├─ index.html · Component.js · manifest.json
├─ controller/   BaseController · Main.controller
├─ view/         Main.view.xml · DetailDialog.fragment.xml
├─ model/        formatter · ErrorHandler
├─ css/ · i18n/
├─ odata/        서비스 정의 · 서비스 로직 · 데이터
└─ media/        소개 영상 · 대표 이미지

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 풀링 규칙 대비 이행 점검 관점을 더해 확장합니다.

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

T-code 별 연계 지점

그래서 운영 전환 때 기존 표준 보고서를 없애지 않습니다. 이 앱은 표준이 주는 숫자를 "규칙대로 옮겼는가"라는 관점으로 읽는 자리이고, 표준 화면은 원천 확인과 전기에 남습니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱은 이미 집계된 현금 위치를 여러 축으로 보는 데 강합니다. 이 앱은 그 옆에서 "규칙 이체액을 다시 구해 실제와 견주는" 판정 한 단계를 맡고, 집계는 운영에서 CDS 가 담당합니다.

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

분석 지표 정의표

CDS 구성

예시 화면은 참가 계좌 18건(월 9건 × 2개월)과 일별 이체 360건을 서비스 데이터로 들고 있지만, 운영에서는 은행 거래명세를 CDS 로 내려 집계합니다. 아래는 그때 만드는 객체를 레이어 순서대로 적은 것입니다. 표준 필드명은 환경마다 달라 "확인 필요"로 표시했습니다.

뷰 레이어 구성

① 풀링 규칙 테이블

계좌마다 목표 잔액과 허용 폭, 마스터 계좌를 둡니다. 유효 시작일을 키에 넣어 규칙을 바꿔도 지난 판정이 흔들리지 않게 합니다.

"  ZT_PoolRule — 풀링 규칙 (투명 테이블)
"  역할 : 계좌 · 유효 시작일별 목표 잔액과 허용 폭
"  나눈 이유 : 규칙은 자금 회의마다 바뀐다. 코드가 아니라 표에 둔다.
@EndUserText.label : 'Pooling rule'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zt_poolrule {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key acct_id    : abap.char(10) not null;
  key valid_from : abap.dats not null;
  pool_id        : abap.char(4);
  master_acct    : abap.char(10);            " 마스터 계좌
  @Semantics.amount.currencyCode : 'zt_poolrule.waers'
  target_bal     : abap.curr(23,2);          " 목표 잔액
  @Semantics.amount.currencyCode : 'zt_poolrule.waers'
  tol_amt        : abap.curr(23,2);          " 허용 폭
  waers          : waers;
}

② 일별 은행 잔액 뷰

전자 은행 거래명세에서 계좌별 일 잔액과 입금·출금을 읽습니다.

" ZI_PoolBalDaily — 일별 은행 잔액
" 확인 필요 : 명세 헤더·항목의 필드는 고객사 설정에 따른다
@EndUserText.label: 'Daily bank balance'
define view entity ZI_PoolBalDaily
  as select from febko
{
  key bukrs   as Bukrs,
  key hbkid   as HouseBank,
  key hktid   as AcctId,
  key azdat   as BalDate,
      ssbtr   as OpenBal,    // 필드 확인 필요
      esbtr   as CloseBal    // 필드 확인 필요
}

③ 마스터 이체 항목 뷰

마스터 계좌와 오간 이체 항목을 일자별로 모읍니다. 부호는 마스터로 집중이 양수입니다.

" ZI_PoolTransfer — 마스터 계좌와 오간 이체
" 역할 : 실제 이체액의 원천 (차변·대변 구분으로 부호 결정)
@EndUserText.label: 'Master transfer'
define view entity ZI_PoolTransfer
  as select from febep as p
    inner join febko as k on k.kukey = p.kukey
{
  key k.bukrs as Bukrs,
  key k.hktid as AcctId,
  key k.azdat as BalDate,
      sum( case p.vgext when 'POOL_OUT' then p.kwbtr
                        when 'POOL_IN'  then 0 - p.kwbtr
                        else 0 end ) as ActualAmt   // 필드 확인 필요
}
group by k.bukrs, k.hktid, k.azdat

④ 규칙 계산 뷰

이체 전 잔액에서 목표 잔액을 빼 허용 폭 밖일 때만 규칙 이체액으로 삼고, 실제 이체액과 견줘 일별 코드를 정합니다. 규칙은 이 뷰 한 곳에만 둡니다.

" ZI_PoolRuleCalc — 이체 전 잔액 · 규칙 이체액 · 차이
" 나눈 이유 : 규칙 계산을 한 번만 구현한다.
@EndUserText.label: 'Pooling rule calculation'
define view entity ZI_PoolRuleCalc
  as select from ZI_PoolBalDaily as d
    inner join zt_poolrule as r
      on r.bukrs = d.Bukrs and r.acct_id = d.AcctId
    left outer join ZI_PoolTransfer as t
      on t.Bukrs = d.Bukrs and t.AcctId = d.AcctId and t.BalDate = d.BalDate
{
  key d.Bukrs, key d.AcctId, key d.BalDate,
  d.OpenBal + d.InAmt - d.OutAmt as PreBal,
  case when r.target_bal = 0 then 0
       when abs( ( d.OpenBal + d.InAmt - d.OutAmt ) - r.target_bal ) > r.tol_amt
         then ( d.OpenBal + d.InAmt - d.OutAmt ) - r.target_bal
       else 0 end                 as RuleAmt,
  coalesce( t.ActualAmt, 0 )      as ActualAmt
}

⑤ 계좌 월 집계 뷰

일별 코드를 세어 계좌 월 판정(A 코드)을 가립니다. 판정 우선순위는 case 의 순서로 표현합니다.

" ZI_PoolAcctMonth — 계좌 월 집계와 A 코드
@EndUserText.label: 'Account month summary'
define view entity ZI_PoolAcctMonth
  as select from ZI_PoolRuleCalc
{
  key Bukrs, key AcctId,
  substring( cast( BalDate as abap.char(8) ), 1, 6 ) as YearMonth,
  sum( case DayCode when 'P01' then 1 when 'P04' then 1 else 0 end ) as MissDays,
  sum( case DayCode when 'P07' then 1 else 0 end )                   as PartDays,
  sum( case DayCode when 'P03' then 1 else 0 end )                   as DirDays,
  case
    when max( TargetBal ) = 0  then 'A04'
    when sum( case DayCode when 'P03' then 1 else 0 end ) >= 1 then 'A03'
    else 'A00'                                   // 이하 A01 · A05 · A02 · A06 는 같은 방식
  end as CheckCode
}
group by Bukrs, AcctId, substring( cast( BalDate as abap.char(8) ), 1, 6 )

⑥ 풀 수신 대사 뷰

참가 계좌 실제 이체 합계와 마스터 계좌 수신액을 풀마다 맞춥니다.

" ZI_PoolRecv — 풀 수신 대사
@EndUserText.label: 'Pool receipt check'
define view entity ZI_PoolRecv
  as select from ZI_PoolAcctMonth as a
    left outer join ZI_PoolMasterRecv as m on m.PoolId = a.PoolId and m.YearMonth = a.YearMonth
{
  key a.PoolId, key a.YearMonth,
  sum( a.ActualSum )                       as ActualNet,
  max( m.MasterRecv )                      as MasterRecv,
  max( m.MasterRecv ) - sum( a.ActualSum ) as MasterDiff
}
group by a.PoolId, a.YearMonth

⑦ 권한 DCL

회사코드 표준 권한 객체를 집계 뷰에 겁니다. 상세에만 걸면 합계와 자기 몫의 차이로 다른 법인의 규모가 드러납니다.

@EndUserText.label: 'Company code authorization'
@MappingRole: true
define role ZI_PoolAcctMonth {
  grant select on ZI_PoolAcctMonth
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의

화면이 읽는 엔티티셋과 같은 이름으로 노출해 서비스 계약을 유지합니다.

@EndUserText.label: 'Pooling check service'
define service ZS_PoolCash {
  expose ZI_PoolAcctMonth as AccountSet;
  expose ZI_PoolRuleCalc  as DailySet;
  expose ZI_PoolRecv      as PoolSet;
}

운영 데이터로 갈 때

거래명세가 수천만 건이면 일별 규칙 계산을 화면이 아니라 DB 에서 해야 합니다. 기간 파라미터와 회사코드를 필수로 두고, 명세일과 회사코드의 인덱스를 확인하며, 월 단위로 읽어 응답 시간을 3초 안에 두는 것을 기준으로 삼는 편이 안전합니다.

자주 묻는 질문

도입 검토에서 나올 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

판정과 활용

도입과 운영