지급 예정 예측 점검 — 미지급 매입송장의 지급일을 영업일로 옮겨 앞으로 12주의 지급 일정을 만들고 주 지급 한도를 넘는 주와 연기·조기지급 제안을 가리는 매입 채무 화면

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

매입 채무 담당자는 매주 같은 질문을 받습니다. '다음 달 둘째 주에 나갈 돈이 한도를 넘지 않나?', '만기가 토요일인 건은 언제 나가나?', '할인 조건이 있는 건은 앞당겨 주는 편이 낫나?' 표준 보고서는 미결 항목과 지급 실행 결과를 정확히 보여 주지만, 앞으로 12주를 주 단위로 펼쳐 한도와 견주는 일은 대개 엑셀에서 손으로 합니다.

이 앱은 그 자리를 메웁니다. 미지급 송장마다 지급조건으로 만기일을 구하고 휴무일이면 다음 영업일로 옮긴 뒤, 지급 주차별로 모아 회사가 정한 주 지급 한도와 견주고, 한도를 넘는 주에는 지급 연기를, 할인 수익이 큰 건에는 조기지급을 제안합니다. 숫자는 대사식 7종이 서비스 안에서 다시 맞춰 봅니다.

핵심 포인트 여섯 가지

만기만 봐서는 지급이 몰리는 주가 보이지 않는다

회사 1000 의 10주차 지급 예정액은 3,034,680,000 원으로 한도의 202% 입니다. 12월 13일이 일요일이라 만기가 12월 14일로 옮겨지면서 큰 금액 세 건이 같은 주에 겹친 결과입니다. 만기일 목록만 정렬해서는 이 겹침이 드러나지 않습니다.

휴무 이월은 주차를 바꾼다

만기일이 금요일이면 같은 주에 나가지만 토요일이면 다음 주 월요일로 넘어가 다른 주의 한도를 씁니다. 이 앱은 이월일수와 지급 주차를 건마다 보여 주고, 주차가 바뀌는 건을 D02 로 가립니다.

연기할 건을 고를 때는 다음 주 사정도 봐야 한다

한도를 넘는 건을 다음 주로 미루면 다음 주가 다시 한도를 넘을 수 있습니다. 이 앱은 옮길 주의 한도를 먼저 확인하고, 지급 유예가 허용되지 않는 거래처나 할인 수익이 큰 건은 연기 대상에서 뺍니다.

예측에서 빠진 건이 조용히 사라지지 않게 한다

지급 차단, 지급조건 미설정, 12주 밖으로 넘어가는 건은 합계에서 빠지는 것이 맞지만 빠졌다는 사실이 보이지 않으면 총액이 작아 보입니다. 이 앱은 건마다 판정 코드를 남기고 대사 결과에 건수를 따로 적습니다.

사용 방법

1. 조회조건 입력 — 회계연도와 기간(월)은 필수이고, 회사·거래처 그룹·지급일 기간·점검 코드·점검 결과는 필요할 때만 고릅니다. 비우거나 "전체"이면 그 조건은 걸리지 않습니다.
2. 조회 — 입력 칸 맨 오른쪽 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다.
3. 요약 확인 — 위쪽 요약에서 한도 초과 주와 초과액, 제안 반영 후 남는 초과액, 확인 필요 건을 먼저 봅니다.
4. 탭 넘기기 — 지급 예정 판정 → 주별 지급 일정 → 조정 제안 → 대사 결과 순서로 봅니다.
5. 행 누르기 — 지급 예정 건을 누르면 판정 근거가 상세 창으로 열립니다.

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

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

검사 합계 423건에서 차이는 0건입니다. 의도적으로 넣은 예외 건은 지급 차단 3건, 지급조건 미설정 2건, 12주 밖 12건으로 대사 결과에 별도 항목으로 남깁니다.

무엇으로 만들었나

실행 화면

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

처음 연 화면

조회조건 · 요약 · 지급 예정 판정이 한 화면에 뜹니다.

지급 예정 175건과 12주 지급 예정액 10,979.0백만원이 요약에 보이고, 한도 초과 주는 6주, 초과액은 2,045.2백만원입니다. 제안을 반영하면 남는 초과액은 1,402.3백만원이고 조기지급 할인 기회는 8,278,812원입니다.

점검 코드로 거르기

점검 코드를 "D02 휴무 이월"로 고르면 만기일이 휴무일이라 지급 주차가 바뀔 수 있는 건만 남습니다.

57건이 남습니다. 이월일수와 만기일, 지급 예정일, 제안 반영 후 주차가 한 줄에 나란히 있어 어느 건이 주를 넘어가는지 바로 보입니다.

주별 지급 일정

주마다 지급 예정액을 주 지급 한도와 견주어 사용률과 초과액을 보여 줍니다.

회사 1000 의 10주차는 지급 예정액 3,034,680,000 원으로 한도 1,500,000,000 원의 202.31% 이고 초과액이 1,534,680,000 원이라 점검 필요입니다. 누적 지급액과 누적 한도도 함께 보입니다.

조정 제안

한도를 넘는 주의 건은 다음 주로 미루고 할인 수익이 큰 건은 앞 주로 당기는 제안입니다.

제안은 25건이며 지급 연기 7건, 조기지급 18건입니다. 현재 주차와 제안 주차, 현재 지급일과 제안 지급일, 효과 금액과 근거 문장이 건마다 붙습니다.

대사 결과

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

7종의 대사식은 모두 차이 0건이고, 의도적으로 넣은 예외 건(지급 차단 · 지급조건 미설정 · 12주 밖)은 별도 항목으로 건수만 기록합니다.

지급 예정 건 상세

행을 누르면 판정 근거가 한 창에 모입니다.

기준일 · 지급조건, 만기일에서 지급 예정일로의 이월, 조기지급 할인율과 연환산 수익률, 지급 유예 허용 일수가 나오고 아래에 판정 문장과 근거가 붙습니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 지급 예정 판정 · 주별 지급 일정 · 조정 제안 · 대사 결과 네 블록을 각각 조회조건과 함께 부르고, 요약의 한도 초과액과 한도 초과 주 수는 서비스의 함수로 받습니다. 나머지 요약은 조회 결과에서 한 곳의 계산식으로 구합니다.

판정 조건과 사용자 조치

판정 우선순위는 표의 위에서 아래입니다. 처리 순서는 ① 건마다 만기일과 지급 예정일 산출 ② 지급 주차별 합계 ③ 한도와 비교 ④ 지급 연기 제안 ⑤ 조기지급 제안 ⑥ 제안 반영 후 지급액 ⑦ 대사식 계산입니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

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

파일 구성

앱 폴더/
├─ 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 가 담당하고, 이 화면은 12주 지급 일정과 한도 점검 관점을 더해 확장합니다.

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

T-code 별 연계 지점

그래서 운영 전환 때 기존 표준 보고서를 없애지 않습니다. 이 앱은 표준이 주는 숫자를 12주와 한도라는 관점으로 읽는 자리이고, 표준 화면은 원천 확인과 지급 실행에 남습니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱은 이미 집계된 채무를 여러 축으로 보는 데 강합니다. 이 앱은 그 옆에서 "앞으로 12주"와 "한도를 넘는 주에 무엇을 옮길까"라는 판정·제안 한 단계를 맡고, 집계는 운영에서 CDS 가 담당합니다.

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

분석 지표 정의표

CDS 구성

예시 화면은 지급 예정 건 175건과 주별 지급 일정 24건을 서비스 데이터로 들고 있지만, 운영에서는 미결 항목을 CDS 로 내려 주 단위로 집계합니다. 아래는 그때 만드는 객체를 레이어 순서대로 적은 것입니다. 표준 필드명은 환경마다 달라 "확인 필요"로 표시했습니다.

뷰 레이어 구성

① 주 지급 한도 테이블

회사별로 주 번호마다 지급 한도를 둡니다. 유효 시작일을 키에 넣어 한도를 바꿔도 지난 판정이 흔들리지 않게 합니다.

"  ZPYFC_WKLIMIT — 주 지급 한도 (투명 테이블)
"  역할 : 회사 · 주 시작일별 지급 한도
"  나눈 이유 : 한도는 자금 회의마다 바뀐다. 코드가 아니라 표에 둔다.
@EndUserText.label : 'Weekly payment limit'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpyfc_wklimit {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key week_start : abap.dats not null;     " 주 시작일(월요일)
  @Semantics.amount.currencyCode : 'zpyfc_wklimit.waers'
  limit_amt      : abap.curr(23,2);        " 주 지급 한도
  waers          : waers;
}

② 영업일 뷰

공장 달력에서 영업일만 뽑아 지급 예정일 계산이 한 곳을 보게 합니다.

" ZI_PayCalendar — 영업일 (공장 달력)
" 확인 필요 : 공장 달력 테이블과 필드는 고객사 설정에 따른다
@EndUserText.label: 'Business day'
define view entity ZI_PayCalendar
  as select from scal_tt_date
{
  key calendar_id as CalendarId,
  key calendar_date as CalDate,
      is_workday    as IsWorkday      // 필드 확인 필요
}
where is_workday = 'X' 

③ 미결 송장 기본 뷰

공급업체 미결 항목에 지급조건 일수와 차단 표시를 붙입니다.

" ZI_PayDueItem — 미지급 송장 (BSIK)
" 역할 : 금액 · 기준일 · 지급조건 · 지급 차단 표시
@EndUserText.label: 'Open payable item'
define view entity ZI_PayDueItem
  as select from bsik as i
    left outer join lfa1 as v on v.lifnr = i.lifnr
{
  key i.bukrs as Bukrs,
  key i.belnr as DocNo,
  key i.buzei as ItemNo,
      i.lifnr as VendorNo,
      v.name1 as VendorName,
      i.wrbtr as Amount,         // 필드 확인 필요
      i.zfbdt as BaseDate,       // 필드 확인 필요
      i.zbd1t as TermDays,       // 필드 확인 필요
      i.zlspr as BlockFlag       // 필드 확인 필요
}

④ 지급 예정일 계산 뷰

만기일에 휴무 이월을 적용해 지급 예정일과 지급 주차를 구합니다. 이월 규칙은 이 뷰 한 곳에만 둡니다.

" ZI_PayDueDate — 만기일 · 지급 예정일 · 주차
" 나눈 이유 : 휴무 이월 규칙을 한 번만 구현한다.
@EndUserText.label: 'Payment due date'
define view entity ZI_PayDueDate
  as select from ZI_PayDueItem as i
    left outer join ZI_PayCalendar as c
      on c.CalDate >= dats_add_days(i.BaseDate, i.TermDays, 0)
     and c.IsWorkday = 'X'
{
  key i.Bukrs, key i.DocNo, key i.ItemNo,
      i.Amount,
      dats_add_days(i.BaseDate, i.TermDays, 0) as DueDate,
      min(c.CalDate)                            as PayDate
}
group by i.Bukrs, i.DocNo, i.ItemNo, i.Amount, i.BaseDate, i.TermDays

⑤ 주별 집계 큐브

지급 예정일이 속한 주를 DB 에서 정해 주마다 합치고 한도와 견줍니다. 화면의 주별 탭이 이 뷰를 읽습니다.

" ZI_PayWeek — 주별 지급 예정액 vs 한도
@EndUserText.label: 'Weekly payment'
@Analytics.dataCategory: #CUBE
define view entity ZI_PayWeek
  as select from ZI_PayDueDate as d
    left outer join zpyfc_wklimit as l
      on l.bukrs = d.Bukrs
{
  key d.Bukrs,
  key l.week_start as WeekStart,
      sum(d.Amount) as PayAmt,
      l.limit_amt   as LimitAmt,
      case when sum(d.Amount) > l.limit_amt
           then sum(d.Amount) - l.limit_amt else 0 end as OverAmt
}
group by d.Bukrs, l.week_start, l.limit_amt

⑥ 분석 쿼리

화면과 표준 분석 도구가 같은 필터를 쓰게 합니다. 회사와 기간은 필수에 가깝게 두어 응답 시간을 지킵니다.

" ZC_PayForecastQuery — 조회조건 + 분석 쿼리
@EndUserText.label: 'Payment forecast query'
@Analytics.query: true
define view entity ZC_PayForecastQuery
  as projection on ZI_PayWeek
{
  key Bukrs,
  key WeekStart,
      PayAmt,
      LimitAmt,
      OverAmt
}

⑦ 권한 정의(DCL)

집계를 읽는 자리에 권한을 겁니다. 상세에만 걸면 합계와 자기 몫의 차이로 다른 법인의 지급 규모가 드러납니다.

" ZI_PAYWEEK — 회사코드 권한
@EndUserText.label: 'Payment week access'
@MappingRole: true
define role ZI_PAYWEEK {
  grant select on ZI_PayWeek
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의

화면이 부르는 서비스를 한 곳에 묶습니다. 화면은 서비스 주소만 알면 되고 뷰 구조가 바뀌어도 서비스 계약은 유지됩니다.

" ZUI_PayForecast — 서비스 정의
@EndUserText.label: 'Payment forecast service'
define service ZUI_PayForecast {
  expose ZC_PayForecastQuery as WeekSet;
  expose ZI_PayDueDate       as DueSet;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

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

자주 묻는 질문

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

숫자와 산식

화면과 조작

판정과 활용

도입과 운영