고객 등급별 기여 점검 — 수익성 분석, 공헌이익으로 매긴 고객 등급이 서비스 비용을 반영하면 어떻게 달라지는지 고객·월별로 따라가는 월마감 화면

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

고객을 A·B·C로 나누는 가장 흔한 방법은 공헌이익을 큰 순서로 세워 누적 비중이 70%까지는 A, 90%까지는 B, 나머지는 C로 두는 것입니다. 그런데 이 등급은 매출에서 변동원가만 뺀 값으로 매겨집니다. 현장에서 같은 고객에게 들어가는 주문 처리 비용, 운임, 반품과 클레임 보상, 할인과 리베이트는 등급에 반영되지 않은 채 영업 우선순위와 조건 협상의 근거로 쓰입니다.

표준 화면은 고객별 수익성 보고서와 청구·조건 문서를 각각 잘 보여 주지만, 비용을 모두 반영하면 등급이 어떻게 바뀌는지를 한 번에 보여 주지는 않습니다. 그래서 월마감이 끝나면 영업과 관리회계가 보고서 몇 개와 엑셀을 오가며 고객마다 비용을 다시 모아 등급을 새로 매깁니다. 이 앱은 그 일을 월 명세 한 건 단위에서 해 두고, 고객 합계와 등급 요약으로 올려 두 기준을 나란히 놓습니다.

이 화면이 다루는 고객 수익성 분석은 회계기준이 정한 항목이 아니라 관리회계 관점의 분석입니다. 그래서 관련 기준서는 없음(-)으로 적고, 대상 영역을 수익성 분석으로 표기합니다. 점검 필요는 확인할 대상을 가리는 표시이며 최종 판단은 회사가 합니다.

공헌이익만 보면 A 등급 고객이 가려진다

샘플 데이터의 타임상사는 공헌이익 기준으로 A 등급이지만 서비스 비용률이 63.78%여서 비용을 반영하면 B 등급으로 내려갑니다. 주몽테크는 공헌이익률 26.31%에 서비스 비용률이 90.79%라 A에서 C로 두 단계 내려가고, 마루상사는 B에서 C로 내려갑니다. 공헌이익 보고서만 보는 영업 회의에서는 세 곳 모두 “상위 고객”으로 남습니다.

서비스 비용은 항목마다 새는 곳이 다르다

전체 서비스 비용 3,176.3백만원 가운데 할인·리베이트가 1,844.9백만원으로 가장 크고, 반품·클레임 580.5백만원, 운임 465.8백만원, 주문 처리 285.1백만원이 뒤따릅니다. 고객마다 큰 항목이 달라서, 화면은 고객 행을 누르면 항목별 금액을 월별로 보여 주고 어느 달에 비용이 몰렸는지 찾을 수 있게 했습니다.

신규 고객은 등급을 바로 매기지 않는다

거래 개월이 3개월 미만인 신규 고객은 비용이 한꺼번에 잡히거나 매출이 아직 쌓이지 않아 등급이 흔들립니다. 화면은 이런 고객 2곳을 의도적 예외(NEWCUST)로 따로 세어 등급 이동 점검에서 제외하고, 거래 개월이 늘면 다시 보도록 안내합니다. 오류로 오인하지 않게 정합성 대사의 차이와도 섞이지 않습니다.

합계가 맞는지 묻는 일이 줄어든다

고객별 표와 등급별 표, 월별 표를 따로 만들면 합계가 서로 달라 “어느 숫자가 맞나” 하는 회의가 열립니다. 이 앱은 월 명세에서 계산한 값을 고객으로, 다시 등급과 월로 올리고 여덟 가지 대사식으로 매번 검산합니다. 차이 건수가 요약 카드에 늘 함께 보이므로, 숫자를 믿어도 되는지를 열어 보기 전에 알 수 있습니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 확인하고, 필요하면 판매 채널, 반영 후 등급, 거래 월 시작·종료, 마지막 주문일 시작·종료, 점검 결과를 고릅니다. 고르지 않은 조건은 걸리지 않습니다.
2. 조회 버튼 또는 Enter — 조건 입력칸의 가장 오른쪽 조회 버튼을 누르거나 회계연도 입력칸에서 Enter 키를 누릅니다. 화면을 열면 기본 조건으로 한 번 자동 조회됩니다.
3. 요약 확인 — 순매출, 공헌이익, 서비스 비용, 서비스 반영 후 기여, 등급 하락 고객, 점검 필요 고객, 대사 차이 건수를 위쪽 숫자로 봅니다.
4. 탭 이동 — 고객 판정 → 등급 요약 → 월 명세 → 월별 추이 → 대사 결과 순서로 넘어갑니다.
5. 행 클릭 상세 — 고객 행을 누르면 판정 근거와 월별 명세가 열리고, 등급 행을 누르면 그 등급 고객이 나옵니다.
6. CSV 내려받기 — 현재 탭의 조회 결과를 UTF-8 CSV 로 내려받습니다.

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

먼저 대사식을 세우고, 검증용 샘플 데이터 전체에 대해 돌린 결과입니다. 아래 여덟 가지가 정합성 대사이고, 의도적 예외 두 가지는 따로 셉니다.

고객 판정은 아래 순서로 적용합니다. 위에서 먼저 걸린 조건이 점검 코드가 되며, 원인은 단정하지 않고 확인 필요로만 안내합니다.

실행 화면

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

처음 열었을 때와 좁혀 보기

처음 화면은 조건, 요약, 판정표 세 단으로 되어 있습니다. 조건을 넣기 전에도 기본 조건으로 한 번 조회되어 빈 화면을 보는 일이 없습니다.

위쪽 일곱 숫자가 순매출 23,610.2백만원, 공헌이익 7,597.7백만원, 서비스 비용 3,176.3백만원, 서비스 반영 후 기여 4,421.5백만원을 먼저 말하고, 그 옆에서 등급 하락 고객과 점검 필요 고객, 대사 차이 0건이 함께 읽힙니다. 조회 버튼은 조건 입력칸 오른쪽 끝에 있습니다.

24곳 가운데 11곳이 남습니다. 비용률 한도 초과 7곳, 등급 하락 3곳, 기여 음수 1곳이며, 점검 내용 칸에 어느 조건에 걸렸는지가 문장으로 적혀 있습니다.

등급이 어떻게 달라지는가 — 등급 요약과 월 명세

점검 필요 고객을 찾았다면 다음 질문은 등급 전체의 모양이 어떻게 바뀌었느냐, 그리고 어느 달의 어느 비용이 그렇게 만들었느냐입니다.

공헌이익 기준으로는 A 8곳·B 5곳·C 11곳이던 것이 서비스 비용을 반영하면 A 6곳·B 6곳·C 12곳으로 바뀝니다. 같은 24곳인데 A 등급에서 두 곳이 빠져나가는 모습이 한 표에서 보입니다.

136건의 월 명세가 열립니다. 마지막 주문일 시작·종료를 넣으면 그 기간에 마지막으로 주문한 고객의 월만 남고, 서비스 반영 후 기여가 음수인 월은 표에서 바로 구별됩니다.

흐름과 상세 — 월별 추이와 고객 상세

월별 흐름에서 비용률이 오른 시점을 찾고, 고객 한 행을 눌러 그 고객의 구성을 확인합니다.

서비스 비용률은 1월 40.32%에서 3월 43.14%까지 올랐다가 5월 40.44%로 내려오고, 기여가 음수인 고객이 2곳 이상인 3월과 6월은 점검 필요로 표시됩니다.

고객의 공헌이익률, 서비스 비용률, 등급 이동(예: A→C)과 점검 코드, 월별 명세가 한 창에 모입니다. 닫기 버튼으로 돌아오면 조건과 탭이 그대로 남아 다음 행을 바로 볼 수 있습니다.

합계가 맞는가 — 대사 결과

순매출 − 변동원가 = 공헌이익, 월 명세 합계 = 고객 합계, 등급별 고객 수 합계 = 전체 같은 식을 화면이 매번 다시 계산해 차이 0을 보입니다. 의도적 예외 두 가지는 오류와 섞이지 않게 따로 세웁니다.

점검 필요 고객 예시 — 샘플 데이터에서

샘플 24곳 가운데 점검 필요는 11곳입니다. 일부를 옮깁니다.

카이로테크는 서비스 비용이 공헌이익보다 커서 서비스 반영 후 기여가 음수입니다. 노을산업은 반대로 C에서 B로 올라가는데, 이는 다른 고객의 기여가 줄어 순위가 올라간 결과이므로 “좋아졌다”로 읽지 않고 기준이 바뀌었다는 사실만 표시합니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙입니다.

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

T-code 별 연계 지점

운영 전환 때 “기존 리포트를 없애야 하나” 하는 질문이 따라옵니다. 답은 없애지 않는다입니다. 표준 리포트는 법정·감사 대응과 원천 확인에 그대로 쓰고, 이 화면은 월마감 전에 점검 대상을 가리는 데 씁니다. 두 결과가 같은 기간에서 같은지 맞춰 보는 것이 전환의 첫 단계입니다.

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

CDS 구성

화면이 읽는 데이터는 결국 CDS 뷰에서 나옵니다. 아래는 이 화면의 서비스를 S/4HANA 위에서 구성할 때의 뼈대입니다. 코드는 구조를 보이는 스케치이며, 원천 필드와 조건 유형은 회사 설정에 맞춰 확인이 필요한 곳을 주석에 적었습니다.

뷰 레이어 구성

① 기준 테이블 — 구간과 한도는 정책이다

누적 비중 구간과 비용률 한도는 회사마다 다르고 해마다 바뀝니다. 값을 표로 두면 화면 코드를 고치지 않고 점검 기준을 조정할 수 있고, 화면은 이 값을 한도 칸으로 받아 그대로 보여 줍니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZCTIER_PARAM  (등급 구간 · 비용률 한도 · 주문 처리 단가)
" 이유  : 정책 값을 CDS 안에 상수로 박아 두면 바뀔 때마다 이송이 필요하다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '고객 등급 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zctier_param {
  key client     : abap.clnt not null;
  key valid_from : abap.dats not null;
  valid_to       : abap.dats;
  cut_a          : abap.dec(5,2);   " 예: 70.00
  cut_b          : abap.dec(5,2);   " 예: 90.00
  svc_limit      : abap.dec(5,2);   " 예: 40.00
  unit_order     : abap.curr(9,2);  " 건당 주문 처리 단가 (출처 확인 필요)
}

② 기본 뷰 — 고객·월 단위 매출과 변동원가

청구 항목을 고객과 월로 묶어 순매출과 변동원가를 읽습니다. 반품 청구 문서는 부호가 반대라 순매출에 그대로 합산됩니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
define view entity ZI_CustTierMonth as select from I_BillingDocumentItem as _item
{
  key SoldToParty                      as CustCode,
  key left(BillingDocumentDate, 6)     as YearMonth,
      @Semantics.amount.currencyCode: 'Currency'
      sum( NetAmount )                 as SalesAmt,
      @Semantics.amount.currencyCode: 'Currency'
      sum( CostAmount )                as VarCost,
      TransactionCurrency              as Currency
}
group by SoldToParty, left(BillingDocumentDate, 6), TransactionCurrency

③ 서비스 비용 뷰 — 네 항목을 같은 단위로

주문 처리, 운임, 반품·클레임, 할인·리베이트를 같은 고객·월 단위로 만들어 붙입니다. 조건 유형은 회사의 가격 조건 구성에 따라 달라서 매핑 표로 뺍니다.

define view entity ZI_CustTierSvc as select from ZI_CustTierMonth as _m
  association [0..*] to ZI_CustTierCond as _cond
    on  _cond.CustCode = _m.CustCode
    and _cond.YearMonth = _m.YearMonth
{
  key _m.CustCode,
  key _m.YearMonth,
      _m.SalesAmt,
      _m.VarCost,
      _m.SalesAmt - _m.VarCost                  as ContribAmt,
      " 아래 네 항목의 원천 필드·조건 유형은 회사 설정 확인 필요
      _cond.OrderCost, _cond.FreightAmt,
      _cond.ReturnClaimAmt, _cond.DiscountAmt,
      _cond.OrderCost + _cond.FreightAmt
        + _cond.ReturnClaimAmt + _cond.DiscountAmt as ServiceCost
}

④ 등급 판정 쿼리 — 자기 이전 누적 비중으로

고객을 기준 금액 큰 순서로 세우고 자기 이전까지의 누적 비중으로 등급을 정합니다. 구간을 넘어서는 큰 고객이 낮은 등급으로 밀려나지 않도록 “자기 이전” 비중을 씁니다. CDS 의 누적 계산 지원 범위는 버전에 따라 달라 서비스 계층에서 계산할 수도 있습니다(확인 필요).

define view entity ZC_CustTierQuery as select from ZI_CustTierCust
{
  key CustCode,
      NetContrib,
      " 누적 비중(자기 이전) = 앞 순위 합계 ÷ 전체 합계 × 100
      CumShareBefore,
      case when CumShareBefore <  70 then 'A'
           when CumShareBefore <  90 then 'B'
           else 'C' end                           as TierNet,
      case when MonthCnt < 3        then 'NEWCUST'
           when NetContrib < 0      then 'NEGATIVE'
           when TierNet > TierBase  then 'TIERDOWN'
           when ServiceRate > 40    then 'COSTHIGH'
           else '' end                            as CheckCode
}

⑤ 접근 제어 — 고객 범위는 집계 단계에서

남의 고객 숫자가 보이지 않도록 권한 객체의 값으로 조회 범위를 제한합니다. 화면에서만 숨기는 것으로는 부족합니다.

@EndUserText.label: '고객 등급 점검 접근 제어'
@MappingRole: true
define role ZC_CUSTTIER_DCL {
  grant select on ZC_CustTierQuery
    where ( SalesOrg ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

운영 시점에 해야 할 일

위 다섯 가지는 코딩이 아니라 합의입니다. 합의가 끝나면 기술 작업은 CDS 뷰와 서비스를 만들고 화면을 올리는 일입니다.

자주 묻는 질문

숫자와 산식, 화면과 조작, 데이터와 표준 연계, 도입과 운영 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

데이터와 표준 연계

도입과 운영