보조부문 원가 배부방식 비교 점검 — 제조원가 분석, 직접·단계·상호배부로 다시 계산해 제조부문 원가가 얼마나 갈리는지 장부와 맞춰 보는 월마감 화면

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

제조 현장의 월마감에는 늘 같은 질문이 따라붙습니다. 동력·수선·품질관리·자재운반 같은 보조부문의 원가를 제조부문에 어떻게 나눴나, 다른 방식으로 나눴다면 제조부문 원가가 얼마나 달라졌을까, 장부에 남은 배부액은 다시 계산한 값과 맞나. 지금은 이 세 답이 SAP 배분·배부 결과 화면, 용역 수량을 적어 둔 엑셀, 방식별 시뮬레이션 파일에 흩어져 있어서 마감 때마다 사람이 맞춰야 합니다.

이 앱은 보조부문 원가를 직접배부 · 단계배부 · 상호배부 세 방식으로 같은 용역 수량에서 다시 계산해 제조부문·월마다 나란히 보여 줍니다. 방식 사이의 차이를 격차율로 가르고, 장부에 남은 단계배부액을 재계산 값과 1원 단위로 대조해 확인이 필요한 제조부문과 월만 골라 줍니다. 표준 배분·배부 실행은 SAP 표준 T-code 가 그대로 맡고, 이 화면은 그 결과를 조회·검증하는 관점을 더해 확장합니다. 이 분석은 특정 기준서를 적용하는 화면이 아니라 제조원가 분석 목적의 점검 도구이며, 배부 기준과 최종 판단은 회사와 감사인이 합니다.

배부 방식을 하나만 보는 리포트는 두 번째 질문에서 멈춘다

장부에는 한 가지 방식으로 나눈 결과만 남습니다. 그래서 “상호배부로 했다면 도장부문 원가가 얼마나 달랐을까” 같은 질문이 나오면 엑셀을 열어 용역 수량을 다시 붙이고 연립방정식을 새로 풀어야 합니다. 이 앱은 세 방식을 처음부터 같은 용역 수량 위에서 계산해 두므로, 같은 제조부문·월을 놓고 방식만 바꿔 가며 볼 필요가 없습니다. 한 행에 직접·단계·상호 배부액과 총원가가 나란히 놓입니다.

차이가 있다는 것과, 봐야 할 만큼 크다는 것은 다르다

세 방식은 보조부문 사이의 용역 주고받음이 작으면 비슷하고 커질수록 갈립니다. 하지만 모든 차이를 들여다볼 수는 없습니다. 이 앱은 제조부문·월마다 (세 방식 배부액의 최댓값 − 최솟값) ÷ 단계배부 총원가를 격차율로 계산하고, 허용 격차율(검증용 샘플에서는 1.00%)을 넘은 곳만 점검 필요로 표시합니다. 이 샘플에서는 27건 가운데 3건이 허용치를 넘었습니다. 가장 큰 곳은 7월 도장부문의 2.43% 입니다.

장부 배부액이 재계산과 다르면 어디서 갈렸는지 찾기가 어렵다

배분 사이클의 용역 수량이 월 중간에 바뀌었거나 전기 내역이 일부 빠지면, 장부의 단계배부액은 규칙대로 다시 계산한 값과 조금씩 어긋납니다. 합계만 보면 묻히는 차이입니다. 이 앱은 장부 단계배부액과 재계산 단계배부액의 차이를 배부 명세 한 줄 단위로 대조하고, 1원을 넘는 줄이 있으면 제조부문 행과 보조부문 행, 월 행까지 올라가며 점검 필요로 알립니다. 이 샘플에서는 세 줄(3월 수선→조립, 5월 동력→도장, 8월 품질관리→절단)이 그렇게 걸렸습니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 확인합니다. 제공 부문·제조부문·배부 방식·마감 월·마감일·점검 결과는 선택이며 비워 두면 전체입니다. 화면을 처음 열면 기본 조건으로 자동 조회됩니다.
2. 조회 버튼 또는 Enter — 조회조건 영역 가장 오른쪽의 조회 버튼을 누르거나, 입력 칸에서 Enter 키를 누릅니다. 초기화 버튼은 같은 줄에 있습니다.
3. 요약 확인 — 위쪽 여섯 개 타일(보조부문 원가 · 방식 간 격차 합계 · 최대 격차율 · 장부와 재계산 차이 합계 · 점검 필요 건수 · 대사 차이 건수)을 봅니다. 금액은 백만원 단위입니다.
4. 탭 이동 — 제조부문 비교 → 보조부문 잔액 → 배부 명세 → 월별 추이 → 대사 결과 순서로, 넓은 곳에서 근거까지 좁혀 갑니다.
5. 행 클릭 상세 — 행을 누르면 세 방식의 배부액·총원가·장부 배부액과 그 부문·월의 배부 명세가 방식별로 열립니다.
6. 내보내기 — 현재 탭의 조회 결과를 UTF-8 CSV 로 내려받습니다. 파일명은 기능명과 탭 이름입니다.

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

배부 화면에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 계산을 만드는 쪽에서 먼저 대사식을 세워 두고 전수로 돌렸습니다. 아래는 이 검증용 샘플 데이터의 결과입니다. 샘플은 가상의 보조부문 4곳(동력·수선·품질관리·자재운반)과 제조부문 3곳(절단·조립·도장), 2026년 1~9월 마감으로 만들었고 실제 고객사의 계정체계나 금액은 쓰지 않았습니다.

정합성 대사 8건은 모두 차이가 없습니다(R06 의 최대 차이 0.0001 은 비율을 소수 4자리로 반올림한 값이며 허용 0.001 안입니다). 이와 별도로 의도적 예외 두 가지를 일부러 심어 두고 대사 차이와 분리해 따로 집계했습니다.

두 예외가 겹치는 5월 도장을 한 곳으로 세면 점검 필요 제조부문·월은 5건입니다. 의도적 예외를 일부러 남긴 이유는, 점검 화면이 정말 이상한 자리를 잡아내는지를 같은 검증에서 함께 보기 위해서입니다. 화면 쪽은 이와 별도로 브라우저 자동화로 확인했습니다 — 점검 필요만 조회하면 5건이 남는지, 배부 방식 단계배부와 3월을 고르면 명세가 18건인지, 마감일을 5~6월로 좁히면 108건인지, Enter 키 조회가 동작하는지를 매번 다시 잽니다.

무엇으로 만들었나

앱 정보표

실행 화면

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

처음 열었을 때

조회조건과 요약, 표가 한 화면에 세로로 쌓입니다. 가장 먼저 눈에 들어와야 하는 것은 “오늘 확인할 곳이 몇 건인가” 입니다.

화면을 열면 기본 조건으로 바로 조회됩니다. 맨 위 파란 안내는 세 방식이 어떻게 다른지(직접은 제조부문 비율만, 단계는 용역 비중이 큰 보조부문부터, 상호는 주고받음을 연립으로) 한 번 적어 둔 것이고, 그 아래가 조회조건과 요약 타일입니다. 표의 “방식 간 격차율”은 세 방식 배부액의 최댓값과 최솟값 차이를 단계배부 총원가로 나눈 비율이며, 허용 1.00% 를 넘는 행만 주황색 “점검 필요”로 바뀝니다. 탭 이름 위의 작은 숫자(27 · 36 · 486 · 9 · 10)는 탭마다 몇 건이 조회됐는지입니다.

마감 때 가장 먼저 쓰는 모습입니다. 27건을 훑지 않고 5건으로 줄여 시작합니다. 5건은 3월 조립(장부 차이) · 5월 도장(격차율과 장부 차이 모두) · 7월 조립(격차율) · 7월 도장(격차율) · 8월 절단(장부 차이)입니다. 점검 결과 칸의 문구로 어느 조건에 걸렸는지 바로 구분되고, 다른 탭의 건수도 함께 줄어 보조부문 잔액 3건 · 배부 명세 3건 · 월별 추이 4건이 됩니다.

한 줄에서 근거까지 내려가기

숫자 하나를 눌러 그 숫자를 만든 줄까지 내려가는 흐름입니다. 마지막 화면은 이 모든 줄이 세 방식으로 어떻게 나뉘었는지 보여 줍니다.

예시는 7월 조립부문입니다. 직접배부액 129,651,148원, 단계배부액 138,612,575원, 상호배부액 133,199,917원으로 방식에 따라 최대 8,961,427원이 갈리고 격차율은 1.39% 입니다. 격차에 가장 크게 기여한 보조부문(수선)도 함께 표시되어, 어느 용역 수량 기준부터 확인할지 바로 정할 수 있습니다. 장부 배부액이 단계배부액과 같으면 장부와 재계산 차이는 0 입니다. 닫기 버튼으로 표로 돌아옵니다.

1월에는 수선(비중 24.39%)이 1순위, 자재운반이 2순위, 동력이 3순위, 품질관리가 4순위입니다. 다른 보조부문에 준 용역 비중이 큰 부문부터 먼저 나누기 때문입니다. 1순위 부문은 앞에서 받은 원가가 0 이라 대상 원가가 발생원가와 같고, 뒤 순서 부문일수록 수취원가가 쌓입니다. 세 방식의 배부 후 잔액은 모두 0 이어야 하며, 장부 배부 잔액이 0 이 아닌 달은 점검 필요입니다.

가장 아래 근거 단계입니다. 한 줄이 “제공 부문 → 받는 부문” 한 쌍이어서 합계 숫자가 의심스러우면 여기서 줄 단위로 확인합니다. 방식과 월, 제공 부문, 받는 부문, 마감일 범위로 좁힐 수 있고 마감일 조건은 서비스가 날짜 비교를 직접 처리합니다. 장부 배부액과 재계산이 1원을 넘게 다른 줄은 점검 필요로 나옵니다. 직접배부와 상호배부 줄은 장부에 반영하지 않는 비교용 재계산이라 장부와 대조하지 않습니다.

월로 보고, 검산으로 닫기

월별 흐름을 보고 마지막에 대사 결과로 숫자를 닫습니다.

1월부터 9월까지 9행입니다. 세 방식의 제조부문 배부 합계는 서로 같고 보조부문 원가와도 같아야 하므로, 한 달이라도 어긋나면 계산이 틀렸다는 신호입니다. 점검 필요 월(3 · 5 · 7 · 8월)은 해당 월의 제조부문 비교 행을 열어 어느 부문인지 좁혀 갑니다. 최대 격차율은 그 달의 제조부문 중 가장 큰 값입니다.

화면의 숫자가 스스로 맞는지 보여 주는 탭입니다. 숫자를 가져다 쓰기 전에 대사 차이 건수 타일이 0 인지 보면 됩니다. 의도적 예외(E01 · E02)는 대사 차이와 섞이지 않게 따로 줄을 세웠고, 걸린 건수가 3건씩이라는 사실이 점검 화면이 제대로 걸러 낸다는 증거가 됩니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 앱은 조회조건을 필터로 바꿔 서비스에 한 번 요청하고, 탭마다 필요한 결과집합을 받아 표에 바인딩합니다. 계산은 화면이 아니라 서비스가 합니다 — 직접·단계·상호배부 재계산, 격차율, 장부 대조, 점검 판정이 모두 서비스 안에서 끝난 뒤 화면은 받은 값을 보여 주기만 합니다. 그래서 같은 조건으로 부르면 어느 화면에서든 같은 숫자가 나옵니다.

1. 용역 비율 = 제공 부문이 받는 부문에 준 용역 수량 ÷ 배부 대상 수량 합계. 직접배부는 제조부문만, 단계배부는 아직 배부하지 않은 보조부문과 제조부문, 상호배부는 자신을 뺀 모든 부문이 대상입니다.
2. 직접배부액 = 보조부문 발생원가 × 제조부문 용역 비율. 원 단위 끝수는 최대잔여법으로 맞춰 합계가 정확히 같게 합니다.
3. 단계배부액 — 대상 원가(발생원가 + 앞 순서 보조부문에서 받은 배부액)에 비율을 곱합니다. 이미 배부한 보조부문에는 되돌려 배부하지 않습니다.
4. 상호배부액 — 대상 원가에 다른 보조부문에서 받은 배부액을 더해, 서로 받고 주는 관계를 정수 반복 계산으로 풀어 모든 보조부문에서 동시에 성립하게 합니다.
5. 제조부문 총원가 = 고유원가 + 방식별 배부액. 방식 간 격차율 = (배부액 최댓값 − 최솟값) ÷ 단계배부 총원가 × 100.

판정 규칙 — 어떤 때 점검 필요가 되나

점검 필요는 “잘못 배부했다”는 뜻이 아닙니다. 용역 수량의 기준월이나 전기 내역처럼 원천에서 확인해야 할 자리가 있다는 표시이며, 원인을 단정하지 않습니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

이 화면은 열 수가 많은 표를 한 줄로 읽는 월마감 점검 화면이라 넓은 화면(1600px 기준)에서 검증했습니다. 표는 가로 스크롤을 지원하지만, 휴대폰 크기의 좁은 화면 배치는 이번 검증 범위에 넣지 않았고 확인 필요로 남겨 둡니다.

파일 구성

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

운영 전환 시 “기존 리포트를 없애야 하나” 에 대한 답은 아니오입니다. 법정 결산과 감사 대응에 쓰는 배분·배부 결과와 전표는 표준 화면에 그대로 남기고, 이 앱은 그 위에서 방식 비교와 점검 용도로 함께 씁니다. 두 화면의 숫자가 맞는지는 위 표의 대사 지점에서 맞춰 봅니다.

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

S/4HANA 에서는 CDS 뷰로 만든 분석 쿼리를 표준 Fiori 앱이 그대로 띄워 줍니다. 이 앱을 올리기 전에 표준 스택으로 먼저 되는지를 확인하는 편이 유지보수가 쌉니다.

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

1. 용역 수량의 원천을 정한다. 제공 부문이 받는 부문에 준 용역 수량은 통계 지표나 활동 수량에서 가져옵니다. S/4HANA 에서의 저장 위치와 필드는 확인 필요이며, 이 값이 정해져야 방식별 비율이 나옵니다.
2. 보조부문·제조부문 구분을 매핑 테이블로 둔다. 코스트센터 범주로 갈음할지 별도 매핑을 둘지 정합니다. 새 부문이 생길 때마다 개발자를 부르지 않게 매핑 테이블 한 곳에서 읽습니다.
3. 단계배부 순서 기준을 회사 정책으로 확정한다. 샘플은 다른 보조부문에 준 용역 비중이 큰 부문부터입니다. 회사에 이미 정해 둔 순서가 있다면 그것을 따르고 이 앱의 순서를 맞춥니다.
4. 허용 격차율을 정한다. 샘플은 1.00% 입니다. 제조부문의 규모와 마감 담당자가 볼 수 있는 건수에 맞춰 정합니다. 너무 낮으면 점검 필요가 쏟아지고, 너무 높으면 봐야 할 차이를 놓칩니다.
5. 권한을 표준 객체로 건다. 코스트센터·회사코드 권한을 집계를 읽는 자리에 겁니다. 부문별 원가는 부서 간 비교가 가능한 정보라서 보는 사람을 정해야 합니다.
6. 월마감 조회 시점을 정한다. 배분·배부 실행 이후에 조회하도록 마감 일정 안에 한 칸을 넣어 두면 장부 대조가 의미를 가집니다.

분석 지표 정의

CDS 구성

이 사례의 화면은 서비스가 계산한 결과를 보여 줍니다. 운영 데이터로 올릴 때는 원가와 용역 수량을 읽는 일은 CDS 가, 방식별 재계산은 ABAP 클래스가 맡습니다. 아래는 그때 만드는 객체들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 부문 매핑 테이블

방식별 계산의 모든 대상이 이 표에서 정해집니다. 어느 코스트센터가 보조부문이고, 몇 번째로 배부하는지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 중간에 부문 체계가 바뀌어도 과거 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZAUX_DEPTMAP — 보조·제조부문 매핑
"  역할   : 코스트센터가 보조부문인지 제조부문인지, 단계배부 순서는 몇 번인지를 담는다
"  이렇게 나눈 이유 : 부문은 늘 늘어난다. 코드에 박으면 새 부문마다 개발자를 부르게 된다
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '보조·제조부문 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zaux_deptmap {
  key client     : abap.clnt not null;
  key kokrs      : kokrs not null;            " 관리회계 영역
  key kostl      : kostl not null;            " 코스트센터
  key valid_to   : abap.dats not null;        " 유효 종료일 — 체계가 바뀌어도 과거 숫자가 흔들리지 않게
  dept_type      : abap.char(3);              " AUX 보조부문 / MFG 제조부문
  step_seq       : abap.numc(2);              " 단계배부 순서(정책으로 확정 — 확인 필요)
  driver_unit    : abap.unit(3);              " 용역 수량 단위(kWh · 시간 · 건 등)
}

② 부문 차원 — ZI_AuxDept

부문 한 행에 구분과 순서, 이름을 붙이는 차원 뷰입니다. 텍스트는 표준 텍스트 뷰에 association 으로 걸어 값 도움말과 쿼리 머리글이 같은 이름을 보게 합니다. where 로 유효 종료일을 걸어 지난 체계를 걸러냅니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AuxDept — 부문 차원
"  역할   : 코스트센터 한 행 + 부문 구분 + 순서 + 이름
"  이렇게 나눈 이유 : 큐브에서 join 을 한 번만 걸고, 값 도움말·텍스트가 이 뷰 하나를 보게 한다
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '보조·제조부문 차원'
@ObjectModel.representativeKey: 'CostCenter'
@Analytics.dataCategory: #DIMENSION
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_AuxDept
  as select from zaux_deptmap as m
  association [0..*] to I_CostCenterText as _Text           " 표준 텍스트 뷰 — 이름은 환경에서 확인 필요
    on  _Text.ControllingArea = $projection.ControllingArea
    and _Text.CostCenter      = $projection.CostCenter
{
      @ObjectModel.text.association: '_Text'
  key m.kostl     as CostCenter,
  key m.kokrs     as ControllingArea,
      m.dept_type as DeptType,          " AUX / MFG
      m.step_seq  as StepSeq,
      m.driver_unit as DriverUnit,
      _Text
}
where m.valid_to >= $session.system_date

③ 용역 수량 큐브 — ZI_AuxUsageQty

세 방식이 같은 수량 위에서 계산된다는 약속이 여기서 지켜집니다. 수량은 @Semantics.quantity.unitOfMeasure 로 단위에 묶어 서로 다른 단위가 합산되지 않게 합니다. 수량의 실제 원천(통계 지표 · 활동 수량)은 확인 필요이며, 적재 표의 이름은 예시입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AuxUsageQty — 용역 수량 큐브
"  역할   : 제공 부문 → 받는 부문 → 월별 용역 수량. 세 방식의 비율은 모두 여기서 나온다
"  이렇게 나눈 이유 : 방식이 달라도 수량은 하나여야 한다. 수량이 둘이면 방식 차이와 수량 차이가 섞인다
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '보조부문 용역 수량'
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #X, sizeCategory: #L, dataClass: #TRANSACTIONAL }
define view entity ZI_AuxUsageQty
  as select from zaux_usage as u                " 통계 지표 수량을 적재한 표 — 저장 위치는 확인 필요
  association [1..1] to ZI_AuxDept as _From on _From.CostCenter = $projection.ProviderCenter
  association [1..1] to ZI_AuxDept as _To   on _To.CostCenter   = $projection.ReceiverCenter
{
  key u.kokrs                       as ControllingArea,
  key u.gjahr                       as FiscalYear,
  key u.poper                       as FiscalPeriod,
  key u.from_kostl                  as ProviderCenter,
  key u.to_kostl                    as ReceiverCenter,
      u.unit                        as DriverUnit,
      @Semantics.quantity.unitOfMeasure: 'DriverUnit'
      @DefaultAggregation: #SUM
      u.qty                         as UsageQty,
      _From,
      _To
}

④ 발생원가 큐브 — ZI_AuxCostCube

배부할 원가와 장부 원가를 한 곳에서 읽습니다. 표준 인터페이스 뷰를 통해 ACDOCA 를 읽고 선도원장(0L)의 코스트센터 행만 집계합니다. 금액은 통화 코드에 묶어 #SUM 으로 집계합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AuxCostCube — 보조·제조부문 발생원가 큐브
"  역할   : 코스트센터·월별 실적 원가. 보조부문의 발생원가와 제조부문의 고유원가가 모두 여기서 나온다
"  이렇게 나눈 이유 : 장부 원가를 한 곳에서만 읽는다. 배부 결과가 장부와 어긋났을 때 비교할 기준이 하나로 정해진다
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '부문별 발생원가'
@Analytics.dataCategory: #CUBE
define view entity ZI_AuxCostCube
  as select from I_JournalEntryItem as j        " ACDOCA 위의 표준 인터페이스 뷰 — 필드 이름은 릴리스별로 확인 필요
  association [0..1] to ZI_AuxDept as _Dept on _Dept.CostCenter = $projection.CostCenter
{
  key j.CompanyCode                 as CompanyCode,
  key j.FiscalYear                  as FiscalYear,
  key j.FiscalPeriod                as FiscalPeriod,
  key j.CostCenter                  as CostCenter,
      j.CompanyCodeCurrency         as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      @DefaultAggregation: #SUM
      sum( j.AmountInCompanyCodeCurrency ) as ActualCost,
      _Dept
}
where j.Ledger = '0L'                           " 선도원장
  and j.CostCenter <> ''
group by j.CompanyCode, j.FiscalYear, j.FiscalPeriod, j.CostCenter, j.CompanyCodeCurrency

⑤ 분석 쿼리 — ZC_AuxCostQuery

이 쿼리 하나로 표준 앱이 코스트센터×월 원가표를 띄웁니다. 방식별 재계산이 필요 없는 사용자는 여기서 끝나도 됩니다. 필수 필터로 회계연도를 두어 전체 기간을 한 번에 읽는 일을 막습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_AuxCostQuery — 부문별 발생원가 분석 쿼리
"  역할   : 표준 Fiori 앱·Analysis for Office 가 그대로 띄우는 쿼리. 이 앱 없이도 원가와 용역 수량은 볼 수 있다
"  이렇게 나눈 이유 : 방식별 재계산이 필요 없는 사용자까지 이 앱을 쓰게 만들 이유가 없다
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '부문별 발생원가 쿼리'
@Analytics.query: true
@Metadata.allowExtensions: true
define view entity ZC_AuxCostQuery
  as select from ZI_AuxCostCube
{
      @AnalyticsDetails.query.axis: #FILTER
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false, mandatory: true }
  key FiscalYear,
      @AnalyticsDetails.query.axis: #COLUMNS
  key FiscalPeriod,
      @AnalyticsDetails.query.axis: #ROWS
  key CostCenter,
      @AnalyticsDetails.query.axis: #COLUMNS
      @AnalyticsDetails.query.decimals: 0
      ActualCost
}

⑥ 권한 — ZI_AUXCOSTCUBE (DCL)

부문별 원가는 부서 간 비교가 가능한 정보입니다. 권한은 집계를 읽는 큐브에 걸어야 합니다. 회사코드는 F_BKPF_BUK, 코스트센터는 K_CCA 를 쓰는 것이 일반적이지만 필드 이름은 환경에서 확인해야 합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AUXCOSTCUBE — 권한(DCL)
"  역할   : 회사코드·코스트센터 권한을 집계를 읽는 자리에 건다
"  이렇게 나눈 이유 : 드릴스루에만 걸면 전체 합계에서 남의 부문 숫자를 뺄셈으로 알아낼 수 있다
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '부문별 발생원가 권한'
@MappingRole: true
define role ZI_AUXCOSTCUBE {
  grant select on ZI_AuxCostCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( CostCenter )  = aspect pfcg_auth( K_CCA, KOSTL, ACTVT = '03' );   " 권한 객체 필드는 환경에서 확인 필요
}

⑦ 배부방식 비교 — 사용자 정의 엔티티와 조회 클래스

단계배부는 순서에 따라 앞 부문에서 받은 원가가 뒤 부문의 대상 원가에 얹히고, 상호배부는 서로 주고받는 관계를 연립으로 풀어야 합니다. SQL 한 줄로 되지 않으므로 사용자 정의 엔티티를 만들고 조회 구현 클래스가 계산합니다. 아래는 직접배부의 최대잔여법(원 단위 끝수를 합계에 정확히 맞추는 처리)까지의 뼈대이며, 단계·상호 계산 본문은 길어서 주석으로 단계만 적었습니다.

" ────────────────────────────────────────────────────────────────
"  ZR_AuxAllocCompare — 배부방식 비교 결과(사용자 정의 엔티티)와 조회 구현
"  역할   : 직접·단계·상호배부 재계산과 격차율을 돌려주는 서비스의 중심
"  이렇게 나눈 이유 : 단계·상호배부는 순서와 연립 계산이 필요해 SQL 한 줄로 되지 않는다
"                     CDS 가 수량과 원가를 가져오고, 계산은 ABAP 클래스가 맡는다
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '배부방식 비교'
@ObjectModel.query.implementedBy: 'ABAP:ZCL_AUX_ALLOC_QUERY'
define custom entity ZR_AuxAllocCompare
{
  key FiscalYear   : gjahr;
  key FiscalPeriod : poper;
  key MfgDept      : kostl;
      DirAlloc     : abap.curr(15,0);        " 직접배부액
      StpAlloc     : abap.curr(15,0);        " 단계배부액
      RecAlloc     : abap.curr(15,0);        " 상호배부액
      GapRate      : abap.dec(7,2);          " 방식 간 격차율(%)
      BookDiff     : abap.curr(15,0);        " 장부 − 재계산
      CheckStatus  : abap.char(5);           " OK / CHECK
}

CLASS zcl_aux_alloc_query DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_rap_query_provider.
  PRIVATE SECTION.
    TYPES: BEGIN OF ty_row, dept TYPE kostl, ratio TYPE p LENGTH 9 DECIMALS 6, END OF ty_row,
           tt_row TYPE STANDARD TABLE OF ty_row WITH EMPTY KEY,
           BEGIN OF ty_amt, dept TYPE kostl, amt TYPE p LENGTH 15 DECIMALS 0, END OF ty_amt,
           tt_amt TYPE STANDARD TABLE OF ty_amt WITH EMPTY KEY.
    METHODS direct_alloc
      IMPORTING iv_cost TYPE p it_ratio TYPE tt_row
      RETURNING VALUE(rt_amt) TYPE tt_amt.            " 합계가 정확히 iv_cost 가 되도록 최대잔여법
ENDCLASS.

CLASS zcl_aux_alloc_query IMPLEMENTATION.
  METHOD if_rap_query_provider~select.
    DATA lt_out TYPE STANDARD TABLE OF zr_auxalloccompare WITH EMPTY KEY.
    TRY.
        DATA(lt_filter) = io_request->get_filter( )->get_as_ranges( ).
      CATCH cx_rap_query_filter_no_range.
        CLEAR lt_filter.
    ENDTRY.
    " 1) 필터의 회계연도·기간·제조부문으로 ZI_AuxCostCube · ZI_AuxUsageQty 를 읽는다
    " 2) 방식별 비율을 만들고 direct_alloc 등으로 배부액을 구한다 (단계: 순서대로, 상호: 반복 수렴)
    " 3) 격차율 = ( max − min ) / 단계배부 총원가 × 100, 장부 전표와의 차이로 CheckStatus 를 정한다
    IF io_request->is_total_numb_of_rec_requested( ).
      io_response->set_total_number_of_records( lines( lt_out ) ).
    ENDIF.
    io_response->set_data( lt_out ).
  ENDMETHOD.

  METHOD direct_alloc.
    DATA(lv_sum) = REDUCE p( INIT s = 0 FOR r IN it_ratio NEXT s = s + r-ratio ).
    DATA lv_given TYPE p LENGTH 15 DECIMALS 0.
    LOOP AT it_ratio INTO DATA(ls) .
      DATA(lv_exact) = iv_cost * ls-ratio / lv_sum.
      APPEND VALUE #( dept = ls-dept amt = floor( lv_exact ) ) TO rt_amt.
      lv_given = lv_given + floor( lv_exact ).
    ENDLOOP.
    " 남은 원 단위는 소수부가 큰 순서대로 한 원씩 나눠 준다(최대잔여법)
    DATA(lv_left) = iv_cost - lv_given.
    " … 소수부 내림차순 정렬 후 lv_left 건에 +1 …
  ENDMETHOD.
ENDCLASS.

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

코스트센터가 수백 개, 마감이 12개월이면 용역 수량 표는 수만 행이 됩니다. 이 정도 규모에서는 수량 집계는 CDS 에서 하고 서버 쪽 계산은 필요한 회계연도·제조부문만 읽도록 필터를 필수로 둡니다. 조회 응답은 월 단위 결과를 기준으로 하고, 배부 명세는 상세를 열 때만 읽는 것이 보통입니다. 응답 시간 기준(예: 조회 한 번에 수 초 이내)은 회사가 정해야 하며 이 글에서는 측정값을 제시하지 않습니다.

자주 묻는 질문

도입을 검토하실 때 가장 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

표준과 도입

운영과 보안