에너지 원가 배부 점검 — 제조원가, 전기·스팀·가스·압축공기 청구 금액이 생산오더에 맞게 나뉘었는지 표준 원단위와 견주는 월마감 화면

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

매월 말, 제조원가 담당자는 같은 질문을 받습니다. “전기료와 스팀·가스 요금이 이번 달 얼마 나왔고, 그게 제품 원가에 제대로 들어갔나?” 청구서의 금액은 하나인데, 그 금액이 오더마다 얼마씩 나뉘었는지 확인하려면 원가센터 개별 항목, 오더 개별 항목, 오더 원가 분석, 계량기 측정 문서를 차례로 열어 엑셀에서 맞춰 봐야 합니다.

이 앱은 그 맞춤 작업을 한 화면에 올립니다. 청구 금액을 에너지원 풀로 모으고, 풀의 청구 수량을 하위 계량 수량과 견주어 손실을 가려낸 뒤, 계량된 수량만큼을 오더 라인에 실적 사용량으로 나눕니다. 그 배부액을 표준 원단위로 계산한 표준 에너지원가와 비교해 사용량 차이와 단가 차이로 갈라 보여 줍니다. 대상 영역은 제조원가 분석이며, 특정 기준서의 요구사항을 점검하는 화면이 아니라 내부 관리용 점검 도구입니다.

청구서는 하나인데 오더 원가는 따로 계산하게 된다

표준 화면은 원가센터에 모인 에너지 비용, 오더에 귀속된 비용, 오더 단위 표준·실적 비교를 각각 보여 줍니다. 세 화면의 숫자가 왜 다른지는 결국 사람이 맞춰 봐야 합니다. 이 앱은 청구 금액 = 오더 배부액 합계 + 미배부 손실액이라는 한 줄의 식으로 세 화면을 이어 붙이고, 이 식이 24개 풀 전부에서 성립하는지 매번 검산해 보여 줍니다.

손실은 합계에 묻히면 보이지 않는다

이 표본의 6개월 합계로 보면 청구 금액 168.6백만 원 가운데 8.8백만 원(5.2%)이 오더에 나뉘지 못했습니다. 평균만 보면 “대체로 괜찮다”입니다. 그러나 월 × 에너지원 풀로 쪼개면 4월 압축공기의 손실률은 15.40%로 한도 12%를 넘고, 5월 스팀은 7.97%로 한도 6%를 넘습니다. 합계에서는 보이지 않던 두 풀이 풀 대사 탭에서는 점검 필요로 바로 떠오릅니다.

표준 원단위에서 벗어난 오더는 따로 찾아야 한다

오더의 표준 사용량은 생산수량 × 표준 원단위입니다. 실적 사용량이 표준보다 10% 넘게 많은 오더는 계량값이나 생산수량, 표준 원단위 자체를 확인해야 하고, 10% 넘게 적은 오더는 계량값 누락을 의심해야 합니다. 이 표본에서는 252개 오더 라인 가운데 초과 8건, 미달 2건이 점검 필요로 표시됩니다. 미달을 같이 보는 이유는 한쪽 오더에서 빠진 사용량이 다른 오더로 몰려 갔을 수 있기 때문입니다.

조회만 되는 리포트는 금방 안 열린다

숫자만 보여 주고 끝나는 리포트는 이상한 숫자를 만나는 순간 멈춥니다. 이 앱은 월 → 풀 → 품목·작업장 → 오더 라인으로 한 단계씩 내려가고, 표의 행을 누르면 상세 창이 열려 하위 라인을 보여 주며, 현재 탭의 결과를 CSV 로 내려받을 수 있습니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 확인하고 필요하면 전기 월 시작·종료, 작업장, 품목, 에너지원, 점검 결과를 고릅니다. 비워 두면 전체입니다.
2. 조회 — 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 화면을 처음 열 때 한 번 자동 조회됩니다.
3. 요약 확인 — 위쪽 타일에서 배부 에너지원가 · 표준 에너지원가 · 원가 차이 · 미배부 손실액 · 월 평균 손실률 · 점검 필요 건수 · 대사 차이 건수를 봅니다.
4. 탭 이동 — 오더별 점검 → 품목별 집계 → 작업장별 집계 → 에너지원 풀 대사 → 월별 추이 → 대사 결과 순서로 넓은 범위에서 근거까지 내려갑니다.
5. 행 클릭 상세 — 표의 행을 누르면 상세 창이 열려 그 행의 값과 하위 오더 라인을 보여 줍니다.
6. 내보내기 — 현재 탭의 결과를 UTF-8 CSV 로 내려받습니다.

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

화면이 보여 주는 숫자가 서로 맞는지는 화면 안의 대사 결과 탭에서 검산합니다. 일곱 가지 식을 총 612건 검사해 차이 0건이었습니다. 점검 필요로 표시되는 건수는 의도적으로 기준을 벗어나게 넣은 값이며 대사 차이와는 다릅니다.

무엇으로 만들었나

실행 화면

아래 화면은 가상의 작업장 6곳(CNC 선반 · 머시닝센터 · 프레스 라인 · 사출 성형기 · 조립 라인 · 도장 라인)과 가상의 단가로 만든 검증용 샘플 데이터(2026년 1~6월)를 실제로 조회한 모습입니다. 오더 라인 252건, 월 × 에너지원 풀 24건이며 실제 고객사 값이 아닙니다.

처음 열었을 때와 조건 조회

처음 열었을 때 한 번 자동 조회되고, 조건을 바꿔 다시 조회하는 흐름입니다.

열면 자동으로 한 번 조회됩니다. 맨 위 조회조건은 회계연도 · 전기 월 시작/종료 · 작업장 · 품목 · 에너지원 · 점검 결과 여섯 칸이고 기본값은 2026년 전체입니다. 요약 지표는 배부 에너지원가 159.8 · 표준 에너지원가 154.3 · 원가 차이 5.5 · 미배부 손실액 8.8(이상 백만 원) · 월 평균 손실률 5.18% · 점검 필요 오더 라인 10 · 점검 필요 풀 2 · 대사 차이 건수 0 순서로 읽습니다. 표는 오더 한 줄에 에너지원 한 종류가 놓이며, 표준 사용량 · 실적 사용량 · 사용량 차이율 · 배부액 · 원가 차이 · 점검 결과가 이어집니다. 탭 이름 옆 숫자는 조회된 건수입니다.

조회조건은 입력 칸에서 Enter 를 누르거나 오른쪽 끝의 조회 버튼을 누르면 서비스로 전달됩니다. 이 화면은 2월부터 4월까지, 전력만 골라 오더 라인 48건이 남았습니다. 비워 둔 칸은 “전체”라는 값을 보내지 않고 조건 자체를 만들지 않습니다. 초기화 버튼은 조회 버튼 옆에 있고 모든 칸을 기본값으로 되돌립니다.

풀에서 품목으로 — 청구 금액이 어디로 나뉘었는지

청구서의 수량이 계량기 수량과 맞는지(풀), 그 수량이 어느 품목에 얹혔는지(품목)를 차례로 봅니다.

월 × 에너지원 24행의 풀입니다. 청구 수량에서 하위 계량 수량을 뺀 것이 손실 수량이고, 손실 수량에 청구 단가를 곱한 것이 미배부 손실액입니다. 한도는 전력 4% · 스팀 6% · 도시가스 3% · 압축공기 12%이며, 4월 압축공기(15.40%)와 5월 스팀(7.97%)이 한도를 넘어 점검 필요(P01)로 표시됩니다. 점검 필요만 보기를 켜면 이 두 행만 남습니다.

품목 8개 × 6개월 48행입니다. 에너지 비중은 배부액을 제조원가로 나눈 값이고 품목마다 한도가 다릅니다. 4월 스테인리스 축(17.35%, 한도 17.2%)을 비롯해 여섯 행이 한도를 넘어 점검 필요(S01)입니다. 원가 차이율은 표준 에너지원가 대비 배부액의 차이이며, 10%를 넘으면 점검 필요(V01)입니다. 이 표본에서는 V01이 걸린 행이 없습니다.

월별 추이와 근거 내려가기

월 단위로 이상한 달을 찾고, 행을 눌러 근거 라인으로 내려가는 흐름입니다.

월 청구 금액은 1월 27.7 · 2월 24.4 · 3월 29.4 · 4월 29.3 · 5월 29.8 · 6월 28.1(백만 원)입니다. 월 손실률은 4월에 8.36%로 튀고 나머지 달은 4.3~4.7%대입니다. 4월의 튄 값은 압축공기 풀 하나가 만든 것이므로, 이 탭에서 월을 확인한 뒤 풀 대사 탭으로 내려가 원인을 좁힙니다. 점검 필요 월은 2 · 4 · 5 · 6월 네 개입니다.

표의 행을 누르면 상세 창이 열려 그 행의 값과 하위 오더 라인 목록을 보여 줍니다. 풀 행에서는 그 달·그 에너지원을 쓴 오더가 표준 사용량 · 실적 사용량 · 차이와 함께 나열되어, 손실이 어느 오더에 얹혔는지가 아니라 배부가 어떻게 나뉘었는지를 확인합니다. 닫기는 X 버튼 · 바깥 영역 · ESC 모두 됩니다.

숫자를 믿을 수 있는가

화면이 스스로 검산한 결과입니다.

대사 결과 탭은 R01~R07의 검사 건수 · 차이 건수 · 최대 차이를 보여 줍니다. 모든 식이 차이 0건이어야 계산이 서로 맞는 것입니다. R01은 월 × 에너지원 24건에서 청구 금액이 오더 배부액 합계와 미배부 손실액의 합과 같은지, R03·R04는 오더 라인 252건 전부에서 표준과 차이의 합이 배부액과 같은지를 봅니다. 점검 필요 건수는 이 탭의 차이 건수와 별개입니다.

화면 뒤에서 일어나는 일

배부는 다섯 단계로 흘러갑니다. 각 단계의 결과가 다음 단계의 입력이 되므로, 어느 단계에서 숫자가 어긋나는지가 대사식으로 바로 드러납니다.

1. 풀 — 월 · 에너지원별 청구 금액 = 청구 수량 × 청구 단가.
2. 손실 — 손실 수량 = 청구 수량 − 하위 계량 수량, 손실률(%) = 손실 수량 ÷ 청구 수량 × 100, 미배부 손실액 = 손실 수량 × 청구 단가.
3. 배부 — 오더 라인 배부액 = 실적 사용량 × 그 달 청구 단가.
4. 표준 — 표준 에너지원가 = 표준 사용량 × 표준 단가, 표준 사용량 = 생산수량 × 표준 원단위.
5. 차이 — 원가 차이 = 배부액 − 표준 에너지원가 = 사용량 차이 금액 + 단가 차이 금액.

마지막으로 월 청구 금액 = 월 배부액 + 월 미배부 손실액이 성립해야 합니다. 이 식이 R07이고, 풀 단위로 같은 식을 세운 것이 R01입니다.

점검 판정 규칙

판정 결과는 “점검 필요”와 “정상” 두 가지입니다. 원인을 단정하지 않고 확인할 자리만 알려 줍니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 줄바꿈되어 위아래로 쌓이고, 요약 타일은 두 줄로 접히며, 표는 가로 스크롤로 전환됩니다. 상세 창은 화면 너비에 맞춰 줄어듭니다. 데스크톱을 기준으로 설계했으며 태블릿에서도 쓸 수 있습니다.

파일 구성

index.html · Component.js · manifest.json
controller/  BaseController.js · Main.controller.js
view/        Main.view.xml · DetailDialog.fragment.xml
model/       formatter.js · ErrorHandler.js
css/         style.css
i18n/        i18n_ko.properties
service/     서비스 정의 · 샘플 데이터 6종

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 에너지 비용의 전기·배부·원가 분석은 표준에 그대로 두고, 그 결과를 청구서와 계량기와 표준 원단위 위에서 다시 맞춰 보는 자리만 이어 붙였습니다.

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

T-code 별 연계 지점

운영 전환 시 기존 리포트를 없앨 필요는 없습니다. 법정·감사 대응은 표준 보고서와 원장에 남겨 두고, 이 앱은 월마감 전에 이상한 풀과 오더를 먼저 골라내는 조회 전용 화면으로 곁에 둡니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 임의의 축으로 합계를 돌려 보는 데 강합니다. 이 앱은 그 위에서 “청구서 = 계량 + 손실”과 “배부 = 실적 사용량 × 단가”라는 업무 규칙을 판정 코드로 올려 둔 점검 화면입니다. 같은 CDS 큐브를 두 곳이 함께 쓰면 분석 쿼리와 이 앱의 숫자가 갈라지지 않습니다.

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

분석 지표 정의표

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 판정은 점검 도구의 결과이며 최종 판단은 회사와 감사인이 합니다.

CDS 구성

화면이 부르는 OData 서비스는 아래 CDS 뷰 위에 올라갑니다. 청구 금액·계량 수량·표준 원단위를 서로 다른 뷰에서 받아 큐브에서 한 번만 계산하고, 화면·CSV·분석 쿼리가 모두 같은 큐브를 쓰도록 나눴습니다. 표준 CDS 뷰 이름은 확인된 것만 쓰고, 확인하지 못한 곳은 원천 테이블 기준으로 적고 “확인 필요”로 남겼습니다.

뷰 레이어 구성

① 표준 원단위 · 한도 기준 테이블 — 값은 코드가 아니라 테이블에 둔다

표준 원단위는 품목 · 작업장마다, 기간마다 다르고 한도는 에너지원마다 다릅니다. 이 값이 코드에 박혀 있으면 설비를 바꿀 때마다 개발이 필요합니다. 두 개의 기준 테이블로 나누면 현업이 값만 바꿔 같은 쿼리를 다시 돌릴 수 있고, 값이 비어 있을 때 표준 사용량이 0 으로 계산되는 문제를 점검 코드로 걸러낼 수 있습니다.

" ───────────────────────────────────────────────
" 표준 원단위 기준 — 품목 · 작업장 · 에너지원 · 유효시작일
" 표준 사용량 = 생산수량 × 표준 원단위 의 원단위를 둔다
" 값을 기간별로 관리하고 코드에 박지 않기 위해 나눈다
" ───────────────────────────────────────────────
@EndUserText.label : '에너지 표준 원단위'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zenergy_std {
  key client     : abap.clnt not null;
  key matnr      : matnr not null;
  key arbpl      : arbpl not null;
  key energy_typ : abap.char(5) not null;   " 전력 · 스팀 · 도시가스 · 압축공기
  key valid_from : datum not null;
  std_intensity  : abap.dec(9,3);           " 제품 1개당 표준 사용량
  std_rate       : abap.curr(11,2);         " 표준 단가
  waers          : waers;
}

@EndUserText.label : '에너지원별 손실률 한도'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zenergy_lim {
  key client     : abap.clnt not null;
  key energy_typ : abap.char(5) not null;
  key valid_from : datum not null;
  loss_limit     : abap.dec(5,2);           " 손실률 한도(%)
  share_limit    : abap.dec(5,2);           " 품목 에너지 비중 한도(%)
}

② 차원 뷰 — 작업장

작업장 이름과 플랜트는 작업장 마스터(CRHD)에서 읽습니다. 집계 뷰가 마스터를 직접 조인하지 않도록 차원 뷰로 분리하면, 작업장 이름이 바뀌어도 한 곳만 고치면 됩니다.

" ───────────────────────────────────────────────
" ZI_EnergyWorkCenter — 작업장 차원
" 작업장 마스터를 한 번만 읽어 이름과 플랜트를 내준다
" 집계 뷰가 마스터 구조를 모르게 하기 위해 나눈다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Energy work center'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #MASTER }
define view entity ZI_EnergyWorkCenter
  as select from crhd
{
  key crhd.werks as Plant,
  key crhd.arbpl as WorkCenter,
      crhd.objid as WorkCenterObjectId,
      crhd.verwe as WorkCenterCategory
}
-- 작업장 이름은 텍스트 테이블(CRTX)에서 연결한다. 표준 CDS 뷰 이름은 확인 필요

③ 청구 풀 뷰 — 월 × 에너지원 청구 금액과 청구 수량

청구서의 금액과 수량을 월 · 에너지원 단위로 모읍니다. 에너지원은 요금 계정 번호로 가르고, 어느 계정이 어느 에너지원인지는 매핑 테이블로 둡니다. 이 뷰의 합계가 청구 금액이며 대사식 R01의 좌변이 됩니다.

" ───────────────────────────────────────────────
" ZI_EnergyBillPool — 에너지원 청구 풀
" 월 · 에너지원별 청구 금액과 청구 수량을 모은다
" 청구서와 계량기를 같은 뷰에서 섞지 않으려고 따로 둔다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Energy billing pool'
@Analytics.dataCategory: #FACT
define view entity ZI_EnergyBillPool
  as select from I_JournalEntryItem as je
  inner join zenergy_acct as ac
    on  ac.gl_account = je.GLAccount
{
  key je.FiscalYear                 as FiscalYear,
  key je.FiscalPeriod               as FiscalPeriod,
  key ac.energy_typ                 as EnergyType,
      je.CompanyCodeCurrency        as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( je.AmountInCompanyCodeCurrency ) as BillAmount,
      @Semantics.quantity.unitOfMeasure: 'BaseUnit'
      sum( je.Quantity )            as BillQuantity,
      je.BaseUnit                   as BaseUnit
}
where je.Ledger = '0L'
group by je.FiscalYear, je.FiscalPeriod, ac.energy_typ,
         je.CompanyCodeCurrency, je.BaseUnit
-- 에너지 요금 계정 매핑 테이블(zenergy_acct)은 회사 계정 체계에 맞춰 만든다.
-- 전표 라인의 수량 필드 채움 여부는 회사별로 달라 확인 필요

④ 계량 수량 뷰 — 하위 계량기의 측정값

하위 계량기의 측정값은 측정 포인트와 측정 문서에서 읽어 오더에 나눕니다. 이 수량의 합이 청구 수량보다 작으면 그 차이가 손실이므로, 풀 대사의 가장 중요한 입력입니다.

" ───────────────────────────────────────────────
" ZI_EnergyMeterQty — 하위 계량 수량
" 측정 문서의 읽은 값을 월 · 에너지원 · 오더로 모은다
" 계량 수량이 비는 에너지원을 이 뷰에서 바로 드러내기 위해 따로 둔다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Energy meter quantity'
define view entity ZI_EnergyMeterQty
  as select from imrg
  inner join zenergy_pnt as pt
    on  pt.point = imrg.point
{
  key left( imrg.idate, 4 )         as FiscalYear,
  key substring( imrg.idate, 5, 2 ) as FiscalPeriod,
  key pt.energy_typ                 as EnergyType,
  key pt.aufnr                      as OrderNumber,
      @Semantics.quantity.unitOfMeasure: 'Unit'
      sum( imrg.recdc )             as MeterQuantity,
      imrg.recdu                    as Unit
}
group by left( imrg.idate, 4 ), substring( imrg.idate, 5, 2 ),
         pt.energy_typ, pt.aufnr, imrg.recdu
-- 측정 포인트 ↔ 오더 연결(zenergy_pnt)은 회사 운영 방식에 맞춰 둔다.
-- 측정 문서의 표준 CDS 뷰 이름과 필드는 확인 필요 (원천 테이블 기준으로 적음)

⑤ 큐브 — 오더 라인 배부액과 표준 에너지원가

배부액 · 표준 에너지원가 · 사용량 차이 · 단가 차이를 한 곳에서만 계산합니다. 화면 · CSV · 분석 쿼리가 이 큐브의 같은 값을 쓰기 때문에, 세 곳의 숫자가 어긋날 자리가 없습니다. 판정에 쓰는 차이율도 여기서 구해 둡니다.

" ───────────────────────────────────────────────
" ZI_EnergyAllocCube — 오더 라인 배부 큐브
" 배부액 · 표준 에너지원가 · 사용량/단가 차이를 한 번만 계산한다
" 계산을 한 곳에 두어 화면 · CSV · 분석 쿼리가 같은 숫자를 쓴다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Energy allocation cube'
@Analytics.dataCategory: #CUBE
define view entity ZI_EnergyAllocCube
  as select from ZI_EnergyMeterQty as mq
  inner join ZI_EnergyBillPool as bp
    on  bp.FiscalYear   = mq.FiscalYear
    and bp.FiscalPeriod = mq.FiscalPeriod
    and bp.EnergyType   = mq.EnergyType
  inner join zenergy_std as st
    on  st.energy_typ = mq.EnergyType
{
  key mq.FiscalYear,
  key mq.FiscalPeriod,
  key mq.EnergyType,
  key mq.OrderNumber,
      @Semantics.amount.currencyCode: 'Currency'
      bp.BillAmount / bp.BillQuantity * mq.MeterQuantity   as AllocAmount,
      @Semantics.amount.currencyCode: 'Currency'
      st.std_rate * st.std_intensity                       as StdAmountPerUnit,
      cast( mq.MeterQuantity as abap.dec(15,3) )           as ActualQuantity,
      bp.Currency
}
-- 생산수량(AFPO)과 표준 원단위를 곱한 표준 사용량은 쿼리 레이어의 계산 필드로 둔다.
-- 청구 단가 = 청구 금액 ÷ 청구 수량 이므로 수량이 0 인 풀은 제외한다(확인 필요)

⑥ 소비 뷰 — 판정 코드를 붙여 서비스로 내보낸다

큐브의 숫자에 점검 판정 코드를 붙여 화면에 내보냅니다. 판정 조건을 이 뷰 한 곳에만 두면 화면과 CSV, 분석 쿼리가 같은 “점검 필요”를 보여 줍니다. 화면 전용 필드와 필터 주석도 여기에 둡니다.

" ───────────────────────────────────────────────
" ZC_EnergyCheckQuery — 배부 점검 소비 뷰
" 사용량 차이율로 E01/E02, 풀 손실률로 P01 을 판정해 UI 주석과 함께 내보낸다
" 판정 조건을 한 곳에 두려고 큐브와 분리한다
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Energy allocation check'
@Metadata.allowExtensions: true
@Consumption.ranked: true
define view entity ZC_EnergyCheckQuery
  as select from ZI_EnergyAllocCube as cube
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key cube.FiscalYear,
  @Consumption.filter: { selectionType: #INTERVAL }
  key cube.FiscalPeriod,
  @Consumption.filter.selectionType: #SINGLE
  key cube.EnergyType,
  key cube.OrderNumber,
      cube.AllocAmount,
      cube.ActualQuantity,
      case
        when cube.StdQuantity = 0                                    then 'E00'
        when cube.ActualQuantity > cube.StdQuantity * 1.10          then 'E01'
        when cube.ActualQuantity < cube.StdQuantity * 0.90          then 'E02'
        else ''
      end                                                           as CheckCode
}

⑦ 접근 제어(DCL) — 권한은 집계 단계에서 건다

단가와 사용량이 함께 보이므로 플랜트 단위로 조회 권한을 나눕니다. 권한은 소비 뷰가 아니라 큐브의 입력에서 걸어야 합계로 새지 않습니다. 화면 쪽에서 가리는 것은 보안이 아닙니다.

" ───────────────────────────────────────────────
" ZC_EnergyCheckQuery 접근 제어
" 플랜트 권한이 있는 사용자만 해당 플랜트의 배부 점검을 본다
" 집계 후가 아니라 집계 입력 단계에서 걸어야 합계로 새지 않는다
" ───────────────────────────────────────────────
@EndUserText.label: 'Energy allocation check access'
@MappingRole: true
define role ZC_EnergyCheckQueryRole {
  grant select on ZC_EnergyCheckQuery
    where ( Plant ) = aspect pfcg_auth( K_CCA, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩 — OData V2 로 게시

화면은 서비스 한 곳만 부릅니다. 서비스 정의에서 노출할 뷰를 고르고, 바인딩에서 OData V2 로 게시합니다. 노출 이름이 곧 화면의 엔티티셋 이름이 되므로, 이름은 한 번 정하면 바꾸지 않는 편이 안전합니다.

" ───────────────────────────────────────────────
" 서비스 정의 · 바인딩
" 화면이 부르는 엔티티셋을 정한다
" 서비스 한 곳으로 모아 운영 전환 때 주소만 바꾸게 한다
" ───────────────────────────────────────────────
@EndUserText.label: 'Energy allocation check service'
define service ZI_EnergyAllocCheckSrv {
  expose ZC_EnergyCheckQuery as LineSet;
  expose ZI_EnergyBillPool   as PoolSet;
  expose ZI_EnergyWorkCenter as WcSet;
}
-- 바인딩: OData V2 - UI. 게시 후 서비스 주소를 화면 manifest 에 선언한다.

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

전표가 수천만 건이면 오더 라인 단위로 매번 전체를 집계할 수 없습니다. 회계연도와 기간을 필수 조건으로 두고, 풀 집계는 월 단위로 미리 모아 두며, 큐브는 키 필드 위에 인덱스를 두어 조회 범위를 좁힙니다. 응답 시간 기준(예: 월 1개 기간 조회가 수 초 안)은 도입 단계에서 합의하는 항목이고, 이 글의 수치는 검증용 샘플 기준이라 운영 성능을 보장하지 않습니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석과 대사

도입과 운영