SAP 영업 가격·리베이트 통합 관리 — 가격 요청에서 정산까지 한 앱에서 처리하고 숫자까지 점검하는 영업 마감

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

영업 가격과 리베이트는 처음부터 끝까지 여러 화면과 파일을 거칩니다. 가격 조건은 가격 조건 화면(VK11)에서, 수주는 판매 오더 화면(VA01)에서, 청구는 청구 화면(VF01)에서, 한도는 신용 관리 화면(FD32)에서 처리하고, 약정 대비 달성 현황과 충당·정산 금액은 엑셀로 맞춰 봅니다. 승인은 메일과 구두로 오가니 “누가 언제 승인했는지”와 “이 숫자가 어디서 왔는지”를 월말마다 사람이 다시 짜 맞춥니다.

이 앱은 가격 요청 → 약정 → 달성 확인 → 리베이트 충당 → 정산(+정정)을 하나의 문서 흐름으로 묶어, 처리 담당자는 작성과 일괄 실행을, 승인자는 승인과 반려를, 관리자는 기준정보를 한 화면 안에서 맡습니다. 처리 규칙은 서버가 판정하고, 다 처리한 뒤에는 여섯 가지 대사 규칙이 약정부터 정산까지의 금액이 이어지는지를 다시 점검합니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리·점검 관점을 더해 확장합니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(2026-01 ~ 2026-10)에서 계획 순매출은 5,451,919,190원이고 실적은 5,305,392,467원으로 달성률 97.31%, 총차이는 −146,526,723원입니다. 표준 리포트는 여기까지 알려 줍니다. 이 앱의 요인 분해는 이 차이를 물량 −11,610,545원 · 믹스 −24,515,330원 · 단가 +3,523원 · 할인·리베이트 −118,910,939원 · 환율 +8,506,568원으로 나눕니다. 총차이의 대부분(약 81%)이 매출 부진이 아니라 할인과 리베이트에서 났다는 것이 바로 보이고, 다섯 요인의 합과 총차이의 차이는 0원으로 검산 줄에 표시됩니다.

같은 데이터에서 대사 6규칙의 검사 건수는 R01 759 · R02 1,007 · R03 24 · R04 442 · R05 24 · R06 759건이고, 차이는 모두 점검 기능을 보여 주려고 의도적으로 넣은 예외 10건뿐입니다.

도입하면 달라지는 것

• 월말 정산 준비 — 일괄 실행의 시뮬레이션 합계를 확인하고 실행하면 대상 목록 작성과 중복 확인이 사라집니다.
• 승인 — 메일 대신 화면에서 승인·반려하고 이력이 문서에 남습니다. 1억원 이상은 두 번째 승인자가 따로 확인합니다.
• 대사 회의 — “어느 숫자가 맞나” 대신 예외 목록의 사유와 조정 문서를 보며 무엇을 조치할지 이야기합니다.
• 감시 — 아무도 화면을 열지 않아도 하루 한 번 감시 규칙이 돌고 걸린 항목이 보고로 올라옵니다.

이런 회사에 맞습니다

가격 조건 · 리베이트 약정이 많아 월말 충당·정산 확인에 엑셀을 쓰는 영업 · 가격 담당 조직. 영업조직이 2곳 이상이고 승인 단계(작성 → 승인 → 확정)와 직무 분리가 필요한 회사. SAP 표준 화면은 그대로 쓰되 약정 · 달성 · 충당 · 정산의 연결 상태를 한 화면에서 점검하고 싶은 경영지원 · 영업관리 조직. AI 를 쓰고 싶지만 숫자의 출처는 서비스가 통제해야 하는 조직.

실행 화면 — 처리부터 대사·분석까지

사용 방법

1. 앱을 엽니다. 첫 화면 「개요 · 할 일」에 미결 정산액 · 승인 대기 · 반려 · 미해결 대사 예외 카드와 내 역할의 할 일이 보입니다. 오른쪽 위 「사용자」 상자로 조회자 · 처리자 · 승인자 · 관리자를 바꿔 볼 수 있습니다(시연용).
2. 조회조건을 넣습니다. 문서 처리 화면 위쪽의 영업조직 · 기간(시작/종료)은 모두 선택 사항이고, 문서번호 · 고객 입력란과 구분 · 상태는 왼쪽 목록 위에 있습니다.
3. 조회합니다. 파란 「조회」 단추를 누르거나 입력란에서 Enter 키를 누릅니다. 처음 열 때는 기본 조건으로 한 번 자동 조회합니다.
4. 요약을 확인합니다. 목록 제목의 문서 건수와 개요 카드의 금액 · 건수를 봅니다.
5. 행을 눌러 상세를 엽니다. 오른쪽에 문서 상세가 열리고 항목 → 상태 이력 → 연계 문서 → 감사 로그 탭으로 이어집니다.
6. 처리합니다. 처리자는 한도 점검 → 검토 요청, 승인자는 승인 또는 반려(사유 필수), 처리자는 승인 문서를 확정합니다.
7. 일괄 실행과 대사는 각각 「시뮬레이션」 → 「실행」, 「대사 실행」 순서입니다. 분석은 「조회」 한 번으로 큐브를 읽은 뒤 축을 바꿔도 서버를 다시 부르지 않습니다.
8. 내려받습니다. 목록과 분석 위쪽의 「CSV」 단추로 현재 값을 파일로 내려받고, 분석에서는 xlsx · PowerPoint 도 만듭니다.

무엇으로 만들었나

앱 정보

첫 화면에서 오늘 할 일이 보인다

앱을 열면 가장 먼저 「개요 · 할 일」이 나옵니다.

미결 정산액 · 약정 보류·차단 고객 · 승인 대기 · 반려 · 미해결 대사 예외 · 확정 문서 · 열린 할 일이 카드로 모입니다. 카드를 누르면 해당 목록으로 이동하고, 「내 할 일」은 지금 선택한 역할의 것만 보여 줍니다. 아래 알림에는 하루 한 번 도는 에이전트의 보고가 올라옵니다.

기준정보는 한곳에서 보고 고친다

고객 · 자재 · 할인 규칙 · 가격 조건 네 묶음을 탭으로 오갑니다.

고객별 영업조직 · 지역 · 유통 채널 · 정산 조건과 리베이트 한도 · 노출액 · 미결 정산액을 한 표로 봅니다. 한도에 가까운 고객은 사용률로 판단하고, 행을 누르면 변경 이력을 확인할 수 있습니다. 조회자 역할에는 수정 단추가 보이지 않습니다.

자재별 제품군 · 단위 · 정가를 봅니다. 정가는 가격 조건 레코드를 만들 때 기준이 되고, 사용 여부 열로 비활성 자재를 걸러낼 수 있습니다.

고객 그룹 × 제품군 × 최소 수량별 할인율 규칙입니다. 문서 항목에 할인율을 넣을 때 허용 범위를 판단하는 근거가 되며, 규칙 수가 적어 한 화면에서 전체를 확인합니다.

확정 약정 항목마다 만들어지는 가격 조건 레코드입니다. 단가 · 할인율 · 리베이트율 · 유효기간과 원천 문서 · 항목을 함께 보여 줘서, 약정이 가격 조건으로 이어졌는지 바로 확인합니다.

관리자 역할이 기준정보를 고치는 창입니다. 저장하면 변경 전후 값이 이력으로 남고, 허용되지 않는 값은 서버가 거절합니다.

승인 버튼은 승인자에게만 보인다

문서 처리는 목록과 상세가 한 화면에 있고, 역할에 맞는 단추만 보입니다.

문서번호 · 고객 · 구분 · 상태로 조회하고 CSV · xlsx 로 내려받습니다. 목록 제목의 건수가 현재 조건의 문서 수이며, 행을 누르면 오른쪽에 상세가 열립니다. 상태는 색으로도 구분됩니다.

문서 머리 정보(상태 · 승인 단계 · 한도 점검 결과 · 작성자 · 승인자 · 참조 문서)와 항목별 수량 · 단가 · 할인율 · 리베이트율 · 순액을 봅니다. 순액은 총액에서 할인과 리베이트를 뺀 값입니다.

초안 상태 문서에서는 항목 수정 · 한도 점검 · 검토 요청 단추가 활성화됩니다. 같은 문서를 조회자나 승인자 역할로 열면 이 단추들은 보이지 않습니다.

약정을 검토 요청하기 전에 리베이트 한도 사용률과 요청 할인율을 점검한 결과입니다. 한도를 넘으면 결과에 표시되고, 이 경우 승인은 두 단계로 진행됩니다.

고객 · 영업조직 · 구분을 정해 새 문서를 만드는 창입니다. 항목은 만든 뒤 상세에서 추가합니다. 필수 입력이 비면 저장 단추가 눌리지 않습니다.

초안 문서를 검토 요청하는 확인 창입니다. 요청하면 상태가 검토요청으로 바뀌고 승인자의 할 일에 올라갑니다.

승인자는 승인 또는 반려를 고릅니다. 반려에는 사유가 필수입니다. 작성자와 같은 사용자의 승인은 서버가 거절하고, 1억원 이상 문서는 두 번째 승인자가 따로 승인해야 승인 상태가 됩니다.

생성 → 검토 요청 → 승인 → 확정까지 처리자와 시각이 상태 이력으로 쌓입니다. 취소나 반려도 같은 표에 남아 문서의 지난 경로를 그대로 읽을 수 있습니다.

시뮬레이션 합계와 실행 결과가 같다

일괄 실행은 조건 → 시뮬레이션 → 확인 → 실행 → 로그 순서를 지킵니다.

영업조직 · 대상 기간 · 실행 유형(달성 일괄 확인 · 리베이트 일괄 충당)을 정합니다. 처리자와 관리자 역할만 실행할 수 있습니다.

시뮬레이션은 저장하지 않고 만들 문서 · 항목 수 · 수량 · 금액과 제외 사유를 미리 보여 줍니다. 이미 진행 중인 후속 문서가 있는 항목은 중복 방지를 위해 제외되고, 시뮬레이션 없이는 실행 단추가 활성화되지 않습니다.

시뮬레이션 합계를 확인하고 실행합니다. 서버는 시뮬레이션과 같은 대상으로만 실행합니다.

실행 이력 · 로그 · 만들어진 문서가 이어집니다. 만들어진 문서의 번호를 눌러 문서 처리에서 이어서 처리하고, 같은 조건으로 다시 실행해도 문서가 두 번 만들어지지 않습니다.

여섯 규칙으로 맞춰 보고 차이는 예외로 남긴다

대사는 약정에서 정산까지 금액이 이어지는지를 규칙별로 점검합니다.

여섯 규칙(R01~R06)의 이름 · 설명 · 허용 오차입니다. 약정 수량 = 달성 + 미확인, 달성 = 충당 + 미충당, 고객 미결 = 충당 − 정산, 총액 − 할인 − 리베이트 = 순액, 노출액 = 미결 + 미충당 약정, 확정 약정 항목 = 가격 조건 1건입니다.

규칙별 검사 건수 · 차이 건수 · 좌우 금액 · 최대 차이를 보여 줍니다. 샘플에서는 R02 만 차이 0건이고 나머지 규칙은 의도적으로 넣은 예외가 각각 2건씩 나옵니다.

차이가 난 항목을 목록으로 보고 사유와 조정 문서로 조치합니다. 상태는 미해결 → 조치 중 → 해결로 바뀌며, 처리자와 승인자 역할이 조치할 수 있습니다.

축을 바꿔도 합계가 같다

분석 화면은 큐브를 한 번 읽고 화면 안에서 축을 바꿔 다시 집계합니다.

차원 9개 가운데 원하는 것을 행(최대 3단계)과 열(최대 2단계)에 놓고 순매출 등 척도를 다시 집계합니다. 칸을 누르면 원천 문서 라인(드릴스루)이 열려 라인 합계가 칸 금액과 같은지 확인합니다.

비교 기준을 켜면 실적과 계획의 차이와 증감률이 칸마다 나옵니다. 색은 좋은 방향(높을수록 좋은지 낮을수록 좋은지)에 따라 칠합니다.

계획 대비 차이를 물량 · 믹스 · 단가 · 할인·리베이트 · 환율 다섯 요인으로 나누고, 요인 합이 총차이와 같은지 검산 줄에 보여 줍니다. 원인은 사람이 확인해야 하므로 화면은 “확인 필요”로 표시합니다.

차원 값을 골라 범위를 좁히는 창입니다. 영업조직 · 지역 · 채널 · 고객 그룹 · 고객 · 제품군 · 자재 · 통화를 조합할 수 있습니다.

경영진 · 영업 책임자 · 가격 담당 · 물류 담당 관점으로 척도 묶음을 한 번에 바꿉니다. 같은 큐브에서 나오므로 어느 관점이든 합계가 어긋나지 않습니다.

영업 문서가 다른 영역으로 이어지는 길

문서 흐름도에서 문서를 누르면 해당 문서 상세로 이동합니다.

영업 문서에서 생산 · 원가 · 재무 · 자금 문서로 이어지는 흐름을 그림으로 봅니다. 문서를 누르면 해당 문서 상세로 이동하고, 앞 문서와 뒤 문서의 금액 · 일자 · 비고가 함께 보입니다.

AI 는 설명만 하고 숫자는 서비스가 계산한다

AI 분석과 에이전트는 서비스가 계산한 근거 표를 읽어 말로 풀어 줍니다.

AI 분석은 서비스가 계산한 근거 표의 값을 읽어 요약합니다. 금액과 비율은 서비스가 만든 값 그대로이고, 모델은 설명만 덧붙입니다. 모델을 쓰지 않아도 같은 근거로 규칙 해설이 나옵니다.

에이전트는 하루에 한 번 감시 규칙 5개(제품군 순매출 계획 미달 · 리베이트 한도 임박 고객 · 장기 미충당 달성 · 고객그룹 공제율 상승 · 승인 대기 장기 문서)를 점검하고 걸린 항목을 역할별 보고로 올립니다.

누가 무엇을 했는지 남는다

이력 · 감사 · 권한 화면에서 역할별 권한과 상태 전이 규칙을 확인합니다.

역할별 권한과 상태 전이 규칙, 그리고 감사 로그를 한 화면에서 봅니다. 직무 분리나 권한 때문에 거절된 요청도 로그에 남습니다. 사용자 전환은 시연용이며 운영에서는 SAP 권한으로 바뀝니다.

좁은 화면에서도 목록과 상세를 쓴다

폭이 좁은 기기에서는 목록과 상세가 한 화면씩 차례로 열립니다.

좁은 화면에서는 목록이 먼저 보이고, 행을 누르면 상세가 이어서 열립니다. 조회조건은 접어 두고, 표의 열은 중요한 항목만 남깁니다.

화면 뒤에서 일어나는 일

모든 쓰기와 상태 전이는 화면이 아니라 서비스가 판정합니다. 화면은 단추를 보이거나 숨길 뿐이고, 같은 요청을 화면 밖에서 보내도 같은 규칙으로 걸러집니다.

처리 판정 규칙 — 조건 → 결과 상태 → 사용자 조치

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭 1060px 이하에서는 왼쪽 메뉴가 접히고 목록 · 상세가 한 열로 쌓입니다. 390px 폭에서도 단추와 표가 잘리지 않도록 표는 가로로 밀어 볼 수 있게 했습니다. 승인 · 반려처럼 중요한 단추는 그대로 남깁니다.

파일 구성

pricehub/
├─ index.html · Component.js · manifest.json
├─ controller/   화면별 제어 · 공통 제어
├─ view/         화면 9종 + 대화상자 16종
├─ model/        큐브 집계 · 서식 · 내보내기 · 권한 보조
├─ odata/        서비스 선언 · 서비스 로직 · 샘플 데이터
├─ css/ · i18n/  스타일 · 번역
└─ media/        소개 영상 · 포스터 · 목차 트랙

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

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리 · 점검 관점을 더해 확장합니다. 아래는 표준 화면으로 충분한 일과 이 앱이 더하는 관점을 나란히 둔 표입니다.

T-code 별 연계 지점

운영 전환 시 기존 표준 리포트와 화면을 없앨 필요는 없습니다. 이 앱은 같은 데이터를 이어받아 점검 · 승인 · 대사를 더하는 자리이므로 표준 화면은 그대로 두고 함께 씁니다.

분석 지표 정의

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

S/4HANA 의 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정해진 보고서와 임의 분석에 강점이 있습니다. 이 앱은 그 위에서 처리 · 승인 · 대사 · 요인 분해를 한 흐름으로 묶는 자리입니다. 표준 분석 앱의 구체적인 이름과 제공 범위는 시스템 버전에 따라 다르므로 이 글에서는 확인 필요로 남깁니다. 운영에서는 같은 CDS 큐브를 표준 분석 도구와 이 앱이 함께 읽을 수 있습니다.

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

CDS 구성 — 원천에서 화면까지

운영 데이터로 갈 때는 아래 순서로 뷰를 나눕니다. 이 절의 뷰 이름은 이 글에서 새로 스케치한 이름이고, 표준 CDS 뷰 이름은 확인하지 못해 원천 테이블(청구 VBRK · VBRP, 고객 KNA1 · KNVV, 자재 MARA · MAKT) 기준으로 썼습니다. 리베이트 약정과 신용 한도 원천은 확인 필요입니다.

뷰 레이어 구성

필드 매핑 — OData 엔티티 → 원천

① 대사 기준 테이블 — 규칙 · 허용 오차

대사 규칙과 허용 오차는 코드가 아니라 데이터로 둡니다. 규칙을 바꿀 때 뷰를 다시 이송하지 않게 하려는 것이 이 테이블의 이유입니다.

" ───────────────────────────────────────────────
"  테이블   : ZSD_RECON_RULE (대사 기준)
"  역할     : 대사 규칙 R01~R06 의 이름 · 허용 오차 · 사용 여부
"  이렇게 나눈 이유 : 허용 오차를 바꿀 때 뷰 이송을 피하려고
" ───────────────────────────────────────────────
@EndUserText.label : '영업 대사 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zsd_recon_rule {
  key client    : abap.clnt not null;
  key rule_id   : abap.char(3) not null;
  rule_name     : abap.char(60);
  @Semantics.amount.currencyCode : 'zsd_recon_rule.currency'
  tolerance     : abap.curr(15,2);
  currency      : abap.cuky;
  active        : abap.char(1);
}

② 고객 차원 — 이름 · 그룹 · 지역

고객 이름과 그룹, 지역을 한곳에서 제공하는 차원 뷰입니다. 모든 큐브와 대사 뷰가 같은 속성을 쓰게 합니다.

" ───────────────────────────────────────────────
"  뷰     : ZSD_I_CustomerDim
"  역할   : 고객 차원(이름 · 영업조직 · 그룹 · 채널 · 지역)
"  이렇게 나눈 이유 : 속성 정의를 큐브마다 복사하지 않으려고
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '영업 고객 차원'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'CustNo'
define view entity ZSD_I_CustomerDim
  as select from kna1
    left outer join knvv on knvv.kunnr = kna1.kunnr
{
  key kna1.kunnr  as CustNo,
      kna1.name1  as Name,
      knvv.vkorg  as SalesOrg,
      knvv.kdgrp  as CustGroup,
      knvv.vtweg  as Channel,
      kna1.regio  as Region
}

③ 자재 차원 — 제품군과 단위

자재의 제품군 · 단위 · 이름을 제공합니다. 제품군은 분석의 행 축과 일괄 실행 제외 판단에 쓰입니다.

" ───────────────────────────────────────────────
"  뷰     : ZSD_I_MaterialDim
"  역할   : 자재 차원(이름 · 제품군 · 기본 단위)
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '영업 자재 차원'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'MatNo'
define view entity ZSD_I_MaterialDim
  as select from mara
    left outer join makt on makt.matnr = mara.matnr
                        and makt.spras = $session.system_language
{
  key mara.matnr  as MatNo,
      makt.maktx  as Name,
      mara.matkl  as ProdGroup,
      mara.meins  as Uom
}

④ 순매출 큐브 — 원천 라인을 척도로 집계

청구 라인을 기간 · 영업조직 · 고객 · 자재 차원으로 묶어 순매출 · 수량을 합산합니다. 이 뷰의 합계가 원천 라인 합계와 같은지가 매번 검산하는 항목입니다.

" ───────────────────────────────────────────────
"  뷰     : ZSD_I_NetCube
"  역할   : 순매출 · 수량 큐브(청구 라인 기준)
"  이렇게 나눈 이유 : 집계는 데이터베이스에서, 화면은 읽기만
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '영업 순매출 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZSD_I_NetCube
  as select from vbrp
    inner join vbrk on vbrk.vbeln = vbrp.vbeln
  association [0..1] to ZSD_I_CustomerDim as _Customer
    on $projection.CustNo = _Customer.CustNo
{
  key vbrp.vbeln                                  as DocNo,
  key vbrp.posnr                                  as ItemNo,
      @ObjectModel.foreignKey.association : '_Customer'
      vbrk.kunag                                  as CustNo,
      vbrk.vkorg                                  as SalesOrg,
      vbrp.matnr                                  as MatNo,
      left( cast( vbrk.fkdat as abap.char(8) ), 6 ) as Period,
      vbrk.waerk                                  as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      vbrp.netwr                                  as NetAmt,
      @DefaultAggregation : #SUM
      vbrp.fkimg                                  as Qty,
      _Customer
}

⑤ 대사 뷰 — 고객 미결 = 충당 − 정산 (R03)

한 규칙을 뷰 하나로 만들어 좌우 금액과 차이를 계산합니다. 허용 오차는 기준 테이블에서 읽으므로 화면은 차이가 오차를 넘는 행만 예외로 보여 줍니다.

" ───────────────────────────────────────────────
"  뷰     : ZSD_I_ReconR03
"  역할   : 규칙 R03 — 고객 미결 정산액 = 확정 충당 순액 − 확정 정산
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '대사 R03'
define view entity ZSD_I_ReconR03
  as select from ZSD_I_CustomerOpen  as c
    inner join   ZSD_I_AccrualSum    as a on a.CustNo = c.CustNo
    inner join   ZSD_I_SettleSum     as s on s.CustNo = c.CustNo
    inner join   zsd_recon_rule      as r on r.rule_id = 'R03'
{
  key c.CustNo,
      c.OpenRebate                                        as LeftAmt,
      a.AccrualNet - s.SettleAmt                          as RightAmt,
      abs( c.OpenRebate - ( a.AccrualNet - s.SettleAmt ) ) as Diff,
      case when abs( c.OpenRebate - ( a.AccrualNet - s.SettleAmt ) ) > r.tolerance
           then 'X' else ' ' end                          as IsException
}

⑥ 분석 쿼리 — 제품군 × 월 순매출

화면의 레이아웃(행 · 열 · 척도)과 같은 모양을 서버 쪽에서도 정의합니다. 계산 항목(평균 순단가)은 수식으로 둡니다.

" ───────────────────────────────────────────────
"  뷰     : ZSD_C_NetQuery
"  역할   : 제품군(행) × 월(열) 순매출 · 평균 순단가
" ───────────────────────────────────────────────
@EndUserText.label : '제품군 × 월 순매출'
@Analytics.query : true
define view entity ZSD_C_NetQuery
  as select from ZSD_I_NetCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, mandatory : false }
  MatNo,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  Period,
  @AnalyticsDetails.query.axis : #COLUMNS
  @AnalyticsDetails.query.formula : 'NetAmt / Qty'
  cast( 0 as abap.dec(15,2) )  as AvgNetPrice,
  @DefaultAggregation : #SUM
  NetAmt
}

⑦ 접근 제어 — 영업조직 단위 제한

집계 단계에서 접근을 제한해야 합계로 새지 않습니다. 영업조직을 권한 객체의 값으로 제한합니다.

" ───────────────────────────────────────────────
"  DCL    : ZSD_I_NetCube
"  역할   : 영업조직(VKORG) 권한이 있는 행만 읽도록 제한
" ───────────────────────────────────────────────
@EndUserText.label : '영업 큐브 접근 제한'
@MappingRole : true
define role ZSD_I_NetCube {
  grant select on ZSD_I_NetCube
    where ( SalesOrg ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩 — 화면이 부르는 서비스

화면은 이 서비스만 바라봅니다. 처리 펑션(검토 요청 · 승인 · 확정 · 일괄 실행)은 RAP 액션으로 노출해 표준 일괄 처리나 BAPI 와 연결합니다.

" ───────────────────────────────────────────────
"  Service Definition : ZSD_UI_PRICEHUB
"  역할   : 화면이 부르는 엔티티 · 액션 목록
" ───────────────────────────────────────────────
@EndUserText.label : '영업 가격·리베이트 서비스'
define service ZSD_UI_PRICEHUB {
  expose ZSD_I_CustomerDim   as Customer;
  expose ZSD_I_MaterialDim   as Material;
  expose ZSD_I_NetCube       as Cube;
  expose ZSD_I_ReconR03      as ReconR03;
  expose ZSD_C_NetQuery      as NetQuery;
}
" 처리 펑션은 행위 정의(Behavior Definition)의 액션으로 선언한다
"   action SubmitDocument result [1] $self;
"   action ApproveDocument result [1] $self;
"   action PostDocument result [1] $self;
" Service Binding(OData V2 - UI) 으로 게시한 뒤 manifest 의 서비스 주소만 바꾼다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여덟 가지는 코딩이 아니라 합의이고, 합의가 끝나야 위 CDS 뷰를 확정할 수 있습니다.

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

위 표의 숫자는 도입 포인트의 사례와 같은 샘플 데이터에서 독립 스크립트로 다시 계산해 앱 결과와 맞춘 값입니다. 차이가 나는 10건은 대사 기능이 실제로 잡아내는지 보여 주려고 의도적으로 넣은 예외입니다. 서비스 로직은 64개 시나리오(상태 전이 · 직무 분리 · 2단계 승인 · 일괄 실행 중복 방지 · 대사 · 요인 분해)를 모두 통과했습니다.

운영 데이터로 갈 때

대용량(전표 · 문서 흐름 수천만 건)에서는 집계를 반드시 데이터베이스에서 합니다. 화면은 큐브 한 번 읽기에 조회 기간 · 영업조직 · 척도를 필수 파라미터로 받아 읽는 양을 제한하고, 드릴스루는 칸 하나의 원천 라인만 가져옵니다. 인덱스는 문서일 · 영업조직 · 고객 · 자재에 두고, 응답 시간 기준은 목록 조회 2초, 큐브 집계 5초, 드릴스루 3초를 출발점으로 잡아 실측으로 조정합니다(기준값은 확인 필요). 데모 데이터로는 문서 2,118건 · 문서 라인 2,363행 · 큐브 4,806행 규모규모이며, 실제 응답 시간은 고객사 데이터로 확인해야 합니다.

자주 묻는 질문

도입을 검토할 때 자주 나오는 질문을 숫자와 산식 · 화면과 처리 · 분석 기능 · 도입과 운영으로 묶었습니다.

숫자와 산식

화면과 처리

분석 기능

도입과 운영