SAP 원가센터 배부·정산 통합 관리 — 시뮬레이션부터 승인, 대사, 차이 요인분해까지 한 앱에서

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

월말 원가 마감에서 현업이 가장 자주 받는 질문은 세 가지입니다. 남은 센터 잔액은 모두 나눠졌나, 누가 승인했고 무엇이 아직 대기 중인가, 계획과 실적의 차이는 어디서 났나. 지금은 이 답이 배부 실행 화면, 엑셀 대사표, 메일 승인으로 흩어져 있어 마감일마다 숫자를 맞추는 회의가 열립니다. 이 앱은 세 질문에 대한 답을 한 앱, 같은 숫자로 이어 줍니다.

표준 배부 실행(KSU5 · KSV5)은 SAP 표준 T-code 가 그대로 담당합니다. 이 앱은 그 앞에서 무엇이 만들어질지 시뮬레이션으로 먼저 보여 주고, 승인과 직무 분리를 거친 뒤, 결과를 원가 라인과 센터 잔액에 대해 자동으로 대사하며, 남은 차이를 요인별로 분해해 보여 줍니다. 대상은 센터별 단계 배부를 쓰는 제조업의 원가·관리회계 조직입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(2026년 1~9월)의 계획 대비 실적은 계획 7,698,573,000원, 실적 7,968,946,600원으로 270,373,600원(3.5%) 늘었습니다. 표준 리포트도 여기까지는 말해 줍니다. 이 앱은 차이를 네 요인으로 갈라, 가장 큰 몫이 변동비가 아니라 기타 고정비(+137,696,800원) 임을 보여 줍니다. 변동비 단가 +94,897,678원과 감가상각비 +61,686,800원이 뒤를 잇고, 가동 시간이 계획보다 줄어든 조업도 효과는 −23,907,678원이었습니다. 네 요인을 더하면 총 차이와 정확히 같고, 이 등식은 점검한 14개 조회 범위에서 모두 0원 차이로 맞았습니다. 가동률을 올리자는 이야기가 아니라 고정비 항목을 먼저 열어 보자는 이야기로 회의가 바뀝니다.

도입하면 달라지는 것

• 마감 준비 — 시뮬레이션, 승인, 실행, 대사가 한 흐름으로 이어져 엑셀 취합과 메일 승인이 사라집니다.
• 회의의 주제 — “어느 숫자가 맞나” 가 아니라 “남은 차이를 어떻게 처리할까” 로 넘어갑니다.
• 책임의 기록 — 누가 작성하고 누가 승인했는지가 문서 이력과 감사 기록에 같은 건수로 남습니다.
• 점검의 자동화 — 사람이 화면을 열지 않아도 감시 규칙이 잔액과 지연 문서를 찾아 대기함에 올립니다.

이런 회사에 맞습니다

여러 사업장에서 관리부문과 보조부문의 비용을 생산부문으로 단계 배부하고, 월 단위로 마감하는 제조업입니다. 센터가 수십 개이고 배부 전표가 월 수백 건 이상이며, 처리 담당과 승인자가 나뉘어 있고, 마감 때 엑셀 대사와 메일 승인이 반복되는 원가·관리회계 조직에 특히 맞습니다. 법정 결산과 세무 신고 숫자는 표준 거래에 그대로 두고 이 앱은 처리 보조와 점검, 분석에 씁니다.

실행 화면

아래 화면은 검증용 샘플 데이터로 실제 앱을 실행해 찍은 캡처입니다(총 32종). 그림을 누르면 크게 볼 수 있고, 순서는 월말 마감에서 일하는 순서와 같습니다.

사용 방법

1. 사용자 고르기 — 오른쪽 위 사용자 전환에서 조회자, 처리자, 승인자, 관리자 중 하나를 고릅니다. 역할마다 보이는 버튼이 다릅니다(데모용이며 운영에서는 SAP 권한으로 바뀝니다).
2. 개요에서 시작 — 잔액이 남은 센터, 승인 대기 문서, 대사 예외와 기한이 다가오는 할 일을 보고 카드의 숫자를 눌러 해당 목록으로 이동합니다.
3. 조회조건 입력 — 목록은 검색어, 센터 유형, 상태 같은 선택 조건으로 좁힙니다. 일괄 실행은 사업장, 기간, 실행 유형이 필수입니다. 조회 버튼은 조건 영역 위쪽에 있고 입력란에서 Enter 키를 눌러도 조회됩니다.
4. 전표 처리 — 문서 처리에서 전표를 만들고 검토 요청, 승인, 확정까지 상태 순서대로 진행합니다. 잘못 확정한 문서는 취소로 역처리합니다.
5. 일괄 실행 — 시뮬레이션으로 만들어질 전표를 먼저 보고 실행을 누릅니다. 시뮬레이션하지 않은 조건은 실행되지 않습니다.
6. 대사 — 대사 실행으로 네 가지 규칙을 검사하고, 어긋난 예외는 행을 눌러 처리합니다.
7. 분석 — 기간과 범위를 정해 조회를 누르면 피벗이 열립니다(들어올 때는 자동 조회하지 않습니다). 차원을 끌어 행과 열을 바꾸고, 금액 칸을 눌러 근거 라인을 엽니다.
8. 행 선택과 상세 — 목록의 행을 누르면 상세가 열려 상태 이력과 연계 문서를 함께 보여 줍니다.
9. 내려받기 — 목록과 분석 표는 CSV 로, 분석 보고서는 PowerPoint 로 현재 필터 그대로 내려받습니다.

무엇으로 만들었나

처음 열었을 때 — 잔액과 할 일이 한곳에

첫 화면은 아직 배부하지 못한 센터 잔액, 승인 대기 문서, 대사 차이처럼 오늘 처리할 일을 한곳에 모읍니다. 카드의 숫자를 누르면 해당 목록이 필터가 걸린 채 열립니다. 월말 점검의 출발점이라서 먼저 이 화면에서 우선순위를 정합니다.

기준정보 관리 — 센터와 규칙을 한 곳에서

관리부문, 보조부문, 생산부문으로 나눈 원가센터를 사업장과 상태 조건으로 조회합니다. 배부 순서와 장부 잔액, 마지막 배부 전표가 한 줄에 보입니다. 행을 선택하면 수정, 사용 중지, 변경 이력 버튼이 켜집니다.

보내는 센터에서 받는 센터로 가는 배부 기준과 가중치를 규칙 단위로 관리합니다. 가중치만 고칠 수 있게 막아 두어 규칙의 뼈대가 실수로 바뀌지 않습니다. 사용 중지한 규칙은 다음 실행부터 제외됩니다.

수정 창은 필수 항목에 별표를 달고, 값을 바꾸면 제목에 변경됨 표시가 붙습니다. 닫을 때 저장하지 않은 변경이 있으면 한 번 더 확인합니다. 저장 결과는 변경 이력에 사용자와 시각으로 남습니다.

문서 처리와 승인 — 승인 버튼은 승인자에게만 보인다

배부, 재분류, 조정 전표를 상태별로 조회합니다. 임시저장, 검토요청, 승인, 확정, 반려, 취소의 여섯 상태가 색으로 구분되어 어디서 멈춰 있는지 바로 보입니다. 금액이 500만원 이상이면 승인 단계가 2단계로 표시됩니다.

보내는 센터와 받는 센터, 금액을 입력해 전표를 만듭니다. 차변과 대변 합계가 맞지 않거나 금액이 최소 배부액보다 작으면 저장 전에 알려 줍니다. 저장하면 임시저장 상태로 만들어집니다.

임시저장 문서는 처리자가 검토를 요청합니다. 요청 사유를 적으면 상태 이력에 함께 남습니다. 반려된 문서도 보완한 뒤 같은 방법으로 다시 요청합니다.

승인은 승인자 역할만 할 수 있고, 문서를 작성한 사람은 같은 문서를 승인할 수 없습니다. 500만원 이상은 승인자 두 명이 차례로 승인해야 다음 상태로 넘어갑니다. 반려할 때는 사유가 필수입니다.

승인된 문서를 확정하면 원가 라인에 반영되고 센터 잔액이 바뀝니다. 상세 화면은 항목 표와 상태 이력, 연계 문서를 한 번에 보여 줍니다. 확정 후에는 수정할 수 없고 취소만 가능합니다.

문서 상세 아래에는 이 전표와 이어진 문서가 표로 나옵니다. 원가 전표에서 재무와 생산 영역의 문서로 이동해 같은 흐름을 따라갈 수 있습니다. 앵커 버튼으로 해당 위치까지 바로 스크롤합니다.

확정 문서를 취소하면 반대 부호의 역처리 문서가 새로 만들어집니다. 취소 사유를 적어야 진행되며 승인자 역할만 할 수 있습니다. 원본 문서는 지우지 않고 상태만 취소로 바뀝니다.

취소가 끝나면 원본은 취소 상태가 되고 역처리 문서의 번호가 연결됩니다. 센터 잔액은 취소 전 값으로 돌아갑니다. 상태 이력에는 취소 사유와 처리한 사람이 남습니다.

여러 전표를 엑셀 파일로 올려 한 번에 만들 수 있습니다. 업로드 전에 미리보기에서 오류 행을 확인하고, 적용하면 정상 행만 임시저장 문서로 생성됩니다. 파일 형식과 합계 오류는 행 번호와 함께 알려 줍니다.

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

기간과 사업장을 고르면 배부 순서대로 보조부문, 관리부문의 잔액을 받는 센터에 나누는 일괄 실행을 준비합니다. 실행 이력이 아래에 쌓여 이전 실행의 결과와 비교할 수 있습니다.

실행 전에 시뮬레이션으로 만들어질 전표와 금액을 미리 확인합니다. 최소 배부액보다 작은 잔액은 제외 표시가 붙습니다. 결과에는 시뮬레이션 식별 값이 부여되어 이후 실행과 연결됩니다.

실행하면 시뮬레이션과 같은 전표가 만들어지고 합계가 일치하는지 확인합니다. 같은 시뮬레이션은 한 번만 실행할 수 있어 중복 배부를 막습니다. 건별 로그는 성공, 건너뜀, 오류로 구분됩니다.

대사와 예외 조치 — 어긋난 곳을 찾아 기록으로 남긴다

네 가지 대사 규칙의 검사 건수와 차이 건수, 최대 차이 금액이 한눈에 보입니다. 허용 오차 안의 차이는 정상으로 보고 그 밖만 예외로 올립니다. 같은 규칙을 여러 번 실행해도 이력이 쌓입니다.

예외 건을 열어 조정 전표를 연결하거나 사유를 적어 처리합니다. 의도적으로 남긴 예외와 아직 조치하지 않은 예외가 구분되어 보입니다. 조치한 내용은 감사 기록에 남습니다.

영역 간 연계 — 원가 전표에서 다른 영역 문서까지

원가 전표에서 시작해 다른 영역의 문서까지 이어지는 흐름을 표와 선으로 보여 줍니다. 각 문서의 영역과 금액, 일자가 함께 나와 어디서 값이 바뀌었는지 추적할 수 있습니다.

분석 — 피벗에서 전표까지, 계획 대비 차이의 요인까지

차원을 행과 열에 끌어다 놓고 지표를 고르는 피벗 분석 화면입니다. 기간, 센터, 원가요소 같은 차원을 자유롭게 바꾸고 접고 펼칠 수 있습니다. 조회 버튼은 화면 위쪽에 두었습니다.

1차 비용, 배부 수신, 배부 송신, 센터 잔액 같은 지표를 골라 표에 올립니다. 지표마다 좋고 나쁨의 방향이 정해져 있어 증감 색이 의미에 맞게 표시됩니다.

배부율, 고정비 비중처럼 지표끼리 나눈 계산 항목을 표에 함께 놓습니다. 계산식은 서비스가 정의하고 화면은 그 식 그대로 계산합니다. 분모가 0이면 빈칸으로 둡니다.

같은 범위의 계획과 실적을 나란히 놓고 차이와 차이율을 봅니다. 비교는 스위치 하나로 켜고 끕니다. 계획에 없는 조합은 계획 0으로 계산합니다.

계획과 실적의 차이를 조업도, 변동비 단가, 감가상각비, 기타 고정비 네 가지 요인으로 나눠 폭포 차트로 보여 줍니다. 네 요인을 더하면 총 차이와 정확히 같습니다. 요인 막대를 누르면 근거 숫자가 나옵니다.

역할을 바꾸면 같은 데이터를 그 역할이 보는 지표와 차원으로 다시 구성합니다. 경영진 관점은 그룹 단위로 접힌 요약을 먼저 보여 줍니다.

차원마다 값을 골라 범위를 좁힙니다. 선택한 조건은 칩으로 남아 지우기 쉽고, 조건이 바뀌면 표가 다시 계산됩니다.

표의 금액 칸을 누르면 그 금액을 만든 원가 라인이 목록으로 열립니다. 라인의 합계는 눌러 본 칸의 금액과 같습니다. 전표 번호로 문서 상세까지 이어서 갑니다.

AI 분석과 에이전트 — 숫자는 서비스가, 설명은 AI 가

현재 범위를 읽어 요약과 핵심 발견을 씁니다. 기본은 규칙 기반 해설이고 모델 연결은 설정으로 켭니다. 해설이 쓴 근거 표를 함께 펼쳐 보여 주며, AI 가 새 숫자를 만들지는 않습니다.

감시 규칙에 걸린 항목을 받을 역할별 보고로 만들어 대기함에 올립니다. 실행은 하루 한 번으로 제한되고 걸린 것이 없어도 실행 기록은 남습니다. 호출 주체가 사람인지 타이머인지 배치인지 구분해 기록합니다.

자주 쓰는 행, 열, 지표 배치를 이름을 붙여 저장합니다. 기본 레이아웃과 자동 조회 여부를 정해 두면 다음에 열 때 바로 같은 표가 나옵니다.

이력과 감사 — 누가 무엇을 했는지

생성, 수정, 승인, 확정, 취소, 대사 조치 같은 모든 변경이 사용자와 시각, 변경 전후 값과 함께 남습니다. 성공과 거절 결과를 모두 기록해 누가 무엇을 시도했는지 확인할 수 있습니다.

좁은 화면 — 휴대폰에서도

좁은 화면에서는 표를 카드로 바꾸고 조건은 접이식 패널에 넣습니다. 손가락으로 누르기 좋은 크기를 유지합니다.

화면 뒤에서 일어나는 일

버튼을 누르면 화면이 직접 판정하지 않고 서비스에 요청합니다. 서비스는 사용자 역할, 문서 상태, 금액을 보고 허용하거나 거절하며, 거절 사유는 그대로 화면에 표시됩니다. 같은 요청을 다른 화면에서 해도 결과가 같은 이유입니다.

문서 상태 판정 — 조건, 결과 상태, 사용자 조치

일괄 실행 판정

처리 단계와 대사식

업무 흐름은 배부 전표 → 검토 요청 → 승인 → 확정(원가 라인 반영) → 일괄 실행 결과 → 대사 → 분석 순서입니다. 대사는 네 가지 식으로 같은 숫자를 서로 다른 쪽에서 맞춰 봅니다. 허용 오차는 규칙마다 1원입니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

휴대폰 폭에서는 셸 메뉴가 접히고 목록은 카드로 바뀌며 조회조건은 접이식 패널로 들어갑니다. 분석의 피벗은 가로로 넘겨 볼 수 있고, 버튼은 손가락으로 누르기 좋은 크기를 유지합니다.

파일 구성

(앱 폴더)
  index.html · manifest.json · Component.js
  view/ · view/fragments/    화면 8개와 대화상자
  controller/                화면별 컨트롤러
  model/                     큐브 계산, 서식, 엑셀·PowerPoint 생성, 권한
  css/ · i18n/
  odata/…/metadata.xml · service.js · json/   서비스 선언과 로직, 데이터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 실행 전 점검과 승인, 실행 뒤 대사와 분석 관점을 더해 확장합니다. 표준 화면을 없애는 앱이 아니므로 운영에 올려도 기존 리포트와 법정 마감 절차는 그대로 둡니다.

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

T-code 별 연계 지점

운영 전환 때 자주 나오는 질문, “기존 리포트를 없애야 하나” 의 답은 아니오입니다. 기존 리포트는 그대로 두고, 두 화면의 숫자를 맞춰 보는 대사 항목을 운영 절차에 한 줄 추가하면 됩니다.

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

S/4HANA 에서는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 로도 원가 데이터를 볼 수 있습니다. 이 앱은 그것들과 경쟁하지 않고, 배부 처리와 승인, 대사까지 한 흐름으로 묶는 자리를 맡습니다. 분석 부분은 같은 원천(유니버설 저널의 원가 라인)을 읽는 CDS 큐브로 옮길 수 있게 구성했습니다(다음 절). 어느 Fiori 앱과 겹치는지는 도입 시점의 릴리스에서 확인이 필요합니다.

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

분석 지표 정의표

CDS 구성 — 운영 데이터로 옮길 때의 뷰 설계

검증용 앱은 같은 구조의 샘플 데이터 위에서 돌지만, 운영에서는 원가 라인을 유니버설 저널(ACDOCA)에서, 센터와 원가요소 기준을 마스터 테이블(CSKS · CSKT · CSKB)에서 읽습니다. 아래는 그 구조를 ABAP CDS 로 옮긴 스케치입니다. 이름은 예시이고, 표준 CDS 뷰 대신 원천 테이블을 직접 읽는 방식으로 적었습니다. 확인하지 못한 표준 뷰 이름은 쓰지 않았습니다.

뷰 레이어 구성

① 원가요소 분류 매핑 테이블

ACDOCA 에는 “배부 수신” 같은 지표 개념이 없고 계정만 있습니다. 어떤 원가요소가 1차 비용이고 어떤 것이 배부 송신 계정인지는 회사가 정하므로, 분류를 데이터로 두고 CDS 가 조인해 읽게 합니다. 계정 체계를 바꿔도 뷰를 이송하지 않고 이 테이블만 고치면 됩니다.

@EndUserText.label : '원가요소 → 지표 분류 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcch_elemmap {
  key client   : abap.clnt not null;
  key kokrs    : kokrs not null;      " 관리회계 영역
  key kstar    : kstar not null;      " 원가요소(계정)
  measure_cat  : abap.char(4);        " ACT 1차 비용 · AIN 배부 수신 · AOUT 배부 송신
                                      " FIX 고정비 · DEP 감가상각비
  behavior     : abap.char(1);        " F 고정비 · V 변동비
}

② 원가 라인 기본 뷰

유니버설 저널의 원가센터 라인을 읽고 매핑을 붙입니다. 금액은 통화 코드와, 가동 시간은 단위와 짝으로 선언해 집계 때 통화와 단위가 섞이지 않게 합니다. 원장은 주 원장(0L)만 읽도록 where 로 고정했습니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '원가 라인 (기본)'
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XXL, dataClass : #TRANSACTIONAL }
define view entity ZI_CcCostLine
  as select from acdoca as a
    inner join zcch_elemmap as m
      on  m.kokrs = a.kokrs
      and m.kstar = a.racct
  association [0..1] to ZI_CcCenter as _Center
    on  $projection.ControllingArea = _Center.ControllingArea
    and $projection.CostCenter      = _Center.CostCenter
{
  key a.rldnr  as Ledger,
  key a.rbukrs as CompanyCode,
  key a.gjahr  as FiscalYear,
  key a.belnr  as AccountingDocument,
  key a.docln  as LedgerItem,
      a.kokrs  as ControllingArea,
      a.rcntr  as CostCenter,
      a.racct  as CostElement,
      a.budat  as PostingDate,
      a.poper  as PostingPeriod,
      m.measure_cat as MeasureCategory,
      m.behavior    as CostBehavior,
      @Semantics.currencyCode : true
      a.rhcur  as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      a.hsl    as Amount,
      @Semantics.unitOfMeasure : true
      a.runit  as Unit,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      a.msl    as Quantity,
      _Center
}
where a.rldnr = '0L'

③ 센터 차원 뷰

센터의 이름과 유형은 유효기간에 따라 바뀝니다. 차원 뷰에 시간 의존을 선언해 두면 큐브가 전기일 기준으로 그때의 이름과 유형을 붙입니다. 센터 유형(관리·보조·생산부문)은 센터 범주 필드를 회사 기준으로 변환해 씁니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@EndUserText.label : '원가센터 (차원)'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'CostCenter'
define view entity ZI_CcCenter
  as select from csks as c
    left outer join cskt as t
      on  t.kokrs = c.kokrs
      and t.kostl = c.kostl
      and t.datbi = c.datbi
      and t.spras = $session.system_language
{
  key c.kokrs as ControllingArea,
  key c.kostl as CostCenter,
  key c.datbi as ValidTo,
      c.datab as ValidFrom,
      t.ktext as CostCenterName,
      c.verak as ResponsiblePerson,
      case c.kosar
        when 'H' then 'PRD'   " 생산(예시 — 센터 범주 매핑은 회사 기준)
        when 'V' then 'ADM'
        else 'AUX'
      end as CenterType
}

④ 큐브 — 지표 집계

큐브는 기본 뷰의 금액을 지표 열로 펼칩니다. 한 곳에서만 집계하므로 어떤 축으로 분석해도 총합이 같습니다. 센터 잔액은 “1차 비용 + 수신 − 송신” 으로 만들어 서비스와 같은 식을 씁니다.

@Analytics.dataCategory : #CUBE
@ObjectModel.modelingPattern : #ANALYTICAL_CUBE
@ObjectModel.supportedCapabilities : [ #ANALYTICAL_PROVIDER, #SQL_DATA_SOURCE, #CDS_MODELING_DATA_SOURCE ]
@EndUserText.label : '원가센터 비용 큐브'
define view entity ZI_CcCostCube
  as select from ZI_CcCostLine as l
{
  l.ControllingArea,
  l.CompanyCode,
  l.CostCenter,
  l.CostElement,
  l.FiscalYear,
  l.PostingPeriod,
  l.CostBehavior,
  l.Currency,

  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  case l.MeasureCategory when 'ACT'  then l.Amount else cast( 0 as abap.curr( 23, 2 ) ) end as PrimaryCost,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  case l.MeasureCategory when 'AIN'  then l.Amount else cast( 0 as abap.curr( 23, 2 ) ) end as AllocIn,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  case l.MeasureCategory when 'AOUT' then l.Amount else cast( 0 as abap.curr( 23, 2 ) ) end as AllocOut,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  case l.MeasureCategory when 'DEP'  then l.Amount else cast( 0 as abap.curr( 23, 2 ) ) end as Depreciation,
  @Aggregation.default : #SUM
  @Semantics.quantity.unitOfMeasure : 'Unit'
  l.Quantity as Hours,
  l.Unit
}

⑤ 차이 요인 뷰 — 계획과 실적을 맞붙임

계획 쪽 원천은 계획 테이블(ACDOCP 계열)이며 어느 계획 범주와 버전을 읽을지는 도입 때 정해야 합니다(아래 표). 요인 네 개는 서비스와 같은 산식이고, 네 요인의 합이 총 차이와 같은지를 점검 뷰로 따로 두어 어긋나면 바로 드러나게 합니다. ZI_CcPlanCube 는 ④ 와 같은 구조로 계획 테이블을 읽는 큐브이고, 변동비율·고정비 열은 지표 분류와 가동 시간에서 파생하므로 지면을 아끼려 생략했습니다.

@EndUserText.label : '계획 대비 실적 — 차이 요인'
define view entity ZI_CcVariance
  as select from ZI_CcCostCube as act
    inner join   ZI_CcPlanCube as pln
      on  pln.ControllingArea = act.ControllingArea
      and pln.CostCenter      = act.CostCenter
      and pln.PostingPeriod   = act.PostingPeriod
{
  act.CostCenter,
  act.PostingPeriod,
  act.PrimaryCost - pln.PrimaryCost                          as TotalVariance,

  " 조업도: (실제 가동시간 − 계획 가동시간) × 계획 변동비율
  ( act.Hours - pln.Hours ) * pln.VarRate                    as VolumeEffect,
  " 변동비 단가: 실제 가동시간 × (실제 변동비율 − 계획 변동비율)
  act.Hours * ( act.VarRate - pln.VarRate )                  as RateEffect,
  " 감가상각비: 실제 − 계획
  act.Depreciation - pln.Depreciation                        as DepreciationEffect,
  " 기타 고정비: (실제 고정비 − 실제 감가상각) − (계획 고정비 − 계획 감가상각)
  ( act.FixedCost - act.Depreciation ) - ( pln.FixedCost - pln.Depreciation ) as OtherFixedEffect
}

⑥ 분석 쿼리 — 축과 필수 필터

쿼리는 화면이 읽는 접점입니다. 기간을 필수 필터로 두어 전체 기간을 한꺼번에 읽는 호출을 막고, 센터와 원가요소는 기본 행 축으로, 지표는 열 축으로 둡니다. 계산 항목(배부율 등)은 쿼리의 계산 열로 정의해 화면이 식을 다시 구현하지 않게 합니다.

@Analytics.query : true
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '원가센터 배부·잔액 분석'
define view entity ZC_CcCostQuery
  as select from ZI_CcCostCube
{
  @AnalyticsDetails.query.axis : #FREE
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  PostingPeriod,

  @AnalyticsDetails.query.axis : #ROWS
  CostCenter,
  @AnalyticsDetails.query.axis : #ROWS
  CostElement,

  @AnalyticsDetails.query.axis : #COLUMNS
  PrimaryCost,
  @AnalyticsDetails.query.axis : #COLUMNS
  AllocIn,
  @AnalyticsDetails.query.axis : #COLUMNS
  AllocOut,

  @EndUserText.label : '센터 잔액'
  @AnalyticsDetails.query.axis : #COLUMNS
  @AnalyticsDetails.query.formula : 'PrimaryCost + AllocIn - AllocOut'
  cast( 0 as abap.curr( 23, 2 ) ) as Balance
}

⑦ 권한 — 집계 단계에서 거는 접근 제한

권한은 쿼리에 걸어 집계 단계에서 적용합니다. 드릴스루에만 걸면 전사 합계에서 자기 몫을 빼서 남의 센터 숫자를 알아낼 수 있기 때문입니다. 데모의 사용자 전환은 운영에서 PFCG 역할로 바뀌며, 아래 권한 객체와 필드는 회사 권한 설계에 맞춰 확인이 필요합니다.

@EndUserText.label : '원가센터 분석 권한'
@MappingRole : true
define role ZC_CcCostQuery {
  grant select on ZC_CcCostQuery
    where ( ControllingArea ) = aspect pfcg_auth( K_CSKS, KOKRS, ACTVT = '03' );
    " 센터·범주 단위 제한은 회사가 쓰는 권한 객체 필드에 맞춰 추가(확인 필요)
}

⑧ 서비스 정의 — 화면이 부르는 접점

쿼리와 센터 차원을 노출하는 서비스 정의입니다. 바인딩은 OData V2 로 게시하고, 처리 펑션(시뮬레이션·실행·승인)은 RAP 동작이나 표준 배부 실행으로 연결합니다.

@EndUserText.label : '원가센터 배부·정산 통합 관리 서비스'
define service ZSD_CcHub {
  expose ZC_CcCostQuery as CostQuery;
  expose ZI_CcCenter    as CostCenter;
  expose ZI_CcVariance  as CostVariance;
}

운영 시점에 해야 할 일

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

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

대사식을 먼저 세우고 샘플 데이터 전체에 돌린 결과입니다. 도입 포인트의 “사례로 보는 효과” 숫자도 같은 데이터에서 나왔습니다.

의도적 예외: 전표 AL26000130 · AL26000154 의 머리 금액은 항목 합계와 2,000원 다르게, 센터 장부 잔액 2건은 최대 12,000원 다르게 두었습니다. 대사가 이를 실제로 잡아내는지 보기 위한 것이며, 가장 최근 대사 실행에서 R01 2건 · R02 2건 · R03 2건 · R04 5건으로 나타났고 예외 목록에는 의도적 예외 17건(미해결 11건)이 있습니다.

운영 데이터로 갈 때

원가 라인이 수천만 건인 환경에서는 집계가 느려지는 곳이 정해져 있습니다. ① 필수 필터: 쿼리에서 기간을 필수로 두고 상한(예: 12개월)을 겁니다. ② 집계 위치: 큐브에서 집계해 화면이 라인을 직접 읽지 않게 하고, 드릴스루만 센터·기간 조건이 붙은 라인 조회로 엽니다. ③ 인덱스와 파티션: 원가 라인의 센터·기간 조건에 맞는 접근 경로를 확인합니다. ④ 응답 시간 기준: 피벗 조회 몇 초, 드릴스루 몇 초처럼 목표를 정하고, 넘기면 사전 집계(구체화)를 검토합니다. 이 앱의 화면은 필터를 서버로 넘기는 구조라 위 조치만으로 운영 규모에 맞출 수 있습니다.

자주 묻는 질문 — 숫자, 화면, 분석 기능, 도입과 운영

도입을 검토할 때 자주 나오는 질문을 네 묶음으로 모았습니다. 이 글의 숫자는 모두 검증용 샘플 데이터에서 나온 것입니다.

숫자와 산식

화면과 조작

대사와 분석 기능

도입과 운영