IAS 16 정기 대수선·부품 교체 원가 자본화 점검 — 자본화액과 직전 장부금액 제거까지 원장과 맞춰 보는 설비 월마감

개발 배경 — 이 앱을 사용해야 하는 이유

설비를 가진 회사의 월마감에는 해마다 같은 질문이 돌아옵니다. 이번 달 정비 지출 가운데 자본화할 몫은 얼마이고 비용으로 둘 몫은 얼마인가, 새 대수선 원가를 올리면서 직전 대수선과 교체한 부품의 장부금액은 함께 걷어냈는가, 그렇게 다시 계산한 설비 장부금액이 원장과 맞는가. IAS 16 유형자산(K-IFRS 제1016호)은 정기적인 대수선과 부품 교체 원가를 인식 요건을 채울 때 장부금액에 포함하고, 그때 직전 원가의 장부금액은 제거하라는 방향을 제시합니다. 문제는 이 세 질문의 답이 정비 오더 조회 · 자산 이력 · 감가상각 화면 · 엑셀로 흩어져 있다는 점입니다.

지금 방식은 대개 이렇습니다. 정비 오더 실적을 내려받아 지출 종류를 손으로 나누고, 자산 이력에서 직전 원가와 누적상각을 찾아 붙이고, 설비별로 기초 + 자본화 − 제거 − 상각 = 기말을 다시 맞춘 뒤 원장 기말 장부금액과 비교합니다. 건수가 적을 때는 버티지만, 한 달에 설비 열 대 · 지출 스무 건만 되어도 어느 건이 어느 단계에서 어긋났는지 찾는 데 마감 시간을 씁니다.

이 앱은 그 자리를 한 화면으로 메웁니다. 지출 한 건마다 인식 요건 두 가지를 읽어 자본화 재계산액과 비용 재계산액을 다시 나누고, 자본화된 건에는 직전 잔여 장부금액을 제거액으로 계산해 원장과 견줍니다. 결과는 점검 코드 하나로 붙고, 설비별 · 종류별 집계와 대사 결과가 같은 숫자에서 나옵니다. 이 화면은 분류 · 집계 · 대사를 돕는 점검 도구이며, 인식 요건의 충족 여부와 최종 회계 판단은 회사와 감사인이 합니다.

자본화 판단이 건마다 흩어지면 월마감 막판에 뒤집힌다

같은 정비 오더라도 일상 수선이면 비용이고, 정기 대수선이나 법정 검사 · 부품 교체이면서 미래 경제적 효익이 유입될 가능성이 있고 원가를 신뢰성 있게 측정할 수 있으면 자본화 후보가 됩니다. 이 판단 결과가 원장에는 이미 들어가 있는데, 같은 기준으로 다시 나눠 본 숫자가 따로 없으면 확인은 마감 직전의 엑셀 작업이 됩니다. 이 앱은 지출 건마다 입력된 두 요건 값(예 · 아니오)을 그대로 읽어 자본화 재계산액을 만들고, 원장 자본화액과의 차이를 점검 코드 R01 · R03 · R04 로 나눠 보여 줍니다.

새 원가를 올릴 때 옛 원가가 남아 있는지는 따로 봐야 한다

대수선 원가를 새로 자본화하면 직전 대수선 원가 가운데 아직 상각되지 않은 몫이 장부에 남아 이중으로 잡히기 쉽습니다. 이 앱은 직전 잔여 장부금액을 직전 원가 − 직전 누적상각으로 계산해 자본화 재계산액이 있는 건의 제거 재계산액으로 삼고, 부품 교체는 교체한 부품별 잔여 장부금액을 합산합니다. 원장 제거액과 다르면 R02 로 표시합니다. 직전 원가를 알 수 없을 때 어떤 추정 방식을 쓸지는 회사의 정책이라 확인 필요 항목으로 남겨 두었습니다.

설비 장부금액 롤포워드가 맞아야 건별 점검이 의미를 갖는다

건별 점검이 모두 정상이어도 설비의 기초 장부금액에 자본화를 더하고 제거와 상각을 뺀 기말이 원장 기말과 다르면 어딘가에 빠진 거래가 있습니다. 설비별 집계 탭은 그 롤포워드를 설비마다 보여 주고 R05 로 차이를 표시합니다. 같은 설비의 지출 건 점검 결과와 함께 보도록 설계해, 차이의 원인을 건 단위로 좁혀 갈 수 있습니다.

사용 방법

1. 조회조건 입력 — 기준 연월(6자리, 필수)을 확인합니다. 설비 · 지출 종류 · 점검 코드 · 점검 결과는 선택이며 비워 두면 전체입니다.
2. 조회 — 조회조건 줄 맨 오른쪽의 조회 버튼을 누르거나 기준 연월 입력 칸에서 Enter 키를 누릅니다. 화면을 처음 열면 기본 기준 연월로 자동 조회합니다.
3. 요약 숫자 확인 — 지출 건수, 지출액 합계, 자본화 재계산액, 비용 재계산액, 제거 재계산액, 점검 필요 건수, 정합성 대사 차이 건수를 봅니다.
4. 탭 이동 — 대수선 지출 명세 → 교체 부품 명세 → 설비별 집계 → 지출 종류별 집계 → 대사 결과 순서로 확인합니다.
5. 행 클릭 상세 — 대수선 지출 명세의 행을 누르면 그 건의 인식 요건 · 직전 잔여 장부금액 · 제거 재계산액과 교체한 부품 명세가 열립니다.
6. 내보내기 — 현재 탭의 조회 결과를 CSV(UTF-8)로 내려받아 검토 자료로 씁니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 가상 설비 · 가상 지출로 만든 검증용 샘플 데이터를 전수로 돌렸습니다. 기준 연월 2개(202609 · 202608)에 지출 명세 40건, 교체 부품 18건, 설비별 집계 20건, 종류별 집계 8건, 대사 16건입니다. 아래는 두 연월을 합친 결과입니다.

01~05 정합성 대사의 차이는 0건입니다. 06~08 장부 점검 대사에 남은 차이는 점검 화면이라 일부러 넣은 예외 8건(연월마다 4건)이 만든 것으로, 정합성 대사 차이와 분리해 기록했습니다. 예외는 일상 수선 지출의 자본화 2건, 효익 유입 가능성이 없는데 자본화된 대수선 1건, 직전 잔여 장부금액 또는 부품 제거액 부족 3건, 지출액을 넘어선 자본화 1건, 요건을 채웠는데 비용 처리된 법정 검사 1건입니다. 이와 별도로 직전 잔여 장부금액 산식 · 부품 장부금액 산식 · 부품 제거액 합계를 다른 스크립트로 다시 계산해 차이 0건을 확인했고, 화면의 요약 값이 그 결과와 같은지를 브라우저에서 대조했습니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 8종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리인지와 숫자를 어떻게 읽는지를 아래에 적었습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건 · 요약 숫자 · 탭이 한 화면에 쌓입니다. 처음 열면 기본 기준 연월(202609)로 자동 조회해 첫 탭인 대수선 지출 명세까지 채워진 상태로 시작합니다.

맨 위 조회조건 줄에서 기준 연월을 확인하고, 그 아래 요약 숫자(지출 건수 · 지출액 · 자본화 · 비용 · 제거 · 점검 필요 건수 · 정합성 대사 차이)를 먼저 봅니다. 표에는 지출 한 건마다 인식 요건 두 값과 재계산한 자본화 · 비용 · 제거 금액, 원장과의 차이, 점검 코드가 한 줄로 놓입니다. 기준 연월은 202609, 나머지 조건은 전체가 기본입니다.

점검 필요 건만 골라 보기와 한 건의 상세

월마감에서 먼저 봐야 할 것은 정상 건이 아니라 확인이 필요한 건입니다. 점검 결과를 “점검 필요”로 고르면 그 건들만 남고, 행을 누르면 판단 근거가 한 다이얼로그에 모입니다.

정상 건을 훑지 않고 점검 코드가 붙은 건만 모아 보는 화면입니다. 기준 연월 칸에서 Enter 를 눌러도 같은 조회가 일어납니다. 자본화 차이가 큰 건부터 위에 놓이도록 정렬해 두었고, 점검 코드(R01~R04)가 어느 단계의 차이인지를 알려 줍니다. 요약 숫자도 점검 필요 건 기준으로 바뀝니다.

표에서 이 값이 왜 나왔는지를 되짚는 자리입니다. 효익 유입 가능 · 원가 측정 가능 값이 재계산 자본화액을 결정하고, 직전 원가 − 직전 누적상각이 제거 재계산액이 됩니다. 원장 제거액과 다르면 점검 코드와 함께 차이 금액이 보입니다. 요건 값의 타당성은 이 화면이 판단하지 않으므로 확인 필요 사항입니다.

부품 · 설비 · 종류로 묶어 보기

같은 지출 명세를 세 방향으로 다시 묶은 탭입니다. 부품 탭은 교체한 부품 단위로, 설비 탭은 롤포워드 단위로, 종류 탭은 지출 성격 단위로 차이를 찾아 들어가게 해 줍니다.

부품 교체 건은 지출 한 건 안에 부품이 여러 개일 수 있어 부품 단위로 다시 풉니다. 교체 전 원가 − 교체 전 누적상각이 부품의 잔여 장부금액이고, 이 합이 지출 건의 제거 재계산액입니다. 원장 제거액이 모자란 부품에는 R02 가 붙습니다.

건별 점검이 모두 정상이어도 설비 기말이 원장과 다르면 빠진 거래가 있다는 신호입니다. 설비마다 롤포워드를 한 줄로 보여 주고, 차이가 있으면 R05 를 붙입니다. 같은 설비의 지출 건은 명세 탭에서 설비 조건으로 좁혀 이어서 확인합니다.

지출 명세를 종류별로 합산한 표입니다. 일상 수선은 자본화가 0 이어야 하므로 여기서 자본화가 보이면 그 자체가 신호입니다. 종류별 자본화 재계산액 합계는 명세 합계와 같아야 하며 대사 04번이 이를 검산합니다.

대사 결과 — 이 화면이 스스로 맞는지

01~05 정합성 대사는 이 화면이 스스로 맞는지를, 06~08 장부 점검 대사는 원장과 재계산이 맞는지를 가립니다. 정합성 대사의 차이는 0이어야 하고, 장부 점검 대사의 차이는 점검 필요 건의 합계와 같은 대상입니다. 대사 결과 탭에는 기준 연월만 적용됩니다.

좁은 화면에서 달라지는 것

조회조건 줄은 여러 줄로 접히고 요약 숫자는 두 줄로 쌓이며, 표는 가로로 넘기며 봅니다. 기능은 줄이지 않고 배치만 바뀝니다. 조회 버튼은 접힌 조회조건 끝에 그대로 있습니다.

창이 좁아지면 조회조건 줄은 여러 줄로 접히고, 요약 숫자는 두 줄로 쌓이며, 표는 가로로 넘기면서 봅니다. 기능은 줄이지 않습니다. 검토 회의에서 노트북 화면을 나눠 띄우는 경우를 위한 동작입니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 탭마다 해당 엔티티셋을 $filter 와 함께 부르기만 합니다. 인식 요건 재계산, 점검 코드 판정, 설비 롤포워드, 대사식 계산은 모두 서비스가 하고, 화면은 받은 숫자를 보여 줍니다. 그래서 같은 서비스를 배치나 다른 화면이 불러도 숫자가 다르지 않습니다. 대수선 실시 일자(InspDate)의 날짜 조건은 서비스가 직접 걸러 응답합니다.

인식 요건 재계산 규칙

점검 코드 판정 — 조건 · 결과 상태 · 사용자 조치

지출 한 건에는 점검 코드가 하나만 붙고, 아래 순서에서 먼저 해당하는 코드를 씁니다. 결과는 “점검 필요”와 “확인 필요”로만 적고 원인은 단정하지 않습니다.

예를 들어 202608 의 어느 대수선 건은 지출액 14.7억 전액이 원장에서 자본화되어 있는데, 효익 유입 가능성 값이 “아니오”라 재계산 자본화액은 0 이 됩니다. 그러면 R03 으로 올라와 요건 값과 처리가 맞는지 확인하라고 알려 줍니다. 202609 의 한 대수선 건은 14.5억 전액이 자본화된 것까지는 같지만 직전 잔여 장부금액 4.99억이 원장에서 제거되지 않아 R02 로 올라옵니다. 요건 값 자체의 타당성은 이 화면이 판단하지 않으므로 확인 필요 사항입니다.

자본화 · 제거 산출과 대사 순서

1. 자본화 재계산액 · 비용 재계산액을 위 규칙으로 구합니다(지출액 = 자본화 + 비용).
2. 직전 잔여 장부금액 = 직전 원가 − 직전 누적상각. 자본화 재계산액이 있는 건만 제거 재계산액으로 인정합니다.
3. 설비별 자본화액 = 설비 지출 건의 자본화 재계산액 합계, 설비별 제거액 = 지출 건의 제거 재계산액 합계.
4. 기말 재계산액 = 기초 장부금액 + 자본화 − 제거 − 당기 상각. 원장 기말 장부금액 = 기초 장부금액 + 원장 자본화액 − 원장 제거액 − 당기 상각.
5. 차이 = 재계산 − 원장(자본화 차이 · 제거 차이 · 기말 차이). 지출 종류별 집계는 지출 명세를 종류별로 합산합니다.

조회조건

“전체”는 코드값으로 보내지 않고 해당 조건을 필터에서 뺍니다. 대사 결과 탭에는 기준 연월만 적용됩니다.

결과 컬럼

파일 구성

index.html · readme.html · Component.js · manifest.json
controller/   BaseController.js · Main.controller.js
view/         Main.view.xml · DetailDialog.fragment.xml
model/        formatter.js · ErrorHandler.js
css/ · i18n/  (i18n_ko.properties)
odata/        서비스 선언 파일 · service.js · json/ (엔티티셋별 5개)
media/        intro.mp4 · intro_poster.jpg

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래는 표준 화면으로 충분한 일과 이 앱이 더하는 관점, 그리고 표준 T-code 와 이어지는 지점입니다.

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

T-code 별 연계 지점

기존 화면을 없애야 하나요? 아닙니다. 취득 · 제거 · 상각의 실행과 법정 · 감사 대응은 표준 T-code 에 남겨 두고, 이 앱은 그 결과를 다시 계산해 견주는 점검 · 대사 화면으로 함께 둡니다.

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

S/4HANA 의 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 원장 데이터를 임의 축으로 집계해 보는 데 강합니다. 이 앱은 그 위에서 “인식 요건 재계산 + 제거 재계산 + 대사”라는 유형자산 점검 규칙을 한 번 더 얹는 자리에 있습니다. 같은 뷰 레이어를 쓰므로 표준 분석 앱에서 본 설비별 합계와 이 앱의 설비별 집계를 서로 맞춰 볼 수 있습니다. 구체적으로 어떤 표준 분석 앱이 이 목적에 맞는지는 시스템 릴리스마다 달라 확인 필요입니다.

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

요구사항 매핑

CDS 구성

이 앱의 숫자는 모두 원장 데이터에서 만들어집니다. 아래는 운영 환경으로 옮길 때 만드는 CDS 뷰와 기준 테이블, 권한(DCL)의 구성과 코드입니다. 표준 뷰와 필드 이름은 시스템 릴리스에 따라 다를 수 있어 코드에 확인 필요로 적어 두었습니다.

뷰 레이어 구성

① 기준 테이블 — 바뀌는 값을 코드 밖으로

오더 유형 체계와 계정 체계, 인식 요건 값은 회사마다 다르고 해마다 바뀝니다. 이 값이 뷰 코드에 박히면 매번 이송이 필요해지므로 테이블 세 개로 뺍니다. 인식 요건 입력 테이블의 공급처(누가 어느 시점에 입력하는가)는 운영에서 가장 먼저 정해야 합니다.

" ───────────────────────────────────────────────────────────────
" ZMINSP_KINDMAP · ZMINSP_GLMAP · ZMINSP_RECOG — 고객사가 관리하는 기준 테이블 3종
" 역할 : ① 정비 오더 유형 → 지출 종류   ② G/L 계정 → 원장 라인 구분(취득·제거·상각)
"        ③ 지출 건별 인식 요건 입력값과 직전 원가
" 이렇게 나눈 이유 : 오더 유형·계정 체계·요건 값은 회사마다 다르고 바뀌는 값이라
"        뷰 코드에 박지 않고 테이블로 뺀다. 바뀌면 이송 없이 데이터만 고친다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '대수선 지출 종류 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zminsp_kindmap {
  key client    : abap.clnt not null;
  key auart     : aufart not null;          " 정비 오더 유형
  insp_kind     : abap.char(8) not null;    " MAJOR / LEGAL / PARTS / ROUTINE
  cap_candidate : abap_boolean;             " 자본화 후보 여부 (ROUTINE 은 비움)
}

@EndUserText.label : '대수선 G/L 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zminsp_glmap {
  key client    : abap.clnt not null;
  key saknr     : saknr not null;           " G/L 계정
  line_kind     : abap.char(8) not null;    " CAP / DEREC / DEPR / EXP
}

@EndUserText.label : '대수선 인식 요건 입력'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zminsp_recog {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key aufnr     : aufnr not null;           " 지출 한 건 = 정비 오더
  benefit_ok    : abap_boolean;             " 미래 경제적 효익 유입 가능
  measure_ok    : abap_boolean;             " 원가 신뢰성 있게 측정 가능
  @Semantics.amount.currencyCode : 'zminsp_recog.waers'
  prev_cost     : abap.curr(23,2);          " 직전 대수선 원가 (확인 필요: 공급처)
  @Semantics.amount.currencyCode : 'zminsp_recog.waers'
  prev_accum    : abap.curr(23,2);          " 직전 누적상각
  waers         : waers;
}

② 설비 차원 — 이름은 한 번만

설비 번호와 이름, 가동 기간을 가진 차원입니다. 집계 뷰는 이 뷰에 association 으로만 연결되어 이름이 바뀌어도 집계 코드가 흔들리지 않습니다.

" ───────────────────────────────────────────────────────────────
" ZI_MajInspAsset — 설비 차원
" 역할 : 설비 번호·이름과 가동 기간. 집계 뷰들이 association 으로 붙는 기준점.
" 이렇게 나눈 이유 : 이름·상태는 마스터에서 한 번만 읽고, 집계 뷰는 키만 들고 간다.
"        (확인 필요: S/4HANA 릴리스에 따라 표준 고정자산 인터페이스 뷰 사용 가능)
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '설비 차원'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #M, dataClass: #MASTER }
define view entity ZI_MajInspAsset
  as select from anla
{
  key bukrs as CompanyCode,
  key anln1 as AssetNo,
  key anln2 as SubNumber,
      txt50 as AssetName,
      aktiv as CapitalizedOn,
      deakt as DeactivatedOn
}
where anln2 = '0000'   -- 서브넘버 정책은 고객사 확인 필요

③ 지출 큐브 — 건 단위 집계

정비 오더 지출을 회계기간 · 오더 단위로 모읍니다. 지출액 · 원장 자본화액 · 원장 제거액을 같은 계정 매핑으로 case 합산하므로 세 숫자의 근거가 같은 라인 집합입니다. 대용량에서는 이 뷰의 집계 위치가 성능을 좌우합니다.

" ───────────────────────────────────────────────────────────────
" ZI_MajInspCost — 지출 큐브 (지출 한 건 = 정비 오더 × 회계기간)
" 역할 : 유니버설 저널의 정비 오더 지출을 종류 매핑과 붙여 건 단위로 집계
" 이렇게 나눈 이유 : 인식 요건 판정은 건 단위인데 원천 라인은 전표 단위다.
"        집계를 여기서 끝내 두면 이후 뷰는 건 키만 보면 된다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '대수선 지출 큐브'
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_MajInspCost
  as select from I_JournalEntryItem as Item
    inner join   aufk               as Ord on Ord.aufnr = Item.OrderID
    inner join   zminsp_kindmap     as Map on Map.auart = Ord.auart
    inner join   zminsp_glmap       as Gl  on Gl.saknr  = Item.GLAccount
  association [0..1] to ZI_MajInspAsset as _Asset
    on  _Asset.CompanyCode = $projection.CompanyCode
    and _Asset.AssetNo     = $projection.AssetNo
{
  key Item.CompanyCode,
  key Item.FiscalYear,
  key Item.FiscalPeriod,
  key Item.OrderID                  as InspNo,
      Item.MasterFixedAsset         as AssetNo,
      Map.insp_kind                 as InspKind,
      Item.CompanyCodeCurrency      as Currency,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when Gl.line_kind = 'EXP' or Gl.line_kind = 'CAP'
                then Item.AmountInCompanyCodeCurrency
                else cast( 0 as abap.curr( 23, 2 ) ) end )  as SpendAmount,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when Gl.line_kind = 'CAP'
                then Item.AmountInCompanyCodeCurrency
                else cast( 0 as abap.curr( 23, 2 ) ) end )  as LedgCap,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when Gl.line_kind = 'DEREC'
                then Item.AmountInCompanyCodeCurrency
                else cast( 0 as abap.curr( 23, 2 ) ) end )  as LedgDerecog,

      _Asset
}
where Item.Ledger = '0L'          -- 원장 구성은 고객사 확인 필요
group by
  Item.CompanyCode, Item.FiscalYear, Item.FiscalPeriod, Item.OrderID,
  Item.MasterFixedAsset, Map.insp_kind, Item.CompanyCodeCurrency

④ 설비 롤포워드 원천 — 지출 없는 설비도 남긴다

건 단위 뷰와 합치면 그 달 지출이 없는 설비가 롤포워드에서 사라집니다. 설비 단위 뷰를 따로 두고 서비스가 기초 장부금액과 합쳐 기말을 계산합니다.

" ───────────────────────────────────────────────────────────────
" ZI_MajInspRoll — 설비 롤포워드 원천 (설비 × 회계기간)
" 역할 : 기초 장부금액 · 당기 상각 · 원장 기말 장부금액을 설비 단위로 모은다.
" 이렇게 나눈 이유 : 건 단위 뷰와 합쳐 버리면 지출이 없는 설비는 롤포워드에서 사라진다.
"        설비 단위는 별도 뷰로 두고 서비스가 건 집계와 이어 붙인다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '설비 롤포워드 원천'
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #L, dataClass: #TRANSACTIONAL }
define view entity ZI_MajInspRoll
  as select from I_JournalEntryItem as Item
    inner join   zminsp_glmap       as Gl on Gl.saknr = Item.GLAccount
{
  key Item.CompanyCode,
  key Item.FiscalYear,
  key Item.FiscalPeriod,
  key Item.MasterFixedAsset          as AssetNo,
      Item.CompanyCodeCurrency       as Currency,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when Gl.line_kind = 'DEPR'
                then Item.AmountInCompanyCodeCurrency
                else cast( 0 as abap.curr( 23, 2 ) ) end )  as Depreciation,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( Item.AmountInCompanyCodeCurrency )                as NetMovement
}
where Item.Ledger = '0L'
  and Item.MasterFixedAsset <> ''
group by
  Item.CompanyCode, Item.FiscalYear, Item.FiscalPeriod,
  Item.MasterFixedAsset, Item.CompanyCodeCurrency

⑤ 재계산·점검 판정 — 규칙은 한 곳에

자본화 재계산액과 점검 코드를 순서가 있는 case 로 선언합니다. 직전 잔여 장부금액 제거(R02)와 설비 롤포워드(R05)는 부품 명세 · 설비 집계와 함께 계산해야 해서 서비스가 이어서 판정합니다. 규칙이 바뀌면 이 뷰만 이송합니다.

" ───────────────────────────────────────────────────────────────
" ZR_MajInspCheck — 인식 요건 재계산과 점검 코드 판정
" 역할 : 요건 입력값으로 자본화·비용·제거 재계산액을 만들고 점검 코드를 붙인다.
" 이렇게 나눈 이유 : 판정 규칙(순서가 있는 case)을 한 곳에 두어, 서비스·배치·화면이
"        같은 규칙을 쓰게 한다. 규칙이 바뀌면 이 뷰 하나만 이송한다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '대수선 재계산·점검 판정'
define view entity ZR_MajInspCheck
  as select from ZI_MajInspCost as Cost
    left outer join zminsp_recog as Rq
      on  Rq.bukrs = Cost.CompanyCode
      and Rq.aufnr = Cost.InspNo
{
  key Cost.CompanyCode,
  key Cost.FiscalYear,
  key Cost.FiscalPeriod,
  key Cost.InspNo,
      Cost.AssetNo,
      Cost.InspKind,
      Cost.Currency,
      Cost.SpendAmount,
      Cost.LedgCap,
      Cost.LedgDerecog,

      // 자본화 재계산액 : 일상 수선은 0, 두 요건이 모두 예일 때만 지출액 전액
      case when Cost.InspKind = 'ROUTINE'                      then 0
           when Rq.benefit_ok = 'X' and Rq.measure_ok = 'X'    then Cost.SpendAmount
           else 0 end                                          as CalcCap,

      // 직전 잔여 장부금액 = 직전 원가 − 직전 누적상각
      ( Rq.prev_cost - Rq.prev_accum )                         as PrevBook,

      // 점검 코드 : 순서대로 먼저 해당하는 하나 (R02·R05 는 서비스가 제거·롤포워드와 함께 판정)
      case when Cost.LedgCap > 0 and
                ( Cost.InspKind = 'ROUTINE' or Rq.benefit_ok <> 'X' or Rq.measure_ok <> 'X' ) then 'R03'
           when Cost.LedgCap = 0 and Cost.InspKind <> 'ROUTINE' and
                Rq.benefit_ok = 'X' and Rq.measure_ok = 'X'                                    then 'R04'
           else 'I00' end                                      as CheckCodeBase
}

⑥ 분석 쿼리 — 조회조건과 컬럼 선언

기준 연월을 필수 단일 선택으로 선언하고 설비 · 종류 · 점검 코드를 선택 조건으로 둡니다. 화면 컬럼의 의미가 여기에 적혀 있어 Fiori 분석 앱에서도 같은 조건으로 열립니다.

" ───────────────────────────────────────────────────────────────
" ZC_MajInspQuery — 서비스에 노출하는 분석 쿼리 (대수선 지출 명세)
" 역할 : 조회조건(기준 연월 필수·설비·종류·점검 코드·점검 결과)과 화면 컬럼을 선언
" 이렇게 나눈 이유 : 필터·컬럼 의미를 쿼리에 선언해 두면 Fiori 분석 앱에서도
"        같은 조회조건으로 열린다. 화면과 표준 분석 앱의 숫자를 맞춰 볼 수 있다.
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '대수선 지출 점검 조회'
@Metadata.allowExtensions: true
@Search.searchable: true
define view entity ZC_MajInspQuery
  as select from ZR_MajInspCheck
{
  key CompanyCode,
  key FiscalYear,
  key FiscalPeriod,
  key InspNo,

      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false, mandatory: true }
      @UI.selectionField: [{ position: 10 }]
      concat( FiscalYear, lpad( cast( FiscalPeriod as abap.char(3) ), 3, '0' ) ) as Period,

      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false }
      @UI.selectionField: [{ position: 20 }]
      @Search.defaultSearchElement: true
      AssetNo,

      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false }
      @UI.selectionField: [{ position: 30 }]
      InspKind,

      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false }
      @UI.selectionField: [{ position: 40 }]
      CheckCodeBase                    as CheckCode,

      @Semantics.amount.currencyCode: 'Currency'
      @UI.lineItem: [{ position: 50 }]
      SpendAmount                      as Cost,

      @Semantics.amount.currencyCode: 'Currency'
      @UI.lineItem: [{ position: 60 }]
      CalcCap,

      @Semantics.amount.currencyCode: 'Currency'
      @UI.lineItem: [{ position: 70 }]
      LedgCap,

      @Semantics.amount.currencyCode: 'Currency'
      PrevBook,

      Currency
}

⑦ 권한(DCL) — 집계 단계에서 거른다

회사코드 권한을 쿼리 전체에 겁니다. 드릴다운 상세에만 권한을 걸면 전체 합계에서 빼는 식으로 남의 숫자가 드러날 수 있어, 반드시 집계 단계에서 걸러야 합니다.

" ───────────────────────────────────────────────────────────────
" ZC_MajInspQuery (DCL) — 회사코드 권한
" 역할 : 조회하는 사람이 권한을 가진 회사코드의 지출만 보이게 한다.
" 이렇게 나눈 이유 : 권한은 집계 단계에 건다. 드릴다운(행 클릭 상세)에만 걸면
"        전체 합계에서 빼는 방식으로 남의 숫자가 드러난다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label: '대수선 지출 점검 권한'
@MappingRole: true
define role ZC_MajInspQuery {
  grant select on ZC_MajInspQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
    -- 자산 권한 오브젝트를 함께 걸지는 고객사 권한 설계에서 확인 필요
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영 전환 전에 합의해 두면 첫 마감에서 막히지 않는 항목입니다.

운영 데이터로 갈 때

샘플 데이터는 한 달에 지출 스무 건 · 설비 열 대지만, 운영에서는 정비 오더 지출 라인이 월 수만~수십만 건이 될 수 있습니다. 이때 먼저 손볼 곳은 세 가지입니다. 첫째, 집계를 화면이 아니라 CDS 큐브(HANA)에서 끝내고 서비스는 집계 결과만 읽게 합니다. 둘째, 기준 연월을 필수 조건으로 두어 전 기간을 한 번에 읽지 못하게 합니다. 셋째, 회사코드 · 회계기간 · 오더로 접근하는 경로에 맞춰 필요하면 인덱스와 응답 시간 기준을 정해 둡니다. 구체적인 응답 시간 목표는 고객사 데이터 규모를 본 뒤 정해야 하므로 확인 필요입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

기준서와 판정

도입과 운영