SAP 발생·이연 결산 통합 관리 — 약정·선급·송장에서 승인·대사·다차원 분석까지 한 앱에서 끝내는 월 마감

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

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

월 마감 때마다 같은 질문이 돌아옵니다. 이번 달 약정과 선급, 송장 때문에 만들어야 할 전표는 다 만들었나, 누가 승인했나, 장부 잔액과 대상 정보가 맞나. 지금은 이 답이 표준 T-code 여러 개와 엑셀 일정표, 메일 승인 사이에 흩어져 있어 마감 직전에 몰아서 맞춥니다. 이 앱은 약정·선급·송장 대상에서 시작해 월 발생 계상, 선급 상각, 송장 정산 문서를 만들고 승인·전기·대사·분석까지 한 화면의 흐름으로 이어, 마감 절차 진행률과 예외를 같은 자리에서 보게 합니다.

이 영역에는 특정 기준서의 요구사항이 정해져 있지 않으므로(해당 기준서 없음 — 영역: 결산의 발생·이연 처리), 앱은 회사의 결산 절차를 따라 업무 처리와 점검을 돕는 도구로 동작합니다. 표준 실행(전표 입력 · 역분개 · 개별 항목 조회)은 SAP 표준 T-code 가 담당하고, 이 화면은 대상 관리 · 일괄 실행 · 대사 · 분석 관점을 더해 확장합니다.

한 줄 요약 — 조회 화면은 누구나 만듭니다. 이 앱의 값은 처리 다음에 있습니다 — 금액을 사람이 옮겨 적지 않고 대상에서 계산하고, 승인과 직무 분리를 서버가 판정하며, 대사 예외를 조치까지 추적하고, 분석 숫자를 전표 라인까지 따라갑니다.

핵심 포인트 여덟 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 마감 절차 51건을 한 화면에서 챙깁니다	단계별 진행률 · 기한 경과 · 내 할 일이 개요 한 장에 모이고, 항목을 누르면 문서·예외로 바로 갑니다.	엑셀 일정표와 메일로 진행 상황을 모으고 담당자에게 묻습니다.
② 약정·선급·송장을 앱에서 관리합니다	대상을 등록하면 월 금액이 계산되고, 문서 금액은 직접 입력하지 않으므로 숫자가 흔들리지 않습니다.	계약서별 엑셀에 월 금액을 적어 두고 전표 입력 때 옮겨 적습니다.
③ 승인과 직무 분리를 서버가 판정합니다	작성자는 자기 문서를 승인할 수 없고 5천만 원 이상은 서로 다른 2인이 승인합니다. 화면 버튼은 서버 값대로만 보입니다.	메일 승인과 구두 확인에 의존해 누가 승인했는지 나중에 맞춰 봅니다.
④ 일괄 실행은 모의 실행부터 합니다	모의 실행으로 대상과 합계를 보고, 실행하면 문서가 만들어지며, 같은 조건을 다시 실행해도 중복되지 않습니다.	월말에 전표를 손으로 만들다 빠진 약정을 뒤늦게 발견합니다.
⑤ 대사 예외를 조치까지 이어서 정리합니다	규칙 네 가지로 점검하고 예외마다 조정 전표 · 사유 · 보류를 남긴 뒤 재대사로 해소를 확인합니다.	차이 목록을 엑셀로 뽑아 메일로 돌리고 조치 결과는 따로 기록합니다.
⑥ 숫자를 문서 라인까지 따라갑니다	다차원 분석에서 축을 바꿔도 총합이 같고, 칸을 누르면 전표 명세와 문서 상세까지 내려갑니다.	요약표와 원장을 번갈아 열어 합계를 맞춰 봅니다.
⑦ 다른 영역으로 이어진 문서를 한 번에 봅니다	발생·상각 문서를 전기하면 원가(CO) 귀속 문서가, 송장 정산을 전기하면 구매(MM) 송장 연계와 자금(TR) 지급 예정 문서가 따라옵니다.	영역마다 화면을 열어 문서 번호를 찾아 이어 봅니다.
⑧ 에이전트가 먼저 알려 줍니다	감시 규칙 네 가지가 하루 한 번 점검해 받을 역할의 대기함에 보고를 올리고, 해설은 외부 AI 없이도 규칙 기반으로 나옵니다.	마감이 끝난 뒤에야 적체와 초과를 알게 됩니다.

사례로 보는 효과

아래는 모두 검증용 샘플 데이터에서 실제로 나온 숫자입니다(운영 효과 수치가 아닙니다).

검증용 샘플 데이터 기준 7~9월 처리 금액은 14,278,070,000원이고, 계획 대비 +105,056,830원(+0.7%)입니다. 요인 분해는 9월 차이 41,139,739원을 요인별로 나눠 그 합계가 총차이와 일치하는지 한 줄로 보여 줍니다.
월 발생 계상 모의 실행에서 계상이 빠진 약정이 대상으로 나옵니다(샘플: 처리 금액 15,200,000원 1건). 실행하면 문서가 만들어지고, 같은 조건을 다시 실행하면 이미 있는 문서는 만들지 않습니다.
대사 규칙 네 가지의 점검 건수는 15 · 39 · 29 · 9건이고, 의도적으로 넣어 둔 예외 24건은 대사 차이 건수와 따로 집계합니다.

도입하면 달라지는 것

마감 회의가 엑셀 취합이 아니라 개요의 진행률과 예외 목록을 보는 시간으로 바뀝니다.
전표 금액을 사람이 옮겨 적지 않으므로 대상 정보만 맞추면 월 계상·상각액이 같은 규칙으로 나옵니다.
승인 기록 · 상태 이력 · 감사 로그가 같은 앱에 남아 누가 언제 무엇을 했는지 바로 찾습니다.
대사 예외가 조치 상태까지 추적되어 마감 직전 몰아서 정리하는 일이 줄어듭니다.
원가 · 구매 · 자금으로 이어진 문서를 따라가며 부서 간 확인 요청을 줄입니다.

이런 회사에 맞습니다

월 마감에서 약정 · 선급 · 송장에 따른 발생·이연 전표를 매달 반복해서 만드는 회사에 맞습니다. 법인이 둘 이상이고 계정과목이 여러 개이며, 작성과 승인을 나누고 원가 귀속까지 이어 보아야 하는 조직(재무팀 · 회계팀 · 세무팀 · 자금팀이 함께 마감하는 곳)에서 효과가 큽니다.

실행 화면 — 처음 열어서 마감까지

사용 방법

조회 범위를 고릅니다. 화면 위쪽 바에서 기간(필수, 기본은 가장 최근에 열린 기간 2026-09)과 회사(선택, 비우면 전체)를 고릅니다. 오른쪽 사용자 선택은 데모 역할을 바꾸는 자리입니다.
왼쪽 메뉴를 위에서 아래로 따라갑니다. 개요·할 일 → 기준정보·결산 일정 → 문서 처리 → 일괄 실행 → 대사·예외 → 결산 분석 → 영역 간 연계 → 이력·감사·권한 순서가 월 결산 흐름과 같습니다.
개요에서 숫자와 할 일을 먼저 봅니다. KPI 타일과 단계별 진행률을 확인하고, 타일이나 할 일 줄을 누르면 해당 문서·예외·과업으로 이동합니다.
조회합니다. 기준정보·문서·대사 화면은 상단 필터를 바꾸면 목록이 바로 다시 그려집니다. 결산 분석은 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 Enter 키를 누르면 조회하고, 기본 레이아웃에 자동 조회를 지정해 두면 열 때 바로 조회합니다.
탭과 축을 옮겨 봅니다. 분석에서는 차원 칩을 행·열 칸으로 끌어 놓거나 이동 메뉴로 옮깁니다. 서비스를 다시 부르지 않고 바로 다시 그려집니다.
행이나 칸을 눌러 상세를 봅니다. 문서 행은 분개·상태 이력·연계 문서 탭이 있는 상세로, 분석 칸은 전표 명세(드릴스루)로 열립니다. 전표 명세의 문서 번호를 누르면 문서 상세로 갑니다.
처리합니다. 문서는 검토 요청 → 승인 → 전기 순서이고, 일괄 실행은 모의 실행 뒤에 실행합니다. 대사 예외는 조정 전표·사유·보류로 조치합니다.
내려받습니다. 결산 분석 위쪽의 표 CSV(사유 포함)와 PPT 보고서(현재 범위의 표와 차트), 기준정보의 엑셀 양식·내보내기를 씁니다.

조회자 역할은 읽기 전용입니다. 쓰기·처리 버튼이 꺼지고 직접 요청해도 서비스가 권한 없음으로 거절합니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면	OpenUI5 1.153 표준 컨트롤(`sap.m` · `sap.f` · `sap.tnt` · `sap.ui.table`), 모듈 여덟 개, 직접 그린 SVG 차트	표준 컨트롤만 써서 사내망에서도 외부 라이브러리 반입 심사가 필요 없고, 테마(Horizon)가 SAP 화면과 같은 결을 유지합니다.
집계·판정 로직	서비스 쪽 업무 규칙 파일(상태 전이 · 채번 · 검증 · 대사 · 계산)과 브라우저 쪽 큐브 집계	판단과 기록을 화면이 아니라 서비스에 두어, 화면을 거치지 않은 요청도 같은 규칙으로 판정합니다.
OData 서비스 구성	OData V2 서비스 하나를 앱 설정의 데이터 소스로 선언하고, 기본 모델로 목록을 바인딩합니다. 생성·수정은 모델의 create · update, 처리 동작은 함수 호출(callFunction)입니다. 필터·정렬은 서비스의 $filter · $orderby 로 보내고, 날짜 조건도 서비스가 직접 평가합니다.	운영 전환 때 데이터 소스의 주소만 바꾸면 같은 화면이 운영 서비스를 바라봅니다.
권한	요청 머리의 사용자 값으로 서비스가 역할(조회자 · 처리자 · 승인자 · 관리자)을 판정	버튼을 숨기는 것으로 끝내지 않고 직접 요청도 서비스가 거절합니다. 운영에서는 PFCG 역할로 바꿉니다.
테마	sap_horizon	SAP 표준 화면과 같은 색·글꼴·간격을 씁니다.

항목	내용
영역	결산
업무 흐름 범위	약정·선급·송장 대상 → 발생 계상·선급 상각·송장 정산 문서 → 승인·전기 → 원가·구매·자금 연계 문서 → 대사 예외 조치 → 다차원 분석
모듈 구성	개요·할 일 · 기준정보·결산 일정 · 문서 처리 · 일괄 실행 · 대사·예외 · 결산 분석 · 영역 간 연계 · 이력·감사·권한
관련 기준서·대상 영역	해당 기준서 없음 — 영역: 결산(발생·이연 처리)
SAP 표준 T-code	FBS1 · F.81 · FB50 · FB08 · FB03 · FBL3N · FAGLB03 · FBL1N · MIRO · KSB1 · F110 · OB52
화면 성격	통합 관리(조회 + 처리 + 분석)
데이터 연동	OData V2 서비스 한 개
테마	sap_horizon

SAP 표준 기능을 그대로 이어받은 부분 — 전표의 차변·대변 구조와 전기 기간(열린 기간) 판정, 원가 귀속 문서와 구매 송장·지급 예정 문서로 이어지는 문서 흐름, 계정 보조원장·총계정 잔액의 대사 개념은 표준 데이터 구조를 그대로 이어받습니다. 표준 실행은 SAP 표준 T-code 가 담당하고 이 화면은 처리·대사·분석 관점을 더해 확장합니다.

처음 열었을 때 — 내 할 일과 진행 상황을 먼저 본다

**처음 열었을 때 — 내 할 일과 결산 진행** — KPI 타일 여섯 개와 내 할 일이 한 화면에 모입니다.

결산 진행률 · 기한 경과 과업 · 승인 대기 · 반려 · 대사 예외 · 일 마감 보고 타일이 보입니다. 타일이나 할 일 줄을 누르면 해당 문서 · 예외 · 과업으로 이동합니다. 기본 기간은 가장 최근에 열린 기간(2026-09)입니다.

**결산 단계별 진행** — 사전 점검부터 마감 보고까지 다섯 단계의 완료율을 막대로 봅니다.

단계 이름 아래 완료 건수와 지연 건수가 함께 표시됩니다. 아래 할 일 목록은 역할에 맞는 항목만 나오며 기한이 임박한 것이 앞에 옵니다.

기준정보 — 약정·선급·송장을 앱에서 관리한다

**기준정보 — 계정** — 계정별 보조원장 잔액과 총계정 잔액을 같이 관리합니다.

보조원장 사용 계정은 두 잔액이 나란히 보이고, 수정 · 변경 이력 · 사용 중지를 줄 끝 버튼으로 합니다. 쓰기는 처리자와 관리자만 가능합니다.

**기준정보 — 원가센터** — 원가 귀속에 쓰는 원가센터를 법인별로 둡니다.

코드는 영문 대문자와 숫자 4~10자이며 같은 법인에서 중복 코드는 거절됩니다. 기준정보를 바꾸는 쪽은 처리자와 관리자이고, 조회자는 목록만 봅니다.

**기준정보 — 약정 · 선급 · 송장** — 발생 약정 · 선급 이연 · 청구 송장 대상 95건을 한 표에서 봅니다.

구분 필터로 약정(AC) · 선급(PP) · 송장(ST)을 나눠 봅니다. 월 금액은 기준 금액과 개월 수로 계산되어 표시되고 누계는 전기된 문서가 쌓은 값입니다.

**기준정보 — 신규 입력** — 구분에 따라 필요한 칸만 입력하게 합니다.

선급은 기준 금액과 상각 개월 수, 송장은 청구 금액, 약정은 월 금액 기준을 입력합니다. 필수값이 비면 저장 전에 알려 줍니다.

**기준정보 — 입력값 점검** — 상각 개월 수가 범위를 벗어나면 서버가 거절 메시지를 돌려줍니다.

개월 수는 2~60 사이여야 하며, 거절 사유는 서버가 보낸 문구 그대로 대화상자에 나옵니다. 저장 전 입력값 점검과 서비스의 거절이 같은 기준을 씁니다.

**기준정보 — 저장 뒤 목록** — 저장하면 탭의 건수가 하나 늘고 목록에 나타납니다.

저장은 서비스에 기록되며 새로 고쳐도 남습니다. 변경 이력에서 누가 언제 어떤 값을 바꿨는지 볼 수 있습니다.

**기준정보 — 결산 과업** — 결산 과업 51건의 일정과 상태를 시작 · 완료 · 되돌림으로 관리합니다.

선행 과업이 끝나지 않으면 시작할 수 없고, 계획일을 넘기면 지연 일수가 표시됩니다. 과업 상태는 개요의 진행률 타일에 바로 반영됩니다.

**기준정보 — 엑셀 일괄 업로드** — 정상 3건과 점검 필요 1건이 있는 파일을 미리보기로 확인합니다.

반영 전에 행마다 정상 여부가 표시되고, 반영 버튼은 정상 건만 저장합니다. 양식은 같은 대화상자에서 내려받습니다.

문서 처리와 승인 — 승인 버튼은 승인자에게만 보인다

**문서 처리 — 목록** — 발생 계상 · 선급 상각 · 송장 정산 문서 목록입니다.

상태 · 유형 · 내가 작성한 것만으로 걸러 보며, 상태는 시맨틱 색으로 구분합니다. 금액은 대상 정보에서 계산되어 사람이 고치지 않습니다.

**문서 처리 — 직무 분리** — 작성자는 자기 문서를 승인할 수 없다는 안내가 상세에 보입니다.

상세는 분개 · 상태 이력 · 연계 문서 탭으로 나뉩니다. 직접 요청해도 서버가 같은 이유로 거절하고 그 메시지를 대화상자로 보여 줍니다.

**문서 처리 — 송장 정산 분개** — 송장 정산은 미지급 청산과 추가 비용 또는 환입을 함께 분개합니다.

차변 합계와 대변 합계가 같을 때만 전기됩니다. 5천만 원 이상은 2인 승인 단계가 표시됩니다.

**문서 처리 — 신규 문서** — 대상을 고르면 금액이 계산되어 만들어집니다.

같은 대상 · 같은 기간의 문서가 이미 있으면 만들 수 없습니다. 금액을 직접 입력하는 칸은 없고 대상에서 계산됩니다.

**문서 처리 — 중복 생성 거절** — 이미 있는 대상 · 기간의 문서를 다시 만들면 서버가 거절합니다.

메시지에 기존 문서 번호가 나오므로 그 문서로 이동해 이어서 처리합니다. 거절은 화면이 아니라 서비스가 판정한 것이어서 같은 요청은 어디서 보내도 같은 결과입니다.

**문서 처리 — 전기와 원가 귀속** — 전기하면 원가 귀속 문서가 자동으로 만들어집니다.

연계 문서 탭에 재무 문서와 원가 문서가 같이 보이고, 상태 이력 탭에 승인 · 전기 시각이 남습니다. 원가 귀속 문서는 전기와 같은 시점에 만들어져 문서 번호가 연결됩니다.

**문서 처리 — 역처리** — 전기된 문서를 취소하면 반대 문서가 원문서와 연결되어 만들어집니다.

역처리 문서의 금액은 원문서 금액의 부호를 바꾼 값이며, 사유는 필수입니다. 역처리 문서도 상태 이력에 남아 원문서와 함께 추적됩니다.

일괄 실행 — 모의 실행 합계와 실행 결과가 같다

**일괄 실행 — 조건과 모의 실행** — 유형 · 회사 · 기간을 고르고 모의 실행으로 대상과 합계를 먼저 봅니다.

모의 실행 없이는 실행 버튼이 켜지지 않습니다. 이미 문서가 있는 대상은 제외되고 계상이 빠진 약정이 대상에 나옵니다.

**일괄 실행 — 실행 결과와 로그** — 실행하면 만들어진 문서 수와 합계가 실행 이력에 남습니다.

모의 실행 합계와 실행 뒤 문서 합계가 같으며, 같은 조건을 다시 실행해도 새 문서가 생기지 않습니다. 실행 로그에는 대상별로 만들어진 문서 번호가 적힙니다.

대사와 예외 조치 — 차이를 조치하고 다시 대사한다

**대사 — 규칙별 결과와 예외 목록** — 규칙 네 가지의 점검 건수 · 차이 건수 · 최대 차이를 봅니다.

보조원장 대 총계정, 발생 월 수, 선급 상각 누계, 송장 청구 금액을 점검합니다. 예외는 미처리 · 조치 중 · 보류 · 해소 상태로 추적합니다.

**대사 — 조정 전표 만들기** — 금액 예외는 사유를 적고 조정 전표를 만들어 조치합니다.

조정 전표는 일반 문서와 같은 승인 · 전기 흐름을 탑니다. 계상 월 수 차이는 발생 일괄 실행으로 정리합니다.

**대사 — 재대사와 해소** — 조정 전표를 전기한 뒤 다시 대사하면 해당 예외가 해소 상태가 됩니다.

대사를 다시 실행하면 새 결과가 쌓이고 해소된 예외는 별도 상태로 남아 이력을 볼 수 있습니다. 해소된 예외는 목록에서 사라지는 것이 아니라 상태가 바뀌어 이력으로 남습니다.

분석 — 축을 바꿔도 총합은 같고 칸은 문서까지 내려간다

**분석 — 계획 대비 피벗** — 결산 단계와 담당 팀을 행으로 놓고 계획 대비 차이를 봅니다.

기준 대비 열은 금액과 비율을 모두 넘을 때만 색이 입혀집니다. 오른쪽 차트는 같은 조건의 막대와 워터폴입니다.

**분석 — 축 바꾸기** — 차원 칩을 끌어 행 · 열 칸으로 옮기면 즉시 다시 그려집니다.

축을 바꿔도 서비스를 다시 부르지 않고, 어떤 배치에서도 총합이 같습니다. 칩의 이동 메뉴로 키보드로도 옮깁니다.

**분석 — 행 펼침** — 행을 펼쳐 담당 팀별 금액을 단계별로 내려 봅니다.

행 수가 많으면 단계마다 상위 항목만 보이고 나머지는 합쳐서 알려 줍니다. 행을 펼쳐도 서비스를 다시 부르지 않고 이미 읽어 둔 큐브에서 바로 그립니다.

**분석 — 드릴스루** — 칸의 금액을 누르면 그 칸을 이루는 전표 명세가 열립니다.

명세 합계와 칸 금액이 같은지 한 줄로 비교해 보여 줍니다. 명세 합계가 칸 금액과 같은지 위쪽 한 줄이 알려 줍니다.

**분석 — 문서 상세로 이동** — 전표 명세의 문서 번호를 누르면 문서 처리 화면 상세로 갑니다.

분석에서 본 숫자의 출처를 문서의 분개와 승인 이력까지 따라갈 수 있습니다. 문서 상세에서 연계 문서와 상태 이력까지 이어서 봅니다.

**분석 — 다중 필터와 계산 항목** — 여러 값을 고른 필터와 비율 계산 항목을 함께 씁니다.

다중 선택 후 합계는 선택한 값들의 큐브 합과 같습니다. 계산 항목은 토큰 식으로 정의되며 열 또는 단계별 행으로 놓습니다.

**분석 — 요인 분해와 워터폴** — 총 차이를 라인 수 효과와 평균 금액 효과로 나눕니다.

요인 합계가 전체 차이와 같은지 아래 한 줄로 확인합니다. 원인을 단정하지 않고 점검할 곳을 알려 줍니다.

**분석 — 역할별 보기** — 재무책임자 · 결산책임자 · 회계담당 보기가 서로 다른 배치로 열립니다.

역할을 바꾸면 행 · 열 · 지표가 그 역할이 보는 요약으로 바뀝니다. 역할 보기는 행·열·지표의 기본 배치만 바꾸며 숫자는 같은 큐브에서 나옵니다.

**분석 — 사유 적기** — 차이가 난 행에 분류와 사유를 적어 둡니다.

저장한 사유는 새로 고쳐도 남고 해설에서 그 단계를 설명하는 근거로 쓰입니다. 사유가 있는 행은 요인 분해 해설에서 건너뛰고 적어 둔 사유를 근거로 씁니다.

영역 간 연계 — 재무 문서가 원가·구매·자금으로 이어진다

**영역 간 연계 — 문서 흐름도** — 재무 문서가 원가 · 구매 · 자금으로 이어진 흐름을 한 화면에서 따라갑니다.

흐름도의 상자를 누르면 해당 문서 상세가 열립니다. 재무 → 원가 496건, 구매 27건, 자금 27건의 연결이 샘플에 있습니다.

AI 분석과 에이전트 — 먼저 알려 주는 보고 대기함

**AI 분석 — 해설** — 요인 분해 결과를 규칙 기반 해설로 읽어 줍니다.

외부 AI 모델이 연결되지 않은 상태에서도 해설이 나오며, 근거 표를 펼치면 숫자의 출처를 확인합니다. 모델이 연결되어 있지 않아도 같은 화면에서 같은 숫자의 해설이 나옵니다.

**AI 분석 — 근거 표** — 해설의 문장마다 서비스가 집계한 근거 표가 따라옵니다.

문장은 점검 참고용이고 숫자는 서비스 집계값입니다. 숫자를 만드는 것은 서비스이고 해설은 그 숫자를 읽어 줄 뿐입니다.

**에이전트 — 보고 대기함** — 감시 규칙에 걸린 보고가 받을 역할의 대기함에 올라옵니다.

규칙은 기한 경과 · 미처리 예외 · 계획 초과 · 승인 적체 네 가지이며 확인 버튼으로 읽음 처리합니다. 확인하면 읽음 처리되고 대기함에서 뒤로 물러납니다.

**에이전트 — 하루 한 번 제한** — 점검을 다시 실행하면 서버가 하루 한 번 제한으로 판정합니다.

실행 기록에는 호출 주체와 시각이 남고, 제한에 걸린 호출은 기록을 늘리지 않습니다. 점검이 필요 없는 날에도 호출 기록은 남습니다.

**에이전트 — 감시 규칙** — 규칙의 지표 · 기준값 · 받을 역할을 관리자가 조정합니다.

기준값을 바꾸면 다음 점검부터 적용됩니다. 규칙을 끄거나 켜는 것도 감사 로그에 남습니다.

이력·감사·역할 — 누가 무엇을 했는지 남는다

**감사 — 이력과 로그** — 누가 · 언제 · 무엇을 · 이전과 이후 값을 로그로 봅니다.

모든 쓰기 · 전이 · 실행 요청이 한 줄씩 남으며 거절된 요청도 결과 열에 표시됩니다. 거절된 요청이 어떤 이유로 막혔는지도 이 화면에서 찾습니다.

**역할 — 사용자와 권한** — 조회자 · 처리자 · 승인자 · 관리자의 기능 차이를 표로 봅니다.

화면 상단 사용자 선택으로 역할을 바꿔 가며 버튼이 어떻게 달라지는지 확인합니다(데모 사용자). 읽기 전용·처리·승인·관리 네 가지 역할의 기능 차이를 한눈에 봅니다.

**역할 — 조회자 화면** — 조회자로 바꾸면 쓰기 · 처리 버튼이 꺼집니다.

버튼을 숨기는 것으로 끝나지 않고 직접 요청해도 서버가 권한 없음으로 거절합니다. 같은 문서를 처리자 화면과 비교하면 버튼이 어떻게 달라지는지 알 수 있습니다.

레이아웃과 좁은 화면 — 저장한 배치로 열고 폰에서도 본다

**레이아웃 — 저장** — 현재 축 배치와 조건을 이름을 붙여 저장합니다.

저장한 레이아웃은 사용자별이며 다른 사람은 고칠 수 없습니다. 저장은 사용자별이어서 다른 사람의 배치를 덮어쓰지 않습니다.

**레이아웃 — 기본 · 자동 조회** — 기본 레이아웃과 자동 조회를 지정하면 열자마자 조회된 채 시작합니다.

새로 고침한 뒤에도 같은 배치로 열립니다. 기본 레이아웃은 사용자마다 하나씩 지정합니다.

**좁은 화면 — 개요** — 390px 폭에서 KPI 타일이 세로로 쌓입니다.

상단 바는 간소화되고 내 할 일이 이어서 나옵니다. 위쪽 바는 간소화되고 내 할 일이 이어서 나옵니다.

**좁은 화면 — 메뉴 접힘** — 메뉴는 단추를 눌러 펼치고 항목을 고르면 다시 접힙니다.

좁은 폭에서도 여덟 모듈에 모두 닿을 수 있습니다. 메뉴는 단추를 눌러 펼치고 항목을 고르면 다시 접힙니다.

**좁은 화면 — 차트가 표 아래로** — 분석에서는 차트가 표 아래로 내려갑니다.

표는 가로로 밀어 보고 차트는 폭에 맞게 줄어듭니다. 차트 폭은 화면 폭에 맞게 자동으로 줄어듭니다.

화면 뒤에서 일어나는 일

금액은 서버가 계산합니다 — 문서 금액은 대상의 기준 금액·개월 수에서 서비스가 계산하며 화면에서 고칠 수 없습니다. 조정 전표만 사유와 함께 금액을 입력합니다.
상태 전이는 서버가 판정합니다 — 표에 없는 전이 요청은 HTTP 400 으로 거절되고 사유 문구가 대화상자에 그대로 나옵니다. 작성자는 자기 문서를 승인할 수 없고 5천만 원 이상은 서로 다른 2인이 승인해야 합니다.
같은 조건의 반복 실행은 중복되지 않습니다 — 같은 대상·같은 기간의 문서가 이미 있으면 새로 만들지 않고 제외합니다.
모든 쓰기와 거절이 기록됩니다 — 쓰기·전이·실행 요청마다 누가 · 언제 · 무엇을 · 이전과 이후 값이 감사 로그에 남고, 거절된 요청도 결과 열에 남습니다.

문서 상태 판정 — 조건, 결과, 사용자 조치

현재 상태	판정 조건	결과 상태	사용자 조치
DRAFT(작성중)	차대 일치 · 필수값 충족	검토 요청 → REVIEW	작성자가 고치거나 검토 요청
REVIEW(검토중)	승인자(작성자 제외)가 승인	APPROVED(승인됨) · 5천만 원 이상은 서로 다른 2인	승인 또는 사유를 적어 반려
REVIEW	승인자가 반려	REJECTED(반려)	작성자가 고쳐 다시 검토 요청
APPROVED	열린 기간에서 전기	POSTED(전기됨) + 연계 문서 자동 생성	전기 뒤 연계 문서 확인
POSTED	승인자 · 관리자가 사유와 함께 역처리	REVERSED(역처리됨) + 반대 문서 생성	역처리 문서 연결 확인
그 밖의 전이	표에 없는 전이 요청	HTTP 400 거절	허용된 다음 동작 안내를 따름

대사 규칙 R1~R4 — 산식과 점검 결과

규칙	산식	허용 오차	점검 건수	차이 건수	최대 차이
R1	보조원장 잔액 − 총계정 잔액	0 (허용 오차 0원)	15	2	1,150,000원
R2	전기된 발생 문서 수(역처리 차감) − 시작월부터 경과한 월 수	0개월	39	17	2개월
R3	상각 누계 − 전기된 상각 문서 합계	100원	29	1	2,400,000원
R4	전기된 정산 청구 금액 − 송장 마스터 청구 금액	0원	9	2	120,000원

처리 단계와 산출·대사식

월 금액 — 약정은 월 금액 기준, 선급은 기준 금액 ÷ 상각 개월 수, 송장은 청구 금액에서 계상 잔액을 뺀 차이.
전표 균형 — 차변 합계 = 대변 합계일 때만 전기.
대사 R1~R4 — 위 표의 산식.
분석 정합 — 큐브 합계 = 원천 라인 합계, 피벗 총합 = 큐브 총합(축 배치와 무관), 칸 금액 = 드릴스루 합계, 요인 합 = 총차이.

조회조건

조건	필수 여부	값	필터 방식
기간	필수	열린 기간 목록, 기본 2026-09	기간 일치
회사	선택	전체 · 1000 본사 · 2000 제조법인 · 3000 판매법인	회사코드 일치
구분 · 상태 · 유형	선택	약정·선급·송장 / 문서 상태 / 문서 유형 / 내가 작성한 것만	해당 필드 일치
기간 From–To · 버전	필수	실적 또는 계획 버전 비교(결산 분석)	기간 구간 + 버전
분석 축 아홉 개	선택	기간 · 회사 · 계정 그룹 · 계정 · 결산 단계 · 문서 유형 · 담당 팀 · 원가센터 · 발생 사유(다중 선택)	선택한 값들의 합집합

결과 컬럼

모듈	컬럼	의미·산출식
개요 · 할 일	KPI 타일 · 단계별 진행률 · 할 일	진행률 = 완료 과업 ÷ 전체 과업, 지연 = 계획일 초과
기준정보	계정 · 원가센터 · 약정/선급/송장 · 결산 과업	월 금액 = 기준 금액 ÷ 개월 수(선급) · 월 금액(약정) · 청구 금액 − 계상 잔액(송장)
문서 처리	문서 번호 · 유형 · 상태 · 금액 · 작성자	금액은 서버가 계산, 차변 합계 = 대변 합계일 때 전기
대사 · 예외	규칙 · 점검 건수 · 차이 건수 · 최대 차이 · 예외 상태	차이 = 좌변 − 우변, 허용 오차 이내면 차이 아님
결산 분석	측정값 다섯 개(처리 금액 · 손익 영향 · 전표 라인 · 지연 일수 · 투입 시간)와 계산 항목 네 개	계획 대비 차이 = 실적 − 계획, 비율 = 차이 ÷ 계획

좁은 화면에서 달라지는 것

390px 폭에서는 위쪽 바가 간소화되고 왼쪽 메뉴가 접혀 단추로 펼칩니다(항목을 고르면 다시 접힙니다). KPI 타일은 세로로 쌓이고, 분석 차트는 숨기지 않고 표 아래로 내려가며, 표는 가로로 밀어 볼 수 있습니다. 여덟 모듈 모두 좁은 화면에서 닿습니다.

파일 구성

app/
├─ index.html · manifest.json · Component.js
├─ controller/   화면별 컨트롤러 (개요 · 기준정보 · 문서 · 일괄 실행 · 대사 · 분석 · 연계 · 감사)
├─ view/ · fragment/   XML 뷰와 문서 상세 조각
├─ model/        서비스 호출 · 실패 처리 · 브라우저 큐브 집계 · 표시 형식 · PowerPoint 생성
├─ css/ · i18n/
├─ odata/<서비스>/
│   ├─ metadata.xml    서비스 정의
│   ├─ core.js         업무 규칙(상태 전이 · 채번 · 검증 · 대사 · 계산)
│   ├─ service.js      요청 처리 연결부
│   └─ json/           엔티티셋별 검증용 샘플 데이터
├─ media/        소개 영상 · 포스터 · 목차 트랙
└─ readme.html

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

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리·대사·분석 관점을 더해 확장합니다.

업무	표준 실행	표준만 쓸 때의 어려움	이 앱이 더하는 것	표준과의 경계
월 발생·선급 상각 전표 생성	FBS1 · FB50 로 건별 입력	대상별 월 금액을 사람이 계산	대상에서 월 금액을 계산해 일괄 실행	없음 아님(표준 일괄 실행 연결 필요)
전표 역분개	F.81 · FB08	사유와 원문서 연결 기록이 화면별로 나뉨	사유 필수 · 반대 문서 자동 연결	표준 역분개가 확정
계정 잔액 대사	FBL3N · FAGLB03	보조원장과 총계정 비교는 화면 두 개	R1 결과와 예외 목록	표준 잔액이 기준
송장 청구 금액 대사	MIRO · FBL1N	송장과 정산 문서를 눈으로 비교	R4 결과와 예외	송장 입력은 표준
원가 귀속 확인	KSB1	전표마다 원가센터 화면 확인	전기 시 귀속 문서 자동 생성	표준 원가 전기가 확정

T-code 별 연계 지점

T-code	이름	이 앱의 연계	오가는 방법·표준에 남길 일
FBS1	계상·이연 전표 입력	발생 계상 · 선급 상각 문서의 분개 구조(차변 비용 · 대변 미지급 · 선급)와 같은 형태	표준 화면에서 개별 전표를 만들 때 이 앱의 대상·월 금액을 기준으로 사용
F.81	계상·이연 전표 역분개	역처리 문서(원문서 부호 반대)와 같은 개념	표준 역분개로 확정하고 이 앱 결과는 점검용으로 대조
FB50	G/L 전표 입력	대사 조정 전표(ADJ)의 분개 형태	조정 전표를 표준에 옮겨 담을 때 같은 계정·금액 사용
FB08	전표 역분개	역처리 사유 · 반대 전표 연결	운영 반영 시 표준 역분개와 사유 코드를 맞춤
FB03	전표 조회	문서 상세의 분개 탭	문서 번호로 표준 전표를 열어 같은 금액인지 확인
FBL3N	G/L 계정 개별 항목	계정별 보조원장 · 총계정 잔액 대사(R1) 원천	표준 화면 잔액과 이 앱의 R1 결과를 맞춰 봄
FAGLB03	G/L 계정 잔액	계정 잔액 열(총계정 잔액)	기간별 잔액 대조
FBL1N	공급업체 개별 항목	송장 정산 문서의 미지급 청산 원천	정산 대상 송장의 미결 항목 확인
MIRO	송장 처리	송장 연계 문서(MM)의 원천 개념	송장 입력은 표준에서, 청구 금액 대사만 이 앱에서
KSB1	원가센터 개별 항목	원가 귀속 문서(CO)의 원천 개념	원가센터별 귀속 금액을 표준과 대조
F110	자동 지급	지급 예정 문서(TR)가 이어지는 표준 지급 실행	지급 실행은 표준 지급 프로그램이 담당
OB52	전기 기간 열기·닫기	전기 가능 기간(열린 기간) 판정의 기준	운영에서는 표준 기간 설정을 따름

운영 전환 뒤에도 기존 표준 리포트를 없애지 않는 것이 안전합니다. 법정·감사·세무 신고에 쓰는 숫자는 표준 화면의 값을 기준으로 두고, 이 앱은 그 숫자를 만들기까지의 처리·대사·분석을 돕습니다.

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

이 앱의 분석은 S/4HANA 의 표준 CDS 분석 쿼리나 Fiori 분석 앱을 대체하지 않습니다. 표준 분석 앱이 이미 맞는 질문(정해진 보고서)은 그대로 쓰고, 이 앱은 결산 절차의 처리·승인·대사와 한 화면에서 이어지는 다차원 보기를 맡습니다. 운영 데이터로 갈 때는 아래 CDS 구성의 큐브·쿼리를 표준 뷰 위에 얹는 방식이 되며, 쓸 수 있는 표준 분석 뷰와 Fiori 앱의 이름은 회사 시스템 버전에서 확인이 필요합니다(확인 필요).

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

구분	대상	놓치면	방법
조건 · 금액 구간	승인 단계 금액 구간	운영 기준에 맞지 않으면 승인 단계가 틀어짐	설정 테이블
매핑	계정 · 원가센터 · 대상 키	변경 이력이 끊김	매핑 테이블 · 변경 문서
확장 필드	문서 머리의 추가 식별 필드	분석 축이 모자람	커스텀 필드 · 확장
BAdI	전기 전 검증 · 연계 문서 생성 시점	표준과 같은 시점에 검증하지 못함	BAdI 구현
권한	회사 · 계정 그룹 · 역할	조회 범위가 넓어짐	PFCG 역할

분석 지표 정의표

기준서 요구사항이 정해진 영역이 아니므로 요구사항 매핑표 대신 이 앱이 쓰는 지표의 정의를 적습니다.

지표	산식·판정 기준	대응 기능	원천 데이터	비고
처리 금액	문서 라인 금액 합계(차대 부호 반영)	분석 피벗·차트	문서 라인	단위 KRW
손익 영향	손익 계정에 미치는 합계	분석 피벗·차트	문서 라인	단위 KRW
전표 라인	라인 건수	분석 피벗·차트	문서 라인	단위 건
지연 일수	계획일 대비 늦은 일수 합계	분석 피벗·차트	결산 과업	낮을수록 좋음
투입 시간	투입 시간 합계	분석 피벗·차트	결산 과업	단위 h
라인당 평균 처리금액	처리 금액 ÷ 전표 라인	계산 항목	—	비율
손익 영향률	손익 영향 ÷ 처리 금액 × 100	계산 항목	—	비율(%)
계획 대비 차이	실적 − 계획, 비율 = 차이 ÷ 계획	기준 대비 열 · 워터폴	계획값	금액과 비율을 모두 넘을 때만 색 표시
요인 분해	총 차이 = 라인 수 효과 + 평균 금액 효과(합이 총차이와 같은지 검산)	요인 분해 · 해설	큐브 · 계획	원인을 단정하지 않고 점검할 곳을 알려 줌

CDS 구성 — 운영 데이터로 가는 길

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	대상 매핑 테이블(약정 · 선급 · 송장) · 계정 · 원가센터	월 금액과 귀속 기준의 출발점	문서 금액을 입력하지 않고 기준에서 계산하려고
차원	결산 단계 · 문서 유형 · 담당 팀 · 발생 사유	분석 축의 이름과 값	축 값이 바뀌어도 큐브를 건드리지 않으려고
큐브	발생 · 상각 · 정산 문서 항목 집계	처리 금액 · 손익 영향 · 라인 · 지연 · 투입 시간	원천 합계와 맞춰 검증하려고
쿼리	결산 분석 쿼리(필터 변수 · 기본 축)	화면 조회조건과 기본 배치	필수 변수로 대용량 범위를 좁히려고
권한	회사 단위 권한 객체	조회 범위 제한	역할별 조회 범위를 PFCG로 관리하려고
서비스	서비스 정의 · 바인딩	OData 노출	화면은 서비스 주소만 알면 되도록

① 대상 매핑 테이블 — 약정·선급·송장의 기준

발생 약정 · 선급 이연 · 청구 송장 대상을 한 테이블에 둡니다. 월 금액 계산의 기준이므로 변경 이력과 키 설계가 먼저 결정됩니다.

" ─────────────────────────────────────────────
" ZACCR_TGT  약정·선급·송장 대상 매핑
" 역할 : 월 발생 계상 · 선급 상각 · 송장 정산 문서의 기준 대상
" 이렇게 나눈 이유 : 문서 금액을 입력하지 않고 이 대상에서 계산하기 위해
" ─────────────────────────────────────────────
@EndUserText.label : '약정·선급·송장 대상'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zaccr_tgt {
  key client     : abap.clnt not null;
  key target_id  : abap.char(10) not null;   " AC-0001 · PP-0001 · ST-0001
  kind           : abap.char(2);              " AC 약정 · PP 선급 · ST 송장
  bukrs          : bukrs;
  start_period   : abap.char(7);              " 2026-01
  saknr          : saknr;                     " 대변 계정(미지급 · 선급)
  exp_saknr      : saknr;                     " 비용 계정
  kostl          : kostl;                     " 원가센터
  currency       : waers;
  @Semantics.amount.currencyCode : 'zaccr_tgt.currency'
  base_amt       : abap.curr(15,2);           " 기준 금액
  months         : abap.int2;                 " 상각 개월 수
  status         : abap.char(1);              " A 사용 · I 중지
}

② 차원 뷰 — 결산 단계와 문서 유형

분석 축의 이름과 코드를 한 곳에서 정합니다. 축 값이 바뀌면 큐브와 쿼리가 모두 영향을 받으므로 별도 뷰로 둡니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '결산 단계 차원'
@ObjectModel.representativeKey : 'Phase'
@Analytics.dataCategory : #DIMENSION
define view entity ZI_ClosingPhase
  as select from zaccr_phase
{
  key phase     as Phase,
      @Semantics.text : true
      phase_txt as PhaseName
}

③ 문서 뷰 — 발생·상각·정산 문서

재무 문서 머리와 항목을 묶습니다. 금액 · 통화 의미를 선언해 두어야 큐브에서 안전하게 합산됩니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '발생·이연 문서'
define view entity ZI_AccrualDocument
  as select from bkpf as h
    inner join   bseg as i on  i.bukrs = h.bukrs
                           and i.belnr = h.belnr
                           and i.gjahr = h.gjahr
  association [0..1] to ZI_ClosingPhase as _Phase on _Phase.Phase = $projection.Phase
{
  key h.bukrs as CompanyCode,
  key h.belnr as DocNo,
  key h.gjahr as FiscalYear,
  key i.buzei as ItemNo,
      h.budat as PostingDate,
      i.hkont as GlAccount,
      i.kostl as CostCenter,
      h.waers as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      i.dmbtr as Amount,
      i.shkzg as DebitCredit,
      _Phase
}

④ 큐브 뷰 — 처리 금액 · 손익 영향 · 라인 · 지연 · 투입 시간

측정값 다섯 개와 축 아홉 개로 집계합니다. 큐브 합계가 원천 라인 합계와 같아야 하므로 검증 뷰와 짝으로 운영합니다.

@Analytics.dataCategory : #CUBE
@EndUserText.label : '결산 처리 큐브'
define view entity ZI_AccrualCube
  as select from ZI_AccrualDocument as d
{
  key d.CompanyCode,
  key d.FiscalYear,
  key d.GlAccount,
  key d.CostCenter,
      d.Currency,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      case d.DebitCredit when 'S' then d.Amount else d.Amount * -1 end as AdjAmt,
      @DefaultAggregation : #SUM
      cast( 1 as abap.int4 ) as DocLines
}

⑤ 분석 쿼리 — 조회조건과 기본 레이아웃

화면의 조회조건(기간 · 회사 · 계정 그룹 · 단계)이 이 쿼리의 필터 변수가 됩니다. 필수 변수를 정해 대용량에서 범위를 좁힙니다.

@Analytics.query : true
@EndUserText.label : '결산 분석 쿼리'
@AccessControl.authorizationCheck : #CHECK
define view entity ZC_AccrualClosingQuery
  as select from ZI_AccrualCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { mandatory : true, selectionType : #INTERVAL }
  key FiscalYear,
  @AnalyticsDetails.query.axis : #ROWS
  CompanyCode,
  @AnalyticsDetails.query.axis : #COLUMNS
  AdjAmt,
  DocLines
}

⑥ 권한 객체 — 회사 단위 조회 범위

화면의 데모 사용자 전환은 운영에서 역할 · 권한 객체로 바뀝니다. 회사코드 단위로 조회 범위를 제한합니다.

@MappingRole : true
define role ZC_AccrualClosingQuery {
  grant select on ZC_AccrualClosingQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ RAP 행위 정의 — 검토 요청 · 승인 · 전기 · 역처리

문서의 상태 전이를 서버 로직으로 두는 자리입니다. 직무 분리와 금액 구간별 승인 단계를 이 검증에서 판정합니다.

managed implementation in class zbp_i_accrualdocument unique;
strict ( 2 );
define behavior for ZR_AccrualDocument alias Doc
persistent table zaccr_doc
lock master
authorization master ( instance )
{
  create;
  update ( features : instance );
  action ( features : instance ) submit result [1] $self;
  action ( features : instance ) approve result [1] $self;
  action ( features : instance ) reject parameter ZA_ReasonText result [1] $self;
  action ( features : instance ) post result [1] $self;
  action ( features : instance ) reverse parameter ZA_ReasonText result [1] $self;
  validation checkBalanced on save { create; update; }
  validation checkSeparationOfDuty on save { field Status; }
}

⑧ 서비스 정의 — 화면이 바라보는 엔티티셋

분석 쿼리와 문서 뷰를 OData 서비스로 노출합니다. 운영 전환에서는 manifest.json 의 서비스 주소만 바꿉니다.

@EndUserText.label : '결산 통합 관리 서비스'
define service ZUI_AccrualClosing {
  expose ZC_AccrualClosingQuery  as ClosingQuery;
  expose ZR_AccrualDocument      as Document;
  expose ZI_ClosingPhase         as Phase;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 샘플을 운영으로 옮기기 전에 회사가 정해야 하는 항목입니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
업무 규칙 확정	상태 흐름 · 승인 단계 · 금액 구간(5천만 원 기준)	샘플 값을 그대로 운영해 승인 기준이 맞지 않음	재무팀장 · 회계팀
직무 분리와 권한	작성 · 승인 · 전기 · 역처리 역할을 PFCG 역할과 권한 객체로 매핑	데모 사용자 전환이 남아 권한이 열려 있음	보안 담당 · 재무팀
처리 펑션 연결	일괄 실행과 전기를 표준 BAPI · RAP 액션 · 표준 일괄 처리와 연결	화면 결과와 표준 전표가 따로 놀음	IT · 재무팀
문서 번호 범위	발생 · 상각 · 정산 · 조정 문서의 번호 범위와 채번 규칙	표준 문서 번호와 충돌	IT
연계 문서 흐름 키	재무 → 원가 · 구매 · 자금 문서를 잇는 키	연계 문서를 따라갈 수 없음	IT · 원가팀 · 자금팀
대사 규칙과 허용 오차	R1~R4의 허용 오차와 예외 처리 담당	예외가 쌓여도 담당이 없음	회계팀
계정과 매핑 변경 관리	계정 · 원가센터 · 대상 매핑 변경 절차	변경 이력이 끊겨 월 금액이 달라짐	회계팀 · IT
서비스 활성화와 전송	서비스 활성화 · 전송 순서 · `manifest.json` 서비스 주소 교체	화면이 검증용 서비스를 계속 바라봄	IT
배치 등록	에이전트 점검과 월 발생 일괄 실행의 배치 주기	수동 실행에 의존	IT · 재무팀

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

검사	점검 건수	차이 건수	최대 차이	비고
보조원장 합계 = 총계정 잔액(R1)	15	2	1,150,000원	샘플 의도 예외(2개 계정)
발생 계상 월 수(R2)	39	17	2개월	의도 예외 포함, 예외 목록과 일치
선급 상각 누계(R3)	29	1	2,400,000원	의도 예외 1건
정산 청구 금액(R4)	9	2	120,000원	의도 예외 2건
전표 차변 = 대변	553	0	0원	FI 문서 전수
상태 이력 마지막 값 = 문서 현재 상태	1,106	0	-	전 영역 문서
큐브 합계 = 원천 라인 합계(큐브 대조)	45	0	0	측정값 5 × 축
피벗 총합 = 큐브 총합(축 배치 6가지)	6	0	0원	처리 금액 14,278,070,000원
칸 금액 = 드릴스루 합계	4	0	0원	칸 4개 대조
요인 합 = 총차이	1	0	0원	41,139,739원

의도적으로 넣은 예외는 24건(R1 3 · R2 17 · R3 2 · R4 2)이며 대사 차이 건수와 따로 집계합니다. 최근 대사 실행의 차이는 R1 2 · R2 17 · R3 1 · R4 2건이고, 조정 전표로 해소된 예외는 차이 건수에서 빠집니다. 그 밖의 검사의 차이 건수는 모두 0입니다.

운영 데이터로 갈 때

분석은 큐브 집계를 서비스에서 하고 조회조건의 기간·회사를 필수로 두는 방식이 필요합니다. 전표와 문서 흐름이 수천만 건이면 집계 위치(CDS 쿼리에서 집계, 화면에는 집계 결과만)와 인덱스, 응답 시간 기준을 먼저 정해야 합니다. 이 앱의 샘플 규모는 큐브 6,220행·원천 라인 2,179건이며, 화면은 행·열 조합이 한도를 넘으면 안내를 띄우고 표를 그리지 않도록 되어 있습니다. 운영 규모에서는 큐브를 브라우저가 한 번에 읽는 방식 대신 필터를 서비스로 내려 보내는 방식으로 바꾸는 작업이 필요하며, 이는 확인 필요 항목입니다.

자주 묻는 질문 — 도입 전에 가장 많이 묻는 것

도입 검토에서 자주 나오는 질문을 주제별로 모았습니다.

도입 효과와 대상

누가 쓰면 가장 효과가 큰가요?

월 마감에서 약정 · 선급 · 송장 때문에 전표를 반복해서 만드는 재무팀 · 회계팀이 가장 큽니다. 승인자는 대기 목록과 직무 분리 안내를, 관리자는 규칙과 권한 관리를 한 앱에서 봅니다. 조회자는 읽기 전용으로 진행 상황과 분석을 확인합니다.

도입 효과를 숫자로 말할 수 있나요?

검증용 샘플 데이터에서 확인한 숫자만 말씀드릴 수 있습니다. 7~9월 처리 금액 14,278,070,000원, 대사 점검 15 · 39 · 29 · 9건, 큐브 6,220행과 원천 라인 2,179건의 합계가 같은 것입니다. 시간 절감률 같은 효과 수치는 운영 데이터로 재어 보아야 하므로 적지 않습니다.

적용 시기와 범위는 어떻게 정해지나요?

이 앱은 업무 처리와 점검을 돕는 도구이며 특정 기준서의 시행일이나 경과규정에 묶여 있지 않습니다. 확인된 적용 시기가 없으므로 회사의 결산 일정에 맞춰 법인 하나, 기간 하나로 먼저 시험하고 범위를 넓히는 방식을 권합니다.

표준 T-code와의 관계

표준 SAP 화면을 대체하나요?

대체하지 않습니다. 전표 입력 · 역분개 · 개별 항목 조회 같은 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 대상 관리 · 일괄 실행 · 대사 · 분석이라는 점검 관점을 더해 확장합니다. 운영 전환 뒤에도 법정 · 감사 · 세무 신고에 쓰는 표준 리포트는 그대로 남겨 두는 것이 안전합니다.

표준 화면 숫자와는 어떻게 맞춰 보나요?

FBL3N · FAGLB03 의 계정 잔액과 이 앱의 R1 결과를, KSB1 의 원가센터 항목과 원가 귀속 문서를, FBL1N · MIRO 의 송장 항목과 R4 결과를 나란히 놓고 봅니다. 맞지 않는 항목은 예외 목록에 올라와 조치 상태를 추적합니다.

숫자와 산식

문서 금액은 어떻게 계산되나요?

발생 계상은 약정 월 금액, 선급 상각은 기준 금액을 개월 수로 나눈 월 금액, 송장 정산은 청구 금액에서 계상 잔액을 뺀 차이로 계산합니다. 금액은 서버가 계산하며 화면에서 직접 고칠 수 없습니다. 조정 전표만 사유와 함께 금액을 입력합니다.

대사 규칙 네 가지는 무엇인가요?

R1 보조원장 잔액과 총계정 잔액, R2 전기된 발생 문서 수와 경과 월 수, R3 상각 누계와 상각 문서 합계, R4 정산 청구 금액과 송장 금액입니다. R3 의 허용 오차는 100원이며 나머지는 0입니다. 차이가 나면 예외 목록에 올라 점검 필요로 표시됩니다.

샘플의 대사 예외는 진짜 차이인가요?

검증을 위해 의도적으로 넣은 예외입니다. 보조원장 잔액 조작 3건, 계상 빠진 달 4건, 상각 누계 조작 2건, 송장 금액 변경 2건 등이 있고 대사 차이 건수와 따로 집계합니다. 일부는 조정 전표로 해소하고 일부는 조치 중 · 보류 · 수용 상태로 남겨 두었습니다.

외화나 환율은 다루나요?

이 샘플은 원화(KRW) 중심입니다. 외화 약정이 있다면 외화 금액 · 통화 · 환율 · 원화 환산 금액을 따로 두고 통화별로 집계해야 하며, 서로 다른 통화의 금액을 그대로 더하지 않습니다. 환율 유형과 환산 시점은 운영에서 정해야 하는 항목입니다.

화면과 조작

승인 버튼은 누구에게 보이나요?

서버가 돌려준 상태와 역할 값으로만 보입니다. 작성자 본인에게는 승인이 보이지 않고, 5천만 원 이상은 서로 다른 두 사람이 승인해야 합니다. 버튼을 거치지 않고 직접 요청해도 서버가 같은 이유로 거절합니다.

같은 조건으로 일괄 실행을 두 번 하면 문서가 두 번 생기나요?

생기지 않습니다. 같은 대상과 같은 기간의 문서가 이미 있으면 새로 만들지 않고 제외합니다. 모의 실행 합계와 실행 후 문서 합계가 같은지도 실행 이력에서 확인합니다.

엑셀 업로드는 어떻게 동작하나요?

파일을 고르면 행마다 정상 여부를 미리보기로 보여 주고 반영 버튼은 정상 건만 저장합니다. 점검이 필요한 행은 사유가 표시되어 반영되지 않습니다. 양식은 같은 대화상자에서 내려받습니다.

좁은 화면에서도 쓸 수 있나요?

390px 폭에서 메뉴가 접히고 KPI 타일이 세로로 쌓이며 분석 차트가 표 아래로 내려갑니다. 표는 가로로 밀어 볼 수 있습니다.

분석 기능

축을 바꾸면 서버를 다시 부르나요?

부르지 않습니다. 큐브를 한 번 읽어 브라우저에서 다시 묶으므로 축을 바꿔도 요청이 나가지 않고, 어떤 배치에서도 총합이 같습니다. 행과 열 조합이 한도를 넘으면 안내가 뜨고 표를 그리지 않습니다.

요인 분해와 해설은 원인을 알려 주나요?

원인을 단정하지 않습니다. 총 차이를 라인 수 효과와 평균 금액 효과로 나누어 점검할 곳을 보여 줄 뿐이며, 해설 문장은 참고용입니다. 외부 AI 모델이 연결되지 않으면 규칙 기반 해설이 나오고 근거 표로 숫자의 출처를 확인합니다.

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

감시 규칙 네 가지(기한 경과 · 미처리 예외 · 계획 초과 · 승인 적체)를 점검해 받을 역할의 대기함에 보고를 올립니다. 하루 한 번 제한은 서버가 판정하고 걸린 것이 없어도 활동 기록을 남깁니다. 운영에서는 배치 스케줄(SM36 또는 cron)로 연결합니다.

레이아웃은 어떻게 저장되나요?

사용자별로 이름을 붙여 저장하고, 기본으로 지정하면 열 때 그 배치로 시작합니다. 자동 조회를 켜 두면 열자마자 조회됩니다. 다른 사용자의 레이아웃은 고칠 수 없습니다.

도입과 운영

운영 데이터에 연결하려면 무엇을 해야 하나요?

서비스 정의를 운영 CDS 뷰와 RAP 행위 정의로 구현하고 manifest.json 의 서비스 주소를 바꿉니다. 그 전에 상태 흐름 · 승인 단계 · 권한 · 문서 번호 · 연계 키 · 대사 허용 오차를 회사 기준으로 정해야 합니다. 개발보다 정하는 일이 많습니다.

권한과 보안은 어떻게 되나요?

화면의 데모 사용자 전환은 운영에서 제거하고 PFCG 역할로 대체합니다. 회사코드 단위 조회 범위는 권한 객체로 제한합니다. 모든 쓰기와 전이는 감사 로그에 남고 거절된 요청도 기록됩니다.

대용량에서도 괜찮은가요?

분석은 큐브 집계를 서비스에서 하고 조회조건의 기간 · 회사를 필수로 두는 방식이 필요합니다. 전표와 문서 흐름이 수천만 건이면 집계 위치 · 인덱스 · 응답 시간 기준을 먼저 정해야 합니다. 샘플의 큐브 규모는 6,220행입니다.

계정체계나 매핑이 바뀌면 어떻게 하나요?

계정 · 원가센터 · 대상 정보는 앱에서 수정하며 변경 이력이 남습니다. 월 금액이 바뀌면 이미 전기된 문서가 있는 대상은 수정이 제한되므로 역처리 후 다시 만드는 절차를 따릅니다.

이 앱의 판단을 그대로 따라도 되나요?

이 앱은 업무 처리와 분류 · 집계 · 대사를 돕는 점검 도구입니다. 계상 대상과 금액, 예외의 처리 방향에 대한 최종 판단은 회사와 감사인이 하며, 세무 신고가 걸린 부분은 회사와 세무 대리인이 판단합니다.

읽기 전용으로만 먼저 써 볼 수 있나요?

조회자 역할은 읽기 전용입니다. 개요 · 문서 · 대사 · 분석 · 감사 화면을 볼 수 있고 쓰기와 처리 버튼은 꺼지며, 직접 요청해도 서버가 거절합니다.