확정급여제도 개정·축소 과거근무원가 점검 — 변경 전·후 DBO 차이를 원장 인식액과 맞춰 보는 화면

Q: 과거근무원가는 어떻게 다시 계산합니까?

변경 후 DBO − 변경 전 DBO 입니다. 양수는 급여가 늘어난 개정, 음수는 급여가 줄어든 개정이나 축소의 효과입니다. 사건마다 이 값을 다시 구한 뒤 직급군 세 줄로 배분해 합이 같은지 확인합니다. 변경 전·후 DBO 자체는 보험수리 평가 결과를 입력값으로 받는 것으로 가정했습니다. 이 앱이 DBO를 새로 평가하지는 않습니다.

Q: 인식 시점은 어떻게 정합니까?

개정·축소일과 구조조정원가 인식일 중 이른 날을 재계산 인식일로 씁니다. 구조조정원가 인식일이 없는 사건은 개정·축소일 그대로입니다. 샘플 28건에는 구조조정원가 인식일이 개정·축소일보다 이른 사건 6건과 늦은 사건 1건이 들어 있어 ‘이른 날’ 판정이 실제로 갈리는지 확인했습니다. 이 판정 기준 자체가 회사 정책과 맞는지는 기준서 원문과 감사인 의견으로 확인해야 합니다(확인 필요).

Q: 사건 후 순이자 재측정액은 무엇입니까?

사건 이후 남은 기간의 순이자를 갱신한 가정으로 다시 산정했는지 보는 값입니다. 이 앱은 변경 후 DBO × 변경 후 할인율 × 잔여 개월 ÷ 12 로 단순화해 계산하고, 원장이 재측정을 반영하지 않았다면 변경 전 DBO × 변경 전 할인율 × 잔여 개월 ÷ 12 를 원장 반영액으로 봅니다. 실제 보험수리 계산은 훨씬 정교하므로, 이 값은 ‘재측정을 했는가’를 가리는 점검용 추정이라고 읽어야 합니다.

Q: 점검 코드는 왜 사건마다 하나만 붙습니까?

한 사건에 여러 조건이 겹쳐도 화면이 여러 이유를 늘어놓지 않도록 정해진 순서(A02 → A03 → A01 → A04 → A05)에서 먼저 해당하는 코드 하나만 씁니다. 처리 구분이 어긋난 사건은 금액 차이를 따져 보기 전에 그것부터 보는 것이 맞기 때문입니다. 어느 조건이 더 있었는지는 상세 창의 원장 항목과 재계산 항목을 나란히 보면 알 수 있습니다.

Q: 정합성 대사와 장부 점검 대사는 무엇이 다릅니까?

정합성 대사 6식(01~06)은 계산이 스스로 맞는지 확인합니다. DBO 변동 산식, 직급군 합계, 집계 합계 같은 것이라 차이는 0건이어야 합니다. 장부 점검 대사 3식(07~09)은 원장이 재계산과 맞는지 확인합니다. 점검 필요 사건이 있으면 여기서 차이 건수가 나옵니다. 둘을 섞으면 ‘계산이 틀렸나, 장부가 다른가’를 가를 수 없어서 구분을 나눠 두었습니다.

Q: 조회조건에서 꼭 넣어야 하는 것은 무엇입니까?

기준 연월(6자리) 하나입니다. 사건 유형, 제도, 개정·축소일 기간, 점검 코드, 점검 결과는 선택이며 비워 두면 전체입니다. 전체는 코드값으로 보내지 않고 해당 조건을 서비스 호출에서 빼는 방식이라, 새 코드가 생겨도 ‘전체’ 의미가 달라지지 않습니다.

Q: 개정·축소일 기간은 어떻게 걸립니까?

시작일과 종료일을 둘 다 넣으면 기간 하나로 묶어 서비스에 전달합니다. 한쪽만 넣으면 그 날 이후 또는 이전만 걸립니다. 날짜 비교는 서비스가 직접 처리하므로 화면에서 걸러 낸 것이 아니라 서비스가 돌려준 사건만 표에 나옵니다.

Q: CSV는 무엇을 내려받습니까?

지금 보고 있는 탭의 조회 결과를 UTF-8 CSV로 내려받습니다. 사건 명세 탭에서 점검 필요만 걸어 내려받으면 확인 대상 목록이 되고, 유형별·제도별·대사 탭도 각각 내려받을 수 있습니다. 서버에 파일을 남기지 않습니다.

소개 영상0분 46초8개 장면표지 → 요약 → 필터 → 집계 → 상세 → 대사 → 정리

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

확정급여제도를 개정하거나 축소한 해의 결산에서는 질문이 늘 같습니다. 과거근무원가를 얼마로 봐야 하나, 언제 인식해야 하나, 장부에는 그렇게 들어가 있나. 지금 이 세 답은 보험수리 평가 결과, 원장 개별항목, 그리고 둘을 맞춰 보는 엑셀로 흩어져 있습니다.

표준 화면으로 원장 라인과 잔액은 얼마든지 볼 수 있습니다. 막히는 자리는 그 다음입니다. 변경 전·후 확정급여채무(DBO)의 차이로 과거근무원가를 다시 계산하고, 인식 시점을 비교하고, 원장 처리가 그와 같은지 사건 하나하나 맞춰 보는 일은 사람이 엑셀로 합니다. 사건이 몇 건 안 될 때는 버티지만, 개정과 축소가 겹친 해에는 확인 순서를 잡는 것부터 일이 됩니다.

이 앱은 그 자리를 메웁니다. 사건 명세 한 줄에 재계산 과거근무원가, 인식일, 원장 인식액과 처리 구분을 나란히 놓고, 점검 코드가 확인할 사건과 이유를 먼저 가려 줍니다. 관련 기준서는 IAS 19 종업원급여(K-IFRS 제1019호) 의 확정급여제도 개정·축소와 과거근무원가입니다. 기준서별 적용 시기와 경과규정은 이 글에서 원문으로 확인하지 않았으므로 “확인 필요”로 두었습니다.

한 줄 요약 — 이 화면은 점검·대사를 돕는 조회 도구입니다. 계산을 대신 확정하지 않고, 원장과 재계산이 다른 사건을 먼저 보여 주어 확인 시간을 줄입니다. 회계 처리의 최종 판단은 회사와 감사인이 합니다.

사건마다 숫자가 세 곳에 흩어져 있다

변경 전·후 DBO 는 평가 결과에, 원장 금액은 개별항목에, 두 숫자의 대조는 엑셀에 있습니다. 한 사건을 맞추려면 세 곳을 열고, 사건이 스무 건이면 그 일을 스무 번 합니다. 이 앱은 사건 한 줄에 세 곳의 숫자를 모아 두고, 직급군별 배분까지 행을 눌러 내려가게 했습니다. 숫자를 찾는 시간이 사라지는 대신 숫자를 해석하는 시간이 남습니다.

인식 시점은 날짜 하나가 아니라 두 날짜 중 이른 날이다

재계산 인식일은 개정·축소일과 구조조정원가 인식일 중 이른 날로 둡니다. 구조조정원가 인식일이 없는 사건은 개정·축소일 그대로입니다. 두 날짜는 서로 다른 문서에 적혀 있어서 눈으로 비교하다 보면 사건마다 기준이 흔들립니다. 샘플에는 구조조정원가 인식일이 더 이른 사건 6건과 더 늦은 사건 1건을 일부러 섞어 판정이 실제로 갈리는지 확인했습니다. 원장 인식월이 이 재계산 인식월과 다르면 점검 코드 A04 가 붙습니다.

원장 처리가 맞는지는 열어 봐야 안다

과거근무원가를 당기손익으로 인식했는지, 기타포괄손익으로 처리했는지, 가득기간에 걸쳐 배분했는지는 금액만 봐서는 알 수 없습니다. 개별항목과 전표를 열어야 보입니다. 이 앱은 원장 처리 구분을 사건 행에 함께 두고, 기타포괄손익(A02)이나 가득기간 배분(A03)으로 처리된 사건에는 금액 비교보다 먼저 코드를 붙입니다. 이유가 분명한 것부터 확인하도록 순서를 잡은 것입니다.

점검 순서를 코드가 먼저 잡아야 확인이 줄어든다

점검 코드는 사건마다 하나만 붙고, 아래 순서에서 먼저 해당하는 코드를 씁니다. 결과는 “점검 필요”와 “확인 필요”로만 표기하고 원인을 단정하지 않습니다. 샘플 28건 중 점검 필요 13건의 분포는 표와 같습니다.

순서	점검 코드	판정 조건	사용자 조치	샘플 건수
1	`A02`	원장 처리 구분이 기타포괄손익	과거근무원가를 당기손익으로 인식했는지 확인	2건
2	`A03`	원장 처리 구분이 가득기간 배분	배분하지 않고 즉시 인식했는지 확인	2건
3	`A01`	원장 인식액 − 재계산 과거근무원가 ≠ 0	변경 전·후 DBO 평가 대상·가정 확인	3건
4	`A04`	원장 인식월 ≠ 재계산 인식월	개정·축소일과 구조조정원가 인식일 비교	3건
5	`A05`	원장이 사건 후 재측정 미반영이고 반영액 차이 ≠ 0	갱신한 가정으로 잔여기간 순이자를 다시 산정했는지 확인	3건
6	`I00`	위 조건에 모두 해당하지 않음	조치 없음	15건

그래서 무엇을 보려는 검토인가

검토의 질문은 두 가지입니다. 첫째, 사건 단위 재계산과 원장 대사를 한 화면에 모으는 점검 도구가 결산 확인 시간을 실제로 줄이는가. 둘째, 도입하려면 무엇을 먼저 정해야 하는가. 둘째 질문의 답은 이 글의 CDS 구성 절 “운영 시점에 해야 할 일” 표에 모아 두었습니다. 평가 결과를 누가 어떻게 공급하는지, 어느 계정을 대상으로 볼지가 기술보다 먼저입니다.

사용 방법

조회조건 입력 — 기준 연월(6자리)은 필수이고 사건 유형 · 제도 · 개정·축소일 기간 · 점검 코드 · 점검 결과는 선택입니다. 비워 두면 전체입니다.
조회 — 조회조건 줄 맨 오른쪽의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 화면을 처음 열면 기본 기준 연월로 자동 조회됩니다.
요약 숫자 확인 — 사건 건수, 재계산 과거근무원가 합계, 원장 인식액 합계, 두 값의 차이, 사건 후 재측정 차이, 점검 필요 건수, 정합성 대사 차이 건수를 봅니다.
탭 이동 — 사건 명세 → 사건 유형별 집계 → 제도별 집계 → 대사 결과 순서로 확인합니다.
행 클릭 상세 — 사건 명세의 행을 누르면 직급군별 변경 전·후 DBO 와 과거근무원가 배분이 창으로 열립니다.
CSV 내려받기 — 지금 보고 있는 탭의 조회 결과를 UTF-8 CSV 로 내려받아 검토 자료로 씁니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세우고 사건 28건 전수로 돌렸습니다. 아래는 가상 샘플 데이터의 결과입니다. 정합성 대사(01~06)는 계산이 스스로 맞는지, 장부 점검 대사(07~09)는 원장이 재계산과 맞는지를 가립니다.

대사식	검사 건수	차이
01 DBO 변동 산식 — Σ변경 전 DBO + Σ과거근무원가 = Σ변경 후 DBO	28	0
02 직급군별 변동 합계 = 사건 과거근무원가	28	0
03 직급군별 변경 전·후 DBO 합계 = 사건 변경 전·후 DBO	28	0
04 사건 유형별 집계 합계 = 명세 합계	28	0
05 제도별 집계 합계 = 명세 합계	28	0
06 인식일 = Min(개정·축소일, 구조조정원가 인식일)	28	0
07 원장 인식액 = 재계산 과거근무원가	28	5건(의도적 예외)
08 사건 후 잔여기간 재측정 — 원장 반영액 = 재계산액	28	3건(의도적 예외)
09 원장 인식월 = 재계산 인식월	28	3건(의도적 예외)

정합성 대사 6식은 모두 차이 0건입니다. 장부 점검 대사의 차이는 점검 필요 사건을 일부러 넣은 의도적 예외 13건(A01 3 · A02 2 · A03 2 · A04 3 · A05 3)에서 나온 것이라 계산 어긋남과 분리해 기록했습니다. 07번의 최대 차이는 264,676,776원, 08번은 7,227,704원, 09번은 10개월입니다. 화면 쪽은 이와 별도로 브라우저 자동화로 요약 숫자(재계산 합계 −2,709,439,585원 · 원장 합계 −2,226,195,521원 · 차이 +483,244,064원)가 검증 결과와 같은지 렌더링 상태에서 대조했습니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면	OpenUI5 표준 컨트롤(sap_horizon 테마) — 조회조건 줄, 요약 카드, 탭 네 개, 사건 명세 표, 상세 창	표준 컨트롤만 써서 외부 라이브러리 반입 심사 없이 올릴 수 있고 Fiori 화면과 결이 같습니다.
점검·집계 로직	컨트롤러의 조회·요약·CSV 코드와 점검 코드 판정(서비스 쪽)	판정을 서비스 한 곳에 두면 화면을 바꿔도 점검 결과가 달라지지 않습니다.
OData 구성	매니페스트의 데이터 소스에 OData V2 서비스를 상대 경로로 선언하고 이름 없는 기본 모델이 이를 씁니다. 탭마다 해당 엔티티셋에 표를 바인딩하고, 조회조건은 Filter 객체로 만들어 서비스의 필터로 전달하며, 총건수는 인라인 카운트로 받습니다	화면 코드를 고치지 않고 같은 계약의 실제 서비스로 주소만 바꿔 운영에 연결하려는 구조입니다. “전체”는 필터를 만들지 않습니다.
연결 실패 안내	연결 실패 · 요청 실패 · 빈 응답을 구분해 사용자 문구로 안내하는 처리	조회가 비었을 때 ‘데이터가 없는 것’과 ‘못 불러온 것’을 가려 읽게 하려는 것입니다.
테마	sap_horizon	SAP 표준 화면과 같은 테마라 사용자가 낯설어하지 않습니다.

항목	내용
업무 영역	재무회계(FI) — 종업원급여
관련 기준서	IAS 19 종업원급여(K-IFRS 제1019호) — 확정급여제도의 개정·축소(과거근무원가)
SAP 표준 T-code	FAGLL03 · FS10N · FB03
화면 성격	조회·점검·대사(조회 전용)
데이터 연동	OData V2 서비스
샘플 데이터	가상 회사·가상 제도의 검증용 데이터 — 사건 28건(개정 16 · 축소 12), 직급군 줄 84건, 대사 9건

SAP 표준 기능을 그대로 이어받은 부분. 원장 인식액과 인식일은 SAP 표준의 총계정원장 라인(유니버설 저널)에서 읽는 값을 그대로 쓰고, 이 화면은 그 위에 사건 단위 재계산과 점검 관점을 더해 확장합니다. 표준 실행은 SAP 표준 T-code 가 담당합니다.

실행 화면

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

처음 열었을 때와 좁혀 볼 때

조회조건 한 줄 아래에 요약 숫자, 그 아래에 사건 명세가 세로로 놓입니다. 기준 연월만 필수이고 나머지는 비워 두면 전체입니다.

처음 연 화면 — 조회조건 · 요약 숫자 · 사건 명세 — **처음 연 화면** — 조회조건 한 줄, 요약 숫자 일곱 칸, 그 아래 사건 명세 28건이 한 화면에 놓입니다.

기준 연월(기본 202412)로 자동 조회되어 열자마자 숫자가 찹니다. 요약은 사건 건수 · 재계산 과거근무원가 합계(−2,709,439,585원) · 원장 인식액 합계(−2,226,195,521원) · 두 값의 차이(+483,244,064원) · 사건 후 재측정 차이 · 점검 필요 건수 · 정합성 대사 차이 건수 순입니다. 마지막 칸이 0이어야 위의 숫자를 믿고 읽을 수 있습니다.

**개정·축소일 기간과 점검 결과로 좁힌 화면** — 개정·축소일 기간과 점검 필요를 고르면 해당 사건만 남고 요약 숫자도 함께 바뀝니다.

기간 시작·종료를 둘 다 넣으면 하나의 기간 조건으로 전달되고, 점검 결과를 점검 필요로 두면 확인할 사건만 남습니다. 요약 숫자가 같이 줄어들기 때문에 남은 사건의 차이 합계가 곧바로 읽힙니다. 이 상태에서 CSV 내려받기를 누르면 보이는 조건 그대로 검토 자료가 됩니다.

유형별 · 제도별로 묶어 볼 때

사건 명세를 읽다 보면 ‘어디에 몰려 있나’가 궁금해집니다. 같은 숫자를 사건 유형과 제도로 묶은 두 탭이 그 답을 줍니다.

사건 유형별 집계 — 제도 개정과 제도 축소 비교 — **사건 유형별 집계** — 제도 개정 16건과 제도 축소 12건을 나눠 변경 전·후 DBO와 과거근무원가, 원장 인식액 차이를 비교합니다.

개정은 과거근무원가가 +1,817,607,207원(급여 증가), 축소는 −4,527,046,792원(급여 감소)으로 방향이 다릅니다. 두 유형을 합친 값이 사건 명세 합계와 같은지는 대사 04번이 매번 확인합니다. 점검 필요 건수는 개정 5건, 축소 8건으로 어느 유형에 확인이 몰리는지 한눈에 보입니다.

제도별 집계 — 본사 사무직 · 생산직 · 해외 자회사 — **제도별 집계** — 제도별로 같은 숫자를 묶어 차이가 특정 제도에 몰려 있는지 확인합니다.

가상 제도 세 개(본사 사무직 12건 · 생산직 9건 · 해외 자회사 7건)로 묶었습니다. 원장 인식액과 재계산의 차이는 본사 사무직에 +477,439,064원으로 몰려 있고 해외 자회사는 0원입니다. 차이가 제도 한 곳에 몰리면 계산 가정이나 원장 처리 방식이 그 제도에서 달랐는지부터 봅니다.

행에서 상세로, 그리고 대사로

의심 가는 사건은 행을 눌러 직급군별 배분까지 내려가고, 마지막으로 대사 탭에서 숫자 전체가 맞는지 확인합니다.

사건 상세 — 직급군별 변경 전·후 DBO와 배분 — **사건 상세** — 사건 행을 누르면 직급군별 변경 전·후 DBO와 과거근무원가 배분, 원장 처리 항목이 한 창에 열립니다.

상단에는 사건의 변경 전·후 DBO, 할인율, 재계산 과거근무원가, 원장 인식액과 처리 구분, 인식일, 점검 코드가 나옵니다. 아래 표는 직급군 세 줄의 변경 전·후 DBO와 변동액이며, 세 줄의 변동액을 더하면 사건 과거근무원가와 같아야 합니다(대사 02번). 점검 필요 사건은 이 창에서 어느 항목이 달랐는지부터 읽습니다.

대사 결과 — 정합성 대사와 장부 점검 대사 — **대사 결과** — 정합성 대사 6식은 차이 0건이고, 장부 점검 대사 3식은 원장과 재계산의 차이 건수를 따로 보여 줍니다.

위쪽 여섯 줄(INT)은 계산이 스스로 맞는지, 아래 세 줄(BOOK)은 원장이 재계산과 맞는지를 가립니다. 장부 점검 대사의 차이 건수(5·3·3)는 점검 필요 사건을 일부러 넣어 둔 결과이며, 계산 자체의 어긋남과 섞이지 않도록 구분을 나눠 두었습니다. 최대 차이 열에서 가장 큰 어긋남이 얼마인지 바로 읽습니다.

화면 뒤에서 일어나는 일

조회를 누르면 사건 명세와 두 집계, 대사 결과를 같은 기준 연월로 읽어 옵니다. 재계산과 판정은 아래 순서로 이루어지며 화면은 그 결과를 그립니다.

과거근무원가 = 변경 후 DBO − 변경 전 DBO. 양수는 급여 증가, 음수는 급여 감소·축소 효과입니다.
직급군 배분 — 직급군별 변동 합계 = 사건 과거근무원가, 직급군별 변경 전·후 DBO 합계 = 사건 변경 전·후 DBO 가 되어야 합니다.
재계산 인식일 = 개정·축소일과 구조조정원가 인식일 중 이른 날(구조조정원가 인식일이 없으면 개정·축소일).
사건 후 잔여 개월 = 12 − 개정·축소월. 재계산 사건 후 순이자 재측정액 = 변경 후 DBO × 변경 후 할인율 × 잔여 개월 ÷ 12.
원장 반영액(재측정 미반영) = 변경 전 DBO × 변경 전 할인율 × 잔여 개월 ÷ 12.
차이 — 과거근무원가 차이 = 원장 인식액 − 재계산 과거근무원가, 인식 시점 차이 = 원장 인식월 − 재계산 인식월(개월).
집계 탭 합계 = 사건 명세 합계(유형별·제도별 각각).

점검 코드 판정 규칙

사건 한 건에 점검 코드는 하나만 붙고, 아래 순서로 먼저 해당하는 코드를 씁니다.

순서	점검 코드	판정 조건	결과 상태	사용자 조치
1	`A02`	원장 처리 구분이 기타포괄손익	점검 필요	과거근무원가를 당기손익으로 인식했는지 확인
2	`A03`	원장 처리 구분이 가득기간 배분	점검 필요	배분하지 않고 즉시 인식했는지 확인
3	`A01`	원장 인식액 − 재계산 과거근무원가 ≠ 0	점검 필요	변경 전·후 DBO 평가 대상·가정 확인
4	`A04`	원장 인식월 ≠ 재계산 인식월	점검 필요	개정·축소일과 구조조정원가 인식일 비교
5	`A05`	원장이 사건 후 재측정 미반영이고 반영액 차이 ≠ 0	점검 필요	갱신한 가정으로 잔여기간 순이자를 다시 산정했는지 확인
6	`I00`	위 조건에 모두 해당하지 않음	정상	조치 없음

조회조건

조건	필수	기본값	서비스로 가는 필터
기준 연월	필수	202412	`Period eq '202412'`
사건 유형	선택	전체	선택했을 때만 `EventType eq 'A'` 또는 `'C'`
제도	선택	전체	선택했을 때만 `PlanCode eq 'P1'` 등
개정·축소일 시작·종료	선택	비움	`EventDate ge/le` 날짜 — 둘 다 넣으면 기간 하나로 전달
점검 코드	선택	전체	선택했을 때만 `CheckCode eq 'A01'` 등
점검 결과	선택	전체	선택했을 때만 `CheckStatus eq 'CHECK'`

“전체”는 코드값으로 보내지 않고 해당 조건을 필터에서 뺍니다. 유형별·제도별 집계 탭에는 그 탭에 해당하는 조건만 적용됩니다.

결과 컬럼

컬럼	의미	산출식
변경 전·후 DBO	제도 변경 전후의 확정급여채무	평가 결과 입력값(확인 필요)
재계산 과거근무원가	변경으로 생긴 채무의 변동	변경 후 DBO − 변경 전 DBO
재계산 인식일	재계산 기준의 인식 시점	Min(개정·축소일, 구조조정원가 인식일)
원장 인식액 · 처리 구분 · 인식일	원장에 실제로 들어간 금액과 처리	총계정원장 라인(유니버설 저널) 합산
과거근무원가 차이	원장과 재계산의 금액 차이	원장 인식액 − 재계산 과거근무원가
인식 시점 차이	원장과 재계산의 인식월 차이(개월)	원장 인식월 − 재계산 인식월
사건 후 재측정 차이	사건 이후 잔여기간 순이자 반영 차이	원장 반영액 − 재계산 재측정액
점검 코드 · 점검 결과	확인 대상 여부와 이유	위 판정 규칙의 순서

좁은 화면에서 달라지는 것

이 사례는 데스크톱 폭을 기준으로 검수했으며 좁은 화면 전용 배치는 따로 만들지 않았습니다. 표는 가로로 넘겨 보게 됩니다. 태블릿이나 휴대폰 사용이 필요한 현장이라면 보여 줄 열을 줄이는 작업을 별도로 정해야 합니다(확인 필요).

파일 구성

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

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 구성

이 사례의 화면은 가상 사건 28건을 서비스에서 받아 그립니다. 데모라서 되는 일이고, 운영에서는 평가 결과와 원장 전표를 CDS 로 읽어 DB 에서 집계하게 됩니다. 아래는 그때 만드는 객체를 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

레이어	객체	하는 일	왜 나누나
기준	`ZPSC_ACCTMAP`	대상 계정 → 처리 구분(손익·기타포괄손익·가득기간 배분) 매핑	계정은 늘고 바뀝니다. 코드에 박으면 바뀔 때마다 개발자를 부르게 됩니다.
입력	`ZPSC_VALUATION`	사건별 변경 전·후 DBO · 할인율 · 개정·축소일	표준 원천이 없는 값이라 받는 자리를 따로 세웁니다.
집계	`ZI_PastSvcLedger`	유니버설 저널 라인을 사건 단위로 합산	화면이 라인을 들고 묶던 일을 DB 로 내립니다.
큐브	`ZI_PastSvcEventCube`	재계산 · 원장 대조 · 차이 · 점검 코드	판정을 화면이 아니라 여기 한 곳에서 정의합니다.
쿼리	`ZC_PastSvcCheckQuery`	필수 조회조건과 목록 열 구성	표준 Fiori 앱과 이 앱이 같은 뷰를 읽게 합니다.
권한	`ZI_PASTSVCEVENTCUBE` (DCL)	회사코드 권한	집계를 읽는 자리에 걸어야 뺄셈으로 새지 않습니다.
서비스	`ZUI_PastSvcCheck`	소비 뷰를 OData 서비스로 노출	화면은 서비스 주소만 알면 됩니다.

① 대상 계정 매핑 테이블

리포트의 모든 원장 숫자가 이 표에서 갈립니다. 어느 계정을 과거근무원가로 볼지, 그 계정이 손익인지 기타포괄손익인지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 것은 계정 체계가 중간에 바뀌어도 과거 기간 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
" ZPSC_ACCTMAP — 과거근무원가 대상 계정 매핑 (DDIC 테이블)
" 역할  : 어떤 계정의 라인을 '과거근무원가 원장 인식액'으로 모을지, 그 계정이
"         손익(P)·기타포괄손익(O)·가득기간 배분(D) 중 무엇인지 정한다.
" 이유  : 계정은 늘고 바뀐다. 코드에 박으면 바뀔 때마다 개발자를 부르게 된다.
"         유효기간을 두어 계정 체계가 바뀌어도 과거 기간 숫자가 흔들리지 않게 한다.
" 확인 필요 : 회사코드·계정 체계는 고객사 기준으로 정한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '과거근무원가 대상 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpsc_acctmap {
  key client       : abap.clnt not null;
  key company_code : abap.char(4) not null;
  key gl_account   : abap.char(10) not null;
  key valid_to     : abap.dats not null;
  valid_from       : abap.dats not null;
  treat_code       : abap.char(1) not null;   " P 당기손익 / O 기타포괄손익 / D 가득기간 배분
  remark           : abap.char(60);
}

② 평가 결과 입력 테이블

변경 전·후 DBO 는 SAP 표준 테이블에서 나오는 값이 아닙니다. 평가 기관이 낸 결과를 받아 적는 자리이므로 누가 어떤 형식으로 언제 적재하는가가 이 테이블의 핵심입니다. 입력 권한은 제한하고 읽기는 CDS 로만 열어 둡니다.

" ────────────────────────────────────────────────────────────────
" ZPSC_VALUATION — 보험수리 평가 결과 입력 테이블 (DDIC 테이블)
" 역할  : 사건별 변경 전·후 DBO, 할인율, 개정·축소일, 구조조정원가 인식일을 받는다.
" 이유  : 변경 전·후 DBO 는 표준 원천 테이블이 없는 값이다(확인 필요).
"         평가 기관 결과를 어떤 경로로 적재할지는 운영 전환에서 가장 먼저 정한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '확정급여제도 개정·축소 평가 결과'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zpsc_valuation {
  key client       : abap.clnt not null;
  key company_code : abap.char(4) not null;
  key fiscal_year  : abap.numc(4) not null;
  key event_id     : abap.char(4) not null;
  event_name       : abap.char(70);
  plan_code        : abap.char(2);
  event_type       : abap.char(1);            " A 제도 개정 / C 제도 축소
  event_date       : abap.dats;
  restruct_date    : abap.dats;               " 구조조정원가 인식일(없으면 초기값)
  disc_rate_before : abap.dec(9,4);
  disc_rate_after  : abap.dec(9,4);
  currency         : abap.cuky;
  @Semantics.amount.currencyCode : 'zpsc_valuation.currency'
  dbo_before       : abap.curr(18,2);
  @Semantics.amount.currencyCode : 'zpsc_valuation.currency'
  dbo_after        : abap.curr(18,2);
}

③ 원장 인식액 집계 뷰

유니버설 저널(ACDOCA)의 라인을 사건 단위로 합산합니다. 사건과 전표를 잇는 키를 무엇으로 할지(배정 필드, 참조 필드 등)가 정해져야 사건별 합계가 맞으므로, 회계팀이 전표 입력 규칙까지 함께 정해야 합니다. 표준 CDS 이름은 환경에서 확인한 뒤 씁니다.

" ────────────────────────────────────────────────────────────────
" ZI_PastSvcLedger — 원장 인식액 집계 (CDS 뷰 엔티티)
" 역할  : 유니버설 저널 라인 중 매핑된 계정의 금액을 사건 단위로 합산한다.
" 이유  : 화면이 라인을 들고 묶던 일을 DB 로 내린다. 사건과 전표를 잇는 키는
"         배정(AssignmentReference) 필드를 쓰는 것으로 가정했다 — 회사 규칙으로 확정(확인 필요).
" 표준 CDS : I_JournalEntryItem (필드명·릴리스별 차이는 View Browser 로 확인 필요)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '과거근무원가 원장 인식액 집계'
define view entity ZI_PastSvcLedger
  as select from I_JournalEntryItem as _Item
    inner join   zpsc_acctmap       as _Map
      on  _Map.company_code = _Item.CompanyCode
      and _Map.gl_account   = _Item.GLAccount
      and _Item.PostingDate between _Map.valid_from and _Map.valid_to
{
  key _Item.CompanyCode,
  key _Item.FiscalYear,
  key _Item.AssignmentReference         as EventId,
      _Map.treat_code                   as LedgerTreat,
      min( _Item.PostingDate )          as LedgerRecogDate,
      _Item.CompanyCodeCurrency         as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( _Item.AmountInCompanyCodeCurrency ) as LedgerAmt
}
where _Item.Ledger = '0L'
group by
  _Item.CompanyCode, _Item.FiscalYear, _Item.AssignmentReference,
  _Map.treat_code, _Item.CompanyCodeCurrency

④ 사건 큐브 — 재계산과 점검 코드

이 앱의 핵심 판정이 모이는 곳입니다. 과거근무원가 재계산, 인식일(이른 날) 판정, 원장 금액과의 차이, 점검 코드가 한 뷰에 있어서 어느 화면이나 같은 판정을 받습니다. 코드는 A02 → A03 → A01 순서까지만 보였고 A04·A05 는 같은 방식으로 이어 씁니다.

" ────────────────────────────────────────────────────────────────
" ZI_PastSvcEventCube — 사건 큐브 (CDS 뷰 엔티티)
" 역할  : 평가 결과로 과거근무원가를 다시 계산하고, 원장 집계와 한 줄에 붙여
"         차이와 점검 코드까지 한 번만 정의한다.
" 이유  : 차이·점검 코드를 화면에서 계산하면 화면마다 판정이 달라진다.
"         판정 순서(A02 → A03 → A01 → A04 → A05)를 여기 한 곳에 둔다.
" 확인 필요 : 재측정액 산식은 점검용 단순화다. 실제 평가 방식과 맞는지 회계팀 확인.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '확정급여제도 개정·축소 사건 큐브'
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #S, dataClass: #MIXED }
define view entity ZI_PastSvcEventCube
  as select from zpsc_valuation as _V
    left outer join ZI_PastSvcLedger as _L
      on  _L.CompanyCode = _V.company_code
      and _L.FiscalYear  = _V.fiscal_year
      and _L.EventId     = _V.event_id
{
  key _V.company_code                          as CompanyCode,
  key _V.fiscal_year                           as FiscalYear,
  key _V.event_id                              as EventId,
      _V.event_name                            as EventName,
      _V.plan_code                             as PlanCode,
      _V.event_type                            as EventType,
      _V.event_date                            as EventDate,
      _V.currency                              as Currency,

      @Semantics.amount.currencyCode: 'Currency'
      _V.dbo_before                            as DboBefore,
      @Semantics.amount.currencyCode: 'Currency'
      _V.dbo_after                             as DboAfter,

      /* 재계산 과거근무원가 = 변경 후 DBO - 변경 전 DBO */
      @Semantics.amount.currencyCode: 'Currency'
      _V.dbo_after - _V.dbo_before             as PastSvcCalc,

      /* 재계산 인식일 = 개정·축소일과 구조조정원가 인식일 중 이른 날 */
      case when _V.restruct_date is not initial
            and _V.restruct_date < _V.event_date
           then _V.restruct_date
           else _V.event_date end              as RecogDate,

      @Semantics.amount.currencyCode: 'Currency'
      _L.LedgerAmt                             as LedgerAmt,
      _L.LedgerTreat                           as LedgerTreat,
      _L.LedgerRecogDate                       as LedgerRecogDate,

      /* 과거근무원가 차이 = 원장 인식액 - 재계산 */
      @Semantics.amount.currencyCode: 'Currency'
      coalesce( _L.LedgerAmt, 0 ) - ( _V.dbo_after - _V.dbo_before ) as AmtDiff,

      /* 점검 코드 — 먼저 해당하는 하나만 */
      case
        when _L.LedgerTreat = 'O'                                        then 'A02'
        when _L.LedgerTreat = 'D'                                        then 'A03'
        when coalesce( _L.LedgerAmt, 0 ) <> _V.dbo_after - _V.dbo_before then 'A01'
        /* A04(인식월 불일치)·A05(사건 후 재측정 미반영)는 같은 방식으로 이어 쓴다 */
        else 'I00'
      end                                      as CheckCode
}

⑤ 조회·점검용 소비 뷰

조회조건과 목록 열을 선언합니다. 회사코드와 회계연도를 필수 필터로 걸어 대량 조회를 막고, 개정·축소일은 구간으로 받습니다. 같은 뷰를 표준 Fiori 앱이 읽어도 필터 정의가 같아집니다.

" ────────────────────────────────────────────────────────────────
" ZC_PastSvcCheckQuery — 조회·점검용 소비 뷰 (Consumption 뷰)
" 역할  : 조회조건(필터)과 목록 열 구성을 선언한다. 표준 Fiori 앱과 이 앱이
"         같은 뷰를 읽게 해서 화면마다 필터 정의가 달라지는 일을 막는다.
" 이유  : 기준 연월·회사코드는 필수로 걸어 대량 조회를 막는다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '과거근무원가 점검 조회'
@Metadata.allowExtensions: true
@Search.searchable: true
define view entity ZC_PastSvcCheckQuery
  as projection on ZI_PastSvcEventCube
{
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key CompanyCode,
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key FiscalYear,
  key EventId,
  @Search.defaultSearchElement: true
  EventName,
  @Consumption.filter.selectionType: #SINGLE
  PlanCode,
  @Consumption.filter.selectionType: #SINGLE
  EventType,
  @Consumption.filter.selectionType: #INTERVAL
  EventDate,
  DboBefore,
  DboAfter,
  PastSvcCalc,
  LedgerAmt,
  AmtDiff,
  @Consumption.filter.selectionType: #SINGLE
  CheckCode
}

⑥ 접근 제어(DCL)

권한은 상세로 내려가는 자리가 아니라 큐브를 읽는 자리에 걸어야 합니다. 합계는 보이고 상세만 막히면 뺄셈으로 다른 사업장의 금액을 알 수 있기 때문입니다. 아래는 회사코드 하나만 건 최소 예시이며 실제 권한 설계는 회사 기준으로 정합니다.

" ────────────────────────────────────────────────────────────────
" ZI_PASTSVCEVENTCUBE — 접근 제어 (DCL)
" 역할  : 큐브를 읽는 자리에 회사코드 권한을 건다.
" 이유  : 합계는 보이고 상세만 막으면 뺄셈으로 다른 사업장 금액이 드러난다.
"         퇴직급여는 인원·금액이 민감해 집계 단계에서 막는 것이 맞다.
" 확인 필요 : 권한 객체와 필드 사용은 회사 권한 설계에 맞춰 확정한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '과거근무원가 점검 접근 제어'
@MappingRole: true
define role ZI_PASTSVCEVENTCUBE {
  grant select on ZI_PastSvcEventCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

소비 뷰를 OData 서비스로 노출합니다. 이 화면은 조회 전용이므로 읽기 가능한 뷰만 노출하고, 서비스 바인딩은 ADT 에서 만들어 게시합니다. 서비스를 활성화하면 화면의 데이터 소스 주소를 이 서비스로 바꿔 운영 데이터를 읽게 됩니다.

" ────────────────────────────────────────────────────────────────
" ZUI_PastSvcCheck — 서비스 정의와 바인딩 (Service Definition)
" 역할  : 소비 뷰를 OData 서비스로 노출한다. 화면은 이 서비스를 읽기만 한다.
" 이유  : 조회 전용 도구이므로 노출 대상은 읽기 가능한 뷰로 한정한다.
" 바인딩 : ADT 에서 서비스 바인딩(OData V2 – UI)을 만들어 게시한다(확인 필요).
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '과거근무원가 점검 서비스'
define service ZUI_PastSvcCheck {
  expose ZC_PastSvcCheckQuery as EventSet;
  expose ZI_PastSvcLedger     as LedgerSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 정하지 않은 채 올리면 첫 결산 때 막히는 것들입니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
평가 결과 공급	평가 기관 결과를 어떤 형식·경로·시점으로 적재할지	변경 전·후 DBO 가 비어 재계산이 돌지 않습니다	인사·회계팀
대상 계정 매핑	과거근무원가 계정과 처리 구분	원장 인식액이 엉뚱한 계정에서 모입니다	회계팀
사건과 전표 연결 키	배정·참조 필드 등 사건 번호를 적는 규칙	사건별 원장 합산이 어긋납니다	회계팀·IT
인식일 판정 기준	이른 날 기준의 적용 범위와 예외	인식 시점 점검(A04)이 사람마다 다르게 읽힙니다	회계팀·감사인
대사 체계	FAGLL03 · FS10N 와 맞출 항목과 허용 차이	‘숫자 맞아?’ 에 답할 기준이 없습니다	회계팀
권한 설계	회사코드·계정 권한 객체와 역할	인원·금액이 권한 없는 사용자에게 보입니다	보안·권한
성능 기준	기준 연월·회사코드 필수화와 응답 시간 목표	대량 전표 집계가 화면 응답을 늦춥니다	IT
이송 순서	테이블 → 뷰 → DCL → 서비스 정의·바인딩 순서	활성화 순서가 꼬여 서비스가 열리지 않습니다	Basis·IT
서비스 활성화와 주소 교체	`/IWFND/MAINT_SERVICE` 또는 바인딩 게시, 화면 데이터 소스 주소 교체	화면이 빈 채로 열립니다	Basis·IT

운영 데이터로 갈 때

사건 명세는 연간 수십~수백 건 수준이라 가볍습니다. 부담은 원장 인식액을 만드는 전표 집계에서 생깁니다. 첫째, 회사코드와 회계연도를 필수 조건으로 두어 전 기간 조회를 막습니다. 둘째, 집계는 화면이 아니라 CDS 에서 하도록 올리고 사건과 전표를 잇는 키에 인덱스가 필요한지 확인합니다. 셋째, 전표가 수천만 건인 환경에서는 집계 결과를 미리 쌓아 두는 방식(집계 테이블이나 분석 캐시)을 검토합니다. 응답 시간 기준은 실제 환경에서 측정해 정해야 하며 이 글에서는 수치를 단정하지 않습니다(확인 필요).

자주 묻는 질문

도입 상담과 데모에서 받을 만한 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

과거근무원가는 어떻게 다시 계산합니까?

변경 후 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 파일에 있어 언어를 늘리는 일도 파일 하나를 더하는 작업입니다.