계약 수익성 점검 — 수익성 분석, 계약·월별 공헌이익과 계약이익을 유형별 한도에 견주고 적자로 돌아서는 계약까지 한 화면에서

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

영업과 재무가 월 마감 뒤에 가장 자주 마주 앉는 질문은 이렇습니다. 이 계약, 팔수록 남는 계약입니까. 매출이 크고 매출총이익이 남아 보여도 운임, 포장, 보증 충당 같은 변동비가 붙고 거기에 설비 상각과 전담 인력 같은 계약 전용 고정비까지 반영하면 적자로 돌아서는 계약이 있습니다. 반대로 매출은 작아도 공헌이익률이 높아 전체 이익을 받쳐 주는 계약도 있습니다. 월 합계 숫자만 보면 이 차이가 서로 상쇄되어 보이지 않습니다.

이 앱은 그 작업을 한 화면에 모읍니다. 계약 명세를 매출 · 변동비 · 계약 고정비 세 구분으로 나누어 계약·월별로 합산하고, 매출에서 변동비를 뺀 공헌이익, 거기서 계약 고정비를 뺀 계약이익, 두 값을 매출로 나눈 공헌이익률과 계약이익률을 계산합니다. 그리고 공헌이익이 음수인지, 공헌이익은 흑자인데 계약이익이 적자로 돌아섰는지, 공헌이익률이 계약 유형별 한도에 못 미치는지 세 가지를 차례로 봅니다. 하나라도 걸리면 ‘점검 필요’로 표시하고, 운임·포장이나 보증 충당처럼 원래 구분과 다르게 전기된 명세는 따로 ‘분류 확인’으로 가려 줍니다. 대상 영역은 관리회계의 수익성 분석입니다. 표준 실행은 SAP 표준 T-code 가 그대로 담당하고, 이 화면은 계약 단위로 한도에 견주는 점검 관점을 더해 확인할 계약·월을 좁힙니다.

월 합계는 안정적인데 계약 안에서는 적자가 숨어 있다

샘플의 여섯 달 월 합계 공헌이익률은 38.53%에서 41.66% 사이로 크게 흔들리지 않고, 월 합계 계약이익률도 22.69%~26.36%입니다. 그러나 같은 달의 계약을 하나씩 열면 모양이 다릅니다. 프로젝트 수주 B는 3월부터 6월까지 공헌이익률이 39.00%~44.80%로 높은데도 계약 고정비가 커서 네 달 내내 계약이익이 -15.3백만원에서 -21.5백만원 사이의 적자입니다. 합계로 보면 다른 계약의 이익이 이 적자를 덮어 버립니다.

공헌이익이 남아도 계약이익은 다를 수 있다

가격 협상에서는 공헌이익이 중요한 기준이고, 계약 유지 여부를 따질 때는 계약 전용 고정비를 반영한 계약이익이 중요합니다. 두 값을 같은 화면에서 구분해 보면 “변동비까지는 남지만 고정비를 못 덮는 계약”과 “변동비부터 못 덮는 계약”이 갈립니다. 샘플에서 적자 전환은 5건이고, 공헌이익 자체가 음수인 계약·월은 유지보수 계약 D의 5월 한 건(공헌이익률 -12.00%)뿐입니다.

유형마다 기대 마진이 다르므로 한도도 다르다

유지보수·서비스는 변동비가 작아 공헌이익률이 높고, 연간 공급계약은 물량으로 버는 대신 마진이 낮으며, 프로젝트 수주는 그 사이에서 계약 고정비가 큽니다. 한 가지 한도로 모든 계약을 재면 유지보수는 거의 다 통과하고 공급계약은 거의 다 걸립니다. 그래서 한도를 유형별로 두었습니다(샘플: 연간 공급계약 25.00% · 프로젝트 수주 20.00% · 유지보수·서비스 40.00%). 연간 공급 계약 E의 3월 공헌이익률은 14.00%로 한도 25.00%에 못 미쳐 점검 필요가 됩니다.

구분이 어긋난 명세는 이익을 조용히 바꾼다

운임·포장은 변동비로 봐야 하는데 계약 고정비로 들어가면 공헌이익이 과대로 보이고, 보증·하자 충당은 계약 고정비로 봐야 하는데 변동비로 들어가면 반대가 됩니다. 두 경우 모두 합계 계약이익은 그대로여서 합계 대사로는 잡히지 않습니다. 샘플에는 운임·포장이 고정비로 들어간 6건과 보증·하자 충당이 변동비로 들어간 6건, 모두 12건이 있고, 이 화면은 두 구분을 나란히 놓아 이런 명세를 따로 가려 보여 줍니다.

사용 방법

1. 조회조건을 넣습니다. 회계연도(필수, 4자리)를 확인하고, 필요하면 전기 월 시작·종료, 계약 유형, 계약, 전기일, 점검 결과를 고릅니다. ‘전체’를 고르면 그 조건은 걸리지 않습니다.
2. 조회합니다. 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 초기화 버튼은 조건을 처음 값으로 되돌립니다.
3. 요약을 읽습니다. 위쪽 숫자 칸에서 매출, 공헌이익률, 계약이익률, 점검 필요 계약·월, 분류 확인 필요 명세를 먼저 봅니다.
4. 탭을 옮깁니다. 계약 판정에서 유형 구성, 명세, 월별 추이, 대사 결과 순서로 넘어갑니다. 탭 이름 위 숫자는 조건에 맞는 건수입니다.
5. 행을 눌러 상세를 봅니다. 표의 행을 누르면 상세 창이 열려 지표 전체와 같은 계약·월(또는 유형·월)의 명세를 보여 줍니다.
6. 내려받습니다. CSV 내려받기 버튼은 지금 보고 있는 탭의 조회 결과를 UTF-8 CSV 로 저장합니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 대사식을 먼저 세우고 샘플 데이터 전수에 돌린 결과입니다.

요약의 매출 22,204.7백만원, 공헌이익 8,956.2백만원(공헌이익률 40.33%), 계약이익 5,382.6백만원(계약이익률 24.24%), 점검 필요 계약·월 10건(84행 중 11.90%), 분류 확인 필요 명세 12건은 별도 스크립트로 처음부터 다시 계산한 값과 모두 같습니다. 분류 불일치 12건은 합계에는 영향이 없어 대사 차이가 아닌 의도적 예외로 따로 셉니다.

무엇으로 만들었나

실행 화면

검증용 샘플 데이터로 실제 브라우저에서 찍은 화면 7종입니다. 화면을 누르면 크게 볼 수 있고, 화면 순서는 실제로 쓰는 순서를 따랐습니다.

처음 열었을 때

앱을 열면 올해 값으로 한 번 자동 조회됩니다. 조회조건, 요약, 표가 위에서 아래로 놓입니다.

앱을 열면 올해 값으로 자동 조회되어 계약 14건 × 6개월, 84행이 한 표에 나옵니다. 위쪽 요약에서 공헌이익률 40.33%와 계약이익률 24.24%를 먼저 읽고, 점검 필요 10건이 어디에 몰려 있는지 표에서 찾아갑니다.

점검 결과를 점검 필요로 고르고 조건 영역 오른쪽 끝의 조회 버튼을 누르면 10행만 남습니다. 입력 칸에서 Enter 키를 눌러도 같습니다. 요약 숫자도 같은 조건으로 함께 바뀝니다.

한 행을 파고든다

월 마감 회의에서는 걸린 계약을 고르고 그 계약의 명세까지 내려갑니다.

표의 행을 누르면 상세 창이 열립니다. 위에는 매출, 변동비, 공헌이익, 계약 고정비, 계약이익과 두 비율, 한도가 나오고 아래에는 그 계약·월을 만든 명세가 나와 비율을 만든 금액까지 따라갈 수 있습니다.

같은 데이터를 다른 묶음으로 본다

유형 구성 · 명세 · 월별 추이는 같은 명세를 유형, 항목, 월로 다시 묶어 보여 줍니다.

월 합계가 비슷해도 유형별로 보면 모양이 다릅니다. 여섯 달 합계로 공헌이익률은 유지보수·서비스 60.70%, 연간 공급계약 39.50%, 프로젝트 수주 37.63%이고, 계약이익률은 프로젝트 수주가 15.09%로 가장 낮습니다.

780건의 명세가 손익 항목, 원천, 전기일, 금액과 함께 나옵니다. 운임·포장이나 보증·하자 충당처럼 활동의 기준 구분과 다르게 전기된 명세 12건은 점검 필요(분류 확인)로 표시됩니다.

월 합계 공헌이익률은 38.53%에서 41.66% 사이에서 움직입니다. 점검 필요 계약은 1~2월 0건, 3월 2건, 4월 2건, 5월 4건, 6월 2건으로 3월부터 늘어, 5월에는 월 계약의 28.57%가 걸립니다.

다섯 가지 대사식은 검사 건수와 차이 건수를 보여 주고, 전기 구분이 기준과 다른 명세 12건은 의도적 예외로 따로 셉니다. 대사 차이는 0건입니다.

화면 뒤에서 일어나는 일

계약·월 한 행마다 아래 조건을 위에서 아래로 확인하고, 먼저 걸린 조건 하나를 점검 코드로 표시합니다.

한도(25.00% · 20.00% · 40.00%)는 이 화면의 가상 기준값이며 회사 기준으로 바꿔 씁니다. 점검 필요는 원인을 단정하는 표시가 아니라 확인 대상을 가리는 표시이고, 최종 판단은 회사가 합니다.

산출과 대사의 순서

1. 명세를 전기 구분별로 모읍니다 — 매출(할인·리베이트는 음수 금액), 변동비, 계약 고정비.
2. 매출 − 변동비로 계약·월의 공헌이익을, 거기서 계약 고정비를 빼 계약이익을 구합니다.
3. 공헌이익 ÷ 매출 × 100, 계약이익 ÷ 매출 × 100 으로 두 비율을 구하고 소수 둘째 자리에서 반올림합니다.
4. 명세 금액 합계가 계약 집계의 계약이익과 같은지, 유형 합계가 월 합계·계약 합계와 같은지 대사합니다.

조회조건

결과 컬럼

파일 구성

앱 폴더/
├─ index.html · readme.html · Component.js · manifest.json   진입점과 서비스 선언
├─ controller/ · view/ · model/ · css/ · i18n/               화면 코드
├─ odata/                                                     서비스 정의와 샘플 데이터
├─ media/                                                     소개 영상과 표지
└─ test/                                                      검증 전용 (앱 본체는 쓰지 않음)

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 그대로 두고, 계약 단위로 한도에 견주는 자리만 이어 붙입니다.

표준으로 되는 것과 이 앱이 더하는 것

T-code 별 연계 지점

분석 지표 정의

확장 포인트 — 회사마다 달라지는 곳

CDS 구성 — 운영 데이터에 붙일 때의 뷰와 테이블

샘플에서는 서비스가 정해진 모양의 데이터를 돌려주지만, 운영에서는 ACDOCA 와 판매 문서, 매핑 테이블에서 같은 모양을 만들어야 합니다. 아래는 그 구성의 스케치이며, 계정 체계와 계약 단위는 회사마다 달라 ‘확인 필요’로 표시한 곳을 도입 때 확정합니다.

뷰 레이어 구성

원천 테이블

① 매핑 테이블 — 계정 · 활동 · 유형 · 한도

계약 단위 손익을 만들려면 먼저 회사의 계정을 매출·변동비·계약 고정비로 나누는 기준과 유형별 한도를 값으로 정해야 합니다. 이 표들이 코드가 아니라 데이터로 있어야 기준이 바뀔 때 화면과 뷰를 고치지 않습니다. 활동 기준 구분 열은 “이 항목은 원래 어느 구분이어야 하는가”를 담아 분류 확인 점검의 비교 대상이 됩니다.

" ─────────────────────────────────────────────────────────
" ① 매핑 테이블
" 역할  : 계정 → 손익 구분, 활동 → 기준 구분, 유형 → 한도
" 이유  : 회사마다 다른 기준을 코드가 아니라 값으로 둔다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '계약 손익 계정 매핑'
define table zctr_accmap {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;
  key saknr    : saknr not null;     " 계정 (원가요소 포함)
  line_code    : abap.char(5);       " 손익 항목 코드 (R100, V100, F100 ...)
  line_group   : abap.char(1);       " 전기 구분 R 매출 · V 변동비 · F 계약 고정비
}

@EndUserText.label : '활동 기준 구분'
define table zctr_actmap {
  key mandt    : mandt not null;
  key line_code: abap.char(5) not null;
  std_group    : abap.char(1);       " 이 항목이 원래 속해야 하는 구분
}

@EndUserText.label : '유형별 공헌이익률 한도'
define table zctr_limit {
  key mandt    : mandt not null;
  key ctype    : abap.char(1) not null;   " S 공급 · P 프로젝트 · M 유지보수
  cm_limit     : abap.dec(7,2);           " 공헌이익률 하한(%)
}

② 차원 — 계약 유형과 손익 구분

유형과 구분의 이름을 화면 곳곳에 문자열로 흩어 두면 이름이 바뀔 때 놓치는 곳이 생깁니다. 코드와 이름을 한 뷰로 모아 화면이 이름을 이 뷰에서만 가져오게 합니다.

" ─────────────────────────────────────────────────────────
" ② ZI_CtrpGroup — 손익 구분 차원
" 역할  : 구분 코드 R · V · F 의 이름과 정렬 순서를 제공
" 이유  : 화면의 구분 이름이 한곳에서 나오게 한다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '계약 손익 구분'
@ObjectModel.resultSet.sizeCategory : #XS
define view entity ZI_CtrpGroup
  as select from dd07t
{
  key cast( substring( domvalue_l, 1, 1 ) as abap.char(1) ) as LineGroup,
      case domvalue_l
        when 'R' then '매출'
        when 'V' then '변동비'
        else '계약 고정비'
      end                                                    as LineGroupName
}
where domname = 'ZCTR_LINE_GROUP'
  and ddlanguage = $session.system_language

③ 큐브 — 명세 단위 (전기 구분과 기준 구분 대조까지)

명세 한 줄마다 전기 구분과 활동 기준 구분을 나란히 두고, 다르면 점검 필요(분류 확인)를 계산해 둡니다. 매출 − 변동비 − 고정비 합계가 구분이 바뀌어도 같다는 점이 대사에서 분류 확인을 대사 차이와 떼어 세는 근거가 됩니다.

" ─────────────────────────────────────────────────────────
" ③ ZI_CtrpItem — 명세 큐브
" 역할  : 판매 문서 연결 계약 번호와 함께 명세 금액, 전기 구분, 기준 구분을 제공
" 이유  : 구분 대조를 명세 수준에서 끝내 집계가 그 결과를 합치기만 하게 한다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '계약 손익 명세'
@Analytics.dataCategory : #CUBE
define view entity ZI_CtrpItem
  as select from acdoca as j
    inner join zctr_accmap as a on a.saknr = j.racct
    left outer join zctr_actmap as m on m.line_code = a.line_code
{
  key j.rbukrs                       as CompanyCode,
  key j.gjahr                        as FiscalYear,
  key j.belnr                        as DocNo,
  key j.docln                        as DocLine,
      j.poper                        as FiscalPeriod,
      j.budat                        as PostDate,
      j.kunnr                        as Customer,
      /* 계약 번호는 판매 문서 연결 필드 — 확인 필요 */
      a.line_code                    as LineCode,
      a.line_group                   as LineGroup,
      m.std_group                    as StdGroup,
      j.rhcur                        as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      j.hsl                          as Amount,
      case when a.line_group <> m.std_group then 'CHECK' else 'OK' end as GroupCheck
}

④ 큐브 — 계약·월 단위 집계

세 구분을 한 번의 집계로 가로로 펼칩니다. case 로 구분별 합을 만들고 group by 로 계약·월을 묶으며, 공헌이익과 계약이익은 이 뷰에서 계산하지 않고 소비 뷰에서 만듭니다. 합계의 출처를 한 곳으로 두어야 “명세 합계 = 계약 합계” 대사가 의미를 가집니다.

" ─────────────────────────────────────────────────────────
" ④ ZI_CtrpMonth — 계약·월 큐브
" 역할  : 명세를 계약·월로 묶어 매출, 변동비, 계약 고정비를 제공
" 이유  : 비율 계산의 분자와 분모를 같은 줄에 둔다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '계약 손익 계약·월 집계'
@Analytics.dataCategory : #CUBE
define view entity ZI_CtrpMonth
  as select from ZI_CtrpItem as i
{
  key i.FiscalYear,
  key i.FiscalPeriod,
  key i.ContractNo,
      i.Currency,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.LineGroup when 'R' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as Revenue,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.LineGroup when 'V' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as VarCost,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.LineGroup when 'F' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as FixedCost,
      sum( case i.GroupCheck when 'CHECK' then 1 else 0 end )                          as MisCnt,
      count( * )                                                                       as ItemCnt
}
group by i.FiscalYear, i.FiscalPeriod, i.ContractNo, i.Currency

⑤ 쿼리 — 공헌이익 · 계약이익 계산과 점검 판정

이 뷰에서 판정 규칙이 정해집니다. 공헌이익과 계약이익을 계산하고, 비율을 유형별 한도에 견주고, 먼저 걸린 조건을 점검 코드로 만듭니다. 화면은 이 결과만 읽으므로 한도나 규칙이 바뀌어도 화면 코드를 고치지 않습니다. 매출이 0인 계약·월의 비율 처리는 도입 때 정해야 합니다.

" ─────────────────────────────────────────────────────────
" ⑤ ZC_CtrpContractQuery — 소비 쿼리
" 역할  : 공헌이익, 계약이익, 두 비율 계산과 한도 비교
" 이유  : 판정 규칙을 화면이 아니라 뷰에 둔다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '계약 수익성 판정'
@Metadata.allowExtensions : true
define view entity ZC_CtrpContractQuery
  as select from ZI_CtrpMonth as p
    left outer join zctr_limit as l on l.ctype = p.CtypeCode
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key p.FiscalYear,
  @Consumption.filter.selectionType : #INTERVAL
  key p.FiscalPeriod,
  @Consumption.filter.selectionType : #SINGLE
  key p.ContractNo,
      p.Revenue, p.VarCost, p.FixedCost,
      ( p.Revenue - p.VarCost )                        as Contribution,
      ( p.Revenue - p.VarCost - p.FixedCost )          as Profit,

      " 비율은 소수 둘째 자리 반올림 — 매출 0 처리는 도입 시 확정 (확인 필요)
      division( cast( ( p.Revenue - p.VarCost ) as abap.dec(15,2) ) * 100,
                cast( p.Revenue as abap.dec(15,2) ), 2 )   as CmRate,
      division( cast( ( p.Revenue - p.VarCost - p.FixedCost ) as abap.dec(15,2) ) * 100,
                cast( p.Revenue as abap.dec(15,2) ), 2 )   as ProfitRate,
      l.cm_limit                                       as CmLimit,

      case
        when ( p.Revenue - p.VarCost ) < 0                                  then 'NEGCM'
        when ( p.Revenue - p.VarCost - p.FixedCost ) < 0                    then 'FLIP'
        when division( cast( ( p.Revenue - p.VarCost ) as abap.dec(15,2) ) * 100,
                       cast( p.Revenue as abap.dec(15,2) ), 2 ) < l.cm_limit then 'LOWCM'
        else ''
      end                                              as CheckCode,
      p.MisCnt
}

⑥ 접근 제어 — 회사코드 단위 권한

권한을 명세 뷰에만 걸면 계약·월 집계나 월별 합계로 다른 조직의 숫자가 새어 나갑니다. 집계 뷰와 소비 쿼리에도 같은 기준을 겁니다.

" ─────────────────────────────────────────────────────────
" ⑥ ZC_CtrpContractQuery 접근 제어
" 역할  : 회사코드 단위로 읽을 수 있는 범위를 제한
" 이유  : 합계 화면으로 다른 조직 숫자가 새는 일을 막는다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '계약 수익성 접근 제어'
@MappingRole : true
define role ZC_CtrpContractQuery {
  grant select on ZC_CtrpContractQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

마지막 단계는 뷰를 서비스로 게시하는 일입니다. 화면은 게시된 서비스 주소만 알면 되므로, 이 단계가 끝나면 서비스 주소를 화면에 연결하는 것으로 이어 붙이기가 끝납니다. 엔티티셋 이름은 화면이 읽는 이름과 맞춥니다.

" ─────────────────────────────────────────────────────────
" ⑦ ZUI_CtrProfit — 서비스 정의와 바인딩
" 역할  : 다섯 뷰를 OData V2 서비스로 게시
" 이유  : 화면은 서비스 주소만 안다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '계약 수익성 점검 서비스'
define service ZUI_CtrProfit {
  expose ZC_CtrpContractQuery as ContractSet;
  expose ZC_CtrpCtypeQuery    as CtypeSet;
  expose ZI_CtrpItem          as ItemSet;
  expose ZC_CtrpMonthQuery    as MonthSet;
  expose ZC_CtrpReconQuery    as ReconSet;
}

" 서비스 바인딩 : OData V2 - UI  (게시 후 활성화 확인)
" 화면의 manifest 데이터 소스 주소를 이 바인딩 주소로 바꾼다

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 항목은 코딩이 아니라 합의입니다.

위 항목이 합의되면 기술 작업은 CDS 뷰를 만들고 서비스를 게시한 뒤 화면의 서비스 주소를 바꾸는 일입니다. 이 글의 코드는 그 출발점이며, 계정 체계와 계약 단위는 ‘확인 필요’로 남겨 두었습니다.

자주 묻는 질문

도입을 검토하시는 분들이 자주 묻는 내용을 숫자와 산식, 화면과 조작, 분류와 예외, 도입과 운영으로 나누어 모았습니다.

숫자와 산식

화면과 조작

분류와 예외

도입과 운영