SAP BOM·라우팅 설계변경 통합 관리 — 설계변경 뒤 남은 구성품 재고를 평가·정리·대사까지 한 화면에서

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

BOM이나 라우팅이 바뀌면 이전 구성품은 하루아침에 쓸 곳이 줄어듭니다. 현업이 부딪히는 질문은 늘 같습니다. 이 변경 때문에 얼마가 남았나, 다른 곳에 쓰거나 소진할 수 있나, 정리한다면 누가 승인하나. 지금은 변경 번호는 표준 화면에서, 재고는 다른 T-code에서, 평가와 정리는 엑셀과 메일 승인으로 나뉘어 있어 월말에 이 셋을 맞추는 일이 따로 생깁니다. 이 앱은 세 질문을 변경 건이라는 하나의 묶음에 붙여, 확인 · 평가 · 승인 · 정리 · 대사를 한 화면 체계에서 처리하게 합니다.

재고 평가와 관련한 회계 기준의 구체 요구사항 매핑은 이 글에서 확인하지 못해 확인 필요로 두었고, 앱은 점검이 필요한 항목을 보여 줄 뿐 위반 여부를 판정하지 않습니다.

핵심 포인트 여덟 가지

사례로 보는 효과

샘플 데이터 2026년 1월~9월 영향 원가는 898,880,557원이고 이 가운데 790,786,000원(88%)이 다른 용도로 소진되었으며 33,045,034원이 정리되고 75,049,523원이 잔존 재고로 남았습니다. 세 숫자를 더하면 영향 원가와 같습니다. 계획 대비로는 +33,108,695원(3.8%)이며, 요인으로 가르면 시간당 영향 원가가 +16,230,553원으로 가장 크고 소진율 +7,338,081원, 물량 +6,119,597원, 재작업 시간 +3,420,464원이 뒤따릅니다. 네 요인의 합과 총차이의 차이는 0원입니다. 대사 규칙 네 가지는 176건을 점검해 의도적으로 넣어 둔 예외 10건만 남겼고, 큐브 합계와 원천 라인 합계의 차이는 측정값 8종 모두 0입니다.

도입하면 달라지는 것

• 변경 건마다 남은 재고와 영향 금액을 목록에서 바로 확인합니다.
• 평가·정리 문서가 승인 단계까지 같은 화면에서 처리됩니다.
• 월말 대사는 예외 10건만 보면 되고 조치 기록이 남습니다.
• 차이가 나면 요인과 원천 문서 라인까지 내려가 이유를 찾습니다.

이런 회사에 맞습니다

BOM · 라우팅 설계변경이 잦은 제조 회사로, 변경 뒤 구 구성품 재고의 평가와 정리를 엑셀과 메일로 처리하고 있는 곳에 맞습니다. 사업장이 둘 이상이거나 문서에 승인 단계가 있어 작성자와 승인자를 나눠야 하는 생산 · 원가 · 경영지원 조직이라면 효과가 큽니다. 표준 화면은 그대로 두고 변경 건 단위의 점검 관점을 더하려는 SAP 운영 조직에도 맞습니다.

실행 화면

사용 방법

1. 조회조건 입력 — 위쪽 조회조건 영역에서 사업장(선택)과 기간(필수)을 정합니다. 사용자 선택에서 역할을 바꿔 볼 수 있습니다.
2. 조회 버튼 · Enter — 조회조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 초기화 버튼은 같은 줄에 있습니다.
3. 요약 확인 — 개요 · 할 일의 타일에서 잔존 재고, 처리 대기, 승인 대기, 대사 예외 건수를 봅니다.
4. 탭 · 축 이동 — 왼쪽 메뉴로 기준정보 → 문서 → 일괄 실행 → 대사 → 분석 → 연계 → 감사 순서로 이동합니다. 분석에서는 차원 칩을 행 · 열 칸에 놓습니다.
5. 행 · 셀 클릭 상세 — 목록의 행을 누르면 오른쪽에 상세가 열리고, 분석의 값 칸을 누르면 원천 문서 라인이 열립니다.
6. 내보내기 — 목록 위의 CSV 버튼과 분석의 PowerPoint 버튼으로 현재 결과를 내려받습니다.

무엇으로 만들었나

처음 열었을 때 — 숫자와 할 일이 먼저 보인다

사업장과 기간을 정해 조회하면 타일이 갱신됩니다. 타일을 누르면 해당 목록으로 이동하고, 숫자는 모두 서버가 집계한 값입니다. 기본 기간은 올해 1월부터 오늘이 속한 달까지입니다.

"내 역할 것만" 을 켜면 현재 사용자의 역할이 처리할 일만 남습니다. 할 일을 누르면 그 문서 화면으로 바로 갑니다. 알림 보고는 에이전트를 실행한 뒤에 채워집니다.

기준정보 관리 — 변경 건과 평가 규칙을 한곳에서

변경 건 · 내용 · 사업장 · 유형 · 상태 · 영향 수량 · 소진 수량 · 장부 잔존 재고가 한 줄에 보입니다. 상태가 진행 · 유효 적용 · 마감 가운데 어디인지가 정리 문서를 만들 수 있는지를 정합니다.

저장하면 서버가 값을 검사합니다. 수정 전후 값은 이력으로 남고 감사 로그에도 같은 내용이 기록됩니다. 관리자 역할에게만 버튼이 켜집니다.

변경 이력이 없으면 없다고 알려 줍니다. 수정이나 사용 중지 처리를 하면 이 목록에 행이 생깁니다.

품목 · 변경 유형 · 영향 수량 · 구 구성 단가 · 개시일 · 이름이 필수입니다. 빠진 값은 저장 전에 알려 줍니다.

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

한 줄에 변경 건과 품목, 전표일, 금액, 상태가 보입니다. 오른쪽에 상세가 열려도 목록은 그대로 남아 이어서 다음 문서를 고를 수 있습니다.

정리 문서는 유효 적용 상태이면서 진행 중인 정리 문서가 없는 변경 건만 고를 수 있습니다. 금액은 변경 건의 잔존재고에서 서버가 계산합니다.

차변 설계변경 손실, 대변 구성품 재고가 같은 금액으로 나옵니다. 검토 요청 · 승인 · 반려 · 확정 · 역처리 버튼은 서버가 알려 준 상태와 내 역할에 맞는 것만 보입니다.

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

시뮬레이션과 실행은 같은 조건을 씁니다. 실행 이력과 로그, 만들어진 문서가 같은 화면 아래에 이어집니다.

합계 2,176,801원을 확인한 뒤 실행하면 같은 금액의 문서가 생깁니다. 시뮬레이션을 거치지 않은 실행과 같은 조건의 재실행은 서버가 거절합니다.

대사와 예외 조치 — 차이는 남기되 조치 기록을 붙인다

R01 75건, R02 32건, R03 62건, R04 7건을 점검해 차이 10건이 나옵니다. 모두 의도적으로 넣어 둔 예외라 조치 흐름을 시험할 수 있습니다.

장부 잔존 재고 차이나 유효 적용 변경 건의 미정리 잔액은 조정 문서로 풀 수 없을 수 있어, 사유 기록이나 보류로 처리합니다. 조치 뒤 재대사하면 해소로 바뀝니다.

분석 — 축을 바꿔도 합계가 변하지 않는다

영향 원가를 기본 측정값으로 보여 줍니다. 값 칸을 누르면 그 금액을 만든 원천 문서 라인이 열려 합계가 같은지 바로 확인됩니다.

행↔열 바꾸기나 칩 이동 뒤에도 총합은 변하지 않습니다. 이미 읽어 둔 큐브를 브라우저에서 다시 묶기 때문입니다.

같은 차원 안의 값은 또는, 서로 다른 차원 사이는 그리고로 묶입니다. 적용 후 조회를 누르면 그 범위로 다시 읽습니다.

계획 8.66억 원, 실적 8.99억 원, 총차이 +3,311만 원이며 요인 네 개를 더하면 총차이와 같다는 검산 줄이 매번 표시됩니다.

AI 분석과 에이전트 — 숫자는 서버가, 해설은 그 위에서

요약, 핵심 발견, 근거 표 순서입니다. 금액과 비율은 서버가 큐브에서 계산한 값이고, 해설은 점검 필요 항목을 알려 주는 참고 자료입니다. 표 아래 버튼으로 PowerPoint 보고서를 받습니다.

하루 한 번 제한이 있어 같은 날 두 번째 실행은 활동 기록만 남기고 판정을 건너뜁니다.

레이아웃 — 만든 배치를 다시 쓴다

기본 레이아웃으로 지정하거나 자동 조회로 열도록 고를 수 있습니다.

새로 고친 뒤에도 저장한 레이아웃이 남아 있어 다시 열면 같은 배치로 시작합니다.

영역 간 연계 — 문서에서 문서로 이동한다

설계변경 건에서 시작한 문서가 어떤 후속 문서로 이어졌는지 보이고, 문서를 누르면 그 상세로 이동합니다.

이력 · 감사 · 역할 — 누가 무엇을 했는지 남는다

누가 언제 무엇을 바꿨는지가 변경 전후 값과 함께 남습니다. 조회조건으로 사용자와 결과를 좁힐 수 있습니다.

버튼을 숨기는 데서 끝나지 않고, 직접 요청해도 서버가 같은 이유로 거절합니다.

좁은 화면에서 달라지는 것

가로폭이 좁아져도 같은 기능을 씁니다.

표 대신 카드형 목록으로 바뀌어 한 손으로도 문서를 찾을 수 있습니다.

화면 뒤에서 일어나는 일

문서는 서비스 안에서 상태 규칙 표를 따라서만 움직입니다. 판정 조건에서 결과 상태, 사용자 조치까지를 아래 표로 정리했습니다.

처리 단계의 산출 · 대사식은 다음과 같습니다.

1. 잔존 재고 = 영향 발생 − 소진 대체 − 정리액 (변경 건별)
2. 진부화 충당 = 경과 구간별 잔존 재고 × 충당률
3. 정리 문서 = 차변 설계변경 손실, 대변 구성품 재고(차대 일치)
4. 큐브 합계 = 원천 문서 라인 합계(측정값 8종)
5. 대사 규칙 R01~R04

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 왼쪽 메뉴가 접히고 타일과 목록이 한 칸씩 쌓입니다. 분석의 차트는 숨기지 않고 표 아래로 내려가며, 축 조합이 상한을 넘으면 안내가 뜹니다.

파일 구성

index.html · Component.js · manifest.json
controller/  화면별 컨트롤러 9개 + 공통
view/        화면별 뷰 9개 + 대화상자 15종
model/       formatter · 오류 처리 · 권한 · 큐브 · 차트 · 보고서 · 레이아웃 · 엑셀
odata/       서비스 정의 · 서비스 로직 · 샘플 데이터
media/       소개 영상

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

표준 실행은 SAP 표준 T-code가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

운영 전환 때 기존 리포트를 없앨 필요는 없습니다. 표준 화면은 그대로 두고 두 화면의 숫자를 대사 지점(MB52의 재고와 이 앱의 장부 잔존 재고)에서 맞춰 보며, 법정 · 감사 · 세무 신고 대응은 표준에 남겨 둡니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱과는 대체가 아니라 나란히 쓰는 관계입니다. 표준 분석 앱이 재고와 이동 데이터를 보여 주는 자리라면, 이 앱은 변경 건이라는 묶음 단위의 평가·정리·대사를 더합니다. 특정 Fiori 앱의 이름은 확인하지 못해 적지 않았고 확인 필요로 둡니다. Analysis for Office 같은 도구에서 같은 큐브를 열도록 분석 쿼리를 공개하는 방법은 CDS 구성 절의 쿼리 뷰에 있습니다.

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

분석 지표 정의표

CDS 구성

운영 데이터로 갈 때의 구조입니다. 객체 이름과 필드는 스케치이며 실제 시스템에서 확인 필요입니다.

뷰 레이어 구성

원천테이블과 필드 매핑

① 경과 구간 충당률 매핑 테이블 — ZDSG_AGING_RT

충당률이 코드가 아니라 테이블에 있어야 현업이 기준을 바꿀 수 있습니다. 구간 번호, 경과 일수 범위, 충당률을 둡니다.

@EndUserText.label : '경과 구간 충당률'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdsg_aging_rt {
  key client   : abap.clnt not null;
  key bucket   : abap.char(1) not null;
  from_days    : abap.int4;
  to_days      : abap.int4;
  rate_pct     : abap.dec(5,2);
  active       : abap_boolean;
}

② 기준 뷰 — ZI_DsgChange

변경 마스터와 변경 대상 객체를 변경 건 단위로 묶습니다. 변경 번호가 키이고 유효 시작일이 정리 시점을 정합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '설계변경 건 기준'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #M, dataClass: #MASTER }
define view entity ZI_DsgChange
  as select from aenr as c
    inner join aeoi as o on o.aennr = c.aennr
{
  key c.aennr  as ChangeNo,
      c.datuv  as EffDate,
      o.werks  as Plant,
      o.matnr  as Material,
      c.aetxt  as ChangeText
}

③ 원천 라인 뷰 — ZI_DsgCostLine

영향 발생, 소진 대체, 정리 라인을 같은 모양으로 맞춰 큐브와 드릴스루가 같은 줄에서 나오게 합니다. 금액 필드는 통화 코드와 함께 둡니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '변경 영향 원가 라인'
define view entity ZI_DsgCostLine
  as select from zdsg_line as l
  association [1..1] to ZI_DsgChange as _Chg on _Chg.ChangeNo = $projection.ChangeNo
{
  key l.docno    as DocNo,
  key l.itemno   as ItemNo,
      l.period   as Period,
      l.plant    as Plant,
      l.changeno as ChangeNo,
      l.material as Material,
      l.aging    as AgingDays,
      @Semantics.amount.currencyCode: 'Currency'
      l.imp_amt  as ImpAmt,
      @Semantics.amount.currencyCode: 'Currency'
      l.use_amt  as UseAmt,
      @Semantics.amount.currencyCode: 'Currency'
      l.dsp_amt  as DspAmt,
      l.currency as Currency,
      _Chg
}

④ 차원 뷰 — ZI_DsgAgingDim

경과 일수를 구간 1·2·3으로 바꾸는 규칙을 한곳에 둡니다. 충당률 테이블과 조인해 구간별 충당률도 함께 줍니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '경과 구간 차원'
define view entity ZI_DsgAgingDim
  as select from ZI_DsgCostLine as l
    left outer join zdsg_aging_rt as r
      on  l.AgingDays >= r.from_days
      and l.AgingDays <= r.to_days
{
  key l.DocNo,
  key l.ItemNo,
      case when r.bucket is null then '1' else r.bucket end as Aging,
      coalesce( r.rate_pct, 0 )                             as RatePct
}

⑤ 큐브 뷰 — ZC_DsgCube

차원 조합별로 측정값을 합칩니다. 화면의 피벗과 드릴스루 합계가 같아야 하므로 집계는 여기서만 합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@EndUserText.label: '설계변경 영향 원가 큐브'
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZC_DsgCube
  as select from ZI_DsgCostLine as l
    inner join ZI_DsgAgingDim as a on a.DocNo = l.DocNo and a.ItemNo = l.ItemNo
{
  @AnalyticsDetails.query.axis: #ROWS
  l.Period,
  l.Plant,
  l.ChangeNo,
  l.Material,
  a.Aging,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  l.ImpAmt,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  l.UseAmt,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  l.DspAmt,
  l.Currency,
  cast( cast( l.ImpAmt as abap.dec(17,2) ) * a.RatePct / 100 as abap.dec(17,2) ) as RsvAmt
}

⑥ 분석 쿼리 뷰 — ZC_DsgCubeQuery

화면과 분석 도구가 같은 쿼리를 쓰도록 행·열·필터 기본값을 정합니다. 기간과 사업장은 조회조건으로 둡니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.query: true
@EndUserText.label: '설계변경 영향 원가 분석'
define view entity ZC_DsgCubeQuery
  as select from ZC_DsgCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  Period,
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #MULTIPLE }
  Plant,
  @AnalyticsDetails.query.axis: #COLUMNS
  Aging,
  @AnalyticsDetails.query.axis: #COLUMNS
  ImpAmt,
  @AnalyticsDetails.query.axis: #COLUMNS
  UseAmt,
  @AnalyticsDetails.query.axis: #COLUMNS
  DspAmt
}

⑦ 권한 정의 — ZC_DsgCube

사업장 단위로 접근을 제한합니다. 권한 객체와 필드 이름은 확인 필요이며 운영 시점에 보안 담당과 정합니다.

@EndUserText.label: '설계변경 큐브 사업장 권한'
@MappingRole: true
define role ZC_DsgCube {
  grant select on ZC_DsgCube
    where ( Plant ) = aspect pfcg_auth( ZDSG_PLNT, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의와 처리 액션 — ZUI_DsgChange

화면이 부르는 서비스를 하나로 모읍니다. 승인과 확정 같은 처리 펑션은 RAP 액션으로 옮기는 자리입니다.

@EndUserText.label: '설계변경 통합 관리 서비스'
define service ZUI_DsgChange {
  expose ZC_DsgCube          as CubeSet;
  expose ZC_DsgCubeQuery     as QuerySet;
  expose ZI_DsgChange        as ChangeSet;
  expose ZI_DsgCostLine      as LineSet;
}

// 처리 액션은 RAP 동작 정의에 둡니다 — 이름과 파라미터는 확인 필요
managed implementation in class zbp_dsg_doc unique;
define behavior for ZR_DsgDoc alias Doc
{
  action Submit;
  action Approve;
  action Reject parameter ZA_DsgReason;
  action Post;
  action Reverse parameter ZA_DsgReason;
}

운영 시점에 해야 할 일

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

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

대사 예외 10건은 조치 흐름을 시험하려고 넣은 의도적 예외이며, 큐브 합계와 원천 라인의 차이는 0입니다. 독립 계산으로 다시 돌린 R01과 R03은 서비스 결과와 건수 · 차이가 같았습니다. 샘플 데이터 값입니다.

운영 데이터로 갈 때

지금은 큐브를 브라우저에서 다시 묶는 구조라 행 수에 상한이 있습니다. 문서 라인이 수천만 건이면 집계를 서버 쪽 CDS로 옮기고 기간과 사업장을 조회 필수 파라미터로 두며, 큐브 키 차원에 인덱스를 둡니다. 응답 시간 목표는 운영 시점에 정할 일입니다.

자주 묻는 질문

도입 전에 가장 많이 물을 만한 질문을 네 묶음, 25문항으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영