확정급여제도 개정·축소 과거근무원가 점검 — 변경 전·후 DBO 차이를 원장 인식액과 맞춰 보는 화면
사건 명세 · 변경 전·후 DBO 차이로 다시 계산한 과거근무원가 · 인식 시점 판정 · 점검 코드 · 유형별·제도별 집계 · 직급군별 상세 · 대사 결과 — 소개 영상과 실제 화면 6종, 그리고 CDS 코드까지
소개 영상블로그 목차 순서대로 · 자막 포함8개 장면표지 → 요약 → 필터 → 집계 → 상세 → 대사 → 정리
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
지금 확정급여제도 개정·축소 시 발생하는 과거근무원가 계산과 원장 인식액 대조는 여러 시스템과 엑셀에 흩어진 데이터를 수작업으로 맞춰 보며 높은 비효율과 오류 위험을 안고 있습니다. 이 앱은 복잡한 기준서 산식과 원장 정합성 검증 로직을 내장하여, 사건 단위 재계산과 원장 대사 작업을 한 화면에서 통합 관리함으로써 결산 확인의 정확성과 효율성을 혁신합니다.
핵심 포인트 여섯 가지
| 핵심 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 흩어진 과거근무원가 정보 통합 | 사건별 재계산 과거근무원가, 원장 인식액, 변경 전·후 확정급여채무(DBO)를 한 화면에 통합하여 모든 관련 정보를 즉시 확인합니다. 직급군별 상세 배분까지 제공합니다. | DBO 평가 결과, 원장 개별 항목, 엑셀 대조 자료를 각각 열어 수작업으로 정보를 취합합니다. |
| ② IAS 19 인식 시점 자동 판정 | K-IFRS 제1019호(IAS 19) 기준에 따라 개정·축소일과 구조조정원가 인식일 중 이른 날을 재계산 인식일로 자동 판정합니다. 원장 인식월과의 차이를 점검 코드 A04로 알려줍니다. | 서로 다른 문서에 기록된 두 날짜를 일일이 비교하며 수작업으로 인식 시점을 판정합니다. |
| ③ 원장 처리 구분 자동 식별 | 과거근무원가의 원장 처리 구분을 당기손익, 기타포괄손익(A02), 가득기간 배분(A03)으로 자동 식별하여 사건 행에 함께 표시합니다. 처리 방식 확인을 지원합니다. | 금액만으로는 처리 방식을 알 수 없어 개별 항목과 전표를 직접 열어 확인해야 합니다. |
| ④ 점검 코드 기반 우선순위 제시 | 6가지 점검 코드(A01~A05, I00)를 기준으로 원장 인식액 불일치, 인식 시점 차이, 재측정 미반영 등 점검이 필요한 사건을 우선순위에 따라 식별합니다. | 수많은 사건을 일일이 확인하며 불일치 지점을 수작업으로 찾아내고 점검 순서를 정해야 합니다. |
| ⑤ 9가지 대사식으로 정합성 검증 | 6가지 자체 계산 정합성 대사식과 3가지 원장 정합성 대사식을 통해 앱 내부 계산과 원장 데이터의 일치 여부를 검증합니다. 점검 결과를 신뢰할 수 있도록 돕습니다. | 핵심 계산 로직의 정합성과 원장과의 대사 정확성을 검증하기 위한 별도 수작업이 필요합니다. |
| ⑥ 사건 후 순이자 재측정 점검 | 개정·축소 사건 후 잔여기간 순이자가 갱신된 가정으로 재산정되어 원장에 반영되었는지 재계산액과 비교합니다. 미반영 시 점검 코드 A05를 부여합니다. | 사건 후 순이자 재측정액의 원장 반영 여부와 정확성을 수작업으로 확인해야 합니다. |
사례로 보는 효과
가상 샘플 데이터 28건 검증 결과, 앱 내부 계산의 정합성 대사 6식은 모두 차이 0건이었습니다. 원장과의 장부 점검 대사 3식에서는 의도된 불일치 13건(A01 3건, A02 2건, A03 2건, A04 3건, A05 3건)이 확인되었으며, 원장 인식액과 재계산 과거근무원가 간 최대 264,676,776원의 차이를 발견했습니다. 이 앱은 이러한 차이를 즉시 식별하여 검토의 우선순위를 제시합니다.
도입하면 달라지는 것
- 사건마다 흩어진 숫자를 찾던 시간이 사라집니다.
- 복잡한 점검 순서를 코드가 먼저 제시하여 확인 업무를 줄입니다.
- K-IFRS 제1019호 기준 과거근무원가 재계산의 정확도를 높입니다.
- CSV 내려받기로 검토 자료 작성이 즉시 가능합니다.
이런 회사에 맞습니다
확정급여제도 개정·축소 과거근무원가 산정 및 원장 대사에 어려움을 겪는 재무, 관리회계, 퇴직연금 담당팀에 적합합니다. 여러 개정·축소 사건이 겹치는 결산 시기에 특히 유용합니다.
점검 순서를 코드가 먼저 잡아야 확인이 줄어든다
점검 코드는 사건마다 하나만 붙고, 아래 순서에서 먼저 해당하는 코드를 씁니다. 결과는 “점검 필요”와 “확인 필요”로만 표기하고 원인을 단정하지 않습니다. 샘플 28건 중 점검 필요 13건의 분포는 표와 같습니다.
| 순서 | 점검 코드 | 판정 조건 | 사용자 조치 | 샘플 건수 |
|---|---|---|---|---|
| 1 | A02 | 원장 처리 구분이 기타포괄손익 | 과거근무원가를 당기손익으로 인식했는지 확인 | 2건 |
| 2 | A03 | 원장 처리 구분이 가득기간 배분 | 배분하지 않고 즉시 인식했는지 확인 | 2건 |
| 3 | A01 | 원장 인식액 − 재계산 과거근무원가 ≠ 0 | 변경 전·후 DBO 평가 대상·가정 확인 | 3건 |
| 4 | A04 | 원장 인식월 ≠ 재계산 인식월 | 개정·축소일과 구조조정원가 인식일 비교 | 3건 |
| 5 | A05 | 원장이 사건 후 재측정 미반영이고 반영액 차이 ≠ 0 | 갱신한 가정으로 잔여기간 순이자를 다시 산정했는지 확인 | 3건 |
| 6 | I00 | 위 조건에 모두 해당하지 않음 | 조치 없음 | 15건 |
숫자를 믿을 수 있는가 — 검증 결과
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
실행 화면
실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지를 아래에 적었습니다. 숫자는 모두 같은 가상 샘플 데이터에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.
처음 열었을 때와 좁혀 볼 때
조회조건 한 줄 아래에 요약 숫자, 그 아래에 사건 명세가 세로로 놓입니다. 기준 연월만 필수이고 나머지는 비워 두면 전체입니다.
기준 연월(기본 202412)로 자동 조회되어 열자마자 숫자가 찹니다. 요약은 사건 건수 · 재계산 과거근무원가 합계(−2,709,439,585원) · 원장 인식액 합계(−2,226,195,521원) · 두 값의 차이(+483,244,064원) · 사건 후 재측정 차이 · 점검 필요 건수 · 정합성 대사 차이 건수 순입니다. 마지막 칸이 0이어야 위의 숫자를 믿고 읽을 수 있습니다.
기간 시작·종료를 둘 다 넣으면 하나의 기간 조건으로 전달되고, 점검 결과를 점검 필요로 두면 확인할 사건만 남습니다. 요약 숫자가 같이 줄어들기 때문에 남은 사건의 차이 합계가 곧바로 읽힙니다. 이 상태에서 CSV 내려받기를 누르면 보이는 조건 그대로 검토 자료가 됩니다.
유형별 · 제도별로 묶어 볼 때
사건 명세를 읽다 보면 ‘어디에 몰려 있나’가 궁금해집니다. 같은 숫자를 사건 유형과 제도로 묶은 두 탭이 그 답을 줍니다.
개정은 과거근무원가가 +1,817,607,207원(급여 증가), 축소는 −4,527,046,792원(급여 감소)으로 방향이 다릅니다. 두 유형을 합친 값이 사건 명세 합계와 같은지는 대사 04번이 매번 확인합니다. 점검 필요 건수는 개정 5건, 축소 8건으로 어느 유형에 확인이 몰리는지 한눈에 보입니다.
가상 제도 세 개(본사 사무직 12건 · 생산직 9건 · 해외 자회사 7건)로 묶었습니다. 원장 인식액과 재계산의 차이는 본사 사무직에 +477,439,064원으로 몰려 있고 해외 자회사는 0원입니다. 차이가 제도 한 곳에 몰리면 계산 가정이나 원장 처리 방식이 그 제도에서 달랐는지부터 봅니다.
행에서 상세로, 그리고 대사로
의심 가는 사건은 행을 눌러 직급군별 배분까지 내려가고, 마지막으로 대사 탭에서 숫자 전체가 맞는지 확인합니다.
상단에는 사건의 변경 전·후 DBO, 할인율, 재계산 과거근무원가, 원장 인식액과 처리 구분, 인식일, 점검 코드가 나옵니다. 아래 표는 직급군 세 줄의 변경 전·후 DBO와 변동액이며, 세 줄의 변동액을 더하면 사건 과거근무원가와 같아야 합니다(대사 02번). 점검 필요 사건은 이 창에서 어느 항목이 달랐는지부터 읽습니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
화면 뒤에서 일어나는 일
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
점검 코드 판정 규칙
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
조회조건
| 조건 | 필수 | 기본값 | 서비스로 가는 필터 |
|---|---|---|---|
| 기준 연월 | 필수 | 202412 | Period eq '202412' |
| 사건 유형 | 선택 | 전체 | 선택했을 때만 EventType eq 'A' 또는 'C' |
| 제도 | 선택 | 전체 | 선택했을 때만 PlanCode eq 'P1' 등 |
| 개정·축소일 시작·종료 | 선택 | 비움 | EventDate ge/le 날짜 — 둘 다 넣으면 기간 하나로 전달 |
| 점검 코드 | 선택 | 전체 | 선택했을 때만 CheckCode eq 'A01' 등 |
| 점검 결과 | 선택 | 전체 | 선택했을 때만 CheckStatus eq 'CHECK' |
“전체”는 코드값으로 보내지 않고 해당 조건을 필터에서 뺍니다. 유형별·제도별 집계 탭에는 그 탭에 해당하는 조건만 적용됩니다.
결과 컬럼
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
좁은 화면에서 달라지는 것
이 사례는 데스크톱 폭을 기준으로 검수했으며 좁은 화면 전용 배치는 따로 만들지 않았습니다. 표는 가로로 넘겨 보게 됩니다. 태블릿이나 휴대폰 사용이 필요한 현장이라면 보여 줄 열을 줄이는 작업을 별도로 정해야 합니다(확인 필요).
파일 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
SAP 표준 기능 확장 포인트
이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 조회와 대조는 표준 T-code 가 담당하고, 이 화면은 사건 단위의 재계산·검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.
표준으로 되는 것과 안 되는 것
| 하고 싶은 일 | SAP 표준 | 표준에서 걸리는 자리 | 이 앱이 하는 일 |
|---|---|---|---|
| 퇴직급여 계정 라인 조회 | FAGLL03 | 라인은 조회되지만 사건별 재계산액과의 대조는 따로 해야 합니다 | 원장 인식액·인식일·처리 구분을 사건 행에 붙입니다 |
| 계정 기간 잔액 조회 | FS10N | 기간 잔액은 보이나 사건 단위로 나눠 볼 수 없습니다 | 집계 합계를 잔액과 맞춰 보는 근거가 됩니다 |
| 전표 확인 | FB03 | 전표 단위 조회라 사건의 점검 사유를 알려 주지 않습니다 | 점검 필요 사건의 전표를 열어 처리 구분을 확인하게 안내합니다 |
| 변경 전·후 DBO 산정 | 확인 필요 | 보험수리 평가 결과는 표준 원천 테이블이 없습니다 | 평가 결과를 입력값으로 받아 차이를 계산합니다 |
| 인식 시점 비교 | 확인 필요 | 사건 단위 인식 시점 판정은 표준에서 확인하지 못했습니다 | 이른 날 기준의 재계산 인식일과 원장 인식월을 비교합니다 |
| 점검 사유 분류 | 확인 필요 | 표준 화면에서는 사람이 판단합니다 | 점검 코드 A01~A05 로 확인할 이유를 먼저 가립니다 |
T-code 별 연계 지점
이 앱이 표준 거래의 어느 자리를 이어받는지 적었습니다. 운영에 올릴 때 “기존 확인 절차를 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다. 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.
| T-code | 이름 | 연계 |
|---|---|---|
FAGLL03 | 총계정원장 개별항목 조회 | 이 앱의 원장 인식액과 인식일이 오는 자리입니다. 같은 유니버설 저널을 같은 조건(회사코드·계정·기간)으로 읽으므로 사건별 원장 인식액이 이 화면의 합계와 같아야 합니다. 이 앱 결과 → FAGLL03: 점검 필요 사건의 계정·기간으로 라인을 열어 금액과 전기일을 확인합니다. 운영 검수의 첫 번째 대사로 둡니다. |
FS10N | 총계정원장 잔액 조회 | 과거근무원가 계정과 확정급여채무 계정의 기간 잔액을 이 앱의 집계 합계와 맞춰 봅니다. 사건 단위로 나눠 보는 것은 이 앱이, 계정 잔액의 최종 확인은 FS10N 이 맡습니다. |
FB03 | 전표 조회 | 점검 필요 사건(특히 A02·A03)의 전표를 열어 손익·기타포괄손익 처리와 배분 여부를 확인하는 자리입니다. 사내 포털에서 열 수 있으면 링크로 이어 두고, 아니면 전표 번호를 복사해 쓰도록 둡니다. |
| 표준에 남겨 둘 일 | 결산·공시·감사 대응 | 법정 공시와 감사 대응 숫자는 표준 거래와 회사의 결산 절차에 둡니다. 이 앱은 그 숫자를 만들기 전·후에 사건 단위로 점검하는 관점만 더합니다. 기존 확인 절차는 없애지 않습니다. |
S/4HANA 분석 스택과의 자리
S/4HANA 에서는 CDS 뷰로 만든 쿼리를 표준 Fiori 앱이 띄워 줍니다. 이 앱을 올리기 전에 표준 스택으로 먼저 되는지 확인하는 편이 좋습니다. 되는 일은 그쪽이 유지보수가 가볍습니다.
| 표준 자리 | 무엇을 하나 | 이 앱과의 관계 |
|---|---|---|
View Browser (F2170) | CDS 뷰의 구조와 의존 관계 탐색 | 원장 집계 뷰를 어떤 표준 뷰 위에 얹을지, 필드 이름을 확인할 때 씁니다. |
| Query Browser | 분석 쿼리로 선언된 뷰를 찾아 실행 | 아래 CDS 구성의 소비 뷰를 만들어 두면 이 앱 없이도 조회할 수 있습니다. 직급군 상세·점검 코드 표시가 필요 없다면 거기서 끝내도 됩니다(확인 필요). |
| Fiori 목록 보고서 | CDS 소비 뷰를 목록으로 띄우는 표준 앱 방식 | 같은 소비 뷰를 읽으면 필터 정의가 이 앱과 같아집니다. |
| Analysis for Microsoft Office | 같은 뷰를 엑셀에서 조회 | 엑셀로 내려 다시 가공하는 업무가 많다면 함께 열어 두는 편이 낫습니다. |
요구사항 매핑
| 기준서 | 요구사항 | 대응 기능 | 원천 데이터 | 비고 |
|---|---|---|---|---|
| IAS 19 종업원급여(K-IFRS 제1019호) | 과거근무원가 = 제도 개정·축소로 인한 확정급여채무의 변동 | 변경 전·후 DBO 차이 재계산, 직급군별 배분 | 보험수리 평가 결과(확인 필요 — 표준 원천 없음) | 양수·음수 모두 산정 |
| IAS 19 종업원급여(K-IFRS 제1019호) | 과거근무원가는 당기손익으로 인식 | 원장 처리 구분 점검(A02·A03) | 원장 라인 아이템 | “점검 필요”로만 표기 |
| IAS 19 종업원급여(K-IFRS 제1019호) | 인식 시점은 개정·축소 시점과 관련 구조조정원가 인식 시점 중 이른 때 | 재계산 인식일, 인식 시점 차이(A04) | 개정·축소일, 구조조정원가 인식일 | - |
| IAS 19 종업원급여(K-IFRS 제1019호) | 사건 후 잔여기간의 당기근무원가와 순이자는 갱신한 가정으로 산정 | 사건 후 재측정 대사(A05) | 변경 전·후 할인율, 원장 반영액 | 순이자 재측정액으로 단순화 |
위 요구사항의 문언과 적용 시기, 경과규정은 이 글에서 기준서 원문으로 확인하지 않았습니다. 도입 검토 때 원문으로 확인해야 합니다(확인 필요).
확장 포인트 — 운영에서 실제로 손대는 자리
| 자리 | 무엇을 손대나 | 왜 |
|---|---|---|
| 대상 계정 매핑 | 과거근무원가 계정과 처리 구분을 매핑 테이블에 둔다 | 계정 체계는 회사마다 다르고 자주 바뀝니다 |
| 평가 결과 입력 | 평가 기관 결과의 적재 경로와 형식을 정한다 | 표준 원천이 없는 값이라 가장 먼저 정해야 합니다 |
| 사건 번호 규칙 | 전표 라인의 배정·참조 필드에 사건 번호를 적는 규칙 | 사건별 원장 합산의 키입니다 |
| 커스텀 필드·BAdI | 사건 번호나 처리 구분을 전표에 남기는 확장이 필요한 경우 검토 | 표준 필드로 부족할 때만 씁니다(확인 필요) |
| 권한 | 회사코드·계정 권한을 집계 뷰에 건다 | 인원·금액이 민감해 집계 단계에서 막아야 합니다 |
| 점검 코드 규칙 | 순서와 임계값(차이 허용 범위)을 회사 정책에 맞춘다 | 모든 차이를 점검 대상으로 두면 확인이 늘기만 합니다 |
권한에서 흔히 놓치는 자리. 집계 화면은 권한이 없어도 합계가 보이는 수가 있습니다. 특정 사업장의 권한이 없는 사람이 전사 합계는 보고 상세만 막히면, 뺄셈으로 다른 사업장 금액을 알아냅니다. 그래서 권한은 상세가 아니라 집계를 읽는 자리에 걸어야 합니다.
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
도입 상담과 데모에서 받을 만한 질문을 네 묶음으로 나눠 적었습니다.
숫자와 산식
과거근무원가는 어떻게 다시 계산합니까?
변경 후 DBO − 변경 전 DBO 입니다. 양수는 급여가 늘어난 개정, 음수는 급여가 줄어든 개정이나 축소의 효과입니다. 사건마다 이 값을 다시 구한 뒤 직급군 세 줄로 배분해 합이 같은지 확인합니다.
변경 전·후 DBO 자체는 보험수리 평가 결과를 입력값으로 받는 것으로 가정했습니다. 이 앱이 DBO를 새로 평가하지는 않습니다.
인식 시점은 어떻게 정합니까?
개정·축소일과 구조조정원가 인식일 중 이른 날을 재계산 인식일로 씁니다. 구조조정원가 인식일이 없는 사건은 개정·축소일 그대로입니다.
샘플 28건에는 구조조정원가 인식일이 개정·축소일보다 이른 사건 6건과 늦은 사건 1건이 들어 있어 ‘이른 날’ 판정이 실제로 갈리는지 확인했습니다. 이 판정 기준 자체가 회사 정책과 맞는지는 기준서 원문과 감사인 의견으로 확인해야 합니다(확인 필요).
사건 후 순이자 재측정액은 무엇입니까?
사건 이후 남은 기간의 순이자를 갱신한 가정으로 다시 산정했는지 보는 값입니다. 이 앱은 변경 후 DBO × 변경 후 할인율 × 잔여 개월 ÷ 12 로 단순화해 계산하고, 원장이 재측정을 반영하지 않았다면 변경 전 DBO × 변경 전 할인율 × 잔여 개월 ÷ 12 를 원장 반영액으로 봅니다.
실제 보험수리 계산은 훨씬 정교하므로, 이 값은 ‘재측정을 했는가’를 가리는 점검용 추정이라고 읽어야 합니다.
점검 코드는 왜 사건마다 하나만 붙습니까?
한 사건에 여러 조건이 겹쳐도 화면이 여러 이유를 늘어놓지 않도록 정해진 순서(A02 → A03 → A01 → A04 → A05)에서 먼저 해당하는 코드 하나만 씁니다. 처리 구분이 어긋난 사건은 금액 차이를 따져 보기 전에 그것부터 보는 것이 맞기 때문입니다.
어느 조건이 더 있었는지는 상세 창의 원장 항목과 재계산 항목을 나란히 보면 알 수 있습니다.
정합성 대사와 장부 점검 대사는 무엇이 다릅니까?
정합성 대사 6식(01~06)은 계산이 스스로 맞는지 확인합니다. DBO 변동 산식, 직급군 합계, 집계 합계 같은 것이라 차이는 0건이어야 합니다.
장부 점검 대사 3식(07~09)은 원장이 재계산과 맞는지 확인합니다. 점검 필요 사건이 있으면 여기서 차이 건수가 나옵니다. 둘을 섞으면 ‘계산이 틀렸나, 장부가 다른가’를 가를 수 없어서 구분을 나눠 두었습니다.
양수와 음수가 섞인 합계는 어떻게 읽습니까?
개정은 양수, 축소는 음수가 많아 합계가 서로 상쇄됩니다. 이 사례의 재계산 합계 −2,709,439,585원은 개정 +1,817,607,207원과 축소 −4,527,046,792원을 더한 값입니다. 합계만 보면 ‘크게 줄었다’로 읽히기 쉬워서 유형별 탭에서 두 방향을 나눠 보는 것이 맞습니다.
화면과 조작
조회조건에서 꼭 넣어야 하는 것은 무엇입니까?
기준 연월(6자리) 하나입니다. 사건 유형, 제도, 개정·축소일 기간, 점검 코드, 점검 결과는 선택이며 비워 두면 전체입니다. 전체는 코드값으로 보내지 않고 해당 조건을 서비스 호출에서 빼는 방식이라, 새 코드가 생겨도 ‘전체’ 의미가 달라지지 않습니다.
개정·축소일 기간은 어떻게 걸립니까?
시작일과 종료일을 둘 다 넣으면 기간 하나로 묶어 서비스에 전달합니다. 한쪽만 넣으면 그 날 이후 또는 이전만 걸립니다. 날짜 비교는 서비스가 직접 처리하므로 화면에서 걸러 낸 것이 아니라 서비스가 돌려준 사건만 표에 나옵니다.
행을 누르면 무엇이 열립니까?
사건 상세 창이 열립니다. 상단에 사건 전체의 변경 전·후 DBO, 할인율, 재계산·원장 금액, 인식일, 처리 구분, 점검 코드가 나오고, 아래에 직급군별 변경 전·후 DBO와 변동액이 나옵니다. 직급군 변동액의 합은 사건 과거근무원가와 같아야 합니다.
CSV는 무엇을 내려받습니까?
지금 보고 있는 탭의 조회 결과를 UTF-8 CSV로 내려받습니다. 사건 명세 탭에서 점검 필요만 걸어 내려받으면 확인 대상 목록이 되고, 유형별·제도별·대사 탭도 각각 내려받을 수 있습니다. 서버에 파일을 남기지 않습니다.
좁은 화면에서도 쓸 수 있습니까?
이 사례는 데스크톱 폭(1440px 안팎)을 기준으로 검수했고 좁은 화면 전용 배치는 따로 만들지 않았습니다. 표는 가로로 넘기며 보게 됩니다. 현장에서 태블릿이나 휴대폰 사용이 필요하다면 요구 범위를 먼저 정한 뒤 표 열 구성을 줄이는 작업을 별도로 잡는 편이 좋습니다(확인 필요).
점검 해석과 책임
‘점검 필요’는 회계 처리가 잘못됐다는 뜻입니까?
아닙니다. 원장과 재계산이 달라서 확인해 볼 만하다는 뜻입니다. 이 화면은 분류·집계·대사를 돕는 조회·점검 도구이며, 차이의 원인이 평가 가정이나 입력값에 있는지 원장 처리에 있는지를 단정하지 않습니다. 회계 처리의 최종 판단은 회사와 감사인이 합니다.
적용 시기와 경과규정은 어떻게 됩니까?
관련 기준서는 IAS 19 종업원급여(K-IFRS 제1019호)의 확정급여제도 개정·축소와 과거근무원가 부분입니다. 기준서별 적용 시기와 경과규정은 이 글에서 원문으로 확인하지 않았으므로 ‘확인 필요’입니다. 도입 검토 때 기준서 원문과 회사 정책으로 확인해 주세요.
정산 손익이나 보험수리적 재측정요소도 다룹니까?
다루지 않습니다. 이 화면의 대상은 제도 개정과 축소로 생긴 과거근무원가와 사건 이후 잔여기간의 순이자 재측정 반영 여부입니다. 정산(settlement) 손익, 보험수리적 손익, 자산 상한 효과는 범위 밖입니다.
법정 공시나 감사 대응 숫자를 이 앱이 만듭니까?
만들지 않습니다. 공시와 감사 대응은 SAP 표준 거래와 회사의 결산 절차에 두고, 이 앱은 그 숫자를 만들기 전·후에 사건 단위로 점검하는 관점을 더합니다. 운영에서 기존 확인 절차를 없앨 필요는 없습니다.
도입과 운영
누가 쓰고, 무엇이 달라집니까?
결산 때 종업원급여를 담당하는 회계팀과 이를 검토하는 팀장·본부장이 씁니다. 사건마다 흩어져 있던 평가 결과 · 원장 개별항목 · 엑셀 대조표가 한 화면의 한 행으로 모이고, 점검 코드가 확인할 사건의 순서를 먼저 잡아 줍니다. 대사 결과 탭이 있어 ‘숫자 맞아?’라는 질문에 바로 답할 수 있습니다.
변경 전·후 DBO는 어디서 옵니까?
보험수리 평가 결과를 입력값으로 받는 것으로 가정했습니다. 표준 원천 테이블이 없는 값이라 운영에서는 평가 기관 결과를 어떤 형식으로 어디에 적재할지부터 정해야 합니다. 이 글의 CDS 구성에서는 평가 결과 입력 테이블을 따로 세우는 방식으로 적었습니다(확인 필요).
원장 인식액은 어디서 가져옵니까?
S/4HANA 라면 유니버설 저널(ACDOCA)의 과거근무원가 계정 라인에서 가져옵니다. 표준 CDS인 I_JournalEntryItem 위에 대상 계정 매핑을 붙여 사건별로 합산하는 구조입니다. 전표 라인과 사건을 잇는 키(배정·참조 필드 등)를 어떻게 쓸지는 회사가 정해야 하는 항목입니다.
권한과 보안은 어떻게 걸립니까?
퇴직급여는 인원·금액이 민감하므로 회사코드와 계정 권한을 집계 뷰를 읽는 자리에 거는 것을 권합니다. DCL 로 표준 권한 객체를 따라가게 하면 화면은 권한이 있는 사건만 받습니다. 합계는 보이는데 상세만 막으면 뺄셈으로 다른 사업장 금액이 드러날 수 있어서 집계 단계가 맞습니다.
운영 데이터로 가도 성능이 괜찮습니까?
이 사례는 사건 28건이라 문제가 되지 않습니다. 운영에서도 사건 수는 연간 수십~수백 건 수준이라 사건 명세 쪽은 가볍습니다. 부담은 원장 인식액을 만드는 전표 집계에서 생기므로 기준 연월과 회사코드를 필수 입력으로 두고, 집계를 화면이 아니라 CDS 에서 하도록 올리는 것이 핵심입니다. 응답 시간 기준은 실제 환경에서 측정해 정해야 합니다(확인 필요).
계정 체계가 바뀌면 어떻게 합니까?
대상 계정은 코드에 박지 않고 매핑 테이블에 둡니다. 계정이 늘거나 바뀌면 매핑 행을 추가하고 유효기간을 조정하면 되고 화면은 그대로입니다. 유효기간을 두는 이유는 과거 기간의 숫자가 계정 체계 변경 뒤에도 흔들리지 않게 하기 위해서입니다.
운영에 올리는 절차는 어떻게 됩니까?
순서로 적으면 이렇습니다. ① 평가 결과 공급 방식과 대상 계정을 합의합니다. ② CDS 뷰와 DCL 을 만들어 이송합니다. ③ 서비스를 활성화합니다. ④ 화면의 데이터 소스 주소를 운영 서비스로 바꿉니다. ⑤ 첫 결산 기간에 표준 화면 숫자와 대사합니다.
기간은 합의 속도와 환경에 따라 달라 이 글에서 단정하지 않습니다(확인 필요).
표준 화면만으로는 안 됩니까?
개별항목 조회와 잔액 조회는 표준 T-code 로 충분합니다. 다만 사건 단위로 재계산하고 인식 시점을 비교해 점검 코드를 붙이는 일은 표준 화면에 없습니다. 이 앱은 표준 거래를 대체하지 않고 대조 지점으로 이어서 씁니다. 자세한 연계는 SAP 표준 기능 확장 포인트 절에 적었습니다.
화면을 다른 환경에 옮기려면 무엇을 바꿉니까?
화면은 데이터 소스를 매니페스트에 선언해 쓰므로, 같은 계약을 지키는 실제 서비스로 주소만 바꾸면 화면 코드는 그대로입니다. 서비스는 엔티티셋 · 키 · 필터 계약을 지켜야 합니다. 표시 글자는 i18n 파일에 있어 언어를 늘리는 일도 파일 하나를 더하는 작업입니다.