로트별 원가 편차 점검 — 같은 품목인데 로트마다 단위원가가 다른 이유를 표준·평균·원인 후보까지 한 화면에서

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

원가 마감 때 가장 자주 듣는 질문은 이렇습니다. 같은 제품인데 이 로트는 왜 더 비쌉니까. 표준원가는 한 품목에 값이 하나지만, 실제 원가는 로트마다 다릅니다. 수율이 떨어진 로트, 재료 단가가 오른 시기에 들어간 로트, 수량이 적어 경비가 나뉘는 몫이 커진 로트가 섞여 있기 때문입니다. 지금은 이 질문에 답하려고 생산오더 목록, 오더별 원가, 차이 계산, 입고 수량을 화면마다 열어 엑셀에서 맞춥니다.

이 앱은 그 작업을 한 화면에 모읍니다. 로트마다 재료비 · 노무비 · 제조경비를 양품수량으로 나눈 단위원가를 구하고, 그 값을 표준 단위원가와 같은 품목·같은 달의 평균 단위원가 두 잣대에 견줍니다. 품목별 한도를 넘은 로트는 ‘점검 필요’로 표시하고, 수율 · 재료비 · 노무비 · 소로트 경비 가운데 어느 쪽이 컸는지 원인 후보까지 붙입니다. 관련 기준서는 없고, 대상 영역은 제조원가 분석입니다. 표준 실행은 SAP 표준 T-code 가 그대로 담당하고, 이 화면은 로트를 비교하는 점검 관점을 더해 확장합니다.

표준원가만 보면 로트의 사정이 평균에 묻힌다

한 품목의 한 달 평균이 표준에 가까워도 그 안에서 로트마다 단위원가는 크게 갈릴 수 있습니다. 샘플에서 평균 단위원가가 표준에 가까운 품목·월도 최고와 최저 로트의 폭이 11%를 넘는 경우가 있습니다(구동모터 하우징 1월 폭 11.34%). 이 앱은 품목·월 평균과 폭, 변동계수를 함께 보여 주어 평균에 가려진 로트를 찾게 합니다.

달 전체가 비싸면 표준 대비 잣대만으로는 모두가 이상해 보인다

재료 단가가 오른 달에는 거의 모든 로트가 표준을 넘습니다. 그때는 ‘표준보다 비싼 로트’가 아니라 ‘다른 로트보다 유독 비싼 로트’가 확인 대상이어야 합니다. 그래서 표준 대비와 평균 대비를 나란히 두고, 둘 중 하나라도 한도를 넘으면 점검 필요로 봅니다. 한도는 품목마다 다르게 정할 수 있습니다.

원인을 가르는 첫 가설이 있어야 확인이 빨라진다

점검 필요 로트가 61건이라는 사실만으로는 어디서부터 볼지 정할 수 없습니다. 이 앱은 로트마다 원인 후보를 하나 붙이고, 후보별로 초과 원가를 모아 월별로 보여 줍니다. 샘플에서는 재료비 상승 후보의 초과 원가가 가장 크고(36.8백만원), 수율 저하(23.8백만원), 소로트 경비 분산(16.3백만원), 노무비 상승(4.2백만원) 순입니다. 후보는 규칙으로 고른 가설이며 원인을 단정하지 않습니다.

재공이 남은 로트는 해석이 달라진다

재공수량이 남은 로트는 재공 원가를 나누지 않은 채 단위원가를 구하므로, 완성 로트와 같은 눈으로 읽으면 안 됩니다. 이 앱은 그런 로트 29건을 의도적 예외로 따로 세어 차이 0건의 대사 결과와 섞이지 않게 합니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수)를 확인합니다. 전기 월 시작·종료, 품목, 플랜트, 생산 완료일, 원인 후보, 점검 결과는 선택이며 비우면 전체입니다.
2. 조회 — 조회 버튼은 조회조건 줄의 오른쪽 끝에 있고, 입력 칸에서 Enter 키를 눌러도 조회됩니다. 앱을 열면 올해 값으로 자동 조회됩니다.
3. 요약 확인 — 실제 총원가 · 표준원가 · 차이 · 점검 필요 로트 · 점검 필요 품목 · 점검 필요 로트 비율 · 대사 차이 건수 일곱 칸을 먼저 읽습니다.
4. 탭 이동 — 로트 명세 → 품목 비교 → 원인 분해 → 월별 추이 → 대사 결과 순서로 둘러봅니다.
5. 행 클릭 상세 — 로트 명세의 행을 누르면 구성 항목별 차이와 같은 품목의 다른 로트가 열립니다.
6. CSV 내려받기 — 표 오른쪽 위 버튼으로 현재 탭의 조회 결과를 저장합니다.

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

화면의 모든 숫자는 로트 237건에서 출발해 품목·월 36행, 월 6행으로 올라갑니다. 올라갈 때마다 합계가 맞는지 대사식으로 전수 검사했고, 아홉 개 식이 모두 차이 0건입니다. 열 번째는 재공이 남은 로트를 세는 의도적 예외입니다.

요약의 실제 총원가 5,134,269,357원과 표준원가 5,053,675,200원, 점검 필요 로트 61건(25.74%)은 별도 검증 스크립트가 데이터를 처음부터 다시 계산한 값과 같습니다. 서비스 쪽에서도 날짜 조건 · 정렬 · 건수 · 쓰기 반영 · 집계 함수 두 개(점검 필요 로트 비율 평균 25.64%, 품목 폭 최댓값 12.84%)가 기대값과 맞았고, 화면은 헤드리스 브라우저에서 콘솔 에러 없이 열렸습니다.

무엇으로 만들었나

실행 화면

아래 8장은 실제 브라우저에서 앱을 열어 찍은 화면입니다. 숫자는 가상의 샘플 데이터이며, 사용 순서대로 배열했습니다.

처음 열었을 때

앱을 열면 조회가 자동으로 실행되어 올해 로트 전체가 나옵니다.

앱을 열면 올해 값으로 자동 조회되어 로트 237개가 한 표에 나옵니다. 위쪽 요약에서 실제 총원가 5,134.3백만원, 표준원가 5,053.7백만원, 표준 대비 +80.6백만원, 점검 필요 로트 61건과 비율 25.74%를 먼저 읽고, 표에서는 양품수량 · 수율 · 단위원가 · 표준 대비 차이율을 한 줄씩 봅니다. 기본 정렬은 전기 월 · 품목 · 로트 번호입니다.

조건으로 좁히기

품목, 전기 월, 플랜트, 생산 완료일, 원인 후보, 점검 결과로 범위를 좁힙니다.

품목과 점검 결과를 고르고 오른쪽 끝의 조회 버튼을 누르면 조건에 맞는 로트만 남습니다(이 예에서는 4건). 입력 칸에서 Enter 키를 눌러도 조회되고, 초기화 버튼은 처음 조건으로 되돌립니다. 요약 일곱 칸도 같은 조건으로 다시 계산되므로, 표와 요약이 서로 다른 범위를 보는 일이 없습니다.

같은 품목끼리 견주고, 원인을 가른다

로트 명세 다음 두 탭은 같은 로트들을 다른 묶음으로 보여 줍니다. 품목 비교는 ‘평균에서 얼마나 퍼졌나’를, 원인 분해는 ‘초과 원가가 어느 후보에서 나왔나’를 답합니다.

한 품목의 한 달을 한 줄로 묶어 평균 단위원가 · 표준 단위원가 · 최고와 최저 로트 단위원가 · 최고-최저 폭 · 변동계수 · 점검 필요 로트 수를 보여 줍니다. 평균이 표준에 가까워도 폭이 크면 로트마다 사정이 다르다는 뜻이라, 평균만 보면 놓치는 품목을 여기서 찾습니다. 한 로트라도 한도를 넘으면 그 품목·월은 '점검 필요'로 표시됩니다.

점검 필요 로트의 초과 원가를 원인 후보 다섯 가지로 나눠 월별로 보여 줍니다. 로트 수와 초과 원가, 월 안에서 차지하는 비중, 그 후보를 고른 판정 기준이 한 줄씩 나옵니다. 후보는 규칙으로 고른 것일 뿐 원인을 단정하지 않습니다. 비중이 큰 후보부터 현업이 확인할 순서를 정하는 용도입니다.

한 로트 안으로 들어가기

의심스러운 로트는 행을 눌러 구성 항목까지 내려갑니다.

로트 명세에서 행을 누르면 상세 창이 열립니다. 재료비 · 노무비 · 제조경비를 원/개 단위로 표준과 견준 차이, 점검 코드와 점검 내용, 같은 품목 같은 달의 다른 로트가 나란히 나옵니다. 이 로트만의 문제인지 그 달 그 품목 전체의 문제인지가 여기서 갈립니다. 닫기 버튼으로 표로 돌아갑니다.

월과 합계로 다시 확인하기

마지막으로 달별 흐름과 대사 결과로 위에서 본 숫자가 맞는지 확인합니다.

여섯 달을 한 줄씩 보여 줍니다. 점검 필요 로트 비율이 가장 높은 달은 4월(36.84%)과 2월(35.00%)이고, 6월(17.50%)과 3월(17.07%)이 낮습니다. 비율이 20% 이상이면 그 달을 '점검 필요'로 표시하므로, 마감 회의에서는 높은 달부터 로트 명세로 내려가 보면 됩니다.

대사식 아홉 개는 모두 차이 0건입니다. 열 번째 줄은 재공수량이 남은 로트 29건을 세는 의도적 예외라서 차이 건수가 아니라 예외 건수로 따로 읽습니다. 요약의 '대사 차이 건수'는 이 탭의 차이 건수를 그대로 가져온 값입니다.

화면 뒤에서 일어나는 일

화면이 하는 일은 조회조건을 필터로 바꿔 서비스에 보내고, 돌아온 행을 표에 올리는 것까지입니다. 단위원가 · 차이율 · 평균 · 원인 후보 · 점검 결과는 모두 서비스가 계산해 두고, 화면은 요약 칸을 만들 때 행을 합산할 뿐 판정은 다시 하지 않습니다. 같은 조건으로 다섯 탭이 동시에 조회되므로 탭끼리 범위가 어긋나지 않습니다.

점검 판정 규칙

샘플 237건은 정상 176건, 점검 필요 61건(표준 대비만 초과 49건, 두 한도 모두 초과 12건)입니다.

조회조건

‘전체’를 고르면 그 조건은 필터로 보내지 않습니다. 같은 필드에 시작과 끝을 거는 조건은 한 묶음(and)으로 보내, 범위가 풀려 전 기간이 통과하는 일이 없게 했습니다.

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조회조건과 요약 칸이 줄바꿈됩니다. 표는 가로 스크롤로 열 폭을 지킵니다.

창이 좁아지면 조회조건이 여러 줄로 나뉘고 요약 칸도 줄바꿈됩니다. 표는 칸을 줄이지 않고 가로 스크롤을 열어 숫자가 잘리지 않게 합니다. 조회 버튼은 조회조건 영역에서 벗어나지 않습니다.

파일 구성

앱 폴더/
├─ index.html · Component.js · manifest.json     진입점과 서비스 선언
├─ view/        Main.view.xml · DetailDialog.fragment.xml
├─ controller/  Main.controller.js · BaseController.js
├─ model/       formatter.js · ErrorHandler.js
├─ css/ · i18n/ 스타일과 문구
├─ media/       소개 영상과 포스터
└─ odata/       서비스 정의(메타데이터) · 서비스 로직 · 데이터 5종

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 두고, 로트를 서로 견주는 자리만 이어 붙이는 방향으로 만들었습니다.

표준으로 되는 것과 이 앱이 더하는 것

T-code 별 연계 지점

운영 전환 때 ‘기존 리포트를 없애야 하나’라는 질문에는 없애지 않는다가 답입니다. 표준 거래는 그대로 쓰고, 이 화면은 마감 전 점검 단계에 얹어 씁니다. 법정 · 감사 대응 숫자는 표준에서 만든 값을 씁니다.

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

이 앱은 소비(Consumption) 수준의 CDS 쿼리를 OData 로 게시해 읽습니다. 같은 CDS 뷰는 Fiori 분석 앱이나 Analysis for Office 에서도 그대로 읽을 수 있으므로, 이 화면과 분석 도구가 서로 다른 숫자를 만들지 않습니다. 표준에서 제공하는 원가 분석 CDS 뷰를 쓸 수 있는지는 시스템별로 확인이 필요한 부분이라, 이 글에서는 원천 테이블 기준으로 뷰를 새로 스케치했습니다.

분석 지표 정의

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

CDS 구성 — 원천 테이블에서 소비 쿼리까지

샘플 화면은 가상 데이터에서 읽지만, 운영에서는 아래 뷰들이 같은 모양의 데이터를 만들어 줍니다. 표준 CDS 뷰 대신 원천 테이블(생산오더 헤더·품목, CO 라인 아이템, 자재 평가)에서 출발한 스케치이며, 필드 매핑은 시스템별로 확인 필요입니다.

뷰 레이어 구성

① 한도 테이블

품목마다 한도를 담는 매핑 테이블입니다. 한도가 달라지는 것은 화면이나 뷰가 아니라 회사 기준 때문이므로 값만 바꾸면 되게 따로 두었습니다. 운영에서는 품목군 단위로 한도를 두고 예외 품목만 따로 적는 방식도 씁니다.

" ─────────────────────────────────────────────────────────
" ① ZLOTC_LIMIT — 품목별 점검 한도 (매핑 테이블)
" 역할  : 표준 대비·평균 대비 한도를 품목마다 담는다
" 이유  : 한도가 코드에 박혀 있으면 기준이 바뀔 때마다 이송이 필요하다.
"         값은 테이블에 두고 뷰는 읽기만 한다.
" ─────────────────────────────────────────────────────────
@EndUserText.label : '로트 원가 점검 한도'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define table zlotc_limit {
  key mandt    : mandt not null;
  key matnr    : matnr not null;
  var_limit    : abap.dec(7,2);   " 표준 대비 한도(%)
  spread_limit : abap.dec(7,2);   " 평균 대비 한도(%)
}

② 원가요소 매핑 테이블

재료비 · 노무비 · 제조경비는 원가요소를 묶어 만든 개념이라 회사마다 묶음이 다릅니다. 이 표 하나가 이 앱과 표준 원가 보고서가 같은 숫자를 만드는 열쇠이며, 도입에서 가장 먼저 합의해야 하는 항목입니다.

" ─────────────────────────────────────────────────────────
" ② ZLOTC_CELEM — 원가요소 → 구성 항목 매핑
" 역할  : 원가요소(KSTAR)를 재료비·노무비·제조경비로 묶는다
" 이유  : 회사마다 원가요소 체계가 다르다. 매핑만 바꾸면 뷰는 그대로다.
" ─────────────────────────────────────────────────────────
@EndUserText.label : '원가요소 구성 항목 매핑'
define table zlotc_celem {
  key mandt : mandt not null;
  key kstar : kstar not null;
  elem_type : abap.char(1);       " M 재료비 · L 노무비 · O 제조경비
}

③ 오더별 구성 항목 원가

CO 라인 아이템에서 실제 값(값 유형)만 골라 오더별로 합산합니다. 이 뷰가 오더 원가 합산의 유일한 자리라서, 합산 조건이 바뀌면 여기만 고칩니다.

" ─────────────────────────────────────────────────────────
" ③ ZI_LotCostElem — 오더별 구성 항목 원가
" 역할  : CO 라인 아이템(실제 값)을 오더·구성 항목별로 합산한다
" 이유  : 합산 규칙(값 유형·버전)을 이 뷰 한 곳에만 둔다.
" ─────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
define view entity ZI_LotCostElem
  as select from coep
    inner join aufk on aufk.objnr = coep.objnr
    inner join zlotc_celem as map on map.kstar = coep.kstar
{
  key aufk.aufnr                                         as LotNo,
      sum(case map.elem_type when 'M' then coep.wtgbtr else 0 end) as MatCost,
      sum(case map.elem_type when 'L' then coep.wtgbtr else 0 end) as LabCost,
      sum(case map.elem_type when 'O' then coep.wtgbtr else 0 end) as OhCost
}
where coep.wrttp = '04'            " 실제 값
  and coep.versn = '000'
group by aufk.aufnr

④ 로트 큐브

로트 한 줄을 만듭니다. 단위원가는 합계를 양품수량으로 나눈 값이며 0 나누기를 피하려고 division 함수를 씁니다. 재공수량은 투입에서 양품과 불량을 뺀 파생값입니다.

" ─────────────────────────────────────────────────────────
" ④ ZI_LotCostBase — 로트 한 줄 (큐브)
" 역할  : 수량 · 구성 항목 원가 · 단위원가 · 표준 대비를 한 줄로 만든다
" 이유  : 로트가 가장 낮은 집계 단위라, 위 모든 뷰가 이 뷰를 읽는다.
" ─────────────────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_LotCostBase
  as select from aufk
    inner join afpo on afpo.aufnr = aufk.aufnr
    inner join afko on afko.aufnr = aufk.aufnr
    inner join ZI_LotCostElem as el on el.LotNo = aufk.aufnr
    inner join mbew on mbew.matnr = afpo.matnr and mbew.bwkey = aufk.werks
{
  key aufk.aufnr                                   as LotNo,
      afpo.matnr                                   as ProdCode,
      aufk.werks                                   as PlantCode,
      afko.gltri                                   as LotDate,
      @Semantics.quantity.unitOfMeasure: 'Unit'
      afpo.wemng                                   as GoodQty,
      afpo.psmng - afpo.wemng - afpo.psamg         as WipQty,
      afpo.meins                                   as Unit,
      @Semantics.amount.currencyCode: 'Currency'
      el.MatCost + el.LabCost + el.OhCost          as TotalCost,
      aufk.waers                                   as Currency,
      cast(
        division( el.MatCost + el.LabCost + el.OhCost, afpo.wemng, 2 )
        as abap.dec(13,2) )                        as UnitCost,
      cast( mbew.stprs / mbew.peinh as abap.dec(13,2) ) as StdUnitCost
}

⑤ 품목·월 평균

같은 품목·같은 달의 가중 평균과 최고·최저를 구합니다. 평균 대비 차이율과 최고-최저 폭의 기준이 되므로 별도 뷰로 분리했습니다.

" ─────────────────────────────────────────────────────────
" ⑤ ZI_LotCostAvg — 품목·월 평균 단위원가
" 역할  : 같은 품목·같은 달 로트의 총원가 합계 ÷ 양품수량 합계
" 이유  : 단순 평균은 소로트에 휘둘린다. 가중 평균을 한 번만 계산해 둔다.
" ─────────────────────────────────────────────────────────
define view entity ZI_LotCostAvg
  as select from ZI_LotCostBase
{
  key ProdCode,
  key substring( cast( LotDate as abap.char(8) ), 1, 6 ) as YearMonth,
      division( sum( TotalCost ), sum( GoodQty ), 2 )     as AvgUnitCost,
      max( UnitCost )                                     as MaxUnit,
      min( UnitCost )                                     as MinUnit,
      count( * )                                          as LotCnt
}
group by ProdCode, substring( cast( LotDate as abap.char(8) ), 1, 6 )

⑥ 점검 판정

두 잣대와 한도로 점검 결과를 정하고 원인 후보를 붙입니다. 판정 경계가 바뀌면 이 뷰 하나만 이송하면 됩니다.

" ─────────────────────────────────────────────────────────
" ⑥ ZI_LotCostJudge — 한도와 원인 후보
" 역할  : 두 잣대와 한도로 점검 결과를, 규칙 순서로 원인 후보를 붙인다
" 이유  : 판정 규칙(3%p · 60% 같은 경계)을 이 뷰 한 곳에만 둔다.
" ─────────────────────────────────────────────────────────
define view entity ZI_LotCostJudge
  as select from ZI_LotCostBase as b
    inner join ZI_LotCostAvg  as a on a.ProdCode = b.ProdCode
    inner join zlotc_limit    as l on l.matnr    = b.ProdCode
{
  key b.LotNo,
      b.ProdCode,
      division( ( b.UnitCost - b.StdUnitCost ) * 100, b.StdUnitCost, 2 ) as VarRate,
      division( ( b.UnitCost - a.AvgUnitCost ) * 100, a.AvgUnitCost, 2 ) as SpreadRate,
      case
        when abs( division( ( b.UnitCost - b.StdUnitCost ) * 100, b.StdUnitCost, 2 ) ) > l.var_limit
          or abs( division( ( b.UnitCost - a.AvgUnitCost ) * 100, a.AvgUnitCost, 2 ) ) > l.spread_limit
        then 'CHECK' else 'OK'
      end as CheckStatus
      " 원인 후보(UNDR → LYLD → SMLT → MATP/LABR 순)는 같은 방식의 case 로 이어 붙인다
}

⑦ 소비 쿼리

화면이 실제로 읽는 모양입니다. 필수 필터와 표시 순서를 주석으로 두어 화면 요구를 계산 뷰와 분리합니다.

" ─────────────────────────────────────────────────────────
" ⑦ ZC_LotCostQuery — 화면이 읽는 소비 쿼리
" 역할  : 필터 · 정렬 · 표시 주석을 붙여 서비스에 내보낼 모양으로 만든다
" 이유  : 화면 요구(어떤 필드로 거르나)를 계산 뷰와 분리한다.
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
@UI.headerInfo: { typeName: '로트', typeNamePlural: '로트' }
define view entity ZC_LotCostQuery
  as projection on ZI_LotCostJudge
{
  @UI.lineItem: [{ position: 10 }]
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key LotNo,
  @Consumption.filter.selectionType: #SINGLE
  ProdCode,
  @UI.lineItem: [{ position: 20 }]
  VarRate,
  @UI.lineItem: [{ position: 30 }]
  SpreadRate,
  @Consumption.filter.selectionType: #SINGLE
  CheckStatus
}

⑧ 접근 제어와 서비스

플랜트 단위 권한을 집계 뷰에도 겁니다. 서비스 정의는 소비 쿼리를 엔티티셋으로 게시하며, 게시 후 화면의 서비스 주소만 바꿉니다.

" ─────────────────────────────────────────────────────────
" ⑧ 접근 제어와 서비스 정의
" 역할  : 플랜트 단위 권한과 서비스 게시
" 이유  : 집계 뷰에도 권한이 걸려야 합계로 다른 플랜트가 드러나지 않는다.
" ─────────────────────────────────────────────────────────
@EndUserText.label: '로트 원가 점검 접근 제어'
@MappingRole: true
define role ZC_LotCostQuery {
  grant select on ZC_LotCostQuery
    where ( PlantCode ) = aspect pfcg_auth( M_MATE_WRK, WERKS, ACTVT = '03' );
}

@EndUserText.label: '로트 원가 점검 서비스'
define service ZUI_LotCost {
  expose ZC_LotCostQuery as LotSet;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

생산오더가 연간 수십만 건이 되면 평균과 변동계수 같은 집계는 조회 때마다 계산하지 않고 마감 시점에 한 번 만들어 두는 편이 안전합니다. 조회 범위(회계연도 · 전기 월)를 필수 조건으로 두고, 오더 번호와 플랜트에 인덱스를 확인하며, 화면은 필요한 행만 가져오고 전체 건수만 따로 받는 방식을 유지합니다. 응답 시간 기준은 도입 전에 현업과 먼저 합의하시기 바랍니다.

자주 묻는 질문

도입을 검토하시는 분들이 가장 많이 묻는 25가지를 주제별로 묶었습니다.

숫자와 산식

원인 후보와 예외

화면과 조작

도입과 운영