회수 예측 점검 — 만기일이 아니라 거래처의 지급 습관으로 다시 구한 주차별 회수액을 장부와 견주는 자금 예측 화면

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

자금 담당자가 매주 받는 질문은 단순합니다. 다음 주에 얼마가 들어오나, 그 숫자를 얼마나 믿어도 되나. 장부의 미결 매출채권은 만기일이 정해져 있어서 만기일이 속한 주에 들어온다고 잡으면 표 하나가 금방 나옵니다. 그런데 거래처마다 실제로 돈을 보내는 날은 만기일과 다르고, 그 차이는 대체로 거래처마다 일정한 습관으로 반복됩니다. 만기일 기준 예측이 매주 같은 방향으로 빗나가는 까닭입니다.

이 앱은 같은 미결 채권을 두 번 놓습니다. 한 번은 만기일 그대로(장부), 한 번은 만기일 + 그 거래처의 최근 6건 평균 지연일(재계산)입니다. 두 결과를 8주 주차별로 나란히 보여 주고, 주차가 달라지는 채권과 근거를 회사가 먼저 확인해야 하는 채권을 골라 줍니다. 마지막으로 직전 4주에는 어느 쪽이 실제 입금에 더 가까웠는지까지 보여 줍니다. 기준일은 2026-10-09 이며, 화면의 판정은 모두 “점검 필요”·“확인 필요”로만 표시합니다. 결론이 아니라 살펴볼 대상을 고르는 기준입니다.

만기일로 잡은 회수 예측은 거래처의 습관을 모른다

미결 채권 124건의 만기일을 그대로 주차에 얹으면 첫 주에 들어올 돈이 크게 잡힙니다. 하지만 평균 지연일이 길게 쌓인 거래처의 채권은 같은 주에 들어오지 않습니다. 표준 화면에서는 거래처별 지급 이력을 따로 열어 평균을 내고, 그 평균을 만기일에 더해 주차를 다시 나누는 일을 엑셀로 합니다. 이 앱은 그 계산을 화면 안에서 같은 규칙(최근 6건, 반올림한 평균, 이력 3건 미만이면 미반영)으로 매번 똑같이 합니다. 담당자가 바뀌어도 산식이 바뀌지 않습니다.

장부 주차와 재계산 주차가 어긋난 채로 자금 계획이 간다

자금 계획은 주 단위로 잡히는데, 어느 채권이 다음 주에서 다다음 주로 밀리는지는 합계표만으로는 보이지 않습니다. 이 앱의 미결 채권 명세는 채권마다 만기일, 재계산한 예상 입금일, 장부 주차, 재계산 주차를 한 줄에 놓습니다. 주차가 달라지는 건은 “점검 필요”, 분쟁 보류·예상일 경과 이월·지급 이력 부족처럼 근거를 먼저 확인해야 하는 건은 “확인 필요”로 표시합니다. 이번 검증용 샘플 데이터에서는 124건 가운데 58건의 주차가 달라지고 50건이 확인 필요로 분류됩니다.

예측이 얼마나 빗나갔는지 돌아보지 않으면 같은 오차가 반복된다

지급행태를 반영한 예측이 더 좋은지는 주장이 아니라 지난 실적으로 확인할 일입니다. 직전 4주마다 실제 입금액과 두 예측(만기일 기준 · 지급행태 반영)의 오차율을 구해 어느 쪽이 더 가까웠는지, 얼마나 개선되었는지를 보여 줍니다. 실적 입금이 3건 미만인 주는 비교를 보류하고 “확인 필요”로 둡니다. 이번 샘플에서는 8개 회사·주차 가운데 6개에서 지급행태 반영 예측이 더 가까웠고 2개에서는 오히려 더 멀었습니다 — 이 두 개는 감추지 않고 “점검 필요”로 올립니다.

사용 방법

1. 조회조건 입력 — 화면 위쪽에서 회계연도(필수 · 4자리)를 입력합니다. 회사 · 거래처 · 예상 입금일 시작/종료 · 분쟁 보류 · 점검 코드 · 점검 결과는 선택이며 비우면 걸지 않습니다.
2. 조회 — 조건 영역 안의 조회 버튼을 누르거나 회계연도 칸에서 Enter 키를 누릅니다. 자동 조회는 없으므로 조건을 바꾼 뒤에는 다시 조회합니다.
3. 요약 확인 — 점검한 미결 채권 건수, 주차가 바뀌는 건수·금액, 8주 밖으로 밀리는 금액, 확인 필요 건수, 직전 4주 예측 오차율 개선, 대사 차이 건수가 먼저 보입니다.
4. 탭 이동 — 주차별 회수 예측 → 미결 채권 명세 → 거래처 지급행태 → 직전 4주 예측 검증 → 대사 결과 순서로 봅니다.
5. 행 클릭 상세 — 주차 행을 누르면 그 주차에 입금될 것으로 재계산된 채권이, 거래처 행을 누르면 지급 이력(최근 순, 평균에 반영된 최근 6건 표시)이 열립니다.
6. 내보내기 — CSV 내려받기 버튼으로 지금 보고 있는 탭의 결과를 파일로 받습니다.

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

만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 아래 여덟 가지는 정합성 대사로 모두 차이가 0 이고, 의도적으로 넣은 점검 대상은 차이 건수에 섞지 않고 참고 대사로 따로 세웠습니다.

참고 대사(의도적 예외)는 세 가지입니다 — 장부 주차와 재계산 주차가 다른 채권 58건, 확인 필요로 분류된 채권 50건, 지급행태 반영 오차율이 만기일 기준보다 큰 주차 2개. 이 건들은 잘못이 아니라 이 화면이 일부러 찾아내야 하는 대상이어서 대사 차이와 분리했습니다. 이 앱은 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

무엇으로 만들었나

실행 화면

아래 화면은 검증용 샘플 데이터로 직접 실행해 캡처한 것입니다. 사용 순서대로 일곱 장입니다. 사진을 누르면 크게 볼 수 있습니다.

처음 열었을 때 — 조회 결과와 요약

회계연도와 회사를 고르고 조회하면 요약 숫자가 먼저 보입니다. 기준일 2026-10-09 이후 8주와 기간 밖(00) 행이 한 표에 있고, 장부 회수액(만기일 기준)과 재계산 회수액(지급행태 반영)의 차이가 주차마다 붙습니다. 처음 열면 회계연도 2026, 회사 전체로 조회됩니다.

주차 행을 눌러 그 주에 들어올 채권 보기

장부와 재계산의 금액 차이, 누적, 주차 이동 건수, 확인 필요 비중과 점검 내용이 위에 놓이고 아래에 채권 목록이 이어집니다. 확인 필요 비중이 30퍼센트 이상이면 그 주의 예측은 근거를 먼저 확인하라는 신호입니다.

채권마다 장부와 재계산을 비교한다

예상 입금일(재계산)은 만기일에 반영 지연일을 더한 값입니다. 장부 주차와 재계산 주차가 다르면 점검 필요, 분쟁 보류나 이월 건은 확인 필요로 표시됩니다. 표 머리를 눌러 정렬하고, 조건을 좁혀 거래처 하나만 볼 수도 있습니다.

거래처의 지급 습관을 직접 확인한다

평균 지연일이 길고 편차가 큰 거래처가 위쪽 후보입니다. 지급 이력이 3건 미만인 거래처는 반영 지연일이 0 이고 확인 필요로 표시됩니다. 행을 누르면 그 거래처의 지급 이력이 열립니다.

만기일, 실제 입금일, 지연일, 금액이 최근 순으로 나옵니다. 평균에 쓰인 최근 6건에 표시가 붙어 있어 “이 평균은 어디서 나왔나” 하는 질문에 그 자리에서 답합니다.

지난 4주에 어느 예측이 더 맞았나, 그리고 대사

오차율이 낮은 쪽이 더 가까운 예측입니다. 개선 열이 양수면 지급행태 반영 쪽이 더 가까웠다는 뜻이고 음수면 오히려 멀었다는 뜻입니다. 실적 입금이 3건 미만인 주는 비교를 보류하고 확인 필요로 둡니다.

정합성 대사 8종은 차이 건수가 모두 0 이어야 합니다. 아래 참고 대사 세 줄은 일부러 찾아내야 하는 대상(주차 이동 · 확인 필요 · 예측이 더 멀었던 주)의 건수이며 차이로 세지 않습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 조회조건이 서버 필터 한 벌로 묶여 다섯 개 탭의 표에 같은 조건으로 적용됩니다. 서비스는 다음 순서로 계산합니다.

1. 지급행태 — 거래처별로 이미 입금된 건의 지연일(실제 입금일 − 만기일) 가운데 최근 6건의 평균을 구하고 반올림해 “반영 지연일”로 씁니다. 이력이 3건 미만이면 지연을 반영하지 않습니다.
2. 예상 입금일 — 만기일 + 반영 지연일. 이 날짜가 기준일(2026-10-09) 이전인데 아직 입금되지 않았으면 1주차로 이월합니다.
3. 주차 배정 — 기준일부터 7일씩 8개 주차에 장부(만기일 기준)와 재계산(예상 입금일 기준)을 각각 나누어 담고, 8주 밖은 “00” 으로 모읍니다.
4. 점검 코드 — 아래 표의 규칙으로 채권 · 주차 · 거래처 · 직전 4주마다 코드를 붙입니다.
5. 대사 — 합계가 서로 맞는지 여덟 가지 대사식으로 검산합니다. 주차를 옮겨도 총액은 그대로여야 합니다.

점검 규칙 — 조건에서 결과, 사용자 조치까지

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

이번에 확인한 화면 폭은 데스크톱(1600 × 1000)입니다. 표는 고정 열 구성이라 좁은 화면에서는 가로로 밀어 보게 되며, 휴대폰 전용 배치는 이번 범위에 넣지 않았습니다. 확인하지 않은 부분이므로 운영 화면에 쓰기 전에 사용할 기기에서 한 번 열어 보시길 권합니다.

파일 구성

index.html · Component.js · manifest.json
controller/   화면 로직 (공통 · 메인)
view/         메인 화면 · 주차 상세 · 거래처 상세
model/        포맷터 · 오류 안내
css/ · i18n/  스타일 · 문구
odata/        서비스 정의 · 서비스 로직 · 검증용 샘플 데이터
media/        소개 영상 · 첫 장면 이미지
readme.html   앱 설명서

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준 화면으로 충분한 일은 표준에 그대로 두고, 표준 화면 여러 개를 오가며 엑셀로 하던 지급행태 계산과 주차 비교만 한 화면에 모았습니다.

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

T-code 별 연계 지점

두 가지 질문이 자주 나옵니다. 첫째, 기존 표준 리포트를 없애야 하나 — 아닙니다. 법정·감사 대응과 원장 기준의 숫자는 표준 화면에 그대로 둡니다. 이 앱은 입금 시점 가정을 점검하는 보조 화면입니다. 둘째, 표준에 남겨 둘 일은 청산 전표 처리, 입금 확인, 대손 판단입니다. 이 앱은 조회 전용이며 어떤 전표도 만들지 않습니다.

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

S/4HANA 의 분석 쿼리와 Fiori 분석 앱은 정해진 지표를 안정적으로 보여 주는 데 강합니다. 이 앱은 그 옆에서 “거래처의 습관으로 다시 계산한 값”이라는 점검용 관점을 더하는 위치입니다. 표준 CDS 분석 뷰나 Analysis for Office 로 같은 원천을 이미 보고 있다면, 이 앱의 CDS 구성(아래)을 그 옆에 같은 방식으로 얹을 수 있습니다. 어떤 표준 분석 뷰를 재사용할 수 있는지는 시스템 버전마다 달라 확인 필요이며, 이 글은 원천 테이블 기준으로 설명합니다.

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

분석 지표 정의표

CDS 구성 — 최대한 자세히

화면이 쓰는 서비스의 원천을 S/4HANA 에서 어떻게 구성하는지 스케치입니다. 원천은 고객 미결 항목(BSID)과 고객 청산 항목(BSAD)이며, 두 테이블의 정확한 필드명과 S/4HANA 에서의 제공 방식(호환 뷰 여부)은 시스템 버전마다 달라 확인 필요로 두고 코드에 주석으로 표시했습니다. 객체 이름은 기능을 뜻하는 영문으로 새로 지었습니다.

뷰 레이어 구성

① 규칙 테이블 — 임계값을 코드 밖으로

최근 몇 건을 쓸지, 최소 몇 건이 있어야 지연을 반영할지, 점검 임계값을 얼마로 둘지는 회사가 정할 일입니다. 코드에 박아 두면 값을 바꿀 때마다 이송이 필요하므로 작은 규칙 테이블에 둡니다. 이 앱의 샘플은 6건 · 3건 · 25퍼센트 · 30퍼센트 · 30일 · 표준편차 10 으로 시작합니다.

@EndUserText.label : '회수 예측 규칙'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zcolldelayrule {
  key client   : abap.clnt not null;
  key bukrs    : bukrs not null;          " 회사 코드
  hist_max     : abap.int1;               " 지급 이력에 쓸 최근 건수 (샘플 6)
  hist_min     : abap.int1;               " 지연 반영에 필요한 최소 건수 (샘플 3)
  week_diff    : abap.dec(5,2);           " 장부와 재계산 차이 임계 비율 (샘플 0.25)
  conf_ratio   : abap.dec(5,2);           " 확인 필요 비중 임계 (샘플 0.30)
  delay_long   : abap.int2;               " 평균 지연 임계 일수 (샘플 30)
}

② 차원 — 거래처

거래처 코드와 이름만 읽는 가장 단순한 뷰입니다. 단순해도 따로 두는 까닭은, 이름 표기를 바꿀 일이 생겼을 때 한 곳만 고치면 되기 때문입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '거래처 (차원)'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_CollectCustomer
  as select from kna1
{
  key kunnr as CustNo,
      name1 as CustName
}

③ 미결 항목 기본 뷰 — 장부 주차의 근거

미결 항목에서 금액·만기일·분쟁 표시를 뽑습니다. 만기일은 기준일과 지급 조건 일수를 더해 구하는데, 어느 필드를 쓰는지(기준일·지급 조건 일수)는 시스템 설정마다 달라 확인 필요입니다. 분쟁 표시도 마찬가지입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '미결 매출채권 기본 뷰'
define view entity ZI_CollectOpenItem
  as select from bsid
  association [0..1] to ZI_CollectCustomer as _Cust on _Cust.CustNo = bsid.kunnr
{
  key bsid.bukrs                                   as CompanyCode,
  key bsid.belnr                                   as DocNo,
  key bsid.gjahr                                   as FiscalYear,
  key bsid.buzei                                   as ItemNo,
      bsid.kunnr                                   as CustNo,
      @Semantics.amount.currencyCode: 'Currency'
      case bsid.shkzg when 'H' then -bsid.dmbtr
                      else bsid.dmbtr end          as Amount,      -- 차대 구분 처리: 확인 필요
      bsid.hwaer                                   as Currency,
      -- 만기일 = 기준일 + 지급 조건 일수 (필드명 확인 필요)
      dats_add_days(bsid.zfbdt,
                    cast(bsid.zbd1t as abap.int4), 'NULL') as DueDate,
      bsid.zlspr                                   as PayBlock,    -- 분쟁 표시로 쓸지는 회사별 확인 필요
      _Cust
}

④ 청산 항목 기본 뷰 — 지연일의 원천

이미 입금된 항목에서 지연일(청산일 − 만기일)을 계산합니다. 이 뷰가 지급행태의 유일한 원천입니다. 청산일 필드를 입금 확인일로 볼지 청산 전표 전기일로 볼지는 회사 정책에 따라 다르므로 확인 필요입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '청산 항목 기본 뷰 (지급 이력)'
define view entity ZI_CollectPaidItem
  as select from bsad
{
  key bsad.bukrs as CompanyCode,
  key bsad.belnr as DocNo,
  key bsad.gjahr as FiscalYear,
  key bsad.buzei as ItemNo,
      bsad.kunnr as CustNo,
      bsad.augdt as PaidDate,                                 -- 청산일: 확인 필요
      dats_add_days(bsad.zfbdt, cast(bsad.zbd1t as abap.int4), 'NULL') as DueDate,
      dats_days_between(
        dats_add_days(bsad.zfbdt, cast(bsad.zbd1t as abap.int4), 'NULL'),
        bsad.augdt)                                           as DelayDays
}

⑤ 지급행태 집계 뷰 — 거래처별 최근 6건

이 앱에서 가장 중요한 뷰입니다. 거래처마다 최근 6건을 골라 평균과 표준편차, 건수를 구합니다. 최근 N건 선택은 윈도 함수가 아니라 행 번호로 처리하는 방식이 이식성이 높습니다. 아래는 개념을 보이는 스케치이며, 실제로는 행 번호용 보조 뷰가 한 단계 더 필요합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '거래처 지급행태 (최근 6건)'
@Analytics.dataCategory: #CUBE
define view entity ZI_CollectDelayStat
  as select from ZI_CollectPaidRanked as r          -- 거래처별 청산일 내림차순 행 번호 부여 뷰
{
  key r.CompanyCode,
  key r.CustNo,
      count(*)                                      as HistCnt,
      avg(r.DelayDays as abap.dec(9,1))             as AvgDelay,
      -- 표준편차는 시스템 버전에 따라 제공 방식이 달라 확인 필요
      case when count(*) >= 3
           then cast(round(avg(r.DelayDays as abap.dec(9,1)), 0) as abap.int4)
           else 0 end                               as ApplyDelay
}
where r.RowNo <= 6
group by r.CompanyCode, r.CustNo

⑥ 주차 쿼리 — 장부와 재계산을 한 행에

미결 항목과 지급행태 집계를 거래처로 붙여 장부 주차와 재계산 주차를 각각 구하고, 주차별로 합산합니다. 주차 경계는 기준일에서 7일 단위이고 8주 밖은 “00” 입니다. 기준일은 파라미터로 받습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '주차별 회수 예측 쿼리'
@Metadata.allowExtensions: true
define view entity ZC_CollectWeekQuery
  with parameters p_baseDate : abap.dats
  as select from ZI_CollectOpenItem as o
  left outer join ZI_CollectDelayStat as s
    on  s.CompanyCode = o.CompanyCode
    and s.CustNo      = o.CustNo
{
  key o.CompanyCode,
  key cast(
        case when dats_days_between($parameters.p_baseDate, o.DueDate) < 0   then '01'
             when dats_days_between($parameters.p_baseDate, o.DueDate) >= 56 then '00'
             else lpad(cast(div(dats_days_between($parameters.p_baseDate, o.DueDate), 7) + 1 as abap.char(2)), 2, '0')
        end as abap.char(2))                      as WeekBook,
      sum(o.Amount)                               as BookAmt
      -- 재계산 주차(만기일 + s.ApplyDelay)도 같은 방식으로 한 열 더 만들어 합산합니다
}
group by o.CompanyCode

⑦ 권한(DCL)과 서비스

회사 코드 단위로 접근을 제어합니다. 집계 쿼리에서는 권한을 집계 전에 거는 것이 중요합니다. 집계 뒤에 걸면 합계에서 뺄셈으로 다른 회사의 숫자가 드러납니다.

@MappingRole: true
define role ZC_CollectWeekQuery {
  grant select on ZC_CollectWeekQuery
    where CompanyCode = aspect pfcg_auth(F_BKPF_BUK, BUKRS, ACTVT = '03');
}

define service ZUI_CollectFcst {
  expose ZC_CollectWeekQuery as WeekSet;
  expose ZI_CollectDelayStat as CustSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 도입할 때 합의가 필요한 항목입니다.

운영 데이터로 갈 때

미결 채권은 수만 건, 청산 항목은 수백만 건이 될 수 있습니다. 가장 먼저 느려지는 곳은 청산 항목에서 거래처별 최근 6건을 고르는 자리입니다. 거래처 단위로 줄인 집계 뷰를 미리 구체화하거나 야간 배치로 갱신하고, 쿼리에는 기준일과 회사 코드를 필수 파라미터로 둡니다. 청산일 필드에 인덱스가 있는지 확인하고, 응답 시간 기준은 도입 전에 정해 두는 편이 안전합니다. 정확한 수치는 운영 환경 측정 후에 정할 일이라 이 글은 수치를 약속하지 않습니다.

자주 묻는 질문

도입 상담과 검증에서 나올 만한 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석과 점검

도입과 운영