SAP 은행 대사 미결 발생·정리 다차원 분석 — 어디에 쌓이고 왜 늘었는지를 한 화면에서 읽는 자금 마감 점검

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

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

월마감 때 자금 담당이 받는 질문은 대체로 세 가지입니다. 은행 대사에서 아직 남은 미결이 얼마인가, 어느 은행 · 어느 통화에 쏠려 있는가, 마감 전 예상보다 늘어난 것은 무엇 때문인가. 지금은 이 답이 은행 명세서 처리 화면, 계정 라인 조회, 엑셀 대사표에 흩어져 있어서 숫자 하나를 맞추는 데 사람이 하루를 씁니다.

이 앱은 세 질문을 한 화면에 붙입니다. 미결의 발생 · 정리 · 기말 잔액을 은행 · 법인 · 통화 · 경과 구간으로 겹쳐 보고, 누른 칸에서 원천 라인까지 내려가며, 마감 전 예상과의 차이를 요인으로 가릅니다. 현금 · 유동성 점검의 관점(IAS 7 · IFRS 7)을 사내 마감 리듬에 맞춰 두는 도구이며, 최종 판단은 회사와 감사인이 합니다.

한 줄 요약 — 은행 대사 미결은 “얼마 남았나”에서 끝나지 않습니다. 이 앱은 어디에 쌓였고, 왜 늘었으며, 누가 먼저 볼 것인가까지 같은 숫자 위에서 보여 주고, 그 숫자가 원천 라인과 1원도 어긋나지 않는지 매번 스스로 검산합니다.

핵심 포인트 일곱 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 갈라지지 않는 피벗	은행 · 법인 · 통화 · 차이 유형 · 경과 구간 등 열 개 차원을 끌어다 놓아 행 3단계 · 열 2단계로 봅니다. 모든 배치가 한 번 읽은 같은 큐브에서 나와, 일곱 가지 배치에서 총합이 4,578.10억으로 같았습니다.	은행별 표, 통화별 표, 경과 구간별 표를 따로 만들고 합계가 서로 다르면 표를 맞추는 회의를 엽니다.
② 칸에서 원천 라인까지	숫자를 누르면 그 칸을 이루는 미결 라인이 열리고, 원천 합계가 칸 금액과 같은지 그 자리에서 보입니다. 가상 시중은행 A 칸은 967건, 1,511.61억이 표와 일치했습니다.	표준 리포트를 닫고 계정 라인 조회를 다시 열어 은행과 기간 조건을 손으로 맞춥니다.
③ 예상 대비 차이를 여섯 요인으로	마감 전 예상과 실적의 발생 미결 차이를 예상 초과 · 예상 미달 · 환율 · 월 이동 · 예상 외 신규 · 예상 미결 미발생으로 가르고, 합이 총차이와 맞는지 매번 검산합니다.	엑셀에서 예상과 실적을 붙여 차이만 구하고, 왜 났는지는 담당자에게 따로 묻습니다.
④ 정리가 늦는 곳이 먼저 보입니다	정리율과 보류 건 미결 잔액 비중, 경과 구간이 같은 표에 놓여 어느 은행 · 어느 발생 경로에서 정리가 밀리는지 한눈에 갈립니다.	미결 총액만 보고, 오래된 건이 어디에 쌓였는지는 마감 뒤에야 압니다.
⑤ 보는 사람에 맞춰 바뀌는 첫 화면	경영 · 재무 · 자금 · 회계 네 역할을 바꾸면 먼저 놓이는 축과 측정값이 달라집니다. 서비스를 다시 부르지 않아 회의 중에도 바로 넘깁니다.	같은 데이터로 대상 부서마다 다른 파일을 만들어 보냅니다.
⑥ 규칙에 걸리면 대기함으로	단일 은행 비중, 보류 건 잔액 비중, 정리율 하한, 예상 차이 임계(샘플 10억) 네 규칙을 서비스가 하루 한 번 판정해 걸린 항목을 대기함에 올리고, 실행 기록을 남깁니다.	누군가 화면을 열어 봐야 알게 되고, 열지 않으면 점검은 일어나지 않습니다.
⑦ 사유와 보기가 남습니다	차이가 난 행에 적은 변동 사유와, 짜 둔 축 배치를 이름 붙여 저장해 다음에 열 때 그 모습으로 시작합니다.	지난달 사유는 메일함에서 찾고, 표 모양은 매번 다시 짭니다.

사례로 보는 효과

가상 샘플 자료(2026년 1월~9월, 원천 라인 3,461건)로 실제 나온 숫자입니다. 이 기간 발생 미결은 4,578.10억으로, 마감 전 예상(4,547.09억)보다 31.01억 많았습니다. 총차이만 보면 “조금 늘었다”로 끝납니다.

요인분해는 같은 31.01억을 이렇게 갈랐습니다.

요인	금액(억원)	읽는 법
예상 초과 발생	+144.47	예상한 건에서 예상보다 많이 발생한 몫
예상 미달 발생	−193.15	예상한 건에서 예상보다 적게 발생한 몫
환율	+9.24	예상 환율과 실적 환율 차이로 생긴 원화 환산 몫
발생 월 이동	0.00	이 범위에서는 월을 걸친 이동이 서로 상쇄되어 0 (한 달만 보면 값이 나옵니다)
예상 외 신규 미결	+262.02	예상에 없던 건이 새로 생긴 몫
예상 미결 미발생	−191.58	예상했으나 생기지 않은 몫
합계	+31.01	총차이와 같습니다(검산 줄 0)

각 요인은 억원 단위로 반올림해 적었으므로 행을 더하면 31.00으로 보일 수 있으나, 원 단위 합은 총차이 31.01억(3,100,791,126원)과 정확히 같습니다.

총차이는 작아 보여도 안에서는 예상 외 신규 미결 +262억과 예상 미결 미발생 −192억이 서로 상쇄되고 있습니다. 예상 체계가 건의 “있고 없음”을 크게 놓치고 있다는 뜻이므로, 점검할 곳은 총액이 아니라 예상을 세우는 방식입니다. 이 읽기는 요인의 합이 총차이와 맞는다는 검산이 있어야 믿을 수 있고, 이 앱은 그 검산을 범위 35개에서 모두 0으로 확인했습니다.

도입하면 달라지는 것

미결을 “총액 한 줄”이 아니라 은행 · 통화 · 경과 구간의 지도로 보며 마감 회의를 시작합니다.
숫자가 다르다는 이의가 나오면 그 자리에서 칸을 눌러 원천 라인과 합계를 맞춰 봅니다. 엑셀을 열러 자리를 뜨지 않습니다.
예상 대비 차이를 요인으로 먼저 읽으므로, 회의가 “왜 늘었나” 추궁이 아니라 “어느 예상을 고칠까”로 흘러갑니다.
사유와 보기가 남아 다음 달 마감은 지난달 화면에서 이어 시작합니다.
정리가 밀리는 경로를 규칙이 하루 한 번 알려 주어, 마감 직전에야 발견하던 점검이 앞당겨집니다.

이런 회사에 맞습니다

여러 통화의 계좌를 여러 은행에 두고, 매월 은행 명세서와 장부를 맞춘 뒤 남는 미결 때문에 마감 일정이 흔들리는 회사에 맞습니다. 예를 들어 수출입 비중이 높아 외화 계좌가 많은 제조 · 무역 · 해운 · 에너지 기업, 법인이 여러 곳이라 은행별 미결을 그룹 단위로 모아 보는 재무팀, 정리 담당자와 자금 담당자 · 회계 담당자가 같은 숫자를 다른 눈으로 읽어야 하는 조직입니다. 계좌가 한두 개이고 미결이 거의 없는 곳이라면 표준 화면만으로 충분합니다.

실행 화면

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

사용 방법

조회조건 입력 — 기간(부터 · 까지)은 필수이며 기본은 2026년 1월~9월입니다. 법인은 선택이고, 비교 기준은 “마감 전 예상과 비교”가 기본입니다.
조회 — 조회조건 상자 안의 파란 [조회] 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 기본 + 자동 조회로 저장한 보기가 있으면 화면을 열 때 자동으로 조회됩니다.
요약 확인 — 위쪽 다섯 가지 지표를 봅니다. 보는 사람(경영 · 재무 · 자금 · 회계)을 바꾸면 먼저 놓이는 축이 달라집니다.
탭과 축 이동 — 차원 칩을 끌어 행 축 · 열 축에 놓고, 측정값과 값 필터로 범위를 좁힙니다. 총합은 어떤 배치에서도 같습니다.
행 · 칸 클릭 — 행을 누르면 오른쪽 차트가 그 행의 요인으로 바뀌고, 숫자 칸을 누르면 원천 라인이 열립니다.
내보내기 — [CSV]로 표를 내려받고, [해설]에서 읽은 내용을 PowerPoint 보고서로 받습니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면	OpenUI5 한 장짜리 분석 화면 — 조회조건 · 지표 · 레이아웃 보드 · 피벗 트리 표 · 차트	조회부터 상세까지 화면 이동 없이 같은 자리에서 끝나게 하려는 것입니다.
집계 · 판정 로직	큐브를 다시 묶는 재집계 모듈, 요인분해 · 해설 · 에이전트 판정을 맡는 계산 모듈	화면과 서비스가 같은 계산 모듈을 써서 두 곳의 숫자가 갈라지지 않게 했습니다.
OData 구성	조회용 집합 열네 개(큐브 · 예상 · 원천 라인 · 차원 · 측정값 · 계산항목 · 기간 요약 · 대사 결과 등)와 요인분해 · 해설 · 에이전트 세 개의 함수, 사유 · 보기 · 대기함을 저장하는 쓰기용 집합	읽기는 큐브를 한 번, 계산은 서비스 함수가, 저장은 쓰기용 집합이 맡도록 역할을 나눴습니다.
모델 사용 방식	기본 모델 하나를 단방향으로 쓰고, 조회 때 큐브와 예상을 기간 · 법인 조건으로 한 번씩 읽습니다. 축 전환 · 역할 전환 · 값 필터는 읽어 둔 큐브 안에서 다시 계산합니다.	축을 바꿀 때마다 서버를 부르면 느려지고 총합이 갈라질 자리가 생기기 때문입니다.
테마	sap_horizon (OpenUI5 1.120)	SAP 화면과 같은 결의 모양으로 맞춰 사용자가 낯설어하지 않게 했습니다.

SAP 표준 기능을 그대로 이어받은 부분 — 미결의 원천은 표준 은행 명세서 처리에서 남는 건과 은행 계정 라인입니다. 이 앱은 표준 데이터 구조를 그대로 이어받아 확장하며, 표준 실행(명세서 입력 · 전기 · 정리)은 SAP 표준 T-code 가 계속 담당합니다. 이 화면은 그 결과를 조회 · 검증하는 관점을 더합니다.

조회 한 번으로 지표 · 표 · 차트가 함께 뜹니다

조회조건 상자, 다섯 가지 지표, 왼쪽 표와 오른쪽 차트, 그리고 축을 고르는 레이아웃 보드가 한 화면에 세로로 쌓입니다. 조회를 누르기 전에도 틀이 서 있어서 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 볼 수 있습니다.

**조회 직후 — 지표·표·차트가 한 번에** — 기간 2026년 01월~09월, 마감 전 예상(P0)과 비교로 조회한 첫 결과입니다. 위쪽 다섯 가지 요약 지표와 왼쪽 표, 오른쪽 차트가 한 번의 읽기로 채워집니다.

기간 2026년 1월~9월, 마감 전 예상(P0)과 비교로 조회한 첫 결과입니다. 위쪽 지표 다섯 개는 발생 미결 4,578.10억을 비롯해 같은 큐브에서 나온 값이며, 표와 차트도 한 번의 읽기로 함께 채워집니다.

**조회 조건 펼침** — 조회 직후에는 조회 조건이 한 줄 요약으로 접혀 표가 넓게 쓰입니다. 막대를 누르면 법인·기간·비교 기준 입력 칸과 [조회]·[초기화] 버튼이 펼쳐집니다.

조회를 누르면 조건 상자는 한 줄 요약(법인 · 기간 · 비교 기준 · 금액 단위)으로 접혀 표가 넓어지고, 막대를 누르면 이 모습으로 펼쳐집니다. 파란 [조회] 버튼은 조건 상자 안 입력 칸 오른쪽에 있고, [초기화]는 조건을 기본값으로 되돌립니다. 아래에는 지표 · 차원 보관함 · 행과 열 축 · 표 · 차트가 이어집니다.

보는 사람에 맞춰 바뀌는 첫 화면

같은 데이터를 경영 · 재무 · 자금 · 회계가 각자의 눈으로 읽습니다. 역할을 바꾸면 서비스를 다시 부르지 않고 먼저 놓이는 축과 측정값만 바뀝니다.

**자금 — 은행·통화별 기말 잔액** — "자금"은 은행과 통화 축에 기말 미결 잔액과 보류 건 미결 잔액 비중을 먼저 보여 줍니다.

보는 사람을 “자금”으로 바꾸면 은행과 통화 축에 기말 미결 잔액과 보류 건 미결 잔액 비중이 먼저 놓입니다. 자금 담당이 가장 먼저 묻는 “어느 은행에 얼마가 남아 있나”에 바로 답하는 배치입니다. 역할을 바꿔도 서비스를 다시 부르지 않습니다.

열 개 차원을 끌어다 놓고, 값으로 범위를 좁힙니다

차원 칩을 행 축과 열 축에 옮겨 표의 모양을 정합니다. 어떤 배치에서도 총합이 같다는 것이 이 화면의 약속이고, 값 필터는 읽어 둔 큐브 안에서만 걸러서 서버를 다시 부르지 않습니다.

**열 축 2단계** — 열 축에 분기와 발생 경로를 함께 놓은 모습입니다. 열 축은 2단계까지 허용하고, 이 과정에서 서버를 다시 부르지 않습니다.

열 축에 분기와 발생 경로를 함께 놓은 모습입니다. 열 축은 두 단계까지 허용하고, 이 과정에서 서버 요청은 0건이었습니다. 열이 너무 많아지면 표가 읽히지 않기 때문에 상한을 두었습니다.

**좁힌 결과** — 적용하면 표·차트·지표가 선택한 범위로 바뀌고, 값 필터 옆에 "필터: 은행 2" 표시가 붙습니다.

값 필터에서 은행 두 곳을 골라 적용한 결과입니다. 표 · 차트 · 지표가 선택 범위로 바뀌고 값 필터 옆에 “필터: 은행 2” 표시가 붙습니다. 필터를 풀면 총합이 원래대로 돌아옵니다.

칸에서 미결 원천 라인까지 — 표의 숫자를 눈으로 확인합니다

표의 숫자 칸을 누르면 그 칸을 이루는 원천 라인이 열립니다. 상단에 원천 합계와 칸 금액이 일치하는지 표시되어 “이 숫자 믿어도 되나”를 그 자리에서 답합니다. 행 축을 회계기간으로 바꾸면 월별 흐름도 같은 방식으로 읽힙니다.

**칸 → 원천 라인** — 가상 시중은행 A 칸을 누르면 그 칸을 이루는 원천 라인 967건이 열립니다. 상단에 "표의 값과 일치"가 표시되고 원천 합계가 칸 금액 1,511.61 억원과 같습니다.

가상 시중은행 A 칸을 누르면 그 칸을 이루는 원천 라인 967건이 열립니다. 원천 합계 1,511.61억이 칸 금액과 같아 상단에 “표의 값과 일치”가 표시됩니다. 일치하지 않으면 이 자리에서 바로 드러나므로 숫자를 의심할 때 가장 먼저 눌러 보는 화면입니다.

**기간별 요약 — 월별** — 행 축을 회계기간으로 바꾸면 9개월 발생 미결이 한눈에 보입니다. 같은 데이터로 재조회 없이 바뀝니다.

행 축을 회계기간으로 바꾸면 아홉 달의 발생 미결이 한눈에 보입니다. 같은 큐브에서 재조회 없이 바뀌고, 월별 총합을 더하면 4,578.10억으로 앞 화면과 같습니다.

정리율처럼 비율은 합계 칸에서 다시 계산합니다

순증감 · 정리율 · 보류 건 비중 같은 계산항목을 측정값처럼 열에 놓을 수 있습니다. 비율은 칸마다 더하지 않고 합계 칸에서 분자와 분모를 각각 더한 뒤 다시 나눕니다.

**계산항목과 측정값 열** — 측정값 3개(발생 미결, 정리율, 보류 건 미결 잔액 비중)를 열로 세웠습니다. 비율 항목은 합계 칸에서 다시 계산한 값입니다.

발생 미결 · 정리율 · 보류 건 미결 잔액 비중 세 측정값을 열로 세웠습니다. 정리율은 칸마다 평균 내지 않고 합계에서 “정리액 ÷ 정리 대상액”으로 다시 계산한 값이므로, 행을 묶어도 비율이 왜곡되지 않습니다.

마감 전 예상 대비 — 같은 표가 마감 점검표가 됩니다

예상 차이를 켜면 칸마다 실적 · 예상 · 차이 · 차이율이 붙고, 금액과 비율을 모두 넘는 칸에만 색이 붙습니다. 선택한 행은 오른쪽 차트에서 예상에서 실적까지의 요인으로 풀리고, 차이의 이유는 행에 적어 둡니다.

**예상 차이 켜기** — 예상 차이를 켜면 실적·예상·차이·차이율 열이 나옵니다. 금액 기준(300 백만원)과 비율 기준(5%)을 모두 넘는 칸에만 색이 붙습니다.

예상 차이를 켜면 실적 · 예상 · 차이 · 차이율 열이 붙습니다. 금액 기준 300백만원과 비율 기준 5%를 둘 다 넘는 칸에만 색이 붙어, 작은 변동에 눈이 끌리지 않습니다.

**워터폴과 요인분해** — 선택한 행의 예상 발생 미결에서 실적 발생 미결까지의 요인을 막대로 보여 줍니다. 아래 검산 줄에서 예상 + 요인 합 − 실적 = 0 을 확인합니다.

선택한 행의 예상 발생 미결에서 실적 발생 미결까지를 요인별 막대로 보여 주는 워터폴입니다. 아래 검산 줄에서 “예상 + 요인 합 − 실적 = 0”을 확인합니다. 0이 아니면 점검이 필요하다는 신호이며, 이번 자료에서는 범위 35개 모두 0이었습니다.

**변동 사유 기재** — 차이가 난 행에 구분과 사유를 적습니다. 사유 문구는 점검 필요 표현으로 쓰는 것을 권합니다.

차이가 난 행에 구분과 사유를 적습니다. 사유는 조회 범위와 행 경로에 묶여 저장되므로 축을 바꾸거나 다음 달에 다시 열어도 그 행을 따라옵니다. 사유 문구는 단정 대신 “점검 필요”처럼 쓰는 것을 권합니다.

숫자는 서비스가, 문장은 초안으로

지금 보고 있는 범위를 해설로 읽어 줍니다. 금액과 비율은 서비스가 계산해 근거 표로 넘기고 문장은 초안이라, 읽는 사람이 근거 표로 확인한 뒤 씁니다.

**해설 — 규칙 기반 초안** — 선택한 범위를 규칙으로 읽은 초안입니다. 숫자는 서비스가 계산한 값이고 문장은 초안이므로, 점검 필요 항목은 근거 표로 확인합니다.

선택한 범위를 읽은 해설 초안입니다. 숫자는 모두 서비스가 계산한 값이고 문장은 그 숫자를 규칙으로 읽은 초안입니다. 문장은 초안이므로 근거 표와 함께 읽고, 보고서로 내려받을 수 있습니다.

규칙에 걸리면 대기함으로 — 하루 한 번

감시 규칙마다 임계값과 받을 사람이 붙어 있습니다. 실행하면 걸린 항목이 대기함에 올라가고 활동 기록이 남으며, 판정과 기록은 화면이 아니라 서비스에 있습니다.

**실행 결과** — 지금 실행을 누르면 걸린 항목이 대기함에 올라가고 활동 기록이 남습니다. 같은 날 두 번째 실행은 제한됩니다.

지금 실행을 누르면 네 개 규칙 중 걸린 4건이 대기함에 올라가고 활동 기록이 남습니다. 같은 날 두 번째 실행은 서버가 “하루 한 번” 제한으로 돌려줍니다. 사람이 자리에 없는 시간에는 배치 작업이 같은 호출을 대신할 수 있습니다.

짜 둔 축을 이름 붙여 저장해 둡니다

자주 쓰는 축 배치를 이름 붙여 저장하고, 다음에 열 때 그 보기로 시작하거나 열자마자 조회하도록 정할 수 있습니다.

**현재 보기 저장** — 보기 이름을 정하고 "다음에 열 때 이 보기로 시작", "열면 바로 조회"를 고를 수 있습니다.

보기 이름을 정하고 “다음에 열 때 이 보기로 시작”, “열면 바로 조회”를 고를 수 있습니다. 두 가지를 모두 켜면 화면을 여는 순간 지난번 그 표가 조회되어 있습니다.

열 조합 상한과 좁은 화면

열 축은 두 단계까지로 막아 두었고, 휴대폰 폭에서도 가로 스크롤 없이 지표가 쌓입니다. 한계는 숨기지 않고 화면에 안내합니다.

**열 조합 상한 안내** — 열 축은 2단계까지입니다. 더 놓으려 하면 추가하지 않고 "열 축은 최대 2단계까지 둘 수 있습니다" 안내가 나옵니다.

열 축에 세 번째 차원을 놓으려 하면 추가하지 않고 “열 축은 최대 2단계까지 둘 수 있습니다” 안내가 뜹니다. 한계를 숨기지 않는 것이 이 화면의 원칙입니다.

**390px 폭 — 상단** — 휴대폰 폭에서도 가로 스크롤 없이 지표가 2열로 쌓입니다.

390px 폭에서도 가로 스크롤이 생기지 않고 지표가 두 줄로 쌓입니다. 표는 아래로 내려가며 가로로만 스크롤됩니다.

화면 뒤에서 일어나는 일

화면의 표시는 아래 판정을 따릅니다. 기준값은 샘플 설정이며 회사 기준으로 바꿉니다. 이 화면은 점검 도구이고 최종 판단은 회사와 감사인이 합니다.

판정 조건	결과 상태	사용자 조치
큐브 합계 ≠ 원천 라인 합계	칸 아래 “표의 값과 일치” 대신 불일치 표시	원천 라인 목록에서 어느 라인이 빠졌는지 점검하고, 사유가 확인되기 전까지 보고 숫자로 쓰지 않습니다.
정리율이 하한(샘플 66%) 미만	규칙 “정리율 하한”에 걸림	분개 대기 · 은행 확인 중 건의 누적을 점검합니다.
보류 건 미결 잔액 비중 ≥ 15%	규칙에 걸림	보류 사유(확인 필요 건)를 정리 담당과 확인합니다.
한 은행의 발생 미결 비중 ≥ 30%	규칙에 걸림	특정 은행 계좌에 쏠린 원인(자동 매칭 실패 · 수기 입력 지연)을 점검합니다.
예상 대비 차이가 금액 300백만원과 비율 5% 둘 다 초과	칸에 색 표시	요인분해로 어느 요인인지 확인하고 변동 사유를 남깁니다.
열 축 3단계 이상 시도	추가하지 않고 안내	필요한 차원을 행 축으로 옮기거나 값 필터로 범위를 줄입니다.

예상 대비 차이가 요인으로 갈라지는 순서

요인분해는 조회한 범위 안에서 다음 순서로 진행됩니다. 모든 단계는 서비스 함수가 계산하고 화면은 결과를 읽기만 합니다.

범위 안의 실적과 예상을 같은 키(기간 · 법인 · 은행 · 차이 유형 · 통화 · 발생 경로 · 경과 구간 · 처리 단계 · 보류 여부)로 맞붙입니다.
양쪽에 있는 키는 예상 금액과 실적 금액의 차이를 예상 초과 발생(+) 또는 예상 미달 발생(−)으로 가르고, 환율 차이로 생긴 몫은 환율로 따로 뺍니다.
같은 건이 예상과 실적에서 서로 다른 달에 잡힌 경우는 발생 월 이동으로 묶습니다.
실적에만 있는 키는 예상 외 신규 미결, 예상에만 있는 키는 예상 미결 미발생입니다.
여섯 요인의 합이 총차이(실적 − 예상)와 같은지 검산해 검산 줄에 표시합니다.

조회조건

필드	필수	기본값	서비스에 보내는 조건
법인	선택	전체	`Comp eq '…'` (여러 개 선택 가능)
기간(부터)	필수	2026년 01월	`Period ge '202601'`
기간(까지)	필수	2026년 09월	`Period le '202609'`
비교 기준	필수	마감 전 예상(P0)과 비교	`Version eq 'P0'` (비교 안 함이면 읽지 않음)
금액 단위	선택	억원	화면에서만 환산(서비스 값은 원)
값 필터	선택	없음	읽어 둔 큐브 안에서 걸러 다시 읽지 않음

결과 컬럼

컬럼(측정값)	의미	산출식
발생 미결	그 기간 새로 남은 미결의 원화 환산액	당월 발생 미결 외화 × 월말 적용 환율, 기간을 합치면 합산
정리액	그 기간 정리된 금액(원화 환산)	정리된 건의 외화 × 월말 환율
정리 대상액	정리해야 했던 총액	기초 미결 + 당월 발생
기말 미결 잔액	기간 끝 시점에 남아 있는 미결	기초 + 발생 − 정리, 기간을 합쳐도 끝 기간만 사용
라인 수	원천 라인 건수	해당 칸의 원천 라인 개수
정리율(계산항목)	정리 속도	정리액 × 100 ÷ 정리 대상액, 합계 칸에서 다시 계산
보류 건 미결 잔액 비중(계산항목)	정리가 보류된 건이 차지하는 몫	보류 건 기말 잔액 × 100 ÷ 전체 기말 잔액
예상 차이 · 차이율	예상 대비 증감	실적 − 예상, 차이 ÷ 예상

좁은 화면에서 달라지는 것

화면 폭이 720px 아래로 내려가면 지표가 줄바꿈되고, 조회조건과 차원 보관함이 세로로 놓이며, 오른쪽 차트는 숨기지 않고 표 아래로 내려옵니다. 390px 폭에서도 가로 스크롤은 생기지 않고, 표만 가로로 스크롤되며 위쪽 열 머리는 유지됩니다. 값 필터 · 보기 저장 같은 대화창은 화면 폭에 맞춰 열립니다.

파일 구성

앱 폴더/
  index.html · Component.js · manifest.json · readme.html
  controller/   화면 컨트롤러 (조회 · 축 · 드릴스루 · 요인분해 · 에이전트)
  view/         메인 화면과 대화창(원천 라인 · 변동 사유 · 해설 · 에이전트 · 보기 저장 · 값 필터)
  model/        재집계 · 차트 · 보기 저장 · 보고서(pptx) · 포매터
  css/ · i18n/
  odata/        서비스 정의(metadata) · 서비스 로직(service.js) · 공용 계산(calc.js) · 데이터
  media/        소개 영상 · 장면 목차

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래 표준 화면 구성은 시스템 버전에 따라 다를 수 있어 운영 시스템에서 확인이 필요합니다.

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

하고 싶은 일	표준 화면으로 충분한 부분	이 앱이 더하는 관점
은행 명세서를 올리고 장부와 맞추기	명세서 입력(FF_5 · FF67)과 후처리(FEBAN)로 건별 정리까지 표준이 담당	정리가 끝난 뒤 남은 미결을 은행 · 통화 · 경과 구간으로 겹쳐 봅니다.
은행 계정의 라인을 확인하기	FBL3N 이 라인 단위 조회를 담당	라인을 모아 칸으로 보고, 칸에서 라인으로 다시 내려갑니다.
미결이 어디에 쌓이는지 보기	표준에서는 은행별 · 기간별 조회를 따로 반복	축을 끌어다 놓아 같은 큐브에서 한 번에 바꿔 봅니다.
마감 전 예상과 실적 비교	표준 리포트에는 예상 대비 요인 분해가 없어 엑셀에서 수행	여섯 요인으로 가르고 검산 줄까지 자동으로 확인합니다.
정리가 밀리는 곳을 알아채기	사람이 화면을 열어 확인	규칙이 하루 한 번 판정해 대기함에 올립니다.

T-code 별 연계 지점

T-code	이름	연계
FF_5	전자 은행 명세서 입력	명세서의 은행 계정 라인이 이 앱의 원천 라인(발생 미결)의 출발점입니다. 오가는 방법: 앱의 칸 → 원천 라인의 문서 번호 → 표준에서 명세서 확인. 법정 · 감사 대응 자료는 표준에 남겨 둡니다.
FF67	수기 은행 명세서 입력	수기 입력 지연이 발생 경로 “수기 입력”으로 구분되어 보입니다. 입력 시점의 지연을 점검하는 용도이고 입력 자체는 표준이 담당합니다.
FEBAN	은행 명세서 후처리	자동 매칭에 실패해 후처리로 넘어간 건이 보류 건 미결 잔액 비중으로 모입니다. 비중이 높으면 FEBAN 에서 해당 은행의 건을 우선 처리합니다.
FBL3N	총계정원장 라인 조회	은행 계정 라인과 이 앱의 원천 라인을 같은 필드(계정 · 전기일 · 금액)로 대조합니다. 두 화면의 합계가 다르면 범위 조건부터 확인합니다.
FB03	전표 조회	원천 라인의 문서 번호로 원전표를 확인합니다. 앱에서 표준으로 넘어가는 마지막 한 걸음입니다.
FS10N	총계정원장 계정 잔액	기말 미결 잔액과 계정 잔액의 차이를 점검합니다. 이 차이가 대사의 마지막 확인선입니다.

기존 리포트를 없애야 하나? 아닙니다. 법정 · 감사 · 세무 신고에 쓰는 보고는 표준 화면에 그대로 남기고, 이 앱은 마감 회의 전에 쏠림 · 정리 속도 · 예상 대비 차이를 내부 점검하는 데 씁니다. 두 화면의 숫자가 다르면 위 표의 대조 지점부터 맞춰 봅니다.

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

S/4HANA 에서는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 도구로 현금 · 은행 관련 조회를 구성할 수 있습니다. 이 앱의 CDS 구성(아래 #sec-cds)은 같은 방식으로 큐브와 분석 쿼리를 두고 그 위에 다차원 화면 · 요인분해 · 감시를 얹는 형태라, 표준 분석 스택과 경쟁하지 않고 같은 데이터 모델 위에서 자리를 나눕니다. 구체적인 표준 앱 이름과 사용 가능 여부는 고객사의 릴리스에서 확인이 필요합니다.

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

자리	손대는 일	손대지 않으면
차이 유형 · 처리 단계 · 보류 사유 매핑	명세서 외부 거래 코드와 계정 기호를 이 앱의 차이 유형(입금 · 출금 · 수수료 · 이자 미기표)에 연결	미결이 “기타”로 쏠려 분석이 의미를 잃습니다.
은행 · 계좌 마스터	하우스 뱅크와 계정 ID를 은행 차원에 연결	같은 은행이 계좌마다 따로 보입니다.
환율 유형 · 환산 시점	월말 환율 유형과 예상용 환율 유형 지정	환율 요인이 의미 없는 값으로 나옵니다.
감시 규칙 임계값	샘플 값(30% · 15% · 66% · 10억)을 회사 기준으로 교체	샘플 기준으로 걸려 현업이 신뢰하지 않습니다.
확장 필드 · BAdI	명세서 라인에 회사 고유 분류 필드를 추가해 차원으로 노출	필요한 분석 축이 없어 엑셀로 돌아갑니다.
권한	법인 · 은행 단위 조회 범위(DCL)	모든 사용자가 전 법인 미결을 보게 됩니다.

분석 지표 정의표

지표	산식	판정 기준(샘플)	대응 기능	원천 데이터	비고
발생 미결	당월 발생 미결 외화 × 월말 환율	예상 대비 차이 금액 300백만원 · 5% 동시 초과	지표 · 피벗 · 예상 차이	은행 대사 미결 라인	기간 합산
정리율	정리액 × 100 ÷ (기초 + 발생)	66% 이하	계산항목 · 규칙	정리 라인	합계 칸에서 재계산
보류 건 미결 잔액 비중	보류 건 기말 잔액 × 100 ÷ 전체 기말 잔액	15% 이상	지표 · 규칙	미결 라인의 보류 표시	기말 기준
최대 은행 비중	한 은행 발생 미결 ÷ 전체	30% 이상	지표 · 규칙	미결 라인의 은행 키	집중도 지수 함께
예상 대비 발생 차이	실적 − 마감 전 예상	절대값 10억 이상(규칙)	예상 차이 · 요인분해 · 규칙	실적 · 예상 큐브	여섯 요인 합 = 차이
관련 기준	IAS 7(현금흐름표) · IFRS 7(금융상품: 공시)	—	내부 점검 관점의 참고	—	문단 번호는 원문 확인 필요

CDS 구성 — 큐브부터 서비스까지

운영 데이터(S/4HANA 은행 계정 라인과 명세서 데이터)로 옮길 때의 뷰 구성입니다. 객체 이름은 설계 예시이며 고객사의 이름 규칙과 릴리스에 맞춰 확인이 필요합니다. 코드는 구조를 보이기 위한 것으로 필드 이름은 시스템에서 확인한 뒤 조정합니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	ZBR_ReasonMap	거래 코드 · 계정 기호를 차이 유형 · 처리 단계 · 보류 사유로 매핑	매핑이 바뀌어도 뷰는 그대로 두고 데이터만 고치려는 것입니다.
차원	ZI_BankDimension · ZI_AgeBucket	은행 · 경과 구간 차원과 텍스트	화면의 모든 축이 같은 차원 정의를 쓰게 합니다.
큐브	ZI_OpenItemCube	월 · 법인 · 은행 · 통화 · 차이 유형 · 경과 구간 별 발생 · 정리 · 기말 집계	화면이 한 번 읽는 단위이며 원화 환산을 여기서 끝냅니다.
큐브(예상)	ZI_OpenItemPlanCube	마감 전 예상 버전별 같은 모양의 집계	실적과 예상이 같은 키 모양이어야 요인분해가 가능합니다.
쿼리	ZC_OpenItemQuery	분석 쿼리 — 필터 · 집계 노출	화면 · 보고서 · 에이전트가 같은 쿼리를 씁니다.
권한	ZR_OpenItemRole	법인 · 은행 단위 접근	쿼리를 바꾸지 않고 권한만 따로 관리합니다.
서비스	ZUI_OpenItem_O2 (정의 · 바인딩)	OData V2 로 게시	화면 주소만 바꾸면 샘플에서 운영으로 전환됩니다.

① 매핑 기준 테이블 — ZBR_ReasonMap

거래 코드와 계정 기호를 이 앱의 차이 유형으로 바꾸는 표입니다. 운영에서 가장 자주 바뀌는 부분이라 코드가 아니라 데이터로 두었습니다. 매핑이 비면 미결이 전부 “기타”로 모여 분석이 무의미해집니다.

" ─────────────────────────────────────────────────────────────
" ZBR_ReasonMap — 미결 차이 유형 · 처리 단계 · 보류 사유 매핑
" 이렇게 나눈 이유: 매핑은 회계 담당이 바꾸는 데이터라 뷰 코드와 분리한다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '미결 차이 유형 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbr_reasonmap {
  key client      : abap.clnt not null;
  key bankbusactv : abap.char(4) not null;   " 은행 외부 거래 코드
  key glaccount   : abap.char(10) not null;  " 은행 계정 기호
  kind_code       : abap.char(2) not null;   " IN / OUT / FEE / INT
  stage_code      : abap.char(2) not null;   " 분개 대기 · 은행 확인 중 등
  hold_flag       : abap_boolean;            " 정리 보류 여부
}

② 차원 뷰 — ZI_BankDimension

은행 차원은 하우스 뱅크와 계정 ID를 묶어 은행 이름으로 보이게 합니다. 같은 은행의 여러 계좌가 하나의 은행으로 모여야 “최대 은행 비중” 규칙이 의미가 있습니다.

" ─────────────────────────────────────────────────────────────
" ZI_BankDimension — 은행 차원
" 이렇게 나눈 이유: 큐브가 은행 키만 알고, 이름과 정렬은 차원이 맡는다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '은행 차원'
@ObjectModel.representativeKey : 'BankKey'
@Analytics.dataCategory : #DIMENSION
@Metadata.ignorePropagatedAnnotations : true
define view entity ZI_BankDimension
  as select from t012
{
  key bukrs       as CompanyCode,
  key hbkid       as HouseBank,
      @Semantics.text: true
      cast( concat( hbkid, bankl ) as abap.char(30) ) as BankKey,
      banks       as BankCountry,
      bankl       as BankInternalId
}

③ 큐브 — ZI_OpenItemCube

화면이 한 번 읽는 단위입니다. 외화 금액을 월말 환율로 원화로 바꾸는 일이 여기서 끝나므로, 위쪽 어느 뷰도 환율을 다시 만지지 않습니다. 정리율처럼 비율은 이 뷰에 두지 않고 분자 · 분모만 합계로 내보냅니다.

" ─────────────────────────────────────────────────────────────
" ZI_OpenItemCube — 월 · 법인 · 은행 · 통화 · 차이 유형 · 경과 구간 집계
" 이렇게 나눈 이유: 환산을 한 곳에서 끝내 다른 뷰가 환율을 모르게 한다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '대사 미결 큐브'
@Analytics.dataCategory : #CUBE
@ObjectModel.usageType: { sizeCategory: #XL, serviceQuality: #D, dataClass: #TRANSACTIONAL }
define view entity ZI_OpenItemCube
  as select from zbr_openitem as oi
  association [0..1] to ZBR_ReasonMapV as _Reason
    on  $projection.BankBusActv = _Reason.BankBusActv
  association [1..1] to ZI_BankDimension as _Bank
    on  $projection.CompanyCode = _Bank.CompanyCode
    and $projection.HouseBank   = _Bank.HouseBank
{
  key oi.bukrs                                   as CompanyCode,
  key oi.hbkid                                   as HouseBank,
  key oi.fiscper                                 as FiscalPeriod,
  key oi.waers                                   as TransactionCurrency,
  key oi.bankbusactv                             as BankBusActv,
  key oi.age_bucket                              as AgeBucket,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      @DefaultAggregation: #SUM
      cast( oi.arise_amt * oi.fx_rate as abap.curr(23,2) ) as AriseAmount,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      @DefaultAggregation: #SUM
      cast( oi.clear_amt * oi.fx_rate as abap.curr(23,2) ) as ClearAmount,
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      @DefaultAggregation: #SUM
      cast( oi.open_amt * oi.fx_rate as abap.curr(23,2) )  as OpenAmount,
      @DefaultAggregation: #SUM
      cast( 1 as abap.int4 )                     as LineCount,
      oi.hold_flag                               as OnHold,
      cast( 'KRW' as waers_curc )                as CompanyCurrency,
      _Reason,
      _Bank
}

④ 예상 큐브 — ZI_OpenItemPlanCube

요인분해는 실적과 예상이 같은 키 모양일 때만 성립합니다. 예상 큐브는 버전 키(마감 전 예상 P0 등)만 더하고 나머지 차원과 측정값을 큐브와 똑같이 둡니다. 두 뷰의 키가 다르면 요인 합이 총차이와 어긋납니다.

" ─────────────────────────────────────────────────────────────
" ZI_OpenItemPlanCube — 마감 전 예상 큐브
" 이렇게 나눈 이유: 실적 큐브와 키 모양을 똑같이 맞춰 요인분해가 가능하게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '대사 미결 예상 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_OpenItemPlanCube
  as select from zbr_openitem_pl as pl
{
  key pl.version                                 as PlanVersion,
  key pl.bukrs                                   as CompanyCode,
  key pl.hbkid                                   as HouseBank,
  key pl.fiscper                                 as FiscalPeriod,
  key pl.waers                                   as TransactionCurrency,
  key pl.bankbusactv                             as BankBusActv,
  key pl.age_bucket                              as AgeBucket,
      @DefaultAggregation: #SUM
      cast( pl.arise_amt * pl.plan_fx_rate as abap.curr(23,2) ) as AriseAmount,
      @DefaultAggregation: #SUM
      cast( pl.clear_amt * pl.plan_fx_rate as abap.curr(23,2) ) as ClearAmount,
      @DefaultAggregation: #SUM
      cast( pl.open_amt * pl.plan_fx_rate as abap.curr(23,2) )  as OpenAmount
}

⑤ 분석 쿼리 — ZC_OpenItemQuery

화면 · 보고서 · 에이전트가 모두 같은 쿼리를 읽습니다. 어느 차원을 필터로 열고 어느 차원을 기본 행 · 열 축으로 둘지가 여기서 정해지며, 월 범위를 필수 파라미터로 두어 대용량에서 전체를 읽는 사고를 막습니다.

" ─────────────────────────────────────────────────────────────
" ZC_OpenItemQuery — 분석 쿼리
" 이렇게 나눈 이유: 읽는 쪽이 모두 같은 쿼리를 쓰게 해 정의를 한 곳에 둔다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '대사 미결 분석'
@Analytics.query : true
@ObjectModel.usageType.sizeCategory : #XL
define view entity ZC_OpenItemQuery
  with parameters
    @Consumption.derivation: { lookupEntity: 'I_FiscalYearPeriodForCmpnyCode' }
    P_FromPeriod : fiscper,
    P_ToPeriod   : fiscper
  as select from ZI_OpenItemCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
  HouseBank,
  @AnalyticsDetails.query.axis: #COLUMNS
  FiscalPeriod,
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
  TransactionCurrency,
  @Consumption.filter.hidden: false
  AgeBucket,
  @AnalyticsDetails.query.axis: #COLUMNS
  AriseAmount,
  ClearAmount,
  OpenAmount,
  LineCount
}
where FiscalPeriod >= $parameters.P_FromPeriod
  and FiscalPeriod <= $parameters.P_ToPeriod

⑥ 접근 제어 — ZR_OpenItemRole (DCL)

법인과 은행 단위로 볼 수 있는 범위를 정합니다. 쿼리 코드를 바꾸지 않고 권한만 따로 손볼 수 있도록 DCL 로 분리했습니다. 사용자가 권한이 없는 법인의 미결은 합계에서도 빠집니다.

" ─────────────────────────────────────────────────────────────
" ZR_OpenItemRole — 법인 · 은행 접근 제어
" 이렇게 나눈 이유: 권한 설계가 바뀌어도 쿼리는 그대로 둔다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '대사 미결 접근 제어'
@MappingRole: true
define role ZR_OpenItemRole {
  grant select on ZI_OpenItemCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의 · 바인딩

쿼리를 OData V2 서비스로 게시하는 마지막 층입니다. 이 서비스를 활성화한 뒤 화면의 서비스 주소만 교체하면 샘플 데이터에서 운영 데이터로 바뀝니다.

" ─────────────────────────────────────────────────────────────
" ZUI_OpenItem — 서비스 정의 · 바인딩
" 이렇게 나눈 이유: 게시 방식(OData V2/V4)을 쿼리와 분리한다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '대사 미결 분석 서비스'
define service ZUI_OpenItem {
  expose ZC_OpenItemQuery as OpenItemAnalysis;
  expose ZI_OpenItemCube  as OpenItemCube;
  expose ZI_OpenItemPlanCube as OpenItemPlan;
  expose ZI_BankDimension as Bank;
}

" 바인딩: 이름 ZUI_OpenItem_O2, 유형 OData V2 - Web API
"   → 게시(Publish) 후 /IWFND/MAINT_SERVICE 에서 활성화 확인

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영 연결 전에 합의해 둘 항목입니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
차이 유형 · 처리 단계 매핑	외부 거래 코드 · 계정 기호를 입금 · 출금 · 수수료 · 이자 미기표로 분류	미결이 기타로 쏠려 분석이 무의미	회계 담당 + 자금 담당
은행 · 계좌 매핑	하우스 뱅크 · 계정 ID 를 은행 차원에 연결	같은 은행이 계좌마다 따로 보임	자금 담당
환율 유형 · 환산 시점	월말 실적 환율, 예상용 환율, 환산 기준일	환율 요인과 합계가 달라짐	회계 담당
부호 규칙	입금 · 출금 미결의 표시 부호	합계가 상쇄되어 작아 보임	회계 담당
실적 · 예상 원천 확정	예상 버전(마감 전 예상)의 확정 시점과 입력 주체	요인분해의 기준이 흔들림	자금 담당 + 경영지원
권한 설계	법인 · 은행 단위 조회 범위	전 사용자가 전 법인을 봄	정보보안 + 자금 담당
대사 체계	표준 T-code(FBL3N · FS10N)와 맞출 항목과 허용 오차	두 화면 숫자가 다를 때 판단 기준이 없음	회계 담당
서비스 활성화와 화면 주소 교체	Binding 게시 · /IWFND/MAINT_SERVICE 활성화 · 매니페스트의 서비스 주소 교체	샘플 데이터 상태로 남음	IT 운영
전송(TR) 순서	기준 테이블 → 차원 → 큐브 → 쿼리 → DCL → 서비스	활성화 오류	IT 운영
배치 등록	에이전트 호출을 정기 배치(SM36)로 등록	자리에 없을 때 점검이 일어나지 않음	IT 운영

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

검증은 같은 자료 위에서 대사식마다 전수로 돌렸습니다. 도입 포인트의 사례(총차이 31.01억, 합계 검산 0)가 이 표의 마지막 두 줄과 같은 숫자입니다.

대사식	검사 건수	차이 건수
큐브 총합 ↔ 원천 총합(측정값 4종 × 큐브 키 736)	2,944	0
큐브 대사 결과(기간 9 × 측정값 5)	45	0
예상 큐브 ↔ 원천 예상 필드(4종 × 938행)	3,752	0
요인분해 검산(범위 35개, 예상 + 요인 − 실적)	35	0
요인분해 실적 ↔ 큐브 · 예상 ↔ 예상 큐브	2	0

의도적으로 둔 예외는 0건입니다. 큐브 합계 4,578.10억, 예상 합계 4,547.09억, 두 값의 차이 31.01억이 요인 여섯 개의 합 +31.01억과 일치합니다. 외화 금액은 통화가 다른 것끼리 더하지 않고 원화 환산액으로만 합산했습니다.

운영 데이터로 갈 때

은행 명세서 라인이 수천만 건인 환경에서는 큐브를 화면에서 읽지 않고 뷰에서 집계하는 것이 기본입니다. 쿼리의 월 범위를 필수 파라미터로 두어 전체 기간을 읽는 호출을 막고, 법인과 은행에는 선택 조건을 권합니다. 큐브 한 번의 응답은 수 초 안에 끝나는 크기(수만 행 이하)로 설계하고, 그보다 커지면 월 단위로 나눠 읽거나 집계 테이블을 둡니다. 원천 라인 드릴스루는 집계가 아니라 조회이므로 건수를 먼저 세고 상한을 넘으면 범위를 좁히라고 안내합니다. 인덱스는 법인 · 계정 · 전기일 순서를 권장하며 실제 시스템에서 확인이 필요합니다.

자주 묻는 질문

도입 검토와 데모에서 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

이 앱은 무엇을 점검합니까?

은행 대사에서 남은 미결의 발생 · 정리 · 기말 잔액을 은행 · 법인 · 통화 · 경과 구간 등으로 겹쳐 보고, 마감 전 예상과 실적의 차이를 요인으로 나눕니다. 점검 필요 항목을 찾는 도구이며, 최종 판단은 회사와 감사인이 합니다.

금액은 어디서 계산합니까?

금액은 서비스가 계산하고 화면은 읽어 보여 줍니다. 요인분해 · 해설 · 에이전트 판정도 서비스 함수가 계산하며, 같은 계산 모듈을 화면의 재집계도 쓰므로 두 곳의 숫자가 갈라지지 않습니다.

외화 금액은 어떻게 합산합니까?

통화가 다른 외화 금액을 그대로 더하면 의미가 없으므로 원화 환산액으로만 합산합니다. 환산은 월말 환율을 쓰고, 예상은 직전 월말 환율로 환산합니다.

환율 요인은 예상 환율과 실적 환율의 차이로 생긴 몫을 따로 보여 줍니다. 이번 샘플 자료의 환율은 가정값이며 실제 고시값이 아닙니다.

요인분해의 검산 줄은 무엇입니까?

예상 + 여섯 요인의 합 − 실적이 0인지 매번 확인하는 줄입니다. 0이 아니면 점검 필요 신호입니다. 이번 자료에서는 범위 35개(전체, 은행 5, 법인 4, 차이 유형 4, 통화 5, 경과 구간 4, 보류 2, 기간 9 등) 모두 0이었습니다.

발생 월 이동 요인이 0으로 나옵니다. 오류입니까?

아닙니다. 월 이동은 같은 건이 예상과 실적에서 다른 달에 잡힐 때 생기는 몫인데, 조회 범위에 두 달이 모두 들어 있으면 예상 초과 · 예상 미달 쪽에서 상쇄되어 0이 됩니다. 한 달만 조회하면 값이 나옵니다. 이 성질은 검증 때 확인해 두었습니다.

정리율은 왜 칸마다 평균 내지 않습니까?

정리율은 분자와 분모가 다른 비율이라 칸의 비율을 평균하면 큰 칸과 작은 칸이 같은 무게로 섞여 왜곡됩니다. 그래서 합계 칸에서 정리액과 정리 대상액을 각각 더한 뒤 다시 나눕니다.

화면과 조작

축을 바꾸면 서버를 다시 부릅니까?

아닙니다. 조회 때 읽어 둔 큐브 안에서 다시 묶으므로 서버 요청은 0건이고, 총합도 바뀌지 않습니다. 이번 검증에서 일곱 가지 배치의 발생 미결 합계가 모두 4,578.10억으로 같았습니다.

열 축을 3단계로 놓을 수 없는 이유가 있습니까?

열이 곱셈으로 늘어 표가 읽히지 않기 때문에 두 단계까지로 막아 두었습니다. 세 번째 차원을 놓으려 하면 추가하지 않고 안내가 뜹니다. 필요한 차원은 행 축으로 옮기거나 값 필터로 범위를 줄입니다.

칸의 숫자를 누르면 무엇이 열립니까?

그 칸을 이루는 원천 라인이 열리고, 원천 합계가 칸 금액과 같은지 상단에 표시됩니다. 가상 시중은행 A 칸은 967건 1,511.61억이 표의 값과 일치했습니다. 라인이 너무 많으면 건수만 먼저 알려 주고 범위를 좁히라고 안내합니다.

보는 사람(역할)을 바꾸면 무엇이 달라집니까?

경영 · 재무 · 자금 · 회계 네 역할에 따라 먼저 놓이는 행 · 열 축과 측정값, 안내 문구가 달라집니다. 데이터는 같고 서비스를 다시 부르지 않습니다. 권한과는 별개이며, 접근 범위는 권한 설계가 정합니다.

저장한 보기는 어디에 남습니까?

서비스의 보기 저장 집합에 남습니다. 이름을 붙이고 기본 보기로 정하면 다음에 열 때 그 모습으로 시작하고, 자동 조회를 켜면 열자마자 조회됩니다.

휴대폰에서도 쓸 수 있습니까?

좁은 폭에서는 지표가 줄바꿈되고 차트가 표 아래로 내려옵니다. 390px 폭에서 가로 스크롤 없이 열립니다. 다만 표가 넓어 가로 스크롤이 필요한 것은 데스크톱 화면과 같습니다.

분석 기능

변동 사유는 어디에 저장됩니까?

서비스의 변동 사유 집합에 조회 범위와 행 경로를 키로 저장됩니다. 축을 바꾸거나 다음 달에 다시 열어도 같은 행에 따라오고, CSV와 해설 근거에도 함께 실립니다.

해설은 어떻게 만들어집니까?

서비스가 선택한 범위의 금액과 비율을 계산해 근거 표로 넘기고, 그 숫자를 규칙으로 읽어 문장 초안을 만듭니다. 운영에서 언어 모델을 연결하더라도 숫자는 서비스가 계산한 값을 넘기고 모델은 설명만 합니다. 문장은 초안이므로 근거 표와 함께 읽고 쓰는 것을 권합니다.

에이전트는 하루에 몇 번 돕니까?

하루 한 번입니다. 같은 날 두 번째 실행은 서버가 제한으로 돌려줍니다. 규칙은 네 개(단일 은행 비중 상한, 보류 건 잔액 비중 상한, 정리율 하한, 예상 차이 임계)이고, 첫 실행에서 4건이 대기함에 올라갔습니다.

사람이 자리에 없을 때도 점검이 됩니까?

판정과 기록이 화면이 아니라 서비스에 있어서 가능합니다. 정기 배치(SM36 등)가 같은 호출을 대신하면 사람이 화면을 열지 않아도 점검이 이뤄집니다. 배치 등록은 운영 연결 때 IT 운영이 합니다.

예상 대비 차이에서 색은 언제 붙습니까?

금액 기준 300백만원과 비율 기준 5%를 둘 다 넘을 때만 붙습니다. 작은 금액의 큰 비율이나 큰 금액의 작은 비율에 눈이 끌리지 않게 하려는 것입니다. 기준값은 회사에 맞게 조정할 수 있는 샘플입니다.

도입과 운영

도입하면 어떤 효과가 있습니까?

마감 회의에서 미결의 쏠림 · 정리 속도 · 예상 대비 차이를 한 화면에서 같은 숫자로 읽을 수 있습니다. 숫자 이의가 나오면 칸에서 원천 라인까지 내려가 그 자리에서 맞춰 볼 수 있습니다. 효과 수치(시간 절감률 등)는 자료에서 측정하지 않아 제시하지 않습니다.

SAP 표준 T-code 를 대체합니까?

아닙니다. 명세서 입력(FF_5 · FF67), 후처리(FEBAN), 계정 라인 조회(FBL3N), 전표 조회(FB03), 계정 잔액(FS10N) 같은 표준 실행은 계속 표준 T-code 가 담당하고, 이 앱은 조회 · 검증 관점을 더해 확장합니다. 법정 · 감사 · 세무 신고에 쓰는 보고도 표준에 남겨 둡니다.

운영 데이터로 연결하려면 무엇이 필요합니까?

CDS 구성(큐브 · 예상 큐브 · 쿼리 · 권한)을 전송하고, 서비스를 게시해 활성화한 뒤 화면의 서비스 주소를 교체합니다. 그 전에 차이 유형 · 은행 · 환율 매핑을 합의해야 하며, 소요는 매핑 합의에 좌우됩니다. 코드 작업보다 정하는 일이 더 걸립니다.

권한과 보안은 어떻게 다룹니까?

법인과 은행 단위 접근을 DCL 로 정합니다. 권한이 없는 법인의 미결은 합계에서도 빠집니다. 보는 사람(역할)은 화면 구성을 바꾸는 것이지 권한이 아닙니다.

대용량에서도 쓸 수 있습니까?

쿼리의 월 범위를 필수 파라미터로 두고 집계는 뷰에서 하는 것이 기본입니다. 한 번에 읽는 큐브를 수만 행 이하로 설계하고, 원천 라인은 건수를 먼저 센 뒤 상한을 넘으면 범위를 좁히게 합니다. 실제 응답 시간은 고객사 환경에서 확인이 필요합니다.

계정 체계나 매핑이 바뀌면 어떻게 됩니까?

매핑은 기준 테이블의 데이터이므로 뷰를 고치지 않고 데이터만 바꿉니다. 바꾼 뒤에는 큐브 합계와 원천 합계를 다시 맞춰 보고, 검증 표의 대사식을 다시 돌리는 것을 권합니다.

이 앱이 내는 결과를 그대로 신고나 공시에 써도 됩니까?

권하지 않습니다. 이 앱은 내부 점검 도구이며 최종 판단은 회사와 감사인이 합니다. 세무 신고는 회사와 세무 대리인이 판단합니다. 공시와 신고에는 표준 화면의 확정 자료를 씁니다.

IAS 7 · IFRS 7 과는 어떤 관계입니까?

현금 · 유동성 점검의 참고 관점입니다. 이 앱이 기준서 요구를 충족했다고 단정하지 않으며, 문단 번호와 세부 요구는 원문 확인이 필요합니다.