공정가치 평가기법 변경 점검 — 기법을 바꾼 효과를 시장 효과와 갈라 장부와 맞춰 보는 결산 화면

도입 배경 — 이 앱을 사용해야 하는 이유

결산 때 평가 담당자가 가장 자주 받는 질문은 이렇습니다. 이번에 평가기법을 바꾼 종목의 공정가치가 얼마나 변했나, 그중 시장이 움직인 몫은 얼마이고 평가 방식을 바꾼 몫은 얼마인가, 바꾼 이유는 적혀 있고 장부와 공시는 맞나. 지금은 이 세 답이 평가 보고서, 엑셀 검산표, 전표 조회 화면에 흩어져 있어 결산 막바지에 한꺼번에 맞춰 보게 됩니다.

관련 기준서의 요구는 단순합니다. IFRS 13 공정가치 측정(K-IFRS 제1113호)은 평가기법을 기간마다 일관되게 적용하라고 하고, 기법을 바꾸는 것은 바뀐 측정이 같거나 더 대표성 있을 때로 한정합니다. 그렇게 바꾼 효과는 IAS 8 회계정책, 회계추정치 변경과 오류(K-IFRS 제1008호)의 회계추정치 변경으로 다루어 변경이 생긴 기간부터 앞으로 반영하며, 기법을 바꾼 사실과 이유는 공시 대상 여부를 확인해야 합니다. 이 앱은 그 요구를 준비·점검 관점에서 화면으로 옮겨, 종목마다 기법 변경 효과를 시장 효과와 갈라 보여 주고 장부가 그에 맞게 기재됐는지 대조합니다.

변동 금액 하나로는 시장 때문인지 방식 때문인지 알 수 없다

평가 보고서에는 직전 보고일과 당기의 공정가치가 있고 차이도 적혀 있습니다. 그러나 기법을 바꾼 종목의 차이에는 두 가지가 섞여 있습니다. 할인율이나 주가가 움직인 몫, 그리고 같은 시점에도 기법이 달라 값이 달라진 몫입니다. 이 앱은 직전 기법으로 당기 입력값을 다시 계산한 값을 기준으로 두고, 그 값과 직전 공정가치의 차이를 시장·입력변수 효과, 당기 기법으로 계산한 값과의 차이를 기법 변경 효과라고 부릅니다. 두 효과를 더하면 직전 공정가치에서 당기 공정가치까지 1원도 남기지 않고 이어집니다.

바꿨다는 표시와 바꾼 이유가 장부에서 따로 논다

기법을 바꾸면 변경 표시, 변경 사유, 공시 대상 표시가 함께 있어야 합니다. 현실에서는 하나가 빠지기 쉽습니다. 직전·당기 기법 코드를 비교해 변경 여부를 앱이 먼저 판정하고, 장부 표시와 다르거나 사유가 비어 있거나 공시 대상 표시가 없으면 점검 필요로 올립니다. 담당자가 결산 막바지에 건건이 열어 보지 않아도 어느 종목을 다시 보면 되는지가 먼저 정리됩니다.

효과를 어디에 반영했는지가 소급 처리 여부를 가른다

기법 변경 효과는 회계추정치 변경의 성격이므로 변경이 생긴 기간에 손익(또는 해당 자산의 기타포괄손익)으로 앞으로 반영하는 것이 원칙입니다. 이익잉여금으로 소급해 반영한 건이 있으면 점검 대상입니다. 이 앱은 인식 위치 칸을 읽어 그런 건을 따로 걸러 내고, 처리 근거를 확인해 달라고만 표시합니다. 소급이 맞는지 아닌지는 앱이 단정하지 않습니다.

사용 방법

1. 조회조건 입력 — 기준 연월(필수, 6자리, 기본 202609)을 두고, 필요하면 자산·부채 유형, 당기 평가기법, 기법 변경(산출), 평가 기준일 기간, 점검 코드, 점검 결과를 고릅니다. “전체”는 그 조건을 걸지 않습니다.
2. 조회 버튼 또는 Enter — 조회 버튼은 조회조건 영역의 오른쪽 끝, 초기화 버튼과 같은 줄에 있습니다. 화면을 처음 열면 기본 조건으로 한 번 자동 조회합니다.
3. 요약 확인 — 평가 종목 건수, 기법 변경 건수, 점검 필요 건수, 기법 변경 효과 합계, 효과 차이 합계, 정합성 대사 차이 건수가 조건에 맞춰 다시 계산됩니다.
4. 탭 이동 — 평가 종목 명세 → 기법 이동표 → 기법별 평가 산식 → 대사 결과 순서로 봅니다. 탭 제목 위 숫자가 건수입니다.
5. 행 클릭 상세 — 종목 명세의 행을 누르면 서열·기법·사유·효과 분해와 두 가지 산식, 장부와의 차이를 한 창에서 봅니다.
6. CSV 내려받기 — 보고 있는 탭의 조회 결과를 UTF-8 BOM CSV 로 내려받습니다.

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

평가 도구에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 화면 산식끼리 어긋나지 않는지 대사식 5종을 먼저 세워 전수로 돌렸고, 장부를 산출값과 견주는 대사 5종은 의도적으로 넣은 예외 건이 잡히는지로 확인했습니다. 두 묶음은 건수를 합치지 않습니다.

검증용 샘플 데이터는 가상 평가 종목 24건(비상장 지분증권·파생상품·채무증권·투자부동산 각 6건)입니다. 이 가운데 기법이 바뀐 종목은 10건, 바뀌지 않은 종목은 14건이고, 점검 필요 8건은 코드 C01 1건 · C02 2건 · C03 1건 · C04 1건 · C05 2건 · C06 1건으로 모두 의도적으로 넣은 예외입니다. 실제 고객사의 계정 체계나 금액은 쓰지 않았습니다.

무엇으로 만들었나

실행 화면

실제로 열어 본 화면 6종입니다. 숫자는 모두 같은 가상 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 사용 순서대로 세 묶음으로 나눴습니다.

처음 열었을 때 — 바뀐 종목과 점검 필요 건

조회조건, 요약, 종목 표가 위에서 아래로 쌓입니다. 요약 6종이 먼저 눈에 들어오고, 표에서는 직전·당기 평가기법의 비교로 바뀐 종목을 알아봅니다.

화면을 열면 기본 조건(기준 연월 202609)으로 한 번 자동 조회됩니다. 맨 위 요약은 평가 종목 24건, 기법 변경 10건, 점검 필요 8건, 기법 변경 효과(산출) 합계, 효과 차이 합계, 정합성 대사 차이 건수입니다. 표에서는 직전 평가기법과 당기 평가기법이 붙어 있어 두 값이 다른 행이 곧 변경 종목이며, 오른쪽에 효과와 점검 결과가 이어집니다. 조건 입력 칸에서 Enter 를 눌러도 조회됩니다.

점검 결과를 점검 필요로 고르고 조회하면 표에는 코드 C01부터 C06까지 걸린 종목만 남습니다. 점검 내용 칸에는 변경 사유 확인 필요, 소급 처리 근거 확인 필요처럼 무엇을 다시 보라는 문구가 적힙니다. 이 표시는 오류 판정이 아니라 장부 근거를 다시 확인하라는 신호이며, 조건을 지우면 전체로 돌아갑니다.

기법이 어디서 어디로 옮겨 갔나 — 이동표와 평가 산식

종목 단위로 본 다음에는 묶음으로 봅니다. 이동표는 조합별 효과를, 평가 산식은 그 효과가 어떤 계산에서 나왔는지를 보여 줍니다.

행 하나가 직전 기법 → 당기 기법 조합입니다. 같은 기법을 유지한 조합은 기법 변경 효과가 0 이고, 바뀐 조합에서만 효과가 생깁니다. 현금흐름할인에서 시장배수로 옮긴 두 종목처럼 한 조합에 몰린 효과를 보면 어느 이동이 숫자를 크게 흔들었는지 알 수 있습니다. 이동표의 당기 공정가치 합계는 종목 명세 합계와 같아야 하며 대사 결과 탭에서 따로 검산합니다.

한 종목이 두 줄로 나옵니다. A 는 직전 기법으로, B 는 당기 기법으로 계산한 줄이며 기초금액에 계수를 곱해 원 미만을 반올림한 값이 산출 평가액입니다. 평가 보고 금액과 차이가 있으면 맨 오른쪽에 나타납니다. 기법 변경 효과는 B 평가액에서 A 평가액을 뺀 값이고, 기법 이름마다 기초금액과 계수의 의미가 달라 이름 칸이 함께 바뀝니다.

맞는 곳과 차이 나는 곳 — 대사와 상세

마지막 묶음은 신뢰의 근거입니다. 대사로 화면 산식의 정합성을 확인하고, 상세에서 종목 하나가 장부와 어떻게 어긋나는지를 끝까지 따라갑니다.

위 다섯 줄은 화면 산식끼리의 정합성 대사로 차이가 모두 0 입니다. 아래 다섯 줄은 장부를 산출값과 견주는 점검 대사이며, 장부 공정가치·기법 변경 효과 인식·변경 표시·사유와 공시 기재·인식 위치에서 차이가 난 건수와 최대 차이가 보입니다. 두 묶음의 차이 건수는 합치지 않고 따로 셉니다. 정합성이 0 이어야 아래 점검 대사의 차이를 믿고 읽을 수 있기 때문입니다.

종목 명세의 행을 누르면 열립니다. 예로 든 통화스왑 한 건은 현금흐름할인에서 옵션가격모형으로 바뀌었고 산출 기법 변경 효과는 +45,609,551원인데 장부에는 +25,085,253원이 반영되어 있어 효과 차이 −20,524,298원이 확인 필요로 표시됩니다. 직전 공정가치에서 당기 공정가치까지 시장 효과와 기법 효과가 어떻게 이어지는지 위에서 아래로 읽으면 됩니다.

화면 뒤에서 일어나는 일

종목마다 직전 보고일과 당기의 평가기법 코드를 먼저 비교해 변경 여부를 정합니다. 변경 종목은 같은 입력값으로 직전 기법(A)과 당기 기법(B) 두 번 계산하고, B 와 A 의 차이를 기법 변경 효과, A 와 직전 공정가치의 차이를 시장·입력변수 효과로 둡니다. 기법 선택과 입력값은 회사가 정한 값을 그대로 쓰며, 앱은 그 값으로 계산이 맞고 장부 기재가 맞는지만 확인합니다.

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

코드는 위에서 아래 순서로 먼저 걸리는 하나만 붙입니다. 화면은 단정하지 않고 “점검 필요”로만 표시하며, 점검 도구이므로 최종 판단은 회사와 감사인이 합니다.

산출·대사 순서

1. 평가액 재계산 — 평가 기초금액 × 계수를 원 미만 반올림해 직전 기법(A)과 당기 기법(B)을 각각 구하고 평가 보고 금액과 맞춥니다(대사 01).
2. 변경 판정 — 직전 기법 코드와 당기 기법 코드가 다르면 변경(대사 04).
3. 기법 변경 효과 — B 평가액 − A 평가액. 변경하지 않은 종목은 0(대사 03).
4. 시장·입력변수 효과 — A 평가액 − 직전 보고일 공정가치.
5. 변동 분해 — 직전 공정가치 + 시장 효과 + 기법 효과 = 당기 공정가치(대사 02).
6. 이동표 합계 — 이동표 당기 공정가치 합계 = 종목 명세 합계(대사 05).
7. 장부 점검 대사 5종 — 장부 공정가치 · 기법 변경 효과 인식 · 변경 표시 · 사유와 공시 기재 · 인식 위치(대사 06~10). 차이가 있는 건이 점검 대상입니다.

조회조건

기법 이동표 · 기법별 평가 산식 · 대사 결과 탭은 기준 연월만 조건으로 겁니다. 정렬은 컬럼 머리글이 $orderby 로, 총건수는 $inlinecount 로 전달됩니다.

결과 컬럼

좁은 화면에서 달라지는 것

이 앱은 데스크톱에서 하는 결산 업무를 기준으로 만들었고 좁은 화면 전용 배치는 따로 두지 않았습니다. 열이 많은 표는 가로로 스크롤해서 보고, 상세 창은 가로가 넓은 창으로 열립니다. 휴대폰·태블릿에서의 배치는 도입 환경에서 확인 필요입니다.

파일 구성

index.html · Component.js · manifest.json
controller/  BaseController.js · Main.controller.js
view/        Main.view.xml · DetailDialog.fragment.xml
model/       formatter.js · ErrorHandler.js
css/         style.css
i18n/        i18n_ko.properties
서비스/      서비스 정의 · service.js(조회 · 조건 · 정렬 처리) · 엔티티셋별 데이터 4개
media/       소개 영상 · 대표 이미지

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 그래서 표준 화면이 이미 잘하는 일은 그대로 두고, 표준만으로는 한 화면에서 이어 보기 어려운 자리를 이 앱이 메웁니다.

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

T-code 별 연계 지점

운영 전환에서 흔한 질문은 “기존 리포트를 없애야 하나” 입니다. 없애지 않습니다. 법정 공시와 감사 대응에 쓰는 표준 화면과 평가 보고서는 그대로 두고, 이 앱은 결산 중 점검과 대조를 앞당기는 용도로 함께 씁니다. 금융상품 평가를 별도 자금·재무 관리 기능으로 하는 회사의 전용 T-code 는 환경마다 달라 확인 필요입니다.

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

표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office 는 같은 CDS 위에서 숫자를 읽는 도구들입니다. 이 앱의 서비스를 아래 CDS 구성처럼 만들면 같은 큐브를 이들 도구가 그대로 열 수 있습니다. 이 앱은 그 위에서 점검 코드와 대조 열을 더한 전용 화면이며, 어느 도구를 어떤 업무에 쓸지는 도입 환경에 따라 확인 필요입니다.

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

요구사항 매핑

CDS 구성

이 사례의 화면은 서비스가 만들어 주는 24개 종목과 48개 평가 산식 행을 그대로 받아 보여 줍니다. 운영에서는 이 계산을 서비스 코드가 아니라 CDS 뷰로 내려서, 평가 보고 기록과 전표 원천을 DB 가 직접 집계하게 합니다. 아래는 그때 만드는 객체를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser 로 실제 이름을 확인해야 하고, 확인하지 못한 곳은 주석에 “확인 필요”로 적어 두었습니다. 평가 보고 기록은 회사마다 위치가 달라 사용자 정의 테이블로 가정했습니다.

뷰 레이어 구성

① 계정 매핑 테이블

어느 계정이 평가손익이고 어느 계정이 장부금액인지, 효과를 어디에 반영하는 계정인지를 정하는 자리입니다. 소급 처리 점검(C04)이 이 구분에 기대므로 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 계정 체계가 바뀌어도 과거 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZFVT_ACCTMAP — 평가 계정 매핑 (투명 테이블)
"  평가손익 계정 · 장부금액 계정 · 효과 인식 위치를 잇는다.
"  코드에 박지 않는 이유 : 계정이 늘 때마다 개발자를 부르게 되면
"  점검 규칙이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '평가 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zfvt_acctmap {
  key mandt     : mandt not null;
  key ktopl     : ktopl not null;        " 계정과목표
  key saknr     : saknr not null;        " 계정
  acct_role     : abap.char(2);          " BV 장부금액 · PL 평가손익 · OC 기타포괄손익 · RE 이익잉여금
  recog_where   : abap.char(2);          " 효과를 반영하는 위치 PL / OC / RE
  valid_from    : abap.dats;
  valid_to      : abap.dats;
}

② 평가 보고 기록 테이블

회사가 정한 평가기법과 입력값을 그대로 담는 자리입니다. 앱은 이 값을 바꾸지 않고 읽기만 합니다. 직전/당기 구분(A/B)을 키에 둔 이유는 같은 종목을 두 기법으로 나란히 보관하기 위해서이며, 실제 원천이 금융상품 평가 기능의 어느 테이블인지는 환경에 따라 달라 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZFVT_VALREC — 평가 보고 기록 (투명 테이블, 원천 위치는 확인 필요)
"  종목 · 기간 · 구분(A 직전 기법 / B 당기 기법)별 기법과 입력값.
"  기초금액 × 계수 = 평가액. 회사가 정한 값을 그대로 둔다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '평가 보고 기록'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zfvt_valrec {
  key mandt     : mandt not null;
  key period    : abap.numc(6) not null;   " 기준 연월
  key inst_id   : abap.char(10) not null;  " 종목
  key basis     : abap.char(1) not null;   " A 직전 기법 · B 당기 기법
  tech_code     : abap.char(2);            " MK · MU · IN · CO · OP
  base_amt      : abap.dec(18,0);          " 평가 기초금액
  factor        : abap.dec(12,4);          " 계수
  report_amt    : abap.dec(18,0);          " 평가 보고 금액
}

③ 종목 차원 뷰

종목 하나당 한 행입니다. 유형과 공정가치 서열, 변경 사유가 여기서 정해지므로 값 도움말과 조회조건의 목록이 이 뷰 하나를 보게 합니다. 서열(1·2·3)은 공시 대상 판정에 쓰이므로 회사가 입력한 값을 바꾸지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FvInstrument — 종목 차원
"  종목 한 행. 유형 · 서열 · 변경 사유를 가진다.
"  차원 뷰를 따로 두는 이유 : 큐브에서 조인을 한 번만 걸고
"  값 도움말이 이 뷰 하나를 보게 하기 위해서다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '평가 종목 차원'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'InstId'
define view entity ZI_FvInstrument
  as select from zfvt_instmaster as Inst      " 종목 마스터(회사 정의) — 확인 필요
{
  key Inst.inst_id    as InstId,
      Inst.inst_name  as InstName,
      Inst.inst_type  as InstType,            " E 지분 · D 파생 · B 채무 · R 투자부동산
      Inst.level_prev as LevelPrev,           " 직전 서열
      Inst.level_curr as LevelCurr,           " 당기 서열
      Inst.reason_cd  as ReasonCode           " 기법 변경 사유
}

④ 평가 큐브 — 직전/당기 기법으로 다시 계산

평가액을 다시 계산하는 자리입니다. 기초금액 × 계수를 원 미만 반올림하는 규칙을 이 뷰 한 곳에만 둡니다. 화면과 대사가 같은 값을 보려면 반올림 규칙이 한 곳에 있어야 합니다. 평가 보고 금액과의 차이도 여기서 열로 만듭니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FvValuationCube — 구분(A/B)별 평가액 재계산
"  평가액 = round(기초금액 × 계수, 0). 반올림 규칙은 여기에만 둔다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                 : '평가 재계산 큐브'
@Analytics.dataCategory            : #CUBE
define view entity ZI_FvValuationCube
  as select from zfvt_valrec as V
  association [1..1] to ZI_FvInstrument as _Inst on _Inst.InstId = $projection.InstId
{
  key V.period                              as Period,
  key V.inst_id                             as InstId,
  key V.basis                               as Basis,        " A 직전 기법 · B 당기 기법
      V.tech_code                           as TechCode,
      @Semantics.amount.currencyCode : 'Currency'
      cast( round( V.base_amt * V.factor, 0 ) as abap.curr(18,0) ) as CalcVal,
      @Semantics.amount.currencyCode : 'Currency'
      V.report_amt                          as ReportVal,    " 평가 보고 금액
      cast( 'KRW' as abap.cuky )            as Currency,
      _Inst
}

⑤ 효과 분해 뷰

직전 기법과 당기 기법의 평가액을 한 줄로 붙여 두 효과를 계산합니다. 시장·입력변수 효과는 A 평가액에서 직전 공정가치를 뺀 값, 기법 변경 효과는 B 평가액에서 A 평가액을 뺀 값입니다. 두 효과의 합이 곧 총변동이라 잔차가 구조적으로 0입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FvTechEffect — 시장 효과 · 기법 변경 효과 분해
"  직전 공정가치 + MktEff + TechEff = 당기 공정가치 (잔차 0)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                 : '기법 변경 효과 분해'
define view entity ZI_FvTechEffect
  as select from ZI_FvValuationCube as B
  inner join   ZI_FvValuationCube   as A
    on  A.Period = B.Period and A.InstId = B.InstId and A.Basis = 'A'
  inner join   zfvt_prevfv          as P
    on  P.period = B.Period and P.inst_id = B.InstId   " 직전 보고일 공정가치
{
  key B.Period,
  key B.InstId,
      A.TechCode                              as TechPrev,
      B.TechCode                              as TechCurr,
      case when A.TechCode <> B.TechCode then 'Y' else 'N' end as ChgYn,
      P.prev_fv                               as PrevFv,
      A.CalcVal - P.prev_fv                   as MktEff,       " 시장 · 입력변수 효과
      B.CalcVal - A.CalcVal                   as TechEff,      " 기법 변경 효과
      B.CalcVal                               as CurrFvNew
}
where B.Basis = 'B' 

⑥ 장부 반영액 뷰

전표 원천(ACDOCA)에서 종목별 장부 공정가치와 기법 변경 효과 반영액을 모읍니다. 종목을 전표 라인에 붙이는 연결 키가 이 뷰의 전제이고, 어느 필드를 쓸지는 회사 정책이라 확인 필요입니다. 인식 위치는 계정 매핑에서 가져와 소급 처리 점검에 씁니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FvBookFv — 종목별 장부 반영액 (ACDOCA 집계)
"  종목 연결 키(예: 지정 필드 ZUONR 또는 사용자 정의 필드)는 확인 필요.
"  계정 매핑으로 장부금액 계정 / 평가손익 계정 / 인식 위치를 가른다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                 : '종목별 장부 반영액'
define view entity ZI_FvBookFv
  as select from acdoca       as L
  inner join     zfvt_acctmap as M
    on  M.saknr = L.racct and M.valid_from <= L.budat and M.valid_to >= L.budat
{
  key L.rbukrs                                    as CompanyCode,
  key L.gjahr                                     as FiscalYear,
  key L.zuonr                                     as InstId,
      M.recog_where                               as RecogWhere,
      sum( case when M.acct_role = 'BV' then L.hsl else 0 end ) as BookFv,
      sum( case when M.acct_role = 'PL' or M.acct_role = 'OC' or M.acct_role = 'RE'
                then L.hsl else 0 end )           as BookTechEff
}
where L.rldnr = '0L'
group by L.rbukrs, L.gjahr, L.zuonr, M.recog_where

⑦ 점검 코드 판정 뷰

판정 규칙을 한 곳에 둡니다. 위에서 아래로 먼저 걸리는 하나만 붙이며, 결과는 “점검 필요”로 표시할 뿐 단정하지 않습니다. 규칙의 문구와 순서는 회사 정책과 감사인 의견에 따라 조정될 수 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FvTechCheck — 점검 코드 판정 (C01 ~ C06, 없으면 I00)
"  먼저 걸리는 하나만 붙인다. 표시는 "점검 필요" 까지만 한다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                 : '기법 변경 점검 판정'
define view entity ZI_FvTechCheck
  as select from ZI_FvTechEffect as E
  inner join   ZI_FvInstrument   as I on I.InstId = E.InstId
  left outer join ZI_FvBookFv    as B on B.InstId = E.InstId
  left outer join zfvt_disc      as D on D.inst_id = E.InstId     " 공시 대상 표시(회사 정의)
{
  key E.Period,
  key E.InstId,
      case
        when E.ChgYn = 'Y' and I.ReasonCode = ''                   then 'C01'  " 변경 사유 없음
        when D.chg_book <> E.ChgYn                                  then 'C02'  " 변경 표시 불일치
        when E.ChgYn = 'Y' and B.BookTechEff <> E.TechEff           then 'C03'  " 효과 불일치
        when E.ChgYn = 'Y' and B.RecogWhere = 'RE'                  then 'C04'  " 소급 처리
        when B.BookFv <> E.CurrFvNew                                then 'C05'  " 장부 공정가치 불일치
        when E.ChgYn = 'Y' and D.disc_yn <> 'Y'                     then 'C06'  " 공시 대상 표시 없음
        else 'I00'
      end as CheckCode
}

⑧ 소비 쿼리 — 조회조건과 열

화면의 조회조건과 같은 필드에 필터 속성을 붙이고 기본 정렬을 둡니다. 이렇게 두면 같은 CDS 를 표준 Fiori 도구와 이 앱이 함께 쓸 수 있습니다. 필터 필수 지정은 대량 데이터에서 전체 스캔을 막는 안전장치입니다.

" ────────────────────────────────────────────────────────────────
"  ZC_FvTechChangeQuery — 소비 쿼리
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '평가기법 변경 점검'
@Metadata.allowExtensions : true
define view entity ZC_FvTechChangeQuery
  as select from ZI_FvTechEffect as E
  association [0..1] to ZI_FvTechCheck as _Chk on _Chk.InstId = $projection.InstId
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key E.Period,
  @UI.lineItem : [{ position : 10 }]
  key E.InstId,
  @UI.lineItem : [{ position : 20 }]  E.TechPrev,
  @UI.lineItem : [{ position : 30 }]  E.TechCurr,
  @Consumption.filter.selectionType : #SINGLE
  @UI.lineItem : [{ position : 40 }]  E.ChgYn,
  @UI.lineItem : [{ position : 50 }]  E.TechEff,
  @UI.lineItem : [{ position : 60 }]  _Chk.CheckCode
}

⑨ 권한(DCL)

집계를 읽는 자리에 걸어야 합계로 새지 않습니다. 이 앱은 회사코드와 평가 계정 권한을 기준으로 삼으며, 어느 권한 객체를 쓸지는 회사의 권한 설계에 따라 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FVTECHCHECK — 접근 제어
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '평가기법 변경 점검 권한'
@MappingRole : true
define role ZI_FVTECHCHECK {
  grant select on ZI_FvBookFv
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑩ 서비스 정의

쿼리를 OData V2 서비스로 노출합니다. 서비스 바인딩을 게시한 뒤 화면의 서비스 주소를 이 바인딩 주소로 교체하는 것이 운영 연결의 마지막 단계입니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_FvTechChange — 서비스 정의 / 바인딩
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '평가기법 변경 점검 서비스'
define service ZUI_FvTechChange {
  expose ZC_FvTechChangeQuery as TechChange;
  expose ZI_FvTechEffect      as TechEffect;
  expose ZI_FvTechCheck       as TechCheck;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영으로 옮기기 전에 정해 두어야 하는 항목입니다.

운영 데이터로 갈 때

종목이 수천 건이고 전표가 수천만 행으로 늘면 계산 위치가 달라집니다. 평가 재계산과 효과 분해는 종목 단위 연산이라 DB 에서 빠르게 끝나지만, 장부 반영액은 전표 집계라 기준 연월과 회사코드를 필수 조건으로 고정해 전체 스캔을 막아야 합니다. 종목 연결 키와 계정에는 인덱스 또는 복합 키 설계를 두고, 목록은 서버 쪽에서 쪽 나누기($top · $skip)와 총건수($inlinecount)를 쓰며, 응답 시간 목표는 도입 환경에서 정해 확인 필요입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

기준서와 판단

도입과 운영