SAP 비금융자산 손상차손 범주 점검 — IFRS 18 에서 손상 손익이 맞는 범주에 놓였는지 장부와 다시 견주는 화면

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

결산이 가까워지면 감사인이 묻는 질문이 있습니다. 이 손상차손은 손익계산서 어느 범주에 들어갔나, 왜 그 범주인가. IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호) 는 손익계산서의 수익과 비용을 영업 · 투자 · 재무 · 법인세 · 중단영업 범주로 나눠 보이게 하는데, 자산 손상은 그 경계에 걸리는 대표적인 항목입니다. 같은 손상차손이라도 영업에 쓰는 설비면 영업범주, 주된 사업활동이 아닌 투자부동산이면 투자범주, 중단영업으로 분류된 사업의 자산이면 중단영업 범주로 갈 수 있기 때문입니다.

지금은 이 답이 계정 한 줄에 들어 있습니다. 손상차손 계정이 어느 손익 범주로 모이는지는 계정 매핑이 정하고, 그 계정에 쌓인 금액이 실제로 어떤 자산의 어떤 손상인지는 자산회계 화면과 원장 조회 화면을 오가며 엑셀로 맞춥니다. 이 앱은 그 자리를 메웁니다. 손상 건마다 자산군 · 주된 사업활동 · 중단영업 여부로 범주를 다시 구해 장부에 놓인 범주와 나란히 보이고, 다른 건에는 점검 코드와 해야 할 일을 문장으로 붙입니다.

범주는 계정만으로 정해지지 않는다

손상차손 계정 하나가 영업범주로 매핑되어 있으면, 그 계정으로 들어온 금액은 모두 영업범주에 모입니다. 그런데 투자부동산에서 난 손상이나 중단영업으로 분류된 사업의 설비에서 난 손상도 같은 계정으로 기표될 수 있습니다. 그러면 장부는 영업범주로 보이지만 자산의 성격으로는 다른 범주여야 하는 금액이 숨습니다. 이 앱은 계정이 아니라 자산 쪽의 사실(자산군, 회사의 주된 사업활동 설정, 중단영업 분류)에서 범주를 다시 구해 장부 범주와 견줍니다.

어긋난 건은 코드와 문장으로 말해 주어야 움직인다

숫자만 다르다고 알려 주면 현업은 왜 다른지를 다시 추적해야 합니다. 그래서 어긋난 유형을 점검 코드로 나눴습니다. 영업용 자산이 투자범주에 놓인 건(I01), 투자부동산이 영업범주에 놓인 건(I02), 투자가 주된 사업활동인 회사의 투자부동산이 투자범주에 놓인 건(I03), 중단영업 자산이 중단영업 범주에 놓이지 않은 건(I04), 영업권 환입이 기록된 건(I05)은 점검 필요, 자산군이 등록되지 않아 판단 기준이 없는 건(I09)은 확인 필요입니다. 코드마다 판정 조건과 사용자 조치가 한 문장으로 붙어 있어 담당자가 무엇부터 열어 볼지 바로 정합니다.

범주를 옮기면 얼마가 움직이는지가 먼저 궁금하다

범주가 다르다는 사실보다 “옮기면 영업이익이 얼마나 달라지나” 가 보고 라인의 관심사입니다. 요약의 범주 이동 필요 금액은 범주가 다른 건의 손상차손을 부호까지 포함해 모은 값입니다(요약에는 절대값 합계로 표시). 검증용 샘플 데이터에서는 25건 가운데 7건이 점검 필요이고 이동 필요 금액은 772.0백만 원입니다.

합계가 맞는지는 화면이 매번 말해야 한다

점검 화면의 숫자가 틀리면 점검 자체가 신뢰를 잃습니다. 손상 건에서 자산으로, 자산에서 자산군으로 올라가는 모든 합계에 대사식을 걸어 두었고, 결과는 별도 탭과 요약의 대사 차이 건수로 항상 보입니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도(4자리)만 필수이고 회사 · 자산군 · 장부 범주 · 인식일 · 자산명 · 점검 코드 · 점검 결과는 선택입니다. 화면을 열면 회계연도 기준으로 자동 조회됩니다.
2. 조회 버튼 또는 Enter 키로 조회합니다. 조회 버튼은 조회조건 영역 안 입력칸들의 가장 오른쪽에 있습니다.
3. 위쪽 요약을 먼저 봅니다. 점검한 손상 건수, 점검 필요 항목, 확인 필요 항목, 이동 필요 금액, 대사 차이 건수 순서입니다.
4. 탭을 옮겨 가며 봅니다. 자산별 범주 판정 → 손상 건별 점검 → 자산군별 합계 → 대사 결과 순서가 읽기 편합니다.
5. 행을 눌러 상세를 엽니다. 손상 건별 점검 탭의 행에서 점검 근거와 같은 자산의 손상 건 비교가 나옵니다.
6. CSV 내려받기로 지금 보고 있는 탭을 UTF-8 파일로 받아 감사 협의 자료에 붙입니다.

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

검증용 샘플 데이터(회사 2곳 · 손상 건 25 · 자산 24 · 자산군 11행)에 대해 대사식을 전수로 돌렸습니다. 정합성 대사 6식과 참고 대사 1식 모두 차이 0입니다.

점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 점검 필요 7건(I01 2건 · I02 1건 · I03 1건 · I04 2건 · I05 1건)과 확인 필요 2건(I09)이며, 이 건수는 대사 차이 건수 0과 별개입니다. 그 밖에 서비스 계약(조회 · 단건 · 날짜 조건 · 함수 호출)과 샘플 데이터 참조 분리도 확인했고 모두 통과했습니다.

무엇으로 만들었나

앱 정보

실행 화면

아래 화면은 검증용 샘플 데이터로 실제 실행해 캡처한 것입니다. 이미지를 누르면 확대되고 좌우 방향키로 넘겨 볼 수 있습니다.

처음 열었을 때

조회조건 · 요약 · 자산별 범주 판정이 한 화면에 나옵니다. 위에서 아래로 읽으면 “몇 건을 봤고, 몇 건이 어긋났고, 옮기면 얼마가 움직이나” 가 순서대로 답이 됩니다.

화면을 열면 회계연도 2026 기준으로 자동 조회됩니다. 맨 위 요약은 점검한 손상 건수 25, 점검 필요 항목 7, 확인 필요 항목 2, 범주 이동 필요 금액 772.0백만 원, 영업범주로 놓인 장부 금액 1,281.0백만 원, 정합성 대사 차이 0건 순서입니다. 점검 필요 항목만 서비스의 건수 함수가 세고 나머지는 조회된 손상 건에서 계산합니다. 아래 표는 자산 하나가 한 줄이며, 장부 범주 금액과 재계산 범주 금액이 나란히 놓여 어긋난 자산이 눈에 띕니다.

건마다 놓인 범주를 비교한다

자산 단위로 훑어 본 뒤에는 손상 건 단위로 내려갑니다. 점검 필요만 골라 보면 지금 확인해야 할 건이 7건으로 줄어듭니다.

손상 건별 점검 탭은 손상차손을 건 단위로 보여 줍니다. 손상차손은 손상 전 장부금액에서 회수가능액을 뺀 금액이고 환입은 마이너스로 표시됩니다. 구분 열의 손상 · 환입, 장부 범주와 재계산 범주, 점검 결과, 이동 필요 금액이 한 줄에 있어 어느 건이 왜 어긋났는지 가로로 읽힙니다.

조회조건의 점검 결과를 점검 필요로 두고 조회하면 7건만 남습니다. 영업용 자산의 손상 손익이 투자범주에 놓인 건, 투자부동산이 영업범주에 놓인 건, 중단영업 자산이 중단영업 범주에 놓이지 않은 건, 영업권 환입이 기록된 건이 코드별로 보입니다. 점검 코드 조건을 함께 쓰면 한 유형씩 따로 확인할 수 있습니다.

행을 눌러 근거를 읽고, 자산군으로 올려 본다

어긋난 건의 근거는 상세 창에서, 어느 자산군에서 어긋남이 큰지는 자산군별 합계에서 봅니다.

행을 누르면 상세 창이 열립니다. 위쪽에는 손상차손, 자산군, 주된 사업활동, 중단영업 여부, 구분, 손상 전 장부금액 3.1억과 회수가능액 2.4억, 장부 범주와 재계산 범주, 인식일이 있고, 그 아래에 점검 근거 두 줄이 이어집니다. 이 예는 중단영업으로 분류된 사업의 설비인데 장부에는 영업범주로 남아 있어 7천만 원이 점검 필요로 잡혔습니다. 맨 아래 표는 같은 자산의 손상 건을 장부 범주와 재계산 범주로 비교합니다.

자산군별 합계 탭은 유형자산 · 무형자산 · 영업권 · 사용권자산 · 투자부동산 · 자산군 미등록으로 묶어 장부 범주와 재계산 범주 금액을 나란히 보여 줍니다. 자산군 미등록 금액은 판정 보류로 따로 모아 합계에서 빠지지 않게 합니다. 어느 자산군에서 범주가 가장 많이 갈리는지가 한눈에 읽힙니다.

합계가 맞는지 대사 결과로 확인한다

마지막으로 대사 결과 탭에서 위에서 본 합계가 서로 맞는지 확인합니다. 감사 협의에 이 화면을 그대로 붙이는 경우가 많습니다.

대사 결과 탭은 좌변과 우변, 검사 건수, 차이 건수, 최대 차이를 식마다 적습니다. 정합성 대사 6식은 모두 차이 0이어야 하고, 참고 대사 1식은 점검 필요 건수가 자산별 합계와 같은지 봅니다. 차이가 한 건이라도 나면 요약의 대사 차이 건수가 먼저 알려 줍니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 표준 필터 조건으로 바꿔 서비스에 보냅니다. 서비스는 손상 건마다 손상차손(손상 전 장부금액 − 회수가능액, 환입은 음수)을 구하고, 자산군 · 주된 사업활동 · 중단영업 여부로 재계산 범주를 정한 뒤 장부 범주와 비교해 점검 코드를 붙입니다. 이 결과를 자산 단위, 자산군 단위로 올려 합산하고 대사식을 계산해 돌려줍니다. 화면은 받은 값을 표에 보여 줄 뿐 판정을 다시 하지 않으므로, 판정 규칙을 바꿔도 서비스 한 곳만 고치면 됩니다.

범주 판정 규칙 — 판정 조건 → 결과 상태 → 사용자 조치

산출과 대사 순서

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조회조건 입력칸이 여러 줄로 접히고, 표는 가로 스크롤로 열 전체를 유지합니다. 열을 줄여 숫자를 숨기지 않으므로 휴대폰에서도 같은 컬럼을 볼 수 있고, 조회 버튼은 접힌 입력칸 끝에 그대로 있습니다.

파일 구성

앱 폴더
├─ index.html · Component.js · manifest.json
├─ view/        Main.view.xml · DetailDialog.fragment.xml
├─ controller/  BaseController.js · Main.controller.js
├─ model/       formatter.js · ErrorHandler.js
├─ css/ · i18n/
├─ odata/       서비스 정의(metadata.xml) · 서비스 로직(service.js) · 샘플 데이터(json)
└─ media/       소개 영상 · 포스터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 손상차손을 인식하고 전기하는 일, 자산 가치를 확인하는 일, 계정 전표를 여는 일은 표준 화면이 그대로 합니다. 이 앱이 더하는 것은 그 결과를 범주 관점으로 다시 모아 장부와 견주는 자리입니다.

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

T-code 별 연계 지점

오가는 방법. 이 앱에서 점검 필요 건의 자산 번호를 확인하고 자산 탐색기에서 같은 자산을 열면 가치 필드와 전기 내역이 나옵니다. 반대로 표준 화면에서 확인한 손상 전기가 이 앱의 어느 행에 대응하는지는 자산 번호와 인식일로 찾습니다. 표준에 남겨 둘 일은 손상 인식 · 전기, 법정 공시 숫자의 확정, 감사 대응용 보고서입니다. 이 앱을 도입해도 기존 표준 리포트는 없애지 않고 그대로 두며, 둘의 숫자를 맞춰 보는 용도로 함께 씁니다.

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

S/4HANA 에서는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 로 자산 · 원장 데이터를 볼 수 있습니다. 이 앱은 그와 겹치지 않고 판정 로직이 들어 있는 점검 화면이라는 자리에 둡니다. 범주 재계산 규칙(자산군 · 주된 사업활동 · 중단영업)은 표준 분석 쿼리에는 없으므로 아래 CDS 구성처럼 별도 큐브로 만들고, 그 위에 분석 쿼리와 권한을 얹습니다. 표준 CDS 뷰 이름은 환경과 릴리스마다 다르므로 이 글의 코드는 원천 테이블을 기준으로 적었고, 어떤 표준 뷰를 쓸지는 도입 시 확인 필요입니다.

요구사항 매핑표

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호) 는 2027-01-01 이후 개시하는 회계연도부터 적용하며 조기 적용이 허용되고 비교기간은 재작성합니다. 그 밖의 경과 규정과 범주별 정의 요건은 원문으로 확인한 사실만 적었고, 확인하지 못한 부분은 위 표의 비고처럼 ‘원문 확인 필요’ 로 남겼습니다.

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

CDS 구성

화면에서 본 판정은 서비스가 만든 값이고, 서비스는 CDS 뷰가 만든 값을 읽습니다. 아래는 운영 환경에 올릴 때의 구성입니다. 모든 코드는 스케치이며 객체 이름은 기능을 뜻하는 영문으로 지었습니다. 어떤 표준 CDS 뷰를 쓸지는 환경과 릴리스에 따라 다르므로 원천 테이블 기준으로 적었고, 실제 활성화 전 확인이 필요합니다.

뷰 레이어 구성

① 자산클래스 → 자산군 매핑 테이블

이 테이블이 비어 있으면 모든 자산이 ‘자산군 미등록(I09)’ 으로 떨어져 판정이 전부 보류됩니다. 운영 전환에서 가장 먼저 채우는 객체이고, 회계팀이 직접 유지하도록 SM30 뷰를 함께 만드는 것이 보통입니다. 투자부동산의 ‘주된 사업활동’ 플래그도 여기에 둡니다.

" ───────────────────────────────────────────────────────────────
" ZNFIC_ASTMAP  자산클래스 → 자산군 매핑 (회계팀이 SM30 으로 유지)
" 하는 일    : 회사의 자산클래스(ANLKL)를 화면이 쓰는 6개 자산군으로 묶는다
" 이렇게 나눈 이유 : 자산클래스 체계는 회사마다 달라 코드에 박으면
"                   클래스가 늘 때마다 이송이 반복된다. 값은 데이터로 둔다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '자산클래스-자산군 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table znfic_astmap {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key anlkl    : anlkl not null;
  astclass     : abap.char(3) not null;  " PPE INT GWL ROU IP UNK
  mainact      : abap.char(1);           " 'X' = 투자부동산 투자가 주된 사업활동 (IP 에만 의미)
}

② 손상차손 계정 → 장부 범주 매핑 테이블

장부 범주는 계정 매핑의 결과입니다. 이 매핑을 데이터로 꺼내 두면 점검 필요 건이 나왔을 때 ‘자산 분류가 틀렸나, 계정 매핑이 틀렸나’ 를 가릴 수 있습니다. 손상차손과 환입을 같은 계정이 받는지 따로 받는지도 여기서 정합니다.

" ───────────────────────────────────────────────────────────────
" ZNFIC_ACCTMAP  손상차손 계정 → 장부 범주 매핑
" 하는 일    : 손상차손·환입을 기표하는 계정이 손익계산서 어느 범주에 모이는지
" 이렇게 나눈 이유 : '장부 범주' 는 계정 매핑의 결과다. 비교의 한쪽을
"                   명시적으로 두어야 어긋남이 '매핑 문제' 인지 '분류 문제' 인지 가려진다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '손상차손 계정-장부 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table znfic_acctmap {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;
  key saknr    : saknr not null;
  bookedcat    : abap.char(4) not null;  " OPR 영업 / INV 투자 / DISC 중단영업
  imptype      : abap.char(1) not null;  " L 손상차손 / R 환입
}

③ 중단영업 분류와 회수가능액 입력 테이블

표준 자산 마스터에는 중단영업 분류도, 회수가능액도 없습니다. 회사의 손상 검토 자료에서 오는 값이므로 입력자와 변경 일시를 함께 남겨 감사 추적이 되게 합니다. 이 두 값이 정확하지 않으면 뒤의 모든 판정이 흔들립니다.

" ───────────────────────────────────────────────────────────────
" ZNFIC_DISCAST  중단영업 분류 자산 + ZNFIC_RECOV  회수가능액 입력
" 하는 일    : 사실(중단영업 분류, 회수가능액)은 SAP 표준 필드에 없어 회사가 입력한다
" 이렇게 나눈 이유 : 판단 근거(분류 일자, 입력자)를 남겨 감사인이 거슬러 볼 수 있게 한다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '중단영업 분류 자산'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table znfic_discast {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key anln1    : anln1 not null;
  key anln2    : anln2 not null;
  valid_from   : abap.dats not null;     " 중단영업 분류일
  changed_by   : syuname;
  changed_at   : timestampl;
}

@EndUserText.label : '회수가능액 입력'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table znfic_recov {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key gjahr    : gjahr not null;
  key anln1    : anln1 not null;
  key anln2    : anln2 not null;
  key impno    : abap.numc(2) not null;
  carry_amt    : abap.curr(23,2);        " 손상 전 장부금액
  recov_amt    : abap.curr(23,2);        " 회수가능액 (회사의 손상 검토 자료)
  waers        : waers;
}

④ 자산 차원 뷰 — 재계산에 쓰는 사실을 한 줄로

범주 재계산은 세 가지 사실(자산군 · 주된 사업활동 · 중단영업 여부)에 달려 있습니다. 이 사실들을 큐브가 아닌 차원에 두면 자산군별 추이처럼 다른 분석도 같은 정의를 씁니다. 매핑에 없는 클래스는 coalesce 로 ‘UNK’ 가 되어 확인 필요로 드러납니다.

" ───────────────────────────────────────────────────────────────
" ZI_NfAssetDim  자산 차원 (Dimension)
" 하는 일    : 자산 마스터에 자산군·주된 사업활동·중단영업 여부를 붙여 한 줄의 '사실' 로 만든다
" 이렇게 나눈 이유 : 범주 재계산에 쓰는 세 가지 사실을 큐브가 아니라 차원에 두어
"                   다른 분석(자산군별 추이 등)도 같은 정의를 쓰게 한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '자산 차원 — 범주 재계산 사실'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'AssetNo'
define view entity ZI_NfAssetDim
  as select from anla
    left outer join znfic_astmap as map
      on  map.bukrs = anla.bukrs
      and map.anlkl = anla.anlkl
    left outer join znfic_discast as dsc
      on  dsc.bukrs = anla.bukrs
      and dsc.anln1 = anla.anln1
      and dsc.anln2 = anla.anln2
{
  key anla.bukrs                                  as CompanyCode,
  key anla.anln1                                  as AssetNo,
  key anla.anln2                                  as AssetSubNo,
      anla.txt50                                  as AssetName,
      coalesce( map.astclass, 'UNK' )             as AssetClass,
      case when map.mainact = 'X' then 'Y' else 'N' end as MainInvestFlag,
      case when dsc.anln1 is not null then 'Y' else 'N' end as DiscontinuedFlag
}

⑤ 손상 건 뷰 — 모든 합계의 최소 단위

손상차손은 손상 전 장부금액에서 회수가능액을 뺀 값입니다. 원장 전표의 손상 계정 라인과 입력 테이블을 건 단위로 맞붙여 한 줄을 만듭니다. S/4HANA 에서는 자산 거래 테이블이 호환 뷰로 남고 실데이터가 원장에 있으므로 어느 원천을 읽을지가 운영 연결의 첫 질문입니다.

" ───────────────────────────────────────────────────────────────
" ZI_NfAssetImpItem  손상 건 (Fact 의 바닥)
" 하는 일    : 원장 전표에서 손상차손·환입 계정의 라인만 골라 손상 건으로 만든다
" 이렇게 나눈 이유 : 손상차손 = 손상 전 장부금액 − 회수가능액 이므로
"                   입력 테이블(ZNFIC_RECOV)과 원장 라인을 건 단위로 맞붙인다
" 주의      : 읽을 원천(ANEP·ANLC 호환 뷰 vs ACDOCA)은 환경마다 확인 필요 — 아래는 ACDOCA 기준 스케치
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '손상 건'
define view entity ZI_NfAssetImpItem
  as select from acdoca as j
    inner join znfic_acctmap as am
      on  am.saknr = j.racct
    inner join znfic_recov as rv
      on  rv.bukrs = j.rbukrs
      and rv.gjahr = j.gjahr
      and rv.anln1 = j.anln1
      and rv.anln2 = j.anln2
{
  key j.rbukrs                      as CompanyCode,
  key j.gjahr                       as FiscalYear,
  key j.anln1                       as AssetNo,
  key j.anln2                       as AssetSubNo,
  key rv.impno                      as ImpNo,
      am.imptype                    as ImpType,
      am.bookedcat                  as BookedCat,
      j.budat                       as ImpDate,
      @Semantics.amount.currencyCode : 'Currency'
      rv.carry_amt                  as CarryAmt,
      @Semantics.amount.currencyCode : 'Currency'
      rv.recov_amt                  as RecovAmt,
      j.rhcur                       as Currency
}
where j.rldnr = '0L'

⑥ 범주 재계산 큐브 — 판정 규칙이 사는 곳

재계산 범주와 점검 코드를 결정하는 가장 중요한 뷰입니다. 판정 순서(미등록 → 중단영업 → 투자부동산 → 영업)가 곧 규칙이므로 순서를 바꾸면 결과가 바뀝니다. 이 뷰만 고치면 모든 화면의 숫자가 함께 바뀌므로 변경 이송은 반드시 대사 결과와 함께 검토합니다.

" ───────────────────────────────────────────────────────────────
" ZC_NfImpCategory  범주 재계산 큐브 (Cube)
" 하는 일    : 재계산 범주(ExpectCat)와 점검 코드(CheckCode)를 건마다 결정하고 금액을 집계한다
" 이렇게 나눈 이유 : 판정 규칙이 한 곳에 있어야 규칙을 바꿀 때 모든 화면의 숫자가 함께 바뀐다.
"                   판정 순서는 '자산군 미등록 → 중단영업 → 투자부동산 → 영업' 으로 고정한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '손상 범주 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZC_NfImpCategory
  as select from ZI_NfAssetImpItem as i
    association [1..1] to ZI_NfAssetDim as _Asset
      on  _Asset.CompanyCode = i.CompanyCode
      and _Asset.AssetNo     = i.AssetNo
      and _Asset.AssetSubNo  = i.AssetSubNo
{
  key i.CompanyCode, key i.FiscalYear, key i.AssetNo, key i.AssetSubNo, key i.ImpNo,
      i.BookedCat,
      _Asset.AssetClass,
      case
        when _Asset.AssetClass = 'UNK'                               then 'NONE'
        when _Asset.DiscontinuedFlag = 'Y'                           then 'DISC'
        when _Asset.AssetClass = 'IP' and _Asset.MainInvestFlag <> 'Y' then 'INV'
        else 'OPR'
      end as ExpectCat,
      case
        when _Asset.AssetClass = 'UNK'                               then 'I09'
        when _Asset.AssetClass = 'GWL' and i.ImpType = 'R'           then 'I05'
        when _Asset.DiscontinuedFlag = 'Y' and i.BookedCat <> 'DISC' then 'I04'
        when _Asset.AssetClass = 'IP' and _Asset.MainInvestFlag = 'Y'
                                       and i.BookedCat <> 'OPR'      then 'I03'
        when _Asset.AssetClass = 'IP' and i.BookedCat <> 'INV'       then 'I02'
        when _Asset.AssetClass <> 'IP' and i.BookedCat <> 'OPR'      then 'I01'
        else 'I00'
      end as CheckCode,
      @Semantics.amount.currencyCode : 'Currency'
      cast( i.CarryAmt - i.RecovAmt as abap.curr(23,2) ) as ImpAmt,
      i.Currency,
      _Asset
}

⑦ 분석 쿼리 — 화면이 부르는 조건과 열

필수 필터(회계연도)와 열 정의를 쿼리에 선언합니다. 화면의 조회조건과 쿼리의 필터 선언이 같아야 하고, 필터를 쿼리에서 막아 두면 서비스가 조건 없는 전체 조회를 받지 못합니다. 대용량에서 성능 사고를 막는 첫 장치입니다.

" ───────────────────────────────────────────────────────────────
" ZC_NfImpCategoryQuery  분석 쿼리 / Consumption
" 하는 일    : 화면이 부르는 조회조건·열·정렬을 선언한다
" 이렇게 나눈 이유 : 필터를 쿼리에 선언해 두면 서비스가 '조건 없는 전체 조회' 를
"                   받지 못하게 막을 수 있다(회계연도 필수)
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '손상 범주 점검 쿼리'
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@OData.publish : false
define view entity ZC_NfImpCategoryQuery
  as select from ZC_NfImpCategory
{
  @Consumption.filter : { mandatory : true, selectionType : #SINGLE, multipleSelections : false }
  @AnalyticsDetails.query.axis : #FREE
  key FiscalYear,
  @Consumption.filter.selectionType : #SINGLE
  @AnalyticsDetails.query.axis : #FREE
  key CompanyCode,
  @UI.lineItem : [{ position : 10 }]
  key AssetNo,
  @UI.lineItem : [{ position : 20 }]
  AssetClass,
  @UI.lineItem : [{ position : 30 }]
  BookedCat,
  @UI.lineItem : [{ position : 40 }]
  ExpectCat,
  @UI.lineItem : [{ position : 50, criticality : 'Crit' }]
  CheckCode,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Aggregation.default : #SUM
  ImpAmt
}

⑧ 권한 DCL — 집계 단계에 건다

드릴스루에만 권한을 걸면 합계에서 뺄셈으로 다른 회사 숫자가 샙니다. 쿼리 자체에 회사코드 권한을 걸어 권한 없는 건은 집계에도 들어가지 않게 합니다. 자산군 단위 권한이 필요하면 같은 방식으로 조건을 더합니다.

" ───────────────────────────────────────────────────────────────
" ZC_NfImpCategoryQuery  권한 (DCL)
" 하는 일    : 회사코드·자산군 권한이 없는 사용자는 해당 건이 집계에도 나오지 않게 한다
" 이렇게 나눈 이유 : 드릴스루(상세)에만 권한을 걸면 합계에서 뺄셈으로 다른 회사 숫자가 샌다.
"                   집계 단계(쿼리)에 건다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '손상 범주 점검 권한'
@MappingRole : true
define role ZC_NfImpCategoryQuery {
  grant select on ZC_NfImpCategoryQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_ANLA_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의 — 화면이 보는 하나의 창

쿼리를 OData V2 로 노출합니다. 서비스 정의와 바인딩을 분리하면 같은 정의로 V2 와 V4 를 모두 게시할 수 있습니다. 화면 쪽 변경은 manifest.json 의 서비스 주소를 바꾸는 한 줄입니다.

" ───────────────────────────────────────────────────────────────
" ZUI_NfImpCategory  서비스 정의 (Service Definition) + 바인딩
" 하는 일    : 쿼리를 OData V2 로 노출한다. 화면이 보는 서비스는 이 하나다.
" 이렇게 나눈 이유 : 서비스 정의와 바인딩을 분리해 두면 같은 정의를 V2 와 V4 로 모두 게시할 수 있다
" 운영 연결  : 서비스 활성화(/IWFND/MAINT_SERVICE 또는 Binding 게시) 후 manifest.json 의 서비스 주소만 바꾼다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '손상 범주 점검 서비스'
define service ZUI_NfImpCategory {
  expose ZC_NfImpCategoryQuery as ImpCheck;
  expose ZI_NfAssetDim         as Asset;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

손상 건은 자산 수에 비례해 늘 뿐이어서 전표 수천만 건의 원장이라도 손상 계정으로 걸러낸 뒤의 건수는 많지 않습니다. 문제는 걸러내기 전의 스캔입니다. 그래서 (1) 손상 계정으로 먼저 좁히는 조건을 뷰에 박아 두고, (2) 회계연도를 필수 파라미터로 받으며, (3) 원장의 자산 번호 · 계정 · 전기일 조합에 맞는 인덱스를 확인합니다. 목표는 조회 한 번이 몇 초 안에 끝나는 것이고, 응답이 느려지면 먼저 쿼리의 필수 필터와 인덱스를 봅니다. 집계는 서비스 쪽에서 하되 건 단위 조회는 페이징으로 나눠 받습니다.

자주 묻는 질문

도입 검토에서 자주 나오는 28가지 질문을 숫자와 판정 · 화면과 조작 · 표준 T-code 와 데이터 · 도입과 운영으로 묶었습니다.

숫자와 판정

화면과 조작

표준 T-code 와 데이터

도입과 운영