재취득 권리 인식·상각 점검 — IFRS 3·IAS 38, 사업결합에서 되찾은 권리를 잔여 계약기간 기준으로 다시 맞춰 보는 화면

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

사업결합이 끝난 뒤 재무팀이 결산 때마다 되돌아오는 질문은 비슷합니다. 인수 전부터 상대방에게 주었던 라이선스·프랜차이즈·유통권을 되찾았을 때, 그 권리를 영업권과 따로 올려 두었나, 그 가치를 남은 계약기간을 기준으로 평가했나, 그 기간에 걸쳐 상각하고 있나. 지금은 이 세 답이 자산 마스터 조회 화면, 자산 이력 시트, 취득 평가 보고서(엑셀)로 흩어져 있어서, 한 건을 확인하려면 화면 세 개를 오가며 숫자를 손으로 맞춰야 합니다.

관련 기준서는 IFRS 3 사업결합(K-IFRS 제1103호)과 IAS 38 무형자산(K-IFRS 제1038호)입니다. 사업결합에서 인수자가 재취득한 권리는 영업권과 별도로 식별되는 무형자산으로 인식하고, 그 가치는 관련 계약의 잔여 계약기간을 기준으로 측정하며(갱신 가능성은 가치에 반영하지 않는 것이 요구사항입니다), 이후에는 그 기간에 걸쳐 상각합니다. 이미 적용 중인 기준서이므로 새로 준비할 제도라기보다 장부가 그 요구사항대로 되어 있는지 점검하는 일이고, 회사별 적용 범위와 평가 자료의 해석은 확인 필요입니다.

이 앱은 그 점검을 한 화면에 모았습니다. 기준 연월을 넣으면 재취득 권리를 한 건씩 잔여 계약기간 기준으로 다시 평가·상각한 재계산 장부금액과 원장 장부금액을 나란히 놓고, 차이가 나는 이유를 점검 코드(별도 인식 없음 · 갱신기간 포함 평가 · 상각기간 상이 · 장부금액 차이)로 분류해 줍니다. 어느 코드도 회계처리가 틀렸다는 결론이 아니라 어디부터 다시 볼지 알려 주는 표지이며, 최종 판단은 회사와 감사인의 몫입니다.

권리를 되찾았는데 장부에서는 영업권 속에 섞여 있을 수 있다

되찾은 권리는 인수 대가 중 영업권과 따로 식별해 무형자산으로 올려야 하는 항목입니다. 그런데 인수 직후 평가 자료와 자산 마스터가 따로 관리되면 자산 마스터에 해당 권리가 아예 없는 경우가 생기고, 원장만 보아서는 영업권에 포함됐는지 알 수 없습니다.

이 앱은 원장 최초 인식액이 0인 권리를 G01(별도 인식 없음)로 분류해 “영업권에 포함됐는지 취득 평가 자료와 대조해 확인 필요”라고만 표시합니다. 포함됐다고 단정하지 않고, 확인할 권리 목록을 만들어 주는 데까지가 이 화면의 일입니다.

평가 기준이 갱신기간까지 넓어지면 장부금액이 처음부터 달라진다

라이선스나 프랜차이즈 계약에는 갱신 가능 기간이 붙어 있는 경우가 많습니다. 기준서가 요구하는 측정 기준은 갱신 가능성을 빼고 남은 계약기간만 보는 것인데, 취득 평가 자료가 갱신기간까지 넣어 계산돼 있으면 최초 인식액이 그만큼 커집니다. 한 번 올라간 금액은 이후 상각 내내 차이로 따라옵니다.

이 앱은 권리마다 잔여 계약기간 기준 평가액과 갱신기간 포함 평가액(참고)을 함께 들고 있고, 원장 최초 인식액이 후자와 같은 권리를 B01로 분류합니다. 갱신기간 포함 값은 ‘이만큼 차이 날 수 있다’를 가늠하는 참고 값일 뿐 회계 기준 값이 아닙니다.

상각기간이 잔여 계약기간과 어긋나면 해마다 차이가 쌓인다

상각은 잔여 계약기간에 걸쳐 이루어져야 하는데, 자산 마스터의 내용연수는 취득 시점에 다른 값(예: 계약기간 + 갱신기간, 또는 회사 표준 연수)으로 들어가 있을 수 있습니다. 상각기간이 길면 매달 상각이 모자라고, 짧으면 넘칩니다. 한 해에는 작은 차이라도 계약 종료 시점까지 누적되면 장부금액과 계약 종료 시점의 잔액이 어긋납니다.

이 앱은 원장 상각기간과 잔여 계약기간이 다른 권리를 P01(상각기간 상이)로, 위 두 경우가 아닌데도 장부금액이 재계산과 다른 권리를 D01로 분류합니다. 코드는 한 권리에 하나만 붙고, 우선순위는 G01 → B01 → P01 → D01입니다.

처분할 때는 장부금액이 손익을 좌우한다

재취득한 권리를 제3자에게 넘기면 처분대가에서 처분 시점 장부금액을 뺀 값이 손익이 됩니다. 장부금액이 위 이유로 달라져 있으면 처분손익도 같은 크기만큼 달라지므로, 처분 건은 권리 점검과 같이 봐야 합니다.

이 앱은 처분 건마다 처분일 기준으로 재계산한 장부금액과 손익을 계산하고 원장의 처분손익과 비교해, 다른 건을 L01로 표시합니다. “처분 시 장부금액 확인 필요”까지만 말하고, 어느 값이 맞는지는 판단하지 않습니다.

사용 방법

1. 조회조건 입력 — 기준 연월(6자리, 필수)을 넣습니다. 권리 유형 · 원장 평가 기준 · 취득일 기간 · 점검 코드 · 점검 결과는 범위를 좁힐 때만 고릅니다.
2. 조회 — 조회조건 오른쪽 끝의 조회 버튼을 누르거나 기준 연월 칸에서 Enter 키를 누릅니다. 화면을 열면 기본값으로 한 번 자동 조회됩니다.
3. 요약 확인 — 맨 위 요약에서 권리 건수 · 평가액·장부금액 합계 · 원장−재계산 차이 · 갱신기간 포함 평가 건수 · 점검 필요 건수 · 대사 차이 건수를 봅니다.
4. 탭 이동 — 재취득 권리 명세 → 권리 유형별 집계 → 원장 평가 기준별 집계 → 처분손익 → 대사 결과 순서로 봅니다. 탭 머리의 작은 숫자는 그 탭의 행 수입니다.
5. 행 클릭 상세 — 명세 탭에서 행을 누르면 평가액에서 누적 상각을 빼는 재계산 산식과 원장 금액이 대화창으로 열립니다.
6. 내보내기 — 보고 있는 탭의 결과를 CSV 내려받기로 받습니다(UTF-8). 점검 필요 건만 골라 담당자에게 넘길 때 씁니다.

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

위 여섯 가지가 산식 대사입니다 — 화면이 보여 주는 합계와 건별 값이 서로 맞는지 보는 검사이고, 검사 건수 합계 97건 모두 차이 0원입니다. 이와 별도로 점검 대상 건은 일부러 심어 두었습니다. 권리 28건 중 13건(G01 2 · B01 4 · P01 4 · D01 3)과 처분 6건 중 3건(L01 3)은 원장과 재계산이 의도적으로 다르게 만든 샘플이며, 이 건수는 산식 대사 차이와 섞지 않고 ‘장부 점검 대사’ 두 줄로 따로 셉니다. 요약의 “정합성 대사 차이 건수 0”과 “점검 필요 권리 건수 13”이 함께 나오는 이유입니다.

데이터는 모두 가상입니다. 실제 고객사의 계정체계나 금액을 쓰지 않았고, 권리 이름 끝에 ‘(가상)’을 붙여 두었습니다.

무엇으로 만들었나

앱 정보

실행 화면

검증용 샘플 데이터로 실제 렌더링한 화면 7종입니다. 사용 순서대로 묶었고, 화면마다 무엇을 보고 무엇을 누르는지 아래에 적었습니다.

처음 열었을 때와 점검 코드로 좁히기

조회조건 · 요약 · 탭이 한 화면에 세로로 쌓입니다. 기준 연월이 기본값(202412)으로 들어간 채 한 번 자동 조회되므로, 처음 여는 사람도 빈 화면을 보지 않습니다.

요약에서 먼저 볼 것은 세 가지입니다. 재취득 권리 28건의 평가액 합계(약 449억 원)와 재계산·원장 장부금액 합계, 둘의 차이(원장−재계산 −1.4억 원), 그리고 점검 필요 건수 13. 명세 표는 권리 한 건이 한 행이고, 기본 정렬은 권리 번호입니다. 금액 단위는 원입니다.

조회조건 중 하나만 바꿔도 요약과 탭 숫자가 함께 바뀝니다. 점검 코드를 비우면 전체로 돌아갑니다. 결과 4건은 “잔여 계약기간 기준 평가인지 확인 필요” 후보이지, 오류로 확정된 건이 아닙니다. 담당자에게 넘길 목록이면 오른쪽 위 CSV 내려받기를 누릅니다.

권리 한 건의 산식 — 행을 누르면 열리는 상세

명세 탭에서 행을 누르면 한 권리의 재계산 과정이 위에서 아래로 읽히는 대화창이 열립니다. 숫자를 의심할 때 다른 화면을 열지 않고 그 자리에서 검산하는 용도입니다.

예시는 갱신기간 포함 평가로 분류된(B01) 권리입니다. 잔여 계약기간 36개월 · 경과 21개월이면 평가액 268,000,000원에서 누적 상각 156,333,333원을 빼 재계산 장부금액 111,666,667원이 됩니다. 원장은 갱신기간 포함 평가액 482,000,000원으로 시작했기 때문에 장부금액이 341,416,667원이고, 차이 +229,750,000원이 점검 코드와 함께 나옵니다. 마지막 07 줄의 갱신기간 포함 평가액은 참고 값입니다.

묶어서 보기 — 권리 유형별 · 원장 평가 기준별

건별로 본 차이를 묶어 ‘어디에 몰려 있나’를 보는 두 탭입니다. 합계는 명세 탭 합계와 같아야 하며, 그 일치가 산식 대사 02·03 입니다.

유형마다 갱신기간 포함 평가 건수 · 상각기간 상이 건수가 따로 있고, 오른쪽으로 밀면 차이 건수 · 점검 필요 건수 · 점검 판정이 이어집니다. 점검 건이 어느 유형에 몰렸는지 보고, 점검 판정이 ‘점검 필요’인 유형부터 담당자와 이야기를 시작하면 됩니다.

‘별도 인식 없음’ 줄은 원장 금액이 0이라 차이가 곧 재계산 장부금액의 크기입니다. ‘갱신기간 포함 기준’ 줄은 원장이 재계산보다 큰 쪽으로 차이가 납니다. 두 기준의 차이 합계 부호가 반대이므로, 합계 한 줄만 보면 서로 상쇄되어 작아 보일 수 있다는 점도 함께 읽습니다.

처분손익과 대사 결과

권리를 제3자에게 넘긴 건과, 이 화면이 스스로 맞는지 보여 주는 대사 탭입니다.

화면 폭에 다 담기지 않는 오른쪽 열(원장 처분손익 · 차이 · 점검 결과)은 밀어서 봅니다. 처분 6건 중 두 손익이 같으면 정상, 다르면 L01 로 표시하고 “처분 시 장부금액 확인 필요”라고 적습니다. 처분일은 취득일로부터 12개월이 지난 날짜로 만들어 둔 샘플입니다.

좌변과 우변이 같으면 대사 차이 0건입니다(요약의 정합성 대사 차이 건수 0). 7·8번은 원장과 재계산이 의도적으로 다른 건을 세는 줄이라 차이가 0이 아니어도 정상이며, 그래서 요약의 대사 차이 건수와 섞이지 않게 구분 열을 따로 두었습니다.

화면 뒤에서 일어나는 일

위 화면들이 어떤 규칙으로 움직이는지를 자리별로 적었습니다. 도입 검토에서 “그래서 이건 어떻게 되느냐”로 자주 되돌아오는 대목들입니다.

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

한 권리가 여러 조건에 걸리면 G01 → B01 → P01 → D01 순서로 가장 앞선 코드 하나만 표시합니다. 먼저 걸린 이유가 해소되면 다음 이유가 드러나는 구조이므로, 담당자가 위에서부터 차례로 푸는 순서와 같습니다. 어느 코드도 ‘오류’라는 이름을 쓰지 않고 ‘점검 필요’·‘확인 필요’로만 표시합니다.

재계산과 대사 — 처리 순서

순서가 중요한 이유는 어느 단계에서 어긋났는지를 대사 번호로 되짚기 위해서입니다. 합계가 안 맞으면 7번 → 건별 산식(3·4·5번) → 입력값(1·2번) 순으로 내려가면 됩니다.

조회조건

취득일 기간은 시작과 끝을 한 묶음(and)으로 보냅니다. 같은 필드의 두 조건을 따로 넣으면 UI5 가 or 로 묶어 내보내 기간을 넣으나 마나가 되기 때문입니다. 조회 결과가 취득일 조건을 무시하는 것처럼 보이면 가장 먼저 볼 자리입니다.

결과 컬럼

좁은 화면에서 달라지는 것

표는 화면 폭에 맞춰 늘어나고, 열이 넘치면 가로로 밀어서 봅니다. 열 폭은 고정이라 숫자가 잘리지 않으며, 휴대폰 전용 배치는 두지 않았습니다. 좁은 화면에서는 처분손익 · 대사 결과처럼 열이 많은 탭이 오른쪽 열(차이 · 점검 결과)을 밀어서 보게 되므로, 점검 건 목록을 읽는 용도라면 CSV 로 내려받아 열어 보는 편이 편합니다.

파일 구성

├─ 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/  style.css · i18n_ko.properties
├─ odata/        서비스 정의(metadata.xml) · 서비스 로직(service.js) · 집합별 데이터(json)
└─ media/        소개 영상 · 대표 이미지

화면 코드(controller · view · model)와 서비스 정의·로직(odata)을 폴더로 나눠 두었습니다. 운영 서비스로 바꿀 때 손대는 곳은 manifest.json 의 서비스 선언과 odata/ 쪽이고, 화면 코드는 그대로입니다.

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준 화면으로 충분한 일은 표준에 그대로 두고, 표준이 이어 주지 않는 자리 — 잔여 계약기간 기준 재계산과 점검 코드 분류 — 만 더합니다.

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

T-code 별 연계 지점

오가는 방법. 이 앱에서 점검 건을 찾으면 권리 번호로 자산 마스터(AS03)를 열어 상각기간과 등록 여부를 확인하고, 금액 차이는 자산 이력 시트(S_ALR_87011963)와 계정 라인 아이템(FAGLL03)에서 원천을 확인합니다. 반대로 표준 화면에서 이상한 값을 발견하면 같은 권리 번호를 이 앱의 명세 탭에서 찾아 재계산 산식 상세를 열어 봅니다.

표준에 남겨 둘 일. 법정 결산 · 공시 · 감사 대응에 쓰는 숫자는 표준 거래가 만듭니다. 이 앱은 그 숫자가 기준서 요구사항과 어긋나 보이는 자리를 먼저 찾는 점검용이고, 회계처리를 바꾸는 기능이 없습니다.

기존 리포트를 없애야 하나? 아닙니다. 기존 자산 리포트는 그대로 두고, 결산 전에 이 앱으로 점검 건을 먼저 걸러 낸 뒤 표준 화면에서 원천을 확인하는 순서를 권합니다.

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

S/4HANA 의 표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 장부 값을 다양한 축으로 집계하는 데 강합니다. 이 앱이 하는 일은 그 옆에서 재계산 값 하나를 더 만들어 장부 값과 비교하는 것입니다. 그래서 같은 원천(자산 마스터 · 자산 연도값 · 전표)을 쓰면서도 결과 모양이 다르고, 표준 분석 쿼리의 집계 결과와 이 앱의 원장 장부금액 합계가 일치하는지가 연결 뒤 첫 대사 항목이 됩니다. 어떤 표준 분석 뷰를 쓸지는 시스템 버전에 따라 달라 확인 필요입니다.

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

요구사항 매핑표

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

CDS 구성

아래는 화면이 읽는 값을 만드는 CDS · DDIC 객체의 구성과 코드 스케치입니다. 뷰를 계층으로 나눠 두면 원천이 바뀌어도 위쪽이 흔들리지 않고, 화면과 대사가 같은 값을 보게 됩니다.

뷰 레이어 구성

① 기준 테이블 — 평가액과 잔여 계약기간을 담는 자리

재취득 권리의 평가액과 계약 종료일은 자산 마스터에 들어 있지 않습니다. 인수 직후의 취득 평가 보고서에서 오는 값이기 때문입니다. 이 값을 어디에 둘지가 도입의 첫 결정이며, 아래는 가장 단순한 형태(별도 테이블)의 스케치입니다. 계약 마스터가 이미 있으면 그쪽을 읽도록 바꿉니다.

" ─────────────────────────────────────────────────────────────
" ZREACQ_VALUATION  재취득 권리 평가 자료
"   · 역할 : 잔여 계약기간 기준 평가액, 갱신기간 포함 평가액(참고), 계약 종료일
"   · 이렇게 나눈 이유 : 자산 마스터에는 평가 자료를 담을 필드가 없어
"                         평가액 출처를 한 곳에서 관리하기 위해
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '재취득 권리 평가 자료'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zreacq_valuation {
  key mandt        : mandt not null;
  key bukrs        : bukrs not null;
  key anln1        : anln1 not null;
  key anln2        : anln2 not null;
  contract_end     : datum;
  waers            : waers;
  @Semantics.amount.currencyCode : 'zreacq_valuation.waers'
  value_contract   : abap.curr(18,2);   " 잔여 계약기간 기준 평가액
  @Semantics.amount.currencyCode : 'zreacq_valuation.waers'
  value_renewal    : abap.curr(18,2);   " 갱신기간 포함 평가액(참고)
  renew_months     : abap.int4;
}

② 차원 뷰 — 자산 마스터와 상각 설정 읽기

권리의 이름 · 취득일 · 상각 연수는 자산 마스터와 상각 설정에서 옵니다. 여기서는 키와 속성만 노출하고 계산은 하지 않습니다. 원천 필드 이름은 시스템 버전에 따라 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ReacqRight  재취득 권리 기준 뷰
"   · 역할 : 권리 번호 · 이름 · 취득일 · 상각 연수(상각 설정)
"   · 이렇게 나눈 이유 : 원천 읽기만 맡겨 두면 위쪽 계산 뷰가 원천 변경에 영향받지 않음
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '재취득 권리 기준'
@ObjectModel.usageType: { sizeCategory: #L, serviceQuality: #A, dataClass: #MASTER }
define view entity ZI_ReacqRight
  as select from anla as a
    inner join   anlb as b
      on  b.bukrs = a.bukrs
     and  b.anln1 = a.anln1
     and  b.anln2 = a.anln2
    left outer join zreacq_valuation as v
      on  v.bukrs = a.bukrs
     and  v.anln1 = a.anln1
     and  v.anln2 = a.anln2
{
  key a.bukrs        as CompanyCode,
  key a.anln1        as RightId,
  key a.anln2        as SubNumber,
      a.txt50        as RightName,      -- 자산 설명(확인 필요)
      a.aktiv        as AcqDate,        -- 자본화일
      b.ndjar        as AmortYears,     -- 상각 연수(확인 필요)
      v.contract_end as ContractEnd,
      v.waers        as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      v.value_contract as ValueContract,
      @Semantics.amount.currencyCode: 'Currency'
      v.value_renewal  as ValueRenewal,
      v.renew_months   as RenewMonths,
      -- 잔여 계약기간(개월) 근사 — 월 계산 함수는 시스템 버전에 맞춰 확인 필요
      div( dats_days_between( a.aktiv, v.contract_end ), 30 ) as RemMonths
}
where b.afabe = '01'      -- 평가 영역(확인 필요)

③ 원장 값 뷰 — 자산 연도값에서 원장 금액 읽기

원장에 올라가 있는 최초 인식액과 누적 상각은 자산 연도값에서 읽습니다. 재계산 쪽 값과 섞이지 않도록 별도 뷰로 둡니다. 두 값의 차이가 이 앱의 핵심 숫자이기 때문입니다.

" ─────────────────────────────────────────────────────────────
" ZI_ReacqLedgerValue  원장 장부금액 기준 뷰
"   · 역할 : 원장 최초 인식액(취득가액 누계) · 원장 누적 상각 · 원장 장부금액
"   · 이렇게 나눈 이유 : 재계산 값과 같은 뷰에 섞지 않아 차이의 출처를 분명히 하기 위해
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '재취득 권리 원장 값'
define view entity ZI_ReacqLedgerValue
  as select from anlc as c
{
  key c.bukrs  as CompanyCode,
  key c.anln1  as RightId,
  key c.anln2  as SubNumber,
  key c.gjahr  as FiscalYear,
      c.waers  as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      c.kansw  as InitAmount,           -- 취득가액 누계(확인 필요)
      @Semantics.amount.currencyCode: 'Currency'
      c.knafa  as AccumAmort,           -- 누적 정상 상각(확인 필요)
      @Semantics.amount.currencyCode: 'Currency'
      cast( c.kansw + c.knafa as abap.curr(18,2) ) as LedgerBook
}
where c.afabe = '01'     -- 평가 영역(확인 필요)

④ 큐브 — 재계산과 점검 코드가 결정되는 자리

이 앱의 계산이 모이는 뷰입니다. 경과 개월은 취득일과 기준 연월 말 사이 개월 수이고, 상각 대상 개월은 그 값과 잔여 계약기간 중 작은 값입니다. 점검 코드의 우선순위(G01 → B01 → P01 → D01)가 case 의 순서로 그대로 들어갑니다. 날짜 계산식은 시스템 함수에 맞춰 확인이 필요하며, 아래는 구조를 보여 주는 스케치입니다.

" ─────────────────────────────────────────────────────────────
" ZR_ReacqRightCube  재취득 권리 재계산 큐브
"   · 역할 : 경과 개월 · 재계산 누적 상각 · 재계산 장부금액 · 차이 · 점검 코드
"   · 이렇게 나눈 이유 : 판정 규칙을 한 뷰에 모아 화면과 대사가 같은 값을 보게 하기 위해
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '재취득 권리 재계산 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZR_ReacqRightCube
  with parameters
    p_period : abap.char(6)                  -- 기준 연월 YYYYMM
  as select from ZI_ReacqRight as r
    left outer join ZI_ReacqLedgerValue as l
      on  l.CompanyCode = r.CompanyCode
     and  l.RightId     = r.RightId
     and  l.SubNumber   = r.SubNumber
     and  l.FiscalYear  = substring( $parameters.p_period, 1, 4 )
{
  key r.CompanyCode,
  key r.RightId,
      r.RightName,
      r.AcqDate,
      r.ContractEnd,
      r.Currency,
      r.RemMonths,
      @Semantics.amount.currencyCode: 'Currency'
      r.ValueContract,
      @Semantics.amount.currencyCode: 'Currency'
      l.InitAmount                                 as InitLedger,
      @Semantics.amount.currencyCode: 'Currency'
      l.LedgerBook                                 as LedgerBook,
      -- 점검 코드: 순서가 곧 우선순위
      case
        when coalesce( l.InitAmount, 0 ) = 0                  then 'G01'
        when l.InitAmount = r.ValueRenewal                    then 'B01'
        when r.AmortYears * 12 <> r.RemMonths                 then 'P01'  -- 상각기간 vs 잔여 계약기간
        -- when 원장 장부금액 <> 재계산 장부금액 then 'D01'  (재계산식은 아래 두 필드와 같은 식)
        else 'I00'
      end                                          as CheckCode,
      -- 경과 개월 = (기준 연 − 취득 연) × 12 + (기준 월 − 취득 월), 일자 보정은 확인 필요
      ( cast( substring( $parameters.p_period, 1, 4 ) as abap.int4 ) * 12
        + cast( substring( $parameters.p_period, 5, 2 ) as abap.int4 ) )
      - ( cast( substring( cast( r.AcqDate as abap.char(8) ), 1, 4 ) as abap.int4 ) * 12
        + cast( substring( cast( r.AcqDate as abap.char(8) ), 5, 2 ) as abap.int4 ) )
                                                   as ElapsedMonths,
      -- 재계산 장부금액 = 평가액 − 평가액 × min(경과, 잔여) ÷ 잔여
      @Semantics.amount.currencyCode: 'Currency'
      r.ValueContract
        - div( r.ValueContract * least( ElapsedMonths, r.RemMonths ), r.RemMonths )
                                                   as RecalcBook
}

⑤ 분석 쿼리 — 조회조건과 컬럼 노출

화면이 읽는 모양을 정하는 뷰입니다. 필터 조건은 여기서 한 번 선언하고, 계산은 아래 큐브에 맡깁니다. 서비스로 노출할 때는 이 뷰가 한 개의 목록(집합)이 됩니다.

" ─────────────────────────────────────────────────────────────
" ZC_ReacqRightQuery  재취득 권리 점검 쿼리
"   · 역할 : 조회조건(필터)과 목록 컬럼 선언
"   · 이렇게 나눈 이유 : 화면에 필요한 모양만 노출하고 계산은 큐브에 두기 위해
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '재취득 권리 점검'
@Metadata.allowExtensions: true
define view entity ZC_ReacqRightQuery
  with parameters
    @Consumption.defaultValue: '202412'
    p_period : abap.char(6)
  as select from ZR_ReacqRightCube( p_period : $parameters.p_period )
{
      @UI.lineItem: [{ position: 10 }]
  key RightId,
      @UI.lineItem: [{ position: 20 }]
      RightName,
      @Consumption.filter: { selectionType: #RANGE }
      @UI.selectionField: [{ position: 20 }]
      AcqDate,
      @UI.lineItem: [{ position: 30 }]
      ValueContract,
      @UI.lineItem: [{ position: 40 }]
      LedgerBook,
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false }
      @UI.selectionField: [{ position: 30 }]
      CheckCode
}

⑥ 처분 뷰 — 처분일 기준 재계산 손익

처분은 권리와 건수 단위가 달라 별도 뷰를 둡니다. 처분 전표(자산 전표 라인)에서 처분대가와 처분일을 읽고, 처분일까지의 재계산 장부금액을 같은 규칙으로 계산해 손익을 만듭니다.

" ─────────────────────────────────────────────────────────────
" ZR_ReacqDisposal  재취득 권리 처분손익
"   · 역할 : 처분대가 − 처분 시 재계산 장부금액 = 재계산 처분손익, 원장 손익과 비교
"   · 이렇게 나눈 이유 : 처분 건수와 권리 건수의 단위가 달라 한 뷰에 섞으면 합계가 어긋남
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '재취득 권리 처분손익'
define view entity ZR_ReacqDisposal
  with parameters
    p_period : abap.char(6)
  as select from anep as e
    inner join   ZR_ReacqRightCube( p_period : $parameters.p_period ) as c
      on  c.CompanyCode = e.bukrs
     and  c.RightId     = e.anln1
{
  key e.bukrs     as CompanyCode,
  key e.anln1     as RightId,
  key e.belnr     as DocumentNo,
      e.bzdat     as DisposalDate,      -- 처분일(확인 필요)
      @Semantics.amount.currencyCode: 'Currency'
      e.anbtr     as Proceeds,          -- 처분대가(확인 필요)
      c.Currency
}
where e.bwasl = '200'                    -- 처분 거래 유형(확인 필요)

⑦ 권한 — 집계 합계가 권한 밖 건을 포함하지 않게

권한은 쿼리 단계에서 걸어야 합니다. 상세 보기에서만 걸면 요약 합계와 집계 탭 숫자가 권한 밖 권리를 포함해, 합계에서 자기 몫을 빼는 계산으로 남의 숫자가 드러납니다. 회사코드 권한 객체를 쓰는 예시이며, 실제 조합은 회사의 권한 설계에 맞춰 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZC_ReacqRightQuery  접근 제어(DCL)
"   · 역할 : 회사코드 권한이 있는 행만 조회 허용
"   · 이렇게 나눈 이유 : 집계 합계가 권한 밖 건을 포함하지 않게 하기 위해
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '재취득 권리 점검 권한'
@MappingRole: true
define role ZC_ReacqRightQuery {
  grant select on ZC_ReacqRightQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 읽는 문

쿼리 뷰를 서비스로 내보내는 마지막 단계입니다. 서비스 바인딩(OData V2)을 만들어 게시하면 화면이 읽을 수 있고, 이 서비스 이름을 화면의 서비스 선언에 적습니다.

" ─────────────────────────────────────────────────────────────
" ZSD_ReacqRight  서비스 정의
"   · 역할 : 점검 쿼리와 처분 뷰를 서비스로 노출
"   · 이렇게 나눈 이유 : 화면은 서비스 이름만 알면 되고, 뷰 이름 변경에 영향받지 않게 함
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '재취득 권리 점검 서비스'
define service ZSD_ReacqRight {
  expose ZC_ReacqRightQuery as RightSet;
  expose ZR_ReacqDisposal   as DispSet;
}

위 코드는 구조를 보여 주는 스케치입니다. 실제 필드 이름 · 평가 영역 · 날짜 계산 함수 · 처분 거래 유형은 시스템 버전과 회사 설정에 맞춰 확인이 필요합니다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여덟 가지는 코딩이 아니라 합의이고, 합의가 끝나면 기술 작업은 위 뷰들을 만들고 화면의 서비스 선언을 바꾸는 일로 줄어듭니다.

전표와 자산 건수가 많은 운영 환경에서는 한 가지가 더 있습니다. 이 앱은 권리 단위(수십~수천 건)를 다루므로 전표 단위 리포트보다 가볍지만, 처분 뷰와 자산 연도값 결합은 기준 연월과 회사코드를 필수 조건으로 두어 전체 스캔을 막아야 합니다.

운영 데이터로 갈 때

권리 단위는 많아야 수천 건이어서 한 번에 읽어도 부담이 크지 않지만, 처분 전표와 연도값 결합은 자산 건수에 따라 커집니다. 운영 데이터로 갈 때는 ① 기준 연월 · 회사코드를 필수 파라미터로 두고, ② 큐브에서 집계 후 화면으로 보내며, ③ 처분 뷰는 기준 연월 범위의 전표만 읽고, ④ 점검 코드 · 권리 번호 인덱스가 필요한지 실행 계획으로 확인합니다. 응답 시간 기준은 회사가 정하며(예: 조회 몇 초 이내), 그 기준을 넘으면 집계 단계를 데이터베이스 안으로 내리는 쪽을 먼저 검토합니다. 화면은 한 번에 행을 모두 받지 않고 스크롤에 맞춰 이어서 받기 때문에 건수가 늘어도 화면 구조는 그대로입니다.

자주 묻는 질문

도입 상담과 데모에서 자주 나오는 질문을 네 묶음으로 적었습니다.

숫자와 산식

화면과 조작

점검 코드 해석

도입과 운영