활동기준원가(ABC) 드라이버 점검 — 관리회계, 쓴 만큼 제품에 나눈 배부액과 놀고 있는 용량의 원가를 월마감 전에 맞춰 보는 화면

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

제조 원가를 월마감에서 점검하는 사람은 해마다 같은 질문을 받습니다. 간접비를 제품에 나눈 방식이 정말 제품이 쓴 만큼인가, 설비와 인력은 얼마나 놀고 있나, 지난달과 달라진 단가는 왜 달라졌나. 지금은 이 세 답이 표준 배부 결과 · 코스트센터 보고서 · 밤새 만든 엑셀로 나뉘어 있어, 숫자가 어긋나면 어디서 갈렸는지부터 찾아야 합니다.

활동기준원가(ABC)는 이 질문에 답하는 방법입니다. 간접비를 활동별 비용풀로 모으고, 활동마다 비용풀 ÷ 실용 용량으로 드라이버율(원/드라이버)을 구한 뒤, 제품이 쓴 드라이버량에 곱해 나눕니다. 직접노무시간 하나로 나누던 방식과 달리 “검사를 많이 받은 제품이 검사 비용을 더 진다”는 원리가 숫자에 들어갑니다. 이 화면은 그 결과를 월마감 전에 점검하는 자리입니다. 활동별 가동률 · 미사용 용량 원가 · 드라이버율 변동을 한 표에 놓고, 제품별로는 활동기준 배부액이 기존 방식과 얼마나 벌어졌는지 견줍니다. 관련 기준서가 따로 정해진 영역이 아니므로 대상 영역은 관리회계(활동기준원가)로 적습니다.

직접노무시간으로 나누면 쉬는 설비의 원가가 제품에 얹힌다

직접노무시간 비례 배부는 비용풀 전액을 그 달 제품에 나눕니다. 설비가 절반만 돌아도 설비 비용 전액이 제품에 실립니다. 그러면 단위원가가 가동률에 따라 오르내리고, 제품이 잘못된 신호를 받습니다. ABC 방식은 쓴 만큼만 제품에 나누고 나머지를 미사용 용량 원가로 따로 세웁니다. 이 자료의 6개월 합계로 보면 활동 비용풀 18.69억 중 제품 배부액은 15.36억이고 3.33억(17.8%)이 미사용 용량 원가로 남습니다. 기존 방식이라면 이 3.33억도 제품에 얹혔을 금액입니다.

가동률이 100%를 넘거나 60%에 못 미치면 드라이버율을 의심한다

드라이버율은 분모인 실용 용량에 민감합니다. 월 용량을 4,000회로 잡았는데 실제로 4,330회를 썼다면 가동률은 108%이고, 용량 산정이나 드라이버 집계 범위가 틀렸을 가능성이 큽니다. 반대로 52%만 쓴 활동은 용량이 과하거나 수요가 줄었다는 신호입니다. 이 화면은 가동률 100% 초과(L01) · 60% 미만(L02)을 점검 필요로 올리고, 어느 쪽이든 원인은 단정하지 않고 확인할 일만 적어 줍니다.

드라이버율이 갑자기 오르면 단위원가가 따라 움직인다

드라이버율은 비용풀이 같아도 용량이 바뀌면 달라지고, 용량이 같아도 비용풀이 바뀌면 달라집니다. 전월 대비 15% 이상 달라진 활동(L03)은 비용풀 변동 항목과 용량 변경 여부를 먼저 봅니다. 이 자료에서는 5월 주문 처리 활동의 드라이버율이 전월보다 20.65% 올라 이 조건에 걸립니다.

제품마다 기존 방식과의 차이가 같지 않다

ABC로 바꾸면 모든 제품이 같은 비율로 달라지지 않습니다. 직접노무시간은 적게 쓰지만 검사 · 셋업 · 설계 변경을 많이 쓰는 제품은 원가가 오르고, 그 반대인 제품은 내립니다. 이 화면은 기존 방식 대비 배부액 차이율이 45% 이상인 제품을 점검 필요로 올리고, 제품 행을 누르면 어느 활동에서 차이가 났는지 활동별로 펼쳐 줍니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도는 필수이고, 전기 월 범위 · 활동 · 제품 · 점검 결과는 선택입니다. ‘전체’를 고르면 그 조건은 걸리지 않습니다.
2. 조회 버튼(조회조건 오른쪽 끝) 또는 입력 칸에서 Enter 키를 누릅니다. 처음 열면 자동으로 한 번 조회합니다.
3. 요약 지표에서 비용풀 · 배부액 · 미사용 용량 원가 · 평균 가동률과 점검 필요 활동 · 제품 건수, 대사 차이 건수를 먼저 봅니다.
4. 탭을 활동 · 드라이버율 → 제품별 원가 비교 → 월별 추이 → 대사 결과 순서로 옮겨 가며 확인합니다.
5. 활동 행이나 제품 행을 누르면 상세 창이 열려 제품별(또는 활동별) 드라이버 사용량 · 배부액 · 기존 방식 배부액 · 차이가 나옵니다.
6. CSV 내려받기 버튼으로 현재 탭의 조회 결과를 UTF-8 CSV로 받아 엑셀로 이어 갑니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 화면을 만들기 전에 대사식 여섯 개를 먼저 세우고 자료 전수에 돌렸습니다.

여섯 대사식 모두 차이 건수 0건입니다(검사 222건). R03과 R06의 최대 차이는 드라이버율을 소수 4자리, 단위원가를 소수 2자리로 반올림한 데서 생기는 값이며 허용 오차를 넘은 건은 없습니다. 이와 별도로 판정 기준에 걸리는 건을 일부러 넣었습니다. 점검 필요 활동 4건(가동률 100% 초과 2건 · 60% 미만 1건 · 드라이버율 15% 이상 변동 1건)과 점검 필요 제품 6건(기존 방식 대비 배부액 차이율 45% 이상)이며, 이 건들은 대사 차이가 아니라 점검 대상이라 차이 건수에 넣지 않았습니다.

무엇으로 만들었나

실행 화면

아래 화면은 가상의 계정체계와 가상의 제품명으로 만든 검증용 자료(2026년 1~6월)를 실제로 조회한 모습입니다. 활동 7종 × 제품 8종 × 6개월이며, 실제 고객사 값이 아닙니다.

처음 열었을 때

열면 자동으로 한 번 조회해, 조회조건 아래에 요약 지표 일곱 개와 활동별 드라이버율 명세가 한꺼번에 보입니다.

맨 위 조회조건은 회계연도 · 전기 월 시작/종료 · 활동 · 제품 · 점검 결과 여섯 칸이고, 기본값은 2026년 전체입니다. 그 아래 요약 지표는 활동 비용풀 합계 · 제품 배부액 합계 · 미사용 용량 원가 · 평균 가동률 · 점검 필요 활동 · 점검 필요 제품 · 대사 차이 건수 순서이며 금액은 백만 원 단위로 보입니다. 미사용 용량 원가와 점검 필요 건수는 경고색으로 눈에 띄게 하고, 표는 활동 · 월별 비용풀 · 실용 용량 · 사용량 · 가동률 · 드라이버율 · 배부액 · 미사용 용량 원가 · 판정을 한 줄에 보여 줍니다.

점검 필요 활동과 활동 상세

점검 결과를 ‘점검 필요’로 좁히면 확인할 활동만 남고, 그 행을 누르면 제품별 사용량이 열립니다.

점검 필요 활동은 네 건입니다. 3월 기계 가동 활동은 가동률이 52.60%라 미사용 용량 원가가 5,590만 원으로 커졌고, 4월 설비 셋업은 108.33%로 용량을 넘겨 썼으며, 5월 주문 처리는 드라이버율이 전월보다 20.65% 올랐고, 6월 설계 변경 관리는 112.22%입니다. 판정 칸에는 조건 코드(L01~L03)와 확인할 일이 함께 적힙니다. 이 화면은 원인을 단정하지 않고 “용량 산정과 드라이버 집계 범위를 확인”처럼 다음 행동만 안내합니다.

활동 행을 누르면 그 활동을 제품 여덟 종이 얼마나 썼는지가 열립니다. 제품마다 드라이버 사용량 · 드라이버율 · 활동기준 배부액 · 직접노무시간 · 기존 방식 배부액 · 차이가 나란히 있어, 같은 비용풀을 두 방식이 어떻게 다르게 나눴는지 한눈에 비교됩니다. 제품별 배부액을 모두 더하면 그 활동의 배부액과 같아야 하며, 이는 대사식 R01로 검산됩니다.

제품별 원가 비교

두 번째 탭은 같은 달 같은 제품에 두 방식이 매긴 배부액을 견줍니다.

제품마다 직접비 · 활동기준 배부액 · 기존 방식 배부액 · 활동기준 총원가 · 단위원가 · 차이율이 한 줄입니다. 차이율은 (활동기준 − 기존) ÷ 기존 × 100이며 음수면 활동기준이 더 적게 배부했다는 뜻입니다. 45% 이상(절댓값) 벌어진 제품 여섯 건이 점검 필요로 표시되고, 이 자료에서는 구동 모터 L이 다섯 달, 구동 모터 S가 3월에 걸립니다. 제품 조건은 이 탭과 상세에만 적용됩니다.

제품 행을 누르면 그 제품이 쓴 활동별 사용량과 배부액 차이가 열립니다. 차이가 어느 활동에서 생겼는지 확인하는 자리입니다. 직접노무시간 비중은 큰데 셋업이나 검사 같은 활동은 적게 쓴 제품이 기존 방식에서 과하게 배부받았다는 사실이 이 표에서 활동 단위로 드러납니다.

월별 추이와 대사 결과

나머지 두 탭은 달 단위로 묶어 보는 자리와 숫자를 믿어도 되는지 확인하는 자리입니다.

월별 비용풀 · 배부액 · 미사용 용량 원가 · 평균 가동률 · 점검 필요 건수가 한 줄씩입니다. 3월에는 미사용 용량 원가가 8,974만 원으로 가장 크고 평균 가동률이 77.34%로 가장 낮으며, 4월에는 가동률이 91.98%까지 올라 미사용 원가가 2,012만 원으로 줄어듭니다. 달마다 어떤 활동이 평균을 움직였는지는 첫 탭에서 월 범위를 좁혀 이어서 봅니다.

여섯 대사식마다 검사 건수 · 좌변과 우변 합계 · 차이 건수 · 최대 차이가 나옵니다. 차이 건수 칸은 0이면 정상색, 0이 아니면 경고색으로 바뀌어 그 숫자는 원천을 확인하라는 신호가 됩니다. R03과 R06의 최대 차이는 반올림에서 오는 값이라 허용 오차 안에 있습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터로 바꿔 서비스에 요청하고, 받은 결과를 탭마다 다른 표에 바인딩합니다. 활동 탭 · 제품 탭 · 월 탭 · 대사 탭이 각자 자기 데이터 묶음을 읽고, 행을 누르면 상세 창이 활동별(또는 제품별) 사용량 묶음을 따로 불러옵니다. 계산은 모두 서비스가 하고 화면은 값을 읽어 보여 주기만 합니다.

판정 기준 값(100%, 60%, 15%, 45%)은 회사 정책에 맞춰 바꿔 쓰는 값입니다. 회계 기준이 정한 숫자가 아니므로, 도입할 때 관리회계 담당이 정하면 됩니다.

조회조건

같은 항목에 시작과 끝을 따로 걸면 한 묶음으로 만들어 and로 이어 보냅니다. 서버마다 괄호 속 or를 해석하는 방식이 달라, 범위 조건을 or로 보내지 않도록 맞췄습니다.

결과 컬럼

좁은 화면에서 달라지는 것

조회조건 칸과 요약 지표는 폭이 좁아지면 다음 줄로 이어지고, 표는 고정 높이 안에서 가로로 밀어 볼 수 있습니다. 숫자 열이 많은 표라 좁은 화면에서는 가로로 밀어 보는 것이 기본이고, 월마감 점검은 노트북 폭을 기준으로 맞췄습니다.

파일 구성

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/         style.css
i18n/        i18n_ko.properties
odata/       메타데이터 정의 · 서비스 구현 · 엔티티셋별 샘플 데이터
media/       소개 영상 · 포스터

검증용 화면과 샘플은 별도 폴더에 두었고 앱 본체는 그 폴더를 읽지 않습니다. 화면 코드 안에는 샘플 값이나 목업 코드가 없습니다.

SAP 표준 기능 확장 포인트

배부를 실행하고 전기하는 일은 SAP 표준 T-code가 담당하고, 이 화면은 그 결과를 조회 · 검증하는 관점을 더해 확장합니다. 표준 화면을 없애는 것이 아니라, 표준 화면 사이를 오가며 하던 대조를 한 화면으로 모읍니다.

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

T-code 별 연계 지점

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

S/4HANA에서는 CDS 뷰 위에 분석 쿼리를 만들고, Fiori 분석 앱이나 Analysis for Office로 읽는 구성이 일반적입니다. 이 앱은 그 구성과 경쟁하지 않고 같은 CDS 뷰를 OData 서비스로 노출하는 자리에 놓입니다. 분석 쿼리는 임의로 축을 바꿔 보는 데 좋고, 이 화면은 정해진 판정 기준으로 이상한 활동 · 제품만 골라 보여 주는 데 맞춰 둔 것입니다. 같은 비용풀 · 사용량 뷰를 공유하므로 두 화면의 숫자는 갈라지지 않습니다.

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

분석 지표 정의표

이 화면은 회계 기준서의 요구사항을 점검하는 도구가 아니라 관리회계 지표를 점검하는 도구이므로, 요구사항 매핑표 대신 지표 정의표를 둡니다.

CDS 구성

아래는 이 화면이 읽는 값을 S/4HANA의 CDS 뷰로 세울 때의 구성 예시입니다. 객체 이름과 필드는 이 글에서 새로 지은 것이고, 표준 테이블(ACDOCA · CSKS)과 표준 필드 이름만 실재하는 것을 썼습니다. 표준 CDS 뷰를 대신 쓰는 경우 뷰 이름은 확인 필요입니다.

뷰 레이어 구성

① 활동 매핑 테이블 — 비용풀의 경계를 데이터로 둔다

어느 코스트센터의 비용이 어느 활동 비용풀로 들어가는지가 ABC 점검의 출발점입니다. 이 경계를 코드에 박으면 조직이 바뀔 때마다 개발자를 불러야 하므로 고객 유지 테이블로 둡니다. 실용 용량도 월 계획값으로 이 옆에 둡니다.

" ────────────────────────────────────────────────────────────────
"  ZABC_ACTMAP — 활동 매핑 (투명 테이블)
"  코스트센터 → 활동 비용풀의 경계를 데이터로 둔다.
"  이렇게 나눈 이유 : 활동은 늘 늘어나고, 늘 때마다 개발자를 부르면
"  점검 도구가 금방 낡는다. SM30 유지보수 뷰를 함께 만든다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : 'ABC 활동 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zabc_actmap {
  key mandt        : mandt not null;
  key kokrs        : kokrs not null;      " 관리회계 영역
  key activity     : abap.char(4) not null;
  key kostl        : kostl not null;      " 코스트센터
  act_name         : abap.char(40);
  driver_code      : abap.char(4);        " 원가 드라이버
  driver_unit      : abap.unit(3);
  practical_cap    : abap.dec(13,0);      " 월 실용 용량
  valid_from       : abap.dats;
  valid_to         : abap.dats;
}

② 비용풀 뷰 — ACDOCA에서 활동별 월 비용을 모은다

비용풀은 매핑 테이블이 정한 코스트센터의 비용을 월 단위로 더한 값입니다. 여기서 정해지는 것은 어느 계정을 간접비로 보느냐인데, 운영에서는 계정 범위를 사내 원가 체계에 맞춰야 하므로 조건을 한 곳(WHERE)에 모아 둡니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AbcPoolCost — 활동별 월 비용풀
"  표준 ACDOCA 의 코스트센터 비용을 매핑 기준으로 더한다.
"  계정 범위 조건은 사내 원가 체계에 맞춰 바꾼다 (확인 필요).
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : 'ABC 활동 비용풀'
define view entity ZI_AbcPoolCost
  as select from acdoca as j
    inner join   zabc_actmap as m
      on  m.kostl = j.rcntr
      and m.kokrs = j.kokrs
{
  key j.rldnr                      as Ledger,
  key j.rbukrs                     as CompanyCode,
  key j.gjahr                      as FiscalYear,
  key j.poper                      as PostingPeriod,
  key m.activity                   as Activity,
      m.act_name                   as ActivityName,
      m.driver_code                as DriverCode,
      @Semantics.currencyCode: true
      j.rhcur                      as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( j.hsl )                 as PoolCost,
      m.practical_cap              as PracticalCapacity
}
where j.rldnr = '0L'
  and j.drcrk = 'S'
group by j.rldnr, j.rbukrs, j.gjahr, j.poper,
         m.activity, m.act_name, m.driver_code, j.rhcur, m.practical_cap

③ 드라이버 사용량 뷰 — 제품이 쓴 양을 한 모양으로 맞춘다

드라이버 수량은 원천이 활동마다 다릅니다. 셋업 횟수는 생산 확인에서, 검사 건수는 검사 로트에서 옵니다. 위쪽 뷰가 원천을 몰라도 되도록 이 뷰에서 “기간 · 활동 · 제품 · 사용량” 모양으로 맞춥니다. 아래는 사용량을 적재 테이블에 모아 두는 방식이며, 원천별 UNION으로 바꿀 수도 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AbcDriverQty — 제품별 드라이버 사용량
"  원천 (AFRU · QALS · VBAP · LIKP · MSEG 등) 은 활동마다 다르다. 확인 필요.
"  이 뷰가 한 모양으로 맞추므로 위쪽 뷰는 원천을 모른다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : 'ABC 드라이버 사용량'
define view entity ZI_AbcDriverQty
  as select from zabc_drvqty as q
{
  key q.gjahr      as FiscalYear,
  key q.poper      as PostingPeriod,
  key q.activity   as Activity,
  key q.matnr      as Product,
      @Semantics.quantity.unitOfMeasure: 'DriverUnit'
      q.driver_qty as DriverQty,
      q.driver_unit as DriverUnit,
      q.dl_hours   as DirectLaborHours     " 기존 방식 비교용
}

④ 풀 큐브 — 드라이버율과 가동률이 정해지는 자리

핵심 계산이 여기 있습니다. 드라이버율은 비용풀을 실용 용량으로 나눈 값이고, 용량이 0인 활동은 0으로 나누지 않도록 걸러 냅니다. 미사용 용량 원가는 비용풀에서 배부액을 뺀 값이라 음수가 되면 용량을 넘겨 배부했다는 뜻입니다. 전월 드라이버율은 같은 활동의 직전 기간 행을 association으로 붙여 변동률을 구합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AbcPoolCube — 드라이버율 · 가동률 · 미사용 원가
"  드라이버율 = 비용풀 / 실용 용량  (소수 4자리)
"  가동률    = 사용량 / 실용 용량 * 100
"  미사용    = 비용풀 - 제품 배부액 합계  (음수 = 용량 초과 배부)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : 'ABC 풀 큐브'
define view entity ZI_AbcPoolCube
  as select from ZI_AbcPoolCost as pool
  association [0..*] to ZI_AbcUsageAlloc as _usage
    on  _usage.FiscalYear    = pool.FiscalYear
    and _usage.PostingPeriod = pool.PostingPeriod
    and _usage.Activity      = pool.Activity
{
  key pool.FiscalYear,
  key pool.PostingPeriod,
  key pool.Activity,
      pool.ActivityName,
      pool.Currency,
      @Semantics.amount.currencyCode: 'Currency'
      pool.PoolCost,
      pool.PracticalCapacity,
      cast( case when pool.PracticalCapacity > 0
                 then pool.PoolCost / pool.PracticalCapacity
                 else 0 end as abap.dec(15,4) )        as DriverRate,
      @Aggregation.default: #SUM
      _usage.AbcAlloc                                   as AllocAmount,
      _usage
}

⑤ 배부 뷰 — 제품별 활동기준 배부액과 기존 방식 배부액

같은 비용풀을 두 방식으로 나눕니다. 활동기준은 사용량에 드라이버율을 곱하고, 기존 방식은 직접노무시간 비례로 나눕니다. 두 값을 같은 행에 두어야 차이율을 뷰에서 바로 계산할 수 있고, 대사식도 이 행 위에서 세울 수 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AbcUsageAlloc — 제품 × 활동 배부
"  ABC 배부액  = 사용량 * 드라이버율  (원 단위 반올림)
"  기존 배부액 = 비용풀 * 직접노무시간 / Σ직접노무시간
"  두 값을 한 행에 둬야 차이를 이 행에서 계산하고 대사할 수 있다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : 'ABC 제품 활동 배부'
define view entity ZI_AbcUsageAlloc
  as select from ZI_AbcDriverQty as u
    inner join   ZI_AbcPoolCost  as p
      on  p.FiscalYear    = u.FiscalYear
      and p.PostingPeriod = u.PostingPeriod
      and p.Activity      = u.Activity
{
  key u.FiscalYear,
  key u.PostingPeriod,
  key u.Activity,
  key u.Product,
      u.DriverQty,
      u.DirectLaborHours,
      @Semantics.amount.currencyCode: 'Currency'
      cast( round( u.DriverQty * ( p.PoolCost / p.PracticalCapacity ), 0 )
            as abap.curr(15,0) )                          as AbcAlloc,
      p.Currency
}

⑥ 활동 점검 쿼리 — 판정 코드를 붙여 서비스로 내보낸다

화면이 직접 부르는 뷰입니다. 가동률 · 드라이버율 변동 임계값을 기준표에서 읽어 판정 코드(L01~L03)를 만들고, 조회조건이 되는 필드에는 필터 주석을 붙입니다. 판정 로직이 여기 있으니 임계값을 바꿀 때는 기준표 한 줄만 고치면 됩니다.

" ────────────────────────────────────────────────────────────────
"  ZC_AbcPoolCheck — 활동 점검 소비 뷰
"  판정: L01 가동률>상한 · L02 가동률<하한 · L03 |드라이버율 변동|>=기준
"  임계값은 기준표(ZABC_THRESH)에서 읽는다. 코드에 박지 않는다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : 'ABC 활동 점검'
@Metadata.allowExtensions : true
define view entity ZC_AbcPoolCheck
  as select from ZI_AbcPoolCube as c
    left outer join zabc_thresh as t
      on t.kokrs = '1000'
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key c.FiscalYear,
  @Consumption.filter.selectionType: #INTERVAL
  key c.PostingPeriod,
  @Consumption.filter.selectionType: #SINGLE
  key c.Activity,
      c.ActivityName,
      c.PoolCost,
      c.PracticalCapacity,
      c.DriverRate,
      case when c.UtilRate > t.util_max then 'L01'
           when c.UtilRate < t.util_min then 'L02'
           when abs( c.RateChgPct ) >= t.rate_chg then 'L03'
           else 'I00' end                      as CheckCode
}

⑦ 제품 비교 쿼리 — 두 방식의 차이율을 계산한다

제품 탭의 원천입니다. 제품 월 단위로 활동기준 총원가와 기존 방식 총원가를 만들고 차이율을 구합니다. 분모가 되는 기존 배부액이 0이면 차이율을 계산하지 않고 비워 두어, 없는 값을 0%로 읽는 일을 막습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_AbcProductCompare — 제품 월 비교
"  총원가 = 직접비 + Σ 활동별 배부액,  단위원가 = 총원가 / 생산수량
"  차이율 = (ABC 배부액 - 기존 배부액) / 기존 배부액 * 100
"  기존 배부액이 0 이면 차이율은 비운다 (0% 로 오해하지 않게).
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : 'ABC 제품 비교'
define view entity ZC_AbcProductCompare
  as select from ZI_AbcUsageAlloc as a
    inner join   zabc_prodcost    as d
      on  d.gjahr = a.FiscalYear
      and d.poper = a.PostingPeriod
      and d.matnr = a.Product
{
  key a.FiscalYear,
  key a.PostingPeriod,
  key a.Product,
      d.direct_cost                              as DirectCost,
      sum( a.AbcAlloc )                          as AbcAlloc,
      sum( a.BasicAlloc )                        as BasicAlloc,
      cast( case when sum( a.BasicAlloc ) <> 0
                 then ( sum( a.AbcAlloc ) - sum( a.BasicAlloc ) )
                      * 100 / sum( a.BasicAlloc )
                 end as abap.dec(7,2) )          as DiffPercent
}
group by a.FiscalYear, a.PostingPeriod, a.Product, d.direct_cost

⑧ 접근 제어와 서비스 정의 — 권한은 집계 단계에서 건다

권한을 드릴스루에만 걸면 합계에서 뺄셈으로 다른 조직의 비용이 드러날 수 있습니다. 그래서 비용풀을 만드는 첫 뷰에 회사코드 권한을 걸고, 서비스에는 소비 뷰 두 개만 내보냅니다.

" ────────────────────────────────────────────────────────────────
"  DCL · 서비스 정의
"  권한은 비용풀(집계 단계)에 건다. 드릴스루에만 걸면 합계 뺄셈으로 샌다.
"  서비스에는 소비 뷰만 노출한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : 'ABC 비용풀 접근 제어'
@MappingRole: true
define role ZI_AbcPoolCost {
  grant select on ZI_AbcPoolCost
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

@EndUserText.label : 'ABC 드라이버 점검 서비스'
define service ZUI_AbcDriverCheck {
  expose ZC_AbcPoolCheck      as PoolSet;
  expose ZC_AbcProductCompare as ProductSet;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

이 화면의 단위는 활동 × 제품 × 월입니다. 활동이 수십 개, 제품이 수천 개이면 사용량 뷰가 수십만 행이 되므로 제품 탭은 조회 기간과 제품 범위를 먼저 좁히게 하는 것이 좋습니다. 큐브의 비용풀 합계는 ACDOCA의 월 집계를 쓰면 전표 수천만 건이어도 활동 × 월 수준으로 줄어듭니다. 드라이버 수량은 원천 테이블을 매번 훑지 말고 월마감 직전에 적재 테이블로 한 번 모아 두는 쪽이 응답 시간이 안정적입니다. 응답 시간 기준(예: 활동 탭 3초 이내)은 도입 때 정해 두고, 넘는 조회는 기간 필수 조건으로 막습니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

판정과 분석

도입과 운영