SAP 사업결합 취득 보험계약 최초 측정 점검 — IFRS 17, 취득일 공정가치와 이행현금흐름의 차이를 CSM·손실요소로 나눠 영업권까지 장부와 맞춰본다

개발 배경

보험회사나 보험계약 포트폴리오를 사업결합으로 인수하면, 인수한 쪽 장부에는 그날 새 보험계약부채가 생깁니다. 이 부채는 피취득자가 들고 있던 장부 금액을 그대로 옮기는 것이 아니라 취득일에 처음부터 다시 측정합니다. IFRS 17 보험계약(K-IFRS 제1117호)은 취득일의 공정가치를 보험료를 받은 것과 같은 자리에 놓고 계약을 집단으로 묶어 측정하게 하고, 사업결합의 영업권은 IFRS 3 사업결합(K-IFRS 제1103호)이 정합니다. 두 기준서가 만나는 자리라서 질문이 꼬리를 뭅니다 — 이행현금흐름은 얼마인가, 공정가치와의 차이는 CSM 이 되는가 손실요소가 되는가, 손실요소는 영업권에 제대로 들어갔는가.

이 질문에 답하는 일은 보통 인수 직후 마감 때 한꺼번에 몰립니다. 계리 쪽에서 받은 평가 결과 파일, 사업결합 정산 자료, 총계정원장 잔액을 한 통의 엑셀에 모아 놓고, 집단마다 현재가치와 위험조정을 더하고 빼며 CSM 을 만듭니다. 손실이 나는 집단은 따로 모아 영업권 계산에 넣습니다. 한 번 맞추면 끝나는 일처럼 보이지만, 인수 건이 두세 건만 돼도 같은 표를 건마다 복제하게 되고, 어느 칸의 숫자가 어느 집단의 것인지 만든 사람만 알게 됩니다.

이 앱은 그 표를 화면으로 옮겨 놓고 장부와 나란히 세운 것입니다. 취득일 평가 결과를 받아 이행현금흐름·CSM·손실요소를 다시 계산하고, 장부 값과 어디서 얼마나 다른지를 취득건 → 집단 → 계약 묶음 순서로 내려가며 보여 줍니다. 분류·집계·대사를 돕는 점검 도구이며, 처리의 최종 판단은 회사와 감사인이 합니다. 시행일·경과규정과 세부 요구사항은 기준서 원문으로 확인할 사항이라 화면은 그 판단을 대신하지 않습니다.

표준 화면은 계정 잔액까지만 보여 준다

총계정원장 쪽 표준 화면은 계정과 기간으로 금액을 보여 줍니다. 보험계약부채 계정의 취득일 잔액이 얼마인지는 바로 나옵니다. 하지만 그 잔액이 어느 취득건의 어느 집단에서 왔는지, 그 집단의 이행현금흐름이 공정가치에서 얼마나 떨어져 있었는지는 계정 화면에 없습니다. 계정 잔액은 결과이고, 점검에 필요한 것은 그 결과를 만든 재료이기 때문입니다.

그래서 이 앱은 재료부터 세웁니다. 집단마다 공정가치, 미래 현금 유입·유출의 현재가치, 위험조정을 한 줄에 놓고 거기서 이행현금흐름을 직접 구합니다. 계정 잔액에서 거꾸로 맞추는 것이 아니라 재료에서 앞으로 계산한 값을 장부 옆에 놓는 것입니다. 두 값이 다르면 그 자리가 곧 점검할 자리입니다.

공정가치와 이행현금흐름의 차이가 CSM 인지 손실인지가 갈린다

이 앱의 계산은 세 줄로 요약됩니다. 이행현금흐름은 미래 유출 현재가치 − 미래 유입 현재가치 + 위험조정입니다. 공정가치에서 이행현금흐름을 뺀 값이 0 이상이면 그 차이가 CSM 이 되고 손실요소는 0 입니다. 0 보다 작으면 CSM 은 0 이고 그 모자란 만큼이 손실요소입니다. 같은 집단이 한쪽에 서는지 다른 쪽에 서는지가 이 한 번의 부호로 정해집니다.

이 분기가 중요한 이유는 갈래마다 갈 곳이 다르기 때문입니다. CSM 은 부채의 일부로 남아 앞으로 서비스 제공에 맞춰 풀립니다. 손실요소는 당기손익으로 바로 인식하지 않고 영업권(또는 염가매수차익) 쪽에 반영한다는 것이 이 처리의 핵심이며, 정확한 문구와 예외는 기준서 원문으로 확인할 사항입니다. 화면은 이 갈래를 집단마다 열 개 남짓한 컬럼으로 풀어 보여 줍니다.

두 번 틀리는 자리가 정해져 있다

이 일에서 틀리는 자리는 크게 두 곳입니다. 하나는 장부의 이행현금흐름에 위험조정이 빠지는 것입니다. 현재가치만으로 부채를 잡으면 위험조정만큼 이행현금흐름이 작아지고, 그 차이가 그대로 CSM 으로 넘어가 CSM 이 부풀려 보입니다. 다른 하나는 손실요소를 영업권에 반영하지 않는 것입니다. 손실부담 집단의 부족분이 어디에도 안 잡히면 영업권이 그만큼 작게 남습니다.

이 앱의 샘플 데이터에는 두 유형을 일부러 심어 두었습니다. 위험조정이 빠진 집단 2건과 손실요소가 영업권에 반영되지 않은 집단 1건입니다. 화면은 이 세 건을 “점검 필요”로 올리고, 점검 내용 컬럼에 사유와 금액을 적습니다. 원인을 단정하지는 않습니다 — 차이가 확인된 자리에 표를 달아 둘 뿐입니다.

취득건에서 계약 묶음까지 내려가는 길이 있어야 한다

숫자 하나가 이상하다고 할 때 가장 먼저 필요한 것은 “이 숫자가 무엇의 합인가”입니다. 영업권은 취득건의 숫자이고, 취득건은 집단들의 합이며, 집단은 보장개시 연도별 계약 묶음들의 합입니다. 이 앱은 그 합산 사슬을 화면으로 그대로 둡니다. 영업권이 어긋나면 집단 탭으로, 집단이 어긋나면 계약 묶음 탭으로 내려가고, 어느 층에서 합이 깨졌는지를 대사 탭이 따로 보여 줍니다.

사용 방법

1. 회계연도를 확인하고(필수, 4자리), 필요하면 기간(취득월) · 취득건 · 포트폴리오 · 수익성 구분 · 취득일 범위 · 점검 결과로 범위를 좁힙니다. 비워 두거나 “전체”로 두면 그 조건은 걸리지 않습니다.
2. 조회 버튼을 누르거나 회계연도 칸에서 Enter 를 누릅니다. 처음 열면 2026년 전체 기간으로 한 번 자동 조회됩니다.
3. 맨 위 요약 지표를 먼저 읽습니다 — 집단 수 · 취득 보험계약 공정가치 합계 · CSM 합계 · 영업권에 반영할 손실요소 합계 · 점검 필요 건수 · 대사 차이 건수.
4. 탭을 위에서 아래로 따라갑니다. 취득건별 영업권 대사 → 집단별 CSM·손실요소 → 계약 묶음 명세 → 정합성 대사.
5. 집단 또는 계약 묶음 행을 누르면 집단 상세 창이 열려 측정 값 · 장부와 재계산의 차이 · 점검 내용 · 소속 계약 묶음 명세를 한 번에 보여 줍니다.
6. 현재 탭의 결과는 CSV 내려받기로 화면 컬럼 이름과 표시 형식 그대로 받습니다.

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

대사 화면에서 가장 비싼 질문은 “이 대사식은 믿어도 되는가”입니다. 그래서 대사식을 먼저 세우고, 샘플 데이터 세 기간 전체를 전수로 돌렸습니다. 아래는 8종 대사식의 결과입니다. 숫자는 모두 검증용 가상 데이터이며 금액 단위는 백만원입니다.

검사 건수를 모두 더하면 93건입니다. 내부 산식(구성 · 분배 · 묶음 합계 · 집단 합계)은 차이가 0건이어야 하고 실제로 0건입니다. 장부와 재계산을 맞춰 보는 네 대사에서 나온 차이 6건은 모두 일부러 넣은 점검 대상입니다. 같은 위험조정 누락이 이행현금흐름과 CSM 에 한 쌍으로 걸리고, 같은 손실요소 미반영이 영업권 반영액과 영업권 대사에 한 쌍으로 걸린다는 점이 이 표의 읽는 법입니다. 화면 위쪽 요약 값(집단 13 · 공정가치 합계 309,344.0 · CSM 합계 17,654.5 · 손실요소 합계 2,062.6 · 집단 점검 필요 3 · 취득건 점검 필요 2 · 대사 차이 6)은 별도 검증 스크립트가 원천 데이터에서 다시 계산한 값과 같습니다.

화면 쪽도 따로 돌렸습니다. 점검 결과를 “점검 필요”로 좁히면 집단 3건만 남는지, 취득일 범위 조건이 서버에서 실제로 걸러 내는지(2026-08-01 이후 9건 · 이전 4건 · 2026-10-01 이후 0건), 상세 창의 합이 표와 같은지를 확인했습니다.

무엇으로 만들었나

화면은 OpenUI5 한 벌입니다. 조회조건은 표준 입력 컨트롤, 결과는 탭마다 하나씩 놓은 표입니다. 서비스는 OData V2 하나이고, 화면은 그 서비스를 모델로 받아 탭마다 한 컬렉션에 표를 직접 바인딩합니다.

실행 화면

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

처음 열었을 때

조회조건 · 요약 지표 · 탭이 한 화면에 세로로 쌓입니다. 처음 열면 2026년 전체 기간으로 한 번 조회가 끝나 있습니다.

요약 지표를 먼저 읽습니다. 집단 13, 취득 보험계약 공정가치 합계 309,344.0, CSM 합계 17,654.5, 영업권에 반영할 손실요소 합계 2,062.6이 점검의 기준선입니다. 그 옆의 집단 점검 필요 3, 취득건 점검 필요 2, 대사 차이 6은 의도적으로 넣은 점검 대상에서 나온 값입니다. 탭 이름 위의 작은 숫자는 그 탭의 행 수(3 · 13 · 61 · 24)이고, 기간은 “전체”가 기본입니다.

점검 필요만 좁혀 보기

숫자가 모두 맞는 집단을 일일이 넘기지 않고, 차이가 확인된 곳만 봅니다.

남은 3건은 위험조정이 빠진 것으로 보이는 집단 2건과 손실요소가 영업권에 반영되지 않은 집단 1건입니다. 탭 이름 위의 건수도 함께 바뀝니다(취득건 2 · 집단 3 · 계약 묶음 13). 요약 지표는 집단 수 3, 공정가치 합계 83,679.7, CSM 합계 5,830.1 로 좁힌 범위를 따라가고, 손실요소 합계 2,062.6 과 점검 필요 3 · 2 · 6 은 이 화면에서 전체 값 그대로 남아 있습니다. 점검 내용에는 “장부 이행현금흐름에 위험조정 …이 빠진 것으로 보임” 같은 문장과 금액이 들어갑니다. “빠진 것으로 보임”이라고만 쓰는 것은 화면이 원인을 단정하지 않기 때문입니다 — 차이가 확인된 곳을 짚고, 왜 생겼는지는 사람이 확인합니다.

집단별 CSM·손실요소

점검의 중심 화면입니다. 집단 한 줄에 재료에서 결과까지가 한 번에 놓입니다.

표는 컬럼이 많아 옆으로 밀어 읽고, 컬럼 순서는 계산 순서와 같습니다. 재료(공정가치 · 유입 · 유출 · 위험조정) → 재계산 이행현금흐름 → 공정가치와의 차이 → CSM 또는 손실요소 → 장부 값과 그 차이입니다. 차이 컬럼은 부호를 붙여 보여 주므로 장부가 큰지 작은지를 숫자만 보고 압니다. 집단 코드는 취득건 · 포트폴리오 · 수익성 구분(N 손실 가능성 크지 않음 · M 그 밖 · O 최초 손실부담)을 이어 붙인 값입니다. 행을 누르면 상세 창이 열립니다.

계약 묶음 명세

집단을 보장개시 연도별로 쪼갠 가장 아래 층입니다.

묶음 값을 더하면 집단 값이 되도록 대사합니다. 집단이 점검 필요면 그 집단의 묶음도 함께 점검 필요로 표시되는데, 이는 묶음 자체가 틀렸다는 뜻이 아니라 소속 집단을 보라는 표시입니다. 점검 내용에도 “소속 집단 점검 필요”라고 적힙니다.

정합성 대사

숫자가 층마다 맞물리는지를 따로 한 장으로 모았습니다.

앞의 검증 결과 표가 이 화면의 합계입니다. 구성 · 분배 · 묶음 합계 · 집단 합계는 차이 건수가 0 이어야 하는 내부 산식이고, 장부 이행현금흐름 · 장부 CSM · 손실요소 반영 · 영업권 대사는 장부와 재계산을 맞춰 보는 대사입니다. 둘이 한 표에 섞이지 않도록 이름으로 구분해 두었습니다.

집단 상세 — 행을 눌렀을 때

집단 하나를 끝까지 읽는 화면입니다. 표에서는 컬럼이 많아 옆으로 밀어야 하는 값을 한 창에 모았습니다.

여기서는 위험조정 누락으로 걸린 집단을 열었습니다. 공정가치 50,195.2 에서 재계산 이행현금흐름 47,012.0 을 뺀 +3,183.2 가 재계산 CSM 입니다. 그런데 장부 이행현금흐름은 45,071.2 로 위험조정 1,940.8 만큼 작고, 그래서 장부 CSM 5,124.0 이 재계산보다 정확히 1,940.8 큽니다. 점검 내용이 그 크기를 그대로 적고, 아래 계약 묶음 5개(보장개시 2018 · 2019 · 2020 · 2022 · 2023)가 모두 점검 필요로 표시됩니다. 창은 오른쪽 아래 닫기 버튼으로 닫습니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 위 화면들이 어떤 규칙으로 그렇게 나오는지를 적었습니다. 도입 검토에서 “그래서 이건 어떻게 계산되느냐”로 자주 되돌아오는 대목들입니다.

판정 규칙 — 무엇이 “점검 필요”가 되는가

판정은 서비스가 하고 화면은 결과만 보여 줍니다. 허용 기준 0.1 백만원은 샘플에 둔 기준 파라미터이며 회사 정책에 따라 조정해야 합니다(확인 필요).

수익성 구분은 취득일 기준으로 “최초 손실부담” · “손실 가능성 크지 않음” · “그 밖” 세 가지로 나눈 샘플 규칙입니다. 실제 구분 기준은 회사의 집단 구분 정책을 따르며 확인 필요입니다.

산출·대사식

손실요소의 영업권 반영 세부와 염가매수차익 처리, 공정가치를 보험료 대용으로 보는 방식은 회사 정책과 기준서 원문으로 확인할 사항입니다(확인 필요). 이 화면은 그 정책이 정해진 뒤의 산식을 다시 계산해 대조합니다.

조회조건

결과 컬럼

각 탭의 머리글과 CSV 머리글은 같습니다. 주요 컬럼의 뜻과 산출식은 아래와 같습니다.

좁은 화면에서 달라지는 것

화면 폭이 줄어도 페이지 전체가 옆으로 밀리지 않습니다. 조회조건은 한 줄에 서지 않고 아래로 줄바꿈되며, 조회·초기화 버튼은 마지막 줄에 따라옵니다. 요약 지표는 가로로 나란히 서지 않고 세로로 쌓이고, 탭과 표는 그 아래에서 시작합니다. 표는 컬럼이 많아 좁은 화면에서 옆으로 밀어 읽으므로, 숫자를 꼼꼼히 비교하는 일은 넓은 화면이 편하고 좁은 화면은 요약과 점검 필요 건수를 확인하는 용도에 맞습니다.

파일 구성

Component.js · manifest.json · index.html   앱 진입과 설정(서비스 선언은 상대 경로)
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/        서비스 폴더 — 메타데이터 정의 · 서비스 로직 · 엔티티셋별 데이터

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 리포트를 없애야 하느냐”는 질문이 꼭 나오는데, 답은 없애지 않고 둡니다입니다. 원장 잔액과 전표를 열어 보는 일, 법정·감사 대응은 표준 거래가 맡는 편이 안전합니다.

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

S/4HANA 에는 CDS 뷰 위에 분석 쿼리를 올려 Fiori 분석 앱이나 Analysis for Office 로 띄우는 길이 이미 있습니다. 이 앱의 아래 CDS 구성은 그 길과 같은 방향입니다. 같은 CDS 뷰를 OData 로 열어 이 화면이 읽을 수도 있고, 같은 뷰 위에 분석 쿼리를 하나 더 얹어 분석 앱으로 띄울 수도 있습니다. 두 길이 서로를 대신하는 것은 아닙니다. 분석 앱은 임의의 축으로 자르는 일에 강하고, 이 화면은 취득건 → 집단 → 계약 묶음 순서와 점검 판정이 고정된 점검 흐름을 한 화면에 담습니다. 어느 쪽을 먼저 열지는 질문이 정해져 있는지에 달려 있습니다.

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

요구사항 매핑

CDS 구성

이 사례의 화면은 샘플 데이터를 서비스가 읽어 재계산합니다. 데모라서 되는 일이고, 운영 데이터에서는 재계산을 CDS 로 내립니다. 운영으로 올릴 때 가장 먼저 하는 일은 평가 결과 적재 테이블을 만들고, 그 위에서 이행현금흐름 · CSM · 손실요소 · 영업권을 계산하는 뷰를 쌓는 것입니다. 아래는 그때 만드는 객체들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 계정 역할 매핑 테이블

장부 쪽 숫자가 어디서 읽히는지가 이 표에서 갈립니다. 어느 원장 계정이 보험계약부채이고 어느 계정이 손실요소 반영액을 받는 영업권 계정인지를 정하는 자리라서 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 계정 체계가 중간에 바뀌어도 과거 취득건의 점검 결과가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZACQI_GRPMAP — 원장 계정 → 역할 매핑 (투명 테이블)
"  운영에서는 회사의 계정 설계를 그대로 옮겨 담는다.
"  코드에 박지 않는 이유 : 계정은 늘 늘어나고, 늘어날 때마다
"  개발자를 부르게 만들면 점검이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '취득 보험계약 계정 역할 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zacqi_grpmap {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key racct      : saknr not null;         " 원장 계정
  key valid_to   : abap.dats not null;
  valid_from     : abap.dats;
  acct_role      : abap.char(4);           " LIAB 보험계약부채 · GWLS 손실요소를 받는 영업권 계정
  sort_no        : abap.int4;
}

② 취득일 평가 결과 적재 테이블

이 앱의 재료는 전부 여기서 옵니다. 계리 평가 결과가 계약 묶음 단위로 들어오고, 나머지 뷰는 이 테이블만 읽습니다. 평가 시스템이 달라도 이 모양으로만 맞추면 위쪽 뷰는 바뀌지 않습니다. 금액 단위와 통화를 컬럼에 같이 두는 이유는 합계를 낼 때 통화가 섞이지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZACQI_VALTN — 취득일 평가 결과 적재 (계약 묶음 단위)
"  공정가치 · 미래 현금흐름 현재가치 · 위험조정은 계리·평가 쪽 결과를
"  그대로 받는다. 이 테이블에서는 계산하지 않는다 — 계산은 뷰에서 한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '취득일 평가 결과'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zacqi_valtn {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key acq_no     : abap.char(4) not null;  " 취득건
  key group_code : abap.char(16) not null; " 취득건-포트폴리오-수익성 구분
  key unit_no    : abap.int4 not null;     " 계약 묶음(보장개시 연도별)
  waers          : waers;
  val_date       : abap.dats;              " 취득일
  cohort_yr      : abap.numc(4);           " 보장개시 연도
  ctr_cnt        : abap.int4;              " 계약 건수
  @Semantics.amount.currencyCode : 'zacqi_valtn.waers'
  fair_value     : abap.curr(18,1);        " 공정가치(보험료 대용)
  @Semantics.amount.currencyCode : 'zacqi_valtn.waers'
  pv_inflow      : abap.curr(18,1);        " 미래 유입 현재가치
  @Semantics.amount.currencyCode : 'zacqi_valtn.waers'
  pv_outflow     : abap.curr(18,1);        " 미래 유출 현재가치
  @Semantics.amount.currencyCode : 'zacqi_valtn.waers'
  risk_adj       : abap.curr(18,1);        " 비금융위험에 대한 위험조정
}

③ 계약 묶음 이행현금흐름 뷰

이행현금흐름의 정의가 여기 한 줄에만 있습니다. 위쪽 어느 뷰도 이 식을 다시 쓰지 않고 이 뷰의 컬럼을 가져다 씁니다. 식이 둘로 갈라지는 순간 “어느 쪽 숫자가 맞는가”가 대사 항목이 되기 때문입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AcqInsUnitValuation — 계약 묶음 + 이행현금흐름 재계산
"  이행현금흐름 = 유출 현재가치 - 유입 현재가치 + 위험조정
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '취득일 계약 묶음 평가'
@ObjectModel.usageType : { serviceQuality : #A, sizeCategory : #L, dataClass : #TRANSACTIONAL }
define view entity ZI_AcqInsUnitValuation
  as select from zacqi_valtn as v
{
  key v.bukrs        as CompanyCode,
  key v.acq_no       as AcquisitionNo,
  key v.group_code   as GroupCode,
  key v.unit_no      as UnitNo,
      v.waers        as Currency,
      v.val_date     as AcquisitionDate,
      v.cohort_yr    as CohortYear,
      v.ctr_cnt      as ContractCount,
      @Semantics.amount.currencyCode : 'Currency'
      v.fair_value   as FairValue,
      @Semantics.amount.currencyCode : 'Currency'
      v.pv_inflow    as PvInflow,
      @Semantics.amount.currencyCode : 'Currency'
      v.pv_outflow   as PvOutflow,
      @Semantics.amount.currencyCode : 'Currency'
      v.risk_adj     as RiskAdjustment,
      @Semantics.amount.currencyCode : 'Currency'
      cast( v.pv_outflow - v.pv_inflow + v.risk_adj as abap.curr( 18, 1 ) ) as FulfilmentCashFlow
}

④ 집단 측정 뷰 — CSM 과 손실요소를 가르는 자리

부호 분기가 이 뷰에서만 일어납니다. 공정가치에서 이행현금흐름을 뺀 값이 0 이상이면 CSM, 아니면 그 크기가 손실요소입니다. 두 컬럼 가운데 하나는 반드시 0 이고, CSM − 손실요소가 공정가치 − 이행현금흐름과 같아야 합니다. 이것이 정합성 대사의 분배 항목입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AcqInsGroupMeasure — 집단 단위 CSM · 손실요소 분리
"  차이 = 공정가치 - 이행현금흐름
"  차이 >= 0 : CSM = 차이, 손실요소 = 0
"  차이 <  0 : CSM = 0,   손실요소 = -차이   (영업권 쪽에 반영할 금액)
"  손실요소의 영업권 반영 세부는 기준서 원문 확인 필요
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '취득 보험계약 집단 최초 측정'
@Analytics.dataCategory : #CUBE
define view entity ZI_AcqInsGroupMeasure
  as select from ZI_AcqInsUnitValuation as u
{
  key u.CompanyCode,
  key u.AcquisitionNo,
  key u.GroupCode,
      u.Currency,
      @Semantics.amount.currencyCode : 'Currency'
      sum( u.FairValue )            as FairValue,
      @Semantics.amount.currencyCode : 'Currency'
      sum( u.FulfilmentCashFlow )   as FulfilmentCashFlow,
      @Semantics.amount.currencyCode : 'Currency'
      cast( case when sum( u.FairValue ) - sum( u.FulfilmentCashFlow ) >= 0
                 then sum( u.FairValue ) - sum( u.FulfilmentCashFlow )
                 else 0 end as abap.curr( 18, 1 ) )             as CsmAmount,
      @Semantics.amount.currencyCode : 'Currency'
      cast( case when sum( u.FairValue ) - sum( u.FulfilmentCashFlow ) < 0
                 then sum( u.FulfilmentCashFlow ) - sum( u.FairValue )
                 else 0 end as abap.curr( 18, 1 ) )             as LossComponent
}
group by u.CompanyCode, u.AcquisitionNo, u.GroupCode, u.Currency

⑤ 장부 잔액 뷰 — 재계산과 갈라 읽는다

장부 값은 일부러 재계산과 다른 뷰에서 읽습니다. 같은 뷰에서 읽으면 차이가 났을 때 어느 쪽이 틀렸는지 갈라 볼 수 없습니다. 아래에서 원장 항목을 집단에 배정하는 필드는 회사 설계에 따라 달라지는 자리라 확인 필요로 적었습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AcqInsBookBalance — 원장의 보험계약·영업권 계정 금액을 집단 배정별로 집계
"  ACDOCA 를 직접 읽는다. 표준 뷰 이름은 릴리스마다 달라 확인 필요.
"  집단 배정 필드(zz_insgrp)는 회사가 원장에 붙이는 확장 필드 예시이다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '취득 보험계약 장부 잔액'
define view entity ZI_AcqInsBookBalance
  as select from acdoca as a
    inner join   zacqi_grpmap as m
      on  m.bukrs = a.rbukrs
      and m.racct = a.racct
{
  key a.rbukrs        as CompanyCode,
  key a.gjahr         as FiscalYear,
  key a.zz_insgrp     as GroupCode,                    " 확장 필드 — 확인 필요
      a.rwcur         as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when m.acct_role = 'LIAB' then a.hsl else 0 end ) as BookInsuranceLiability,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when m.acct_role = 'GWLS' then a.hsl else 0 end ) as BookGoodwillLoss
}
where a.rldnr = '0L'
group by a.rbukrs, a.gjahr, a.zz_insgrp, a.rwcur

⑥ 취득건 뷰 — 영업권을 한 줄에서 한 번 정의한다

영업권 식은 이전대가 − 보험계약 외 식별가능순자산 + Σ 취득일 보험계약부채입니다. 이 식의 세 항이 서로 다른 출처(정산 자료 · 집단 측정 · 장부)에서 오기 때문에 한 뷰에 모아 두는 가치가 큽니다. 장부의 영업권과 차이가 나면 이 뷰의 비교 컬럼이 그 차이를 그대로 올립니다.

" ────────────────────────────────────────────────────────────────
"  ZI_AcqInsAcquisition — 취득건 단위 영업권 재계산과 장부 비교
"  영업권 = 이전대가 - 식별가능순자산(보험계약 제외) + Σ(공정가치 + 손실요소)
"  zacqi_acq 는 사업결합 정산 자료(이전대가·식별가능순자산)를 담는 회사 테이블 예시.
"  이전대가·식별가능순자산은 사업결합 정산 자료(회사 자료)에서 온다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '취득건 영업권 재계산'
define view entity ZI_AcqInsAcquisition
  as select from zacqi_acq     as q
    inner join   ZI_AcqInsGroupMeasure as g
      on  g.CompanyCode   = q.bukrs
      and g.AcquisitionNo = q.acq_no
{
  key q.bukrs   as CompanyCode,
  key q.acq_no  as AcquisitionNo,
      q.waers   as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      q.consideration       as Consideration,
      @Semantics.amount.currencyCode : 'Currency'
      q.net_assets_ex_ins   as NetAssetsExInsurance,
      @Semantics.amount.currencyCode : 'Currency'
      sum( g.FairValue + g.LossComponent ) as InsuranceLiabilityAtAcq,
      @Semantics.amount.currencyCode : 'Currency'
      cast( q.consideration - q.net_assets_ex_ins
            + sum( g.FairValue + g.LossComponent ) as abap.curr( 18, 1 ) ) as GoodwillRecalc
}
group by q.bukrs, q.acq_no, q.waers, q.consideration, q.net_assets_ex_ins

⑦ 점검 쿼리 — 판정을 한 곳에서 낸다

화면이 “점검 필요”를 스스로 판정하지 않게 하려고, 판정은 쿼리 뷰에서 냅니다. 같은 뷰를 분석 앱이나 배치가 읽어도 같은 판정이 나옵니다. 허용 오차는 스케치에서 0.1 로 적었지만 운영에서는 코드에 박지 않고 파라미터나 서비스 설정에서 읽게 해 정책이 바뀌어도 코드를 고치지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_AcqInsMeasureCheck — 집단 점검 화면용 소비 뷰
"  장부(이행현금흐름·CSM·손실요소 반영액)와 재계산의 차이를 계산하고
"  허용 오차를 넘으면 CHECK 로 표시한다. 원인은 단정하지 않는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '취득 보험계약 집단 점검'
@AccessControl.authorizationCheck : #CHECK
@Metadata.allowExtensions : true
define view entity ZC_AcqInsMeasureCheck
  as select from ZI_AcqInsGroupMeasure as g
    left outer join ZI_AcqInsBookBalance as b
      on  b.CompanyCode = g.CompanyCode
      and b.GroupCode   = g.GroupCode
{
      @UI.lineItem   : [{ position : 10 }]
      @Consumption.filter : { selectionType : #SINGLE, multipleSelections : false }
  key g.AcquisitionNo,
      @UI.lineItem   : [{ position : 20 }]
      @Consumption.filter : { selectionType : #MULTIPLE }
  key g.GroupCode,
      g.CsmAmount          as CsmRecalc,
      g.LossComponent      as LossRecalc,
      b.BookGoodwillLoss   as LossBook,
      @UI.lineItem   : [{ position : 90, criticality : 'CheckCrit' }]
      case when abs( coalesce( b.BookGoodwillLoss, 0 ) - g.LossComponent ) >= 0.1
           then 'CHECK' else 'OK' end as CheckStatus,
      case when abs( coalesce( b.BookGoodwillLoss, 0 ) - g.LossComponent ) >= 0.1
           then 1 else 3 end as CheckCrit                " 1 경고 · 3 정상
}

⑧ 접근 제어 — 집계를 읽는 자리에 건다

회사코드 권한을 집단 측정 뷰에 거는 이유는 이 뷰가 합계를 내는 자리이기 때문입니다. 상세 행에만 권한을 걸면 전체 합계에서 보이는 행을 빼는 식으로 안 보이는 행의 크기를 짐작할 수 있습니다. 취득건 단위 제한이 필요하면 같은 방식으로 한 줄을 더합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ACQINSGROUPMEASURE — 집단 측정 뷰 접근 제어
"  회사코드(F_BKPF_BUK 의 BUKRS)로 제한한다. 취득건 단위 제한은
"  회사 정책에 따라 추가(확인 필요).
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '취득 보험계약 접근 제어'
@MappingRole : true
define role ZI_ACQINSGROUPMEASURE {
  grant select on ZI_AcqInsGroupMeasure
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의와 바인딩

마지막으로 쿼리 뷰를 OData V2 로 게시합니다. 게시한 서비스는 서비스 활성화 뒤에 화면 설정의 서비스 주소만 바꾸면 이 화면이 그대로 읽습니다. 화면과 서비스를 이어 주는 것은 상대 경로 하나입니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_AcqInsMeasure — 서비스 정의(노출할 뷰)와 OData V2 바인딩
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '취득 보험계약 최초 측정 점검 서비스'
define service ZUI_AcqInsMeasure {
  expose ZC_AcqInsMeasureCheck as GroupCheck;
  expose ZI_AcqInsAcquisition  as AcquisitionCheck;
  expose ZI_AcqInsUnitValuation as UnitValuation;
}

" 서비스 바인딩(ADT) : 이름 ZUI_ACQINSMEASURE_O2 · 바인딩 유형 OData V2 - UI
" 게시 뒤 /IWFND/MAINT_SERVICE 에서 활성화 상태를 확인한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

이 앱이 다루는 단위는 계약 묶음 수십~수백 행 수준입니다. 운영에서도 평가 결과는 계약 단위가 아니라 집단과 보장개시 연도로 묶은 단위로 받는 것이 보통이라, 전표 수천만 건을 읽는 리포트와는 다른 성격입니다. 무거워지는 곳은 장부 쪽입니다. 원장에서 보험계약 · 영업권 계정을 집단 배정별로 집계하는 뷰는 계정 · 기간 · 회사코드 조건을 반드시 걸어 읽게 하고, 집계는 화면이 아니라 뷰에서 합니다. 회계연도 · 기간 · 취득건 조건은 서비스에서 필수 또는 기본값으로 두어 전체를 한 번에 읽는 호출이 생기지 않게 합니다. 응답 시간 기준은 회사가 정할 일이며, 화면은 표를 서버 쪽 정렬 · 페이징으로 읽으므로 건수가 늘어도 처음 받는 양은 일정합니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

기준서와 표준 연계

도입과 운영