SAP 구매-지급 통합 관리 — 구매요청에서 지급까지 한 앱에서 처리하고 승인하고 대사하는 구매 운영

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

구매 담당은 매일 같은 질문을 받습니다. 이 발주는 승인이 끝났나, 입고와 송장이 발주와 맞나, 지급은 나갔나. 지금은 이 답이 ME21N · MIGO · MIRO · FBL1N 같은 표준 화면과 엑셀 대사표, 메일 승인으로 흩어져 있어서 한 건을 따라가려면 화면을 여러 번 오가야 합니다. 이 앱은 구매요청부터 지급까지 문서를 한 줄로 이어 붙여 처리 · 승인 · 점검을 한 곳에서 하게 하고, 단계 사이 금액이 맞는지를 매번 대사식으로 확인합니다.

승인은 금액에 따라 한 명 또는 두 명이 하고, 작성자가 자기 문서를 승인할 수 없는 직무 분리를 서버가 판정합니다. 일괄 실행은 시뮬레이션으로 대상과 합계를 먼저 보여 준 뒤에만 실행되고, 같은 조건으로 다시 돌려도 문서가 두 번 만들어지지 않습니다. 이 앱은 업무 처리와 점검을 돕는 도구이며, 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 계획 대비 발주금액 차이 1,000만 원의 요인

검증용 샘플 데이터의 2026-04 ~ 2026-10 범위에서 계획 발주금액은 1,426,465,667원, 실적 발주금액은 1,436,472,652원이었고 총차이는 10,006,986원(약 1,001만 원)이었습니다. 요인분해는 이 차이를 물량 약 −2,254만 원 · 단가 +1,539만 원 · 긴급 할증 +1,501만 원 · 환율 +214만 원으로 가릅니다. 물량은 계획보다 덜 발주해 차이를 줄였지만 단가와 긴급 할증이 더 크게 올렸다는 뜻이어서, 회의의 주제가 "왜 늘었나"에서 "긴급 발주를 어디서 줄일까"로 바뀝니다.

분해에는 조건을 걸었습니다. 요인의 합이 총차이와 어긋나면 안 됩니다. 화면 아래에 "요인 합 10,006,986 = 총차이 10,006,986, 검산 0"이 매번 적힙니다. 대사도 같은 방식입니다. 대사 규칙 4개를 전수로 돌려 865건을 점검했고, 나온 차이 11건은 검증을 위해 의도적으로 넣어 둔 예외 11건(R01 4건 · R02 3건 · R03 2건 · R04 2건)과 정확히 같았으며 그 밖의 차이는 0건이었습니다.

도입하면 달라지는 것

• 처리 화면 — 표준 T-code 를 바꿔 열던 일이 상태 이력 · 항목 · 연계 문서가 있는 한 화면으로 모입니다.
• 승인 — 메일로 돌던 승인선이 금액별 1~2단계로 화면에 남고, 직무 분리 위반은 서버가 먼저 막습니다.
• 월말 점검 — 엑셀 대사표 네 장이 규칙 네 개와 예외 목록으로 바뀌고, 조치 내용이 감사 로그에 남습니다.
• 회의 — "어느 숫자가 맞나"보다 "이 차이를 누가 어떻게 조치하나"를 이야기합니다.
• 놓치는 날 — 화면을 열지 않은 날에도 감시 규칙에 걸린 항목이 받을 역할의 대기함으로 올라갑니다.

이런 회사에 맞습니다

구매요청 · 발주 · 입고 · 송장검증 · 지급이 SAP 에서 이어지는데 단계 사이 대사를 엑셀로 하고 있는 회사, 공급사 · 자재그룹별 리포트가 여러 벌이라 숫자를 맞추는 데 시간을 쓰는 구매 · 구매 관리팀, 승인 단계와 직무 분리를 시스템으로 남기려는 경영지원 조직에 맞습니다. 월 처리 문서가 수백~수천 건이고, 사업장이 둘 이상이며, 구매 담당 · 구매 책임 · 재무 담당이 한 건을 나눠 처리하는 구조에서 효과가 큽니다.

실행 화면

실제로 돌아가는 화면 51종을 쓰는 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 무엇을 누르면 무엇이 일어나는지를 아래에 적었습니다. 모든 이름과 금액은 가상의 검증용 샘플입니다.

사용 방법

1. 조회조건 입력 — 모든 화면 위에 사업장 · 기간(시작) · 기간(종료)가 있고 모두 선택 항목입니다. 기본값은 사업장 전체, 2026-04 ~ 2026-10 입니다.
2. 조회 버튼과 Enter — 조회 버튼은 조회조건 영역의 오른쪽 끝에 있고, 입력란에서 Enter 를 눌러도 조회됩니다. 개요 화면은 열면 자동으로 조회합니다.
3. 요약 확인 — 개요의 KPI 카드(미입고 발주 잔액 · 입고-송장 미결 · 미지급 채무 · 승인 대기 · 반려 · 미해결 대사 예외 · 확정 문서 · 열린 할 일)와 할 일 목록을 봅니다.
4. 탭 이동 순서 — 개요 · 할 일 → 기준정보 → 문서 처리 → 일괄 실행 → 대사 · 점검 → 분석 → 문서 흐름 → 이력 · 감사 · 권한. 카드나 할 일을 누르면 해당 화면으로 이동합니다.
5. 행 · 셀 클릭 상세 — 문서 목록 행을 누르면 오른쪽에 문서 상세가 열리고, 분석 표의 칸을 누르면 원천 문서 줄이 열립니다. 문서 번호를 누르면 문서 상세로 이동합니다.
6. 내보내기 — 목록 위의 CSV · xlsx 로 현재 조회 결과를 내려받고, 분석의 PowerPoint 는 현재 범위의 표와 차트를 브라우저에서 만듭니다.

무엇으로 만들었나

처음 열었을 때 — 한 화면에서 오늘 할 일까지

개요 화면은 열자마자 자동으로 조회됩니다. KPI 카드는 숫자를 누르면 해당 화면으로 이동하는 입구이기도 합니다.

카드는 발주금액 − 입고금액 누계(미입고), 입고금액 − 송장 정리 금액(입고-송장 미결), 송장금액 − 지급금액(미지급)처럼 산식이 카드 아래에 적혀 있습니다. 사업장과 기간을 바꾸고 조회하면 서버 집계와 같은 값으로 갱신됩니다.

열린 할 일은 승인 대기(검토요청) + 반려 + 미해결 대사 예외 + 납기가 지난 진행 문서의 합입니다. 행을 누르면 해당 문서 또는 예외 화면으로 바로 이동합니다.

기준정보 관리 — 역할에 따라 버튼이 달라진다

공급사 · 자재 · 단가 같은 기준정보를 한 화면에서 보고 고칩니다. 변경은 이력으로 남습니다.

역할은 요청 머리의 사용자로 판정하며, 조회자에게는 생성 · 수정 · 중지가 비활성입니다. 화면을 우회해 직접 요청해도 서버가 같은 규칙으로 거절합니다.

처리자로 바꾸면 생성 버튼이 켜집니다. 검색어는 번호와 이름에 모두 걸립니다.

필수 항목이 비면 저장되지 않고 항목 옆에 사유가 표시됩니다. 값 목록(구분 · 지역 · 지급조건)은 서비스가 돌려주는 코드와 이름으로 채웁니다.

저장 직후 목록을 다시 읽어 서버에 반영된 값으로 보여 줍니다.

키(번호)는 고칠 수 없고 이름 · 구분 · 지급조건 같은 항목만 바뀝니다. 중지를 누르면 삭제가 아니라 사용 중지로 남습니다.

변경자와 변경 시각, 바뀐 항목이 줄로 쌓입니다. 감사 로그 화면에서도 같은 기록을 다시 찾을 수 있습니다.

문서 처리와 승인 — 승인 버튼과 직무 분리

구매요청 · 발주 · 입고 · 송장검증 · 지급 문서를 한 목록에서 처리합니다. 상태는 임시저장 → 검토요청 → 승인 → 확정(전기)이며 반려와 취소가 있습니다.

문서번호 아래에 구분(구매요청 · 발주 · 입고 · 송장검증 · 지급)이 붙고, 공급사 아래에 요약이 붙습니다. 좁은 화면에서는 발주번호 · 사업장 · 문서일 · 금액 열이 숨겨집니다.

공급사와 자재의 계약 단가가 없는 조합은 서버가 저장을 거절하고 이유를 메시지로 돌려줍니다.

임시저장 상태에서는 수정과 검토 요청만 보입니다. 서버가 돌려준 허용 동작 목록이 버튼을 결정하므로 화면과 서버 판정이 어긋나지 않습니다.

요청하면 상태가 검토요청으로 바뀌고 상태 이력에 한 줄이 쌓입니다.

처리자 화면에서는 승인 · 반려 버튼이 보이지 않고, 승인 대기 건수가 개요 KPI 에 반영됩니다.

승인 권한이 있는 사용자가 자기 문서를 승인하려 하면 서버가 직무 분리 위반으로 거절하고 이유를 메시지로 보여 줍니다. 상태는 바뀌지 않습니다.

승인자 화면에서는 승인 · 반려 버튼이 켜지고, 3,000만 원 이상 문서는 승인이 두 단계로 진행됩니다.

1단계 승인 후에도 상태는 검토요청이고, 다음 승인자 차례가 상태 이력에 남습니다.

같은 사람이 두 단계를 모두 승인할 수 없습니다. 두 번째 승인이 끝나야 승인(30)이 됩니다.

확정 시 차변 합과 대변 합이 다르면 서버가 거절합니다. 확정 후에는 수정할 수 없고 취소는 역처리로만 합니다.

역처리는 원 문서를 지우지 않고 반대 문서를 만들어 원 문서에 연결합니다. 사유는 필수입니다.

원 문서의 상태는 취소(99)가 되고 연계 문서 탭에서 반대 문서로 이동할 수 있습니다.

업로드한 파일을 브라우저에서 읽어 오류 행(수량 0 등)을 먼저 보여 주고, 정상 행만 반영합니다. 문서일은 2026-10-12 처럼 쓴 형식만 받습니다.

정상 세 행이 문서 세 건으로 만들어졌고, 오류 행 한 줄은 반영되지 않은 사실이 결과에 남습니다.

일괄 실행 — 시뮬레이션 다음에만 실행된다

대상을 먼저 계산해 보여 주고, 같은 결과일 때만 실행합니다.

실행 유형을 고르면 해당 조건의 대상만 계산합니다. 시뮬레이션을 하지 않으면 실행 버튼은 요청을 서버로 보내도 거절됩니다.

검증용 샘플에서 시뮬레이션 합계는 7,379,752원이었고, 이 값이 실행 뒤 만들어진 문서의 합과 같아야 합니다.

실행으로 문서 4건이 만들어졌고 합계가 시뮬레이션 합계 7,379,752원과 같았습니다. 로그에는 건별 결과가 한 줄씩 남습니다.

이미 만든 대상은 건너뛰어 재실행에서 새로 만들어진 문서가 없다는 로그가 남습니다. 운영에서 배치로 돌릴 때도 같은 규칙을 씁니다.

대사와 예외 조치 — 단계 사이 금액을 맞춘다

규칙 네 개를 한 번에 돌리고, 차이는 예외로 올려 조치합니다.

R01 발주 = 입고 + 미입고, R02 입고 = 송장 + 입고-송장 미결, R03 송장 = 지급 + 미지급, R04 구매요청 = 발주 전환 + 미전환. 허용 오차는 1원입니다.

검증용 샘플에는 대사 차이를 확인하기 위해 의도적으로 넣은 예외 11건이 있고, 목록에서 의도적 예외로 표시됩니다.

조치 유형과 사유를 입력합니다. 사유가 없으면 저장되지 않습니다.

조정문서를 선택하면 차이 금액을 맞추는 문서가 만들어지고 예외에 연결됩니다.

조치한 예외는 미해결에서 조치 중 또는 해결로 바뀌고, 개요의 미해결 예외 수에서 빠집니다.

조정문서로 정리한 건은 재대사에서 차이가 아니게 됩니다. 규칙별 건수가 그 자리에서 갱신됩니다.

분석 — 축만 바꾸는 피벗과 셀에서 문서까지

분석은 서버가 집계 행을 한 번 돌려주면 브라우저가 다시 묶습니다. 축을 바꿔도 서버 요청이 생기지 않습니다.

쓰지 않는 차원 · 행 축 · 열 축 세 칸에 차원 칩이 있습니다. 기본 레이아웃에 자동 조회가 켜져 있으면 열자마자 조회합니다.

표 아래 한 줄에 피벗 총합과 원천 라인 합계가 같은지 검산이 적힙니다. 오른쪽 차트는 같은 값을 그립니다.

행은 최대 3단계, 열은 최대 2단계까지 쌓입니다. 합계는 축을 바꿔도 변하지 않습니다.

맨 위 건수와 합계가 눌렀던 셀 금액과 같아야 합니다. 같지 않으면 그것이 오류 신호입니다.

분석에서 본 숫자를 만든 문서의 상태와 이력을 바로 열어 봅니다.

칸마다 차이와 증감률이 붙습니다. 색은 금액과 증감률이 둘 다 기준을 넘을 때만 입힙니다.

계획 1,426,465,667원에서 실적 1,436,472,652원까지 물량 · 단가 · 긴급 할증 · 환율로 가르고, 맨 아래 검산 줄이 요인 합과 총차이가 같은지(0) 적습니다.

역할을 고르면 그 역할이 먼저 볼 지표가 앞에 나옵니다. 숫자는 같은 집계에서 나옵니다.

열 조합이 상한(36개)을 넘으면 표를 그리지 않고 안내합니다. 현재 범위는 138개라 축을 줄이라고 알려 줍니다.

영역 간 연계 — 구매 문서에서 재무 · 자재 · 원가 · 자금으로

문서 번호 하나로 앞 문서와 뒤 문서를 따라갑니다.

발주 한 건의 앞 문서(구매요청)와 뒤 문서(입고 · 자재 문서 · 송장검증 · 재무 전표 · 지급 · 자금 전표)가 화살표로 이어집니다. 구매 문서는 번호를 누르면 문서 처리로 이동합니다.

다른 영역 문서는 영역 · 문서 · 일자 · 이전 · 다음 문서를 담은 상세 팝업으로 열립니다. 이 앱이 처리하지 않는 영역은 조회만 합니다.

AI 분석과 에이전트 — 숫자는 서비스가 계산한다

해설은 규칙 기반이 기본이고, 숫자를 새로 만들지 않습니다.

해설 아래에 근거 표를 펼쳐 볼 수 있어 어떤 숫자를 읽었는지 확인합니다. 모델 연결은 서비스 설정 하나로 켜고 기본은 꺼져 있으며, 키는 앱에 두지 않습니다.

납기 지연 입고 비율 · 계약 단가 대비 상승 · 입고-송장 장기 미결 · 불량 수량 비율 같은 규칙과 받을 역할이 보입니다.

실행은 하루 한 번으로 제한되며 서버가 판정합니다. 걸린 항목이 없어도 호출 주체와 시각이 활동 기록에 남습니다.

이력 · 감사 · 역할 · 레이아웃 — 누가 무엇을 했나

모든 처리에 로그가 남고, 역할은 화면과 서버가 같은 규칙으로 판정합니다.

거절된 승인 시도도 로그에 남습니다. 사용자 · 동작 · 대상으로 찾을 수 있습니다.

조회자는 문서 목록과 상세를 볼 수 있지만 생성 · 업로드가 비활성이며 서버도 직접 요청에 403 을 돌려줍니다.

기본 레이아웃으로 지정하면 다음에 열 때 그 배치로 시작하고, 자동 조회를 켜 둘 수 있습니다.

좁은 화면 — 390px 에서도 같은 기능

휴대폰 폭에서는 메뉴가 레일로 접히고 표와 차트가 세로로 쌓입니다.

왼쪽 메뉴는 56px 레일로 접히고, KPI 카드는 한 열로 내려갑니다.

피벗 표는 가로로 밀어 보고, 차트는 표 아래에 둡니다. 조회 · 초기화 버튼은 그대로 조회조건 오른쪽 끝에 있습니다.

화면 뒤에서 일어나는 일

화면은 OData V2 서비스를 읽고 쓰며, 판정은 서비스 로직이 합니다. 목록 · 상세는 엔티티셋 바인딩과 Filter 로 읽고, 검토요청 · 승인 · 반려 · 확정 · 역처리 · 시뮬레이션 · 실행 · 대사 · 조치 · 요인분해 · AI 해설 · 에이전트는 펑션으로 호출합니다. 분석은 집계 행을 한 번 읽어 브라우저에서 다시 묶습니다. 요청 머리의 사용자로 역할을 판정하므로 화면을 우회해도 같은 규칙이 적용됩니다.

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

처리 단계와 대사식

업무 흐름은 구매요청 → 발주 → 입고 → 송장검증 → 지급이며, 단계 사이 금액을 대사식 네 개가 맞춰 봅니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 왼쪽 메뉴가 56px 레일로 접히고, 목록에서는 발주번호 · 사업장 · 문서일 · 금액 열이 숨겨집니다. 분석은 차트가 표 아래로 내려갑니다. 조회 · 초기화 버튼의 위치는 같습니다.

파일 구성

app/
  Component.js · manifest.json · index.html · readme.html
  controller/   (화면별 컨트롤러 · 기반 컨트롤러)
  view/         (화면 XML 9개 · fragments 다이얼로그)
  model/        (집계 · 차트 · xlsx · pptx · 서식 · 오류 처리 모듈)
  css/ · i18n/
  odata/        (서비스 로직 · 메타데이터 · 엔티티셋별 샘플 데이터)
  media/        (소개 영상 · 포스터 · 목차 트랙)

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

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

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

T-code 별 연계 지점

맞닿은 표준 T-code 마다 이어받는 데이터, 두 화면 숫자를 맞춰 보는 지점, 오가는 방법, 표준에 남겨 둘 일을 정리했습니다. 운영 전환 때 기존 표준 리포트를 없앨 필요는 없습니다. 표준 리포트는 그대로 두고 이 앱은 처리 도중의 조회 · 대사에 씁니다.

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

S/4HANA 에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 표준 분석 도구가 있습니다. 이 앱의 피벗과 차이 분해는 그 도구를 대체하지 않고, 같은 CDS 뷰 위에서 처리 · 승인 · 대사와 같은 화면에 붙은 분석이라는 자리를 맡습니다. 표준 분석 앱이 이미 충분한 조회라면 그대로 쓰고, 처리 도중에 숫자를 확인해야 할 때 이 앱을 쓰도록 나누는 것을 권합니다. 어떤 표준 Fiori 앱이 있는지는 고객사의 릴리스와 활성화 상태에 따라 다르므로 이 글에서는 앱 이름을 단정하지 않고, 운영 연결 전에 확인할 항목으로 남깁니다.

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

분석 지표 정의

CDS 구성 — 최대한 자세히

운영 전환 때는 이 앱의 엔티티를 CDS 뷰로 노출합니다. 아래 코드는 구조와 결정 지점을 보여 주는 스케치이며, 원천 필드와 설정값은 고객사 시스템에서 확인해야 합니다(확인하지 못한 부분은 주석에 "확인 필요"로 적었습니다).

뷰 레이어 구성

원천 테이블과 필드 매핑

① 상태 전이 규칙 테이블 — 코드가 아니라 데이터로 두는 이유

문서가 어느 상태에서 어떤 동작으로 어디로 가는지, 그 동작에 어떤 역할이 필요한지가 이 표 한 곳에서 결정됩니다. 규칙이 코드에 박혀 있으면 승인 정책이 바뀔 때마다 이송이 필요하지만 테이블이면 설정 이송으로 끝납니다.

" ───────────────────────────────────────────────────────────────
" ZPUR_STATRULE — 구매 문서 상태 전이 규칙
" 역할 : 이전 상태 · 동작 · 다음 상태 · 필요 역할을 정의한다.
" 이렇게 나눈 이유 : 승인 정책(상태 · 역할)을 코드가 아닌 설정 데이터로 둔다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '구매 문서 상태 전이 규칙'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpur_statrule {
  key client      : abap.clnt not null;
  key from_status : abap.char(2) not null;   " 10 임시저장 · 20 검토요청 · 30 승인 · 40 확정 · 90 반려 · 99 취소
  key action      : abap.char(10) not null;  " SUBMIT · APPROVE · REJECT · POST · REVERSE
  to_status       : abap.char(2) not null;
  need_role       : abap.char(10) not null;  " HANDLER · APPROVER (운영에서는 권한 객체로 대체)
  step_text       : abap.char(60);
}

② 공급사 차원 뷰 — 이름과 코드를 한 번에

공급사는 분석 축이면서 대사 근거이기도 합니다. 공급사 기본 정보와 회사코드 데이터를 한 뷰로 묶어 두면 큐브와 쿼리가 같은 이름으로 공급사를 말합니다.

" ───────────────────────────────────────────────────────────────
" ZI_PurVendor — 공급사 차원
" 역할 : 공급사 번호 · 이름 · 지급조건을 분석 축에 제공한다.
" 이렇게 나눈 이유 : 큐브에서 이름을 다시 조인하지 않고 차원 뷰로 재사용한다.
" 확인 필요 : 지급조건 필드는 고객사 설정에 따라 다를 수 있다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '구매 공급사 차원'
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'Vendor'
define view entity ZI_PurVendor
  as select from lfa1
  left outer join lfb1 on lfb1.lifnr = lfa1.lifnr
{
  @ObjectModel.text.element: ['VendorName']
  key lfa1.lifnr as Vendor,
  lfa1.name1     as VendorName,
  lfa1.land1     as Country,
  lfb1.bukrs     as CompanyCode
}

③ 문서 흐름 큐브 — 발주 · 입고 · 송장을 같은 키로

발주 한 줄에 입고와 송장이 이어지는 이력은 구매 문서 이력 테이블에 쌓입니다. 이 뷰는 그 이력을 발주 줄 기준으로 모아 대사와 분석이 같은 숫자를 읽게 합니다.

" ───────────────────────────────────────────────────────────────
" ZI_PurFlowCube — 구매 흐름 집계(발주 · 입고 · 송장)
" 역할 : 기간 · 플랜트 · 공급사 · 자재그룹별 금액을 모은다.
" 이렇게 나눈 이유 : 분석(피벗)과 대사(R01~R03)가 같은 집계를 읽는다.
" 확인 필요 : 이력 유형 값(입고 · 송장)과 통화 환산 방식은 고객사 확인.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '구매 흐름 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_PurFlowCube
  as select from ekpo
  inner join ekko on ekko.ebeln = ekpo.ebeln
  left outer join ekbe on ekbe.ebeln = ekpo.ebeln and ekbe.ebelp = ekpo.ebelp
{
  key ekpo.ebeln as PurchaseOrder,
  key ekpo.ebelp as PurchaseOrderItem,
  ekko.lifnr     as Vendor,
  ekpo.werks     as Plant,
  ekpo.matkl     as MaterialGroup,
  ekko.waers     as Currency,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  ekpo.netwr     as OrderAmount,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  case when ekbe.vgabe = '1' then ekbe.dmbtr else cast( 0 as abap.curr(13,2) ) end as GoodsReceiptAmount,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  case when ekbe.vgabe = '2' then ekbe.dmbtr else cast( 0 as abap.curr(13,2) ) end as InvoiceAmount,
  @Semantics.amount.currencyCode: 'Currency'
  @DefaultAggregation: #SUM
  " 미입고 금액 : 납품 완료 표시가 있으면 0, 아니면 발주 금액 − 입고 금액 (확인 필요: 부분 입고 계산 방식)
  case when ekpo.elikz = 'X' then cast( 0 as abap.curr(13,2) )
       else ekpo.netwr - case when ekbe.vgabe = '1' then ekbe.dmbtr else cast( 0 as abap.curr(13,2) ) end end as OpenAmount
}

④ 대사 규칙 R01 뷰 — 발주 = 입고 + 미입고

규칙마다 뷰를 따로 두면 규칙별 점검 건수와 차이 건수를 각각 셀 수 있고, 허용 오차를 규칙마다 다르게 둘 수 있습니다. 아래는 R01 입니다.

" ───────────────────────────────────────────────────────────────
" ZI_PurReconR01 — 발주 금액 = 입고 금액 + 미입고 금액 대조
" 역할 : 발주 줄별 차이를 계산하고 허용 오차를 넘으면 표시한다.
" 이렇게 나눈 이유 : 규칙별 점검 건수 · 차이 건수를 따로 센다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '대사 R01 — 발주 = 입고 + 미입고'
define view entity ZI_PurReconR01
  as select from ZI_PurFlowCube
{
  key PurchaseOrder,
  key PurchaseOrderItem,
  Currency,
  OrderAmount,
  GoodsReceiptAmount,
  OpenAmount,
  OrderAmount - ( GoodsReceiptAmount + OpenAmount ) as Difference,
  case when abs( OrderAmount - ( GoodsReceiptAmount + OpenAmount ) ) > 1
       then 'X' else '' end as IsDifference   " 허용 오차 1원
}

⑤ 분석 쿼리 — 피벗 화면이 읽는 뷰

화면 필터와 측정값 노출은 쿼리 한 곳에서 정합니다. 화면이 읽는 필드가 늘면 이 뷰만 고치면 됩니다.

" ───────────────────────────────────────────────────────────────
" ZC_PurPivotQuery — 구매 피벗 분석 쿼리
" 역할 : 큐브 위에 화면 필터와 측정값 · 계산항목을 얹는다.
" 이렇게 나눈 이유 : 큐브는 재사용하고, 화면이 바뀌어도 쿼리만 고친다.
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '구매 피벗 분석 쿼리'
@Analytics.query: true
define view entity ZC_PurPivotQuery
  as select from ZI_PurFlowCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true, mandatory: false }
  Vendor,
  @AnalyticsDetails.query.axis: #ROWS
  Plant,
  @AnalyticsDetails.query.axis: #COLUMNS
  MaterialGroup,
  @AnalyticsDetails.query.axis: #COLUMNS
  OrderAmount,
  GoodsReceiptAmount,
  InvoiceAmount
}

⑥ 권한(DCL) — 집계 단계에서 걸어야 하는 이유

권한을 드릴스루에만 걸면 합계 · 차이 계산으로 남의 범위 숫자가 새어 나갑니다. 큐브와 쿼리 단계에서 플랜트 범위를 거는 DCL 입니다.

" ───────────────────────────────────────────────────────────────
" ZC_PurPivotQuery — 플랜트 범위 접근 제어
" 역할 : 사용자가 가진 구매 오더 플랜트 권한만 보이게 한다.
" 이렇게 나눈 이유 : 집계 단계에서 걸어 합계로 새는 일을 막는다.
" 확인 필요 : 권한 객체 · 필드 값은 고객사 권한 설계 확인.
" ───────────────────────────────────────────────────────────────
@EndUserText.label: '구매 피벗 쿼리 접근 제어'
@MappingRole: true
define role ZC_PurPivotQuery {
  grant select on ZC_PurPivotQuery
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑦ 문서 처리 액션 — 승인 · 확정을 서버 한 곳에서

화면이 아니라 서버가 상태 전이 · 직무 분리 · 차대 균형을 판정해야 화면을 우회한 요청도 같은 규칙으로 걸러집니다. RAP 동작 정의의 스케치입니다.

" ───────────────────────────────────────────────────────────────
" ZR_PurDoc — 구매 문서 처리 동작 정의(스케치)
" 역할 : 검토요청 · 승인 · 반려 · 확정 · 역처리 액션을 선언한다.
" 이렇게 나눈 이유 : 상태 전이와 직무 분리 판정을 서버 한 곳에 둔다.
" 확인 필요 : 실제 구현 클래스에서 규칙 테이블을 읽는 방식은 고객사 설계.
" ───────────────────────────────────────────────────────────────
managed implementation in class zbp_r_purdoc unique;
strict ( 2 );
define behavior for ZR_PurDoc alias PurDoc
persistent table zpur_doc
lock master
authorization master ( instance )
{
  field ( readonly ) DocNo, Status, ApprovalStep;
  create;
  update;
  action submit result [1] $self;
  action approve result [1] $self;      " 직무 분리: 작성자 ≠ 승인자
  action reject parameter ZA_PurReason result [1] $self;
  action post result [1] $self;         " 차변 합 = 대변 합 검사
  action reverse parameter ZA_PurReason result [1] $self;
  validation checkSegregation on save { action approve; }
  validation checkBalanced on save { action post; }
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 코딩이 아니라 합의가 먼저 필요한 항목입니다.

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

리포트에서 가장 비싼 질문은 "이 숫자 맞아?" 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 도입 포인트의 사례와 같은 숫자입니다.

대사 차이 11건은 검증을 위해 의도적으로 넣은 예외이며 일반 차이와 분리해 기록했습니다. 화면 쪽은 브라우저 자동화로 따로 확인했습니다 — 축을 바꿔도 합계가 변하지 않는지, 셀 금액과 원천 문서 합계가 같은지, 승인 · 직무 분리 · 역처리 · 일괄 실행 · 대사 조치 시나리오(76개)가 모두 통과하는지입니다.

운영 데이터로 갈 때

• 집계 위치 — 전표 · 문서 이력이 수천만 건이면 화면에서 집계하지 않고 CDS 큐브(또는 분석 쿼리)에서 집계합니다. 이 앱의 브라우저 재집계는 조회 범위가 좁을 때 쓰는 방식입니다.
• 파라미터 필수화 — 기간과 플랜트를 필수 조건으로 두어 전체 기간 조회를 막습니다. 화면도 열 조합 상한(36개)과 표시 행 수 상한을 둡니다.
• 인덱스 · 응답 기준 — 조회 조건이 되는 필드(기간 · 플랜트 · 공급사)에 인덱스를 두고, 첫 응답 시간 기준(예: 몇 초 이내)을 도입 단계에서 합의합니다. 구체 수치는 고객사 데이터로 측정한 뒤 정합니다.
• 일괄 실행 — 대상이 많을 때는 시뮬레이션을 건수 상한 안에서 보여 주고, 실행은 배치로 나눠 돌립니다.

자주 묻는 질문 — 최대한 자세히

도입 검토에서 자주 나오는 질문을 숫자와 대사 · 화면과 조작 · 분석 기능 · 도입과 운영으로 묶었습니다. 이 앱은 점검 도구이며 최종 판단은 회사와 감사인(세무 신고는 회사와 세무 대리인)이 합니다.

숫자와 대사

화면과 조작

분석 기능

도입과 운영