별도재무제표 투자 측정방법 점검 — 원가법·지분법·IFRS 9 를 범주별로 다시 계산해 원장 장부금액과 맞춰 보는 화면

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

별도재무제표에서 종속기업·공동기업·관계기업 투자는 한 번 정한 방법으로 끝나는 계정이 아닙니다. IAS 27 별도재무제표(K-IFRS 제1027호) 는 이 투자들을 원가로, IFRS 9 로, 또는 지분법(IAS 28)으로 회계처리하되 투자 범주마다 같은 방법을 적용하도록 요구합니다. 월마감 때 회계팀이 받는 질문은 늘 같습니다. 같은 범주 안에서 방법이 섞인 투자는 없는가, 방법대로 다시 계산한 금액이 원장과 맞는가, 처분손익은 처분 시 장부금액 기준으로 맞게 잡혔는가.

지금 이 세 질문은 표준 원장 조회 화면 여러 개와 엑셀 대장, 건별 메모로 흩어져 있습니다. 투자가 수십 건이면 버티지만 범주가 늘고 방법이 섞이기 시작하면 건별로 열어 보는 방식은 오래 걸리고, 어디까지 확인했는지도 남지 않습니다. 이 앱은 투자 한 건 한 건을 정책 방법·적용 방법·재계산 금액·원장 금액 네 가지로 한 줄에 놓고, 확인이 필요한 투자만 점검 코드로 가려 줍니다.

같은 범주 안에서 방법이 섞여도, 건별로 열어 보기 전에는 모른다

투자 범주마다 정책 방법이 있습니다. 이 사례 데이터에서는 종속기업과 공동기업이 원가법, 관계기업이 지분법입니다. 그런데 투자 36건 가운데 5건은 범주 정책과 다른 방법으로 장부가 잡혀 있습니다. 표준 화면에는 "범주 안에서 방법이 같은가"를 한 번에 보여 주는 곳이 없어 보통 엑셀 대장을 놓고 눈으로 대조합니다. 이 앱은 범주별로 정책과 다른 방법의 건수를 세어 보여 주고, 점검 코드 M01 로 해당 투자만 걸러 줍니다.

방법마다 산식이 달라, 엑셀 재계산이 건별로 갈라진다

원가법은 취득원가에서 누적 손상차손을 뺍니다. 지분법은 취득원가에 취득 후 순손익 지분과 기타포괄손익 지분을 더하고 수취 배당과 손상차손을 뺍니다. IFRS 9 로 회계처리하는 투자는 보고기간 말 공정가치를 씁니다. 세 산식을 건별 엑셀에 따로 두면 월마감마다 어느 칸을 고쳤는지 추적이 어려워집니다. 이 앱은 적용 방법에 따라 산식을 골라 재계산하고, 투자 상세 창에 산식 줄을 그대로 보여 줍니다.

원장과 재계산이 어긋나면, 어느 투자인지 거꾸로 찾아야 한다

원장 장부금액 합계가 재계산 합계와 10.58억 다르다는 사실까지는 합계만 봐도 알 수 있습니다. 어려운 것은 그 차이가 어느 투자의 손상·배당·공정가치 갱신 누락인지 찾는 일입니다. 이 앱은 차이를 투자·범주·방법 세 단위로 나눠 보여 주고, 원장과 재계산이 다른 투자 4건에 D01 을 붙여 줍니다. 손상징후 후보(원가법 투자의 순자산 지분 참고액이 장부금액의 70% 미만)는 X01 로 따로 표시하며, 손상 여부의 판단은 회사와 감사인이 합니다.

처분손익은 처분 시 장부금액이 맞아야 맞는다

처분손익은 처분대가에서 처분 시 장부금액을 뺀 값입니다. 처분 시 장부금액을 어떤 방법으로 정했는지에 따라 원장의 처분손익이 달라질 수 있어, 이 앱은 처분 8건을 다시 계산해 원장 값과 나란히 둡니다. 사례에서는 1건이 35억 다르게 나와 S01 로 표시됩니다.

사용 방법

1. 조회조건 입력 — 기준 연월(6자리, 필수)을 넣습니다. 투자 범주·적용 방법·취득일 기간·점검 코드·점검 결과는 선택이며 "전체"는 조건을 걸지 않는다는 뜻입니다.
2. 조회 — 조회 버튼은 조회조건 줄의 오른쪽 끝에 있습니다. 기준 연월 칸에서 Enter 를 눌러도 같은 조회가 실행되고, 처음 열 때는 기준 연월 202412 로 자동 조회합니다.
3. 요약 확인 — 상단 숫자 8개(투자 건수·취득원가·재계산 장부금액·원장 장부금액·차이·정책과 다른 방법 건수·점검 필요 건수·정합성 대사 차이 건수)를 먼저 봅니다.
4. 탭·범주 이동 — 투자 명세 → 범주별 방법 일관성 → 측정방법별 집계 → 처분손익 → 대사 결과 순서로 봅니다.
5. 행 클릭 상세 — 투자 명세에서 행을 누르면 적용 방법의 재계산 산식과 원장 장부금액, 점검 코드가 상세 창으로 열립니다.
6. 내보내기 — 탭 위쪽의 CSV 내려받기로 지금 보고 있는 탭의 조회 결과를 UTF-8(BOM) 파일로 받습니다.

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

리포트에서 가장 비싼 질문은 "이 숫자 맞아?" 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 검증용 샘플 데이터 전수로 돌렸습니다. 대사는 두 종류로 나눴습니다. 정합성 대사는 화면 안의 집계끼리 맞추는 것이라 차이가 곧 화면의 오류이고, 장부 점검 대사는 원장과 재계산을 맞추는 것이라 차이가 곧 확인할 투자의 수입니다.

정합성 대사 6개는 모두 차이 0 입니다. 장부 점검 3개의 차이는 의도적으로 넣은 예외 건입니다 — 정책과 다른 방법 5건(M01), 원장·재계산 차이 4건(D01 3건과 M01 와 겹치는 1건), 원가법 손상징후 후보 2건(X01), 처분 원장 차이 1건(S01). 이 예외가 점검 코드로 정확히 걸러지는지도 전수로 확인했고, 합계로 보면 점검 필요 투자는 10건입니다. 화면 쪽은 별도로 브라우저 자동화로 조회·탭 이동·행 상세·CSV 내려받기를 돌려 요약 숫자와 표의 합계가 같은지 확인했습니다.

무엇으로 만들었나

앱 정보

실행 화면

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

처음 열었을 때

조회조건, 요약 숫자 8개, 탭 5개가 한 화면에 세로로 놓입니다. 열자마자 기준 연월 202412 로 조회되어 빈 화면을 먼저 보는 일이 없습니다.

위쪽 안내 띠는 이 화면이 점검용이며 최종 판단은 회사와 감사인이 한다는 취지를 먼저 밝힙니다. 조회조건은 한 줄에 놓이고 조회 버튼은 그 오른쪽 끝에 있습니다. 요약 숫자는 투자 36건, 취득원가 2,514억, 재계산 장부금액 2,645.12억, 원장 장부금액 2,634.54억, 차이 −10.58억이며, 정책과 다른 방법 5건과 점검 필요 투자 10건, 정합성 대사 차이 0건이 이어집니다. 탭 이름 위의 작은 숫자는 그 탭에 담긴 행 수입니다.

조회조건의 점검 코드 칸에서 M01 을 고르고 조회 버튼을 누르거나 기준 연월 칸에서 Enter 를 누른 결과입니다. 투자 명세 탭 이름 위의 숫자가 36에서 5로 줄어듭니다. 어떤 투자부터 볼지 가리는 첫 단계로 쓰고, "전체"로 되돌리려면 초기화 버튼을 누릅니다.

범주와 방법으로 묶어 보기

투자 한 건씩 보기 전에 범주와 방법으로 묶은 숫자를 먼저 봅니다. 같은 36건을 두 가지 방향으로 나눠 본 표입니다.

이 표는 범주를 기준으로 한 줄씩 보여 줍니다. 관계기업은 정책 방법이 지분법이고 14건 중 1건이 다른 방법입니다. 공동기업은 정책 방법이 원가법이고 6건 중 1건이 다릅니다. 종속기업은 원가법 정책에 16건 중 3건이 다른 방법입니다. 건수가 하나라도 있으면 점검 판정이 "점검 필요"로 표시되며, 어느 방법이 맞는지는 이 화면이 정하지 않습니다.

원가법 19건은 원장이 재계산보다 2.64억 크고, 지분법 15건은 1.22억 작고, IFRS 9 2건은 12억 작습니다. 정책 일치 건수 열은 그 방법을 쓰는 투자 가운데 정책과 같은 건수를 보여 줍니다. 차이 건수와 점검 필요 건수가 함께 있어 금액이 작아도 건수로 먼저 볼 수 있습니다.

처분손익과 투자 상세

처분은 따로 다시 계산하고, 의심스러운 투자는 상세 창에서 산식 줄까지 내려갑니다.

2024년에 처분한 8건이 처분일 순서로 섭니다. 일곱 건은 재계산 처분손익과 원장 처분손익이 같고, 한 건(처분 번호 X002)만 재계산 −90억에 원장 −125억으로 35억 차이가 납니다. 처분일은 날짜 범위로도 좁힐 수 있습니다. 처분 시 장부금액을 어떤 방법으로 정했는지가 확인 대상입니다.

예시는 범주 정책이 원가법인데 IFRS 9 로 적용된 종속기업 투자입니다. 창 위쪽에는 투자 정보와 점검 결과(점검 필요 · 코드 M01)가 놓이고, 아래쪽 표에는 적용한 방법의 재계산 산식 줄이 순서대로 나옵니다. 산식 줄은 보고기간 말 공정가치와 재계산 장부금액 두 줄이며, 원장 장부금액(40.32억)과의 차이 −12억도 같은 창에서 봅니다. 창을 닫으면 조회 상태 그대로 표로 돌아옵니다.

대사와 예외 상황

마지막 탭은 화면이 스스로 한 검산의 결과입니다. 연결이 끊긴 경우의 안내도 이 묶음에 둡니다.

1~6번은 화면의 숫자끼리 맞추는 대사이며 모두 차이가 0입니다. 7~9번은 장부와 재계산을 맞추는 점검이며, 여기서 나오는 차이는 화면 오류가 아니라 확인해야 할 투자의 수입니다. 왼쪽 변과 오른쪽 변, 검사 건수, 차이 건수, 최대 차이가 한 줄에 있어 어느 줄에서 얼마가 벌어졌는지 바로 읽힙니다.

서비스가 응답하지 않으면 요약 숫자가 0 으로 비고 표에는 조건에 맞는 데이터가 없다는 문구가 나옵니다. 그 위에 안내 창이 열리고 세부사항 보기로 원인을 확인할 수 있습니다. 숫자가 0 으로 보이는 것이 데이터가 없어서인지 연결이 안 돼서인지를 구분하려고 둔 화면입니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 조회조건이 필터로 만들어져 서비스에 전달되고, 서비스는 투자별로 적용 방법에 맞는 산식으로 재계산 금액을 구한 뒤 원장 장부금액과의 차이와 점검 코드를 붙여 돌려줍니다. 범주별·방법별 집계와 대사는 그 결과를 묶어 만듭니다. 판정은 아래 순서로 하나만 표시합니다.

같은 투자에 여러 조건이 겹치면 1번부터 순서대로 하나만 표시합니다. 결과 문구는 "점검 필요"와 "확인 필요"로만 쓰고 확정적인 판단 문구는 쓰지 않습니다. 처리 순서는 이렇습니다.

1. 방법별 재계산 — 원가법, 지분법, IFRS 9 산식으로 재계산 장부금액을 구합니다.
2. 차이 계산 — 원장 장부금액 − 재계산 장부금액.
3. 집계 — 범주별·방법별 건수와 금액, 정책과 다른 방법 건수, 차이 건수.
4. 처분손익 — 처분대가 − 처분 시 장부금액.
5. 대사 — 정합성 6개와 장부 점검 3개.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건 줄과 요약 숫자는 줄바꿈으로 아래로 흘러내리고, 표는 폭이 모자라면 가로로 스크롤됩니다. 상세 창도 화면 폭에 맞춰 줄어듭니다. 요약 숫자와 탭 이름의 행 수만 먼저 훑는 용도로는 좁은 화면으로도 충분하고, 건별 확인은 넓은 화면을 권합니다.

파일 구성

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/                OData 서비스 정의 · 서비스 구현 · 데이터
media/                intro.mp4 · intro_poster.jpg

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 법정 보고와 감사 대응을 대신하지 않으며, 표준에서 원천을 확인하러 가는 길을 짧게 만드는 데 목적이 있습니다.

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

T-code 별 연계 지점

그래서 운영에 들어가도 기존 리포트는 없애지 않습니다. 표준 화면은 원천 확인과 감사 대응에 그대로 쓰고, 이 앱은 월마감 때 점검 후보를 먼저 훑는 용도로 곁에 둡니다.

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

이 앱은 CDS 뷰 위에 OData 서비스를 얹어 읽는 구조라 S/4HANA 의 CDS 분석 쿼리나 Fiori 분석 앱과 같은 층에서 동작합니다. 표준 분석 앱이 이미 해 주는 일(계정 잔액 조회 등)은 그대로 쓰고, 이 앱은 투자 대장과 정책 매핑이라는 회사 고유의 정보가 필요한 점검을 맡습니다. Analysis for Office 로 같은 CDS 쿼리를 열어 피벗으로 보는 용도와도 겹치지 않으며, 표준 분석 뷰 가운데 이번 용도에 맞는 것은 확인 필요입니다.

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

요구사항 매핑

CDS 구성

앱의 서비스 구현은 검증용 샘플 데이터 위에서 돌고, 운영 시스템에서는 아래 CDS 뷰가 같은 모양의 데이터를 내려보내는 것을 전제로 합니다. 뷰는 기준(정책·대장) → 차원 → 큐브(재계산) → 점검 쿼리 → 권한 → 서비스 순서로 쌓습니다. 표준 CDS 뷰 이름은 확인한 것만 쓰고, 확인하지 못한 곳은 원천 테이블 기준으로 적었습니다.

뷰 레이어 구성

① 투자 범주별 정책 방법 테이블 (ZSEPINV_POLICY)

정책 방법은 코드가 아니라 데이터로 둡니다. 여기서 정해진 값이 화면의 "정책 방법" 열과 M01 판정의 유일한 근거이며, 값을 정하는 일은 회계팀과 감사인의 몫입니다.

@EndUserText.label : '투자 범주별 정책 방법'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zsepinv_policy {
  " ─── 이름 : ZSEPINV_POLICY
  " ─── 역할 : 투자 범주(S 종속 / A 관계 / J 공동)별 정책 방법(C 원가법 / E 지분법 / F IFRS 9)
  " ─── 이렇게 나눈 이유 : 정책이 바뀔 때 뷰 코드를 건드리지 않고 이 테이블 행만 고치기 위해
  key client       : abap.clnt not null;
  key bukrs        : bukrs not null;
  key inv_category : abap.char(1) not null;
  policy_method    : abap.char(1) not null;
  valid_from       : abap.dats;
}

② 투자 대장 테이블 (ZSEPINV_REGISTER)

취득원가·지분율·취득 후 순손익 지분·기타포괄손익 지분·수취 배당·누적 손상차손·공정가치는 원장에 없는 회사 정보입니다. 대장의 표준 대응 테이블은 회사 구성에 따라 달라 확인 필요이며, 이 테이블은 그 대장을 적재하는 자리입니다.

@EndUserText.label : '투자 대장'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zsepinv_register {
  " ─── 이름 : ZSEPINV_REGISTER
  " ─── 역할 : 투자 1건당 1행. 취득정보와 취득 후 변동을 모아 둔다
  " ─── 이렇게 나눈 이유 : 방법별 재계산에 필요한 입력값을 원장과 분리해 관리하기 위해
  key client        : abap.clnt not null;
  key bukrs         : bukrs not null;
  key inv_id        : abap.char(10) not null;
  inv_category      : abap.char(1) not null;
  applied_method    : abap.char(1) not null;
  own_pct           : abap.dec(7,4);
  acq_date          : abap.dats;
  currency          : waers;
  @Semantics.amount.currencyCode : 'zsepinv_register.currency'
  acq_cost          : abap.curr(18,0);
  @Semantics.amount.currencyCode : 'zsepinv_register.currency'
  impair_acc        : abap.curr(18,0);
  @Semantics.amount.currencyCode : 'zsepinv_register.currency'
  share_ni          : abap.curr(18,0);
  @Semantics.amount.currencyCode : 'zsepinv_register.currency'
  share_oci         : abap.curr(18,0);
  @Semantics.amount.currencyCode : 'zsepinv_register.currency'
  div_cum           : abap.curr(18,0);
  @Semantics.amount.currencyCode : 'zsepinv_register.currency'
  fair_value        : abap.curr(18,0);
}

③ 원장 투자 장부금액 (ZI_SepInvLedger)

원장 장부금액을 투자 번호별로 한 번만 합산하는 층입니다. 투자 번호와 원장 라인을 잇는 필드(여기서는 지정 항목 ZUONR)는 회사의 전표 입력 규칙에 따라 다르므로 확인 필요이며, 계정 범위는 회사 계정체계에 맞춰 조정합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '원장 투자 장부금액'
define view entity ZI_SepInvLedger
  as select from acdoca
{
  " ─── 이름 : ZI_SepInvLedger
  " ─── 역할 : 투자 계정의 원장 금액을 회사코드·기간·투자 번호별로 합산
  " ─── 이렇게 나눈 이유 : 원장 합산을 한 곳에서만 해 모든 상위 뷰가 같은 값을 쓰도록 하기 위해
  key rbukrs                                    as CompanyCode,
  key gjahr                                     as FiscalYear,
  key poper                                     as Period,
  key zuonr                                     as InvestmentId,
      rhcur                                     as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( hsl )                                as LedgerBookAmount
}
where rldnr = '0L'
  and racct between '0000110000' and '0000119999'   -- 투자 계정 범위(회사 계정체계 기준, 확인 필요)
group by rbukrs, gjahr, poper, zuonr, rhcur

④ 투자 + 정책 (ZI_SepInvRegister)

대장과 정책 매핑을 이어 투자마다 정책 방법을 붙입니다. 정책과 적용 방법이 다르면 이 층에서 곧바로 불일치 표시가 되므로, 상위 뷰는 비교를 다시 하지 않습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '투자 대장과 정책 방법'
@ObjectModel.usageType: { serviceQuality: #B, sizeCategory: #M, dataClass: #MASTER }
define view entity ZI_SepInvRegister
  as select from zsepinv_register as r
    left outer join zsepinv_policy as p
      on  p.bukrs        = r.bukrs
      and p.inv_category = r.inv_category
{
  " ─── 이름 : ZI_SepInvRegister
  " ─── 역할 : 투자별 적용 방법과 범주 정책 방법을 한 행에 놓는다
  " ─── 이렇게 나눈 이유 : 정책 비교(M01)를 이 층에서 끝내 상위 뷰의 산식을 단순하게 하려고
  key r.bukrs                                   as CompanyCode,
  key r.inv_id                                  as InvestmentId,
      r.inv_category                            as Category,
      r.applied_method                          as AppliedMethod,
      p.policy_method                           as PolicyMethod,
      case when r.applied_method <> p.policy_method then 'X' else '' end as MethodMixFlag,
      r.own_pct                                 as OwnPercent,
      r.acq_date                                as AcquisitionDate,
      r.currency                                as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      r.acq_cost                                as AcquisitionCost,
      @Semantics.amount.currencyCode: 'Currency'
      r.impair_acc                              as AccumulatedImpairment,
      @Semantics.amount.currencyCode: 'Currency'
      r.share_ni                                as ShareOfProfit,
      @Semantics.amount.currencyCode: 'Currency'
      r.share_oci                               as ShareOfOci,
      @Semantics.amount.currencyCode: 'Currency'
      r.div_cum                                 as DividendsReceived,
      @Semantics.amount.currencyCode: 'Currency'
      r.fair_value                              as FairValue
}

⑤ 방법별 재계산 큐브 (ZC_SepInvRecalc)

이 뷰가 화면 숫자의 핵심입니다. 적용 방법에 따라 세 산식을 고르는 한 곳이며, 원장 금액과의 차이도 여기서 계산합니다. 산식은 이 뷰에서만 정의하고 다른 뷰는 결과만 읽습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '방법별 재계산 장부금액'
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #L, dataClass: #MIXED }
define view entity ZC_SepInvRecalc
  as select from ZI_SepInvRegister as reg
    left outer join ZI_SepInvLedger as led
      on  led.CompanyCode  = reg.CompanyCode
      and led.InvestmentId = reg.InvestmentId
{
  " ─── 이름 : ZC_SepInvRecalc
  " ─── 역할 : 적용 방법별 재계산 장부금액과 원장 장부금액의 차이
  " ─── 이렇게 나눈 이유 : 산식을 한 곳에서만 정의해 화면·서비스·검증이 같은 값을 쓰게 하려고
  key reg.CompanyCode,
  key reg.InvestmentId,
      reg.Category,
      reg.AppliedMethod,
      reg.PolicyMethod,
      reg.Currency,
      @Semantics.amount.currencyCode: 'Currency'
      case reg.AppliedMethod
        when 'C' then reg.AcquisitionCost - reg.AccumulatedImpairment
        when 'E' then reg.AcquisitionCost + reg.ShareOfProfit + reg.ShareOfOci
                      - reg.DividendsReceived - reg.AccumulatedImpairment
        else reg.FairValue
      end                                                   as RecalcBookAmount,
      @Semantics.amount.currencyCode: 'Currency'
      led.LedgerBookAmount                                  as LedgerBookAmount
}

⑥ 처분손익 재계산 (ZC_SepInvDisposal)

처분손익은 처분대가에서 처분 시 장부금액을 뺀 값입니다. 처분 시 장부금액이 어떻게 정해졌는지가 원장 값과의 차이를 만드는 자리라서 처분 전표의 입력값을 그대로 읽어 둡니다. 처분 이력 테이블의 표준 대응은 확인 필요입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '처분손익 재계산'
@Analytics.dataCategory: #FACT
define view entity ZC_SepInvDisposal
  as select from zsepinv_disposal as d
{
  " ─── 이름 : ZC_SepInvDisposal
  " ─── 역할 : 처분대가 − 처분 시 장부금액으로 처분손익을 다시 계산하고 원장 값과 비교
  " ─── 이렇게 나눈 이유 : 처분은 투자 장부와 키가 달라 큐브와 분리
  key d.bukrs                                  as CompanyCode,
  key d.disp_id                                as DisposalId,
      d.inv_id                                 as InvestmentId,
      d.disp_date                              as DisposalDate,
      d.currency                               as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      d.proceeds                               as Proceeds,
      @Semantics.amount.currencyCode: 'Currency'
      d.carry_amount                           as CarryingAmount,
      @Semantics.amount.currencyCode: 'Currency'
      d.proceeds - d.carry_amount              as RecalcGainLoss,
      @Semantics.amount.currencyCode: 'Currency'
      d.ledger_gain_loss                       as LedgerGainLoss,
      @Semantics.amount.currencyCode: 'Currency'
      d.ledger_gain_loss - ( d.proceeds - d.carry_amount ) as GainLossDifference
}

⑦ 점검 쿼리 (ZC_SepInvCheckQuery)

점검 코드 판정을 화면 쪽이 아니라 이 뷰에 둡니다. 판정 순서(M01 → D01 → X01)와 70% 임계값이 여기 한 곳에 모여 있어 회사 기준에 맞출 때 이 뷰만 봅니다. 순자산 지분 참고액은 대장의 값으로 계산합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '투자 측정방법 점검'
@Analytics.query: true
@OData.publish: false
define view entity ZC_SepInvCheckQuery
  as select from ZC_SepInvRecalc as rc
    inner join   ZI_SepInvRegister as reg
      on  reg.CompanyCode  = rc.CompanyCode
      and reg.InvestmentId = rc.InvestmentId
{
  " ─── 이름 : ZC_SepInvCheckQuery
  " ─── 역할 : 점검 코드(M01 · D01 · X01 · I00)와 화면에 쓰는 필터·표시 속성
  " ─── 이렇게 나눈 이유 : 판정 순서와 임계값을 한 곳에 모아 회사 기준 변경을 이 뷰만으로 끝내기 위해
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key rc.CompanyCode,
  key rc.InvestmentId,
      @Consumption.filter.selectionType: #SINGLE
      rc.Category,
      rc.AppliedMethod,
      rc.PolicyMethod,
      @Semantics.amount.currencyCode: 'Currency'
      rc.RecalcBookAmount,
      @Semantics.amount.currencyCode: 'Currency'
      rc.LedgerBookAmount,
      @Semantics.amount.currencyCode: 'Currency'
      rc.LedgerBookAmount - rc.RecalcBookAmount            as DifferenceAmount,
      rc.Currency,
      case
        when reg.MethodMixFlag = 'X'                       then 'M01'
        when rc.LedgerBookAmount <> rc.RecalcBookAmount    then 'D01'
        when rc.AppliedMethod = 'C'
         and ( reg.AcquisitionCost + reg.ShareOfProfit + reg.ShareOfOci - reg.DividendsReceived )
             < rc.RecalcBookAmount * 70 / 100              then 'X01'   -- 70% 는 화면 점검용 임계값(확인 필요)
        else 'I00'
      end                                                  as CheckCode
}

⑧ 접근 제어 (DCL)

권한은 집계 단계에 겁니다. 회사코드 권한이 없으면 해당 회사의 투자는 합계에도 들어오지 않아, 합계에서 빼는 방식으로 남의 숫자가 드러나는 일이 없습니다.

@EndUserText.label: '투자 측정방법 점검 접근 제어'
@MappingRole: true
define role ZC_SepInvCheckQuery {
  " ─── 이름 : ZC_SepInvCheckQuery (DCL)
  " ─── 역할 : 회사코드 단위로 조회 범위를 제한한다
  " ─── 이렇게 나눈 이유 : 화면이 아니라 뷰에서 권한을 걸어 어느 경로로 읽어도 같은 제한이 걸리게 하려고
  grant select on ZC_SepInvCheckQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의 (ZUI_SepInv)

화면이 읽는 뷰만 서비스로 내보냅니다. 서비스 바인딩은 OData V2 로 만들고, 활성화 뒤 앱의 서비스 주소 설정을 이 서비스 주소로 바꿉니다.

@EndUserText.label: '투자 측정방법 점검 서비스'
define service ZUI_SepInv {
  " ─── 이름 : ZUI_SepInv
  " ─── 역할 : 점검 쿼리·재계산·처분 뷰를 OData 서비스로 노출
  expose ZC_SepInvCheckQuery as InvestmentCheck;
  expose ZC_SepInvRecalc     as InvestmentRecalc;
  expose ZC_SepInvDisposal   as Disposal;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

운영 데이터로 갈 때

투자 건수는 보통 수십~수백 건이라 부담이 없고, 부담은 원장 합계에서 옵니다. 원장 합산은 기간·회사코드·계정 범위를 필수 조건으로 걸어 서버 안에서 끝내고, 투자 번호별 합계만 내려보냅니다. 전표가 수천만 건이라도 계정 범위와 기간으로 좁힌 뒤 합산하므로 화면에는 투자 건수만큼의 행이 올라옵니다. 응답 시간 기준은 운영 데이터로 측정해 정해야 하므로 확인 필요입니다.

자주 묻는 질문

도입 검토 자리에서 자주 나오는 질문 26개를 주제별로 정리했습니다.

숫자와 판정

화면과 조작

표준과의 관계·데이터

도입과 운영