대체가격 점검 — 사업부 사이 이전 단가를 정책가와 맞춰 보는 내부 거래 점검 화면

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

사업부끼리 반제품이나 제품을 넘길 때 적용하는 내부 거래 단가, 곧 대체가격은 해마다 같은 질문을 낳습니다. 정한 방법대로 계산한 단가와 실제로 적용한 단가가 같은가, 공급 사업부가 표준원가도 못 받고 넘기고 있지는 않은가, 수요 사업부가 외부에서 사는 값보다 비싸게 받고 있지는 않은가. 지금은 이 답이 단가표 · 표준원가 목록 · 사업부별 전기 내역에 흩어져 있어, 월마감마다 엑셀에 붙여 놓고 눈으로 대조합니다.

이 앱은 이전 건마다 정책 대체가격을 다시 계산해 적용 대체가격 옆에 놓고, 기준을 벗어난 건만 점검 필요로 가려냅니다. 건에서 사업부 쌍으로, 쌍에서 월로 모아 보고, 한 건을 열면 표준원가에서 적용 대체가격까지의 단가 구성 8단계가 펼쳐집니다. 그리고 그 숫자가 서로 맞는지를 아홉 가지 대사식으로 매번 검산합니다. 관련 기준서가 있는 영역이 아니라 관리회계 내부 점검이므로, 정책 방법과 기준은 회사가 정하고 이 화면은 그 기준에 맞는지를 봅니다.

핵심 포인트 여섯 가지

단가표 대조는 두 번째 질문에서 멈춘다

“이 단가가 정책대로인가”까지는 단가표로 답할 수 있습니다. 하지만 바로 이어지는 질문, 곧 “정책대로인데 공급 사업부는 손해를 보고 있지 않은가”, “이 쌍 전체로는 어느 쪽으로 쏠렸는가”에서 대조 작업이 끊깁니다. 표준원가는 다른 목록에, 시장가는 또 다른 목록에 있기 때문입니다. 이 앱은 표준원가와 시장가 참조를 이전 명세에 같이 싣고, 한 건에 여러 기준이 걸리면 L1 → M1 → P1 → K1 순서로 대표 코드를 하나 보여 주면서 점검 내용에는 걸린 기준을 모두 적습니다.

정책대로인 건과 정책에서 벗어난 건을 같은 줄에 놓는다

점검 화면은 이상한 건만 보여 주면 되는 것처럼 보이지만, 실제로는 정상 건과 같은 표에 있어야 판단이 됩니다. 이 화면은 정상 건과 점검 필요 건을 같은 이전 명세에 두고, 점검 결과 조건으로 걸러 볼 수 있게 했습니다. 점검 필요 16건만 보고 싶으면 조건에서 고르고, 정상 건까지 포함한 흐름이 필요하면 비워 두면 됩니다.

집계 행의 합계가 명세와 어긋나면 점검 자체를 믿을 수 없다

사업부 쌍과 월 집계는 모두 이전 명세를 더해 만든 값입니다. 그래서 쌍 합계 · 월 합계가 이전 명세 합계와 1원도 다르지 않아야 하고, 이 앱은 그 등식을 대사식으로 두고 전수로 돌립니다. 대사 결과 탭은 아홉 가지 대사식의 검사 건수와 차이 건수를 그대로 보여 줍니다.

사용 방법

1. 조회조건을 채웁니다. 회계연도는 필수이고, 전기 월 범위 · 공급 사업부 · 수요 사업부 · 대체가격 방법 · 점검 결과는 선택입니다. 비워 두면 전체입니다.
2. 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 화면을 처음 열면 자동으로 한 번 조회됩니다.
3. 조건 아래 요약 8개를 확인합니다. 점검 필요 이전 건과 사업부 쌍 숫자가 먼저 눈에 들어옵니다.
4. 탭을 이전 명세 → 사업부 쌍 → 월별 추이 → 단가 구성 → 대사 결과 순서로 옮겨 가며 범위를 좁힙니다.
5. 이전 명세 · 사업부 쌍 · 월별 추이 탭에서 행을 누르면 상세가 열립니다. 이전 건은 단가 구성 8단계를, 쌍과 월은 해당 이전 명세를 보여 줍니다.
6. CSV 내려받기로 지금 보는 탭의 조회 결과를 내려받습니다(UTF-8, 엑셀에서 바로 열립니다).

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

샘플 자료 전체(이전 119건 · 단가 구성 952행 · 사업부 쌍 45행 · 월 9행)에 대해 아홉 가지 대사식을 전수로 돌린 결과입니다. 모두 차이 0입니다. 한편 점검 필요 16건은 대사 차이가 아니라 점검 화면을 시연하려고 일부러 넣은 예외(정책 이탈 · 표준원가 미달 · 매입액 불일치 · 시장가 초과)입니다.

무엇으로 만들었나

실행 화면

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

처음 열었을 때

조회 조건과 요약, 이전 명세가 한 화면에 세로로 놓입니다. 처음 여는 사람도 무엇을 고르면 무엇이 바뀌는지 바로 보이도록, 조건을 채우기 전에 올해 전체를 한 번 조회해 둡니다.

위쪽 안내 띠는 대체가격이 무엇이고 어떤 기준에서 점검 필요로 표시하는지를 먼저 적어 둡니다. 요약 8개는 적용 이전금액 8,865.5백만 원, 정책 이전금액 8,849.8백만 원, 편차 +15.7백만 원(+0.18%), 공급 이전이익 1,376.1백만 원, 점검 필요 이전 16건, 점검 필요 사업부 쌍 8개, 정합성 대사 차이 0건입니다. 탭 머리의 숫자(119 · 45 · 9 · 952 · 9)는 각 탭의 행 수입니다.

조건은 회계연도(필수) · 전기 월 시작과 종료 · 공급 사업부 · 수요 사업부 · 대체가격 방법 · 점검 결과입니다. 비워 두면 전체이고, 입력칸에서 Enter 키를 눌러도 조회됩니다. 초기화를 누르면 기본값으로 돌아가 다시 조회합니다. 요약 8개도 조회 범위에 맞춰 같이 바뀌므로, 사업부 하나만 골라 편차를 볼 수 있습니다.

모아서 보기 — 사업부 쌍과 월

이전 건 하나하나는 정책 안에 있어도 사업부 쌍이나 월로 모으면 한쪽으로 쏠릴 수 있습니다. 두 집계 탭이 그 쏠림을 먼저 보여 줍니다.

한 건씩 보면 작은 편차도 쌍으로 모으면 방향이 보입니다. 쌍의 편차율이 ±1.5%를 넘으면 점검 필요로 표시하고, 이 자료에서는 45개 쌍 가운데 8개가 걸립니다. 행을 누르면 그 월 · 그 쌍의 이전 명세가 열립니다. 쌍의 이전금액 합계는 이전 명세 합계와 같아야 하며, 이 등식은 대사 결과 탭에서 매번 확인합니다.

월 편차율이 ±0.75%를 넘거나 점검 필요 이전 건이 3건 이상이면 그 달을 점검 필요로 표시합니다. 이 자료에서는 3월(−1.09%), 8월(+0.92%), 9월(+2.77%)이 걸립니다. 마감 회의에서는 걸린 달부터 열어 사업부 쌍과 이전 명세로 내려가는 순서가 가장 빠릅니다.

한 건을 열어 보기 — 단가 구성과 상세

점검 필요로 표시된 건이 왜 걸렸는지는 단가 구성에서 확인합니다. 표준원가에서 출발해 정책가를 거쳐 적용가까지 가는 길이 한 줄씩 보입니다.

10 직접재료비 · 20 직접노무비 · 30 제조간접비가 표준원가를 이루고, 40 정책 기준단가 · 50 가감액 · 60 정책 대체가격이 정책가를, 70 적용 편차 · 80 적용 대체가격이 실제로 적용한 단가를 보여 줍니다. 단가 구성 탭은 이 단계를 모두 펼친 목록(952행)이라 방법별 · 단계별로 걸러 볼 수 있습니다.

왼쪽은 이전 건의 식별 정보, 가운데는 기준단가 · 가감율 · 정책 대체가격 · 적용 대체가격 · 시장가 참조 · 편차율, 오른쪽은 금액과 점검 결과입니다. 이 건은 정책가 대비 편차율 +7.40%이고 적용 대체가격이 시장가 참조보다 높아 점검 필요로 표시됩니다. 점검 내용 칸에는 걸린 기준이 모두 적히며, 아래 표가 8단계 단가 구성입니다.

쌍의 편차율이 크면 그 안에서 어느 건이 끌었는지를 찾아야 합니다. 목록은 편차율을 눌러 정렬할 수 있어 위쪽에 큰 건이 모입니다. 원인은 화면이 단정하지 않습니다. 근거를 확인할 건을 골라 주는 데까지가 이 화면의 일입니다.

숫자를 믿을 수 있는가 — 대사 결과

점검 화면의 숫자가 틀리면 점검 자체가 의미가 없습니다. 화면이 스스로 대사식을 돌려 결과를 보여 줍니다.

대사식마다 검사 건수와 차이 건수, 최대 차이가 나옵니다. 아홉 가지 모두 차이 0건이며, 요약의 마지막 칸(정합성 대사 차이)이 이 탭의 합계입니다. 숫자가 의심될 때 가장 먼저 열 탭입니다.

화면 뒤에서 일어나는 일

화면은 조건을 모아 서비스에 한 번에 하나의 요청을 보내고, 돌아온 행을 그대로 표에 묶습니다. 탭마다 요청이 따로 나가므로 이전 명세에서 쌍 탭으로 옮겨도 다시 계산하지 않고 해당 집계를 받아 옵니다. 정책가 재계산 · 편차 · 점검 코드는 서비스가 정해 내려보내기 때문에, 화면에서 숫자를 고쳐 쓰는 자리가 없습니다.

점검 판정 규칙

한 건이 여러 기준에 걸리면 L1 → M1 → P1 → K1 순서로 코드를 하나만 보여 주고, 점검 내용에는 걸린 기준을 모두 적습니다. 이 자료에서는 대표 코드 기준으로 P1 8건 · M1 4건 · L1 3건 · K1 1건, 합쳐서 16건이 걸립니다.

산출식

조회조건

“전체”는 코드값으로 보내지 않고 해당 조건을 빼는 방식입니다. 그래서 목록에 없는 새 코드가 생겨도 “전체”에는 빠짐없이 들어옵니다.

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조건 줄이 두 줄 이상으로 접히고 요약 8개가 가로로 흘러내립니다. 표는 가로 스크롤로 넘기며, 행을 누르면 상세 창이 화면 전체 폭으로 열립니다. 조회 버튼과 초기화 버튼은 어느 폭에서도 조건 줄 안에 있습니다.

파일 구성

앱 폴더
├─ index.html · Component.js · manifest.json
├─ controller/  (BaseController · Main)
├─ view/        (Main.view · DetailDialog.fragment)
├─ model/       (formatter · ErrorHandler)
├─ css/ · i18n/
├─ odata/       (서비스 메타데이터 · service.js · 샘플 json)
└─ media/       (소개 영상 · 포스터)

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다. 원천 확인과 감사 대응은 표준 거래가 맡는 편이 안전합니다.

법정 보고와 감사 대응에 쓰는 숫자는 표준 거래에 두는 편이 좋습니다. 이 앱은 내부 관리용 점검 도구이고, 바뀌는 속도와 책임이 다르기 때문입니다.

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

S/4HANA 에서는 CDS 분석 쿼리를 Fiori 분석 앱이나 Analysis for Office 로 바로 띄우는 방식이 표준입니다. 이 앱의 서비스를 운영에서 CDS 서비스로 바꾸면 같은 쿼리를 표준 분석 도구에서도 열 수 있습니다. 다만 점검 코드와 쌍 · 월 판정처럼 “다음에 무엇을 확인하라”를 알려 주는 부분은 이 앱 화면이 더하는 관점이고, 분석 도구에서는 숫자만 나옵니다. 둘을 같이 두면 분석가는 도구로 자유롭게 파고, 현업은 이 화면으로 점검합니다.

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

분석 지표 정의표

원천 테이블

표준원가를 이전 시점에 고정하는 방식과 내부 청구 단가를 어느 필드에서 읽는지는 확인 필요 항목입니다. 운영 환경의 원가 계산 설정에 따라 다르므로 도입 때 함께 정합니다.

CDS 구성

이 사례의 화면은 샘플 서비스가 내려 주는 값을 그대로 보여 줍니다. 운영에서는 같은 모양의 값을 CDS 뷰가 만들어 주어야 하고, 점검 코드와 집계도 DB 에서 한 번만 정의해야 화면 · 분석 도구 · 배치가 같은 숫자를 봅니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 정책 매핑 테이블

리포트의 모든 판정이 이 표에서 갈립니다. 어느 품목을 어떤 방법으로 계산하고 가감율이 얼마인지를 정하는 자리라, 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 중간에 방법이 바뀌어도 과거 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  zprice_policy — 대체가격 정책 매핑 (투명 테이블)
"  품목 · 공급 · 수요 사업부 조합마다 방법과 가감율을 둔다.
"  코드에 박지 않는 이유 : 방법은 협의로 바뀌고, 바뀔 때마다
"  개발자를 부르게 만들면 점검 기준이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '대체가격 정책 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zprice_policy {
  key mandt    : mandt not null;
  key matnr    : matnr not null;         " 품목
  key supplier : abap.char(4) not null;  " 공급 사업부
  key receiver : abap.char(4) not null;  " 수요 사업부
  key valid_to : abap.dats not null;     " 유효 종료일
  valid_from   : abap.dats;
  method       : abap.char(4);           " COST 원가가산 · MKT 시장가 기준 · NEG 협상가
  basis_price  : abap.curr(15,2);        " 협상가일 때의 계약 단가
  adj_pct      : abap.dec(5,2);          " 가감율(%) — 마이너스 가능
  currency     : waers;
}

② 표준원가 차원 뷰

단가 구성의 앞 세 단계(재료비 · 노무비 · 제조간접비)가 여기서 나옵니다. 표준원가는 품목 평가 데이터에서 읽는데, 이전 시점의 값이어야 하므로 기간과 평가 영역을 키에 포함합니다. 품목 평가 데이터에서 구성 항목을 어떻게 얻는지는 원가 계산 설정에 따라 다르므로 확인이 필요합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_TrfItemCost — 품목 표준원가 차원
"  한 품목 · 한 평가 영역당 한 행. 원가 구성 3항목을 함께 둔다.
"  차원 뷰를 따로 두는 이유 : 표준원가를 읽는 곳을 한 곳으로 모아
"  단가 구성 10 · 20 · 30 단계와 점검 규칙이 같은 값을 보게 한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '품목 표준원가'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'Material'
define view entity ZI_TrfItemCost
  as select from mbew as Val
{
  key Val.matnr                        as Material,
  key Val.bwkey                        as ValuationArea,

      cast( 'KRW' as waers )           as Currency,   " 확인 필요 — 운영에서는 회사코드 통화에서 얻는다
      @Semantics.amount.currencyCode : 'Currency'
      Val.stprs                        as StandardPrice,
      Val.peinh                        as PriceUnit,

      " 재료 · 노무 · 간접 구성은 원가 계산 결과 테이블에서 읽는다 (확인 필요)
      cast( 0 as abap.curr(15,2) )     as MaterialCost,
      cast( 0 as abap.curr(15,2) )     as LaborCost,
      cast( 0 as abap.curr(15,2) )     as OverheadCost
}

③ 이전 건 기본 뷰

이전 건 하나를 한 행으로 만드는 뷰입니다. 공급 사업부의 내부 수익 라인과 수요 사업부의 내부 매입 라인을 같은 이전 건 키로 묶어 금액과 매입 차이를 만듭니다. 이 키를 어떻게 만들지(전표 참조 필드, 자재 문서 번호 등)가 운영 전환의 숨은 논점입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_TrfActual — 이전 건 기본 뷰
"  공급 수익 라인과 수요 매입 라인을 이전 건 키로 묶는다.
"  묶는 기준(TransferKey) 은 환경마다 달라 확인이 필요하다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '사업부 간 이전 실적'
define view entity ZI_TrfActual
  as select from acdoca as Sup
  inner join      acdoca as Buy
    on  Buy.rldnr = Sup.rldnr
    and Buy.rbukrs = Sup.rbukrs
    and Buy.gjahr = Sup.gjahr
    and Buy.awref = Sup.awref          " 이전 건 참조 — 확인 필요
{
  key Sup.rldnr                               as Ledger,
  key Sup.rbukrs                              as CompanyCode,
  key Sup.gjahr                               as FiscalYear,
  key Sup.awref                               as TransferKey,

      Sup.poper                               as Period,
      Sup.prctr                               as SupplierProfitCenter,
      Buy.prctr                               as ReceiverProfitCenter,
      Sup.matnr                               as Material,
      Sup.msl                                 as Quantity,
      Sup.runit                               as QuantityUnit,

      @Semantics.amount.currencyCode : 'Currency'
      -1 * Sup.hsl                            as TransferAmount,   " 수익은 대변(음수)
      @Semantics.amount.currencyCode : 'Currency'
      Buy.hsl                                 as BuyAmount,        " 비용은 차변(양수)
      Sup.rhcur                               as Currency
}
where Sup.racct between '0042000000' and '0042999999'   " 내부 수익 계정 범위 — 회사 체계에 맞춘다
  and Buy.racct between '0052000000' and '0052999999'   " 내부 매입 계정 범위

④ 정책 대체가격 뷰

방법별로 기준단가가 다릅니다. 원가가산은 표준단가, 시장가 기준은 시장가 참조, 협상가는 계약 단가입니다. 이 선택을 case 한 곳에서만 하도록 모아 두면, 방법이 하나 늘어도 이 뷰만 고치면 됩니다.

" ────────────────────────────────────────────────────────────────
"  ZI_TrfPolicyPrice — 정책 대체가격
"  정책 대체가격 = 기준단가 × (1 + 가감율 ÷ 100)
"  기준단가를 고르는 규칙을 이 뷰 하나에만 둔다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '정책 대체가격'
define view entity ZI_TrfPolicyPrice
  as select from zprice_policy as Pol
  association [0..1] to ZI_TrfItemCost as _Cost
    on _Cost.Material = $projection.Material
{
  key Pol.matnr                                   as Material,
  key Pol.supplier                                as Supplier,
  key Pol.receiver                                as Receiver,
  key Pol.valid_to                                as ValidTo,

      Pol.method                                  as Method,
      Pol.adj_pct                                 as AdjPct,

      case Pol.method
        when 'COST' then _Cost.StandardPrice
        when 'NEG'  then Pol.basis_price
        else             Pol.basis_price           " 시장가 기준은 시장가 참조 뷰에서 채운다 (확인 필요)
      end                                         as BasisPrice,

      cast( case Pol.method
              when 'COST' then _Cost.StandardPrice
              else Pol.basis_price
            end * ( 1 + Pol.adj_pct / 100 )
            as abap.curr(15,2) )                  as PolicyPrice,
      Pol.currency                                as Currency,
      _Cost
}

⑤ 점검 큐브

점검 규칙을 정의하는 자리입니다. 편차 · 편차율 · 이전이익 · 매입 차이와 점검 코드(L1 → M1 → P1 → K1)가 모두 여기서 만들어지고, 화면은 이 값을 그대로 씁니다. 규칙을 화면에서 빼야 하는 이유는 분석 도구와 배치가 같은 판정을 써야 하기 때문입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_TrfCheckCube — 점검 큐브
"  실적 + 정책 + 편차 + 점검 코드.
"  코드 우선순위 : L1 표준원가 미달 → M1 매입 불일치 → P1 편차율 5% 초과 → K1 시장가 초과
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '대체가격 점검 큐브'
@Analytics.dataCategory              : #CUBE
define view entity ZI_TrfCheckCube
  as select from ZI_TrfActual as Act
  left outer join ZI_TrfPolicyPrice as Pol
    on  Pol.Material = Act.Material
  association [0..1] to ZI_TrfItemCost as _Cost
    on  _Cost.Material = Act.Material
{
  key Act.TransferKey,
      Act.Period,
      Act.SupplierProfitCenter,
      Act.ReceiverProfitCenter,
      Act.Material,

      @Aggregation.default : #SUM
      Act.Quantity                                                  as Quantity,
      @Aggregation.default : #SUM
      Act.TransferAmount                                            as TransferAmount,
      @Aggregation.default : #SUM
      cast( Act.Quantity * Pol.PolicyPrice as abap.curr(15,0) )     as PolicyAmount,
      @Aggregation.default : #SUM
      cast( Act.Quantity * _Cost.StandardPrice as abap.curr(15,0) ) as StandardAmount,

      " 편차율 = (적용가 − 정책가) ÷ 정책가 × 100
      cast( ( Act.TransferAmount / Act.Quantity - Pol.PolicyPrice )
            / Pol.PolicyPrice * 100 as abap.dec(7,2) )              as GapPct,

      case
        when Act.TransferAmount < Act.Quantity * _Cost.StandardPrice            then 'L1'
        when Act.BuyAmount      <> Act.TransferAmount                           then 'M1'
        when abs( Act.TransferAmount / Act.Quantity - Pol.PolicyPrice )
             > Pol.PolicyPrice * 0.05                                           then 'P1'
        " K1 : 시장가 참조 뷰(확인 필요)를 association 으로 붙여 같은 방식으로 더한다
        else 'OK'
      end                                                           as CheckCode,

      _Cost
}

⑥ 분석 쿼리

사업부 쌍과 월 집계가 여기서 나옵니다. 화면 탭과 같은 모양으로 행 축 · 열 축 기본 배치를 두면 Fiori 분석 앱과 Analysis for Office 가 같은 쿼리를 그대로 엽니다. 사업부 쌍 편차율 기준(1.5%)은 계산 측정값으로 둡니다.

" ────────────────────────────────────────────────────────────────
"  ZC_TrfCheckQuery — 분석 쿼리
"  행 : 사업부 쌍 · 열 : 회계기간. 측정값은 이전금액 · 정책금액 · 편차율.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '대체가격 점검 쿼리'
@Analytics.query                  : true
@OData.publish                    : false
define view entity ZC_TrfCheckQuery
  as select from ZI_TrfCheckCube
{
      @AnalyticsDetails.query.axis : #ROWS
      @Consumption.filter.selectionType : #SINGLE
  key SupplierProfitCenter,
      @AnalyticsDetails.query.axis : #ROWS
  key ReceiverProfitCenter,
      @AnalyticsDetails.query.axis : #COLUMNS
      Period,

      @AnalyticsDetails.query.axis : #COLUMNS
      @Aggregation.default : #SUM
      TransferAmount,
      @Aggregation.default : #SUM
      PolicyAmount,

      " 쌍 편차율 = (이전금액 − 정책금액) ÷ 정책금액 × 100
      @AnalyticsDetails.query.formula : '( TransferAmount - PolicyAmount ) / PolicyAmount * 100'
      @EndUserText.label : '쌍 편차율(%)'
      cast( 0 as abap.dec(7,2) )                    as PairGapPct
}

⑦ 권한 정의(DCL)

집계를 읽는 자리에 걸어야 합니다. 상세 라인에만 걸면 전체 합계에서 내 몫을 빼는 방식으로 남의 사업부 숫자를 알아낼 수 있습니다. 회사코드와 프로핏센터 두 축으로 겁니다.

" ────────────────────────────────────────────────────────────────
"  ZC_TrfCheckQuery — 권한 정의
"  회사코드 · 프로핏센터 표준 권한 객체를 집계 단계에 건다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '대체가격 점검 권한'
@MappingRole : true
define role ZC_TrfCheckQuery {
  grant select on ZC_TrfCheckQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( SupplierProfitCenter ) = aspect pfcg_auth( K_PCA, PRCTR, ACTVT = '03' );
}

⑧ 서비스 정의

마지막으로 쿼리를 OData 서비스로 노출합니다. 서비스 바인딩을 게시하고 나면 화면의 서비스 주소만 바꿔 운영에 붙입니다.

" ────────────────────────────────────────────────────────────────
"  ZSD_TrfCheck — 서비스 정의
"  바인딩은 OData V2 - UI 로 만들고 게시한다(활성화 후 서비스 주소 확인).
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '대체가격 점검 서비스'
define service ZSD_TrfCheck {
  expose ZC_TrfCheckQuery   as TrfCheck;
  expose ZI_TrfCheckCube    as TrfCube;
  expose ZI_TrfPolicyPrice  as TrfPolicy;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

이전 건이 수천만 건으로 늘면 집계를 화면에서 하는 방식은 바로 막힙니다. 쌍과 월 집계는 DB 에서 집계한 결과만 받고, 이전 명세는 필수 조건(회계연도 · 기간)을 반드시 받아 범위를 좁힌 뒤 페이지 단위로 읽습니다. 기간 · 사업부 · 점검 결과에 인덱스를 두고, 첫 화면은 최근 월 하나로 시작하도록 기본값을 정합니다. 응답 시간 기준은 도입 때 정하되, 쌍 집계는 수 초 안에, 이전 명세는 한 페이지 단위로 바로 나오는 것을 목표로 잡습니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문들입니다. 네 묶음으로 나누어 적었습니다.

숫자와 산식

화면과 조작

점검 판정

도입과 운영