SAP 회계전표 전기 통합 관리 — 적요 한 줄 분개부터 전기 전 위험 점검, 승인 · 역분개 · 대사 · 차이 요인분해까지 한 앱에서

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

회계전표를 다루는 현업이 가장 자주 받는 질문은 세 가지입니다. 이 적요에는 어느 계정과 부가세 코드를 써야 하나, 전기하기 전에 잘못된 전표를 어떻게 걸러 내나, 누가 승인했고 전기된 결과는 원장과 맞나. 지금은 표준 입력 화면에서 계정을 외워 입력하고, 세액은 계산기로 나누고, 승인은 메일로 받고, 마감 때 보조원장과 부가세 계정을 엑셀로 맞춥니다.

이 앱은 그 흐름을 한 화면에 잇습니다. 적요 한 줄을 쓰면 분개 패턴과 거래처 일치로 분개 줄이 채워지고, 13개 규칙이 전기 전에 위험을 점수로 매기며, 차단 규칙에 걸린 전표는 서비스가 검토 요청과 전기를 거절합니다. 표준 전기는 SAP 표준 T-code 가 담당하고, 이 화면은 입력 보조 · 점검 · 승인 · 대사 · 분석 관점을 더해 확장합니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터의 2026년 9월 차변 금액은 계획 853,652,877원, 실적 894,796,100원으로 41,143,223원(4.8%) 늘었습니다. 이 앱은 그 차이를 요인으로 가릅니다. 라인 수는 계획보다 줄어 건수 효과는 약 −1,117만 원이었지만, 건당 금액이 커져 건당 금액 효과가 약 +5,032만 원이었고, 역분개 전표가 다시 잡힌 역분개 효과가 +1,996,500원이었습니다. 세 요인을 더하면 총차이와 정확히 같습니다. 같은 데이터에서 대사식 18개를 전수로 돌린 결과 차이는 11건이었고, 11건 모두 대사가 잡아내는지 보려고 일부러 넣은 예외였습니다. “전표가 많아졌나” 가 아니라 “건당 금액이 큰 거래가 어디서 늘었나” 로 회의의 질문이 바뀝니다.

도입하면 달라지는 것

• 입력 — 적요 한 줄과 확인 클릭으로 분개가 끝나고, 세액 분할과 거래처 찾기가 화면 안에서 해결됩니다.
• 점검의 위치 — 오류를 전기 뒤 대사에서 찾던 일이 전기 전 점수와 차단 규칙으로 앞당겨집니다.
• 승인 줄 — 소액 · 저위험 전표는 자동 승인으로 빠지고, 승인자는 큰 금액과 경고가 붙은 전표에 집중합니다.
• 마감 회의 — “어느 숫자가 맞나” 가 아니라 “남은 예외 11건을 어떻게 정리할까” 로 넘어갑니다.

이런 회사에 맞습니다

하루 수십 건 이상의 카드 · 경비 · 매출 전표를 여러 담당자가 입력하고, 회사 코드가 둘 이상이며, 승인자와 처리자가 나뉜 재무 조직에 맞습니다. 부가세 코드 선택 실수와 중복 입력이 마감 때 대사 차이로 돌아오는 회사, 반복 전표(임차료 · 통신비 · 보험료)를 매달 손으로 만드는 회사에 특히 맞습니다. 법정 결산과 세무 신고 숫자는 표준 거래와 표준 보고서에 두고, 이 앱은 입력 보조와 점검에 씁니다.

실행 화면

사용 방법

1. 조회조건 입력 — 오른쪽 위에서 회사(기본 전체) · 기간(기본 2026-10) · 사용자를 고릅니다. 전표 조회 · 처리 화면의 조건(전기일 부터 · 까지, 상태, 전표 유형, 입력 경로, 위험, 헤더 텍스트, 내가 만든 것)은 모두 선택이고, 분석 화면은 기간과 지표가 필수입니다.
2. 조회 버튼 · Enter — 조회 버튼은 조회 조건 영역 오른쪽 끝에 있고, 조건 칸에서 Enter 를 눌러도 조회됩니다. 개요 타일에서 넘어오거나 자동 조회 레이아웃으로 열면 바로 조회된 상태로 시작합니다.
3. 요약 확인 — 개요 타일 9개(임시저장 · 승인 대기 · 전기 대기 · 반려 · 고위험 미전기 · 전기 금액 · 한 줄 분개 비중 · 미해결 대사 예외 · 안 읽은 보고)와 분석 화면의 차변 · 대변 합계를 먼저 봅니다.
4. 전표 입력 — 회계전표 생성 화면의 한 줄 입력칸에 적요를 쓰고 분개 추천 → 전기 전 점검 → 검토 요청 → 회계전표 전기 순서로 누릅니다.
5. 탭 · 축 이동 — 전표 상세는 분개 항목 → 위험 점검 → 상태 이력 → 연계 문서 → 감사 로그 탭, 분석 화면은 차원을 행 · 열로 끌어다 놓아 축을 바꿉니다.
6. 행 · 칸 클릭 상세 — 전표 목록의 행을 누르면 상세 창이, 분석 표의 칸을 누르면 그 금액을 만든 전표 라인이 열립니다.
7. 내보내기 — 목록은 엑셀 · CSV, 분석 결과는 표 CSV · PPT 보고서로 받습니다. 여러 전표는 엑셀 업로드 양식으로 한 번에 올립니다.

무엇으로 만들었나

처음 열었을 때 — 오늘 처리할 전표가 한곳에

임시저장 12 · 승인 대기 13 · 전기 대기 31 · 반려 8 · 고위험 미전기 0 · 전기 금액 · 한 줄 분개 비중 31% · 미해결 대사 예외 11 타일과 입력 경로별 전표 분포가 나옵니다. 타일을 누르면 해당 조건의 전표 목록으로 이동합니다. 타일 숫자는 상단에서 고른 회사 · 기간 기준이며, 기본값은 전체 회사 · 2026-10 입니다. 월초에는 승인 대기와 전기 대기 타일부터 비우는 것이 보통의 순서입니다.

역할에 맞는 할 일(승인 대기 · 반려 수정 · 예외 조치 · 전기 대기)과 하루 한 번 자동 점검한 에이전트 보고(승인 대기 누적 · 묵은 전표 · 미해결 예외 · 역분개 비율)가 나옵니다. 보고는 하루 한 번만 만들어지고, 같은 날 다시 눌러도 건너뛴 기록만 남습니다. 보고를 누르면 해당 목록으로 이동합니다.

기준정보 관리 — 계정 · 거래처 · 분개 패턴

회사별 G/L 계정의 계정 그룹 · 조정계정 유형 · 세금 범주 · 원가센터 필수 여부 · 전기 잔액을 봅니다. 조정계정 라인에는 거래처가 필요하다는 규칙(C03)의 기준이 됩니다. 조정계정 유형이 고객 · 공급업체인 계정은 전표 라인에 거래처가 꼭 있어야 합니다. 잔액은 전기 전표의 차변을 양수로 집계한 값입니다.

고객 · 공급업체를 새로 만듭니다. 조정계정과 지급 조건을 함께 정하고 같은 이름은 서비스가 거절합니다. 처리자 이상만 저장할 수 있고, 저장하면 감사 로그에 생성 기록이 남습니다. 거래처 코드는 비어 있는 다음 번호로 자동 부여됩니다.

생성 · 수정 · 사용 중지가 사용자 · 일시 · 이전 값과 함께 감사 로그로 남습니다. 사용 중지는 삭제가 아니라 상태 변경이라, 과거 전표의 거래처 이름은 그대로 보입니다.

적요 키워드별 추천 계정 · 부가세 코드 · 결제 수단 · 원가센터와 사용 건수를 관리합니다. 전기된 한 줄 분개는 사용 건수를 올려 다음 추천에 반영됩니다. 사용 건수가 많은 패턴이 먼저 추천됩니다. 관리자는 키워드와 추천 계정을 고칠 수 있고, 고친 내용은 다음 추천부터 반영됩니다.

회계전표 생성 — 적요 한 줄에서 전기까지

"가온카드 카페 매출 100,000원 부가세 포함" 한 줄을 넣고 분개 추천을 누르면 미수금 100,000 · 매출 90,910 · 부가세 9,090 세 줄이 신뢰도와 함께 채워집니다. 행마다 붙은 신뢰도는 패턴 일치 · 거래처 일치 · 금액 표현을 합친 값입니다. 추천은 제안일 뿐이라 사람이 확인하고 임시 저장이나 검토 요청을 눌러야 저장됩니다.

고객 코드 칸의 검색 도움말에서 "*가온*" 으로 찾으면 일치하는 고객이 조정계정과 함께 나옵니다. * 를 앞뒤에 붙이면 포함 검색입니다. 고른 고객의 조정계정이 미수금과 맞는지도 함께 보입니다.

전기 전 점검을 누르면 13개 규칙으로 점수를 매깁니다. 이 전표는 10점(낮음)이며 주말 전기 안내 1건만 있습니다. 점수는 0~19 낮음 · 20~49 보통 · 50 이상 높음으로 읽습니다. 참고 규칙은 진행을 막지 않고 안내만 합니다.

100만 원 이하 · 위험 낮음 전표는 검토 요청과 함께 자동 승인되고, 회계전표 전기를 누르면 "전표 생성되었습니다. (전기 완료 · 100,000원)" 이 나옵니다. 자동 승인은 승인자가 SYSTEM 으로 기록되고 상태 이력에 그대로 남습니다. 자동 승인 상한은 샘플 설정값이라 회사가 정하면 바뀝니다.

전기 전 점검 — 중복은 경고, 차단은 거절

같은 거래처 · 같은 금액 전표가 3일 안에 있으면 중복 의심(C08) 경고와 함께 위험 점수가 40점(보통)으로 올라갑니다. 경고는 진행을 막지 않습니다. 먼저 들어간 전표를 확인한 뒤 진행 여부를 사람이 판단합니다.

고객 코드가 빠진 미수금 라인은 차단 규칙(C03)에 걸려 검토 요청이 거절됩니다. 같은 요청을 직접 보내도 서비스가 거절합니다. 화면 버튼만 막는 것이 아니라 서비스가 같은 규칙을 다시 확인하므로, 요청을 직접 보내도 결과가 같습니다.

차단된 라인의 고객 코드 칸이 경고 상태로 표시되고 위험 점수는 100점(차단)입니다. 차단 라인에 고객 코드를 넣고 다시 점검하면 점수가 내려가고 검토 요청이 가능해집니다.

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

전기일 범위 · 상태 · 전표 유형 · 입력 경로 · 위험 · 텍스트 · 내가 만든 것으로 거릅니다. 조회 버튼은 조건 영역 오른쪽 끝에 있고 Enter 로도 조회됩니다. 개요 타일에서 넘어오면 해당 조건이 미리 걸린 채 조회됩니다. 결과는 CSV(UTF-8 BOM)와 엑셀로 내려받을 수 있습니다.

분개 항목 · 위험 점검 · 상태 이력 · 연계 문서 · 감사 로그 탭이 있습니다. 처리자에게는 승인 버튼이 보이지 않고 "승인 권한은 승인자 · 관리자만" 안내가 나옵니다. 현재 사용자가 할 수 있는 버튼만 보입니다. 위험 점검 탭에는 걸린 규칙과 라인 번호가 함께 나옵니다.

승인자로 바꾸면 승인 · 반려 버튼이 나타납니다. 5,000만 원 이상은 서로 다른 두 사람이 승인해야 승인 완료가 됩니다. 2단계 승인 전표는 첫 승인 뒤 검토중에 머물고 승인 단계 표시가 1/2 로 바뀝니다.

작성자가 자기 전표를 승인하려 하면 "직무 분리 — 작성자는 자기 전표를 승인할 수 없습니다" 로 서비스가 거절합니다. 같은 거절은 감사 로그에 거절 결과로 남아, 누가 언제 시도했는지 나중에 확인할 수 있습니다.

전기된 전표를 역분개하면 반대 방향 전표가 만들어지고 원전표 · 원가센터 실적과 함께 연계 문서 탭에 이어집니다. 역분개 사유는 필수이고, 원전표 상세에서 역분개 전표 번호로, 역분개 전표에서 원전표 번호로 서로 이동합니다.

조회자로 바꾸면 쓰기 버튼이 모두 사라지고 닫기만 남습니다. 직접 요청도 403 으로 거절됩니다. 데모에서는 오른쪽 위 사용자 전환으로 역할을 바꿉니다. 운영에서는 SAP 권한 객체와 역할로 바뀝니다.

양식을 내려받아 여러 전표를 한 파일로 올리면 묶음 번호별로 미리 검증해 정상 3건 · 오류 1건을 보여 주고, 정상 건만 반영합니다. 오류 행은 사유(차대 불일치 · 없는 계정 등)와 함께 빨갛게 표시되고, 반영 결과는 성공 · 실패 건수로 나옵니다.

일괄 실행 — 미리보기 합계와 실행 결과가 같다

반복 전표 생성 유형 · 회사 · 기간을 고르고 미리보기를 누르면 대상 6건 · 합계 11,630,000원이 저장 없이 나옵니다. 미리보기는 저장하지 않으므로 몇 번이든 눌러 볼 수 있습니다. 대상은 반복 전표 정의 중 해당 기간에 아직 만들어지지 않은 것입니다.

실행하면 미리보기와 같은 6건 · 11,630,000원이 만들어지고 실행 로그가 남습니다. 같은 조건으로 다시 실행하면 중복으로 만들어지지 않습니다. 실행 로그는 대상별 결과와 만들어진 전표 번호를 남깁니다. 만들어진 전표는 임시저장 상태로 시작해 같은 승인 흐름을 탑니다.

대사와 예외 조치 — 어긋난 곳을 찾아 기록으로 남긴다

7개 규칙(차대 · 부가세예수금 · 부가세대급금 · 보조원장 · 역분개 · 중복 전기 · 세액)으로 9월 전기 전표를 점검한 결과와 예외 11건이 나옵니다. 규칙마다 검사 건수 · 차이 건수 · 최대 차이가 나오고, 허용 오차를 넘은 건만 예외로 올라옵니다.

거래처가 빠진 미수금 차이(R4)에 조정 전표를 만들면 예외가 조치 중으로 바뀌고 조정 전표 번호가 연결됩니다. 조정 전표는 일반 전표와 같은 점검 · 승인 흐름을 거칩니다. 보류와 허용 종결은 사유가 필수입니다.

조정 전표를 승인 · 전기한 뒤 대사를 다시 실행하면 해당 예외가 해소로 바뀝니다. 해소된 예외도 지워지지 않고 처리 이력과 함께 남아, 다음 달 같은 대상이 다시 걸리면 지난 조치를 볼 수 있습니다.

분석 — 피벗에서 전표 라인까지, 계획 대비 차이의 요인까지

계정 그룹 > G/L 계정 행에 실적 · 계획 · 차이 · 증감률 열을 놓고 차변 합계 896,318,800원을 봅니다. 아래 폭포 차트가 차이 요인을 보여 줍니다. 이 캡처는 검증 중 조정 전표 1건을 전기한 뒤의 상태라 차변 합계가 896,318,800원입니다. 증감률은 금액과 비율이 함께 기준을 넘을 때만 색칠됩니다.

입력 경로 · 위험 구간 같은 차원을 행 · 열로 끌어다 놓으면 서버 요청 없이 다시 집계됩니다. 다섯 가지 배치에서 총합이 같습니다. 축 이동은 받아 둔 큐브를 화면에서 다시 집계하므로 서버 요청이 생기지 않습니다. 행 수 상한을 넘는 조합은 안내와 함께 막습니다.

칸을 누르면 그 금액을 만든 전표 라인이 열리고 칸 금액과 라인 합계가 일치하는지 표시됩니다. 드릴스루 창 맨 위에 건수와 합계가 나오고, 전표 번호를 누르면 전표 상세로 이동합니다.

9월 차변 금액의 계획 대비 차이를 신규 계정 · 건수 · 건당 금액 · 역분개 효과로 나눕니다. 요인 합은 총차이와 같습니다. 요인 합계 = 총차이 검산 줄이 함께 나오고, 요인마다 금액이 큰 계정을 적어 둡니다.

조회 조건 · 축 배치 · 지표를 레이아웃으로 저장하고 기본값 · 열 때 자동 조회를 지정합니다. 자동 조회를 켠 기본 레이아웃은 화면을 열자마자 조회된 상태로 시작합니다.

영역 간 연계 — 영업 · 구매 · 자금 · 원가 문서

전표 번호로 찾으면 원가센터 실적 · 역분개 전표까지 이어진 흐름과 영역별 문서 수가 나옵니다. 흐름의 상자를 누르면 그 문서의 상세가 열리고, 영역별 문서 수와 전기 수가 아래 표로 나옵니다.

영업 청구 · 구매 송장 · 은행 명세가 회계전표로, 비용 전표가 원가센터 실적으로 이어지는 흐름을 영역별 열로 봅니다. 영업 청구 89건 · 구매 송장 91건 · 은행 명세 177건이 회계전표로, 비용 전표가 원가 실적 266건으로 이어져 있습니다.

AI 분석과 에이전트 — 숫자는 서비스가, 설명은 AI 가

규칙 기반 해설이 현재 범위의 핵심 발견을 쓰고, 해설에 쓴 근거 표를 펼쳐 보여 줍니다. 숫자는 집계 결과만 씁니다. 해설은 서비스가 계산한 숫자만 인용합니다. 모델 연결은 기본 꺼짐이며, 꺼도 규칙 기반 해설이 같은 근거로 나옵니다. PPT 보고서는 브라우저에서 만들어 내려받습니다.

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

생성 · 수정 · 상태 전이 · 일괄 실행 · 대사 · 레이아웃 저장까지 사용자 · 대상 · 이전 값 → 이후 값 · 결과가 남습니다. 거절된 요청도 기록됩니다. 로그는 사용자 · 결과로 거르고 엑셀로 내려받습니다. 거절된 요청도 사유와 함께 남습니다.

조회자 · 처리자 · 승인자 · 관리자 6명의 쓰기 · 승인 · 실행 · 관리 권한과 직무 분리 규칙, 허용된 상태 전이표를 봅니다. 허용된 상태 전이표가 서비스가 판정에 쓰는 표와 같습니다. 관리자도 자기 전표는 승인할 수 없습니다.

좁은 화면 — 휴대폰에서도

390px 폭에서는 메뉴가 접히고 조회 조건이 세로로 쌓입니다. 차트는 표 아래로 내려가고, 조회 버튼은 조건 영역 끝에 그대로 있습니다.

390px 폭에서도 한 줄 분개 입력과 헤더 정보를 그대로 씁니다. 좁은 화면에서는 툴바 버튼이 더보기 메뉴로 접힙니다.

화면 뒤에서 일어나는 일

화면의 버튼은 모두 서비스의 펑션 하나에 대응합니다. 분개 추천은 적요의 키워드로 분개 패턴을, 이름 · 검색어로 거래처를 찾아 분개 줄을 돌려주고, 전기 전 점검은 13개 규칙을 돌려 점수와 걸린 규칙을 돌려줍니다. 검토 요청 · 승인 · 전기 · 역분개는 상태 전이표와 역할 · 금액 규칙을 서비스가 다시 확인한 뒤 처리하고, 모든 시도는 성공이든 거절이든 감사 로그에 남습니다.

전기 전 점검 판정 — 조건, 결과 상태, 사용자 조치

점수는 걸린 규칙 점수의 합(최대 100)이며 0~19 낮음 · 20~49 보통 · 50 이상 높음, 차단 규칙이 하나라도 있으면 차단입니다. 경고와 참고는 ‘점검 필요’로 보여 주고 진행 여부는 사람이 판단합니다.

문서 상태 판정 — 승인과 전기

허용되지 않는 전이(예: 임시저장 → 전기)는 400 으로, 역할이 맞지 않는 요청은 403 으로 서비스가 거절합니다.

처리 단계와 대사식

1. 세액 분할 — 합계 기준: 세액 = 합계 × 세율/(100+세율), 원 미만 버림, 공급가액 = 합계 − 세액. (R7 세액 = 공급가액 × 세율, 허용 10원)
2. 전기 — 전표마다 차변 = 대변 (R1). 비용 라인의 원가센터 실적이 함께 생깁니다.
3. 역분개 — 역분개 전표 금액 = 원전표 × (−1), 계정별 상쇄 (R5).
4. 부가세 계정 — 부가세예수금 증감 = 매출 코드 세액 (R2), 부가세대급금 증감 = 매입 코드 세액 (R3).
5. 보조원장 — 거래처가 있는 라인 합계 = 조정계정 합계 (R4), 같은 거래처 · 같은 금액 · 같은 날 중복 없음 (R6).
6. 분석 — 큐브 합계 = 전표 라인 합계, 요인 합 = 총차이.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 사이드 메뉴가 접히고, 조회 조건이 세로로 쌓이며, 차트가 표 아래로 내려갑니다. 툴바 버튼은 더보기 메뉴로 들어가고, 행 · 열 축 조합이 상한을 넘으면 안내와 함께 막습니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json · readme.html
├─ view/      Main · Home · Master · Post · Docs · Batch · Recon · Analysis · Flow · Audit
├─ controller/ · i18n/ · css/
├─ model/     Api · ErrorHandler · formatter · cube · chart · pptx
├─ media/     소개 영상 · 첫 장면
└─ odata/     metadata.xml · service.js · core.js · json/(엔티티셋별 샘플 데이터)

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 입력 보조 · 전기 전 점검 · 승인 · 대사 · 분석 관점을 더해 확장합니다. 같은 전표 구조를 쓰므로 이 앱에서 전기한 전표는 표준 조회 화면에서 그대로 보입니다.

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

T-code 별 연계 지점

법정 결산 · 공시 · 세무 신고에 쓰는 숫자는 표준 거래와 표준 보고서에 두고, 이 앱은 입력 보조와 점검에 씁니다. 기존 보고서를 없앨 필요는 없습니다.

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

운영에서는 유니버설 저널(ACDOCA) 위의 표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office 가 원장 분석을 담당합니다. 이 앱은 그 앞단 — 전표가 원장에 들어가기 전의 입력 · 점검 · 승인 — 과 전기 직후의 대사를 맡고, 분석 화면은 입력 경로 · 위험 구간처럼 표준 원장에 없는 차원을 더해 봅니다. 표준 분석 앱의 이름은 고객사 버전에 따라 다르므로 도입 때 확인합니다.

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

분석 지표 정의표

CDS 구성 — 운영 데이터로 옮길 때의 뷰 설계

화면이 읽는 서비스는 하나지만, 운영 데이터로 옮길 때는 기준 테이블 → 기본 뷰 → 차원 → 큐브 → 쿼리 → 권한 → 서비스로 나눠 둡니다. 분개 패턴과 점검 규칙은 회사가 자주 바꾸므로 코드가 아니라 데이터로 둡니다.

뷰 레이어 구성

① 분개 패턴 매핑 테이블

한 줄 분개의 품질은 이 테이블이 정합니다. 키워드와 방향(수익 · 비용)으로 계정 · 부가세 코드 · 결제 수단 · 원가센터를 찾고, 전기될 때마다 사용 건수를 올려 많이 쓰인 패턴을 먼저 추천합니다.

" ─── ZJEP_PATTERN ─────────────────────────────────────────
"  역할 : 적요 키워드 → 추천 계정 · 부가세 코드 매핑
"  나눈 이유 : 계정과목표가 회사마다 달라 코드가 아니라 데이터로 둔다
" ──────────────────────────────────────────────────────────
@EndUserText.label : '한 줄 분개 패턴'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zjep_pattern {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key keyword   : abap.char(20) not null;   " 적요 키워드
  direction     : abap.char(3);             " REV 수익 · EXP 비용
  blart         : blart;                    " 전표 유형
  hkont         : hkont;                    " 추천 계정
  mwskz         : mwskz;                    " 추천 부가세 코드
  kostl         : kostl;                    " 추천 원가센터
  use_cnt       : abap.int4;                " 전기된 사용 건수
  last_used     : abap.dats;
}

② 점검 규칙 테이블

13개 규칙의 점수 · 기준값 · 차단 여부를 데이터로 둡니다. 내부통제 기준이 바뀌면 이 테이블만 고칩니다.

" ─── ZJEP_CHKRULE ─────────────────────────────────────────
"  역할 : 전기 전 점검 규칙(점수 · 기준값 · 수준)
"  나눈 이유 : 차단 / 경고 판단은 회사 정책이라 데이터로 관리
" ──────────────────────────────────────────────────────────
@EndUserText.label : '전기 전 점검 규칙'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zjep_chkrule {
  key client  : abap.clnt not null;
  key rule_id : abap.char(4) not null;     " C01 ~ C13
  rule_text   : abap.char(40);
  rule_level  : abap.char(5);              " BLOCK · WARN · INFO
  score       : abap.int2;                 " 0 ~ 100
  param       : abap.dec(15,2);            " 기준값(일 · 배 · 원)
  active      : abap_boolean;
}

③ 전표 라인 기본 뷰

전표 라인에 헤더와 세금 데이터를 붙이고 차변 · 대변을 나눕니다. 금액은 통화와 짝으로 선언해 집계 때 통화가 섞이지 않게 합니다.

" ─── ZI_JePostItem ────────────────────────────────────────
"  역할 : BSEG + BKPF + BSET 기본 뷰 (모든 상위 뷰의 원천)
" ──────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '회계전표 라인 (기본)'
@ObjectModel.usageType : { serviceQuality : #C, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
define view entity ZI_JePostItem
  as select from bseg as i
    inner join bkpf as h on  h.bukrs = i.bukrs
                         and h.belnr = i.belnr
                         and h.gjahr = i.gjahr
  association [0..1] to ZI_JePostAccount as _Account
    on  $projection.CompanyCode = _Account.CompanyCode
    and $projection.GlAccount   = _Account.GlAccount
{
  key i.bukrs as CompanyCode,
  key i.belnr as AccountingDocument,
  key i.gjahr as FiscalYear,
  key i.buzei as LineItem,
      h.blart as DocumentType,
      h.budat as PostingDate,
      h.bldat as DocumentDate,
      h.monat as FiscalPeriod,
      h.stblg as ReversalDocument,
      i.bschl as PostingKey,
      i.shkzg as DebitCredit,
      i.hkont as GlAccount,
      i.kunnr as Customer,
      i.lifnr as Supplier,
      i.mwskz as TaxCode,
      i.kostl as CostCenter,
      @Semantics.currencyCode : true
      h.hwaer as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      case i.shkzg when 'S' then i.dmbtr else cast( 0 as abap.curr( 23, 2 ) ) end as DebitAmount,
      @Semantics.amount.currencyCode : 'Currency'
      case i.shkzg when 'H' then i.dmbtr else cast( 0 as abap.curr( 23, 2 ) ) end as CreditAmount,
      _Account
}

④ 계정 차원 뷰

계정 그룹과 조정계정 유형은 점검 규칙(C03 · C06 · C10)과 분석 축이 함께 씁니다.

" ─── ZI_JePostAccount ─────────────────────────────────────
"  역할 : 계정 · 계정 그룹 · 조정계정 유형 · 계정명 차원
" ──────────────────────────────────────────────────────────
@EndUserText.label : '계정 (차원)'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'GlAccount'
define view entity ZI_JePostAccount
  as select from skb1 as b
    inner join t001 as c on c.bukrs = b.bukrs
    inner join ska1 as a on a.ktopl = c.ktopl and a.saknr = b.saknr
    left outer join skat as t on  t.ktopl = c.ktopl
                              and t.saknr = b.saknr
                              and t.spras = $session.system_language
{
  key b.bukrs as CompanyCode,
  key b.saknr as GlAccount,
      a.ktoks as AccountGroup,
      b.mitkz as ReconciliationType,   " D 고객 · K 공급업체 · 빈 값 일반
      b.mwskz as AllowedTaxCategory,
      t.txt50 as GlAccountName
}

⑤ 점검 판정 뷰

라인 단위로 차단 · 경고 조건을 계산합니다. 화면의 전기 전 점검과 야간 배치가 같은 판정을 씁니다. 중복 의심 · 이상 금액처럼 다른 전표와 비교하는 규칙은 서비스 쪽 로직으로 둡니다.

" ─── ZI_JePostRisk ────────────────────────────────────────
"  역할 : 라인 단위 점검 규칙 판정 (C03 조정계정 거래처 · C10 원가센터 · C06 코드 방향)
" ──────────────────────────────────────────────────────────
@EndUserText.label : '전기 전 점검 (라인 판정)'
define view entity ZI_JePostRisk
  as select from ZI_JePostItem as l
{
  key l.CompanyCode,
  key l.AccountingDocument,
  key l.FiscalYear,
  key l.LineItem,
      case when l._Account.ReconciliationType = 'D' and l.Customer = ''
             or l._Account.ReconciliationType = 'K' and l.Supplier = ''
           then 'C03' else '' end as BlockRule,
      case when l._Account.AccountGroup = 'EXP' and l.CostCenter = ''
           then 'C10' else '' end as WarnCostCenter,
      case when l._Account.AccountGroup = 'REV' and left( l.TaxCode, 1 ) = 'V'
             or l._Account.AccountGroup = 'EXP' and left( l.TaxCode, 1 ) = 'A'
           then 'C06' else '' end as WarnTaxDirection
}

⑥ 큐브 — 차변 · 대변 · 세액 · 라인 수

분석 화면의 모든 숫자는 이 큐브 한 곳에서 나옵니다. 입력 경로와 위험 구간은 앱이 기록한 값을 헤더에서 이어 붙입니다.

" ─── ZI_JePostCube ────────────────────────────────────────
"  역할 : 차원 8개 × 측정값 4개 집계 (기간 · 회사 · 유형 · 계정 그룹 · 계정 · 코드 · 경로 · 위험)
" ──────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@ObjectModel.modelingPattern : #ANALYTICAL_CUBE
@ObjectModel.supportedCapabilities : [ #ANALYTICAL_PROVIDER, #SQL_DATA_SOURCE ]
@EndUserText.label : '회계전표 큐브'
define view entity ZI_JePostCube
  as select from ZI_JePostItem as l
{
  l.CompanyCode,
  l.FiscalYear,
  l.FiscalPeriod,
  l.DocumentType,
  l._Account.AccountGroup as AccountGroup,
  l.GlAccount,
  l.TaxCode,
  l.Currency,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  l.DebitAmount,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  l.CreditAmount,
  @Aggregation.default : #SUM
  cast( 1 as abap.int4 ) as LineCount
}

⑦ 분석 쿼리 — 축과 필수 필터

기간을 필수 필터로 강제해 전체 기간 집계가 실수로 돌지 않게 하고, 순 차변 · 라인당 평균 금액을 계산 항목으로 둡니다.

" ─── ZC_JePostQuery ───────────────────────────────────────
"  역할 : 행 · 열 축, 필수 필터(기간), 계산 항목
" ──────────────────────────────────────────────────────────
@Analytics.query : true
@EndUserText.label : '회계전표 분석'
define transient view entity ZC_JePostQuery
  provider contract analytical_query
  with parameters
    @Consumption.defaultValue : '009'
    p_period : fins_fiscalperiod
  as projection on ZI_JePostCube
{
  @AnalyticsDetails.query.axis : #ROWS
  AccountGroup,
  @AnalyticsDetails.query.axis : #ROWS
  GlAccount,
  @AnalyticsDetails.query.axis : #FREE
  DocumentType,
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true }
  CompanyCode,
  DebitAmount,
  CreditAmount,
  LineCount,
  @EndUserText.label : '순 차변'
  @Aggregation.default : #FORMULA
  $projection.DebitAmount - $projection.CreditAmount as NetDebit
}
where FiscalPeriod = $parameters.p_period

⑧ 권한 — 회사 코드와 전표 유형

데모의 사용자 전환을 운영에서는 이 권한 정의와 PFCG 역할이 대신합니다. 집계 단계에서 걸어야 다른 회사 숫자가 합계로 새지 않습니다.

" ─── ZC_JePostQuery (DCL) ─────────────────────────────────
"  역할 : 회사 코드 · 전표 유형 단위 조회 권한
" ──────────────────────────────────────────────────────────
@EndUserText.label : '회계전표 분석 권한'
@MappingRole : true
define role ZC_JePostQuery {
  grant select on ZC_JePostQuery
    where ( CompanyCode )  = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( DocumentType ) = aspect pfcg_auth( F_BKPF_BLA, BRGRU, ACTVT = '03' );
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

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

만드는 쪽에서 먼저 대사식을 세워 검증용 샘플 데이터 전체(전표 922건 · 항목 2,554행)에 돌린 결과입니다.

차이 11건(R2 2 · R3 1 · R4 2 · R6 2 · R7 4)은 대사가 실제로 잡아내는지 보려고 일부러 넣은 예외이며, 예기치 않은 차이는 0건입니다. 화면 쪽은 자동화로 따로 돌려 축을 다섯 가지로 바꿔도 총합(896,318,800원)이 같고, 드릴스루 칸 금액과 라인 합계가 같은지 매번 다시 잽니다.

운영 데이터로 갈 때

전표 라인이 수천만 건이면 집계는 큐브 뷰에서 데이터베이스가 하고, 화면은 기간 필수 필터로 범위를 좁혀 큐브 결과만 받습니다. 전기 전 점검의 라인 판정은 뷰에서, 중복 의심 · 이상 금액처럼 과거 전표와 비교하는 규칙은 회사 · 거래처 · 금액 인덱스를 전제로 서비스에서 계산합니다. 드릴스루는 칸 조건 그대로 라인을 페이지 단위로 읽고, 목록 응답은 건수와 함께 50행씩 가져옵니다. 응답 시간 기준(예: 분석 조회 3초 안)은 도입 때 데이터 양을 보고 정합니다.

자주 묻는 질문 — 숫자, 화면, 점검 기능, 도입과 운영

도입 검토에서 나올 만한 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

점검과 분석 기능

도입과 운영