지역별 수익성 점검 — 수익성 분석, 총매출에서 공헌이익과 지역이익까지 지역·월별로 따라가며 한도를 벗어난 지역을 찾는 월마감 화면

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

월마감이 끝나면 영업과 경영지원이 가장 먼저 묻는 것은 “어느 지역이 돈을 남겼고, 어느 지역이 남기지 못했나” 입니다. 총매출은 잘 나왔는데 지역이익이 적자인 지역이 있고, 공헌이익은 충분한데 고정비를 얹으면 얇아지는 지역이 있습니다. 표준 화면은 수익성 분석 결과와 청구·비용 문서를 각각 잘 보여 주지만, 지역·월 단위로 한도에 견주어 “지금 확인해야 할 곳”만 가려 주지는 않습니다.

그래서 현업은 보고서를 지역·제품군마다 여러 번 돌려 엑셀에 붙이고, 할인이 얼마나 나갔는지, 운임이 빠진 건은 없는지를 눈으로 훑으며 월마감을 보냅니다. 이 앱은 그 훑는 일을 출고 명세 한 건 단위에서 해 두고, 지역·월·요인 순으로 합쳐 올려 한 화면에 놓습니다. 총매출에서 할인·리베이트, 변동매출원가, 변동운임·수수료를 차례로 빼 공헌이익을 만들고, 지역 고정비를 한 번 더 빼 지역이익을 만듭니다.

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

축이 고정된 보고서는 두 번째 질문에서 멈춘다

첫 질문은 “이번 달 수도권 수익성은?” 이지만 두 번째 질문은 곧바로 “제품군별로는?”, “할인이 얼마나 나갔나?”로 이어집니다. 지역과 제품군을 고정해 만든 보고서는 이 두 번째 질문에서 다시 조건을 넣고 다시 돌려야 합니다. 이 앱은 지역·제품군·출고일·점검 결과를 한 줄 조건으로 모아 두고, 같은 조건이 지역 판정·손익 구성·출고 명세·월별 추이·대사 결과 다섯 탭에 함께 걸리게 했습니다.

공헌이익만 보면 적자 지역이 가려진다

호남권 4월은 순매출 338.1백만원에 공헌이익이 132.2백만원이고 공헌이익률은 39.10%로 하한 30.00%를 넘습니다. 그런데 지역 고정비가 149.0백만원이라 지역이익은 −16.8백만원입니다. 공헌이익률만 보는 보고서는 이 달을 정상으로 넘깁니다. 이 앱은 공헌이익과 지역이익을 한 줄에 놓고, 지역이익이 0보다 작으면 점검 필요로 표시합니다. 같은 달 할인율도 11.31%로 한도 8.00%를 넘었다는 점까지 점검 내용에 함께 적힙니다.

운임이 빠지면 이익이 좋아 보인다

운임 정산이 늦으면 변동운임·수수료가 0원인 출고 명세가 생기고, 그 명세의 공헌이익은 실제보다 좋아 보입니다. 아시아 2월에는 이런 명세가 3건 있습니다. 한도만 보는 점검은 운임이 아예 없는 건을 놓치기 쉬워서, 화면은 운임 0원 명세를 따로 세어 지역·월 행에 운임 확인 필요로 올립니다. 공헌이익이 음수인 명세 2건도 의도적 예외로 따로 집계해 정합성 대사와 섞이지 않게 했습니다.

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

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

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 확인하고, 필요하면 매출 월 시작·종료, 지역, 제품군, 요인, 출고일 시작·종료, 점검 결과를 고릅니다. 고르지 않은 조건은 걸리지 않습니다.
2. 조회 버튼 또는 Enter — 조건 입력칸의 가장 오른쪽 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 화면을 열면 기본 조건으로 한 번 자동 조회됩니다.
3. 요약 확인 — 순매출, 공헌이익, 공헌이익률, 지역이익, 점검 필요 지역, 확인 필요 명세, 대사 차이 건수를 위쪽 숫자로 봅니다.
4. 탭 이동 — 지역 판정 → 손익 구성 → 출고 명세 → 월별 추이 → 대사 결과 순서로 넘어가며, 탭 이름 위 숫자는 조건에 맞는 건수입니다.
5. 행 클릭 상세 — 표의 행을 누르면 상세 창이 열려 지표 전체와 같은 지역·월의 출고 명세를 보여 줍니다.
6. CSV 내려받기 — 현재 탭의 조회 결과를 UTF-8 CSV 로 내려받습니다.

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

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

의도적 예외 — 운임이 0원인 명세 3건(아시아 2월)과 공헌이익이 음수인 명세 2건(수도권 3월 · 충청권 5월)은 확인 필요 예시로 넣었으며 대사 차이 건수와 분리해 셉니다. 판정은 36개 지역·월 중 점검 필요 7건이며 별도 스크립트 재계산과 모두 일치했습니다. 화면의 요약 숫자(순매출 14,846.9백만원, 공헌이익 6,184.3백만원, 공헌이익률 41.65%, 지역이익 2,464.1백만원)도 스크립트 결과와 같았습니다.

무엇으로 만들었나

실행 화면

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

처음 열었을 때

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

위쪽 일곱 숫자가 순매출 14,846.9백만원, 공헌이익 6,184.3백만원(공헌이익률 41.65%), 지역이익 2,464.1백만원을 먼저 말합니다. 그 옆에서 점검 필요 지역 7건, 확인 필요 명세 5건, 대사 차이 0건이 함께 읽힙니다. 아래 36행 표는 지역·월 한 줄이 하나의 판정 단위이고, 조회 버튼은 조건 입력칸 오른쪽 끝에 있습니다.

점검 결과만 걸어도 7건이 남고, 지역·월 어디서 한도를 넘었는지가 점검 내용에 문장으로 적혀 있습니다. 요약과 표가 같은 조건에서 나오므로 어느 쪽을 봐도 숫자가 갈라지지 않습니다.

이익이 어디서 깎이는가 — 손익 구성과 출고 명세

공헌이익률이 낮다는 사실 다음에 오는 질문은 어느 칸이 이익을 깎았느냐입니다. 월별 손익 구성에서 비중을 비교하고, 출고 명세로 내려가 건별 금액을 확인합니다.

총매출에서 네 항목을 차례로 빼면 지역이익이 남습니다. 4월은 할인·리베이트 5.46%, 변동매출원가 51.67%, 변동운임·수수료 2.70%, 지역 고정비 25.14%여서, 어느 칸이 이익을 깎았는지 비중으로 곧바로 비교됩니다.

288건의 출고 명세가 열립니다. 운임이 0원이거나 공헌이익이 음수인 명세는 점검 결과에 표시되고, 출고일 시작·종료를 넣으면 그 기간의 명세만 남습니다. 확인 필요 명세 5건은 일부러 넣어 둔 예시입니다.

흐름과 상세 — 월별 추이와 행 상세

월별 흐름에서 수익성이 얇아진 시점을 찾고, 지역·월 한 행을 눌러 그 달의 구성을 확인합니다.

공헌이익률은 1월 42.68%에서 6월 39.01%로 내려오고, 점검 필요 지역은 1월 0곳에서 5·6월 2곳으로 늘어납니다. 어느 달부터 수익성이 얇아졌는지가 6개월 흐름으로 읽힙니다.

4월 호남권은 순매출 338.1백만원에 공헌이익 132.2백만원이지만 지역 고정비 149.0백만원이 더 커서 지역이익이 −16.8백만원입니다. 할인율 11.31%도 한도 8.00%를 넘어 두 조건이 함께 걸렸다는 것이 점검 내용에 적힙니다.

숫자를 믿어도 되는가 — 대사 결과

마지막 탭은 화면이 스스로 하는 검산입니다. 합계가 맞는지와 의도적 예외를 구분해 보여 줍니다.

총매출 − 할인·리베이트 = 순매출, 명세 합계 = 지역·월 집계, 지역 합계 = 월 합계 같은 식을 화면이 매번 다시 계산해 차이 0을 보입니다. 의도적 예외 두 가지는 오류와 섞이지 않게 따로 세웁니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조건을 필터 객체로 만들어 탭마다 해당 엔티티셋에 요청하고, 서비스는 명세에서 지역·월로 합친 값을 돌려줍니다. 한도 판정과 대사도 서비스 쪽 계산 결과이며, 화면은 그 값을 그대로 보여 줍니다.

판정 규칙 — 한도에 견주어 점검 필요를 가린다

지역·월 한 행마다 아래 조건을 차례로 확인하고, 하나라도 걸리면 점검 필요로 표시합니다. 걸린 조건은 점검 내용에 모두 적힙니다.

산출·대사 순서

1. 총매출 − 할인·리베이트 = 순매출, 순매출 − 변동매출원가 − 변동운임·수수료 = 공헌이익 (명세)
2. 명세 합계 = 지역·월 집계 (순매출 · 공헌이익)
3. 공헌이익 − 지역 고정비 = 지역이익 (지역·월)
4. 공헌이익 ÷ 순매출 × 100 = 공헌이익률 (소수 둘째 자리 반올림), 할인·리베이트 ÷ 총매출 × 100 = 할인율, 운임 ÷ 순매출 × 100 = 운임률
5. 지역 합계 = 월 합계, 총매출 − 손익 구성 항목 합계 = 지역이익 (전사)

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 줄을 바꿔 쌓이고 요약 숫자는 두 칸씩 접힙니다. 표는 화면 안에서 좌우로 넘겨 봅니다. 폭 390px 에서 페이지 전체가 가로로 밀리지 않는 것을 확인했습니다. 열이 많은 표라 현장에서는 데스크톱 화면이 더 읽기 편합니다.

파일 구성

index.html · readme.html · Component.js · manifest.json
controller/  BaseController.js · Main.controller.js
view/        Main.view.xml · DetailDialog.fragment.xml
model/       formatter.js · ErrorHandler.js
css/ · i18n/
odata/       metadata.xml · service.js · json/ (엔티티셋별 데이터)
media/       intro.mp4 · intro_poster.jpg

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 임의의 축으로 파고드는 탐색에 강합니다. 이 앱은 그 자리를 대신하지 않고, 월마감에서 매번 같은 한도와 같은 대사식으로 확인할 곳을 가려 주는 점검 화면의 자리에 둡니다. 같은 CDS 뷰를 분석 스택과 공유하면 두 화면의 숫자가 갈라지지 않습니다.

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

분석 지표 정의표

CDS 구성

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

뷰 레이어 구성

① 지역 매핑 테이블 — 지역 구분은 코드가 아니라 데이터로

지역 구분이 가장 먼저 흔들립니다. 영업 조직이 개편되면 판매처의 소속 지역이 바뀌는데, 그 구분을 뷰의 case 문에 박아 두면 개편 때마다 이송이 필요합니다. 유효 기간을 둔 매핑표로 빼 두면 과거 월은 옛 구분으로, 새 월은 새 구분으로 읽혀 지난 달 숫자가 흔들리지 않습니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZREGP_REGMAP  (지역 매핑 테이블 — 판매처 → 지역)
" 역할  : 판매처가 어느 지역에 속하는지를 한 곳에서 정한다.
" 이유  : 지역 구분을 CDS 안에 case 문으로 박아 두면 구분이 바뀔 때마다
"         뷰를 고쳐 이송해야 한다. 표로 빼 두면 현업이 행만 고치면 된다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '지역 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zregp_regmap {
  key client     : abap.clnt not null;
  key kunag      : kunag not null;
  key valid_from : abap.dats not null;
  valid_to       : abap.dats;
  regcode        : abap.char(3);
  regname        : abap.char(12);
}

② 지역별 한도 테이블 — 한도는 정책이다

공헌이익률 하한과 할인율·운임률 한도는 지역마다 다르고 해마다 바뀝니다. 한도를 표로 두면 화면 코드를 고치지 않고 값만 바꿔 점검 기준을 조정할 수 있고, 화면은 이 값을 한도 칸으로 받아 그대로 보여 줍니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZREGP_LIMIT  (지역별 한도 테이블)
" 역할  : 공헌이익률 하한 · 할인율 한도 · 운임률 한도를 지역마다 둔다.
" 이유  : 한도는 정책이라 자주 바뀐다. 화면에는 이 값이 한도 칸으로 내려온다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '지역별 한도'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zregp_limit {
  key client     : abap.clnt not null;
  key regcode    : abap.char(3) not null;
  cm_limit       : abap.dec(7,2);
  frt_limit      : abap.dec(7,2);
  disc_limit     : abap.dec(7,2);
}

③ 기본 뷰 — 출고 명세

청구 항목 한 줄이 출고 명세 한 건입니다. 총매출과 순매출의 정의, 취소 청구의 제외, 지역 매핑 결합이 모두 여기서 결정되므로 운영에서 가장 먼저 검증해야 하는 뷰입니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZI_RegProfitLine  (기본 뷰 — 출고 명세)
" 역할  : 청구 문서 항목 한 줄을 출고 명세 한 건으로 읽는다.
" 이유  : 이후 모든 집계의 바닥이므로 금액·수량 정의를 여기서 한 번만 정한다.
"         총매출 · 할인 · 순매출의 부호와 통화를 여기서 확정한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '지역별 수익성 — 출고 명세'
define view entity ZI_RegProfitLine
  as select from vbrk
    inner join vbrp on vbrp.vbeln = vbrk.vbeln
    left outer join zregp_regmap as rmap
      on  rmap.kunag      = vbrk.kunag
      and rmap.valid_from <= vbrk.fkdat
      and ( rmap.valid_to >= vbrk.fkdat or rmap.valid_to = '00000000' )
{
  key vbrk.vbeln                      as BillNo,
  key vbrp.posnr                      as BillItem,
      vbrk.gjahr                      as Gjahr,
      cast( substring( vbrk.fkdat, 5, 2 ) as abap.numc( 3 ) ) as Period,
      vbrk.fkdat                      as PostDate,
      rmap.regcode                    as RegCode,
      vbrp.matkl                      as ProdGroup,
      vbrk.waerk                      as Currency,
      @Semantics.quantity.unitOfMeasure: 'SalesUnit'
      vbrp.fkimg                      as Qty,
      vbrp.vrkme                      as SalesUnit,
      /* 총매출 = 청구 정가 금액 — 세금·통화 처리는 회사 설정에 맞춰 확인 필요 */
      @Semantics.amount.currencyCode: 'Currency'
      vbrp.kzwi1                      as GrossAmt,
      /* 순매출 = 청구 순가치 */
      @Semantics.amount.currencyCode: 'Currency'
      vbrp.netwr                      as NetAmt
}
where vbrk.fksto = ''   /* 취소 청구 제외 */

④ 기본 뷰 — 변동원가와 운임

원가와 운임은 원천이 달라 정산 시점이 어긋납니다. 운임이 아직 정산되지 않으면 0원으로 남는데, 이 사실을 지우지 않고 보존해야 뒤에서 “운임 0원 명세”를 점검 대상으로 가려낼 수 있습니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZI_RegProfitCost  (기본 뷰 — 변동원가 · 운임)
" 역할  : 출고 명세에 변동매출원가와 변동운임·수수료를 붙인다.
" 이유  : 원가는 저널 항목, 운임은 운임 문서에서 온다. 두 원천이 달라
"         정산이 늦은 운임은 0원으로 남는다 — 이 뷰에서 그 사실을 보존한다.
" 확인 필요 : 원가 계정 범위와 운임 배부 키는 회사 설정에 따라 달라진다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '지역별 수익성 — 변동원가·운임'
define view entity ZI_RegProfitCost
  as select from ZI_RegProfitLine as l
    left outer join vfkp as f
      on f.rebel = l.BillNo
{
  key l.BillNo,
  key l.BillItem,
      /* 변동매출원가 = 출고 시 전기된 원가 — 저널 항목에서 청구 항목 단위로 배부 */
      @Semantics.amount.currencyCode: 'Currency'
      cast( 0 as abap.curr( 15, 2 ) ) as CostAmt,
      /* 변동운임·수수료 = 운임 문서 금액 배부분. 정산 전이면 0 */
      @Semantics.amount.currencyCode: 'Currency'
      coalesce( f.netwr, cast( 0 as abap.curr( 15, 2 ) ) ) as FrtAmt,
      l.Currency
}

⑤ 큐브 — 공헌이익과 집계

금액만 합산 가능하게 두고 비율은 소비 쪽에서 합계끼리 나눕니다. 행마다 계산한 공헌이익률을 평균하면 지역 값이 틀어지므로, 큐브에는 비율을 두지 않는 것이 원칙입니다. 운임 0원 건수와 음수 공헌이익 건수도 합산 가능한 값으로 둡니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZI_RegProfitCube  (큐브 — 지역·월·제품군 수익성)
" 역할  : 명세에서 공헌이익을 계산하고 지역·월·제품군으로 집계 가능하게 한다.
" 이유  : 공헌이익률 같은 비율은 합산하면 안 되므로 금액만 합산하고
"         비율은 소비 쪽 쿼리에서 합계끼리 나눈다.
" ─────────────────────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '지역별 수익성 — 큐브'
define view entity ZI_RegProfitCube
  as select from ZI_RegProfitLine as l
    inner join ZI_RegProfitCost  as c
      on c.BillNo = l.BillNo and c.BillItem = l.BillItem
{
  key l.BillNo,
  key l.BillItem,
      l.Gjahr,
      l.Period,
      l.RegCode,
      l.ProdGroup,
      l.Currency,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.GrossAmt,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.GrossAmt - l.NetAmt                         as DiscAmt,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.NetAmt,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      c.CostAmt,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      c.FrtAmt,
      /* 공헌이익 = 순매출 − 변동매출원가 − 변동운임·수수료 */
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.NetAmt - c.CostAmt - c.FrtAmt               as CmAmt,
      /* 운임 0원 명세 수 — 정산 누락 의심 */
      @Aggregation.default: #SUM
      case when c.FrtAmt = 0 then 1 else 0 end      as NoFrtCnt,
      @Aggregation.default: #SUM
      case when l.NetAmt - c.CostAmt - c.FrtAmt < 0 then 1 else 0 end as NegCmCnt
}

⑥ 분석 쿼리 — 지역·월 판정

화면이 읽는 엔티티가 이 쿼리입니다. 한도에 견준 판정 코드를 여기서 만들면 서버 계산과 화면 표시가 같은 기준을 쓰게 되어, 화면과 표준 결과를 맞출 때 판정 때문에 어긋나는 일이 없습니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZC_RegProfitQuery  (분석 쿼리 — 지역·월 판정)
" 역할  : 큐브를 지역·월로 묶고 한도에 견줘 판정 코드를 만든다.
" 이유  : 화면이 읽는 엔티티는 이 쿼리 하나다. 판정 기준을 여기 두면
"         화면 코드에 한도가 흩어지지 않는다.
" ─────────────────────────────────────────────────────────────
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '지역별 수익성 — 지역·월 판정'
define view entity ZC_RegProfitQuery
  as select from ZI_RegProfitCube as c
    inner join zregp_limit        as lim on lim.regcode = c.RegCode
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key c.Gjahr,
  @Consumption.filter.selectionType: #INTERVAL
  key c.Period,
  @UI.selectionField: [{ position: 10 }]
  key c.RegCode,
      sum( c.GrossAmt )  as GrossAmt,
      sum( c.DiscAmt )   as DiscAmt,
      sum( c.NetAmt )    as NetAmt,
      sum( c.CmAmt )     as CmAmt,
      /* 공헌이익률은 합계끼리 나눈다 — 행 비율을 평균하지 않는다 */
      division( sum( c.CmAmt ) * 100, sum( c.NetAmt ), 2 ) as CmRate,
      max( lim.cm_limit )   as CmLimit,
      max( lim.disc_limit ) as DiscLimit,
      sum( c.NoFrtCnt )  as MisCnt,
      case
        when division( sum( c.CmAmt ) * 100, sum( c.NetAmt ), 2 ) < max( lim.cm_limit )
          then 'LOWCM'
        when division( sum( c.DiscAmt ) * 100, sum( c.GrossAmt ), 2 ) > max( lim.disc_limit )
          then 'DISC'
        when sum( c.NoFrtCnt ) > 0 then 'NOFRT'
        else ''
      end                as CheckCode
}
group by c.Gjahr, c.Period, c.RegCode

⑦ 접근 제어 — 지역 단위 권한

권한은 집계 단계에서 겁니다. 드릴 단계에서만 걸면 전사 합계에서 내 지역 합계를 빼는 식으로 남의 숫자를 추정할 수 있습니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZC_RegProfitQuery  (접근 제어 — DCL)
" 역할  : 지역 단위 권한이 있는 사용자만 해당 지역을 본다.
" 이유  : 화면에서만 숨기면 서비스를 직접 부를 때 새 나간다.
"         집계 단계에서 걸어야 전사 합계와 자기 몫의 차이로 남의 숫자가
"         드러나지 않는다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '지역별 수익성 — 지역 권한'
@MappingRole: true
define role ZC_RegProfitQuery {
  grant select on ZC_RegProfitQuery
    where ( RegCode ) = aspect pfcg_auth( ZREGPROF, ZREGCODE, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리를 OData V2 서비스로 노출합니다. 서비스 활성화와 바인딩 게시 뒤에는 화면의 서비스 주소 한 줄만 바꾸면 운영 서비스로 전환됩니다.

" ─────────────────────────────────────────────────────────────
" 객체  : ZUI_RegProfit  (서비스 정의 · 바인딩)
" 역할  : 쿼리를 OData V2 서비스로 노출한다.
" 이유  : 화면은 서비스 주소만 알면 되므로, 개발 서비스에서 운영 서비스로
"         옮길 때 매니페스트의 주소 한 줄만 바꾼다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '지역별 수익성 점검 서비스'
define service ZUI_RegProfit {
  expose ZC_RegProfitQuery as RegProfit;
}

" 서비스 바인딩 : 유형 OData V2 - UI, 이름 ZUI_REGPROFIT_O2
" 활성화 후 서비스 주소를 화면 매니페스트의 서비스 선언에 넣는다.

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

청구 항목이 수천만 건이 되면 집계 위치가 성능을 가릅니다. 명세 단위로 화면에 올리지 않고 지역·월 집계를 서버에서 먼저 만들고, 출고 명세 탭은 기간이나 지역을 사실상 필수로 받아 건수를 제한합니다. 회계연도와 기간은 쿼리의 필수 파라미터로 두고, 큐브의 기준 열에는 인덱스나 집계 캐시를 검토합니다. 응답 시간 기준은 도입 때 함께 정하며, 대용량에서는 월 마감 시점 집계를 미리 만들어 두는 방식이 안전합니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

데이터와 표준 연계

도입과 운영