SAP 자금 솔루션 인건비 지급 자금 다차원 분석 — 지급 계획 대비 차이와 변동 사유까지 한 화면에서 (관련 기준서: - / 대상 영역: 자금 지급·자금 수지)

소개 영상블로그 목차 순서대로 · 자막 포함

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

월마감 때 자금 담당과 인사·총무가 마주치는 질문은 해마다 같습니다. 이번 달 인건비로 얼마가 나갔나, 계획보다 얼마나 더 나갔나, 왜 그랬고 아직 안 나간 돈은 얼마인가. 지금은 이 답이 표준 화면 여러 개와 급여 정산 자료, 은행 이체 결과, 엑셀로 흩어져 있고 숫자를 맞추는 일이 회의보다 앞섭니다. 이 앱은 세 답을 한 화면에 붙입니다. 지급 계획과 실제 지급을 같은 차원으로 놓고, 칸을 누르면 그 금액을 만든 지급 줄까지 내려가고, 차이는 일곱 요인으로 갈라 합계가 어긋나지 않는지 매번 검산합니다.

이 앱은 조회·점검 도구입니다. 회사의 지급 실행이나 회계 처리를 대신하지 않고, 점검할 자리를 추려 주는 데까지만 합니다. 관련 기준서: - / 대상 영역: 자금 지급·자금 수지 — 특정 회계기준서의 요구사항을 구현한 앱이 아니라 자금 지급과 자금 수지를 보는 업무 분석 앱이며, 표준 지급 실행(F110)과 은행 명세 처리(FEBAN)는 표준 화면이 계속 맡습니다.

한 줄 요약 — 지급 현황 조회는 표준 화면으로도 됩니다. 이 앱의 값은 조회 다음에 있습니다: 계획과의 차이를 요인으로 가르고, 사유를 행에 남기고, 사람이 열지 않아도 감시하고, 그 숫자가 원천 지급 줄과 어긋나지 않는지 매번 스스로 검산합니다.

핵심 포인트 일곱 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 합계가 갈라지지 않는 피벗	지급 유형 · 은행 · 지급 방식 · 직군 · 법인 같은 차원을 끌어다 놓아 행 3단계 · 열 2단계로 봅니다. 모든 축이 같은 큐브에서 나오므로 합계가 어긋날 자리가 없습니다.	은행별 · 유형별 · 직군별 리포트를 따로 만들고, 합계가 서로 다르면 어느 쪽이 맞는지 맞추는 회의를 엽니다.
② 칸에서 원천 지급 문서까지 한 번에	숫자를 누르면 그 칸을 만든 지급 줄이 열리고 합계가 칸 금액과 같은지 그 자리에서 보입니다.	리포트를 닫고 G/L 계정 개별 항목(FBL3N)을 다시 열어 조건을 손으로 맞춥니다.
③ 지급 계획 대비 차이를 일곱 요인으로	실지급액이 계획에서 얼마나 벌어졌는지를 인원 변동 · 단가 변동 · 소급·정산 · 상계 · 지급월 이동 · 계획 외 신규 지급 · 계획 지급 미발생으로 가릅니다.	엑셀로 요인을 나누고 합계가 총차이와 맞는지 다시 손으로 확인합니다.
④ 차이 사유가 행에 남는다	사유는 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도, 다음 달에도 그 행에 따라옵니다.	같은 질문을 매달 다시 하고 지난달 답은 메일함에서 찾습니다.
⑤ 사람이 열지 않아도 도는 감시	지연 지급 비중 · 소급·정산 반영 · 계획 차이 · 미이체 잔액 규칙마다 받을 사람이 붙어 있어 걸리면 대기함에 보고가 올라갑니다.	이체 마감을 넘긴 날 아무도 화면을 열지 않으면 그대로 지나갑니다.
⑥ 숫자는 모델에 맡기지 않는 해설	금액과 비율은 서비스가 큐브에서 계산하고 문장은 그 숫자를 읽어 줍니다. 모델을 꺼도 같은 근거로 규칙 기반 해설이 나옵니다.	요약 문장의 숫자를 누가 계산했는지부터 따져야 합니다.
⑦ 보는 사람별 첫 화면과 보기 저장	경영 · 재무 · 인사 · 자금 탭이 같은 큐브를 각자의 질문에 맞게 보여 주고, 짜 둔 배치는 이름을 붙여 저장해 둡니다.	사람마다 다른 엑셀 양식을 유지하고 매달 새로 만듭니다.

사례로 보는 효과 — 34억 차이는 어디서 났나

검증용 샘플 데이터(가상 법인 · 가상 은행)에서 9개월 실지급액은 959.87억 원으로 지급 계획 925.60억 원보다 34.27억 원(+3.7%) 많았습니다. 표준 화면은 여기까지를 말해 줍니다. 이 앱은 일곱 요인으로 가른 결과를 보여 줍니다. 가장 큰 요인은 계획 외 신규 지급 +52.62억이었고, 계획 지급 미발생 −33.27억이 일부를 상쇄했습니다. 인원 변동 +11.06억, 1인당 단가 변동 +1.78억, 소급·정산 반영 +2.91억, 가불·대여금 상계 −0.83억, 지급월 이동 0.00억을 모두 더하면 총차이 +34.27억과 같고, 화면의 검산 줄이 이 등식을 매번 적습니다.

지급 유형별로는 복리후생비가 계획보다 +7.30억(+25.4%) 많아 가장 두드러졌고, 지연 지급 비중은 8.1%로 규칙 임계(6%)를 넘어 점검 필요로 표시되었습니다. 이 숫자들은 샘플 데이터에서 나온 것이며, 회사의 실제 지급 현황을 뜻하지 않습니다. 원인의 판단은 숫자 옆에 변동 사유로 사람이 적습니다.

도입하면 달라지는 것

마감 보고 준비 — 차이 표 · 요인 분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 화면 캡처가 줄어듭니다.
회의의 주제 — “어느 숫자가 맞나”를 따지는 시간이 줄고 “계획 외 지급을 어떻게 볼 것인가”를 이야기하게 됩니다.
다음 달로 이어지는 기록 — 사유와 저장한 보기가 남아 같은 설명을 반복하지 않습니다.
놓치는 날이 없는 감시 — 아무도 화면을 열지 않아도 규칙에 걸린 항목이 받을 사람별 대기함에 올라갑니다.

이런 회사에 맞습니다

여러 법인이 여러 은행으로 급여 · 상여 · 퇴직연금 · 사회보험료 · 경비 정산을 나눠 지급하고, 지급 계획과 실제 지급의 차이를 월마다 설명해야 하는 자금 · 인사 · 총무 조직에 맞습니다. 특히 급여 정산과 은행 이체 사이에 미이체 잔액이 남거나 이체 마감을 넘겨 지연 지급이 생기는 회사, 소급분과 연말정산 정산분이 지급액을 흔드는 회사라면 “무엇이 계획과 달랐나”를 한 화면에서 답하는 쪽이 이득입니다. 반대로 지급 계획 자체가 없는 회사는 비교 기준을 “비교 없음”으로 두고 축 전환과 드릴스루만 먼저 쓰는 편이 맞습니다.

실행 화면

사용 방법

조회 조건 입력 — 위쪽 조회 조건 줄에서 법인(비우면 전체), 기간 부터·까지(필수), 비교 기준(지급 계획과 비교 / 비교 없음)을 고릅니다.
조회 — 오른쪽 위 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 기본 보기에 자동 조회를 켜 두면 화면을 열 때 바로 조회합니다.
요약 확인 — 실지급액 · 최대 지급 유형 비중 · 소급·정산 반영률 · 지연 지급 비중 · 계획 대비 차이 카드를 봅니다. 보는 사람 탭을 바꾸면 해설과 기본 배치가 바뀝니다.
축 이동 — 차원 보관함의 칩을 행 축 · 열 축으로 끌어다 놓거나 눌러 옮깁니다. 측정값 · 값 필터 · 금액 단위도 같은 줄에서 고릅니다.
행 · 칸 클릭 — 행을 고르면 요인 분해와 변동 사유를, 실적 칸을 누르면 원천 지급 줄을 봅니다.
내보내기 — 오른쪽 위 CSV 버튼으로 현재 표를, 해설 창에서 보고서(PPTX)를 내려받습니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
조회 화면	OpenUI5 표준 컨트롤(트리 표 · 다이얼로그 · 메시지 토스트)과 직접 그린 SVG 차트	외부 차트 라이브러리 반입 심사를 피하고, 내부망에서 CDN 이 막혀도 같은 화면이 나오게 하려는 선택입니다.
큐브 피벗 로직	브라우저에서 큐브를 다시 피벗하는 모델 파일, 차트 · 보고서 파일	축을 바꿀 때 서버를 다시 부르지 않아 응답이 빠르고, 어느 축에서나 합계가 같습니다.
집계 · 분해 · 해설 로직	서비스 쪽 로직 파일 한 벌(조회 · 단건 · 생성 · 수정 · 삭제 · 펑션 호출)	판단과 기록이 화면이 아니라 서비스에 있어서 배치가 같은 문을 두드릴 수 있고, 모델을 꺼도 숫자가 같습니다.
데이터 연결	OData V2 서비스 하나. 화면은 서비스를 한 번 읽어 큐브를 만들고 원천 줄은 조건과 쪽 나눔으로 읽으며, 쓰기는 사유 · 보기 · 대기함 · 실행 이력에 보냅니다.	서비스 경로와 엔티티 목록은 앱 설명서에 적어 두었습니다. 운영 전환 때는 서비스 주소만 바꾸면 됩니다.
테마	sap_horizon	표준 Fiori 와 같은 모양으로 보이게 하려는 선택입니다.

앱 정보

항목	내용
솔루션	자금 솔루션
업무 영역	인건비 지급 자금 · 계획 대비 지급 실적 분석
관련 기준서 · 대상 영역	기준서 지정 없음(-) · 대상 영역: 자금 지급 · 자금 수지
화면 성격	다차원 분석 리포트(조회 · 점검 도구)
연계 표준 T-code	FF7A · FF7B · FEBAN · FBL3N · F110
데이터 연동	OData V2(샘플 데이터로 시연)
테마	sap_horizon

SAP 표준 기능을 그대로 이어받은 부분 — 지급 실행은 표준 자동 지급 프로그램(F110)이, 은행 명세 확인은 FEBAN 이, 계정 개별 항목 확인은 FBL3N 이, 자금 잔액과 유동성 예측은 FF7A · FF7B 가 계속 맡습니다. 이 앱은 그 결과를 같은 차원으로 모아 계획과 견주고 점검할 자리를 추리는 관점만 더하며, 표준 화면의 데이터를 바꾸지 않습니다.

처음 열었을 때 — 조건을 고르고 조회를 누릅니다

화면을 열면 위쪽에 조회 조건, 그 아래에 요약 지표와 보는 사람 탭, 차원 보관함과 행·열 축, 표와 차트가 차례로 놓입니다. 조회를 누르기 전에는 표가 비어 있어 무엇을 먼저 해야 하는지 헷갈리지 않습니다.

조회 전 화면 — 조회 조건과 비어 있는 표 — **조회 전 — 조회조건과 빈 표** — 법인·기간·비교 기준을 고르고 조회를 누르면 시작합니다.

위쪽 조회 조건 줄에서 법인(비우면 전체), 기간 부터·까지, 비교 기준(지급 계획과 비교 / 비교 없음)을 고릅니다. 기간은 필수이고 기본값은 2026년 1월부터 9월까지입니다. 조회를 누르기 전에는 표와 차트 자리에 안내 문구만 보입니다.

조회 결과 — 요약 지표 카드와 지급 유형 표 — **조회 결과 — 요약 지표와 첫 표** — 실지급액 · 최대 지급 유형 비중 · 소급·정산 반영률 · 지연 지급 비중 · 계획 대비 차이가 먼저 보입니다.

카드 다섯 장이 지금 범위의 요약입니다. 이 자료에서는 실지급액 959.87억 원, 최대 지급 유형(급여) 비중 65.2%, 소급·정산 반영률 0.34%, 지연 지급 비중 8.1%, 계획 대비 +34.27억 원(+3.7%)입니다. 아래 표는 행 축에 지급 유형, 열 축에 분기가 올라와 있고 오른쪽 차트는 같은 값을 막대로 그립니다. 임계값을 넘은 카드는 색이 바뀌어 어디부터 볼지 알려 줍니다.

보는 사람에 따라 달라지는 첫 화면 — 경영 · 재무 · 인사 · 자금

같은 큐브를 보더라도 경영진, 재무, 인사, 자금 담당이 먼저 보고 싶은 값은 다릅니다. "보는 사람" 탭을 바꾸면 요약 지표의 해설과 기본 행·열 배치가 그 사람의 질문에 맞춰 바뀌고, 숫자 자체는 바뀌지 않습니다.

경영 탭 — 지급 유형별 분기 흐름 — **경영 — 전체 흐름을 분기로** — 가장 큰 지급 유형과 계획 대비 차이를 분기 열로 먼저 보여 줍니다.

경영 탭은 지급 유형별 실지급액을 분기 흐름으로 보여 주고, 요약 카드의 설명도 경영진이 묻는 말(얼마나 나갔고 계획보다 얼마나 더 나갔나)에 맞춥니다. 탭을 바꿔도 조회 범위와 큐브는 그대로라서 서버를 다시 부르지 않습니다.

재무 탭 — 상계와 소급·정산 반영률 — **재무 — 상계와 소급·정산을 함께** — 지급액에 얹히고 빠지는 항목을 나란히 놓습니다.

재무 탭은 실지급액과 함께 가불·대여금 상계, 소급·정산 반영률처럼 지급액을 움직이는 값을 열로 올립니다. 대상액에서 실지급액으로 가는 길을 한 표에서 확인하려는 사람에게 맞춘 배치입니다.

인사 탭 — 직군별 지급 인원과 1인당 실지급액 — **인사 — 직군별 인원과 1인당 지급액** — 직군을 행으로 두고 지급 인원과 1인당 실지급액을 봅니다.

인사 탭은 직군(임원 · 관리·사무직 · 생산·기술직 · 계약·파견직)을 행으로 올리고 지급 인원과 1인당 실지급액을 계산 항목으로 붙입니다. 지급 인원은 월별 대상 인원을 더한 연인원이므로 사람 수가 아니라 지급 횟수에 가까운 값입니다.

자금 탭 — 은행·지급 방식별 실지급액과 미이체 잔액 — **자금 — 은행·지급 방식과 지연 지급** — 이체가 어느 은행·방식으로 얼마나 나가고 얼마나 밀렸는지 봅니다.

자금 탭은 지급 은행과 지급 방식을 행으로 두고 실지급액, 기말 미이체 잔액, 지연 지급 비중을 보여 줍니다. 기말 미이체 잔액은 기간을 합쳐도 끝 기간의 값만 쓰기 때문에 월을 모두 더한 숫자가 나오지 않습니다.

축 전환과 범위 — 끌어다 놓으면 표가 다시 짜입니다

차원 보관함의 칩을 행 축이나 열 축으로 끌어다 놓거나 칩을 눌러 옮깁니다. 모든 축이 같은 큐브를 브라우저에서 다시 피벗할 뿐이라 서버를 다시 부르지 않고, 어느 축에서 보아도 합계가 갈라지지 않습니다.

행 축을 지급 은행으로 바꾼 화면 — **행 축 바꾸기 — 지급 은행을 행으로** — 칩을 옮기면 같은 큐브가 다른 모양으로 다시 짜입니다.

지급 은행 칩을 행 축으로 옮기면 은행 네 곳이 행이 되고 합계 행 아래에서 펼칠 수 있습니다. 칩의 X 를 누르면 차원이 보관함으로 돌아갑니다. 합계 행의 숫자는 축을 어떻게 바꿔도 같아야 하며 이 불변은 검증 항목에 들어 있습니다.

열 축을 분기와 지급 방식 두 단계로 놓은 화면 — **열 축 2단계 — 분기 아래에 지급 방식** — 열 머리가 두 단계로 나뉩니다.

열 축은 2단계까지 겹칠 수 있습니다. 분기 아래에 지급 방식을 놓으면 열 머리가 두 줄로 나뉘고 칸마다 그 조합의 실지급액이 들어갑니다. 열이 너무 많아지면 뒤에 나오는 범위 한도 안내가 대신 뜹니다.

지급 은행 값 필터 선택 창 — **값 필터 — 보고 싶은 값만 고르기** — 차원마다 값을 여러 개 골라 표를 줄입니다.

값 필터 창에서 차원을 고르고 값을 체크하면 표에 쓸 행이 줄어듭니다. 값 옆의 숫자는 그 값에 속한 원천 지급 라인 수입니다. 이 단계도 서버를 다시 부르지 않고 이미 읽은 큐브에서 걸러 냅니다.

지급 은행 두 곳으로 필터한 결과 — **필터 결과 — 조건 요약과 표가 함께 줄어듭니다** — 조건 요약에 "필터: 지급 은행 2" 처럼 적힙니다.

은행 두 곳만 고르면 요약 카드와 표, 차트가 모두 그 범위 값으로 다시 계산됩니다. 합계가 전체 합계와 달라진 이유는 조건 요약 줄에서 바로 읽힙니다. 필터를 풀면 원래 범위로 돌아옵니다.

표와 차트 사이 손잡이를 끈 화면 — **차트 손잡이 — 표와 차트의 너비를 나눕니다** — 표를 넓게 볼지 차트를 넓게 볼지 끌어서 정합니다.

표와 차트 사이의 손잡이를 끌면 두 영역의 너비가 바뀌고 그 값은 이 브라우저에 남습니다. 열이 많은 표를 볼 때는 차트를 좁히고 비중을 말로 설명할 때는 차트를 넓히는 식으로 씁니다.

칸에서 원천 문서까지 — 숫자를 누르면 그 금액을 만든 지급 줄이 열립니다

표의 숫자 칸(실적 열)을 누르면 그 칸의 조건이 그대로 조회 조건이 되어 원천 지급 라인을 보여 줍니다. 맨 위에는 건수와 합계, 그리고 합계가 눌렀던 칸 금액과 같은지가 표시됩니다.

합계 칸에서 연 원천 지급 문서 창 — **합계 칸 — 전체 지급 줄** — 합계 행의 칸을 누르면 범위 안 모든 줄이 쪽 나눔으로 열립니다.

합계 칸은 범위 전체의 지급 라인이므로 건수가 많아 500건씩 쪽을 나눠 읽습니다. 창 위쪽의 합계와 칸 금액이 같으면 일치 표시가 붙습니다. 오른쪽 아래의 CSV 버튼으로 이 창의 줄을 그대로 내려받습니다.

급여 칸에서 연 원천 지급 문서 창 — **지급 유형 칸 — 급여 줄만** — 행 경로가 조건으로 따라옵니다.

급여 행의 칸을 누르면 지급 유형이 급여인 줄만 열립니다. 문서 번호, 지급일, 은행, 지급 방식, 지급일 대비, 대상액, 소급·정산, 상계 같은 컬럼이 한 줄에 나와 표준 화면에서 다시 찾을 때 쓸 단서가 됩니다.

하위 행 칸에서 연 원천 지급 문서 창 — **하위 행 칸 — 조건이 더 좁아집니다** — 행을 펼친 뒤 누르면 그 경로의 줄만 보입니다.

행을 펼쳐 은행이나 방식까지 내려간 칸을 누르면 조건이 더 좁아져 줄 수가 줄어듭니다. 세 곳을 눌러 본 결과 창의 합계가 칸 금액과 모두 일치했고 이 확인도 검증 표에 들어 있습니다.

기간 축과 계산 항목 — 월별 흐름과 1인당 값

회계기간(지급월)을 행으로 올리면 월별 흐름이 보이고, 계산 항목은 기본 측정값 둘을 식으로 이어 만든 지표를 표에 나란히 둡니다. 계산 항목은 칸마다 분모와 분자를 먼저 합친 뒤 나누므로 비율의 평균이 아니라 합의 비율입니다.

회계기간을 행으로 올린 화면 — **회계기간 축 — 월별 흐름** — 지급월을 행으로 올려 월마다 실지급액을 봅니다.

회계기간 칩을 행 축에 놓으면 1월부터 9월까지가 행이 됩니다. 월별 실지급액이 지급 유형 열과 함께 보이고 차트는 월마다 막대를 그립니다. 기말 미이체 잔액처럼 기간을 합치지 않는 측정값은 이 축에서 월말 값이 그대로 보입니다.

직군별 1인당 실지급액과 반영률 — **계산 항목 — 1인당 실지급액과 소급·정산 반영률** — 기본 측정값에서 식으로 만든 지표입니다.

1인당 실지급액(실지급액 ÷ 지급 인원)과 소급·정산 반영률(소급·정산 ÷ 지급 대상액) 같은 값을 직군 행에 나란히 보입니다. 계산 항목의 식은 서비스에 정의가 있어 화면이 임의로 바꾸지 않습니다.

지급 계획 대비 차이 — 같은 표가 월마감 점검표가 됩니다

비교 기준을 지급 계획으로 두면 같은 표의 칸마다 실적 · 계획 · 차이 · 차이율이 나란히 붙습니다. 금액 기준과 비율 기준을 둘 다 넘은 칸만 색을 입혀, 모든 칸이 붉게 물드는 일을 피합니다.

계획 차이 모드의 표와 차트 — **차이 모드 — 실적 · 계획 · 차이 · 차이율** — "계획 차이" 스위치를 켭니다.

스위치를 켜면 열이 실적, 계획, 차이, 차이율로 바뀌고 차트도 실적과 계획을 짝으로 그립니다. 이 자료의 합계는 실적 959.87억, 계획 925.60억, 차이 +34.27억(+3.7%)입니다. 금액 기준과 비율 기준은 표 위에서 바로 고칩니다.

기준을 넘은 칸만 색이 입혀진 차이 표 — **차이 색 — 기준을 넘은 칸만** — 기본 기준은 0.3억 원과 5%입니다.

|차이|가 금액 기준 이상이고 |차이율|도 비율 기준 이상인 칸만 붉은 글씨(계획보다 증가)나 초록 글씨(감소)로 칠합니다. 이 자료에서는 복리후생비가 +7.30억(+25.4%)으로 가장 두드러집니다. 색은 점검할 자리를 추리는 용도이며 원인을 단정하지 않습니다.

변동 사유 입력 창 — **변동 사유 — 점검 필요 행에 이유를 적습니다** — 행을 고르고 "변동 사유"를 누릅니다.

구분을 고르고 사유를 적어 저장합니다. 사유의 열쇠는 축 배치가 아니라 조회 범위와 행 경로라서 축을 바꾸거나 트리를 다시 펼쳐도 같은 행에 따라옵니다. 적은 사람의 역할과 시각이 함께 남습니다.

변동 사유가 저장된 화면 — **사유 저장 — 표에 표시가 붙습니다** — 저장하면 그 행에 사유가 있다는 표시가 붙습니다.

저장 직후 알림이 뜨고 행에는 사유가 있다는 표시가 붙습니다. 사유는 서비스에 저장되므로 다음 달에도, 다른 사람이 열어도 같은 범위에서는 그대로 보입니다. CSV 와 해설의 근거 표에도 함께 실립니다.

요인 분해 — 계획과 실적 사이를 일곱 요인으로 가릅니다

차이 행을 누르면 오른쪽에 폭포 차트와 요인 표가 나옵니다. 계획 지급액에서 실적 실지급액까지를 인원 변동 · 1인당 단가 변동 · 소급·정산 반영 · 가불·대여금 상계 · 지급월 이동 · 계획 외 신규 지급 · 계획 지급 미발생으로 나누고, 맨 아래 검산 줄이 합계를 맞춰 봅니다.

일곱 요인으로 나눈 폭포 차트 — **요인 분해 — 폭포 차트와 검산** — 차이 행을 누르면 오른쪽에 나옵니다.

계획 지급액 925.60억에서 시작해 요인을 하나씩 더하고 빼면 실적 959.87억에 닿습니다. 이 자료에서 가장 큰 요인은 계획 외 신규 지급(+52.62억)이고, 계획 지급 미발생(−33.27억)이 그 일부를 상쇄합니다. 표 아래 검산 줄은 계획 + 요인 합 − 실적이 0인지 매번 적습니다.

합계 행의 요인 표와 검산 줄 — **합계 행 — 요인 표를 끝까지** — 합계 행을 선택하면 막대가 가장 또렷합니다.

합계 행을 고르면 요인별 금액이 표로 내려옵니다. 인원 변동 +11.06억, 1인당 단가 변동 +1.78억, 소급·정산 반영 +2.91억, 가불·대여금 상계 −0.83억, 지급월 이동 0.00억입니다. 행 하나를 고르면 막대가 작아질 수 있으니 합계 행에서 큰 그림을 먼저 보시기를 권합니다.

해설과 근거 — 문장은 모델이, 숫자는 서비스가

"해설" 창은 지금 범위를 요약하고 점검 필요 항목을 규칙으로 정리합니다. 금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고 문장만 읽어 줍니다. 모델 연결은 기본 꺼짐이며, 꺼져 있어도 같은 근거로 규칙 기반 해설이 나옵니다.

해설 창 — 범위 요약과 점검 필요 항목 — **해설 — 범위 요약과 점검 필요 항목** — 지금 보고 있는 범위의 말 정리입니다.

범위 요약 아래에 "점검 필요"로 걸린 항목이 금액과 함께 나열됩니다. 문장에는 판단이 아니라 확인할 자리가 적히고, 원인을 단정하는 표현은 쓰지 않습니다. 같은 창에서 보고서(PPTX)를 내려받을 수 있습니다.

해설 근거 표 — **해설 근거 — 문장에 쓴 숫자의 출처** — 해설 맨 아래 근거 표에 계획 · 실적 · 차이가 묶음별로 나옵니다.

해설이 인용한 숫자는 근거 표에서 묶음별 계획, 실적, 차이로 다시 볼 수 있습니다. 문장과 표의 숫자가 다르면 표가 맞다고 보시면 됩니다. 변동 사유를 적어 둔 행은 그 사유도 근거에 함께 실립니다.

에이전트 — 사람이 열지 않아도 도는 점검

감시 규칙 네 가지가 서비스에 있고, 실행하면 걸린 항목이 받을 사람별로 대기함에 올라갑니다. 판단과 기록은 화면이 아니라 서비스에 있어서 정해진 주기에 배치가 같은 문을 두드릴 수도 있습니다.

에이전트 감시 규칙 창 — **감시 규칙 — 규칙이 곧 받을 사람** — 규칙마다 임계값과 받을 사람이 붙어 있습니다.

지연 지급 비중 상한(자금 담당, 6% 이상), 소급·정산 반영 임계(인사, 3억 원 이상), 실지급액 계획 차이 임계(재무, 5억 원 이상), 기말 미이체 잔액 상한(경영, 8억 원 이상)의 네 규칙입니다. 임계값은 샘플의 가정값이며 회사 기준에 맞춰 조정합니다.

에이전트 실행 결과와 대기함 — **실행과 대기함 — 걸린 항목이 올라옵니다** — 실행 결과가 받을 사람별 보고로 쌓입니다.

"지금 실행"을 누르면 규칙을 판정해 걸린 항목을 대기함에 올리고 실행 이력에 남깁니다. 이 자료에서는 최근 기간 실지급액 계획 차이 규칙이 걸려 보고가 올라왔습니다. 보고에는 심각도와 제목, 받을 사람의 눈으로 다시 적은 본문이 담깁니다.

하루 한 번 제한 안내 — **하루 한 번 — 같은 날 두 번째는 제한 안내** — 서버가 제한을 판정해 돌려줍니다.

같은 날 다시 실행하면 서버가 하루 한 번 제한을 알리고 새 보고를 만들지 않습니다. 사람이 버튼을 누르는 경우와 배치가 부르는 경우가 같은 제한을 받아 같은 날 같은 보고가 쌓이지 않습니다.

보기 저장과 범위 한도 — 짜 둔 배치를 이름 붙여 둡니다

맞춰 둔 축 배치, 필터, 금액 단위를 이름을 붙여 저장해 두면 다음에 그 배치로 열 수 있습니다. 기본 보기와 자동 조회를 지정하면 화면을 열자마자 조회까지 끝납니다.

보기 저장 창 — **보기 저장 — 현재 배치에 이름을 붙입니다** — 기본 보기 · 자동 조회를 함께 정할 수 있습니다.

이름을 적고 저장하면 현재 행·열 축과 필터, 측정값이 한 벌로 남습니다. 기본 보기로 지정하면 다음에 열 때 그 배치로 시작하고, 자동 조회를 켜면 조회 버튼을 누르지 않아도 됩니다.

저장한 보기 관리 창 — **보기 관리 — 적용 · 기본 지정 · 이름 바꾸기 · 삭제** — 저장한 보기를 한 목록에서 다룹니다.

목록에서 보기를 적용하거나 기본으로 지정하고, 이름을 바꾸거나 지웁니다. 보기는 서비스에 저장되므로 브라우저를 바꿔도 따라옵니다.

저장한 보기를 복원한 화면 — **복원 — 저장한 배치로 되돌립니다** — "기본 배치로 되돌렸습니다" 알림이 뜹니다.

배치를 이리저리 바꾼 뒤에도 저장한 보기를 적용하면 그때의 축과 필터로 돌아옵니다. 처음 상태로 돌리고 싶으면 기본 배치 복원을 씁니다.

열 한도를 넘었을 때의 안내 화면 — **범위 한도 — 열이 너무 많으면 그리지 않습니다** — 열이 36개를 넘으면 안내만 뜹니다.

회계기간(9)과 지급 방식(5)을 열로 겹치면 45열이 되어 한도 36을 넘습니다. 이때는 표를 억지로 그리지 않고 열 축을 줄이라고 안내합니다. 행이 300을 넘을 때도 같습니다. 큰 표를 그리다 브라우저가 멈추는 일을 미리 막는 장치입니다.

좁은 화면 — 휴대폰에서도 같은 리포트

창이 좁아지면 차트를 감추지 않고 표 아래로 내려 같은 기능을 그대로 씁니다. 390px 폭에서도 가로로 넘치는 곳이 없도록 확인했습니다.

390px 폭의 모바일 화면 — **390px 폭 — 한 줄로 쌓입니다** — 조회 조건 · 요약 카드 · 차원 보관함이 위에서 아래로 놓입니다.

요약 카드는 두 줄로 접히고 축 보관함과 행·열 축은 세로로 쌓입니다. 표가 넓으면 표 안에서만 가로로 밀리고 화면 전체는 흔들리지 않습니다. 모든 기능은 같은 버튼으로 쓸 수 있습니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스에서 큐브(실적)와 계획 큐브를 한 번 읽습니다. 큐브는 지급월 · 법인 · 은행 · 지급 유형 · 지급 방식 · 직군 · 지급일 대비 · 처리 단계 · 공제 상계의 아홉 축으로 미리 집계한 값이고, 이 자료에서는 원천 지급 줄 2,569줄이 실적 큐브 1,909행과 계획 큐브 1,833행이 됩니다. 이후 축을 옮기거나 필터를 바꾸는 일은 모두 브라우저가 이 큐브를 다시 피벗하는 일이라 서버를 부르지 않습니다. 칸을 누를 때만 원천 줄을 조건과 쪽 나눔(500건)으로 읽고, 차이 행의 요인 분해와 해설, 에이전트 실행은 서비스의 펑션이 계산합니다.

점검 판정 규칙 — 조건에서 사용자 조치까지

판정 조건	결과 상태	사용자 조치
범위 안 지급 월의 지연 지급 실지급액 ÷ 실지급액 합계 ≥ 6%	지연 지급 비중 상한 초과 — 점검 필요	이체 마감 시각과 결재 대기 건을 확인합니다
최근 지급 월 소급·정산 반영 합계 ≥ 3억 원	소급·정산 반영 임계 초과 — 점검 필요	소급이 몰린 직군 · 법인 · 지급 유형을 보고 사유를 남깁니다
최근 지급 월 \|실지급액 − 계획 지급액\| ≥ 5억 원	계획 차이 임계 초과 — 점검 필요	요인 분해로 일곱 요인 중 큰 요인을 확인합니다
최근 지급 월 기말 미이체 잔액 ≥ 8억 원	미이체 잔액 상한 초과 — 점검 필요	지급 일정과 자금 여력을 확인합니다
차이 모드에서 \|차이\| ≥ 금액 기준(0.3억 원)이고 \|차이율\| ≥ 비율 기준(5%)	붉은 글씨(증가) · 초록 글씨(감소)	행을 눌러 요인 분해와 변동 사유로 갑니다
계획 + 일곱 요인 합 − 실적 ≠ 0	검산 줄이 붉게 바뀜 — 확인 필요	조회 범위와 원천 대사 결과를 확인합니다

임계값과 기준은 샘플의 가정값이며 회사 기준에 맞춰 조정합니다. 판정은 점검 대상을 추리는 용도이며 원인을 단정하지 않습니다.

대사식 — 숫자를 어떻게 검산하나

식	내용
① 큐브 = 원천	각 지급 월 · 측정값별로 큐브 합계와 원천 지급 줄 합계가 같아야 합니다. 월별 결과는 대사 결과 목록에 남습니다.
② 칸 = 원천 문서 합	표의 한 칸을 누르면 그 칸 조건으로 원천 줄을 읽어 합계를 칸 값과 견줍니다(합계 행 포함).
③ 계획 + 요인 = 실적	계획 지급액 + 인원 변동 + 1인당 단가 변동 + 소급·정산 반영 + 가불·대여금 상계 효과 + 지급월 이동 + 계획 외 신규 지급 + 계획 지급 미발생 = 실적 실지급액. 검산 줄에 차이를 보여 줍니다.
④ 실지급액 식	실지급액 = 지급 대상액 + 소급·정산 반영 − 가불·대여금 상계. 원천 줄마다 성립해야 하며 모든 줄에서 검사합니다.
⑤ 합계 = 하위 합	행 축을 펼쳤을 때 하위 행의 합이 상위 행과 같습니다(여러 값 선택 합계 포함).

조회조건

필드	필수 여부	기본값	쓰임
법인	선택(비우면 전체)	전체	서버에서 읽을 범위
기간(부터)	필수	2026년 01월	지급월 조건 — 서버에서 읽을 범위
기간(까지)	필수	2026년 09월	지급월 조건 — 서버에서 읽을 범위
비교 기준	선택	지급 계획과 비교	계획 큐브를 함께 읽을지 정함
값 필터	선택	없음	브라우저에서 큐브를 걸러 냄(서버 호출 없음)

결과 컬럼

컬럼	의미 · 산출식	합산 방식
실지급액	지급 대상액 + 소급·정산 반영 − 가불·대여금 상계	합산(기간을 합치면 더함)
지급 대상액	지급 결의된 급여 · 상여 등 총액(상계 전)	합산
소급·정산 반영	임금 소급분 · 연말정산 정산분 등 지급액에 더해진 금액(음수는 차감)	합산
가불·대여금 상계	지급액에서 차감한 가불금 · 사내 대여금 상계분	합산
기말 미이체 잔액	지급 결의 후 월말까지 이체하지 않은 금액	기간을 합쳐도 끝 기간의 값만 사용
지급 인원(연인원)	월별 지급 대상 인원을 더한 값	합산
1인당 실지급액	실지급액 ÷ 지급 인원	계산 항목
소급·정산 반영률	소급·정산 반영 ÷ 지급 대상액 × 100	계산 항목
가불·대여금 상계율	상계 ÷ 지급 대상액 × 100	계산 항목
지연 지급 비중 · 조기 지급 비중	지급일 대비 지연(조기) 지급분 실지급액 ÷ 실지급액 × 100	계산 항목
지급 비중	실지급액 ÷ 전체 실지급액 × 100	계산 항목

좁은 화면에서 달라지는 것

창이 좁아지면 이 앱은 차트를 감추지 않고 표 아래로 내려 쌓고 요약 카드를 두 줄로 접습니다. 표는 안에서만 가로로 밀리며 390px 폭에서 화면 전체의 가로 흔들림이 없는 것을 확인했습니다. 열이 36개를 넘거나 행이 300개를 넘으면 표를 그리지 않고 안내만 띄우는 한도는 폭과 무관하게 같습니다.

파일 구성

(앱 폴더)/                  앱 폴더
├─ index.html · Component.js · manifest.json
├─ view/        Main.view.xml · fragments/(조회 조건 · 값 필터 · 원천 문서 · 변동 사유 · 해설 · 에이전트 · 보기 저장)
├─ controller/  Main.controller.js
├─ model/       cube.js(피벗) · chart.js(SVG 차트) · pptx.js(보고서) · layout.js(보기) · formatter.js · ErrorHandler.js
├─ odata/       서비스 메타데이터 · service.js · calc.js · 샘플 데이터(json)
├─ i18n/ · css/
├─ media/       소개 영상 · 포스터 · 재생 지점
└─ readme.html  앱 설명서

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래 표는 표준 화면으로 충분한 일과 이 앱이 더하는 관점을 나란히 놓은 것입니다.

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

하고 싶은 일	SAP 표준	표준에서 걸리는 자리	이 앱이 하는 일
지급 현황을 여러 각도로 보기	지급 전표 개별 항목 조회(FBL3N) · 급여 정산 결과	각도마다 화면과 조건을 따로 열어야 하고 합계를 직접 맞춥니다	같은 큐브에서 축만 바꾸고 합계는 늘 같습니다
지급 계획과 실적 비교	자금 계획 · 유동성 예측(FF7B) 항목	계획과 실적을 읽는 화면이 갈라져 있어 같은 차원으로 나란히 놓기 어렵습니다	계획 큐브를 같은 차원으로 얹고 차이를 칸마다 보입니다
지급 실행	자동 지급 프로그램(F110)	—(표준이 하는 일입니다)	실행하지 않습니다. 실행 결과를 점검하는 쪽입니다
이체 결과 확인	은행 명세 조회 · 후처리(FEBAN)	명세 줄과 지급 줄을 사람이 대조합니다	미이체 잔액과 지연 지급 비중을 범위별로 보여 줘 어디를 대조할지 추립니다
은행 · 계좌별 잔액	현금 포지션(FF7A)	지급 이후의 잔액 화면이라 지급 구성과 이어 보기 어렵습니다	지급을 은행 · 방식으로 나눠 보고 FF7A 에서 잔액을 이어 확인합니다
차이의 원인 분해	없음(확인 필요)	표준 화면에서 요인을 나눠 주는 기능을 확인하지 못했습니다. 보통 엑셀로 만듭니다	일곱 요인으로 가르고 합계를 검산합니다
차이 사유 기록	전표 적요	전표 단위라 집계 행에는 붙일 자리가 없습니다	조회 범위와 행 경로를 열쇠로 남깁니다

T-code 별 연계 지점

T-code	이름	이어받는 데이터와 대사 지점	표준에 남겨 둘 일
FF7A	현금 포지션	지급 이후의 은행 · 계좌별 자금 잔액 이 앱의 은행별 실지급액과 미이체 잔액을 FF7A 의 잔액 변동과 견줍니다. 원천은 은행 계정 잔액 계열 테이블(확인 필요)입니다.	자금 포지션 · 유동성 보고는 표준에 그대로 둡니다.
FF7B	유동성 예측	지급 계획이 자금 예측에 반영됐는지 이 앱의 계획 큐브와 FF7B 의 예측 항목을 맞춰 봅니다. 계획 원천 항목은 확인 필요입니다.	유동성 예측 관리는 표준에 둡니다.
FEBAN	은행 명세 조회 · 후처리	이체된 지급이 은행 명세로 확인되는지 이 앱에서 지연 지급 비중이나 미이체 잔액이 걸린 범위를 FEBAN 의 명세 줄과 대조합니다.	은행 명세 후처리는 표준에서 합니다.
FBL3N	G/L 계정 개별 항목	급여 · 상여 등 인건비 계정의 지급 전표 칸을 눌러 연 원천 줄의 합계를 FBL3N 의 계정 개별 항목 합계와 견줍니다. 같은 전표 헤더 · 라인 테이블(BKPF · BSEG · ACDOCA)을 읽습니다.	전표 조회 · 감사 대응은 표준에서 합니다.
F110	자동 지급 프로그램	지급 실행 건의 대상 · 결과 지급 실행 이력(REGUH · REGUP)과 이 앱의 지급 줄 건수를 맞춰 봅니다.	지급 실행은 표준에서만 합니다. 이 앱은 실행하지 않습니다.

운영 전환 때 자주 나오는 질문은 “기존 리포트를 없애야 하나”입니다. 답은 없애지 않는다입니다. 법정 · 감사 · 세무 신고에 쓰는 숫자와 지급 실행은 표준 거래에 그대로 두고, 이 앱은 월마감 전에 차이를 설명하고 점검할 자리를 추리는 용도로 나란히 씁니다. 두 화면의 숫자가 다를 때는 위 표의 대사 지점에서 먼저 맞춰 봅니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, 스프레드시트 연동 도구가 이미 있습니다. 이 앱은 그것들을 대체하지 않고 같은 모델 방식(기준 → 차원 → 큐브 → 쿼리 → 권한)으로 쌓은 CDS 뷰를 서비스로 열어 두 가지를 더합니다. 하나는 계획 큐브를 같은 차원에 얹어 차이와 요인 분해까지 한 화면에 두는 것, 다른 하나는 사유 · 보기 · 대기함 같은 쓰기 자료를 서비스에 두는 것입니다. 회사가 이미 쓰는 표준 분석 앱이 있다면 이 앱의 큐브와 쿼리를 그 앱의 데이터 원천으로 열어 줄 수도 있으며, 어느 표준 앱이 맞는지는 확인 필요입니다.

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

자리	무엇을 정하나	정하지 않으면	누가
계정 → 지급 유형 · 직군 매핑	인건비 계정을 어느 지급 유형 · 직군으로 볼지 매핑 테이블에 적습니다	계정이 새로 생기면 리포트 숫자가 기존 보고서와 어긋납니다	현업(자금 · 인사)
하우스 뱅크 · 지급 방법 필드	지급 은행과 지급 방식을 읽을 필드 위치(확인 필요)	은행 · 방식 축이 비어 보입니다	자금 · 개발
약정 지급일	지연 지급을 판정할 기준 일자의 원천(확인 필요)	지연 지급 비중이 의미를 잃습니다	자금
계획 버전	어느 계획 범주 · 버전을 비교 기준으로 쓸지	“예산이 왜 이 숫자냐”가 반복됩니다	기획
확장 필드 · BAdI	급여 정산 인원 · 소급 구분처럼 표준에 없는 필드를 큐브에 얹을 때	필드를 읽지 못해 측정값이 0 으로 나옵니다	개발
권한	법인 · 코스트센터 같은 표준 권한 객체를 집계 단계에 걸 방식	드릴스루에만 걸면 합계에서 남의 숫자가 새어 나옵니다	보안 · 권한

분석 지표 정의

지표	산식	판정 기준	대응 기능	원천 데이터	비고
실지급액	지급 대상액 + 소급·정산 반영 − 가불·대여금 상계	—	지급 유형별 합계 · 열 축 · 계획 차이	지급 전표 금액 또는 급여 정산 결과(확인 필요)	샘플 값
지급 계획 대비 차이	실적 실지급액 − 계획 실지급액	\|차이\| ≥ 금액 기준이고 \|차이율\| ≥ 비율 기준	차이 모드 · 요약 카드	계획 버전(확인 필요)	기본 0.3억 원 · 5%
최대 지급 유형 비중	가장 큰 지급 유형 실지급액 ÷ 합계	—	요약 카드 · 해설	큐브	집중도 지수 병기
소급·정산 반영률	소급·정산 반영 ÷ 지급 대상액	—	계산 항목	큐브	—
지연 지급 비중	지급일 대비 “지연 지급” 실지급액 ÷ 합계	≥ 6% 점검 필요	요약 카드 · 에이전트 규칙	지급일 − 약정 지급일(확인 필요)	샘플 가정값
1인당 실지급액	실지급액 ÷ 지급 인원(연인원)	—	계산 항목	급여 정산 인원(확인 필요)	—
기말 미이체 잔액	지급 결의 후 월말까지 이체하지 않은 금액(끝 기간만)	≥ 8억 원 점검 필요	요약 카드 · 에이전트 규칙	처리 단계 “지급 결의·미이체”	집계 방식 LAST

CDS 구성 — 코드와 운영 작업까지

기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스 순서로 쌓는 구성입니다. 이름과 필드는 예시이며, 확인하지 못한 필드 위치는 주석에 확인 필요로 적었습니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	`ZPAY_ACCMAP`	계정 → 지급 유형 · 직군 매핑 테이블	계정과 분류의 연결을 코드가 아니라 데이터로 두어 현업이 직접 고칩니다
기준	`ZI_PayCashLine`	원천 지급 줄을 한 모양으로 읽는 기본 뷰	표준 테이블 구조 변화를 이 뷰 한 곳에서 흡수합니다
차원	`ZI_PayBank`	지급 은행 차원 뷰(텍스트 연결)	코드와 이름을 분리해 화면 머리글을 이름으로 보이게 합니다
큐브	`ZI_PayCashCube`	실적 큐브(측정값 6 · 차원 9)	집계를 한 곳에 모아 어느 쿼리에서도 합계가 같게 합니다
큐브	`ZI_PayPlanCube`	계획 큐브(같은 차원)	계획과 실적이 같은 차원을 쓰도록 강제합니다
쿼리	`ZC_PayCashQuery`	분석 쿼리(행 · 열 · 필터 정의)	화면이 부르는 단 하나의 읽기 창구입니다
권한	`ZPAY_CASH_ROLE`	DCL — 법인 단위 접근 제어	집계 단계에 걸어 드릴스루와 합계가 같은 규칙을 따르게 합니다
서비스	`ZUI_PayCash`	서비스 정의 · 바인딩	화면이 보는 OData 서비스를 한 곳에서 게시합니다

① 계정 매핑 테이블 — 분류를 데이터로

인건비 계정이 어느 지급 유형(급여 · 상여·성과급 · 퇴직금·퇴직연금 · 4대보험 사업주분 · 경비·출장비 정산 · 복리후생비)이고 어느 직군인지는 코드가 아니라 데이터로 둡니다. 계정이 새로 생겨도 이 표에 한 줄을 적으면 되고, 적지 않으면 리포트 숫자가 기존 보고서와 어긋납니다. 계정 값은 예시이며 회사 계정과목에 맞춰 바꿉니다.

@EndUserText.label : '인건비 계정 → 지급 유형 · 직군 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpay_accmap {
  key client  : abap.clnt not null;
  key ktopl   : ktopl not null;     " 계정과목표
  key racct   : racct not null;     " 계정
  paytype     : abap.char(2);       " 01 급여 · 02 상여 · 03 퇴직 · 04 사회보험 · 05 경비 정산 · 06 복리후생
  staff       : abap.char(2);       " 직군 — 비우면 직군 구분 없음
  valid_from  : abap.dats;
  valid_to    : abap.dats;
}

② 기본 뷰 — 지급 줄을 한 모양으로

원천 줄을 한 모양으로 읽는 뷰입니다. 이 앱의 원천은 회계 전표 헤더 · 라인과 총계정원장 라인이며, 지급 은행(하우스 뱅크)과 지급 방법 필드가 놓인 테이블과 위치는 확인 필요라서 주석에 자리만 표시했습니다. 나중에 구조가 바뀌어도 이 뷰만 고치면 위쪽 큐브는 그대로 갑니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '지급 줄 기본 뷰'
define view entity ZI_PayCashLine
  as select from acdoca as a
  left outer join zpay_accmap as m
    on  m.racct = a.racct
{
  key a.rldnr                         as Ledger,
  key a.rbukrs                        as CompanyCode,
  key a.gjahr                         as FiscalYear,
  key a.belnr                         as DocNo,
  key a.docln                         as DocLine,
      a.budat                         as PostingDate,
      substring(a.budat, 1, 6)        as Period,
      m.paytype                       as PayType,
      m.staff                         as Staff,
      // 하우스 뱅크 · 지급 방법 · 약정 지급일은 필드 위치 확인 필요 — 아래는 자리 표시
      cast( '' as abap.char(5) )      as HouseBank,
      cast( '' as abap.char(2) )      as PayMethod,
      @Semantics.amount.currencyCode : 'Currency'
      a.hsl                           as AmountInLocal,
      a.rhcur                         as Currency
}
where a.rldnr = '0L'                  // 선행 원장 — 회사 기준 원장에 맞춰 변경

③ 차원 뷰 — 지급 은행

차원은 코드와 이름을 나눠 둡니다. 화면 머리글에는 코드가 아니라 이름이 보여야 하고, 이름은 언어에 따라 달라지기 때문입니다. 은행 이름은 하우스 뱅크 마스터에서 읽는 것을 전제로 하며 테이블 이름은 확인 필요입니다.

@ObjectModel.representativeKey : 'HouseBank'
@Analytics.dataCategory : #DIMENSION
@EndUserText.label : '지급 은행'
define view entity ZI_PayBank
  as select from t012
{
  @ObjectModel.text.element : ['BankName']
  key bukrs        as CompanyCode,
  key hbkid        as HouseBank,
      @Semantics.text : true
      cast( hbkid as abap.char(40) ) as BankName   // 이름 필드는 확인 필요
}

④ 실적 큐브 — 합계가 갈라지지 않는 자리

측정값을 한 번만 정의하고 모든 쿼리가 이 큐브를 읽습니다. 실지급액 식은 원천 줄마다 성립해야 하므로 큐브에 넣지 않고 줄 단계에서 계산해 합산합니다. 기말 미이체 잔액은 기간을 합쳐도 끝 기간 값만 쓰는 측정값이라 합산 방식을 따로 선언해야 합니다.

@Analytics.dataCategory : #CUBE
@VDM.viewType : #COMPOSITE
@EndUserText.label : '인건비 지급 실적 큐브'
define view entity ZI_PayCashCube
  as select from ZI_PayCashLine as l
  association [0..1] to ZI_PayBank as _Bank
    on  $projection.CompanyCode = _Bank.CompanyCode
    and $projection.HouseBank   = _Bank.HouseBank
{
  key l.CompanyCode,
  key l.FiscalYear,
  key l.DocNo,
  key l.DocLine,
      l.Period,
      l.PayType,
      l.Staff,
      l.HouseBank,
      l.PayMethod,
      _Bank,
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      l.AmountInLocal                       as PayAmount,
      l.Currency,
      @DefaultAggregation : #SUM
      1                                     as LineCount
}

⑤ 계획 큐브 — 실적과 같은 차원

계획 큐브가 실적과 같은 차원 이름을 쓰는 것이 차이 계산의 전제입니다. 계획 원천(범주 · 버전)은 회사마다 달라 확인 필요이며, 아래는 계획 테이블을 읽는다는 가정의 뼈대입니다.

@Analytics.dataCategory : #CUBE
@EndUserText.label : '인건비 지급 계획 큐브'
define view entity ZI_PayPlanCube
  as select from acdocp as p
{
  key p.rbukrs                              as CompanyCode,
  key p.gjahr                               as FiscalYear,
  key p.racct                               as Account,
      p.versn                               as PlanVersion,   // 계획 버전 — 확인 필요
      @Semantics.amount.currencyCode : 'Currency'
      @DefaultAggregation : #SUM
      p.hsl                                 as PlanAmount,
      p.rhcur                               as Currency
}

⑥ 분석 쿼리 — 화면이 부르는 단 하나의 창구

화면은 이 쿼리만 읽습니다. 조회 조건(법인 · 기간)은 필수 필터로 두어 전체 범위를 한 번에 읽는 일을 막고, 행 · 열에 올릴 차원과 측정값 이름은 여기서 정합니다.

@Analytics.query : true
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '인건비 지급 분석 쿼리'
define view entity ZC_PayCashQuery
  as select from ZI_PayCashCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @AnalyticsDetails.query.displayHierarchy : #ON
  PayType,
  @AnalyticsDetails.query.axis : #COLUMNS
  Period,
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  CompanyCode,
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  Period                                    as PeriodFilter,
  Staff,
  HouseBank,
  PayMethod,
  @AnalyticsDetails.query.axis : #COLUMNS
  PayAmount,
  LineCount
}

⑦ 권한(DCL) — 합계 단계에서 거릅니다

권한을 드릴스루 화면에만 걸면 “전체 합계 − 보이는 합계”로 남의 숫자를 거꾸로 계산할 수 있습니다. 그래서 집계 단계(쿼리)에 걸어 합계와 드릴스루가 같은 규칙을 따르게 합니다. 권한 객체와 필드는 회사 설계에 맞춰 확인해야 합니다.

@EndUserText.label : '인건비 지급 분석 — 법인 단위 접근'
@MappingRole : true
define role ZPAY_CASH_ROLE {
  grant select on ZC_PayCashQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 보는 문

쿼리를 OData 서비스로 열어 둡니다. 서비스 활성화(게이트웨이 서비스 관리 또는 서비스 바인딩 게시)와 화면 설정의 서비스 주소 교체는 아래 운영 표에 따로 적었습니다.

@EndUserText.label : '인건비 지급 분석 서비스'
define service ZUI_PayCash {
  expose ZC_PayCashQuery as PayCash;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않으면 코드가 맞아도 첫 회의에서 막힙니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
계정 → 지급 유형 · 직군 매핑 채우기	어느 계정이 어느 지급 유형 · 직군인가	리포트 숫자가 기존 보고서와 어긋나 첫 회의에서 막힙니다	회계 · 인사
지급 은행 · 지급 방법 필드 확정	하우스 뱅크와 지급 방법을 어느 테이블 · 필드에서 읽나	은행 · 방식 축이 비어 보입니다	자금 · 개발
약정 지급일 원천	지연 지급을 판정할 기준 일자	지연 지급 비중이 의미를 잃습니다	자금
계획 범주 · 버전	비교할 계획의 범주와 버전	“계획이 왜 이 숫자냐”가 반복됩니다	기획
소급 · 정산 · 상계 분리	소급 · 정산분과 가불 · 대여금 상계를 전표에서 어떻게 가르나	대상액에서 실지급액으로 가는 길을 설명하지 못합니다	회계 · 인사
부호 규칙	지급을 양수로 볼지 원장 부호 그대로 볼지	합계와 차이의 부호가 서로 반대로 읽힙니다	회계
차원 범위	쓸 차원을 어디까지 열어 둘지	나중에 늘리려면 뷰를 고쳐 다시 이송해야 합니다	현업 · 개발
권한 설계	법인 · 코스트센터 중 무엇으로 거를지	합계에서 남의 숫자가 새어 나옵니다	보안 · 권한
성능 기준	조회 범위 필수화와 응답 시간 기준	범위를 열어 둔 채 운영하면 첫 조회가 느립니다	개발 · Basis
대사 체계	FBL3N · FEBAN · F110 결과와 맞출 항목과 주기	숫자가 다를 때 어디부터 볼지 모릅니다	회계 · 자금
이송(TR) 순서	매핑 테이블 → 기본 뷰 → 차원 → 큐브 → 쿼리 → 권한 → 서비스	권한 없이 쿼리가 먼저 올라가는 틈이 생깁니다	개발
서비스 활성화와 화면 연결	서비스 게시와 화면 설정의 서비스 주소 교체	화면이 샘플 데이터를 계속 읽습니다	Basis · 개발
에이전트 실행 주기	하루 한 번 배치로 부를 시각과 받을 사람	사람이 화면을 열 때만 점검이 돕니다	Basis · 자금

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

대사식	검사 건수	차이 건수
큐브 = 원천 지급 줄 합계(측정값 6종)	6	0
큐브 = 원천(9개 축 각각의 값별 합계 · 5개 두 축 조합의 임의 칸)	92	0
칸 = 원천 문서 합(화면에서 3개 칸을 눌러 확인)	3	0
계획 + 요인 = 실적(서로 다른 5개 범위)	5	0
계획 큐브 = 원천 계획 필드(측정값 5종)	5	0
실지급액 = 지급 대상액 + 소급·정산 − 가불·대여금 상계(원천 2,569줄 전부)	2,569	0

대사 합계 104건(스크립트 기준, 최대 차이 0원)에서 차이 0건입니다. 서비스 쪽 검사 25건도 모두 통과했고, 축을 바꿀 때 서버 호출이 없다는 점과 여러 축 배치 14가지, 열 2단계 배치를 화면에서도 열어 확인했습니다. 임계값과 계획은 샘플의 가정값입니다.

운영 데이터로 갈 때

운영 데이터에서는 지급 줄이 월 수십만 줄, 연 수백만 줄이 될 수 있습니다. 그때도 집계는 서비스의 CDS 큐브에서 하고 화면에는 이미 집계된 큐브만 내려보내야 합니다. 조회 조건의 법인과 기간을 필수로 두어 범위를 좁히고, 필터 · 정렬에 쓰는 필드에는 인덱스를 검토하며, 칸을 눌러 여는 원천 줄은 500건씩 쪽 나눔으로 읽습니다. 큐브가 5,000행을 넘으면 화면은 범위를 좁히라고 안내하므로, 차원 수와 기간을 조정해 이 한도 안에서 쓰는 것을 기준으로 삼습니다. 응답 시간 기준(첫 조회 몇 초 이내인지)은 회사가 정해야 하며 확인 필요입니다.

자주 묻는 질문

도입 전에 가장 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

이 앱의 숫자는 어디서 오나요?

지급 전표 헤더 · 라인과 총계정원장 라인, 급여 정산 결과가 원천이며, 이 자료에서는 가상 법인 · 가상 은행의 샘플 데이터 2,569줄로 시연합니다. 서비스가 원천 줄을 지급월 · 법인 · 은행 · 지급 유형 등 아홉 축으로 미리 집계한 큐브를 화면이 한 번 읽습니다. 급여 정산 인원처럼 원천 필드 위치가 회사마다 다른 값은 확인 필요로 남겨 두었습니다.

실지급액은 어떻게 계산하나요?

실지급액 = 지급 대상액 + 소급·정산 반영 − 가불·대여금 상계입니다. 이 식은 원천 줄마다 성립해야 하며 샘플의 2,569줄 전부에서 검사해 차이 0건이었습니다. 소급분과 상계분을 전표에서 어떻게 가를지는 회사별 확인 필요 항목입니다.

큐브 합계와 원천 지급 줄 합계가 같다는 걸 어떻게 압니까?

각 지급 월 · 측정값별로 큐브 합계와 원천 줄 합계를 견준 결과가 서비스의 대사 결과 목록에 월별로 남습니다. 이 자료에서는 측정값 6종, 축별 값과 두 축 조합 92건을 견주어 차이가 0건이었습니다. 화면에서 칸을 누르면 그 칸의 원천 줄 합계가 칸 금액과 같은지도 그 자리에서 보입니다.

일곱 요인 분해는 무엇을 뜻하나요?

계획 지급액에서 실적 실지급액까지를 인원 변동 · 1인당 단가 변동 · 소급·정산 반영 · 가불·대여금 상계 효과 · 지급월 이동 · 계획 외 신규 지급 · 계획 지급 미발생으로 나눕니다. 계획과 실적에 모두 있는 묶음은 인원과 단가로, 한쪽에만 있는 묶음은 신규 · 미발생으로 갈립니다. 요인 합이 총차이와 같지 않으면 검산 줄이 붉게 바뀌어 확인 필요를 알립니다.

기말 미이체 잔액은 왜 월을 합치면 더해지지 않나요?

지급 결의 후 월말까지 이체하지 않은 금액은 그 시점의 잔액이라 여러 달을 더하면 같은 돈이 겹쳐 셉니다. 그래서 기간을 합칠 때는 끝 기간의 값만 씁니다. 지급 인원도 월별 대상 인원을 더한 연인원이므로 사람 수가 아니라 지급 횟수에 가깝다는 점을 읽을 때 유의해야 합니다.

임계값은 누가 정하나요?

지연 지급 6%, 소급·정산 3억 원, 계획 차이 5억 원, 미이체 잔액 8억 원, 차이 색 0.3억 원 · 5%는 모두 샘플의 가정값입니다. 회사의 자금 · 인사 정책에 맞춰 규칙 값을 고치며, 화면의 금액 · 비율 기준은 사용자가 바로 입력합니다.

화면과 조작

축은 몇 개까지 겹칠 수 있나요?

행 축은 3단계, 열 축은 2단계까지입니다. 열이 36개를 넘거나 행이 300개를 넘으면 표를 그리지 않고 열 축 · 행 축을 줄이라고 안내합니다. 큰 표를 억지로 그리다 브라우저가 멈추는 일을 막는 장치입니다.

축을 바꿀 때마다 서버를 다시 부르나요?

부르지 않습니다. 조회 시 큐브를 한 번 읽고, 이후 축 이동 · 값 필터 · 금액 단위 변경은 브라우저가 같은 큐브를 다시 피벗합니다. 그래서 어느 축에서나 합계가 같고, 서버 호출이 0건이라는 점을 검증 항목에 넣었습니다.

칸을 누르면 무엇이 열리나요?

그 칸을 이루는 원천 지급 줄이 문서 번호 · 지급일 · 은행 · 지급 방식 · 대상액 · 소급 · 상계 컬럼으로 열리고, 맨 위에 건수와 합계, 칸 금액과의 일치 여부가 나옵니다. 합계 칸은 줄이 많아 500건씩 쪽 나눔으로 읽습니다.

변동 사유는 어디에 저장되나요?

서비스에 저장되며 열쇠는 조회 범위와 행 경로입니다. 축 배치를 바꾸거나 트리를 다시 펼쳐도 같은 행이면 사유가 따라오고, 다음 달에도 남습니다. CSV 와 해설의 근거 표에도 함께 실립니다.

보는 사람 탭은 무엇을 바꾸나요?

경영 · 재무 · 인사 · 자금 탭이 요약 카드의 해설과 기본 행 · 열 배치를 바꿉니다. 큐브와 숫자는 그대로이고 어디를 먼저 보여 줄지만 달라집니다.

휴대폰에서도 쓸 수 있나요?

쓸 수 있습니다. 창이 좁아지면 차트를 표 아래로 내리고 요약 카드를 두 줄로 접으며, 390px 폭에서 화면 전체의 가로 흔들림이 없는 것을 확인했습니다. 표가 넓으면 표 안에서만 가로로 밀립니다.

분석 기능

해설은 AI 가 숫자를 만드나요?

아닙니다. 금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고 문장은 그 숫자를 읽어 줍니다. 모델 연결은 기본 꺼짐이며 꺼져 있어도 같은 근거로 규칙 기반 해설이 나옵니다. 근거 표에서 문장에 쓴 숫자의 출처를 확인할 수 있습니다.

에이전트는 무엇을 하나요?

켜 둔 감시 규칙 네 가지(지연 지급 비중 · 소급·정산 반영 · 계획 차이 · 미이체 잔액)를 판정해 걸린 항목을 받을 사람별 대기함에 올립니다. 판단과 기록은 서비스에 있어 화면을 닫아도 같은 문으로 배치가 부를 수 있습니다.

에이전트를 하루에 여러 번 돌릴 수 있나요?

하루 한 번입니다. 같은 날 두 번째 실행은 서버가 제한 안내를 돌려주고 새 보고를 만들지 않습니다. 사람이 누르는 경우와 배치가 부르는 경우가 같은 제한을 받습니다.

보고서(PPTX)는 서버에 남나요?

남지 않습니다. 보고 있는 범위의 표와 차트로 브라우저에서 바로 만들어 내려받습니다. 해설 창에서 받으며, 만든 시각과 범위가 보고서에 적힙니다.

저장한 보기는 무엇을 담나요?

행 · 열 축, 값 필터, 측정값, 금액 단위를 한 벌로 담습니다. 기본 보기로 지정하면 다음에 그 배치로 열리고, 자동 조회를 켜면 조회 버튼 없이 바로 조회합니다.

도입과 운영

이 앱은 점검 도구인가요, 최종 판단 도구인가요?

점검 도구이며 최종 판단은 회사와 감사인이 합니다. 점검 필요로 표시된 항목은 확인할 자리를 추린 것이며 원인이나 옳고 그름을 단정하지 않습니다. 이 앱의 숫자는 그 판단을 위한 참고 자료입니다.

표준 T-code 를 대체하나요?

대체하지 않습니다. 지급 실행(F110) · 은행 명세 처리(FEBAN) · 계정 개별 항목(FBL3N) · 현금 포지션(FF7A) · 유동성 예측(FF7B)은 표준이 계속 맡고, 이 앱은 그 결과를 같은 차원으로 모아 계획과 견주는 관점을 더합니다. 기존 리포트도 없애지 않고 나란히 씁니다.

운영 시스템에 연결하려면 무엇이 필요한가요?

매핑 테이블 채우기, 기본 뷰의 원천 필드 확정, CDS 큐브 · 쿼리 · 권한 이송, 서비스 활성화, 화면 설정의 서비스 주소 교체가 필요합니다. 코딩보다 합의가 많은 일이며, 앞의 운영 표에 항목과 정하지 않을 때의 결과를 적어 두었습니다. 소요 기간은 회사의 원천 구조에 따라 달라 확인 필요입니다.

권한은 어떻게 거나요?

법인 단위 표준 권한 객체를 CDS 쿼리의 DCL 로 집계 단계에 겁니다. 드릴스루에만 걸면 전체 합계에서 보이는 합계를 빼는 방법으로 남의 숫자를 알아낼 수 있으므로 집계 단계에서 거르는 것을 권합니다.

지급 줄이 수백만 건이면 어떻게 되나요?

집계는 서비스의 CDS 큐브에서 하고 화면은 집계된 큐브만 받습니다. 조회 조건의 법인 · 기간을 필수로 두고, 큐브 5,000행 한도와 원천 줄 500건 쪽 나눔이 화면을 보호합니다. 대용량에서의 응답 시간은 실제 환경에서 측정해야 하며 확인 필요입니다.

계정과목이 바뀌거나 새로 생기면요?

계정 → 지급 유형 · 직군 매핑 테이블에 한 줄을 추가하거나 고치면 됩니다. 코드는 건드리지 않으며 현업이 직접 유지할 수 있습니다. 매핑을 빠뜨리면 그 계정의 금액이 분류 없음으로 보여 기존 보고서와 어긋나므로 대사로 걸러 냅니다.

외화 지급은 어떻게 다루나요?

샘플은 원화 기준 한 통화로 시연했습니다. 해외 송금 같은 외화 지급은 환율 유형과 환산 시점을 회사가 정해 큐브의 금액 필드에 반영해야 하며, 이 부분은 확인 필요로 남겼습니다.

데모 데이터는 실제 회사 데이터인가요?

아닙니다. 가상 법인 3곳과 가상 은행 4곳으로 만든 샘플이며 실제 회사나 개인과 관련이 없습니다. 숫자의 크기와 요인은 화면 기능을 보여 주기 위한 것입니다.

감사나 법정 보고에 이 숫자를 써도 되나요?

쓰는 용도가 아닙니다. 법정 보고 · 감사 대응 · 신고에 쓰는 숫자는 표준 거래와 회사의 절차를 따르며, 이 앱은 월마감 전에 차이를 설명하고 점검할 자리를 추리는 도구입니다. 적용 여부는 회사와 감사인이 판단합니다.