결제조건 자금비용 반영 수익성 점검 — 결제조건이 길고 입금이 늦은 거래의 자금비용을 청구마다 반영해 공헌이익이 얼마나 줄어드는지 확인하는 수익성 분석

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

영업은 결제조건을 길게 주고 계약을 따옵니다. 재무는 입금이 늦어지면 독촉을 합니다. 그런데 그 청구가 결국 이익을 얼마나 남겼는지는 어느 쪽에서도 한 번에 보이지 않습니다. 공헌이익은 매출에서 변동비만 빼고, 돈이 들어올 때까지 묶인 자금의 비용은 다른 보고서나 엑셀로 따로 계산하기 때문입니다. 이 화면은 그 자금비용을 청구 한 줄마다 약정 기간분과 지연 기간분으로 나눠 붙이고, 자금비용을 뺀 공헌이익률로 다시 점검합니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 공헌이익률 14.47%가 13.39%가 되는 과정

검증용 샘플의 판정 대상 청구 64건(입금 미완료 4건 제외)을 합치면 매출액은 194.76억원, 공헌이익은 28.18억원(공헌이익률 14.47%)입니다. 여기서 자금비용 2.09억원을 빼면 자금비용 반영 공헌이익은 26.08억원, 반영 후 공헌이익률은 13.39%입니다. 자금비용은 약정 기간분 1.77억원과 지연 기간분 0.32억원으로 나뉘고, 공헌이익의 약 7.4%에 해당합니다. 전체로는 1.08%p 가 빠진 정도지만, 조건별로 보면 차이가 큽니다.

120일 후 지급 조건은 공헌이익률 11.68% 에서 반영 후 10.00% 로 내려가고, 판정 대상 13건 중 9건이 점검 필요입니다. 반면 30일 후 지급 조건은 16.00% 에서 15.54% 로 거의 그대로입니다. 청구 하나를 보면 120일 조건의 한 건은 공헌이익률 7.17% 에서 반영 후 5.85% 로 내려가고 자금비용이 공헌이익의 18.39% 를 차지합니다. 매출액과 공헌이익률만 봤다면 “거래가 이어지고 있다”로 끝났을 숫자입니다. 다만 이 표시는 점검 필요일 뿐, 단가 협상 문제인지 조건 설정 문제인지는 화면이 판단하지 않고 확인 순서만 정해 줍니다. 점검 필요 17건의 내역은 공헌이익률 미달 8건, 자금비용 비중 초과 6건, 입금 지연 3건입니다.

도입하면 달라지는 것

• 결제조건 협상의 근거 — “조건을 길게 줘도 되는가”를 매출이 아니라 반영 후 공헌이익률로 이야기합니다.
• 회수 관리의 우선순위 — 입금이 30일 이상 늦은 청구와 자금비용 비중이 큰 청구를 먼저 확인합니다.
• 고객·조건 비교 — 같은 지표가 결제조건 4종·고객 12곳으로 합산되어 부담이 큰 자리가 한눈에 보입니다.
• 숫자를 믿는 근거 — 8개 대사식과 의도적 예외가 화면에 그대로 나와 “이 숫자 맞아?”에 바로 답할 수 있습니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지 아래에 적었습니다. 숫자는 모두 가상의 검증용 샘플에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

조회하고 걸러내기

조회조건은 회계연도·결제조건·고객·청구일 범위·점검 결과이고, 조회 버튼은 조건 영역 오른쪽 끝에 있습니다. 회계연도 입력 칸에서 Enter 키를 눌러도 조회됩니다. 요약 지표는 입금 미완료 청구 4건을 빼고 판정 대상 64건으로 더합니다.

점검 필요는 세 가지입니다. 반영 후 공헌이익률이 기준(9.00%)에 못 미치는 청구, 자금비용이 공헌이익의 13.00% 이상인 청구, 약정 입금기한보다 30일 이상 늦게 입금된 청구입니다. 표시는 원인을 단정하지 않고 확인 순서만 정해 줍니다.

요인과 요약

매출액 − 변동비 = 공헌이익, 공헌이익 − 약정 기간 자금비용 − 지연 기간 자금비용 = 자금비용 반영 공헌이익이 되도록 맞춰 두었고, 구성비와 산식 칸이 함께 있어 숫자가 어디서 나왔는지 바로 읽힙니다. 이 합은 대사식 R07·R08 로 전수 검증합니다.

30·60·90·120일 조건을 같은 지표로 견줍니다. 점검 필요 비율이 35% 이상이거나 반영 후 공헌이익률이 기준에 못 미치면 그 결제조건을 점검 필요로 표시합니다.

결제조건과 고객은 같은 청구 판정 행을 서로 다른 축으로 합산한 것이라 두 요약의 반영 후 공헌이익 합계는 같습니다(대사식 R05·R06).

근거까지 내려가기

약정 일수와 실제 회수 일수, 지연 일수를 같은 자리에서 확인합니다. 결제조건·고객 행을 누르면 소속 청구가 나옵니다.

정합성 대사 8건의 차이는 모두 0건입니다. 예외 4건은 대사 차이 건수와 분리해 R09 로 기록합니다.

SAP 표준 기능 확장 포인트

이 화면은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 화면인지를 먼저 적습니다.

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

표준 기능과 이어 쓰는 순서

1. 화면에서 점검 필요 청구를 고릅니다. 결제조건·고객 요약으로 부담이 큰 자리를 먼저 찾습니다.
2. 합계를 표준 수익성 보고서(KE30)와 맞춰 봅니다. 합계가 어긋나면 기간·조회 범위부터 확인합니다.
3. 개별 항목(KE24)과 청구 문서(VF03)로 내려가 매출과 변동비의 원천 전기를 확인합니다.
4. 고객 개별 항목(FBL5N)에서 입금일과 반제 내역을, 잔액(FD10N)에서 미입금 청구의 남은 금액을 확인합니다.

표준에 없는 자리

청구마다 자금비용을 걷어낸 판정과 약정 기간·지연 기간 구분은 표준에 없습니다. 이 화면이 그 계산을 하고, 계산에 쓴 가정(연 자금비용률 4.50%, 판정 기준 9.00%·13.00%·30일, 요약 행 기준 35%)을 모두 샘플 값으로 밝혀 둡니다. 운영에서는 이 가정을 회사 기준에 맞춰 정해야 하며, 그 결정이 도입에서 가장 큰 일입니다.

OData 서비스 계약

화면은 manifest 에 선언한 상대 경로의 OData V2 서비스 하나만 부릅니다. 서비스 이름은 소문자 termprofit_srv 이고 엔티티셋 5개(InvoiceSet · FactorSet · TermSet · CustSet · ReconSet)와 펑션 2개(GetMinNetRate · GetMaxNetRate)를 노출합니다. 조회조건은 모두 $filter 로, 정렬·페이징은 $orderby · $top · $skip 으로 보내고 총건수는 $inlinecount=allpages 로 받습니다. 날짜 범위 조건은 서비스가 직접 처리합니다.

CDS 구성

이 사례의 화면은 샘플 데이터를 서비스가 들고 계산합니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 계산을 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰의 스케치입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 자금비용률 테이블

연 자금비용률은 회사 정책이고 바뀌므로 코드에 박지 않고 유효기간을 둔 테이블로 뺍니다. 률이 바뀌어도 과거 청구의 판정이 달라지지 않게 하려는 것입니다.

" ────────────────────────────────────────────────────────────────
"  ZTRM_RATE — 연 자금비용률 (투명 테이블, 유효기간 관리)
" ────────────────────────────────────────────────────────────────
define table ztrm_rate {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key valid_from : abap.dats not null;
      valid_to   : abap.dats;
      rate_pct   : abap.dec(7,2);     " 연 자금비용률(%) — 확인 필요: 조달 금리 기준
}
" 유효기간이 겹치지 않도록 입력 시 점검하는 로직이 따로 필요하다.

② 청구 기본 뷰

청구일·매출액·변동비를 한 줄로 세우는 기준 뷰입니다. 변동비를 어느 원천에서 가져올지는 회사마다 달라 확인 필요로 남겨 두었습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '청구 기본 — 청구일 · 매출액 · 변동비'
define view entity ZI_TermInvoice
  as select from vbrk as h
    inner join   vbrp as i on i.vbeln = h.vbeln
{
  key h.vbeln                 as BillDoc,
  key i.posnr                 as BillItem,
      h.bukrs                 as CompanyCode,
      h.kunag                 as Customer,
      h.fkdat                 as BillDate,
      h.zterm                 as PayTerm,        // 지급 조건 키 → T052
      i.netwr                 as Sales,
      // 변동비는 CO-PA 값 필드 또는 표준 원가 — 확인 필요
      cast( 0 as abap.curr(15,0) ) as VarCost
}

③ 입금일 뷰

청구에 대응하는 반제 일자를 찾아 입금일로 삼습니다. 아직 반제되지 않은 청구는 입금일이 비어 있고, 이 값으로 의도적 예외를 가립니다.

@EndUserText.label: '청구별 입금일 — 반제 항목에서 산출'
define view entity ZI_TermPayment
  as select from bsad as a
{
  key a.belnr                 as ClearDoc,
      a.vbeln                 as BillDoc,
      max( a.augdt )          as PayDate        // 반제일 — 입금 전기일과 다를 수 있음(확인 필요)
}
group by a.belnr, a.vbeln
// 미결(BSID)에만 남아 있는 청구는 이 뷰에 없으므로 left outer join 으로 이어야 한다.

④ 결제조건 약정 일수

지급 조건 키를 약정 일수로 바꿉니다. 지급 조건에 할인 기간이 함께 있으면 약정 일수를 어느 값으로 볼지 정해야 합니다.

@EndUserText.label: '지급 조건 → 약정 일수'
define view entity ZI_TermDays
  as select from t052 as t
{
  key t.zterm                 as PayTerm,
      t.ztag1                 as Days1,          // 첫 번째 기간 — 확인 필요: 어느 일수를 약정으로 볼지
      t.ztag2                 as Days2,
      t.ztag3                 as NetDays         // 순 지급 기한
}

⑤ 자금비용 계산 뷰

약정 기간분과 지연 기간분을 나눠 계산하는 핵심 뷰입니다. 화면이 들고 하던 계산을 DB 로 내리는 자리이며, 연 자금비용률은 ① 테이블에서 가져옵니다.

@EndUserText.label: '청구별 자금비용 — 약정 기간 · 지연 기간'
define view entity ZI_TermFinCost
  as select from ZI_TermInvoice   as v
    left outer join ZI_TermPayment as p on p.BillDoc = v.BillDoc
    inner join      ZI_TermDays    as d on d.PayTerm = v.PayTerm
    inner join      ztrm_rate      as r on r.bukrs = v.CompanyCode
{
  key v.BillDoc, key v.BillItem,
      v.Sales, v.VarCost,
      v.Sales - v.VarCost                               as Cm,
      dats_days_between( v.BillDate, p.PayDate )        as ActDays,
      d.NetDays                                         as TermDays,
      // 약정 기간 자금비용 = Sales * Rate/100 * MIN(ActDays, TermDays) / 365
      // 지연 기간 자금비용 = Sales * Rate/100 * MAX(ActDays - TermDays, 0) / 365
      r.rate_pct                                        as FundRate
      // p.PayDate 가 비어 있으면 입금 미완료 — 판정에서 제외(ExcFlag)
}

⑥ 소비 뷰 — 점검 결과와 OData 노출

판정 기준을 한 번만 정의하는 자리입니다. 기준값은 샘플 값이며 운영에서는 회사 기준으로 바꿉니다. 이 뷰를 OData 서비스로 노출합니다.

@EndUserText.label: '결제조건 자금비용 반영 수익성 점검'
@OData.publish: true
define view entity ZC_TermProfitCheck
  as select from ZI_TermFinCost
{
  key BillDoc, key BillItem,
      Sales, Cm, ActDays, TermDays,
      // TotalFin = TermFin + DelayFin,  NetCm = Cm - TotalFin
      // NetRate  = NetCm / Sales * 100
      case when ActDays is null          then 'UNPAID'    // 의도적 예외
           when NetRate  < 9.00          then 'LOWNET'    // 기준 9.00% — 샘플 값
           when FinShare >= 13.00        then 'HIGHFIN'   // 기준 13.00% — 샘플 값
           when DelayDays >= 30          then 'LATE'      // 기준 30일 — 샘플 값
           else 'OK' end                 as CheckCode
}

⑦ 권한 제어(DCL)

집계 뷰를 읽는 자리에 권한을 걸어야 합계 뺄셈으로 다른 사업 영역의 숫자가 새지 않습니다. 권한 객체와 필드 매핑은 환경에 맞게 확인해야 합니다.

@EndUserText.label: '결제조건 점검 — 회사코드 권한'
@MappingRole: true
define role ZC_TERMPROFITCHECK {
  grant select on ZC_TermProfitCheck
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
  // 고객·판매 영역 권한이 필요하면 조건을 추가 — 확인 필요
}

자주 묻는 질문

도입 상담과 데모에서 받는 질문을 세 묶음으로 나눠 적었습니다.

기준과 산식

화면과 데이터

표준 기능과 운영