준비(셋업) 원가 점검 — 제조원가, 로트마다 든 준비시간과 소모자재를 원가로 바꿔 표준과 견주는 월마감 화면

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

매월 제조원가를 점검할 때, 로트별 준비시간과 소모자재의 원가 기여, 그리고 표준 대비 초과 원인 파악에 어려움을 겪으십니까? 이 앱은 생산오더별 실적 준비원가를 계산하고 표준과 비교하며, 로트 크기, 작업장 원가풀 배부액까지 통합 점검하여 원가 관리의 투명성을 확보합니다.

핵심 포인트 여섯 가지

사례로 보는 효과

6개월간 준비원가는 로트원가의 6.99%(6,326만 원)로 보이나, 모터 하우징 같은 소형 로트 품목은 여섯 달 모두 품목별 한도를 초과했습니다. 또한, 전체 206개 로트 중 47건은 점검 필요 대상으로, 이 로트들의 준비원가 비중은 11.84%로 전체 평균의 약 2배에 달하는 비효율을 보여줍니다.

도입하면 달라지는 것

• 월마감 전 제조원가 점검 시간이 단축됩니다.
• 로트 단위 비효율을 조기에 발견하고 개선합니다.
• 원가 데이터의 정합성과 신뢰성이 향상됩니다.
• 분산된 원가 데이터를 통합하여 신속하게 분석합니다.

이런 회사에 맞습니다

제조원가(준비·셋업 원가)를 월마감 전에 점검하고, 로트 단위 비효율 개선 및 원가 데이터 신뢰도 향상을 목표로 하는 제조 기업의 재무, 관리회계, 생산 관리 팀에 적합합니다.

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

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

아홉 대사식 모두 차이 건수 0건입니다(검사 1,314건). R06 의 최대 차이 0.005 는 반올림 허용 범위입니다. 이와 별도로 판정 기준에 걸리는 건을 일부러 넣었습니다. 점검 필요 로트 47건(시간 초과 20건 · 비중 초과 24건 · 둘 다 3건), 점검 필요 품목·월 18행(한도 초과 11행 · 차이율 초과 6행 · 둘 다 1행), 점검 필요 작업장·월 2행, 점검 필요 월 3행이며, 이 건들은 대사 차이가 아니라 점검 대상이라 차이 건수에 넣지 않았습니다.

실행 화면

아래 화면은 가상의 작업장 6곳(CNC 선반 · 머시닝센터 · 프레스 라인 · 조립 라인 · 사출 성형기 · 도장 라인)과 가상의 품목 8종, 가상의 단가로 만든 검증용 샘플 데이터(2026년 1~6월)를 실제로 조회한 모습입니다. 로트 206건, 품목·월 48행, 작업장·월 36행이며, 실제 고객사 값이 아닙니다.

처음 열었을 때

열면 자동으로 한 번 조회해, 조회조건 아래에 요약 지표 일곱 개와 품목별 집계 표가 한꺼번에 나옵니다.

맨 위 조회조건은 회계연도 · 전기 월 시작/종료 · 작업장 · 품목 · 점검 결과 여섯 칸이고 기본값은 2026년 전체입니다. 요약 지표는 준비원가 합계 63.3 · 표준 준비원가 61.4 · 준비원가 차이 +1.8(이상 백만 원) · 준비원가 비중 6.99% · 점검 필요 로트 47 · 점검 필요 품목 18 · 정합성 대사 차이 건수 0 순서입니다. 탭 이름 앞의 숫자는 조회된 건수입니다.

로트별 점검 — 한 줄이 준비 1회

두 번째 탭은 로트를 한 줄씩 보여 줍니다. 준비시간과 준비원가가 로트마다 표준과 얼마나 다른지 보는 자리입니다.

표준 준비시간과 실적 준비시간, 준비시간 차이, 활동단가, 준비 활동원가, 소모자재비, 준비원가, 표준 준비원가, 로트원가, 단위 준비원가와 비중이 한 줄에 나옵니다. 오른쪽 끝에 점검 결과와 점검 코드, 점검 내용이 붙습니다. 컬럼 제목을 눌러 정렬할 수 있고, 행을 누르면 상세 창이 열립니다.

조회조건의 점검 결과를 점검 필요로 두고 조회하면 로트 47건만 표에 남고, 요약 지표도 같은 조건으로 다시 계산되어 준비원가 비중이 11.84%로 올라갑니다. 준비시간이 표준의 120%를 넘었거나 준비원가 비중이 15%를 넘은 로트이며, 점검 내용 칸에 어느 쪽에 걸렸는지 적힙니다. 조건을 전체로 되돌리고 다시 조회하면 206건으로 돌아옵니다.

품목별 집계 — 로트 크기를 한도와 견준다

품목·월 단위로 모으면 로트가 작아서 생기는 문제가 보입니다. 품목마다 한도가 다르므로 한도와 평균 로트수량을 함께 봅니다.

품목마다 로트 수, 평균 로트수량, 표준 준비원가와 실적 준비원가, 차이율, 단위 준비원가, 준비원가 비중, 비중 한도, 기준 로트수량이 한 줄에 나옵니다. 점검 결과를 점검 필요로 두면 18행이 남고, 모터 하우징과 커넥터 케이스는 여섯 달 모두 한도를 넘었습니다. 평균 로트수량이 기준 로트수량보다 작은지 함께 보면 로트를 합칠 후보가 보입니다.

작업장별 집계와 월별 추이

작업장 탭은 원가풀과 배부액을, 월 탭은 월 단위 비중을 봅니다. 둘 다 점검 판정이 함께 나옵니다.

준비 횟수, 표준·실적 준비시간, 평균 준비시간, 활동단가, 활동 원가풀, 로트 배부액, 미배부 차이, 배부율이 나옵니다. 미배부 차이가 원가풀의 3%를 넘는 조립 라인 2월(-4.28%)과 사출 성형기 4월(+4.94%)이 점검 필요입니다. 작업장 조건을 걸면 한 작업장의 여섯 달만 볼 수 있습니다.

월 준비원가 비중은 1월 7.26%, 2월 6.93%, 3월 6.65%, 4월 7.52%, 5월 7.22%, 6월 6.39%입니다. 7%를 넘는 1월, 4월, 5월이 점검 필요이고 점검 필요 로트 수는 4월과 5월이 10건으로 가장 많습니다. 달이 정상이어도 안에 점검 필요 로트가 있을 수 있어 건수를 함께 봅니다.

대사 결과와 행 클릭 상세

숫자를 믿어도 되는지는 대사 결과 탭에서, 점검 필요의 이유는 상세 창에서 확인합니다.

아홉 대사식마다 좌변 · 우변 · 검사 건수 · 차이 건수 · 최대 차이가 나옵니다. 로트 대사식은 206건씩, 월·작업장 대사식은 6건 또는 36건씩 검사하며 차이는 모두 0건입니다. 차이 건수 칸은 0이면 정상색, 0이 아니면 경고색으로 바뀌어 그 숫자는 원천을 확인하라는 신호가 됩니다.

상세 창은 위에서부터 로트와 품목, 표준·실적 준비시간, 활동단가, 준비 활동원가와 소모자재비, 표준 대비 차이, 점검 내용 순서입니다. 점검 필요 로트는 어떤 조건(L1~L3)에 걸렸는지와 확인할 일이 함께 적히고, 같은 품목의 다른 로트도 같이 볼 수 있습니다. 품목·작업장·월 행을 눌러도 같은 모양의 창이 열립니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터로 바꿔 서비스에 요청하고, 받은 결과를 탭마다 다른 표에 바인딩합니다. 품목 탭 · 로트 탭 · 작업장 탭 · 월 탭 · 대사 탭이 각자 자기 데이터 묶음을 읽고, 행을 누르면 상세 창이 해당 로트나 월의 묶음을 따로 불러옵니다. 계산은 모두 서비스가 하고 화면은 값을 읽어 보여 주기만 합니다.

화면의 요약 지표 준비원가 비중은 로트원가 가중(준비원가 합계 ÷ 로트원가 합계)이고, 월별 비중의 단순 평균은 별도 조회용 함수가 돌려줍니다. 이 자료에서 그 평균은 6.995%이며, 두 값은 용도가 다르므로 화면에서는 가중 값만 지표로 씁니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 줄바꿈되어 위아래로 배치되고, 결과 표는 가로로 스크롤됩니다. 상세 창은 화면 폭에 맞춰 줄어듭니다. 요약 지표는 한 줄에 들어가지 않으면 다음 줄로 내려갑니다.

파일 구성

setupcost/
  index.html · Component.js · manifest.json
  controller/ (BaseController · Main)   view/ (Main · DetailDialog)   model/ (formatter · ErrorHandler)
  css/ · i18n/
  odata/ 서비스 선언 · 서비스 로직 · 엔티티셋별 데이터
  media/ 소개 영상

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

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

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

분석 지표 정의표

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

CDS 구성

아래는 이 화면이 읽는 값을 S/4HANA의 CDS 뷰로 세울 때의 구성 예시입니다. 객체 이름과 필드는 이 글에서 새로 지은 것이고, 표준 테이블(CRHD · CRCO · AFKO · AFRU)과 표준 필드 이름만 실재하는 것을 썼습니다. 준비 구분 확정과 준비용 소모자재의 원천은 회사마다 달라 확인 필요입니다.

뷰 레이어 구성

① 활동단가 기준 테이블 — 작업장별 활동단가와 점검 기준

활동단가와 점검 기준은 작업장마다, 기간마다 다르므로 코드가 아니라 기준 테이블에 둡니다. 이 테이블이 비어 있으면 준비 활동원가가 0 으로 집계되므로 운영에서 가장 먼저 채워야 하는 자리입니다.

" ───────────────────────────────────────────────
" 준비원가 활동단가 기준 — 작업장 · 유효시작일 단위
" 단가와 점검 기준을 코드에 두지 않고 기간별로 관리하기 위해 나눈다
" ───────────────────────────────────────────────
@EndUserText.label : '준비원가 활동단가 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zsetup_rate {
  key client     : abap.clnt not null;
  key werks      : werks_d not null;
  key arbpl      : arbpl not null;
  key valid_from : datum not null;
  act_rate       : abap.curr(11,0);
  waers          : waers;
  tol_hours_pct  : abap.dec(5,2);   " 준비시간 허용 초과율(%)
  share_lim_pct  : abap.dec(5,2);   " 로트 준비원가 비중 점검 기준(%)
}

② 차원 뷰 — 작업장

작업장 이름과 코스트센터를 한 곳에서만 읽게 합니다. 작업장 체계가 바뀌어도 이 뷰만 고치면 모든 탭이 같이 따라옵니다.

" ───────────────────────────────────────────────
" ZI_SetupWorkCenter — 작업장 차원
" 작업장 마스터(CRHD)와 코스트센터 할당(CRCO)을 한 번만 조인한다
" 위쪽 뷰가 작업장 이름과 코스트센터를 각자 읽지 않게 하려는 것이다
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '준비원가 — 작업장 차원'
@ObjectModel.representativeKey : 'WorkCenter'
define view entity ZI_SetupWorkCenter
  as select from crhd as wc
  inner join crco as co on co.objty = wc.objty and co.objid = wc.objid
{
  key wc.werks as Plant,
  key wc.arbpl as WorkCenter,
      wc.verwe as Category,
      co.kostl as CostCenter,
      co.lstar as ActivityType
}

③ 로트 뷰 — 준비시간과 소모자재를 로트 한 줄로

이 글에서 가장 회사마다 달라지는 자리입니다. 오더 확정에서 준비를 어떻게 구분하는지, 준비용 소모자재를 어떤 소비로 볼지가 여기서 정해지며, 두 값 모두 확인 필요로 남겼습니다.

" ───────────────────────────────────────────────
" ZI_SetupLot — 로트(생산오더) 단위 준비시간과 소모자재
" 원천: 오더 헤더(AFKO) · 오더 확정(AFRU) · 예약(RESB)
" 준비 구분 확정 시간과 준비용 소모자재의 구분 방식은 회사마다 달라 확인 필요
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '준비원가 — 로트'
define view entity ZI_SetupLot
  as select from afko as hd
  inner join aufk as ak on ak.aufnr = hd.aufnr
{
  key hd.aufnr                          as OrderNo,
      ak.werks                          as Plant,
      hd.plnbez                         as Material,
      hd.gamng                          as LotQty,
      " 준비 구분 확정 시간(AFRU) 합계 — 확인 필요
      cast(0 as abap.dec(9,1))          as ActHours,
      " 준비용 소모자재 소비 금액(RESB 등) — 확인 필요
      cast(0 as abap.curr(15,0))        as SetupMat
}

④ 큐브 뷰 — 시간 → 원가 계산을 한 곳에서

시간에 단가를 곱하는 계산은 이 뷰에서만 합니다. 화면과 CSV, 분석 쿼리가 같은 큐브를 쓰기 때문에 숫자가 갈라지지 않습니다.

" ───────────────────────────────────────────────
" ZI_SetupCostCube — 로트 · 월 큐브
" 이 뷰에서만 시간 → 원가 계산을 한다 (식을 한 곳에 모으기 위해)
" ───────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '준비원가 큐브'
define view entity ZI_SetupCostCube
  as select from ZI_SetupLot as lt
  association [0..1] to zsetup_rate as _Rate
    on _Rate.werks = lt.Plant
{
  key lt.OrderNo,
  key lt.Plant,
      @Aggregation.default : #SUM
      lt.ActHours,
      @Semantics.amount.currencyCode : 'Currency'
      cast(lt.ActHours * _Rate.act_rate as abap.curr(15,0))                as SetupLabor,
      @Semantics.amount.currencyCode : 'Currency'
      cast(lt.ActHours * _Rate.act_rate + lt.SetupMat as abap.curr(15,0))  as SetupCost,
      _Rate.waers                                                          as Currency,
      lt.LotQty
}

⑤ 쿼리 뷰 — 화면이 바라보는 점검 쿼리

플랜트는 필수 필터로 두어 한 번에 전체 플랜트를 읽지 못하게 합니다. 화면에서 쓰는 열과 정렬 위치도 여기서 정합니다.

" ───────────────────────────────────────────────
" ZC_SetupCostQuery — 점검 쿼리
" ───────────────────────────────────────────────
@Analytics.query : true
@EndUserText.label : '준비(셋업) 원가 점검'
@UI.headerInfo : { typeName : '로트', typeNamePlural : '로트' }
define view entity ZC_SetupCostQuery
  as select from ZI_SetupCostCube
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key Plant,
  @UI.lineItem : [{ position : 10 }]
  key OrderNo,
  @UI.lineItem : [{ position : 20, criticality : 'CheckCrit' }]
  ActHours,
  @UI.lineItem : [{ position : 30 }]
  SetupCost,
  @AnalyticsDetails.query.axis : #COLUMNS
  LotQty
}

⑥ 권한 — 플랜트 단위 접근 제어

준비원가는 활동단가와 로트 원가가 함께 드러나므로 플랜트 단위로 접근을 나눕니다. 권한 오브젝트와 값은 회사의 권한 설계에 맞춰 정합니다.

" ───────────────────────────────────────────────
" 플랜트 단위 접근 제어
" ───────────────────────────────────────────────
@EndUserText.label : '준비원가 — 플랜트 권한'
@MappingRole : true
define role ZC_SETUPCOSTQUERY {
  grant select on ZC_SetupCostQuery
    where ( Plant ) = aspect pfcg_auth( C_AFKO_WRK, WERKS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

화면은 서비스 정의에 올린 쿼리만 바라봅니다. 운영에서는 이 서비스를 게시하고 manifest 의 서비스 주소만 교체합니다. 서비스 활성화는 서비스 바인딩에서 게시합니다.

" ───────────────────────────────────────────────
" 서비스 정의 — 점검 쿼리와 작업장 차원 노출
" ───────────────────────────────────────────────
@EndUserText.label : '준비(셋업) 원가 점검 서비스'
define service ZUI_SetupCost {
  expose ZC_SetupCostQuery  as LotSet;
  expose ZI_SetupWorkCenter as WorkCenterSet;
}

운영 시점에 해야 할 일

아래 아홉 가지는 코딩이 아니라 합의입니다. 개발보다 정하는 일이 많고, 합의가 끝나기 전에는 화면이 올라가도 숫자가 믿을 만해지지 않습니다.

운영 데이터로 갈 때

운영에서는 로트가 월 수천 건, 연 수만 건이 될 수 있습니다. 화면이 전체를 받아 계산하지 않도록 조회 조건을 서비스로 보내 필요한 만큼만 받게 만들었고, 집계는 큐브 뷰에서 합니다. 회계연도와 플랜트를 사실상 필수로 쓰고, 기간 조건을 함께 걸어 읽는 범위를 줄이는 것이 좋습니다. 응답 시간 기준은 회사의 데이터 규모에 맞춰 정하고, 원천 테이블의 인덱스 상태는 확인 필요입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

점검 기능

도입과 운영