종속·관계기업 지분 처분손익 범주 점검 — IFRS 18 에서 지분을 팔며 남긴 손익이 맞는 범주에 놓였는지 처분 방식으로 다시 구해 장부와 맞춰 보는 화면

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

종속기업이나 관계기업, 공동기업의 지분을 팔고 나면 결산 담당자는 같은 질문을 받습니다. 이 처분손익은 손익계산서의 어느 범주에 놓였나, 그 범주가 처분 방식과 사업 성격에 맞나, 다른 범주에 놓였다면 얼마를 옮겨 봐야 하나. IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익을 영업·투자·재무 등 범주로 나누어 표시하도록 요구하므로, 지분 처분처럼 한 번에 여러 구성요소(처분손익, 기타포괄손익 재순환액, 잔여지분 재측정이익, 거래원가)가 생기는 거래는 구성요소마다 범주를 따로 따져 봐야 합니다. 적용 시기와 범위는 회사가 직접 확인할 사항입니다(확인 필요).

지금은 이 점검이 표준 전표 조회 화면 몇 개와 엑셀 표로 흩어져 있습니다. 처분 건마다 처분 방식(전부 처분, 지배력을 유지한 일부 처분, 지배력을 잃은 일부 처분)을 적고, 주된 사업활동 여부를 판단한 근거를 찾고, 전표에 기록된 범주와 대조하는 일을 사람이 반복합니다. 이 앱은 그 대조를 한 화면에서 하게 해서, 기록한 범주와 다시 구한 범주가 다른 건만 먼저 보이게 합니다.

처분손익은 한 줄이 아니라 구성요소 묶음이다

지분을 팔 때 장부에 남는 것은 처분손익 하나가 아닙니다. 지배력을 잃으면 남은 지분을 공정가치로 다시 재서 생기는 이익이 있고, 그동안 기타포괄손익에 쌓아 둔 금액이 손익으로 옮겨 오는 재순환액이 있으며, 매각에 든 거래원가가 있습니다. 이 구성요소들이 서로 다른 범주에 기록되기 쉽습니다. 이 앱은 처분 건 아래에 구성요소를 줄로 펼쳐 놓고 줄마다 기록 범주와 다시 구한 범주를 나란히 둡니다.

범주는 처분 방식과 사업 성격으로 정해진다

다시 구하는 규칙은 단순합니다. 중단영업으로 분류되는 처분이면 중단영업 범주, 지배력을 유지한 일부 처분이면 일반적으로 자본거래로 봅니다(확인 필요). 그 밖에는 투자 대상의 주된 사업활동 여부로 영업과 투자 중 하나를 정합니다. 주된 사업활동 여부를 판단한 근거가 정리되지 않았다면 화면은 범주를 정하지 않고 확인 필요로 남겨, 회사가 먼저 판단하게 합니다.

범주가 달라도 합계는 어긋나지 않아야 한다

범주를 옮겨 보더라도 전체 금액은 같아야 합니다. 그래서 구성요소 합계, 처분 건별 합계, 기록 범주 합계, 다시 구한 범주 합계를 서로 맞춰 보는 대사 네 가지를 화면 안에 두었고, 처분손익을 순처분대가에서 처분분 장부금액을 빼서 다시 구한 값과 장부 값을 맞춰 보는 대사를 하나 더 두었습니다.

사용 방법

1. 회계연도(필수, 4자리)를 입력하고, 회사 · 투자 유형 · 처분 방식 · 기록 범주 · 처분일 범위 · 투자처 이름 · 점검 코드 · 점검 결과를 필요한 만큼 고릅니다.
2. 조회 버튼은 조회조건 영역 오른쪽 끝에 있고, 입력 칸에서 Enter 키를 눌러도 조회됩니다. 초기화 버튼은 조건을 처음 상태로 되돌립니다.
3. 위쪽 요약 수치 6개로 점검한 구성요소 수, 점검 필요 · 확인 필요 건수, 범주 이동 필요 금액을 확인합니다.
4. 탭을 처분 건별 → 구성요소별 → 범주별 합계 → 처분손익 재계산 → 대사 결과 순서로 넘겨 봅니다.
5. 표의 행을 누르면 같은 처분 건의 구성요소가 상세 창에 모입니다.
6. CSV 내려받기 버튼으로 현재 탭의 조회 결과를 파일로 저장합니다.

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

검증용 샘플 데이터(처분 44건, 구성요소 127줄, 회사 2곳)로 대사식을 전수 돌렸습니다. 처분손익 재계산 대사에는 의도적 예외 3건이 들어 있으며, 정합성 대사의 차이 건수와 분리해 적습니다.

무엇으로 만들었나

실행 화면

처음 열었을 때

화면을 열면 현재 입력된 회계연도로 한 번 자동 조회됩니다. 조건 한 줄과 요약 수치를 먼저 봅니다.

조회조건은 회계연도(필수)와 선택 조건 아홉 개로 이루어지고, 위쪽 요약 수치는 구성요소 수, 점검 필요, 확인 필요, 범주 이동 필요 금액, 투자범주로 기록된 손익, 정합성 대사 차이 건수입니다. 이 샘플에서는 127줄 가운데 15건이 점검 필요, 8건이 확인 필요입니다. 정합성 대사 차이 건수는 0 입니다. 입력 칸에서 Enter 키를 눌러도 조회됩니다.

점검 필요 건만 골라 보기

구성요소 단위로 내려가 기록 범주와 다시 구한 범주가 다른 줄을 찾습니다.

한 줄은 처분손익, 기타포괄손익 재순환액, 잔여지분 재측정이익, 거래원가 중 하나입니다. 기록 범주와 재계산 범주를 나란히 두고 이동 필요 금액을 오른쪽에 보여 줍니다. 점검 코드 열은 A01 부터 A06 까지가 점검 필요, C01 이 확인 필요입니다. 이 화면은 이동을 확정하지 않고 확인 대상을 보여 줄 뿐입니다.

조건을 바꾸면 요약 수치도 같은 조건으로 다시 계산됩니다. 처분일은 시작과 종료를 따로 입력할 수 있고, 한쪽만 넣어도 조회됩니다. 투자처 이름은 일부 문자만 넣어도 찾습니다. 회계연도가 비었거나 시작일이 종료일보다 늦으면 입력 칸 아래에 안내가 뜹니다.

건에서 구성요소로

처분 건 하나를 열어 구성요소를 한 자리에서 비교합니다.

상세 창은 처분 번호, 투자 유형, 처분 방식을 위에 두고 구성요소별 기록 범주와 재계산 범주를 줄로 보여 줍니다. 영업범주로 기록된 처분손익이 재계산에서는 투자범주로 나오는 식의 차이가 보입니다. 다른 범주에 기록한 사유가 있는지는 회사가 확인합니다.

범주와 손익을 다시 맞춰 보기

합계로 범주를 비교하고, 처분손익을 다시 계산하고, 대사로 마무리합니다.

차이가 있는 범주에서는 점검 건수가 함께 보여 바로 해당 구성요소로 내려갈 수 있습니다. 범주별 합계의 총합은 구성요소 금액 합계와 같아야 하며, 이 등식이 대사 결과 탭에 따로 적혀 있습니다.

이 샘플에는 일부러 넣은 차이 3건이 있어 점검 필요로 표시됩니다. 처분분 장부금액은 투자 장부금액에 처분 지분율을 곱해 구합니다. 차이가 나는 건은 금액 차이의 원인을 회사가 확인합니다.

대사 하나마다 검사 건수, 차이 건수, 최대 차이 금액과 산식이 적혀 있습니다. 의도적 예외는 정합성 대사와 분리해 읽어야 합니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터 객체로 만들어 서비스의 처분 건, 구성요소, 범주별 합계, 재계산, 대사 결과 묶음에 각각 요청합니다. 판정과 집계는 서비스가 하고, 화면은 받은 값을 보여 줍니다.

처리 단계와 대사식

1. 처분분 장부금액 = 투자 장부금액 × 처분 지분율
2. 다시 구한 처분손익 = 순처분대가 − 처분분 장부금액
3. 다시 구한 범주 = 처분 방식과 주된 사업활동 여부로 정한 범주
4. 범주 이동 필요 금액 = 기록 범주와 다시 구한 범주가 다른 구성요소의 금액
5. 대사: 구성요소 합계 = 처분 건 합계 = 범주별 합계(기록 · 재계산), 이동 필요 금액 = 점검 필요 구성요소 금액

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

표는 가로로 넘겨 볼 수 있고, 조회조건은 줄바꿈되어 조회 버튼이 입력 칸 아래로 내려옵니다. 상세 창은 화면 폭에 맞춰 줄어듭니다.

파일 구성

├─ index.html · Component.js · manifest.json
├─ controller/ · view/ · model/ · css/ · i18n/
├─ odata/ (서비스 선언 · 서비스 로직 · 데이터)
├─ media/ (소개 영상)
└─ readme.html

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 전표를 만들고 고치는 일, 법정 보고와 공시, 감사 대응은 표준 화면에 그대로 둡니다.

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

요구사항 매핑

T-code 별 연계 지점

운영 전환 시 “기존 화면을 없애야 하나”라는 질문에는 아니라고 답합니다. 표준 화면은 전표와 법정 대응용으로 남고, 이 앱은 결산 전 점검에 쓰입니다.

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

표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office 와 겹치는 일은 하지 않습니다. 이 앱의 서비스는 CDS 뷰 위에 얹히는 조회 서비스이며, 표준 분석 앱이 이미 있다면 같은 CDS 뷰를 그 앱의 데이터원으로도 쓸 수 있습니다(확인 필요).

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

CDS 구성

아래는 이 화면의 데이터를 만드는 CDS 구성의 스케치입니다. 실제 테이블과 필드 이름은 회사 환경에서 확인해야 하므로 확인 필요로 표시했습니다. 이름은 모두 기능을 뜻하는 영문입니다.

뷰 레이어 구성

① 범주 규칙 매핑 테이블

처분 방식과 사업 성격으로 다시 구하는 범주 규칙은 테이블 한 장으로 둡니다. 규칙이 바뀌어도 뷰를 이송하지 않고 데이터만 바꿉니다. 운영에서 가장 먼저 정해야 하는 자리입니다.

" ─── ZDSP_CATRULE ────────────────────────────────────────
" 역할 : 처분 방식(DISP_MODE)과 사업 성격(BIZ_NATURE)을 재계산 범주로 옮기는 규칙
" 이유 : 규칙을 코드에 박지 않아야 회계팀이 판단 변경을 데이터로 반영한다
@EndUserText.label : '지분 처분 범주 규칙'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zdsp_catrule {
  key mandt     : mandt not null;
  key disp_mode : abap.char(1) not null;   " F 전부, P 일부(유지), L 일부(상실)
  key biz_nat   : abap.char(1) not null;   " Y 주된 사업활동, N 아님, U 판단 전
  comp_type     : abap.char(1);             " G 처분손익, M 재측정, R 재순환, C 거래원가
  exp_cat       : abap.char(3);             " INV OPR DSC EQT CNF
}

② 투자처 차원 뷰

투자처 이름과 투자 유형을 한 곳에서 읽습니다. 투자 유형은 종속 · 관계 · 공동기업 구분이며, 이 뷰의 원천은 확인 필요입니다.

" ─── ZI_DispInvestee ─────────────────────────────────────
" 역할 : 투자처 속성(이름, 유형)
" 이유 : 구성요소 · 처분 건 뷰가 같은 투자처 정의를 쓰게 한다
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #MASTER }
define view entity ZI_DispInvestee as select from zdsp_investee   " 확인 필요
{
  key bukrs    as CompanyCode,
  key invee_id as Investee,
      invee_name as InvesteeName,
      invee_type as InvesteeType     " S 종속, A 관계, J 공동
}

③ 구성요소 기본 뷰

이 앱의 중심 뷰입니다. 구성요소 줄마다 기록 범주(원천)와 재계산 범주(규칙 매핑)를 붙이고, 둘이 다르면 이동 필요 금액을 만듭니다. 범주를 정하지 못하면 확인 필요 범주로 둡니다.

" ─── ZI_DispLine ─────────────────────────────────────────
" 역할 : 처분 구성요소 줄 + 기록 범주 vs 재계산 범주
" 이유 : 줄 단위 비교를 한 곳에 두어 건 · 범주 · 대사 집계가 같은 값을 쓴다
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@Semantics.systemDateTime.createdAt: false
define view entity ZI_DispLine
  as select from zdsp_line as l
  left outer join zdsp_catrule as r
    on  r.disp_mode = l.disp_mode
    and r.biz_nat   = l.biz_nat
    and r.comp_type = l.comp_type
  association [0..1] to ZI_DispInvestee as _Investee
    on  _Investee.CompanyCode = l.bukrs and _Investee.Investee = l.invee_id
{
  key l.gjahr   as FiscalYear,
  key l.bukrs   as CompanyCode,
  key l.disp_no as DispNo,
  key l.seq_no  as SeqNo,
      l.comp_type as CompType,
      l.disp_mode as DispMode,
      @Semantics.amount.currencyCode: 'Currency'
      l.amount    as Amount,
      l.currency  as Currency,
      l.booked_cat as BookedCat,
      case when r.exp_cat is null then 'CNF' else r.exp_cat end as ExpectCat,
      case when r.exp_cat is not null and l.booked_cat <> r.exp_cat
           then l.amount else cast( 0 as abap.curr(23,2) ) end   as MoveAmt,
      _Investee
}

④ 범주별 집계 큐브

기록 범주와 재계산 범주를 각각 집계해 범주별 합계를 만듭니다. 두 합계의 총합은 구성요소 합계와 같아야 하며 이 등식이 대사의 기준이 됩니다.

" ─── ZI_DispCatCube ──────────────────────────────────────
" 역할 : 범주별 장부 금액 · 재계산 금액 집계
" 이유 : 합계 대사를 SQL 한 번으로 재현 가능하게 한다
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_DispCatCube as select from ZI_DispLine
{
  key FiscalYear, key CompanyCode,
  key BookedCat  as Category,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( Amount )  as BookAmt,
      @DefaultAggregation: #SUM
      sum( case when ExpectCat = BookedCat then Amount else cast(0 as abap.curr(23,2)) end ) as MatchAmt,
      count( * )     as LineCnt,
      Currency
} group by FiscalYear, CompanyCode, BookedCat, Currency

⑤ 조회 쿼리(소비 뷰)

화면이 보는 필드만 노출하고 조회조건의 필터 대상을 선언합니다.

" ─── ZC_DispCatQuery ─────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
@Search.searchable: true
define view entity ZC_DispCatQuery as projection on ZI_DispLine
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key FiscalYear,
  @Consumption.filter.selectionType: #SINGLE
  key CompanyCode,
  key DispNo, key SeqNo,
  @Consumption.filter.selectionType: #SINGLE
  DispMode,
  @Consumption.filter.selectionType: #SINGLE
  BookedCat,
  ExpectCat, Amount, MoveAmt, Currency
}

⑥ 권한 정의(DCL)

회사코드 기준으로 집계 단계에 권한을 겁니다. 합계에만 걸고 상세에 걸지 않으면 뺄셈으로 남의 숫자가 드러나므로 뷰 전체에 겁니다.

" ─── ZDSP_DispLine_DCL ───────────────────────────────────
@EndUserText.label: '지분 처분 구성요소 권한'
@MappingRole: true
define role ZDSP_DISPLINE_DCL {
  grant select on ZI_DispLine
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

쿼리 뷰를 서비스로 노출합니다. 화면 모델은 이 서비스 주소만 바꾸면 운영 데이터로 전환됩니다. 서비스 활성화는 게이트웨이 서비스 관리에서 확인합니다(확인 필요).

" ─── ZUI_DispCat ─────────────────────────────────────────
@EndUserText.label: '지분 처분손익 범주 점검 서비스'
define service ZUI_DispCat {
  expose ZC_DispCatQuery as LineSet;
  expose ZI_DispCatCube  as CatSet;
}
" 바인딩 : OData V2 - UI (확인 필요: 회사 환경의 게시 방식)

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

처분 거래는 한 해 수십~수백 건이라 집계 성능이 문제가 되는 일은 드뭅니다. 다만 구성요소를 전표 라인 단위로 읽는 경우 줄 수가 크게 늘 수 있으므로 회계연도를 필수 조건으로 두고, 회사코드를 인덱스 첫 조건으로 둡니다. 응답 시간 기준은 회사가 정합니다(확인 필요).

자주 묻는 질문

자주 받는 질문을 주제별로 묶었습니다.

숫자와 산식

화면과 조작

도입과 운영