가격 워터폴 점검 — 정가에서 포켓 매출까지, 가격이 새는 단계와 고객군을 찾는 수익성 분석

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

수익성 회의에서 가장 자주 나오는 질문은 "정가는 그대로인데 왜 손에 남는 돈이 줄었나"입니다. 청구서에 찍힌 할인만 보면 괜찮아 보이는데, 분기 말에 정산되는 리베이트와 결제 시점의 현금할인, 사후에 발행되는 크레딧노트까지 빼고 나면 실제로 손에 남는 매출, 곧 포켓 매출은 정가의 85%도 안 되는 경우가 있습니다. 이 가격이 새는 길은 단계마다 담당 부서와 근거 문서가 달라, 한 화면에서 이어 보기가 어렵습니다.

지금은 보통 판매 오더와 청구 문서 화면(VA03 · VF03)을 열어 조건을 확인하고, 수익성 보고서(KE30)에서 고객·제품별 공헌이익을 보고, 정산 내역은 별도 엑셀로 이어 붙입니다. 거래 한 건을 따라가는 데는 문제가 없지만, "어느 고객군이 정책 허용 범위를 넘게 새고 있는가"를 월마다 모아 보려면 엑셀에서 단계별 금액을 다시 합쳐야 하고, 그때마다 합계가 맞는지 확인하는 일이 따라옵니다.

이 화면은 그 자리를 메웁니다. 정가에서 시작해 거래 할인, 리베이트, 현금할인, 크레딧노트를 차례로 빼며 포켓 매출을 다시 구하고, 거래·고객군·월·단계 단위로 누수율을 계산해 정책 한도와 견줍니다. 기준을 넘은 곳에는 "점검 필요"를 표시해 어디부터 열어 볼지 알려 주며, 원인을 단정하지는 않습니다. 이 화면은 조회·점검 도구이고, 최종 판단은 회사가 합니다.

할인만 보면 새는 곳을 놓친다

거래 할인율이 승인 한도 안이어도, 리베이트와 크레딧노트가 겹치면 누수율은 정책을 넘습니다. 이 화면은 거래 할인율과 누수율을 따로 판정합니다(승인 할인율을 넘으면 P2, 정책 허용 누수율에 3%p 여유를 더한 값을 넘으면 P1). 한 거래가 두 코드에 모두 걸리기도 하고 한쪽에만 걸리기도 하므로, 어느 단계의 차감이 큰지를 상세 창의 워터폴로 바로 확인합니다.

평균은 고객군마다 다른 이야기를 감춘다

검증용 샘플 데이터에서 전체 누수율은 15.41% 입니다. 이 숫자만 보면 무난해 보이지만 고객군별로 나누면 대형유통 20.88% 부터 가장 낮은 곳 10.84% 까지 벌어집니다. 정책 허용 누수율이 고객군마다 다르므로(예: 대형유통 19%, 온라인몰 10%) 같은 15% 라도 어떤 고객군에서는 정상이고 어떤 고객군에서는 점검 대상입니다. 그래서 점검 표의 단위를 고객군·월로 두었습니다.

매출이 늘어도 마진율은 따로 움직인다

월별 추이에서 포켓 마진율은 17.45%(1월)에서 20.32%(5월), 10.71%(6월)로 움직입니다. 정가 매출이 큰 달이 마진율이 좋은 달은 아니므로, 누수율과 포켓 마진율을 같은 월 축에 놓고 봅니다. 점검 필요 거래가 몰린 달을 먼저 열어 보면 확인할 후보가 빨리 좁혀집니다.

숫자가 맞는지는 화면이 먼저 확인한다

단계별 금액을 합치는 일은 실수가 가장 많이 생기는 곳입니다. 이 화면은 거래·고객군·월·단계 사이의 합계가 서로 맞는지를 정합성 식 9가지로 전수 검사하고, 그 결과를 대사 탭에서 바로 보여 줍니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도는 필수(4자리)이고 전기 월 시작·종료, 고객군, 제품군, 점검 결과는 선택입니다.
2. 조회 버튼을 누르거나 회계연도 칸에서 Enter 를 누릅니다. 조회 버튼은 조회조건 영역 안, 입력 칸들의 가장 오른쪽에 있습니다.
3. 요약 카드를 확인합니다. 정가 매출, 포켓 매출, 누수액, 누수율, 포켓 마진율, 점검 필요 건수가 카드로 나옵니다.
4. 탭을 차례로 봅니다. 고객군별 점검, 거래 명세, 가격 단계별 워터폴, 월별 추이, 대사 결과 순서입니다.
5. 행을 눌러 상세를 엽니다. 정가에서 포켓 마진까지의 워터폴과 판정 내용, 같은 월·고객군 거래가 한 창에 열립니다.
6. CSV 로 내려받습니다. 현재 탭의 조회 결과가 UTF-8 CSV 로 내려옵니다.

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

검증용 샘플 데이터(거래 108건, 고객군·월 24행, 가격 단계·월 36행, 월 6행)를 대상으로 정합성 식 9가지를 전수로 검사했습니다. 검사 690건, 차이는 0건입니다. 누수율 식은 소수 둘째 자리 반올림을 감안해 허용 오차 0.005 안에서 맞는지 봅니다.

의도적으로 넣은 점검 필요 사례는 거래 44건(P1 29 · P2 30 · P3 6, 한 거래가 여러 코드에 걸릴 수 있음), 고객군·월 9행, 단계·월 5행, 월 3행입니다. 이 사례는 판정 규칙이 작동하는지 보기 위한 것으로 대사 차이와는 별개입니다. 숫자는 모두 가상의 값이며 실제 회사 값이 아닙니다.

무엇으로 만들었나

앱 정보

실행 화면

실제 브라우저에서 찍은 화면 7종입니다. 숫자는 검증용 샘플 데이터이며 실제 회사 값이 아닙니다.

처음 열었을 때 — 어디부터 볼지 좁히기

조회조건을 정하고 조회하면 요약과 고객군별 점검 표가 나옵니다.

맨 위 조회조건에서 회계연도(필수)와 월 범위, 고객군, 제품군, 점검 결과를 고르고 오른쪽 끝의 조회 버튼을 누릅니다. 요약 카드는 정가 매출 1,811.2백만 원, 포켓 매출 1,532.1백만 원, 누수율 15.41% 처럼 금액 가중으로 계산한 값입니다. 아래 표에서 "점검 필요" 배지가 붙은 행부터 보면 됩니다. 기본값은 회계연도 2026, 나머지는 전체입니다.

점검 결과를 "점검 필요"로 고르면 기준을 넘은 행만 남아 어느 고객군·월부터 열어 볼지 바로 좁혀집니다. 전체로 되돌리면 그 조건은 서비스에 보내지 않습니다. 건수는 각 탭 이름 옆 숫자로 확인합니다.

거래 한 건에서 — 정가에서 포켓 마진까지

숫자를 의심할 때는 거래 단위로 내려가 단계마다 얼마가 빠졌는지 봅니다.

거래 한 건이 한 줄입니다. 거래 할인율이 승인 할인율을 넘거나 누수율이 정책 허용 범위를 넘으면 점검 필요로 표시하고, 판정 내용은 같은 줄의 설명에 적힙니다. 열 머리를 눌러 정렬하고, 고객군과 제품군 조건으로 범위를 줄입니다.

거래 행을 누르면 정가에서 거래 할인, 리베이트, 현금할인, 크레딧노트를 차례로 뺀 워터폴이 열립니다. 어느 단계의 차감이 큰지가 한눈에 보입니다. 아래에는 같은 월, 같은 고객군의 거래가 함께 나와 비슷한 거래와 견줄 수 있습니다.

단계와 월로 — 새는 길과 시기 찾기

같은 데이터를 단계와 월 축으로 다시 모아 어디서, 언제 새는지 봅니다.

막대는 정가를 100%로 두었을 때 각 단계 금액의 비율입니다. 단계 한도는 거래 할인 9.0%, 리베이트 4.5%, 현금할인 1.2%, 크레딧노트 1.2%이며 이를 넘는 달에는 점검 필요가 붙습니다. 전체 기간 평균 비율은 거래 할인 9.44%, 리베이트 4.02%, 현금할인 1.10%, 크레딧노트 0.85%입니다.

월마다 누수율과 포켓 마진율, 점검 필요 거래 수가 한 줄로 나옵니다. 점검 필요 거래가 8건 이상이면 그 달을 점검 필요로 표시합니다. 이 샘플에서는 6월의 누수율 17.39%, 포켓 마진율 10.71% 가 가장 눈에 띕니다.

숫자 맞춰 보기 — 대사 결과

점검 결과를 믿어도 되는지, 계산 자체가 맞는지 확인하는 자리입니다.

정합성 식 아홉 가지마다 검사 건수와 차이 건수, 최대 차이가 나옵니다. 숫자를 믿고 판단하기 전에 이 탭부터 확인하면 계산이 서로 맞는지 알 수 있고, 이 샘플에서는 차이가 모두 0건입니다.

화면 뒤에서 일어나는 일 — 판정 규칙

판정 조건에 걸리면 결과 상태를 "점검 필요"로 표시합니다. 원인을 단정하지 않고 확인할 후보를 알려 주는 표시입니다.

산출 순서

1. 청구액 = 정가 매출 − 거래 할인, 거래 할인율 = 거래 할인 ÷ 정가 매출 × 100
2. 포켓 매출 = 청구액 − 리베이트 − 현금할인 − 크레딧노트
3. 포켓 마진 = 포켓 매출 − 표준원가, 포켓 마진율 = 포켓 마진 ÷ 포켓 매출 × 100
4. 누수액 = 정가 매출 − 포켓 매출, 누수율 = 누수액 ÷ 정가 매출 × 100
5. 정책과 견줍니다 — 누수율은 정책 허용 누수율에 3%p 를 더한 값과, 거래 할인율은 승인 할인율과, 포켓 마진율은 목표 마진율과 견줍니다.

요약 카드의 누수율과 포켓 마진율은 금액 가중(합계 ÷ 합계)입니다. 거래별 비율을 평균내지 않으므로 금액이 큰 거래가 비율에 더 크게 반영됩니다.

조회조건

결과 컬럼

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 두고, 단계별 누수를 한 화면에서 이어 보는 자리만 더합니다.

표준으로 되는 것과 이 화면이 더하는 것

T-code 별 연계 지점

운영에 옮길 때 기존 보고서를 없앨 필요는 없습니다. 표준 보고서는 그대로 두고, 이 화면은 월마다 누수가 큰 곳을 먼저 가려내는 용도로 병행하면 됩니다.

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

S/4HANA 의 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 같은 원천 위에서 집계를 보는 도구입니다. 이 화면은 그 가운데 "정책 기준과 견주는 점검"을 한 화면에 모은 것으로, 아래 CDS 구성에서 보듯 큐브와 분석 쿼리를 SAP 표준 방식으로 만들고 화면은 서비스로 읽습니다. 표준 분석 앱을 쓰는 회사라면 같은 큐브를 두 화면이 함께 쓸 수 있습니다.

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

분석 지표 정의

이 화면은 특정 기준서 요구사항을 점검하는 것이 아니라 수익성 분석 영역의 내부 관리 점검 도구이므로, 요구사항 매핑표 대신 분석 지표의 정의를 적습니다.

CDS 구성

아래는 실제 구현의 방향을 보여 주는 스케치입니다. 조건 요소와 정산 원천처럼 회사마다 달라지는 부분은 "확인 필요"로 남겼고, 표준 테이블과 필드는 S/4HANA 에 있는 것만 썼습니다.

뷰 레이어 구성

① 정책 기준 테이블 — 고객군별 허용 누수율 · 승인 할인율 · 목표 마진율

가격 정책의 숫자는 코드에 박지 않고 테이블에 둡니다. 정책이 바뀔 때 개발이 아니라 데이터 관리로 처리하려는 것이며, 유효 시작일을 키에 넣어 이력을 남깁니다.

@EndUserText.label : '가격 누수 정책 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zpwf_policy {
  key client     : abap.clnt not null;
  key kdgrp      : kdgrp not null;     " 고객 그룹
  key valid_from : datum not null;     " 유효 시작일
  leak_cap       : abap.dec(5,2);      " 허용 누수율(%)
  appr_disc      : abap.dec(5,2);      " 승인 할인율(%)
  target_margin  : abap.dec(5,2);      " 목표 포켓 마진율(%)
}

② 차원 뷰 — 고객군

고객 마스터의 고객 그룹을 화면의 고객군 차원으로 노출합니다. 이름은 텍스트 연관으로 붙여 화면이 코드와 이름을 함께 받게 합니다.

" ─── ZI_PwfCustGroup ─────────────────────────────
" 역할  : 고객 그룹(KDGRP)을 고객군 차원으로 노출
" 이유  : 정책 기준이 고객 그룹 단위라 집계 단위를 같게 맞춘다
@AbapCatalog.viewEnhancementCategory : [#NONE]
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'CustGroup'
@EndUserText.label : '고객군'
define view entity ZI_PwfCustGroup
  as select from t151
  association [0..*] to t151t as _Text on _Text.kdgrp = $projection.CustGroup
{
  @ObjectModel.text.association : '_Text'
  key t151.kdgrp as CustGroup,
  _Text
}

③ 큐브 뷰 — 거래 단위 가격 워터폴

청구 품목에서 정가와 청구액을 읽고, 조건 요소에서 차감 금액을 붙여 포켓 매출까지 한 행에서 계산합니다. 이 뷰가 화면의 모든 숫자의 출발점이므로 계산식은 여기 한 곳에만 둡니다. 조건 유형별 금액과 정산 원천은 회사마다 달라 확인 필요로 남겼습니다.

" ─── ZI_PwfDealCube ──────────────────────────────
" 역할  : 청구 품목 1건 = 가격 워터폴 1행
" 이유  : 정가 → 청구액 → 포켓 매출 계산을 한 곳에 둬 집계 단위가 달라도 값이 같다
@Analytics.dataCategory : #CUBE
@EndUserText.label : '가격 워터폴 큐브'
define view entity ZI_PwfDealCube
  as select from vbrp as i
    inner join   vbrk as h on h.vbeln = i.vbeln
  association [0..1] to ZI_PwfCustGroup as _CustGroup on _CustGroup.CustGroup = h.kdgrp
{
  key i.vbeln                       as BillingDocument,
  key i.posnr                       as BillingItem,
      h.kdgrp                       as CustGroup,
      h.waerk                       as Currency,
      i.fkimg                       as Quantity,        " 단위 연결은 @Semantics.quantity 로 보강
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      cast( 0 as abap.curr(15,2) )  as ListAmount,      " 가격 조건 기준 정가 (확인 필요)
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      cast( 0 as abap.curr(15,2) )  as DiscountAmount,  " 거래 할인 (조건 요소 합산, 확인 필요)
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      cast( 0 as abap.curr(15,2) )  as RebateAmount,    " 리베이트 정산 배분 (확인 필요)
      _CustGroup
}

④ 계산 뷰 — 포켓 매출과 누수율

큐브의 금액을 받아 청구액, 포켓 매출, 누수액을 계산합니다. 누수율은 합계를 구한 뒤 나누도록 해서 금액 가중이 되게 합니다.

" ─── ZI_PwfPocket ────────────────────────────────
" 역할  : 청구액 · 포켓 매출 · 누수율 계산
" 이유  : 비율은 합계 ÷ 합계로 구해야 고객군·월 어느 단위에서도 가중이 같다
@EndUserText.label : '포켓 매출 계산'
define view entity ZI_PwfPocket
  as select from ZI_PwfDealCube
{
  key BillingDocument,
  key BillingItem,
      CustGroup,
      Currency,
      ListAmount,
      ListAmount - DiscountAmount                                    as InvoiceAmount,
      ListAmount - DiscountAmount - RebateAmount                     as PocketAmount,   " 현금할인·크레딧노트 차감은 확인 후 추가
      DiscountAmount + RebateAmount                                  as LeakAmount,
      case when ListAmount = 0 then 0
           else cast( ( DiscountAmount + RebateAmount ) * 100 as abap.dec(15,4) )
                / cast( ListAmount as abap.dec(15,4) ) end           as LeakRate
}

⑤ 분석 쿼리 — 고객군·월 점검 조회

화면이 읽는 조회 단위입니다. 필터로 노출할 항목과 기본 정렬을 선언하고, 집계 기준은 큐브에 맡깁니다.

" ─── ZC_PwfSegQuery ──────────────────────────────
" 역할  : 고객군 · 월 단위 점검 표의 조회 쿼리
" 이유  : 필터 항목과 정렬을 쿼리에 선언해 화면은 조건만 넘긴다
@Analytics.query : true
@Analytics.dataCategory : #CUBE
@EndUserText.label : '고객군·월 가격 누수 점검'
define view entity ZC_PwfSegQuery
  as select from ZI_PwfPocket
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, multipleSelections : true }
  CustGroup,
  @AnalyticsDetails.query.axis : #COLUMNS
  sum( ListAmount )   as ListAmount,
  sum( PocketAmount ) as PocketAmount,
  sum( LeakAmount )   as LeakAmount
}
group by CustGroup

⑥ 권한 — 접근 제어(DCL)

집계 단계에 권한을 걸어야 합니다. 상세 조회에만 걸면 전체 합계와 자기 몫의 차이로 다른 영업조직의 숫자를 짐작할 수 있기 때문입니다.

" ─── ZI_PwfDealCube 권한 ────────────────────────
" 역할  : 영업조직 단위 접근 제한
" 이유  : 집계 쿼리 쪽에서 막아야 합계로 새지 않는다
@EndUserText.label : '가격 워터폴 접근 제어'
@MappingRole : true
define role ZI_PwfDealCube {
  grant select on ZI_PwfDealCube
    where ( SalesOrganization ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

쿼리를 OData V2 서비스로 노출합니다. 서비스 이름은 소문자로 통일하고, 활성화한 서비스 주소가 앱 설정의 서비스 주소가 됩니다.

" ─── 서비스 정의 ────────────────────────────────
@EndUserText.label : '가격 워터폴 점검 서비스'
define service ZUI_PwfCheck {
  expose ZC_PwfSegQuery as SegSet;
  expose ZI_PwfPocket   as DealSet;
}
" 바인딩 : OData V2 - UI. 활성화 후 서비스 주소를 앱 설정에 반영한다
" (게이트웨이 관리 화면 /IWFND/MAINT_SERVICE 에서 활성화 상태를 확인)

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

청구 품목이 수천만 건이면 거래 단위 조회를 그대로 열면 안 됩니다. 고객군·월 집계는 큐브에서 서비스가 계산해 내려보내고, 거래 단위는 조회 기간과 고객군을 필수 조건으로 걸어 건수를 제한해야 합니다. 조건 요소는 행 수가 청구 품목의 몇 배라 인덱스와 집계 위치를 먼저 정하고, 응답 시간 기준(예: 고객군·월 집계는 수 초 이내)을 합의해 두는 편이 안전합니다. 이 화면의 샘플 데이터는 108건이라 이런 문제가 드러나지 않으므로, 운영 규모의 성능은 별도로 확인해야 합니다.

자주 묻는 질문

도입 검토 중에 자주 나오는 질문을 숫자와 산식, 화면과 조작, 판정과 해석, 도입과 운영 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

판정과 해석

도입과 운영