IFRS 18 사업결합 손익 범주 귀속 점검 — 염가매수차익부터 인수금융 이자까지, 기록한 범주가 정책표와 맞는지 다시 따져 보는 화면

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

사업결합이 있는 해의 결산에서 손익계산서 담당자가 가장 자주 받는 질문은 금액이 아니라 자리입니다. 염가매수차익은 어느 줄에 놓였나, 조건부대가의 공정가치 변동은 영업 쪽인가 재무 쪽인가, 인수 때 든 수수료는 비용으로 나갔나 영업권에 얹혔나. 금액은 전표에 있으니 합계는 맞는데, 그 금액이 손익계산서의 어느 범주에 앉았느냐는 전표 한 장 한 장을 열어 봐야 알 수 있습니다.

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익을 영업·투자·재무 등의 범주로 나누어 보이도록 요구하고, 그 범주별 소계를 표시하도록 합니다. 이 기준서는 2027-01-01 이후 개시하는 회계연도부터 적용하며 조기 적용이 허용되고, 비교기간도 다시 작성해야 합니다. 사업결합에서 생긴 손익은 IFRS 3 사업결합(K-IFRS 제1103호)에서 인식·측정하는 항목이라, 한 건의 인수가 여러 종류의 손익을 한꺼번에 만들고 그 종류마다 놓일 자리가 다릅니다. 기준을 도입하기 전에 지금 장부가 정책표와 얼마나 어긋나 있는지를 미리 재 보는 일이 이 앱의 자리입니다.

이 앱은 사업결합 손익 건을 가져와 구성요소(염가매수차익·조건부대가 변동·취득 관련 원가·기존 보유 지분 재측정·인수금융 이자)마다 회사의 정책표로 범주를 다시 정하고, 장부에 기록된 범주와 건별로 맞댑니다. 다르면 ‘점검 필요’, 판단 재료가 비어 있으면 ‘확인 필요’로 표시하고, 범주가 옮겨질 때 소계에 미치는 금액을 따로 모아 보여 줍니다. 점검 도구이며 범주 판단과 최종 결정은 회사와 감사인이 합니다.

손익은 맞는데 범주가 틀리면 소계가 흔들린다

총계정원장 잔액과 전표 합계는 맞는데 영업이익 소계가 다르게 나오는 이유는 대개 금액이 아니라 범주 지정에 있습니다. 같은 1,300백만 원이라도 영업범주에 있으면 영업이익에, 투자범주에 있으면 영업이익 아래 소계에 들어갑니다. 합계 대사로는 잡히지 않고, 소계를 만들어 본 다음에야 드러납니다. 이 앱은 소계를 만들기 전에 건별로 범주를 맞대어 이동이 필요한 금액을 먼저 보여 줍니다.

사업결합 손익은 다섯 갈래라 범주 판단이 갈린다

한 건의 인수에서 나오는 손익은 한 종류가 아닙니다. 아래 정책표는 이 사례에서 회사가 정했다고 가정한 것이며, 실제 정책은 회사가 정하고 감사인과 협의합니다. 같은 인수 건 안에서도 구성요소에 따라 기본 범주가 다르고, 기존 보유 지분 재측정은 그 지분의 성격에 따라 범주가 갈립니다.

장부와 정책표를 건별로 맞대는 자리가 비어 있다

손익 계정 라인을 조회하는 표준 화면은 있지만, 그 라인이 어느 인수 건의 어느 구성요소인지, 정책표로 다시 정하면 어느 범주인지는 화면 바깥에서 엑셀로 맞춥니다. 건수가 적을 때는 되지만, 인수 건이 여러 개이고 회사가 둘 이상이면 매번 다시 만들게 됩니다. 이 앱은 구성요소·기록 범주·재계산 범주·이동 필요 금액을 한 행에 놓아, 어긋난 건만 걸러 보는 일을 조회조건 하나로 줄입니다.

재계산한 손익까지 보아야 입력이 맞는지 안다

범주가 맞아도 금액이 틀릴 수 있습니다. 취득 관련 원가 일부가 자산 원가로 기록되면 손익에 들어와야 할 비용이 빠지고, 조건부대가 변동은 기말 공정가치가 갱신되지 않으면 어긋납니다. 이 앱은 취득가배분 결과의 인수일 공정가치와 지급 수수료 같은 입력값으로 손익을 다시 구해 장부 손익과 맞댑니다. 차이가 나면 입력값과 전기 누락 여부부터 확인하도록 안내합니다.

그래서 이 점검으로 무엇을 확인하는가

첫째, 건별로 기록 범주가 정책표와 같은지. 둘째, 다르다면 범주를 옮길 때 소계에 미치는 금액이 얼마인지. 셋째, 재계산 손익이 장부와 같은지. 넷째, 건 합계·딜 합계·범주 합계가 서로 맞는지. 이 네 가지가 한 화면에서 확인되면, 기준서 도입 전에 정책표와 매핑을 어디까지 손봐야 하는지가 숫자로 나옵니다. 아래 표는 이 앱이 해 주는 일과, 그것이 없을 때 생기는 일입니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수)를 넣고, 회사·손익 구성요소·기록 범주·전기일·딜 이름·점검 코드·점검 결과는 필요한 것만 고릅니다. 화면을 열면 2026 으로 자동 조회됩니다.
2. 조회 버튼 또는 Enter — 조회 버튼은 조회조건 줄의 가장 오른쪽에 있고, 입력 칸에서 Enter 를 눌러도 조회됩니다. 초기화 버튼은 그 옆에 있습니다.
3. 요약 확인 — 점검한 손익 건수 · 점검 필요 · 확인 필요 · 범주 이동 필요 금액 · 영업범주 손익 · 정합성 대사 차이 건수가 위쪽에 한 줄로 나옵니다.
4. 탭 이동 — 딜별 점검 → 손익 건별 점검 → 범주별 합계 → 재계산 근거 → 대사 결과 순서로 봅니다.
5. 행 클릭 상세 — 손익 건별 점검의 행을 누르면 같은 딜의 기록 범주와 재계산 범주를 비교하는 상세 창이 열립니다.
6. CSV 내려받기 — 오른쪽 위 버튼으로 지금 탭의 조회 결과를 저장합니다.

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

점검 도구의 값은 “이 숫자 맞아?”에 먼저 답해야 합니다. 만드는 쪽에서 대사식을 세워 전수로 돌렸고, 화면 위쪽 요약의 ‘정합성 대사 차이 건수’가 같은 검사를 열 때마다 다시 합니다.

대사 차이와는 별개로, 점검 기능이 제대로 걸러 내는지 보려고 의도적으로 넣은 예외가 있습니다. 손익 건 6건(B01~B06 각 1건), 재계산 근거 2건(B07), 판단 재료가 빠진 1건(B09)입니다. 요약의 점검 필요 6건·확인 필요 1건이 이 예외와 정확히 일치하고, 범주 이동 필요 금액 합계는 1,815.0백만 원입니다. 이 자료의 회사·딜·금액은 모두 가상입니다.

무엇으로 만들었나

앱 정보는 아래와 같습니다.

실행 화면

실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리이고 숫자를 어떻게 읽는지를 아래에 적었습니다. 모든 숫자는 같은 가상 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건 · 요약 지표 · 탭이 한 화면에 세로로 쌓입니다. 화면을 열면 회계연도 2026 으로 자동 조회되어, 처음 보는 사람도 빈 화면 대신 결과부터 만납니다.

조회조건은 회계연도(필수) · 회사 · 손익 구성요소 · 기록 범주 · 전기일 시작·종료 · 딜 이름 · 점검 코드 · 점검 결과입니다. 요약에는 점검한 손익 27건, 점검 필요 6건, 확인 필요 1건, 범주 이동 필요 금액 1,815.0백만 원, 영업범주로 기록된 손익 1,255.0백만 원, 정합성 대사 차이 0건이 나옵니다. 처음 열리는 딜별 점검 탭에는 인수 건 여섯 개가 한 줄씩 놓이고, 손익 합계 옆에 영업·투자·재무·그 밖의 범주별 장부 금액이 붙습니다. 이 표는 장부 기준이라 정책표로 다시 정한 금액은 오른쪽으로 이어집니다.

손익 건별 점검 — 기록 범주와 재계산 범주를 나란히

이 앱의 중심 탭입니다. 인수 건 안의 손익을 구성요소별로 한 줄씩 펼치고, 장부에 기록된 범주와 정책표로 다시 정한 범주를 나란히 둡니다.

두 범주가 같으면 ‘정상’이고 이동 필요 금액은 0입니다. 다르면 ‘점검 필요’가 붙고, 그 건의 손익 금액이 그대로 이동 필요 금액이 됩니다. 점검 코드 열의 B01~B06 이 어긋난 이유를 알려 주므로, 조회조건의 점검 코드·점검 결과로 어긋난 건만 걸러 볼 수 있습니다. 기존 보유 지분 재측정은 지분 성격이 확정되지 않으면 범주를 정할 수 없어 ‘확인 필요’로 따로 표시됩니다.

여기서는 물류사 지분 추가 취득의 기존 보유 지분 재측정 손익 1,300,000,000원이 영업범주에 기록돼 있는데, 보유 지분이 관계기업·공동기업 지분이었으므로 정책표의 재계산 범주는 투자범주여서 점검 필요가 됩니다. 아래 표에는 같은 딜의 취득 관련 원가 · 조건부대가 변동 · 인수금융 이자가 함께 놓여, 이 딜에서 어긋난 것은 이 한 건뿐임을 바로 알 수 있습니다. 창 아래쪽 모서리를 끌어 크기를 바꿀 수 있습니다.

범주별 합계 · 재계산 근거 · 대사 결과

나머지 세 탭은 건별 점검의 결과가 믿을 만한지를 받쳐 주는 자리입니다. 합계가 서로 맞는지, 손익을 입력값에서 다시 구하면 장부와 같은지, 그리고 이 화면 스스로 낸 숫자의 대사가 맞는지를 차례로 봅니다.

범주마다 장부 금액과 재계산 금액, 그 차이가 나옵니다. 재계산은 건을 다른 범주로 옮기기만 하고 금액은 바꾸지 않으므로 회사별로 두 합계는 같아야 합니다. 범주 이동이 소계에 어떤 영향을 주는지는 이 표에서 영업범주 쪽이 얼마 줄고 투자범주 쪽이 얼마 느는지로 읽습니다.

입력값 ①~④의 뜻은 구성요소마다 다릅니다. 취득 관련 원가는 비용 처리 대상 수수료, 조건부대가 변동은 취득일 공정가치와 기말 공정가치, 염가매수차익은 식별가능 순자산 공정가치와 이전대가·비지배지분·기존 지분 공정가치입니다. 오른쪽으로 이어지는 재계산 금액과 장부 금액의 차이가 0이 아니면 점검 필요(B07)로 표시되고, 이 경우 범주가 아니라 입력값과 전기 누락부터 확인합니다.

정합성 대사는 검사 30건에서 차이가 0건이고 최대 차이도 0원입니다. 참고 대사는 범주 이동 필요 금액의 딜별 합계와 건별 합계를 비교하며, 의도적으로 넣은 예외 건을 포함해도 같습니다. 이 탭이 비어 있거나 차이가 0이 아니면 앞 탭의 숫자를 쓰기 전에 원천부터 점검합니다.

화면 뒤에서 일어나는 일

화면은 조회조건을 서비스에 보낼 뿐이고, 범주 판정과 집계는 서비스가 합니다. 판정 규칙은 아래 표가 전부입니다. 코드가 같은 건은 같은 이유로 어긋났다는 뜻이므로, 점검 코드로 걸러 보면 매핑을 한 번 고쳐 한꺼번에 풀리는 묶음이 보입니다.

서비스가 숫자를 만드는 순서는 다음과 같습니다. 이 순서가 곧 대사의 순서이기도 해서, 어느 단계에서 틀어졌는지 위에서부터 짚어 내려갈 수 있습니다.

조회조건

조건 사이는 모두 and 로만 잇습니다. 구현마다 해석이 갈리는 or 를 쓰지 않고, 날짜 범위는 ge · le 두 개로 풉니다.

결과 컬럼

좁은 화면에서 달라지는 것

화면은 sap.m 표준 컨트롤이라 좁은 창에서는 조회조건이 줄을 바꿔 쌓이고, 표는 가로로 밀어 보는 방식으로 열립니다. 건별 비교는 상세 창이 한 화면에 모아 주므로, 좁은 화면에서는 표를 넓게 펴 보는 대신 행을 눌러 상세 창으로 보는 쪽이 읽기 편합니다.

파일 구성

(앱 폴더)/
  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
  odata/       서비스 로직 · 검증용 샘플 데이터
  media/       소개 영상 · 포스터

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 화면의 어느 자리와 맞닿는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐”는 질문이 꼭 나오는데, 없애지 않고 둡니다. 법정 보고와 감사 대응은 표준 거래에 두는 편이 책임 소재가 분명합니다.

기존 화면 대비 남겨 둘 일을 정리하면 이렇습니다. 소계 확정, 법정·공시 보고, 감사 대응은 표준에 그대로 두고, 이 앱은 기준서 도입 준비와 결산 전 점검에 씁니다.

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

이 앱의 숫자는 CDS 뷰 위에서 만들어질 수 있습니다. 아래 CDS 구성처럼 큐브와 분석 쿼리를 세워 두면, Fiori 분석 앱이나 Analysis for Office 에서도 같은 판정 결과를 열어 볼 수 있습니다. 다만 범주 재판정은 구성요소와 지분 성격이라는 회사 정책표를 입력으로 받으므로 표준 분석 쿼리에 그대로 있는 기능이 아닙니다. 이 앱은 그 판정을 한 곳에 모아 두고, 표준 분석 도구는 그 결과를 읽는 쪽으로 이어 붙이는 구성을 권합니다.

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

요구사항 매핑표

기준서의 요구사항과 이 앱의 대응 기능을 맞춰 보았습니다. 기준서 해석과 범주 판단은 회사와 감사인의 몫이며, 이 표는 화면이 어느 요구사항 관점에서 어떤 자료를 보여 주는지를 정리한 것입니다.

CDS 구성

이 사례의 화면은 가상 자료 27건을 서비스가 그 자리에서 판정합니다. 데모라서 되는 일이고, 운영 데이터에서는 판정과 집계를 CDS 로 내립니다. 아래는 그때 만드는 객체를 읽는 순서대로 적은 것입니다. 정책표와 계정 매핑을 가장 먼저 합의해야 하고, 그 위에 건 뷰 · 딜 큐브 · 범주 큐브 · 조회 쿼리 · 권한 · 서비스가 차례로 올라갑니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스와 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170)로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 범주 정책표 — 구성요소와 지분 성격에서 기본 범주를 정한다

리포트의 모든 판정이 이 표에서 갈립니다. 취득 관련 원가는 영업범주, 인수금융 이자는 재무범주, 기존 보유 지분 재측정은 지분 성격에 따라 투자범주 또는 영업범주로 정하는 식입니다. 운영 전환에서 가장 먼저 합의해야 하는 항목이며, 유효기간을 둔 이유는 정책이 바뀌어도 과거 기간의 판정을 그대로 보존하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  zbcm_polmap — 구성요소 · 지분 성격 → 기본 범주 (투명 테이블)
"  코드에 박지 않는 이유 : 범주 정책은 회사가 정하고 감사인과 협의해
"  바뀔 수 있다. 바뀔 때마다 개발자를 부르면 점검이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '사업결합 손익 범주 정책표'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 - 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zbcm_polmap {
  key mandt      : mandt not null;
  key comp_type  : abap.char(1) not null;   " G 염가매수차익 · C 조건부대가 · A 취득 관련 원가
                                            " S 기존 지분 재측정 · F 인수금융 이자
  key held_nat   : abap.char(1) not null;   " A 관계기업·공동기업 지분 · B 그 밖의 지분 · - 해당 없음
  key valid_from : abap.dats not null;      " 유효 시작일
  valid_to       : abap.dats;               " 유효 종료일 - 비우면 계속
  exp_cat        : abap.char(3);            " OPR 영업 · INV 투자 · FIN 재무 · CNF 판단 보류
  note           : abap.char(100);          " 정책 사유(감사인과 협의한 근거 메모)
}

② 계정 매핑 — 손익 계정이 장부에서 어느 범주에 놓이는가

재계산 범주와 맞댈 상대는 장부에 실제로 기록된 범주입니다. 손익 계정마다 어느 범주 계열인지를 이 표가 가지고 있습니다. 계정 체계가 바뀌면 이 표만 고치면 되므로, 뷰는 그대로 둔 채 점검 결과가 따라 바뀝니다. 같은 계정이 사업결합 구성요소 구분도 함께 가지므로 건이 어느 구성요소인지도 여기서 정해집니다.

" ────────────────────────────────────────────────────────────────
"  zbcm_catmap — 손익 계정 → 장부 기록 범주 · 사업결합 구성요소
"  운영에서는 재무제표 구조(FSV)에 지정한 범주를 그대로 옮겨 담는다.
"  [확인 필요] 범주 지정이 계정 속성인지 구조 노드인지는 환경마다 다르다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '손익 계정 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbcm_catmap {
  key mandt     : mandt not null;
  key ktopl     : ktopl not null;           " 계정과목표
  key saknr     : saknr not null;           " 손익 계정
  key valid_from: abap.dats not null;
  valid_to      : abap.dats;
  book_cat      : abap.char(3);             " OPR · INV · FIN · AST(자산 원가) · NON(미지정)
  comp_type     : abap.char(1);             " 사업결합 구성요소(G · C · A · S · F)
}

③ 건 뷰 — 기록 범주와 재계산 범주를 한 행에 놓는다

이 뷰가 점검의 본체입니다. ACDOCA 의 손익 건에 기록 범주를 붙이고, 정책표를 association 으로 걸어 재계산 범주를 구한 뒤, 두 범주가 다른 건의 금액만 이동 필요 금액으로 남깁니다. 판정을 이 뷰에서 한 번만 정의하고, 딜 큐브·범주 큐브·쿼리가 모두 이 뷰를 읽게 해야 화면마다 숫자가 갈라지지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_BcmLine — 사업결합 손익 건 (기본 뷰)
"  결정하는 것 : 건마다 ① 기록 범주 ② 재계산 범주 ③ 이동 필요 금액 ④ 점검 코드
"  이렇게 나눈 이유 : 판정 조건을 이 뷰 한 곳에 두면 딜·범주 집계와
"  화면·배치가 같은 결과를 쓴다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '사업결합 손익 건'
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_BcmLine
  as select from acdoca as j
    inner join   zbcm_catmap as m on  m.saknr = j.racct          // [확인 필요] 계정과목표(ktopl)도 함께 건다
    left outer join zbcm_polmap as p on p.comp_type = m.comp_type
                                     and p.held_nat  = j.zz_held_nat    // [확인 필요] 지분 성격을 담는 필드
                                     and p.valid_from <= j.budat
                                     and ( p.valid_to is null or p.valid_to >= j.budat )
{
  key j.rldnr                      as Ledger,
  key j.rbukrs                     as Bukrs,
  key j.gjahr                      as Gjahr,
  key j.belnr                      as DocNo,
  key j.docln                      as DocLine,
      j.racct                      as GlAcct,
      j.budat                      as PostDate,
      j.zz_deal_no                 as DealNo,        // [확인 필요] 인수 건 식별 키(오더·프로젝트·참조)
      m.comp_type                  as CompType,
      m.book_cat                   as BookedCat,
      p.exp_cat                    as ExpectCat,
      @Semantics.amount.currencyCode: 'Currency'
      j.hsl                        as Amount,
      @Semantics.currencyCode: true
      j.rhcur                      as Currency,

      /* 이동 필요 금액 : 기록 범주와 재계산 범주가 다른 건의 손익 금액 */
      @Semantics.amount.currencyCode: 'Currency'
      case when p.exp_cat <> 'CNF' and m.book_cat <> p.exp_cat
           then j.hsl else cast( 0 as abap.curr( 23, 2 ) ) end  as MoveAmt,

      /* 점검 코드 : 구성요소와 상태로 정한다 */
      case
        when p.exp_cat = 'CNF'                                   then 'B09'
        when m.book_cat = p.exp_cat                              then 'B00'
        when m.book_cat = 'NON'                                  then 'B05'
        when m.comp_type = 'G'                                   then 'B01'
        when m.comp_type = 'C'                                   then 'B02'
        when m.comp_type = 'A'                                   then 'B03'
        when m.comp_type = 'S'                                   then 'B04'
        else                                                          'B06'
      end                                                       as CheckCode
}
where j.rldnr = '0L'

④ 딜 큐브 — 인수 건별 손익과 범주별 장부 금액

딜별 점검 탭이 이 큐브를 읽습니다. 장부 범주별 합계와 재계산 범주별 합계를 같은 키로 모으고, 대사식 R01·R02 가 이 뷰의 합계로 계산됩니다. 집계를 읽는 자리에 권한을 걸어야 하므로 DCL 은 이 뷰와 건 뷰 양쪽에 붙입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_BcmDeal — 인수 건별 큐브
"  결정하는 것 : 딜 단위 손익 합계 · 범주별 장부/재계산 금액 · 이동 필요 금액
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '사업결합 딜별 점검 큐브'
define view entity ZI_BcmDeal
  as select from ZI_BcmLine as l
{
  key l.Bukrs,
  key l.Gjahr,
  key l.DealNo,
      l.Currency,

      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.Amount                                                  as TotAmt,

      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case when l.BookedCat = 'OPR' then l.Amount else 0 end    as OprBook,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case when l.BookedCat = 'INV' then l.Amount else 0 end    as InvBook,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case when l.BookedCat = 'FIN' then l.Amount else 0 end    as FinBook,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case when l.ExpectCat = 'OPR' then l.Amount else 0 end   as OprExp,

      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.MoveAmt                                                 as MoveAmt,
      @Aggregation.default: #SUM
      case when l.CheckCode between 'B01' and 'B06' then 1 else 0 end  as FlagCnt
}

⑤ 범주 큐브 — 회사·범주별 장부 금액과 재계산 금액

재계산은 건을 다른 범주로 옮기기만 하므로 회사별로 장부 합계와 재계산 합계는 같아야 합니다. 이 큐브가 그 등식의 양쪽을 한 뷰에서 내놓습니다. 두 합계가 어긋나면 금액이 아니라 판정 로직이 틀린 것이라 원인을 가르는 데 쓰입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_BcmCat — 회사 · 범주별 큐브
"  결정하는 것 : 범주별 장부 금액(BookAmt) · 재계산 금액(ExpAmt) · 차이(DiffAmt)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '사업결합 범주별 합계 큐브'
define view entity ZI_BcmCat
  as select from ZI_BcmLine as l
{
  key l.Bukrs,
  key l.Gjahr,
  key l.BookedCat                                         as Cat,
      l.Currency,

      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      l.Amount                                            as BookAmt,

      /* 같은 범주에 재계산으로 들어오는 금액은 쿼리에서 ExpectCat 으로 다시 모은다 */
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case when l.ExpectCat = l.BookedCat then l.Amount
           else cast( 0 as abap.curr( 23, 2 ) ) end      as StayAmt,

      @Aggregation.default: #SUM
      case when l.MoveAmt <> 0 then 1 else 0 end          as FlagCnt
}

⑥ 조회 쿼리 — 조회조건과 결과 컬럼

화면의 조회조건이 이 쿼리의 필터가 됩니다. 필수 조건(회계연도)은 @Consumption.filter.mandatory 로 강제해, 조건 없이 전체 건을 읽는 일이 생기지 않게 합니다. 같은 쿼리를 표준 분석 도구가 열어도 같은 조건과 같은 컬럼이 나옵니다.

" ────────────────────────────────────────────────────────────────
"  ZC_BcmLineCheck — 손익 건별 점검 조회 쿼리
"  결정하는 것 : 조회조건(필수/선택) · 결과 컬럼 · 기본 정렬
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '사업결합 손익 건별 점검'
@Metadata.allowExtensions: true
@Search.searchable: true
define view entity ZC_BcmLineCheck
  as projection on ZI_BcmLine
{
      @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key Gjahr,
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false }
  key Bukrs,
  key DocNo,
  key DocLine,
      @Consumption.filter.selectionType: #RANGE
      PostDate,
      DealNo,
      @Consumption.filter.selectionType: #SINGLE
      CompType,
      @Consumption.filter.selectionType: #SINGLE
      BookedCat,
      ExpectCat,
      Amount,
      MoveAmt,
      @Consumption.filter.selectionType: #SINGLE
      CheckCode,
      Currency
}

⑦ 권한 — 회사코드 단위 DCL

집계를 읽는 뷰에 권한을 걸지 않으면 합계에서 남의 회사 숫자가 새어 나옵니다. 아래 DCL 은 회사코드 표준 권한 객체를 그대로 따르게 해, 별도의 권한 설계 없이 기존 역할을 씁니다. 딜 큐브와 범주 큐브도 같은 방식으로 건 뷰의 권한을 상속합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_BcmLine — DCL (Access Control)
"  결정하는 것 : 어느 회사코드의 손익 건을 누가 읽는가
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '사업결합 손익 건 권한'
@MappingRole: true
define role ZI_BcmLine {
  grant select on ZI_BcmLine
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 — 화면이 바라보는 문

화면은 CDS 가 아니라 서비스를 부릅니다. Service Definition 으로 내보낼 뷰를 고르고 Service Binding 으로 OData V2 를 게시합니다. 게시한 뒤 화면 쪽에서는 manifest.json 의 서비스 주소만 바꾸면 되도록 서비스 이름을 고정해 둡니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_BcmCheck — Service Definition
"  Service Binding(OData V2 - UI) 은 ADT 에서 만들어 게시한다.
"  게시 확인 : /IWFND/MAINT_SERVICE 에서 서비스 활성화 상태를 본다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '사업결합 손익 범주 점검 서비스'
define service ZUI_BcmCheck {
  expose ZI_BcmDeal       as DealCheck;
  expose ZC_BcmLineCheck  as LineCheck;
  expose ZI_BcmCat        as CatTotal;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 일곱 가지는 코딩이 아니라 합의이고, 합의가 끝나면 기술 작업은 위 객체를 만들고 화면을 올리는 일로 줄어듭니다.

운영 데이터로 갈 때

사업결합 손익은 건수가 많지 않아 건 뷰 자체는 가볍습니다. 문제는 ACDOCA 전체에서 손익 계정 건을 골라 내는 비용입니다. 전표가 수천만 건이면 회계연도와 회사코드를 필수 파라미터로 받아 인덱스를 타게 하고, 구성요소 계정 계열을 먼저 걸러 읽는 순서로 뷰를 짜야 합니다. 응답 시간 기준은 조회 한 번에 수 초 안쪽으로 잡고, 그보다 느려지면 건 뷰를 구체화한 테이블(일 배치)로 내리는 선택지가 있습니다. 이 경우 화면은 같은 서비스를 보므로 바뀌는 것이 없습니다.

자주 묻는 질문

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

숫자와 판정

화면과 조작

데이터와 원천

도입과 운영