품질원가 점검 — 제조원가 분석, 예방·평가·실패 비용을 품목·월별로 모아 한도에 견주고 분류가 어긋난 명세까지 한 화면에서

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

월 마감 때 품질팀과 원가팀이 가장 자주 부딪히는 질문은 이렇습니다. 품질에 쓴 돈이 제조원가의 몇 퍼센트이고, 그 돈이 예방에 쓰였습니까, 실패 뒤처리에 쓰였습니까. 같은 품질 비용이라도 검사·교육 같은 예방·평가 활동에 쓰면 미리 막는 돈이고, 스크랩·재작업·클레임·보증 수리로 나가면 이미 터진 뒤에 치르는 돈입니다. 그런데 이 비용은 코스트센터 라인, 생산오더 정산, 품질 통보에 흩어져 있어서 한 표로 모아 보려면 화면을 여러 개 열어 엑셀에서 맞추게 됩니다.

이 앱은 그 작업을 한 화면에 모읍니다. 품질 비용 명세를 예방 · 평가 · 내부실패 · 외부실패 네 범주로 나누어 품목·월별로 합산하고, 제조원가에 대한 품질원가율, 실패비용 가운데 고객에게 넘어간 외부실패 비중, 실패 비용에 견준 예방·평가 투자 수준 세 가지를 한도에 견줍니다. 하나라도 한도를 넘으면 ‘점검 필요’로 표시하고, 활동이 원래 속하는 범주와 다른 범주로 전기된 명세도 따로 가려 보여 줍니다. 관련 기준서는 없고, 대상 영역은 제조원가 분석입니다. 표준 실행은 SAP 표준 T-code 가 그대로 담당하고, 이 화면은 품질 비용을 한도에 견주는 점검 관점을 더해 확장합니다.

월 합계는 멀쩡한데 품목 안에서는 한도를 넘는다

샘플의 여섯 달 품질원가율은 월 합계로 보면 4.60%~4.98%로 한도 6.00% 안에 얌전히 들어옵니다. 그러나 같은 달을 품목·월로 풀면 유압 실린더 3월 8.46%, 4월 7.79%, 커넥터 하네스 4월 7.58%, 구동 샤프트 6월 6.75%가 한도를 넘습니다. 합계는 큰 품목의 낮은 비율에 섞여 작은 품목의 문제를 가립니다. 이 앱은 월 합계와 품목·월을 같은 화면의 다른 탭으로 두어, 합계가 괜찮을 때에도 품목 단위로 내려가 보게 합니다.

비용의 크기보다 비용이 어디서 나왔는지가 신호다

품질원가율이 한도 안이어도 구성이 나쁠 수 있습니다. 인버터 보드는 1월, 3월, 4월, 5월, 6월 다섯 달에 걸쳐 품질원가율이 4.51%~5.94%로 한도 안인데도 외부실패 비중이 51.60%~66.23%로 계속 한도 50.00%를 넘습니다. 실패 비용의 절반 넘게가 출하 뒤 고객에게서 발견된 문제라는 뜻이므로, 비율 하나만 보는 리포트로는 이 품목이 눈에 띄지 않습니다. 외부실패 비중을 별도 조건으로 둔 이유입니다.

쓴 돈이 막는 쪽에 가고 있는지도 같이 본다

예방·평가 비용은 아낄수록 좋아 보이는 항목이지만, 너무 적으면 나중에 실패 비용으로 돌아옵니다. 이 앱은 (예방 + 평가) ÷ (내부실패 + 외부실패)를 예방·평가 대 실패로 계산해 30.00% 아래로 내려가면 점검 필요로 표시합니다. 센서 브래킷 3월은 이 값이 19.72%, 커넥터 하네스 1월과 4월은 20.51%와 26.27%로 낮았습니다. 이 한도는 샘플용 가상 기준이며, 회사 기준에 맞춰 바꾸는 값입니다.

분류가 어긋난 명세는 합계에 조용히 섞여 들어간다

범주를 사람이 정해 전기하면 같은 활동이 다른 범주로 들어가는 일이 생깁니다. 샘플에는 현장 출동 비용 18,859,000원이 외부실패가 아니라 내부실패로 전기된 명세, 재검사가 평가가 아니라 내부실패 활동인데 평가로 전기된 명세 등 6건이 일부러 들어 있습니다. 합계는 맞으므로 대사로는 걸리지 않고 비율만 달라집니다. 활동 기준 범주와 전기 범주를 나란히 두고 다른 것을 ‘점검 필요(분류 확인)’로 표시하는 이유입니다.

사용 방법

1. 조회조건을 넣습니다. 회계연도(필수, 4자리)를 확인하고, 필요하면 전기 월 시작·종료, 플랜트, 품목, 품질원가 범주, 전기일, 점검 결과를 고릅니다. 고르지 않은 조건은 걸리지 않습니다(전체).
2. 조회합니다. 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 초기화 버튼은 같은 줄에 있고, 앱을 열면 기본 조건으로 한 번 자동 조회됩니다.
3. 요약을 읽습니다. 총 품질원가, 제조원가, 품질원가율, 실패비용 비중, 점검 필요 품목, 분류 확인 필요 명세, 대사 차이 건수를 위쪽 일곱 칸에서 봅니다.
4. 탭을 옮깁니다. 품목 판정에서 범주 구성, 명세, 월별 추이, 대사 결과 순서로 넘어갑니다. 탭 이름 위 숫자는 조건에 맞는 건수입니다.
5. 행을 눌러 상세를 봅니다. 표의 행을 누르면 상세 창이 열려 지표 전체와 같은 품목·월(또는 범주·월)의 명세를 보여 줍니다.
6. 내려받습니다. CSV 내려받기 버튼은 지금 보고 있는 탭의 조회 결과를 UTF-8 CSV 로 저장합니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 대사식을 먼저 세우고 샘플 데이터 전수에 돌린 결과입니다.

요약의 총 품질원가 1,642.0백만원, 제조원가 34,430.9백만원, 품질원가율 4.77%, 점검 필요 품목 12건(48개 품목·월 중 25.00%)은 별도 검증 스크립트가 데이터를 처음부터 다시 계산한 값과 같습니다. 날짜 조건 · 정렬 · 건수 · 쓰기 반영 · 집계 함수 두 개의 결과도 기대값과 맞았고, 화면은 헤드리스 브라우저에서 콘솔 에러 없이 열렸습니다.

무엇으로 만들었나

실행 화면

검증용 샘플 데이터로 실제 브라우저에서 찍은 화면 8종입니다. 화면을 누르면 크게 볼 수 있고, 화면 순서는 실제로 쓰는 순서를 따랐습니다.

처음 열었을 때

앱을 열면 올해 값으로 한 번 자동 조회됩니다. 조회조건, 요약, 표가 위에서 아래로 놓입니다.

앱을 열면 올해 값으로 자동 조회되어 품목 8개 × 6개월, 48행이 한 표에 나옵니다. 위쪽 요약에서 총 품질원가 1,642.0백만원, 제조원가 34,430.9백만원, 품질원가율 4.77%, 실패비용 비중 61.74%를 먼저 읽고, 표에서는 품목·월마다 네 범주 금액과 세 가지 비율, 점검 결과를 한 줄씩 봅니다. 점검 필요 품목 12건은 표의 점검 결과 열에서 바로 구별됩니다.

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

3월을 열고, 한 행을 파고든다

월 마감 회의에서는 한 달을 골라 걸린 품목을 보고 그 품목의 명세까지 내려갑니다.

전기 월 시작과 종료를 같은 달로 두면 그 달의 품목만 남습니다. 3월에는 유압 실린더가 품질원가율 8.46%로 한도 6.00%를 넘었고, 센서 브래킷은 외부실패 비중과 예방·평가 대 실패 두 조건이 함께 걸렸으며, 인버터 보드는 외부실패 비중 53.70%로 점검 필요가 됩니다. 한 달에 세 품목이 걸린 달이라 월 마감 회의에서 가장 먼저 열어 볼 화면입니다.

표의 행을 누르면 상세 창이 열립니다. 위에는 그 품목·월의 제조원가, 네 범주 금액, 세 가지 비율과 한도가 나오고, 아래에는 같은 품목·월에 쌓인 명세가 함께 나옵니다. 유압 실린더 3월은 한도를 넘은 비율과 그 비율을 만든 명세를 한 창에서 이어 볼 수 있어, 표준 화면을 여러 개 열어 숫자를 맞추던 수고가 줄어듭니다.

같은 데이터를 다른 묶음으로 본다

범주 구성 · 명세 · 월별 추이는 같은 명세를 범주, 활동, 월로 다시 묶어 보여 줍니다.

월별로 네 범주의 금액을 모아 총 품질원가에서 차지하는 몫과 제조원가 대비 비율을 함께 보여 줍니다. 예방 208.5백만원, 평가 419.7백만원, 내부실패 570.2백만원, 외부실패 443.5백만원이 여섯 달의 합계이며, 실패비용(내부+외부)이 총 품질원가의 61.74%를 차지합니다. 비율은 같은 달의 총 품질원가와 제조원가를 분모로 계산합니다.

398건의 품질원가 명세가 활동 · 원천 · 전기일 · 금액 · 전기 범주 · 활동 기준 범주와 함께 나옵니다. 활동이 원래 속하는 범주와 실제로 전기된 범주가 다르면 점검 필요(분류 확인)로 표시되며, 이런 명세가 6건 들어 있습니다. 전기일 시작·종료는 이 탭에서만 걸리는 조건입니다.

월 합계 기준으로 품질원가율은 4.60%에서 4.98% 사이에서 움직이고, 점검 필요 품목은 1월 2건, 2월 1건, 3월 3건, 4월 3건, 5월 1건, 6월 2건으로 여섯 달에 합계 12건입니다. 월 합계의 품질원가율은 괜찮아 보여도 품목 단위로는 한도를 넘는 달이 섞여 있다는 점을 확인하는 화면입니다.

합계가 맞는지 마지막으로 확인한다

숫자를 믿고 쓰려면 합계가 맞는지 먼저 확인해야 합니다.

네 가지 대사식은 검사 건수와 차이 건수를 보여 주고, 활동 기준 범주와 전기 범주가 다른 명세 6건은 의도적 예외로 따로 셉니다. 정합성 대사의 차이 건수가 모두 0이라는 사실과 분류 확인이 필요한 명세가 있다는 사실이 서로 섞이지 않게 하려는 구성입니다.

화면 뒤에서 일어나는 일

품목·월 한 행마다 아래 조건을 차례로 확인하고, 하나라도 걸리면 점검 필요로 표시합니다. 걸린 조건은 점검 내용 칸에 모두 적힙니다.

한도(6.00% · 50.00% · 30.00%)는 이 화면의 가상 기준값이며 회사 기준으로 바꿔 씁니다. 점검 필요는 원인을 단정하는 표시가 아니라 확인 대상을 가리는 표시이고, 최종 판단은 회사가 합니다.

산출과 대사의 순서

1. 예방 + 평가 + 내부실패 + 외부실패를 더해 품목·월의 총 품질원가를 구합니다.
2. 총 품질원가 ÷ 제조원가 × 100 으로 품질원가율을 구하고 소수 둘째 자리에서 반올림합니다.
3. 실패비용 비중, 외부실패 비중, 예방·평가 대 실패를 같은 방식으로 구해 한도와 견줍니다.
4. 명세 금액 합계가 품목 집계의 총 품질원가와 같은지, 품목 합계가 월 합계·범주 합계와 같은지 대사합니다.

조회조건

결과 컬럼

파일 구성

앱 폴더/
├─ 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/       서비스 정의 · 서비스 로직 · 데이터

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

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

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

T-code 별 연계 지점

이 앱을 도입한다고 기존 리포트를 없애야 하는 것은 아닙니다. 법정·감사 대응에 쓰는 표준 거래는 그대로 두고, 이 앱은 그 앞 단계에서 “어느 품목·월을 먼저 열어 볼 것인가”를 좁히는 용도로 쓰시면 됩니다.

분석 지표 정의

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

S/4HANA 에는 CO 전표 라인을 보는 표준 CDS 분석 뷰와 Fiori 분석 앱, Analysis for Office 같은 도구가 이미 있습니다. 이 앱은 그 도구들과 경쟁하는 것이 아니라 “품질 비용을 네 범주로 묶어 한도에 견주는 판정 규칙”이라는 한 층을 더합니다. 운영에서는 이 글의 CDS 구성처럼 ACDOCA 와 활동 매핑 테이블을 바탕으로 뷰를 만들고, 판정 규칙은 소비 뷰에서 계산해 화면은 서비스만 읽습니다. 표준 CDS 뷰의 정확한 이름과 필드는 릴리스마다 다를 수 있어, 이 글에서는 원천 테이블을 기준으로 적었고 확인이 필요한 곳에는 확인 필요로 표시했습니다.

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

CDS 구성 — 운영 데이터에 붙일 때의 뷰와 테이블

샘플에서는 서비스가 정해진 모양의 데이터를 돌려주지만, 운영에서는 ACDOCA 와 매핑 테이블 위에 CDS 뷰를 쌓아 같은 모양을 만들어야 합니다. 아래는 그 뼈대입니다. 이름과 필드 가운데 릴리스나 고객사 설정에 따라 달라질 수 있는 부분은 코드 안에 확인 필요로 적었습니다.

뷰 레이어 구성

① 매핑 테이블 — 활동 · 계정 · 범주 · 한도 · 제조원가 계정군

이 앱을 운영에 붙일 때 가장 먼저 합의해야 하는 것이 이 표들입니다. 회사마다 품질 활동의 이름과 계정 체계가 달라서, 매핑을 값으로 두어야 뷰를 바꾸지 않고 기준만 바꿀 수 있습니다.

" ─────────────────────────────────────────────────────────
" ① 매핑 테이블 5종
" 역할  : 활동·계정을 네 범주로 매핑하고 한도와 제조원가 범위를 담는다
" 이유  : 기준이 바뀔 때마다 이송을 새로 만들지 않도록 값으로 둔다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '품질 활동 → 기준 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define table zqcost_actmap {
  key mandt    : mandt not null;
  key lstar    : lstar not null;          " 활동 유형 (확인 필요 — 활동 식별 방식은 고객사별)
  std_cat      : abap.char(1);            " 1 예방 · 2 평가 · 3 내부실패 · 4 외부실패
  act_name     : abap.char(20);
}

@EndUserText.label : '전기 계정 → 전기 범주 매핑'
define table zqcost_accmap {
  key mandt    : mandt not null;
  key racct    : racct not null;          " 총계정원장 계정
  coq_cat      : abap.char(1);            " 전기 범주
}

@EndUserText.label : '품질원가 범주 이름'
define table zqcost_catmap {
  key mandt    : mandt not null;
  key coq_cat  : abap.char(1) not null;
  cat_name     : abap.char(12);           " 예방 · 평가 · 내부실패 · 외부실패
  group_name   : abap.char(24);           " 적합비용(예방·평가) · 실패비용(내부·외부)
}

@EndUserText.label : '품질원가 점검 한도'
define table zqcost_limit {
  key mandt    : mandt not null;
  key werks    : werks_d not null;        " 플랜트 (품목군 단위로 확장 가능)
  rate_limit   : abap.dec(7,2);           " 품질원가율 한도(%)   예: 6.00
  ext_limit    : abap.dec(7,2);           " 외부실패 비중 한도(%) 예: 50.00
  pf_limit     : abap.dec(7,2);           " 예방·평가 하한(%)    예: 30.00
}

@EndUserText.label : '제조원가 계정군'
define table zqcost_mfgacc {
  key mandt    : mandt not null;
  key racct    : racct not null;          " 제조원가로 볼 계정 (확인 필요)
}

② 차원 — 범주

범주 이름과 구분을 화면 곳곳에 문자열로 흩어 두면 이름이 바뀔 때 놓치는 곳이 생깁니다. 차원 뷰 하나에서 모두 읽도록 했습니다.

" ─────────────────────────────────────────────────────────
" ② ZI_QualCostCategory — 범주 차원
" 역할  : 범주 코드·이름·구분 제공
" 이유  : 화면과 집계가 같은 이름을 쓰게 한다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '품질원가 범주'
@ObjectModel.representativeKey : 'CoqCat'
@Analytics.dataCategory : #DIMENSION
define view entity ZI_QualCostCategory
  as select from zqcost_catmap
{
  key coq_cat     as CoqCat,
      cat_name    as CoqCatName,
      group_name  as GroupName
}

③ 큐브 — 명세 단위 (범주 대조까지)

명세 한 줄마다 전기 범주와 활동 기준 범주를 나란히 두고, 다르면 점검 필요(분류 확인)로 표시합니다. 이 뷰에서 정해지는 것은 “분류가 어긋난 명세를 어떻게 알아내는가”이고, 합계 대사의 출발점이기도 합니다.

" ─────────────────────────────────────────────────────────
" ③ ZI_QualCostItem — 명세 큐브
" 역할  : ACDOCA 라인을 전기 범주와 기준 범주에 붙여 한 줄씩 제공
" 이유  : 품목·월 집계의 합이 이 뷰의 합과 같다는 대사를 가능하게 한다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '품질원가 명세'
@Analytics.dataCategory : #CUBE
define view entity ZI_QualCostItem
  as select from acdoca as j
    inner join   zqcost_accmap as a on a.racct = j.racct          " 품질 비용 계정만
    left outer join zqcost_actmap as m on m.lstar = j.lstar
  association [0..1] to I_Product as _Product on _Product.Product = j.matnr
{
  key j.rldnr  as Ledger,
  key j.rbukrs as CompanyCode,
  key j.gjahr  as FiscalYear,
  key j.belnr  as AccountingDocument,
  key j.docln  as LedgerGLLineItem,
      j.poper  as FiscalPeriod,
      j.budat  as PostingDate,
      j.werks  as PlantCode,
      j.matnr  as ProductCode,
      a.coq_cat as PostedCat,                         " 전기 범주
      m.std_cat as StdCat,                            " 활동 기준 범주
      case when m.std_cat is not null and m.std_cat <> a.coq_cat
           then 'CHECK' else 'OK' end as CatCheck,    " 분류 확인 필요 여부
      @Semantics.amount.currencyCode : 'Currency'
      j.hsl     as Amount,
      j.rhcur   as Currency,
      _Product
}

④ 큐브 — 품목·월 단위 집계

네 범주를 한 번의 집계로 가로로 펼칩니다. case 로 범주별 합을 만들고 group by 로 품목·월을 묶으며, 합계 열을 따로 계산하지 않고 소비 뷰에서 더합니다. 합계의 출처를 한 곳으로 두어야 “명세 합계 = 품목 합계” 대사가 의미를 가집니다.

" ─────────────────────────────────────────────────────────
" ④ ZI_QualCostProdMonth — 품목·월 큐브
" 역할  : 명세를 품목·월로 묶어 네 범주 금액과 제조원가를 제공
" 이유  : 비율 계산의 분자(범주 합)와 분모(제조원가)를 같은 줄에 둔다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '품질원가 품목·월 집계'
@Analytics.dataCategory : #CUBE
define view entity ZI_QualCostProdMonth
  as select from ZI_QualCostItem as i
{
  key i.FiscalYear,
  key i.FiscalPeriod,
  key i.PlantCode,
  key i.ProductCode,
      i.Currency,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.PostedCat when '1' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as PreventionAmt,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.PostedCat when '2' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as AppraisalAmt,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.PostedCat when '3' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as IntFailAmt,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case i.PostedCat when '4' then i.Amount else cast( 0 as abap.curr(15,2) ) end ) as ExtFailAmt,
      sum( case i.CatCheck when 'CHECK' then 1 else 0 end ) as MisclassifiedCnt,
      count( * ) as ItemCnt
}
group by i.FiscalYear, i.FiscalPeriod, i.PlantCode, i.ProductCode, i.Currency

⑤ 쿼리 — 비율 계산과 점검 판정

이 뷰에서 판정 규칙이 정해집니다. 세 비율을 계산해 한도 테이블과 견주고, 걸린 조건을 점검 코드로 만듭니다. 화면은 이 결과만 읽으므로 한도나 규칙이 바뀌어도 화면 코드를 고치지 않습니다. 나눗셈은 분모가 0일 때를 막아 두어야 하고, 제조원가가 없는 품목·월이 생기는 경우의 처리는 도입 때 정해야 합니다.

" ─────────────────────────────────────────────────────────
" ⑤ ZC_QualCostProdQuery — 소비 쿼리
" 역할  : 품질원가율·외부실패 비중·예방평가 대 실패 계산과 한도 비교
" 이유  : 판정 규칙을 화면이 아니라 뷰에 둔다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '품질원가 품목 판정'
@Metadata.allowExtensions : true
define view entity ZC_QualCostProdQuery
  as select from ZI_QualCostProdMonth as p
    left outer join zqcost_limit as l on l.werks = p.PlantCode
    left outer join ZI_QualCostMfg as f
         on f.FiscalYear = p.FiscalYear and f.FiscalPeriod = p.FiscalPeriod
        and f.PlantCode  = p.PlantCode  and f.ProductCode  = p.ProductCode
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key p.FiscalYear,
  @Consumption.filter.selectionType : #INTERVAL
  key p.FiscalPeriod,
  @Consumption.filter.selectionType : #SINGLE
  key p.PlantCode,
  @Consumption.filter.selectionType : #SINGLE
  key p.ProductCode,
      f.MfgCost,
      p.PreventionAmt, p.AppraisalAmt, p.IntFailAmt, p.ExtFailAmt,
      ( p.PreventionAmt + p.AppraisalAmt + p.IntFailAmt + p.ExtFailAmt ) as TotalCoq,

      " 비율은 소수 둘째 자리 반올림 — 분모 0 처리는 도입 시 확정 (확인 필요)
      division( cast( ( p.PreventionAmt + p.AppraisalAmt + p.IntFailAmt + p.ExtFailAmt ) as abap.dec(15,2) ) * 100,
                cast( f.MfgCost as abap.dec(15,2) ), 2 )                        as CoqRate,
      division( cast( ( p.IntFailAmt + p.ExtFailAmt ) as abap.dec(15,2) ) * 100,
                cast( ( p.PreventionAmt + p.AppraisalAmt + p.IntFailAmt + p.ExtFailAmt ) as abap.dec(15,2) ), 2 ) as FailShare,
      division( cast( p.ExtFailAmt as abap.dec(15,2) ) * 100,
                cast( ( p.IntFailAmt + p.ExtFailAmt ) as abap.dec(15,2) ), 2 )  as ExtShare,
      division( cast( ( p.PreventionAmt + p.AppraisalAmt ) as abap.dec(15,2) ) * 100,
                cast( ( p.IntFailAmt + p.ExtFailAmt ) as abap.dec(15,2) ), 2 )  as PfRatio,

      l.rate_limit as RateLimit, l.ext_limit as ExtLimit, l.pf_limit as PfLimit,
      p.MisclassifiedCnt,
      p.ItemCnt
      " 점검 결과 : 세 비율 중 하나라도 한도를 넘거나 MisclassifiedCnt > 0 이면 '점검 필요'
      " 걸린 조건을 점검 코드(RATE · EXT · PREV)로 이어 붙이는 case 식은 지면상 생략
}

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

권한을 명세 뷰에만 걸면 품목·월 집계나 월별 합계로 다른 플랜트의 숫자가 새어 나갑니다. 소비 쿼리와 집계 큐브 양쪽에 같은 규칙을 걸었습니다. 권한 객체와 필드는 회사의 권한 설계에 맞춰 정하는 값이라 확인 필요입니다.

" ─────────────────────────────────────────────────────────
" ⑥ ZC_QualCostProdQuery 접근 제어 (DCL)
" 역할  : 사용자의 플랜트 권한 범위의 행만 읽게 한다
" 이유  : 집계 단계에서 걸어야 합계로 새지 않는다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '품질원가 플랜트 권한'
@MappingRole : true
define role ZC_QUALCOSTPRODQUERY {
  grant select on ZC_QualCostProdQuery
    where ( PlantCode ) = aspect pfcg_auth( M_MSEG_WWA, WERKS, ACTVT = '03' );
    " 권한 객체와 활동 값은 고객사 권한 설계에 따른다 (확인 필요)
}

⑦ 서비스 정의와 바인딩

마지막 단계는 뷰를 서비스로 게시하는 일입니다. 화면은 게시된 서비스 주소만 알면 되므로, 이 단계가 끝나면 화면 쪽에서는 서비스 주소만 바꿉니다. OData V2 로 게시할지 V4 로 게시할지는 화면이 쓰는 모델 종류와 맞춰야 합니다.

" ─────────────────────────────────────────────────────────
" ⑦ ZUI_QualCost — 서비스 정의와 바인딩
" 역할  : 소비 쿼리와 명세·월 집계를 OData 서비스로 노출
" 이유  : 화면과 CDS 사이의 계약을 서비스 한 곳으로 모은다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '품질원가 점검 서비스'
define service ZUI_QualCost {
  expose ZC_QualCostProdQuery as ProdCheck;
  expose ZI_QualCostItem      as CostItem;
  expose ZI_QualCostCategory  as Category;
}

" 서비스 바인딩 : 유형 OData V2 - UI, 이름 ZUI_QUALCOST_O2 로 만들고 게시 (확인 필요)
" 활성화 확인 : /IWFND/MAINT_SERVICE 또는 바인딩 화면의 게시 버튼

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

샘플은 명세 398건이지만 운영의 ACDOCA 는 수천만 건이 될 수 있습니다. 첫째, 회계연도를 필수 조건으로 두어 한 해 범위 안에서만 읽게 하고, 명세 탭은 전기 월이나 전기일로 좁힌 뒤 읽도록 안내합니다. 둘째, 품목·월 집계는 CDS 에서 매번 계산하기보다 집계 결과를 미리 쌓아 두는 방식(마감 후 배치로 적재)을 검토합니다. 셋째, 전기일 · 플랜트 · 품목에 해당하는 인덱스와 조회 조건이 실제로 쓰이는지 실행 계획으로 확인합니다. 화면의 응답 시간 기준은 조회 한 번에 몇 초 안으로 둘지 먼저 정하고 그에 맞춰 집계 위치를 고르시기 바랍니다.

자주 묻는 질문

도입을 검토하시는 분들이 자주 묻는 내용을 숫자와 산식, 화면과 조작, 분류와 예외, 도입과 운영으로 나누어 모았습니다.

숫자와 산식

화면과 조작

분류와 예외

도입과 운영