SAP Level 3 공정가치 투입변수·민감도 점검 — K-IFRS 제1113호, 관측 불가능 투입변수의 범위·가중평균과 민감도 영향을 공시 초안·장부와 맞춰본다

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

Level 3 로 측정하는 금융상품은 관측할 수 없는 투입변수에 기대어 가격이 정해집니다. 그래서 공시에는 투입변수의 범위와 가중평균, 그리고 투입변수를 합리적으로 달리 가정했을 때 공정가치가 얼마나 달라지는지가 따라붙습니다. 이 숫자들은 평가 파일, 공시 초안, 원장에 나뉘어 있어 결산 막바지에 서로 맞는지 확인하는 일이 가장 고됩니다. 이 앱은 그 세 자료를 같은 화면에서 다시 계산해 맞춰 보는 조회·점검 화면입니다.

핵심 포인트 여섯 가지

사례로 보는 효과

이 앱은 검증용 샘플 3개 기준 연월에서 579건의 검사를 돌려 서비스 계산과의 차이 0건을 확인했습니다. 샘플에는 평가-장부 차이 3건, 공시 가중평균 불일치 2건, 공시 범위 불일치 1건을 의도적으로 넣었고, 앱이 이를 대사 차이와 분리해 점검 필요로 가려냈습니다.

도입하면 달라지는 것

• 평가 결과·공시 초안·장부 세 자료를 같은 형식으로 대조
• 범위·가중평균 재계산 근거를 화면에서 바로 제시
• 유의 종목의 공시 표시 누락을 결산 앞 단계에서 발견
• 합계 검산을 사람 손이 아닌 대사식으로 반복

이런 회사에 맞습니다

공정가치 서열체계 Level 3 로 측정하는 금융상품이 있고, 관측 불가능 투입변수 정량정보와 민감도 공시를 준비하는 재무회계팀·평가 담당자·내부 검토자에게 맞습니다. 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

사용 방법

1. 조회조건 입력 — 기준 연월(필수, 예: 202609)을 넣습니다. 종목명 일부, 범주, 평가기법, 점검 코드, 점검 결과는 선택이며 "전체"는 조건을 걸지 않습니다.
2. 조회 — 조회조건 오른쪽 끝의 조회 버튼을 누르거나 기준 연월·종목명 칸에서 Enter 를 누릅니다. 화면을 열면 기본 조건으로 한 번 자동 조회됩니다.
3. 요약 지표 확인 — 종목 수, 자산·부채 공정가치 합계, 불리 시나리오 영향 합계, 유의 종목, 점검 필요 종목, 대사 차이 건수가 한 줄에 나옵니다.
4. 탭 이동 — 투입변수 정량정보 → 민감도 명세 → 범주별 영향 → 대사 결과 순서로 봅니다.
5. 상세 확인 — 민감도 명세에서 종목 행을 누르면 상승·하락 시나리오의 공정가치와 영향, 방향 확인이 열립니다.
6. CSV 내려받기 — 지금 보는 탭을 조회조건 그대로 UTF-8 파일로 받습니다.

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

화면의 숫자는 서비스가 계산하고, 그 계산을 서비스와 무관한 코드로 한 번 더 계산해 비교했습니다. 검사는 579건이고 차이는 0건입니다. 의도적으로 넣은 점검 대상 6건(평가-장부 차이 3 · 공시 가중평균 2 · 공시 범위 1)은 대사 차이와 섞이지 않게 따로 세었습니다.

무엇으로 만들었는가

화면은 OpenUI5 표준 컨트롤(sap_horizon 테마)로 만들었고 OData V2 서비스를 바라봅니다. 샘플 서비스는 엔티티셋 다섯 개(종목 · 시나리오 · 묶음 · 범주 · 대사)로 구성되며, 운영에서는 같은 계약의 CDS 서비스로 바꿔 끼웁니다.

앱 구성
├─ 시작 파일 · 앱 설정 · 컴포넌트
├─ 화면 정의(메인 화면 · 상세 창)
├─ 컨트롤러(조회 · 정렬 · 상세 · 내보내기)
├─ 모델 보조(표시 형식 · 오류 처리)
├─ 문구 · 스타일
└─ 서비스 구현(종목 판정 · 묶음 재계산 · 범주 집계 · 대사)

실행 화면

아래 화면은 모두 검증용 샘플 데이터(가상 종목, 단위 억 원)로 실제 렌더링한 것입니다. 종목명과 금액은 모두 가상입니다.

조회와 점검 필요 좁히기

기준 연월은 필수이고 기본값은 202609 입니다. 화면을 열면 자동으로 한 번 조회하므로 아무것도 누르지 않아도 스무 종목의 합계가 보입니다. 요약 지표 중 "점검 필요" 종목 수와 "불리 시나리오 영향 합계"를 먼저 보면 됩니다. 묶음 표에서는 재계산한 범위·가중평균과 공시 초안 값이 나란히 있어 어느 묶음이 다른지 곧바로 읽힙니다.

샘플에서는 202609 기준 다섯 종목이 남습니다. 행마다 점검 코드가 붙어 평가-장부 차이, 방향 상이, 공시 미표시, 범위 이탈, 비대칭 중 무엇이 걸렸는지 구분됩니다. "점검 필요"는 원인이나 위반을 단정하는 표시가 아니라 다시 확인하라는 신호이며, 기준액과 비대칭 한도는 회사가 정하는 가상의 샘플 값입니다.

민감도와 범주별 영향

자산은 공정가치 변동이 그대로 영향이 되고 부채는 부호가 반대입니다. 부채는 공정가치가 늘면 손실이기 때문입니다. 상승과 하락의 변동 폭이 2배를 넘게 다르면 옵션성이나 볼록성 같은 근거를 확인하라는 뜻으로 비대칭 점검을 표시합니다.

유리 영향은 종목별로 더 좋은 쪽 시나리오를, 불리 영향은 더 나쁜 쪽 시나리오를 합한 값입니다. 종목 간 상관을 보지 않는 단순 합산이므로 공시의 합계와 같은 개념인지는 회사 정책으로 확인해야 합니다.

대사와 상세

정합성 대사는 화면이 스스로 합계를 다시 재는 식이라 차이 건수가 0 이어야 정상입니다. 장부 점검 대사는 평가와 장부, 공시 초안과 재계산을 맞추는 식이라 점검 필요 종목이 있으면 차이가 나올 수 있고, 이 차이는 계산 오류와 분리해 읽습니다.

목록에서 본 숫자를 창 안에서 풀어 보여 주는 화면입니다. 방향 확인 칸에서 기대와 다른 시나리오가 바로 드러나고, 창을 닫으면 조회조건과 스크롤 위치가 그대로 남아 다음 종목으로 이어 갈 수 있습니다.

판정 규칙 — 점검 코드

종목은 아래 순서로 먼저 걸리는 코드 하나를 표시합니다. 기준값은 샘플이며 회사 정책과 감사인의 해석으로 정합니다.

산출 순서

조회조건과 결과 컬럼

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

요구사항 매핑표

기준서 요구의 세부 범위는 회사의 자산·부채 구성에 따라 달라지므로 이 글에서는 확인 필요로 남겨 둡니다.

도입 전에 검토할 항목

CDS 구성

아래는 같은 점검을 S/4HANA 의 CDS 로 옮길 때의 구성안입니다. 샘플 앱의 서비스 로직과 같은 규칙을 뷰 단계로 나눈 스케치이며, 객체 이름은 설명을 위한 가상의 이름입니다(운영에서는 회사 고객 네임스페이스 접두를 붙입니다). 표준 CDS 뷰의 이름과 필드는 릴리스별 확인 필요이고, 여기서는 원천 테이블을 직접 읽는 형태로 적었습니다.

뷰 레이어 구성

① 평가 입력 자료 — 종목별 투입변수와 시나리오 공정가치를 담는 자리

표준에는 Level 3 평가 모델의 투입변수와 시나리오 결과를 담는 테이블이 없습니다. 평가는 보통 별도 모델이나 파일에서 이루어지므로 결과를 적재할 테이블을 두는 것이 출발점이며, 적재 방식은 고객사 환경에 따라 달라 확인 필요입니다.

" ─────────────────────────────────────────────────────────────
"  l3in_valinput — Level 3 종목 평가 입력 자료
"  역할 : 종목별 평가기법, 투입변수 기준값·변동폭, 기준/상승/하락 공정가치를 보관
"  이렇게 나눈 이유 : 평가 결과는 SAP 밖의 모델에서 나오므로 적재 대상 테이블이 필요하다
"         적재 주기와 책임 부서는 운영 전에 합의한다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : 'Level 3 평가 입력 자료'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table l3in_valinput {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key period    : abap.numc(6) not null;     " 기준 연월 6자리
  key inst_no   : abap.char(10) not null;    " 종목 번호
  category      : abap.char(2) not null;     " 손익 · 기타포괄손익 구분
  kind          : abap.char(1) not null;     " A 자산 / L 부채
  technique     : abap.char(4) not null;     " 평가기법
  input_name    : abap.char(20) not null;    " 관측 불가능 투입변수
  input_base    : abap.dec(10,2);            " 투입변수 기준값
  shock         : abap.dec(10,2);            " 합리적으로 가능한 변동폭
  fv_base       : abap.curr(18,0);           " 기준 공정가치
  fv_up         : abap.curr(18,0);           " 투입변수 상승 시
  fv_down       : abap.curr(18,0);           " 투입변수 하락 시
  currency      : abap.cuky(5) not null;
}

② 유의성 기준값 — 1.5억·3.0억을 데이터로 두는 자리

유의성 기준액과 비대칭 한도는 회사 정책과 감사인의 해석에 따라 달라질 수 있습니다. 샘플의 값을 뷰에 박아 두면 정책이 바뀔 때마다 이송이 필요하므로 회사코드 단위로 읽는 테이블로 분리합니다.

" ─────────────────────────────────────────────────────────────
"  l3in_param — 유의성·비대칭 기준값
"  역할 : 범주별 유의성 기준액과 상·하 비대칭 한도를 회사 정책으로 보관
"  이렇게 나눈 이유 : 샘플 값(1.5억 · 3.0억 · 2.00)은 설명을 위한 값일 뿐이다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : 'Level 3 점검 기준값'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table l3in_param {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key category  : abap.char(2) not null;
  signif_amt    : abap.curr(18,0);           " 유의성 기준액
  asym_limit    : abap.dec(5,2);             " 비대칭 한도
  currency      : abap.cuky(5) not null;
}

③ 공시 초안 — 이미 공시하기로 한 범위와 가중평균을 담는 자리

공시 초안과의 대조가 이 앱의 핵심이므로 묶음 단위의 공시 값을 별도 테이블로 둡니다. 초안이 확정되면 같은 구조로 다시 적재해 확정본과 비교할 수 있습니다.

" ─────────────────────────────────────────────────────────────
"  l3in_disc — 공시 초안 값(묶음 단위)
"  역할 : 평가기법·투입변수 묶음별로 공시하기로 한 최소·최대·가중평균과 민감도 표시 여부
" ─────────────────────────────────────────────────────────────
@EndUserText.label : 'Level 3 공시 초안'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table l3in_disc {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key period    : abap.numc(6) not null;
  key technique : abap.char(4) not null;
  key input_name: abap.char(20) not null;
  disc_min      : abap.dec(10,2);
  disc_max      : abap.dec(10,2);
  disc_wtd      : abap.dec(10,2);            " 공시 가중평균
  sens_shown    : abap_boolean;              " 민감도 공시 표시 여부
}

④ 원장 공정가치 뷰 — 장부 잔액을 종목 단위로 모으는 기준 뷰

장부 공정가치는 총계정원장 잔액에서 가져옵니다. 종목과 계정의 연결 방식(계정 하나가 한 종목인지, 속성으로 구분하는지)은 회사마다 달라 확인 필요이며, 아래는 종목 번호를 배정 필드에서 읽는다고 가정한 스케치입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '원장 공정가치 (스케치)'
define view entity l3in_i_ledgerfv
  as select from acdoca
{
  key rbukrs                          as CompanyCode,
  key cast( fiscyearper as abap.numc(6) ) as Period,   " 연월 변환은 확인 필요
  key zuonr                           as InstNo,       " 종목 연결 필드는 회사별 확인 필요
      rhcur                           as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( hsl )                      as LedgFv
}
where rldnr = '0L'
group by rbukrs, fiscyearper, zuonr, rhcur

⑤ 종목 민감도 큐브 — 변동·영향·점검 코드를 한 곳에서 계산

판정을 뷰에 두는 이유는 어떤 화면이나 배치가 읽어도 같은 결론이 나오게 하기 위해서입니다. 점검 코드는 먼저 걸리는 하나만 표시하도록 case 문의 순서로 우선순위를 표현합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@EndUserText.label: '종목 민감도 큐브 (스케치)'
define view entity l3in_i_instcube
  as select from l3in_valinput as V
  association [0..1] to l3in_i_ledgerfv as _Ledger
    on  _Ledger.CompanyCode = $projection.CompanyCode
    and _Ledger.Period      = $projection.Period
    and _Ledger.InstNo      = $projection.InstNo
  association [0..1] to l3in_param as _Param
    on  _Param.bukrs    = $projection.CompanyCode
    and _Param.category = $projection.Category
{
  key V.bukrs    as CompanyCode,
  key V.period   as Period,
  key V.inst_no  as InstNo,
      V.category as Category,
      V.kind     as Kind,
      V.fv_base  as BaseFv,
      V.fv_up - V.fv_base   as DeltaUp,
      V.fv_down - V.fv_base as DeltaDn,
      case V.kind when 'L' then -1 else 1 end as Sign,
      ( V.fv_up - V.fv_base ) *
        case V.kind when 'L' then -1 else 1 end as EffUp,
      ( V.fv_down - V.fv_base ) *
        case V.kind when 'L' then -1 else 1 end as EffDn,
      cast( _Ledger.LedgFv as abap.curr(18,0) ) as LedgFv,
      case
        when _Ledger.LedgFv <> V.fv_base then 'R06'     " 평가-장부 차이
        else 'I00'                                      " 나머지 코드는 같은 방식으로 이어 붙임
      end as CheckCode,
      _Ledger, _Param
}

⑥ 조회 쿼리 — 화면에 노출할 조건과 정렬

계산은 큐브가 하고, 쿼리는 조회조건으로 노출할 필드와 기본 정렬만 정합니다. 이렇게 나누면 화면 변경이 계산 뷰를 건드리지 않습니다.

@EndUserText.label: '종목 점검 쿼리 (스케치)'
@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
define view entity l3in_c_inst
  as projection on l3in_i_instcube
{
  key CompanyCode,
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key Period,
  key InstNo,
  @Consumption.filter.selectionType: #SINGLE
  Category,
  Kind,
  BaseFv, DeltaUp, DeltaDn, EffUp, EffDn, LedgFv,
  @Consumption.filter.selectionType: #SINGLE
  CheckCode
}

⑦ 접근 제어 — 회사코드 권한을 아래에서 한 번만

권한을 기준 뷰 가까이에서 걸면 모든 탭과 합계가 같은 범위를 봅니다. 권한 객체와 범위는 보안 담당과 함께 정해야 하므로 확인 필요입니다.

@EndUserText.label: '종목 민감도 접근 제어 (스케치)'
@MappingRole: true
define role l3in_i_instcube_dcl {
  grant select on l3in_i_instcube
    where ( CompanyCode ) = aspect pfcg_auth( f_bkpf_buk, bukrs, actvt = '03' );
}

⑧ 서비스 정의와 바인딩 — 화면이 바라보는 주소

샘플 앱이 쓰는 서비스 계약(서비스 이름, 엔티티셋, 키, $filter)을 그대로 지키면 화면 코드는 바꾸지 않고 서비스 경로만 운영 서비스로 바꾸면 됩니다.

@EndUserText.label: 'Level 3 투입변수·민감도 점검 서비스 (스케치)'
define service l3input_srv {
  expose l3in_c_inst  as InstSet;
  expose l3in_c_group as GroupSet;      " 묶음 정량정보 쿼리(위와 같은 방식)
  expose l3in_c_cat   as CategorySet;   " 범주별 영향 쿼리
  expose l3in_c_recon as ReconSet;      " 대사 쿼리
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 일은 모두 코드가 아니라 합의에서 시작합니다.

위 여섯 가지가 정해지면 기술 작업은 CDS 뷰(기준 뷰 · 큐브 · 쿼리 · 권한)를 만들고 서비스를 게시하는 일입니다.

자주 묻는 질문

도입을 검토하는 분들이 자주 묻는 내용을 네 묶음 27문항으로 정리했습니다. 이 앱은 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

숫자와 판정

화면과 사용

SAP 연계와 데이터

도입과 운영