외주가공비 점검 — 관리회계, 외주 입고 라인의 단가·불량·부대비용 차이를 표준 외주가공비와 견주고 원가 편입액까지 대사하는 월마감 화면

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

매월 말, 원가 담당자는 같은 질문을 받습니다. “외주 가공비가 표준보다 얼마나 더 나갔고, 그 차이는 단가 때문인가 불량 때문인가?” 외주처가 청구한 금액은 구매오더 단위로 쌓이는데, 그 금액이 표준 가공단가와 어디서 갈라졌는지, 원가에는 같은 금액이 들어갔는지를 확인하려면 구매오더, 입고 문서, 송장, 오더 원가 분석을 차례로 열어 엑셀에서 맞춰 봐야 합니다.

이 앱은 그 맞춤 작업을 한 화면에 올립니다. 외주 입고 라인마다 실적 가공단가에 (합격 입고수량 + 가공비를 지급한 불량수량)을 곱해 가공 단가분을 구하고 부대비용(운반·포장)을 더해 실적 외주가공비를 만듭니다. 이를 표준 가공단가 × 합격 입고수량 + 표준 부대비용인 표준 외주가공비와 견주어 원가 차이를 단가 차이, 불량 지급분, 부대비용 차이로 나눕니다. 마지막으로 계산액과 원가에 실제 편입된 금액을 월·원가 구분별로 대조합니다. 대상 영역은 제조원가 분석이며, 특정 기준서의 요구사항을 점검하는 화면이 아니라 내부 관리용 점검 도구입니다.

외주 구매오더는 있는데 표준 대비 차이는 따로 계산하게 된다

표준 화면은 구매오더의 단가와 수량, 입고 문서, 송장 검증, 오더 원가 분석을 각각 보여 줍니다. 네 화면의 숫자가 왜 다른지는 결국 사람이 맞춰 봐야 합니다. 이 앱은 표준 외주가공비 + 원가 차이 = 실적 외주가공비, 원가 차이 = 단가 차이 + 불량 지급분 + 부대비용 차이라는 두 줄의 식으로 이를 이어 붙이고, 136개 입고 라인 전부에서 성립하는지 매번 검산해 보여 줍니다.

합계에서는 단가 차이가 묻힌다

이 표본의 6개월 합계로 보면 실적 외주가공비 332.3백만 원이 표준 327.9백만 원보다 4.4백만 원(+1.3%) 많을 뿐입니다. 평균만 보면 “대체로 괜찮다”입니다. 그러나 입고 라인으로 쪼개면 단가 차이율이 -8.34%에서 +10.76%까지 벌어져 있고, 외주처 × 월로 보면 5월 C 도금의 원가 차이율은 +10.6%로 한도 ±6%를 넘습니다. 합계에서는 서로 상쇄되어 보이지 않던 값이 외주처별 집계 탭에서는 점검 필요로 바로 떠오릅니다.

불량 지급분은 따로 보지 않으면 단가에 섞인다

외주 가공 중 불량이 나도 가공비는 외주처에 지급하는 경우가 있습니다. 이 표본에서는 합격 입고 230,480EA에 더해 1,283EA의 불량 가공비를 24개 라인에서 지급했고, 금액으로는 +1.7백만 원입니다. 이 몫이 단가 차이에 섞이면 외주처의 단가 협상과 품질 책임이 한 숫자에 뭉칩니다. 이 앱은 불량 지급분 금액을 단가 차이 금액과 따로 보여 주고, 외주처별 불량 지급률이 한도 2%를 넘는 곳을 점검 필요로 표시합니다.

원가 편입액이 계산액과 다른 달을 따로 찾아야 한다

입고와 송장이 맞아도 원가에 편입된 금액이 다를 수 있습니다. 이 표본에서는 12개 월 × 원가 구분 가운데 다섯 곳에서 편입액이 계산액과 달랐고, 가장 큰 것은 3월 가공 단가분 +881,229원입니다. 원인을 단정할 수는 없지만, 어느 구매오더에서 어긋났는지까지 한 화면에서 좁혀 줍니다.

조회만 되는 리포트는 금방 안 열린다

숫자만 보여 주고 끝나는 리포트는 이상한 숫자를 만나는 순간 멈춥니다. 이 앱은 월 → 외주처 → 품목·공정 → 입고 라인으로 한 단계씩 내려가고, 표의 행을 누르면 상세 창이 열려 계산 과정을 보여 주며, 현재 탭의 결과를 CSV 로 내려받을 수 있습니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 확인하고 필요하면 전기 월 시작·종료, 외주처, 품목, 점검 결과를 고릅니다. 비워 두면 전체입니다.
2. 조회 — 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 화면을 처음 열 때 한 번 자동 조회됩니다.
3. 요약 확인 — 위쪽 타일에서 실적 · 표준 외주가공비, 원가 차이, 단가 차이 · 불량 지급분 · 부대비용 차이, 점검 필요 건수, 대사 차이 건수를 봅니다.
4. 탭 이동 — 외주 가공 명세 → 외주처별 집계 → 품목·공정별 집계 → 원가 편입 대사 → 월별 추이 → 대사 결과 순서로 넓은 범위에서 근거까지 오갑니다.
5. 행 클릭 상세 — 표의 행을 누르면 상세 창이 열려 그 행의 값과 해당 입고 라인 목록을 보여 줍니다.
6. 내보내기 — 현재 탭의 결과를 UTF-8 CSV 로 내려받습니다.

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

화면이 보여 주는 숫자가 서로 맞는지는 화면 안의 대사 결과 탭에서 검산합니다. 여덟 가지 식을 총 568건 검사해 차이 0건이었습니다. 점검 필요로 표시되는 건수는 의도적으로 기준을 벗어나게 넣은 값이며 대사 차이와는 다릅니다.

대사 결과 탭의 R09는 원가 편입액이 계산액과 다른 라인 5건을 별도로 보여 주며, 대사 차이 건수 0과 섞이지 않게 구분합니다.

무엇으로 만들었나

실행 화면

아래 화면은 가상의 외주처 6곳(A 표면처리 · B 열처리 · C 도금 · D 코팅 · E 전자실장 · F 정밀가공)과 가상의 단가로 만든 검증용 샘플 데이터(2026년 1~6월)를 실제로 조회한 모습입니다. 입고 라인 136건, 외주처 × 월 36건이며 실제 고객사 값이 아닙니다.

처음 열었을 때와 조건 조회

처음 열었을 때 한 번 자동 조회되고, 조건을 바꿔 다시 조회하는 흐름입니다.

열면 자동으로 한 번 조회됩니다. 맨 위 조회조건은 회계연도 · 전기 월 시작/종료 · 외주처 · 품목 · 점검 결과 다섯 칸이고 기본값은 2026년 전체입니다. 요약 지표는 실적 외주가공비 332.3 · 표준 외주가공비 327.9 · 원가 차이 +4.4 · 단가 차이 금액 +2.3 · 불량 지급분 금액 +1.7 · 부대비용 차이 +0.3(이상 백만 원) · 점검 필요 입고 라인 34 · 점검 필요 외주처 6 · 대사 차이 건수 0 순서로 읽습니다. 표는 입고 라인 한 줄에 구매오더 한 품목이 놓이며, 입고 수량 · 단가 차이율 · 실적과 표준 외주가공비 · 원가 차이 · 점검 결과가 이어집니다. 탭 이름 옆 숫자는 조회된 건수로 입고 라인 136 · 외주처 36 · 품목·공정 48 · 원가 편입 12 · 월 6 · 대사 9입니다.

조회조건은 입력 칸에서 Enter 를 누르거나 오른쪽 끝의 조회 버튼을 누르면 서비스로 전달됩니다. 점검 필요만 고르면 탭 건수가 입고 라인 34 · 외주처 6 · 품목·공정 5 · 원가 편입 5 · 월 5로 줄고, 요약 지표도 같은 범위로 다시 계산되어 실적 97.8 · 표준 93.9 · 원가 차이 +3.9(백만 원)가 됩니다. 비워 둔 칸은 “전체”라는 값을 보내지 않고 조건 자체를 만들지 않습니다. 초기화 버튼은 조회 버튼 옆에 있고 모든 칸을 기본값으로 되돌립니다.

외주처에서 품목·공정으로 — 차이가 어디서 났는지

외주처 기준으로 불량과 원가 차이를 보고, 같은 차이가 어느 품목·공정에 몰렸는지 이어서 봅니다.

외주처 6곳 × 6개월 36행입니다. 불량 지급률 한도는 2%, 원가 차이율 한도는 ±6%이며, 여섯 행이 점검 필요입니다. 2월 E 전자실장(원가 차이율 +6.9%, 불량 지급률 2.4%)과 5월 C 도금(+10.6%, 3.4%)은 두 기준을 함께 넘었고, 4월에는 A 표면처리 2.8% · B 열처리 2.7% · F 정밀가공 3.0%가 불량 지급률만 넘었습니다. 6월 C 도금은 원가 차이율 +8.1%만 넘었습니다. 합계로 보면 평온한 6개월이 외주처 × 월로 쪼개면 서로 다른 이유로 걸리는 것을 확인할 수 있습니다.

품목 8개와 외주 공정을 6개월로 펼친 48행입니다. 평균 실적 가공단가를 표준 가공단가와 나란히 두고, 외주비 비중(제조원가 중 외주 몫)을 품목별 한도와 견줍니다. 원가 차이율 한도 ±5%를 넘은 행은 다섯 개로, 2월 제어반 조립체(+6.9%), 4 · 5 · 6월 철제 프레임(+5.7% · +10.6% · +6.8%), 6월 수지 커버(+8.8%)입니다. 철제 프레임의 용융아연도금 공정이 석 달 연속 걸린다는 점이 이 탭에서 한눈에 드러납니다.

원가 편입 대사와 월별 추이

계산액과 원가에 들어간 금액을 맞춰 보고, 달 단위로 이상한 곳을 찾는 흐름입니다.

월 × 원가 구분(가공 단가분 · 부대비용) 12행입니다. 계산액은 입고 라인의 실적 외주가공비를 모은 값이고, 편입액은 원가에 실제로 얹힌 금액입니다. 둘이 다른 행이 다섯 개로 1월 부대비용 -90,100원 · 2월 가공 단가분 -322,560원 · 3월 가공 단가분 +881,229원 · 4월 가공 단가분 -71,200원 · 6월 부대비용 -38,500원이며, 각각 한 개 입고 라인이 만든 차이입니다. 5월은 두 구분 모두 일치합니다.

월 실적 외주가공비는 1월 53.5 · 2월 50.9 · 3월 58.4 · 4월 51.7 · 5월 59.6 · 6월 58.1(백만 원)입니다. 원가 차이율은 1월 -0.03%에서 5월 +2.22%까지 오르내리지만 모두 작아 보이고, 그 안에서 단가 차이 · 불량 지급분 · 부대비용 차이가 서로 상쇄하기도 합니다. 점검 필요 월은 편입 차이가 있는 1 · 2 · 3 · 4 · 6월 다섯 개이며 5월만 정상입니다. 달을 먼저 고른 뒤 외주처 · 품목 · 편입 탭으로 내려가 원인을 좁힙니다.

근거 내려가기와 대사 결과

행을 눌러 계산 과정을 보고, 마지막으로 화면의 숫자가 서로 맞는지 대사 결과로 확인합니다.

표의 행을 누르면 상세 창이 열립니다. 이 화면의 1월 입고 라인(D 코팅, 도어 패널, 입고 2,460EA)은 표준 가공단가 2,300원에 실적 2,257원(-1.87%)이라 단가 차이 금액이 -105,780원이고, 부대비용은 표준 84,900원 대비 실적 90,100원으로 +5,200원입니다. 가공 단가분 5,552,220원에 부대비용을 더한 실적 외주가공비 5,642,320원이 표준 5,742,900원보다 100,580원 적습니다. 그런데 원가 편입액이 계산액보다 90,100원 모자라 편입 차이로 표시됩니다.

여덟 가지 정합성 식(R01~R08)의 검사 건수가 라인 136건 · 월 6건 단위로 나열되고 차이 건수는 모두 0입니다. 맨 아래 R09는 의도적으로 넣은 예외로, 원가 편입액이 계산액과 다른 라인이 5건임을 보여 주며 대사 차이 건수와 분리해 집계합니다. 계산이 서로 맞는데도 값이 기준을 벗어난 곳이 점검 대상이라는 구분이 이 탭에서 드러납니다.

화면 뒤에서 일어나는 일

외주가공비는 다섯 단계로 흘러갑니다. 각 단계의 결과가 다음 단계의 입력이 되므로, 어느 단계에서 숫자가 어긋나는지가 대사식으로 바로 드러납니다.

1. 가공 단가분 — 가공 단가분 = 실적 가공단가 × (합격 입고수량 + 가공비를 지급한 불량수량).
2. 실적 — 실적 외주가공비 = 가공 단가분 + 실적 부대비용(운반 · 포장).
3. 표준 — 표준 외주가공비 = 표준 가공단가 × 합격 입고수량 + 표준 부대비용.
4. 차이 — 원가 차이 = 실적 − 표준 = 단가 차이 금액 + 불량 지급분 금액 + 부대비용 차이 금액.
5. 편입 대사 — 계산액(실적 외주가공비)과 원가 편입액을 월 · 원가 구분별로 견주어 편입 차이를 구합니다.

마지막으로 외주처 합계, 품목·공정 합계, 월 합계, 편입 대사의 계산액 합계가 모두 전사 실적 외주가공비와 같아야 합니다. 이 식이 R04~R07이고, 라인 단위의 분해식이 R01~R03입니다.

점검 판정 규칙

판정 결과는 “점검 필요”와 “정상” 두 가지입니다. 원인을 단정하지 않고 확인할 자리만 알려 줍니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 줄바꿈되어 위아래로 쌓이고, 요약 타일은 두 줄로 접히며, 표는 가로 스크롤로 전환됩니다. 상세 창은 화면 너비에 맞춰 줄어듭니다. 데스크톱을 기준으로 설계했으며 태블릿에서도 쓸 수 있습니다.

파일 구성

index.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
service/     서비스 정의 · 샘플 데이터 6종

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 구매오더 · 입고 · 송장 · 오더 원가 분석은 표준에 그대로 두고, 그 결과를 표준 가공단가와 원가 편입액 위에서 다시 맞춰 보는 자리만 이어 붙였습니다.

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

T-code 별 연계 지점

운영 전환 시 기존 리포트를 없앨 필요는 없습니다. 법정 · 감사 대응은 표준 보고서와 원장에 남겨 두고, 이 앱은 월마감 전에 이상한 외주처와 라인을 먼저 골라내는 조회 전용 화면으로 곁에 둡니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 임의의 축으로 합계를 돌려 보는 데 강합니다. 이 앱은 그 위에서 “실적 = 표준 + 단가 + 불량 + 부대비용”과 “편입액 = 계산액”이라는 업무 규칙을 판정 코드로 올려 둔 점검 화면입니다. 같은 CDS 큐브를 두 곳이 함께 쓰면 분석 쿼리와 이 앱의 숫자가 갈라지지 않습니다.

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

분석 지표 정의표

CDS 구성

화면이 부르는 OData 서비스는 아래 CDS 뷰 위에 올라갑니다. 입고 실적 · 불량 지급분 · 원가 편입액 · 표준 가공단가를 서로 다른 뷰에서 받아 큐브에서 한 번만 계산하고, 화면 · CSV · 분석 쿼리가 모두 같은 큐브를 쓰도록 나눴습니다. 표준 CDS 뷰 이름은 확인된 것만 쓰고, 확인하지 못한 곳은 원천 테이블 기준으로 적고 “확인 필요”로 남겼습니다.

뷰 레이어 구성

① 표준 가공단가 · 한도 기준 테이블 — 값은 코드가 아니라 테이블에 둔다

표준 가공단가는 품목 · 외주 공정마다, 기간마다 다르고 한도는 점검 항목마다 다릅니다. 이 값이 코드에 박혀 있으면 단가 개정 때마다 개발이 필요합니다. 두 개의 기준 테이블로 나누면 현업이 값만 바꿔 같은 쿼리를 다시 돌릴 수 있고, 값이 비어 있을 때 표준 금액이 0 으로 계산되는 문제를 점검 코드로 걸러낼 수 있습니다.

" ───────────────────────────────────────────────
" 표준 가공단가 기준 — 품목 · 외주 공정 · 유효시작일
" 표준 외주가공비 = 표준 가공단가 × 합격 입고수량 + 표준 부대비용
" 값을 기간별로 관리하고 코드에 박지 않기 위해 나눈다
" ───────────────────────────────────────────────
@EndUserText.label : '외주 표준 가공단가'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zoutsrc_std {
  key client     : abap.clnt not null;
  key matnr      : matnr not null;
  key vornr      : abap.char(4) not null;   " 외주 공정 번호
  key valid_from : datum not null;
  std_price      : abap.curr(9,2);          " 표준 가공단가(1개당)
  std_frt        : abap.curr(13,2);         " 표준 부대비용(운반 · 포장)
  waers          : waers;
}

@EndUserText.label : '외주가공비 점검 한도'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zoutsrc_lim {
  key client     : abap.clnt not null;
  key valid_from : datum not null;
  price_lim      : abap.dec(5,2);           " 단가 차이율 한도(%)
  frt_lim        : abap.dec(5,2);           " 부대비용 차이 한도(표준금액 대비 %)
  vendor_rej_lim : abap.dec(5,2);           " 외주처 불량 지급률 한도(%)
  vendor_var_lim : abap.dec(5,2);           " 외주처 원가 차이율 한도(%)
  prod_var_lim   : abap.dec(5,2);           " 품목 원가 차이율 한도(%)
}

② 차원 뷰 — 외주처

외주처 이름과 그룹은 공급업체 마스터(LFA1)에서 읽습니다. 집계 뷰가 마스터를 직접 조인하지 않도록 차원 뷰로 분리하면, 외주처 이름이 바뀌어도 한 곳만 고치면 됩니다.

" ───────────────────────────────────────────────
" ZI_OutsrcVendor — 외주처 차원
" 공급업체 마스터를 한 번만 읽어 이름과 그룹을 내준다
" 집계 뷰가 마스터 구조를 모르게 하기 위해 나눈다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Outsourcing vendor'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #MASTER }
define view entity ZI_OutsrcVendor
  as select from lfa1
{
  key lfa1.lifnr as VendorNo,
      lfa1.name1 as VendorName,
      lfa1.ktokk as VendorGroup
}
-- 사업장별 이름은 구매 조직 데이터(LFM1)에서 연결한다. 표준 CDS 뷰 이름은 확인 필요

③ 입고 실적 뷰 — 구매오더 품목별 입고 수량과 실적 가공단가

구매오더 품목의 단가와 입고 수량을 한 줄로 모읍니다. 입고 수량은 입고 이력(EKBE)에서 합격분만 합산하고, 단가는 구매오더 품목의 순가격을 가격단위로 나눕니다. 이 뷰의 가공 단가분 합계가 대사식 R03의 우변을 만듭니다.

" ───────────────────────────────────────────────
" ZI_OutsrcReceipt — 외주 입고 실적
" 구매오더 품목별 합격 입고수량과 실적 가공단가를 모은다
" 구매 데이터와 재고 데이터를 한 뷰에서 섞지 않으려고 따로 둔다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Outsourcing receipt'
@Analytics.dataCategory: #FACT
define view entity ZI_OutsrcReceipt
  as select from I_PurchaseOrderItemAPI01 as po
  inner join ekbe as gr
    on  gr.ebeln = po.PurchaseOrder
    and gr.ebelp = po.PurchaseOrderItem
{
  key po.PurchaseOrder        as PoNo,
  key po.PurchaseOrderItem    as PoItem,
      po.Supplier             as VendorNo,
      po.Material             as ProdCode,
      po.DocumentCurrency     as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      cast( po.NetPriceAmount as abap.curr(9,2) ) as ActPrice,
      @Semantics.quantity.unitOfMeasure: 'OrderUnit'
      sum( gr.menge )         as RcvQty,
      po.PurchaseOrderQuantityUnit as OrderUnit
}
where gr.vgabe = '1'
group by po.PurchaseOrder, po.PurchaseOrderItem, po.Supplier, po.Material,
         po.DocumentCurrency, po.NetPriceAmount, po.PurchaseOrderQuantityUnit
-- 입고 이력 필드(vgabe = 1: 입고)는 EKBE 기준이며 표준 CDS 뷰 이름은 확인 필요

④ 불량 지급 뷰 — 가공비를 지급한 불량 수량

불량이 나도 가공비를 지급하는 수량은 회사마다 처리 방식이 다릅니다. 이 뷰는 불량 처리 문서에서 지급 대상 수량만 모아 입고 라인에 붙입니다. 이 뷰가 비어 있으면 불량 지급분이 0으로 나오므로, 원천을 먼저 합의해야 합니다.

" ───────────────────────────────────────────────
" ZI_OutsrcRejectPaid — 가공비 지급 불량 수량
" 불량으로 판정됐지만 가공비를 지급하는 수량만 모은다
" 단가 차이와 불량 지급분을 따로 보이기 위해 뷰를 분리한다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Outsourcing paid reject'
@Analytics.dataCategory: #FACT
define view entity ZI_OutsrcRejectPaid
  as select from ekbe as rj
{
  key rj.ebeln                as PoNo,
  key rj.ebelp                as PoItem,
      @Semantics.quantity.unitOfMeasure: 'Uom'
      sum( rj.menge )         as PaidRejQty,
      rj.meins                as Uom
}
where rj.vgabe = '1'
  and rj.shkzg = 'H'                -- 지급 대상 불량 처리 표시. 회사 기준에 따라 조건을 바꾼다
group by rj.ebeln, rj.ebelp, rj.meins
-- 불량 지급 판정 조건은 회사마다 다르다. 확인 필요

⑤ 원가 편입 뷰 — 오더에 실제로 얹힌 금액

원가 개별 항목(COEP)에서 외주 가공 단가분과 부대비용에 해당하는 원가 구분의 금액을 월 · 구매오더 단위로 모읍니다. 계산액과 이 뷰의 금액을 견주는 것이 원가 편입 대사입니다.

" ───────────────────────────────────────────────
" ZI_OutsrcPosted — 원가 편입액
" 오더에 귀속된 외주 가공 단가분 · 부대비용 원가를 모은다
" 원가 구분 코드로 두 가지를 가른다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Outsourcing posted cost'
@Analytics.dataCategory: #FACT
define view entity ZI_OutsrcPosted
  as select from coep as ce
  inner join zoutsrc_ce as mp
    on mp.kstar = ce.kstar
{
  key ce.gjahr                  as FiscalYear,
  key ce.perbl                  as FiscalPeriod,
  key ce.objnr                  as OrderObject,
  key mp.cost_part              as CostPart,      " PROC(가공 단가분) · FRT(부대비용)
      ce.twaer                  as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( ce.wtgbtr )          as PostAmount
}
group by ce.gjahr, ce.perbl, ce.objnr, mp.cost_part, ce.twaer
-- 원가요소(kstar)와 원가 구분 매핑 테이블은 회사 계정 체계에 맞춰 만든다. 확인 필요

⑥ 큐브 — 라인별 실적 · 표준 외주가공비와 차이 분해

입고 실적, 불량 지급, 표준 기준, 원가 편입을 한 곳에서 합쳐 실적 · 표준 외주가공비와 세 가지 차이를 한 번만 계산합니다. R01~R03의 등식이 이 큐브에서 성립합니다.

" ───────────────────────────────────────────────
" ZI_OutsrcLineCube — 외주가공비 라인 큐브
" 가공 단가분 · 실적 · 표준 외주가공비와 단가 · 불량 · 부대비용 차이를 계산한다
" 화면 · CSV · 분석 쿼리가 모두 이 큐브를 읽는다
" ───────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Outsourcing cost line cube'
@Analytics.dataCategory: #CUBE
define view entity ZI_OutsrcLineCube
  as select from ZI_OutsrcReceipt as r
  left outer join ZI_OutsrcRejectPaid as j
    on j.PoNo = r.PoNo and j.PoItem = r.PoItem
  left outer join zoutsrc_std as s
    on s.matnr = r.ProdCode
{
  key r.PoNo, key r.PoItem, r.VendorNo, r.ProdCode,
      r.RcvQty,
      coalesce( j.PaidRejQty, 0 )                                   as PaidRejQty,
      r.ActPrice,
      s.std_price                                                   as StdPrice,
      r.ActPrice * ( r.RcvQty + coalesce( j.PaidRejQty, 0 ) )       as ProcAmt,
      s.std_price * r.RcvQty + s.std_frt                            as StdAmt,
      ( r.ActPrice - s.std_price ) * r.RcvQty                       as PriceVarAmt,
      r.ActPrice * coalesce( j.PaidRejQty, 0 )                      as QtyVarAmt
}
-- 부대비용 · 원가 편입액은 같은 방식으로 붙인다. 표준 가공단가가 비면 StdAmt 가 0 이 되므로 점검 코드로 걸러낸다

⑦ 소비 뷰 — 판정 코드를 붙여 서비스로 내보낸다

큐브의 값에 판정 코드와 UI 주석을 붙입니다. 한도는 기준 테이블에서 읽으므로 값이 바뀌어도 이 뷰는 그대로입니다. 화면 전용 필드(점검 결과 문구 등)를 큐브에서 떼어 두는 자리이기도 합니다.

" ───────────────────────────────────────────────
" ZC_OutsrcLineCheck — 외주가공비 점검 쿼리
" 판정 코드(PRC · REJ · FRT · POST)와 UI 주석을 붙여 서비스로 내보낸다
" 한도는 기준 테이블에서 읽는다
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Outsourcing cost line check'
@OData.publish: false
define view entity ZC_OutsrcLineCheck
  as select from ZI_OutsrcLineCube as c
  inner join zoutsrc_lim as l
    on l.valid_from <= $session.system_date
{
  @UI.lineItem: [{ position: 10 }] key c.PoNo,
  @UI.lineItem: [{ position: 20 }] key c.PoItem,
  @UI.lineItem: [{ position: 30 }] c.VendorNo,
  @UI.lineItem: [{ position: 40 }] c.RcvQty,
  @UI.lineItem: [{ position: 50 }] c.PriceVarAmt,
  case when c.StdPrice = 0 then 0
       else division( ( c.ActPrice - c.StdPrice ) * 100, c.StdPrice, 2 )
  end                                                       as PriceVarRate,
  case when abs( ( c.ActPrice - c.StdPrice ) * 100 / c.StdPrice ) > l.price_lim then 'PRC'
       when c.PaidRejQty > 0 then 'REJ'
       else ''
  end                                                       as CheckCode
}

⑧ 접근 제어(DCL)와 서비스 정의 — 권한은 집계 단계에서 건다, OData V2 로 게시

권한은 큐브와 쿼리에 걸어 합계로 새지 않게 합니다. 서비스 정의에는 화면이 쓰는 엔티티셋만 노출하고, 바인딩을 OData V2 로 만들어 화면 manifest 의 서비스 주소가 이 한 곳을 가리키게 합니다.

" ───────────────────────────────────────────────
" ZI_OutsrcLineCube 접근 제어 · 서비스 정의
" 구매 조직 권한을 큐브에 건다
" 화면이 쓰는 엔티티셋만 서비스에 노출한다
" ───────────────────────────────────────────────
@EndUserText.label: 'Outsourcing cost line cube access'
@MappingRole: true
define role ZI_OutsrcLineCube {
  grant select on ZI_OutsrcLineCube
    where ( VendorNo ) = aspect pfcg_auth( M_BEST_EKO, EKORG, ACTVT = '03' );
}

@EndUserText.label: 'Outsourcing cost check service'
define service ZUI_OutsrcCostCheck {
  expose ZC_OutsrcLineCheck as LineSet;
  expose ZC_OutsrcVendorCheck as VendorSet;
  expose ZC_OutsrcProdCheck as ProdSet;
  expose ZC_OutsrcPostCheck as PostSet;
  expose ZC_OutsrcMonthCheck as MonthSet;
  expose ZC_OutsrcRecon as ReconSet;
}
-- 서비스 바인딩은 OData V2 - UI 유형으로 만든다. 권한 오브젝트와 값은 회사 권한 설계에 맞춘다(확인 필요)

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

구매오더와 입고 이력이 수천만 건이면 라인 단위로 매번 전체를 집계할 수 없습니다. 회계연도와 기간을 필수 조건으로 두고, 외주처 · 품목 집계는 월 단위로 미리 모아 두며, 큐브는 구매오더 키 위에 인덱스를 두어 조회 범위를 좁힙니다. 응답 시간 기준(예: 월 1개 기간 조회가 수 초 안)은 도입 단계에서 합의하는 항목이고, 이 글의 수치는 검증용 샘플 기준이라 운영 성능을 보장하지 않습니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

분석과 대사

도입과 운영