SAP 수주-수금 통합 관리 — 견적에서 수금까지 승인 · 대사 · 분석을 한 화면 흐름에서

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

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

영업 현업의 질문은 해마다 같습니다. 이 수주는 승인해도 되나, 출하와 청구는 빠짐없이 이어졌나, 돈은 들어왔나. 지금 이 답은 표준 화면 · 엑셀 대사 · 메일 승인으로 흩어져 있습니다. 이 앱은 견적에서 수금까지를 한 화면 흐름에 붙여, 화면을 옮겨 다니는 시간과 “어느 숫자가 맞나” 하는 회의를 줄입니다.

관련 기준서는 IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)입니다. 이 앱은 수익 인식을 판단하지 않고, 수주 · 출하 · 청구 · 수금의 연결 숫자를 점검하는 도구입니다. 회계 판단과 공시는 회사와 감사인이 합니다.

한 줄 요약 — 처리와 분석을 따로 만들지 않았습니다. 승인과 직무 분리는 서버가 판정하고, 일괄 실행은 시뮬레이션을 거치며, 대사 규칙 다섯 개가 숫자를 매번 검산하고, 분석은 그 숫자를 같은 큐브에서 축과 요인으로 풀어 보여 줍니다.

핵심 포인트 여덟 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 한 앱에서 견적부터 수금까지	기준정보 · 문서 처리 · 승인 · 일괄 실행 · 대사 · 분석 · 감사가 한 앱 안에서 이어집니다. 조회조건과 선택한 문서가 화면을 옮겨도 따라옵니다.	견적 · 수주 · 출하 · 청구 · 수금을 표준 화면으로 따로 열고, 엑셀로 이어 붙여 현황을 만듭니다.
② 작성자는 승인하지 못하는 승인 흐름	임시저장 → 검토요청 → 승인 → 확정 → 취소 순서를 서버가 지킵니다. 작성자 = 승인자 요청과 허용되지 않는 전이는 서버가 거절하고 거절 이력도 남습니다.	메일과 구두로 승인하고, 누가 승인했는지는 나중에 문서를 뒤져 확인합니다.
③ 여신을 보고 승인하는 2단계 판정	수주를 저장하면 한도 · 사용액 · 이번 금액이 점검되고, 1억 원 이상이거나 결과가 정상이 아니면 승인자 두 명이 필요합니다. 예외 승인에는 메모가 남습니다.	출하 직전에 보류가 걸려 영업과 여신 담당이 전화로 사정을 맞춥니다.
④ 시뮬레이션을 거쳐야 도는 일괄 실행	출하와 청구 일괄 생성은 만들어질 문서와 제외될 문서를 먼저 보여 주고, 같은 조건의 시뮬레이션 결과가 있어야 실행됩니다. 재실행은 중복 문서를 만들지 않습니다.	월말에 대상 목록을 엑셀로 뽑아 하나씩 만들고, 두 번 만든 문서를 나중에 찾아냅니다.
⑤ 대사 규칙 다섯 개와 예외 조치	수주 · 출하 · 청구 · 채권 · 여신의 연결 숫자를 규칙으로 매번 맞춰 보고, 어긋난 건은 예외 목록에서 조정 문서나 사유로 조치합니다. 조치하면 차이 건수가 줄어드는 것이 화면에서 보입니다.	월마감 직전에 숫자가 안 맞는 것을 발견하고 원인을 거슬러 올라갑니다.
⑥ 축을 바꿔도 합계가 갈라지지 않는 분석	한 번 읽은 큐브에서 제품군 · 고객 그룹 · 지역 · 월 등의 축을 끌어다 놓아 바꿔 봅니다. 서버를 다시 부르지 않으므로 빠르고, 모든 축이 같은 큐브라 합계가 어긋나지 않습니다.	축마다 리포트를 따로 만들고 합계를 맞추는 회의를 엽니다.
⑦ 숫자에서 문서 라인까지, 차이에서 요인까지	칸을 누르면 그 금액을 만든 문서 라인이 열려 합계 일치를 보여 주고, 계획 대비 차이는 물량 · 믹스 · 단가 · 할인 · 환율 다섯 요인으로 갈라 합이 총차이와 같다고 검산합니다.	차이가 났다는 것까지만 알고, 원인은 엑셀로 다시 분해합니다.
⑧ 숫자를 만들지 않는 AI와 스스로 도는 에이전트	AI 는 서비스가 계산한 숫자를 읽어 해설만 하고 근거 표를 보여 줍니다. 에이전트는 감시 규칙에 걸린 항목을 받을 역할의 대기함에 올리고, 하루 한 번만 돕니다.	화면을 열지 않은 날에는 여신 초과나 장기 미청구 출하가 그대로 지나갑니다.

사례로 보는 효과 — 계획 대비 1억 7,697만 원 차이의 가장 큰 몫은 물량

계획 대비 순매출이 1억 7,697만 원 모자랐다는 것까지는 표준 리포트도 말해 줍니다. 이 앱은 그 다음을 답합니다. 검증용 샘플 데이터에서 계획 2,331,202,210원 대비 실적 2,154,235,823원, 차이 −176,966,387원(−7.6퍼센트)을 다섯 요인으로 가르자 물량(−124,658,834원) 이 가장 큰 몫이었고, 믹스 −38,197,076원 · 할인·리베이트 −13,681,584원 · 단가 −3,836,948원이 뒤를 이었으며 환율은 +3,408,055원이었습니다. 다섯 요인의 합은 총차이와 1원도 어긋나지 않습니다. 고객별로는 고객 두 곳(−32.4퍼센트 · −29.7퍼센트)의 미달이 컸습니다. 원인은 확인 필요이지만, 회의는 “매출이 모자랐다”에서 “어느 고객의 물량을 어떻게 볼 것인가”로 바뀝니다.

숫자의 신뢰도 같은 방식으로 보입니다. 대사 규칙 다섯 개는 1,393건을 검사해 차이 12건을 찾았고, 이 12건은 검증을 위해 일부러 넣은 예외입니다. 큐브 합계와 원천 문서 라인 합계는 여섯 개 측정값 모두에서 같습니다.

도입하면 달라지는 것

화면 이동 — 견적에서 수금까지 한 앱에서 처리하므로 표준 화면과 엑셀을 오가는 횟수가 줄어듭니다.
승인의 기록 — 누가 요청했고 누가 승인했는지, 거절된 시도까지 서버 로그에 남아 감사 대응이 쉬워집니다.
월말 일괄 처리 — 시뮬레이션으로 합계를 먼저 확인하고 실행하므로 중복 생성과 누락 확인에 쓰던 시간이 줄어듭니다.
회의의 주제 — 숫자가 맞는지를 다투는 대신 차이의 요인과 조치를 이야기합니다.
놓치지 않는 감시 — 아무도 화면을 열지 않은 날에도 감시 규칙에 걸린 항목이 받을 사람의 대기함에 올라갑니다.

이런 회사에 맞습니다

SAP S/4HANA 로 수주에서 수금까지를 운영하면서 승인과 대사를 메일과 엑셀로 처리하는 회사에 맞습니다. 월 수백 건에서 수천 건의 영업 문서를 처리하는 영업관리팀 · 여신 담당 · 물류 담당이 함께 쓰고, 영업조직이 둘 이상이거나 고객 그룹별 할인 규칙이 있어 숫자를 맞추는 일이 잦은 조직일수록 효과가 큽니다. 승인 단계는 1~2단계 구조를 기본으로 하며, 단계를 늘리는 일은 운영 시점에 정합니다.

실행 화면

사용 방법

조회조건 입력 — 화면 위쪽 공통 영역에 영업조직(선택, 전체 · 국내영업 · 수출영업)과 기간 시작 · 종료(선택, 형식 2026-01)가 있습니다. 필수 입력은 없고, 비워 두면 전체 기간을 읽습니다.
조회 · Enter — 조회 단추는 조회조건 줄의 오른쪽에 있고 기간 입력 칸에서 Enter 를 눌러도 조회됩니다. 초기화는 조건을 처음 값으로 돌립니다. 앱을 열면 개요 화면이 자동으로 한 번 조회됩니다.
개요 · 할 일 확인 — 첫 화면의 타일 7개(미결채권 · 여신 보류 고객 · 승인 대기 · 반려 · 미해결 대사 예외 · 확정 문서 · 열린 할 일)를 보고 아래 "내 할 일"에서 항목을 눌러 해당 화면으로 이동합니다.
메뉴 순서 — 왼쪽 메뉴를 위에서 아래로: 개요 · 할 일 → 기준정보 관리 → 문서 처리 → 일괄 실행 → 대사 · 점검 → 분석 → 영역 간 연계 → 이력 · 감사 · 권한. 메뉴를 옮겨도 조회조건은 이어집니다.
행 클릭 상세 — 문서 · 기준정보 목록의 행을 누르면 오른쪽에 상세가 열리고, 상태와 내 역할에서 가능한 단추만 켜집니다. 오른쪽 위 사용자 전환으로 조회자 · 처리자 · 승인자 · 관리자를 바꿔 권한 차이를 확인합니다.
분석 사용 — 분석 화면에서 차원 칩을 끌어 행 · 열 축을 바꾸고, 비교 기준을 켜 계획과 견주고, 칸을 눌러 드릴스루를, 행 단추로 요인분해와 변동 사유를 엽니다. 레이아웃은 이름 붙여 저장합니다.
CSV · 보고서 내려받기 — 표 위의 내려받기로 현재 표를 CSV 로, AI 분석 창의 PowerPoint 보고서 단추로 현재 범위의 표 · 차트를 pptx 로 받습니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면 골격	도구 페이지 + 측면 메뉴 8개 모듈, 문서 · 기준정보는 목록-상세 분할 화면	모듈을 옮겨도 조회조건과 선택 문서가 이어지도록 하나의 앱 안에서 라우팅합니다.
데이터 연결	OData V2 서비스 1개. 화면은 매니페스트에 선언한 서비스에만 연결하고 조회조건은 $filter, 정렬과 페이징은 모델 기능으로 보냅니다.	운영 전환 때 서비스 주소만 바꾸면 되도록 화면 코드에 서비스 주소와 샘플 데이터를 넣지 않았습니다.
판정 로직	서비스 파일 한 곳이 상태 전이 · 채번 · 직무 분리 · 금액 계산 · 일괄 실행 · 대사 · 요인분해를 맡습니다.	화면이 달라져도 같은 판정이 나오게 하고, 직접 요청도 같은 규칙으로 막기 위해서입니다.
분석 큐브	큐브 행을 한 번 읽어 브라우저에서 행 · 열 축대로 다시 묶고, 차트는 직접 그린 SVG 입니다.	축을 바꿀 때 서버를 다시 부르지 않고, 외부 차트 라이브러리 반입 심사를 피합니다.
테마	sap_horizon 테마의 표준 컨트롤만 사용합니다.	SAP Fiori 화면과 같은 시각 언어로 현업이 낯설어하지 않게 합니다.

OData 구성은 모델 수준으로만 말씀드리면, 화면은 매니페스트에 선언한 OData V2 서비스 하나에 연결합니다. 엔티티셋 34개와 펑션 13개로 되어 있고 조회 · 단건 · 생성 · 수정 · 삭제 · 처리 펑션을 서비스 로직이 구현합니다. 승인 · 직무 분리 · 시뮬레이션 해시 확인 · 하루 한 번 제한 같은 판정은 모두 서비스 쪽에 있고, 화면은 그 결과를 보여 줍니다.

앱 정보

항목	내용
영역	영업
업무 흐름 범위	견적 → 수주 → 여신 점검·승인 → 출하 → 청구 → 수금
모듈 구성	M1 개요 · M2 기준정보 · M3 문서 처리 · M4 일괄 실행 · M5 대사 · M6 분석 · M7 영역 간 연계 · M8 이력 · 감사 · 권한
업무 영역	영업 (수주~수금), 여신, 채권
관련 기준서	IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)
SAP 표준 T-code	VA21 · VA01 · VKM1 · VL01N · VF01 · F-28 · FBL5N · VA05
Namespace	zui5.o2chub
화면 성격	통합 관리 (처리 + 분석 + 감시)
데이터 연동	OData V2 · o2chub_srv (검증용 샘플 데이터)
테마	sap_horizon

SAP 표준 기능을 그대로 이어받은 부분 — 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 문서 번호 체계와 가격 결정 · 여신 점검의 법정 · 감사 대응은 표준에 그대로 둡니다.

열자마자 오늘 할 일이 보인다

개요 · 할 일 — 미결채권 577.4백만원, 승인 대기 46건이 첫 화면에 보입니다. — **개요 · 할 일** — 미결채권 577.4백만원, 승인 대기 46건이 첫 화면에 보입니다.

타일 7개는 미결채권 합계 · 여신 보류 고객 · 승인 대기 · 반려 · 미해결 대사 예외 · 확정 문서 · 열린 할 일입니다. 타일 숫자는 위쪽 조회조건(영업조직 · 기간)을 따라 바뀝니다. 아래 "내 할 일"의 항목을 누르면 해당 문서나 예외로 바로 이동합니다.

고객 · 자재 · 가격 규칙을 한 곳에서 고친다

고객 목록 — 고객 20곳의 여신 한도와 사용액, 미결 채권이 한 표에 있습니다. — **고객 목록** — 고객 20곳의 여신 한도와 사용액, 미결 채권이 한 표에 있습니다.

고객 번호 · 이름 · 영업조직 · 지역 · 채널 · 고객 그룹 · 여신 한도 · 사용액을 보여 줍니다. 사용 중지된 고객은 흐리게 보이고 검색 상자와 상태 선택으로 좁힙니다. 행을 고르면 수정 · 사용 중지 · 변경 이력 단추가 켜집니다.

자재 목록 — 자재 10종의 제품군 · 단위 · 정가가 보입니다. — **자재 목록** — 자재 10종의 제품군 · 단위 · 정가가 보입니다.

자재마다 제품군과 정가가 있어 문서 항목의 단가가 여기서 나옵니다. 정가를 고치면 이후 만드는 문서에 반영되고 이미 전기된 문서는 그대로입니다. 변경한 사람과 시각이 오른쪽 끝에 남습니다.

가격 · 할인 규칙 — 고객 그룹과 수량 조건에 따른 할인 규칙 5개를 봅니다. — **가격 · 할인 규칙** — 고객 그룹과 수량 조건에 따른 할인 규칙 5개를 봅니다.

핵심 고객 5퍼센트 · 일반 고객 2퍼센트 · 수량 구간 추가 할인 · 제품군 프로모션이 규칙으로 들어 있습니다. 문서를 저장할 때 서비스가 이 규칙으로 할인액을 계산하므로 화면에서 할인을 손으로 넣지 않습니다.

고객 생성 — 필수값과 중복을 서버가 검사하는 생성 창입니다. — **고객 생성** — 필수값과 중복을 서버가 검사하는 생성 창입니다.

고객 번호 · 이름 · 영업조직 · 지역 · 채널 · 그룹 · 여신 한도를 입력하고 저장하면 서비스가 형식과 중복을 확인합니다. 저장 전에 창을 닫으면 변경 내용을 버릴지 묻습니다.

변경 이력 — 고객 정보를 누가 언제 어떻게 바꿨는지 한 줄씩 남습니다. — **변경 이력** — 고객 정보를 누가 언제 어떻게 바꿨는지 한 줄씩 남습니다.

생성과 수정마다 이전 값과 이후 값이 한 줄로 기록되어 여기서 바로 열립니다. 같은 내용은 이력 · 감사 화면에서도 조회됩니다.

사용 중지 확인 — 삭제 대신 사용 중지로 처리하고, 확인 창에서 한 번 더 묻습니다. — **사용 중지 확인** — 삭제 대신 사용 중지로 처리하고, 확인 창에서 한 번 더 묻습니다.

기준정보는 지우지 않고 사용 중지 플래그만 바꿉니다. 이미 문서가 있는 고객도 이력을 잃지 않기 위해서입니다. 중지된 고객은 새 문서의 고객 선택에서 빠집니다.

작성자는 승인할 수 없다 — 상태 흐름을 서버가 지킨다

문서 목록 — 견적 · 수주 · 출하 · 청구 · 수금 문서 1,302건이 상태와 함께 나열됩니다. — **문서 목록** — 견적 · 수주 · 출하 · 청구 · 수금 문서 1,302건이 상태와 함께 나열됩니다.

구분 · 상태 · 고객 · 문서일로 좁힐 수 있고 왼쪽 목록에서 문서를 고르면 오른쪽에 상세가 열립니다. 상태는 임시저장 · 검토요청 · 승인 · 확정 · 반려 · 취소 여섯 가지입니다. 조회조건은 위쪽 공통 영역과 이어집니다.

문서 생성 — 고객과 자재 · 수량만 넣으면 단가와 할인은 서버가 계산합니다. — **문서 생성** — 고객과 자재 · 수량만 넣으면 단가와 할인은 서버가 계산합니다.

견적과 수주는 항목을 직접 넣고 출하 · 청구 · 수금은 앞 문서를 참조해 잔량 전체로 만듭니다. 저장하면 문서 번호가 서버에서 채번되고 임시저장 상태가 됩니다.

문서 상세 — 임시저장 — 머리 · 항목 · 상태 이력이 한 화면에 모입니다. — **문서 상세 — 임시저장** — 머리 · 항목 · 상태 이력이 한 화면에 모입니다.

위쪽은 고객 · 금액 · 여신 결과, 가운데는 항목 표, 아래는 상태 이력입니다. 지금 상태와 내 역할에서 할 수 있는 동작만 단추로 보입니다.

검토 요청 — 검토를 요청하면 승인자의 할 일이 서버에서 만들어집니다. — **검토 요청** — 검토를 요청하면 승인자의 할 일이 서버에서 만들어집니다.

확인 창에서 메모를 남기고 요청하면 문서가 검토요청 상태로 바뀌고 승인 대기 타일의 숫자가 하나 늘어납니다. 요청한 사람은 같은 문서를 승인할 수 없습니다.

직무 분리 거절 — 작성한 사람이 승인하려 하면 서버가 거절합니다. — **직무 분리 거절** — 작성한 사람이 승인하려 하면 서버가 거절합니다.

관리자 계정이 자기가 만든 문서를 승인하면 "작성자와 승인자는 같을 수 없습니다"라는 서버 메시지가 그대로 뜹니다. 화면에서 단추를 숨기는 것에 의존하지 않고 요청 자체를 서버가 판정한다는 뜻입니다.

허용되지 않는 상태 전이 — 검토요청 상태의 문서를 바로 확정하려는 요청은 400 으로 거절됩니다. — **허용되지 않는 상태 전이** — 검토요청 상태의 문서를 바로 확정하려는 요청은 400 으로 거절됩니다.

상태 전이 규칙은 서비스의 규칙 표에 들어 있고 단추가 없어도 직접 요청한 경우를 막습니다. 메시지에 현재 상태와 막힌 동작이 함께 적힙니다.

여신 점검 — 수주 금액을 더했을 때 한도의 몇 퍼센트가 되는지 먼저 계산합니다. — **여신 점검** — 수주 금액을 더했을 때 한도의 몇 퍼센트가 되는지 먼저 계산합니다.

한도 · 현재 사용액 · 이번 금액 · 반영 후 사용액 · 사용률이 한 창에 보이고 결과는 정상 · 초과 · 보류 중 하나입니다. 초과나 보류면 승인 때 메모가 필수이고 2단계 승인으로 이어집니다.

2단계 승인 — 1억 원 이상이거나 여신 결과가 정상이 아니면 승인자 두 명이 필요합니다. — **2단계 승인** — 1억 원 이상이거나 여신 결과가 정상이 아니면 승인자 두 명이 필요합니다.

첫 승인 뒤에도 문서는 검토요청에 머물고 다른 승인자가 한 번 더 승인해야 승인 상태가 됩니다. 두 번째 승인자는 첫 승인자와 같을 수 없습니다.

전기 후 — 확정된 문서는 수정할 수 없고 상태 이력에 전이가 모두 남습니다. — **전기 후** — 확정된 문서는 수정할 수 없고 상태 이력에 전이가 모두 남습니다.

전기할 때 서버가 기간 열림 · 필수값 · 금액 합계를 확인합니다. 확정 뒤에는 수정 단추가 사라지고 취소(역처리)만 가능합니다.

역처리 — 역처리는 원 문서를 지우지 않고 반대 문서를 만들어 연결합니다. — **역처리** — 역처리는 원 문서를 지우지 않고 반대 문서를 만들어 연결합니다.

사유를 적고 역처리하면 부호가 반대인 문서가 새로 생기고 원 문서는 취소 상태가 됩니다. 두 문서는 문서 흐름으로 이어져 있습니다.

엑셀 업로드 — 엑셀 파일 4행을 먼저 검사해 통과 3건 · 확인 필요 1건으로 미리 보여 줍니다. — **엑셀 업로드** — 엑셀 파일 4행을 먼저 검사해 통과 3건 · 확인 필요 1건으로 미리 보여 줍니다.

형식이 맞지 않는 행은 이유와 함께 표시되고 통과한 행만 반영됩니다. 반영 때 서버가 다시 한 번 검사하므로 미리 보기를 통과해도 서버가 거절할 수 있고 그 결과도 행마다 적힙니다.

시뮬레이션 합계와 실행 결과가 같다

일괄 실행 — 시뮬레이션 — 출하를 일괄 만들기 전에 만들어질 문서와 제외될 문서를 먼저 봅니다. — **일괄 실행 — 시뮬레이션** — 출하를 일괄 만들기 전에 만들어질 문서와 제외될 문서를 먼저 봅니다.

영업조직 · 기간 · 실행 유형을 고르고 시뮬레이션을 누르면 저장 없이 결과가 나옵니다. 문서 수 · 금액 합계 · 제외 사유가 함께 보이고, 시뮬레이션 없이 실행 단추는 켜지지 않습니다.

실행 후 로그 — 실행하면 문서가 만들어지고 실행 이력과 로그가 남습니다. — **실행 후 로그** — 실행하면 문서가 만들어지고 실행 이력과 로그가 남습니다.

시뮬레이션에서 본 건수와 금액이 실행 결과와 같습니다. 실행 이력 표에서 실행 번호를 고르면 아래에 로그가 열리고 만들어진 문서 번호를 눌러 문서 처리 화면으로 이동합니다.

재시뮬레이션 — 중복 제외 — 같은 조건으로 다시 돌리면 이미 만든 문서는 제외됩니다. — **재시뮬레이션 — 중복 제외** — 같은 조건으로 다시 돌리면 이미 만든 문서는 제외됩니다.

잔량이 남아 있지 않은 참조 문서는 "만들 문서 0건"으로 나오고 제외 사유가 줄마다 적힙니다. 같은 문서가 두 번 생기지 않도록 서버가 막습니다.

대사 예외는 조치하면 줄어든다

대사 규칙과 결과 — 다섯 규칙을 한 번에 돌려 검사 건수와 차이 건수를 봅니다. — **대사 규칙과 결과** — 다섯 규칙을 한 번에 돌려 검사 건수와 차이 건수를 봅니다.

수주 = 출하 + 미출하, 출하 = 청구 + 미청구, 고객 미결 채권 = 청구 − 수금, 순매출 = 총액 − 할인 − 리베이트, 여신 사용액 = 미결 채권 + 미청구 수주를 확인합니다. 허용 오차 안에 들어오지 않는 건이 예외로 올라갑니다.

예외 조치 — 예외마다 조정 문서 생성 · 사유 확정 · 보류 중에서 조치를 고릅니다. — **예외 조치** — 예외마다 조정 문서 생성 · 사유 확정 · 보류 중에서 조치를 고릅니다.

조정 문서를 고르면 서버가 정정 문서를 만들고 예외가 해소 상태로 바뀝니다. 사유 확정과 보류는 사유 입력이 필수이고 조치 중 상태로 남습니다.

재대사 후 — 조치한 뒤 다시 대사하면 해당 규칙의 차이 건수가 줄어듭니다. — **재대사 후** — 조치한 뒤 다시 대사하면 해당 규칙의 차이 건수가 줄어듭니다.

재대사 결과가 규칙별로 쌓이고 예외 목록의 상태가 미해결 → 조치 중 → 해소로 옮겨 갑니다. 조치 전후의 숫자를 같은 화면에서 비교할 수 있습니다.

숫자 하나를 눌러 문서 라인까지 내려간다

피벗 — 기본 배치 — 제품군 × 월 순매출이 한 번의 조회로 펼쳐집니다. — **피벗 — 기본 배치** — 제품군 × 월 순매출이 한 번의 조회로 펼쳐집니다.

전체 합계 2,154,235,823원이 행 맨 위에 있고 제품군별로 내려갑니다. 오른쪽 차트는 같은 큐브에서 그려지고 합계 아래 검산 줄이 큐브 합계와 원천 라인 합계가 같은지 매번 보여 줍니다.

축 전환 — 차원을 끌어 행과 열을 바꿔도 서버를 다시 부르지 않습니다. — **축 전환** — 차원을 끌어 행과 열을 바꿔도 서버를 다시 부르지 않습니다.

쓰지 않는 차원 · 행 축 · 열 축 세 칸에서 칩의 메뉴나 끌어놓기로 배치를 바꿉니다. 행은 최대 3단계, 열은 최대 2단계이고 합계는 축을 바꿔도 같습니다.

계획 비교 — 비교 기준을 켜면 칸마다 실적 · 계획 · 차이가 나란히 나옵니다. — **계획 비교** — 비교 기준을 켜면 칸마다 실적 · 계획 · 차이가 나란히 나옵니다.

실적 2,154,235,823원 대비 계획 2,331,202,210원, 차이 −176,966,387원(−7.6퍼센트)입니다. 색은 순매출에 준 영향 방향으로 칠하고 금액과 비율이 둘 다 임계를 넘을 때만 강조합니다.

요인분해와 워터폴 — 총차이를 물량 · 믹스 · 단가 · 할인 · 환율 다섯 요인으로 가릅니다. — **요인분해와 워터폴** — 총차이를 물량 · 믹스 · 단가 · 할인 · 환율 다섯 요인으로 가릅니다.

물량 −124,658,834 · 믹스 −38,197,076 · 단가 −3,836,948 · 할인·리베이트 −13,681,584 · 환율 +3,408,055원이고 합이 총차이와 같다는 검산 줄이 아래에 있습니다. 감소 요인은 빨간색, 증가 요인은 초록색 막대입니다.

드릴스루 — 칸 금액 141,271,522원이 원천 라인 47개의 합계와 같다고 확인됩니다. — **드릴스루** — 칸 금액 141,271,522원이 원천 라인 47개의 합계와 같다고 확인됩니다.

제어기 제품군 · 2026-02 칸을 누르면 그 금액을 만든 문서 라인이 열리고 질의 조건과 일치 여부가 머리에 보입니다. 문서 번호를 누르면 문서 처리 화면의 해당 문서로 이동합니다.

변동 사유 — 차이가 난 행에 사유를 적으면 조회 범위와 행 경로에 묶여 남습니다. — **변동 사유** — 차이가 난 행에 사유를 적으면 조회 범위와 행 경로에 묶여 남습니다.

사유 구분과 내용을 저장하면 같은 범위를 다시 조회해도 그 행에 따라옵니다. CSV 와 AI 분석의 근거에도 함께 실립니다.

수주 하나가 다른 영역에 남긴 흐름

문서 흐름 — 수주 하나에서 시작해 생산 · 재무 · 자금으로 이어진 흐름을 따라갑니다. — **문서 흐름** — 수주 하나에서 시작해 생산 · 재무 · 자금으로 이어진 흐름을 따라갑니다.

문서 번호를 넣고 조회하면 앞 문서와 뒤 문서가 연계 영역과 함께 나옵니다. 영업 문서는 눌러서 문서 처리로 이동하고, 다른 영역의 문서는 흐름만 보여 줍니다.

숫자는 서비스가 계산하고 AI 는 읽어서 설명한다

AI 분석 · 보고서 — 요약과 핵심 발견, 모델에 넘기는 근거 표를 함께 보여 줍니다. — **AI 분석 · 보고서** — 요약과 핵심 발견, 모델에 넘기는 근거 표를 함께 보여 줍니다.

금액과 비율은 서비스가 큐브에서 계산하고 해설은 그 값을 읽어 씁니다. 근거 표를 펼쳐 값과 출처를 확인할 수 있고, 같은 창에서 PowerPoint 보고서를 만들어 내려받습니다.

에이전트 — 감시 규칙 5개와 받을 역할별 대기함, 활동 기록이 있습니다. — **에이전트** — 감시 규칙 5개와 받을 역할별 대기함, 활동 기록이 있습니다.

지금 실행을 누르면 규칙에 걸린 항목을 받을 역할의 눈으로 다시 적어 대기함에 올립니다. 하루 한 번 제한은 서버가 판정하고 두 번째 실행은 활동 기록만 남깁니다.

누가 무엇을 했는지 서버가 남긴다

역할과 상태 전이 규칙 — 데모 사용자 4명의 권한과 허용되는 상태 전이 6개를 확인합니다. — **역할과 상태 전이 규칙** — 데모 사용자 4명의 권한과 허용되는 상태 전이 6개를 확인합니다.

조회자 · 처리자 · 승인자 · 관리자가 할 수 있는 일이 서버 기준으로 적혀 있습니다. 운영에서는 이 부분을 SAP 권한 객체와 역할로 바꿉니다.

거절된 요청 이력 — 권한 없음과 직무 분리로 거절된 요청도 감사 로그에 남습니다. — **거절된 요청 이력** — 권한 없음과 직무 분리로 거절된 요청도 감사 로그에 남습니다.

결과를 "거절"로 거르면 누가 어떤 동작을 시도했다가 막혔는지가 모입니다. 성공한 쓰기와 마찬가지로 이전 값과 이후 값이 한 줄에 적힙니다.

조회자 화면 — 조회자에게는 쓰기 단추가 꺼지고 직접 요청해도 서버가 거절합니다. — **조회자 화면** — 조회자에게는 쓰기 단추가 꺼지고 직접 요청해도 서버가 거절합니다.

기준정보 화면의 생성 · 수정 단추가 비활성이고, 같은 요청을 직접 보내도 403 으로 돌아옵니다. 화면 제어와 서버 판정이 함께 막고 있다는 확인입니다.

내 배치를 저장하고 좁은 화면에서도 쓴다

레이아웃 저장 — 축 · 기간 · 측정값 · 비교 기준을 이름 붙여 저장합니다. — **레이아웃 저장** — 축 · 기간 · 측정값 · 비교 기준을 이름 붙여 저장합니다.

기본 레이아웃으로 지정하고 자동 조회를 켜 두면 화면을 열 때 조회된 채로 시작합니다. 이름은 최대 40자입니다.

레이아웃 관리 — 저장한 배치의 이름 바꾸기 · 기본 지정 · 삭제를 관리합니다. — **레이아웃 관리** — 저장한 배치의 이름 바꾸기 · 기본 지정 · 삭제를 관리합니다.

기본과 자동 조회 표시를 한눈에 보고 바꿉니다. 적용을 누르면 저장해 둔 축과 조건으로 바로 돌아갑니다.

좁은 화면 — 390px 폭에서는 조회조건이 위아래로 쌓이고 메뉴가 아이콘으로 접힙니다. — **좁은 화면** — 390px 폭에서는 조회조건이 위아래로 쌓이고 메뉴가 아이콘으로 접힙니다.

표와 차트가 위아래로 쌓이고 가로 스크롤이 생기지 않습니다. 행 · 열 조합이 상한 36을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 나옵니다.

메뉴 펼침 — 왼쪽 메뉴 단추를 누르면 이름이 있는 메뉴가 펼쳐집니다. — **메뉴 펼침** — 왼쪽 메뉴 단추를 누르면 이름이 있는 메뉴가 펼쳐집니다.

좁은 화면에서도 여덟 개 모듈로 이동할 수 있습니다. 이동해도 조회조건은 이어집니다.

화면 뒤에서 일어나는 일

업무 흐름은 견적 → 수주 → 여신 점검·승인 → 출하 → 청구 → 수금 입니다. 각 단계는 앞 문서의 잔량을 참조해 만들어지고, 서비스가 상태 · 금액 · 여신 결과를 판정해 이력을 남깁니다. 아래 표는 판정 조건이 어떤 결과 상태와 사용자 조치로 이어지는지 보여 줍니다.

판정 조건	결과 상태	사용자 조치
작성자와 승인자가 같다	거절 (403 성격 · "작성자와 승인자는 같을 수 없습니다")	다른 승인자 계정으로 전환해 승인합니다.
현재 상태에서 허용되지 않는 동작	거절 (400 · 현재 상태와 막힌 동작을 메시지에 적음)	상태 이력을 보고 가능한 단계부터 진행합니다.
사용자 역할에 권한이 없다	거절 후 감사 로그에 "거절" 기록	권한이 있는 역할로 전환하거나 관리자에게 요청합니다.
수주 금액 반영 후 사용액이 한도 이내	여신 정상	일반 승인 1단계로 진행합니다.
한도 초과 또는 보류 고객	여신 초과 · 보류 → 승인 시 메모 필수, 2단계 승인	메모를 남기고 승인자 두 명이 순서대로 승인합니다.
금액이 1억 원 이상 (샘플 기준)	2단계 승인	다른 승인자가 한 번 더 승인합니다. 두 번째 승인자는 첫 승인자와 같을 수 없습니다.
일괄 실행인데 같은 조건의 시뮬레이션이 없다	실행 거절	시뮬레이션을 먼저 돌려 건수와 금액을 확인합니다.
앞 문서의 잔량이 0	일괄 실행에서 제외 (제외 사유 표시)	제외 사유를 확인하고 필요하면 앞 문서를 점검합니다.
대사 규칙 차이가 허용 오차를 넘는다	예외로 등록 (미해결)	조정 문서 생성 · 사유 확정 · 보류 중에서 조치하고 재대사합니다.
분석 큐브 합계 ≠ 원천 라인 합계	검산 줄이 "불일치"로 표시	점검 필요 — 매핑과 원천 집계를 확인합니다.
요인 합 ≠ 총차이	요인분해 검산 줄이 "불일치"로 표시	점검 필요 — 요인 정의와 반올림 처리를 확인합니다.

단계	상태 · 처리	SAP 데이터 지점	이 앱의 모듈
1. 견적	임시저장 → 검토요청 → 승인 → 확정	견적 문서(머리 · 항목)	문서 처리
2. 수주	여신 점검 · 1~2단계 승인 → 확정	수주 문서 · 여신 한도 · 미결 채권	문서 처리 · 대사
3. 출하	수주 잔량을 참조해 일괄 실행(시뮬레이션 → 실행)	출하 문서 · 문서 흐름	일괄 실행 · 대사 R01
4. 청구	출하 잔량을 참조해 일괄 실행	청구 문서 · 총액 · 할인 · 리베이트	일괄 실행 · 대사 R02 · R04 · 분석
5. 수금	청구 잔액을 참조해 수금 전기	수금 문서 · 고객 미결 항목	문서 처리 · 대사 R03 · R05

대사식	허용 오차	의도
수주 수량 = 출하 + 미출하	0.001	수주가 출하로 이어졌는지
출하 수량 = 청구 + 미청구	0.001	출하가 청구로 이어졌는지
고객 미결 채권 = 청구 − 수금	1원	채권 잔액이 맞는지
총액 − 할인 − 리베이트 = 순매출	1원	청구 문서의 금액 등식
여신 사용액 = 미결 채권 + 미청구 수주	1원	여신 사용액 산출
큐브 합계 = 원천 문서 라인 합계	0	분석 숫자의 근거
요인 합 = 총차이	0	차이 분해의 완결성

조회조건

조회조건	필수 여부	값	기본값
영업조직	선택	전체 / 국내영업 (1000) / 수출영업 (2000)	전체
기간 (시작)	선택	연-월 (2026-01)	2026-01
기간 (종료)	선택	연-월 (2026-10)	2026-10
문서 구분 · 상태	선택 (문서 처리)	견적 · 수주 · 출하 · 청구 · 수금 / 여섯 상태	전체
고객 · 자재 검색	선택 (기준정보)	이름 · 번호 일부, 사용 상태	사용 중
실행 유형	필수 (일괄 실행)	출하 / 청구	출하
분석 축 · 측정값 · 비교 기준	선택 (분석)	차원 9개 · 측정값 6개 · 비교 기준 켬/끔	제품군 × 월 · 순매출

조회조건은 서비스의 $filter 로 전달됩니다. 영업조직과 기간은 모든 화면이 함께 쓰고, 문서 구분 · 상태 · 고객 검색은 해당 화면에서만 씁니다.

결과 컬럼

컬럼	의미	산출식
문서 번호 · 구분 · 상태	문서의 식별과 현재 단계	번호는 서버가 채번, 상태는 규칙표의 전이 결과
금액 · 할인 · 리베이트	총액에서 차감액을 뺀 순금액	총액 − 할인 − 리베이트
여신 결과 · 사용률	정상 · 초과 · 보류와 한도 대비 비율	(사용액 + 이번 금액) ÷ 한도
검사 건수 · 차이 건수	대사 규칙이 본 건수와 어긋난 건수	규칙식 양변의 차이가 허용 오차 초과
실적 · 계획 · 차이	분석 칸의 비교 값	차이 = 실적 − 계획, 비율 = 차이 ÷ 계획
요인 금액	물량 · 믹스 · 단가 · 할인 · 환율의 몫	다섯 요인의 합 = 총차이

좁은 화면에서 달라지는 것

390px 폭에서는 조회조건이 위아래로 쌓이고 왼쪽 메뉴가 아이콘으로 접힙니다. 표와 차트는 위아래로 쌓이며 가로 스크롤이 생기지 않습니다. 행과 열 조합이 상한 36을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 나옵니다.

파일 구성

앱 폴더 (루트)
├─ index.html · Component.js · manifest.json
├─ i18n/ i18n_ko.properties
├─ css/ style.css
├─ controller/ App · Overview · Master · Document · Run · Recon · Analysis · Flow · Audit · Base
├─ view/ App · Overview · Master · Document · Run · Recon · Analysis · Flow · Audit (+ fragments/)
├─ model/ ErrorHandler · auth · chart · cube · formatter · layout · pptx · xlsx
├─ odata/o2chub_srv/ metadata.xml · service.js · json/ (엔티티셋 34개 + index.json)
└─ readme.html

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 문서 번호 체계와 가격 결정 · 여신 점검의 법정 · 감사 대응은 표준에 그대로 둡니다.

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

업무	표준 T-code	표준에서의 불편	이 앱
수주 · 출하 · 청구 문서 처리	VA01 · VL01N · VF01	문서마다 화면이 다르고 흐름을 한 번에 보려면 문서 흐름 조회를 따로 엽니다.	한 앱에서 상태 · 승인 · 금액을 이어서 보고, 문서 흐름으로 이동합니다.
여신 점검	VKM1 · 여신 관리	보류 뒤 해소 단계 중심이라 승인 전에 영향을 미리 보기 어렵습니다.	수주 저장 · 승인 전에 한도 대비 사용률을 계산해 보여 줍니다.
월말 일괄 청구 · 출하	VF04 · VL10 류 목록	대상 목록 중심이고 실행 전 합계 확인은 사람이 합니다.	시뮬레이션 합계를 보고 실행하며 중복을 막습니다.
수주-수금 숫자 맞추기	FBL5N · VA05 · VF03	화면마다 조건을 다시 넣고 엑셀로 대사합니다.	대사 규칙 다섯 개를 한 번에 돌려 차이 건수로 보여 줍니다.
계획 대비 차이의 요인	없음	표준에 없습니다. 보통 엑셀로 만듭니다.	다섯 요인으로 가르고 합계를 검산합니다.
승인 이력 · 직무 분리	문서 변경 이력	변경은 남지만 거절된 시도는 남지 않습니다.	거절된 요청까지 감사 로그에 남깁니다.

T-code 별 연계 지점

T-code	이름	연계
VA21 · VA23	견적 생성 · 조회	이 앱의 견적 문서(머리 · 항목)와 같은 데이터 구조를 이어받습니다. 견적 번호로 표준 화면에서 원천을 확인합니다.
VA01 · VA03	수주 생성 · 조회	수주 문서 · 항목 · 금액을 표준 화면과 맞춰 봅니다. 이 앱의 수주 번호 → VA03 에서 같은 항목을 확인합니다.
VKM1	여신 보류 SD 문서	이 앱의 여신 점검 결과(정상 · 초과 · 보류)와 표준의 보류 문서 목록을 대조합니다. 한도 maintenance 는 표준(여신 관리)에 둡니다.
VL01N · VL03N	출하 생성 · 조회	출하 일괄 실행 결과 문서의 수량을 표준 출하 문서와 맞춥니다. 대사 규칙 R01 이 같은 숫자를 봅니다.
VF01 · VF03 · VF04	청구 생성 · 조회 · 청구 대상 목록	청구 일괄 생성 결과와 표준의 청구 대상 목록을 대조합니다. 대사 규칙 R02 · R04 가 수량과 순매출을 맞춥니다.
F-28 · FBL5N	수금 전기 · 고객 미결 항목	수금과 미결 채권을 표준 고객 개별 항목과 맞춥니다. 대사 규칙 R03 이 고객별 미결 채권을 맞춥니다.
VA05	수주 목록	분석 화면의 수주 금액 집계와 표준 수주 목록 합계를 대조합니다.

이 앱의 결과를 표준 화면으로 확인하는 순서는 같습니다. 이 앱에서 문서 번호를 확인하고 해당 표준 조회 화면(VA03 · VL03N · VF03)에서 같은 항목과 금액을 맞춰 봅니다. 반대로 표준 화면의 값은 이 앱의 문서 흐름과 대사 화면에서 다시 볼 수 있습니다. 문서 번호 체계와 가격 결정 · 여신 점검의 법정 · 감사 대응은 표준에 남겨 둡니다. 따라서 운영 전환 때 기존 표준 리포트를 없앨 필요는 없습니다.

업무 흐름 매핑표

단계	표준 T-code	이 앱의 모듈	원천 데이터
견적	VA21 · VA23	문서 처리 (견적)	견적 머리 · 항목
수주 · 여신	VA01 · VA03 · VKM1	문서 처리 · 여신 점검	수주 머리 · 항목 · 신용 한도
출하	VL01N · VL03N	일괄 실행 (출하)	출하 문서 · 문서 흐름
청구	VF01 · VF03 · VF04	일괄 실행 (청구)	청구 문서
수금 · 미결	F-28 · FBL5N	문서 처리 (수금) · 대사 R03	고객 개별 항목
수주 목록	VA05	분석 (수주 금액)	수주 집계

분석 지표 정의표

지표	산식 · 판정 기준	대응 기능	원천 데이터	비고
총매출	청구 항목의 정가 기준 금액 합	분석	청구 항목	-
할인 · 리베이트	가격 규칙 · 고객 리베이트율로 계산한 차감액 합	분석 · 대사 R04	청구 항목	-
순매출	총매출 − 할인 · 리베이트	분석	청구 항목	-
수주 · 수금	수주 금액 합 · 수금 금액 합	분석	수주 · 수금 문서	-
수주 대비 청구 격차	수주 금액 − 순매출	분석 (계산항목)	큐브	점검 필요 항목
요인분해	물량 · 믹스 · 단가 · 할인 · 환율 합 = 총차이	분석	큐브 · 계획	합이 총차이와 같아야 함
여신 사용률	(사용액 + 이번 금액) ÷ 한도	여신 점검	고객 기준정보	정상 · 초과 · 보류

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

S/4HANA 의 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정형 조회와 대량 분석에 강합니다. 이 앱은 그 위에서 대체하려는 것이 아니라 한 업무 흐름 안에서 처리와 분석을 이어 붙이는 자리에 있습니다. 구체적인 표준 Fiori 앱 이름과 사용 가능 여부는 고객사 환경에 따라 달라 확인 필요입니다.

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

항목	표준	이 앱의 방식
가격 결정 · 할인	표준 조건 레코드(VK11 류) · 가격 절차	이 앱의 할인 규칙은 단순 규칙입니다. 운영에서는 표준 가격 절차의 조건 유형과 매핑해 고객사가 정합니다.
여신 한도	표준 여신 관리	샘플은 고객 기준정보의 한도와 사용액을 씁니다. 운영에서는 표준 여신 관리의 한도 · 노출 값을 읽는 뷰로 바꿉니다.
문서 상태	표준 문서 상태 · 완료 상태	이 앱의 상태 여섯 가지는 업무 흐름용입니다. 표준 상태와 어떻게 대응시킬지 정합니다.
권한	표준 권한 객체 · 역할	데모 사용자 4명을 영업조직 단위 권한 객체와 역할로 바꿉니다.
확장 필드	확장 필드 · BAdI	고객사 고유 항목은 확장 필드로 추가하고 큐브 차원에 올릴지를 정합니다.

CDS 구성

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	zsdo2c_dimmap	차원 이름 · 코드 매핑	표준 마스터에 없는 약속을 한 곳에 두려고
차원	ZI_O2cCustomerDim	고객의 이름 · 영업조직 · 그룹	이름이 바뀌어도 큐브를 다시 만들지 않으려고
큐브(흐름)	ZI_O2cDocFlow	앞 문서 → 뒤 문서 연결	대사 규칙과 문서 흐름 화면의 근거
큐브(집계)	ZI_O2cSalesCube · ZI_O2cSalesPlan	실적과 계획 집계	축을 바꿔도 합계가 같게
쿼리	ZC_O2cSalesQuery	화면이 읽는 조회 단위	필터와 계산항목을 한 곳에서 정의
권한	ZI_O2cSalesCube(DCL)	영업조직 단위 접근 제어	집계에서 새는 숫자를 막으려고
서비스	서비스 정의 · 바인딩	화면이 부르는 OData 서비스	서비스 주소만 바꿔 운영으로 전환

① 매핑 테이블 — 영업조직 · 지역 · 채널 · 고객 그룹

분석 차원 이름과 코드는 표준 마스터에 없는 고객사 약속이 많습니다. 이 테이블이 그 약속을 한 곳에 둡니다. 비어 있으면 큐브에서 고객이 그룹 없이 빠지므로 도입에서 가장 먼저 채웁니다.

@EndUserText.label : '수주-수금 분석 차원 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zsdo2c_dimmap {
  key client     : abap.clnt not null;
  key kunnr      : kunnr not null;          " 고객
  vkorg          : vkorg;                   " 영업조직
  region_code    : abap.char(4);            " 지역 코드
  channel_code   : abap.char(4);            " 유통 채널 코드
  cust_group     : abap.char(4);            " 고객 그룹(핵심 · 일반 · 수출 등)
  credit_limit   : abap.curr(15,2);         " 샘플의 한도 — 운영에서는 여신 관리 값을 읽음(확인 필요)
  waers          : waers;
}

② 차원 뷰 — 고객

고객의 이름과 영업조직, 그룹을 한 번에 가져오는 차원 뷰입니다. 큐브는 이 뷰의 키만 들고 이름은 여기서 찾아 읽으므로 이름이 바뀌어도 큐브를 다시 만들지 않습니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '고객 차원 (수주-수금)'
@ObjectModel.representativeKey : 'Customer'
@Analytics.dataCategory : #DIMENSION
@Metadata.ignorePropagatedAnnotations : true
define view entity ZI_O2cCustomerDim
  as select from kna1 as c
    left outer join zsdo2c_dimmap as m on m.kunnr = c.kunnr
{
  @ObjectModel.text.element : ['CustomerName']
  key c.kunnr                 as Customer,
  c.name1                     as CustomerName,
  m.vkorg                     as SalesOrganization,
  m.region_code               as Region,
  m.channel_code              as Channel,
  m.cust_group                as CustomerGroup
}

③ 문서 흐름 뷰 — 앞 문서에서 뒤 문서로

수주 → 출하 → 청구 → 수금 연결의 근거입니다. 표준의 문서 흐름 테이블을 항목 단위로 읽어 대사 규칙 R01 · R02 가 같은 키로 맞춥니다. 항목 번호까지 키에 넣는 이유는 한 수주 항목이 여러 출하로 쪼개지기 때문입니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '수주-수금 문서 흐름'
define view entity ZI_O2cDocFlow
  as select from vbfa as f
{
  key f.vbelv      as PrecedingDocument,
  key f.posnv      as PrecedingItem,
  key f.vbeln      as SubsequentDocument,
  key f.posnn      as SubsequentItem,
  f.vbtyp_n        as SubsequentCategory,   // 출하 · 청구 구분
  @Semantics.quantity.unitOfMeasure : 'BaseUnit'
  f.rfmng          as ReferenceQuantity,
  f.meins          as BaseUnit,
  f.erdat          as CreationDate
}

④ 큐브 — 청구 순매출 · 수주 · 수금

이 앱의 분석은 이 큐브 위에서 돕니다. 청구 항목에서 총매출 · 할인 · 순매출을 합치고 수량을 함께 가져가야 요인분해에서 물량과 단가를 가를 수 있습니다. 통화는 문서 통화와 원화 환산 금액을 함께 둡니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수주-수금 큐브'
@Analytics.dataCategory : #CUBE
@VDM.viewType : #COMPOSITE
define view entity ZI_O2cSalesCube
  as select from vbrp as i
    inner join   vbrk as h on h.vbeln = i.vbeln
  association [0..1] to ZI_O2cCustomerDim as _Customer on _Customer.Customer = h.kunag
{
  key h.vbeln                              as BillingDocument,
  key i.posnr                              as BillingItem,
  h.fkdat                                  as BillingDate,
  concat(substring(h.fkdat,1,4),concat('-',substring(h.fkdat,5,2))) as Period,
  h.vkorg                                  as SalesOrganization,
  h.kunag                                  as Customer,
  i.matnr                                  as Material,
  h.waerk                                  as TransactionCurrency,
  @Aggregation.default : #SUM
  @Semantics.quantity.unitOfMeasure : 'BillingUnit'
  i.fkimg                                  as BillingQuantity,
  i.vrkme                                  as BillingUnit,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  i.netwr                                  as NetAmount,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  cast( i.netwr + i.kzwi1 as abap.curr(15,2) ) as GrossAmountEstimate, // 항목 조건 합계 — 확인 필요
  _Customer
}

⑤ 계획 뷰 — 같은 차원의 계획값

계획 대비 차이의 기준입니다. 큐브와 같은 차원 키로 맞춰 두어야 칸마다 실적과 계획이 한 줄에 놓입니다. 샘플의 계획은 고객 · 제품군 · 월 단위이며, 운영에서는 계획 원천(판매 계획 테이블 또는 계획 데이터 서비스)을 확정해야 합니다(확인 필요).

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수주-수금 계획'
@Analytics.dataCategory : #FACT
define view entity ZI_O2cSalesPlan
  as select from zsdo2c_plan as p
{
  key p.plan_version                       as PlanVersion,
  key p.period                             as Period,
  key p.vkorg                              as SalesOrganization,
  key p.kunnr                              as Customer,
  key p.matnr                              as Material,
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  p.net_amount                             as PlanNetAmount,
  @Semantics.quantity.unitOfMeasure : 'BaseUnit'
  p.plan_qty                               as PlanQuantity,
  p.meins                                  as BaseUnit,
  p.waers                                  as TransactionCurrency
}

⑥ 분석 쿼리

화면이 부르는 조회 단위입니다. 필터는 기간 · 영업조직 · 고객 그룹처럼 업무가 쓰는 것만 노출하고, 계산항목(평균 순단가 · 할인율 · 수금률)은 쿼리에서 정의합니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수주-수금 분석 쿼리'
@Analytics.query : true
@Consumption.filter.selectionType : #RANGE
define view entity ZC_O2cSalesQuery
  as select from ZI_O2cSalesCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter.mandatory : true
  Period,
  @AnalyticsDetails.query.axis : #ROWS
  SalesOrganization,
  @AnalyticsDetails.query.axis : #ROWS
  Customer,
  @AnalyticsDetails.query.axis : #COLUMNS
  NetAmount,
  @AnalyticsDetails.query.axis : #COLUMNS
  BillingQuantity,
  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '평균 순단가'
  division( NetAmount, BillingQuantity, 2 ) as AvgNetPrice
}

⑦ 권한 — 영업조직 단위 접근 제어

집계 단계에서 권한을 걸어야 합계 뺄셈으로 남의 영업조직 숫자가 드러나지 않습니다. 데모의 역할 4개는 운영에서 이 정의와 표준 역할로 바뀝니다.

@EndUserText.label : '수주-수금 큐브 — 영업조직 권한'
@MappingRole : true
define role ZI_O2cSalesCube {
  grant select on ZI_O2cSalesCube
    where ( SalesOrganization ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
상태 흐름 · 승인 단계 · 금액 구간	임시저장 → 검토요청 → 승인 → 확정 → 취소 순서와 2단계 승인 기준 금액(샘플 1억 원)	현업마다 승인 기준이 달라 첫 도입에서 문서가 막히거나 통과합니다.	영업관리팀 · 재무
직무 분리 · 역할	데모 사용자 4명을 영업조직별 SAP 권한 객체와 역할로 옮기고, 작성자 ≠ 승인자 판정을 표준 권한으로 구현	데모 사용자 전환이 남아 있으면 누구나 권한을 바꿀 수 있습니다.	보안 · 권한
처리 펑션 연결	검토 요청 · 승인 · 전기 · 역처리를 표준 BAPI 또는 RAP 액션과 연결(확인 필요: 문서 유형별 대응)	화면 상태와 표준 문서 상태가 따로 놀아 대사에서 계속 차이가 납니다.	IT · 영업관리팀
문서 번호 범위	견적 · 수주 · 출하 · 청구 · 수금 번호 범위와 연도 구분	번호가 겹치면 문서 흐름 키가 깨집니다.	IT
영역 간 연계 키	문서 흐름의 앞 문서 → 뒤 문서 키 정의(생산 · 재무 · 자금)	연계 화면이 일부 영역만 이어져 흐름을 추적하지 못합니다.	IT · 각 영역
대사 규칙 · 허용 오차	규칙 5개의 허용 오차(수량 0.001, 금액 1원)와 예외 조치 권한	허용 오차가 너무 좁으면 예외가 넘치고 넓으면 놓칩니다.	재무 · 영업관리팀
환율 유형 · 환산 시점	외화 문서를 원화로 환산하는 환율 유형과 시점, 계획 환율	요인분해의 환율 요인이 설명되지 않습니다.	재무
원천 확정	큐브 원천(청구 · 수주 · 수금)과 계획 버전	“예산이 왜 이 숫자냐”가 반복됩니다.	기획팀
권한 설계	영업조직 · 고객 그룹 단위 접근 제어를 집계 단계에 적용	드릴스루에만 권한을 걸면 합계 뺄셈으로 남의 숫자가 보입니다.	보안 · 권한
성능 기준	큐브 행 수 상한 · 필수 파라미터 · 응답 시간 목표	문서가 수천만 건이면 첫 조회가 길어집니다.	IT · Basis
대사 체계	표준 화면(VA05 · FBL5N · VF03)과 맞출 항목과 주기	표준과 이 앱의 숫자가 다를 때 어느 쪽이 맞는지 정해져 있지 않습니다.	재무
전송 순서	DDIC → CDS → 서비스 정의 → 권한 → 서비스 활성화(서비스 게시 후 화면의 서비스 주소 교체)	순서가 틀리면 활성화에서 막힙니다.	Basis
배치 등록	에이전트 실행을 화면 타이머가 아닌 배치(SM36 또는 스케줄러)로 연결	아무도 화면을 열지 않으면 감시가 돌지 않습니다.	Basis

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

대사식	검사 건수	차이 건수
수주 수량 = 출하 + 미출하	567	3
출하 수량 = 청구 + 미청구	547	3
고객 미결 채권 = 청구 − 수금	20	2
총액 − 할인 − 리베이트 = 순매출	239	2
여신 사용액 = 미결 채권 + 미청구 수주	20	2
큐브 합계 = 원천 문서 라인 합계 (측정값 6개)	6	0
요인분해 합 = 총차이	1	0

대사 차이 12건(규칙당 2~3건)은 대사 규칙이 실제로 걸러 내는지 보이려고 의도적으로 넣은 예외입니다. 일반 정합성 차이는 0건입니다. 위 숫자는 도입 포인트의 사례와 같은 검증용 샘플 데이터입니다.

운영 데이터로 갈 때

문서 흐름과 청구 항목이 수천만 건이 되면 집계는 화면이 아니라 큐브 뷰와 분석 쿼리에서 합니다. 기간 · 영업조직을 필수 파라미터로 두어 무제한 조회를 막고, 문서 흐름과 청구 항목의 조인 키에 인덱스를 점검하며, 화면이 한 번에 읽는 큐브 행 수에 상한을 둡니다. 응답 시간 기준은 고객사와 정해야 하며 확인 필요입니다. 샘플 데이터로 잰 속도를 운영 규모의 성능으로 읽으면 안 됩니다.

자주 묻는 질문

도입을 검토하시는 분들이 자주 물으시는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

큐브 합계와 문서 라인 합계가 같은지 어떻게 아나요?

분석 화면의 검산 줄이 매번 보여 줍니다. 총매출 · 할인 · 순매출 · 수주 · 수금 · 수량 여섯 개 측정값을 큐브 합계와 원천 문서 라인 합계로 비교해 같으면 일치로 표시합니다. 검증용 샘플 데이터에서는 여섯 개 모두 차이가 0입니다. 셀을 눌러 드릴스루를 열어도 칸 금액과 라인 합계를 같은 방식으로 비교합니다.

순매출과 총매출, 할인·리베이트는 어떻게 다른가요?

총매출은 청구 항목의 정가 기준 금액이고, 할인·리베이트는 가격 규칙으로 계산한 차감액이며, 순매출은 총매출에서 할인·리베이트를 뺀 값입니다. 대사 규칙 R04 가 청구 문서마다 이 등식을 1원 허용 오차로 검사합니다.

“수주 대비 청구 격차”는 무엇을 보나요?

계산항목 하나로 수주 금액에서 순매출을 뺀 값입니다. 수주했지만 아직 청구되지 않은 규모를 고객이나 제품군별로 보는 용도입니다. 격차가 크다고 문제가 있다는 뜻은 아니며, 출하 일정과 함께 점검이 필요한 항목입니다.

요인분해의 다섯 요인은 어떻게 정의되나요?

물량은 수량 변화가 계획 평균 단가에 미친 영향, 믹스는 제품 구성이 바뀐 영향, 단가는 판매 단가 변화, 할인·리베이트는 차감액 변화, 환율은 계획 환율 대비 환산 차이입니다. 요인은 서비스가 계산하고 각 요인을 반올림한 뒤 합이 총차이와 같도록 마지막 요인에서 단위 미만 차이를 맞춥니다. 화면의 검산 줄이 그 등식을 보여 줍니다. 원인은 확인 필요입니다.

외화 문서와 환율은 어떻게 처리하나요?

샘플 데이터는 문서 통화별 금액을 원화로 환산해 두고 환율 요인에 가정 환율을 씁니다. 운영에서는 환율 유형과 환산 시점(문서일 · 청구일 · 기말)을 먼저 정해야 합니다. 이 항목은 운영 시점에 할 일 표에 포함되어 있습니다.

대사 규칙의 허용 오차는 어떻게 정했나요?

수량 규칙은 0.001, 금액 규칙은 1원이 기본이고 고객 미결 채권 · 여신 규칙은 금액 단위가 커서 허용 오차 안에 들어오지 않는 건을 예외로 올립니다. 허용 오차는 규칙 정의에 들어 있어 운영에서 재무가 조정합니다.

화면과 조작

처음 쓸 때 어떤 순서로 쓰면 되나요?

위쪽 조회조건(영업조직 · 기간)을 정하고 조회를 누릅니다. 개요에서 할 일을 확인하고 문서 처리에서 문서를 만들어 검토 요청 · 승인 · 확정까지 진행합니다. 월말에는 일괄 실행과 대사를, 분석 화면에서는 피벗과 요인분해를 봅니다. 조회 버튼은 조건 영역 오른쪽 끝에 있고 Enter 키로도 조회됩니다.

승인 단추가 보이지 않는 이유는 무엇인가요?

문서 상태가 검토요청이 아니거나 내 역할에 승인 권한이 없기 때문입니다. 처리자 역할은 승인할 수 없고 승인자나 관리자 역할만 승인할 수 있습니다. 단추를 숨기는 것과 별개로 서버가 같은 규칙으로 직접 요청도 거절합니다.

왜 작성한 문서를 제가 승인할 수 없나요?

직무 분리 규칙입니다. 작성자와 승인자가 같으면 서버가 거절하고, 그 시도도 감사 로그에 거절로 남습니다. 2단계 승인이 필요한 문서는 두 번째 승인자가 첫 승인자와도 달라야 합니다.

일괄 실행에서 시뮬레이션을 꼭 먼저 해야 하나요?

예. 같은 조건의 시뮬레이션 결과가 있어야 실행 단추가 켜지고, 서버도 시뮬레이션 해시 없이는 실행을 거절합니다. 실행 결과의 문서 수와 금액은 시뮬레이션과 같고, 잔량이 없는 참조 문서는 제외되어 중복 문서가 생기지 않습니다.

엑셀 업로드는 어떤 형식인가요?

구분 · 고객 · 참조문서 · 자재 · 수량 · 문서일 · 비고 열을 쓰며 양식은 화면에서 내려받습니다. 업로드하면 먼저 브라우저에서 형식을 검사해 통과 · 확인 필요 건수를 미리 보여 주고, 반영할 때 서버가 다시 검사합니다. 서버가 거절한 행은 사유가 행마다 적힙니다.

휴대폰이나 좁은 화면에서도 쓸 수 있나요?

좁은 화면에서는 조회조건이 위아래로 쌓이고 메뉴가 아이콘으로 접히며 표와 차트가 위아래로 놓입니다. 390px 폭에서 가로 스크롤이 생기지 않는 것을 확인했습니다. 다만 피벗의 열 조합이 많으면 범위를 좁히라는 안내가 나옵니다.

분석 기능

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

아니요. 조회 때 큐브를 한 번 읽어 브라우저가 행 · 열 축대로 다시 묶습니다. 축을 바꾼 뒤 요청 수는 늘지 않고 합계도 같습니다. 조건(기간 · 영업조직)을 바꿔 조회할 때만 서버를 부릅니다.

드릴스루 합계가 칸 금액과 다르면 어떻게 되나요?

드릴스루 창 머리에 불일치로 표시되고 확인 필요 문구가 나옵니다. 검증용 샘플 데이터에서는 시험한 칸이 모두 일치했습니다. 불일치가 나오면 큐브와 원천 라인의 기준이 어긋난 것이므로 큐브 집계 조건을 점검합니다.

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

서버의 사유 엔티티에 조회 범위 + 행 경로를 키로 저장합니다. 같은 범위를 다시 조회하면 그 행에 따라오고 CSV 와 AI 분석 근거에도 실립니다. 다른 범위에서는 다른 사유로 다룹니다.

AI 는 숫자를 만들어 내나요?

아니요. 금액과 비율은 서비스가 큐브에서 계산하고 AI 는 그 값을 읽어 문장으로 설명합니다. 모델에 넘기는 근거 표를 화면에서 펼쳐 볼 수 있고, 모델 연결은 서비스 설정에서만 켜며 기본은 꺼져 있어 규칙 기반 해설이 나옵니다. API 키는 앱에 두지 않습니다.

에이전트는 어떻게 돌고 하루 한 번만 도는 이유는 무엇인가요?

감시 규칙 5개(제품군 계획 미달 · 여신 한도 초과 · 장기 미청구 출하 · 할인율 상승 · 승인 대기 장기)를 평가해 걸린 항목을 받을 역할의 대기함에 올립니다. 같은 보고가 반복되지 않도록 하루 한 번 제한을 서버가 판정하고, 걸린 것이 없거나 제한에 걸려도 활동 기록은 남깁니다.

도입과 운영

기존 표준 화면은 없애야 하나요?

아니요. 표준 실행은 SAP 표준 T-code 가 담당하고 이 앱은 조회와 점검 관점을 더해 확장합니다. 법정 · 감사 대응은 표준에 그대로 두고, 이 앱의 숫자는 표준 화면과 대사 규칙으로 맞춰 봅니다.

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

데모 사용자 4명은 시연용이며 운영에서는 영업조직 단위 SAP 권한 객체와 역할로 바꿉니다. 권한은 집계 단계에 걸어야 합계 뺄셈으로 숫자가 새지 않습니다. 모든 쓰기와 거절은 감사 로그에 남습니다.

문서가 수천만 건이면 성능은 어떤가요?

샘플은 문서 라인 1,495행에서 큐브 1,758행으로 묶는 규모입니다. 운영 규모에서는 집계를 데이터베이스(큐브 뷰)에서 하고 기간 · 영업조직을 필수 조건으로 두며 열 조합 상한 36과 표시 행 상한을 유지합니다. 응답 시간 목표와 인덱스는 운영 시점에 정합니다.

운영 데이터에 연결하려면 무엇이 필요하고 얼마나 걸리나요?

기준 · 차원 · 큐브 · 쿼리 · 권한 뷰를 만들고 서비스를 게시한 뒤 화면의 서비스 주소를 바꿉니다. 코드 작업보다 매핑 · 승인 기준 · 권한 같은 합의가 많습니다. 소요 기간은 고객사 범위에 따라 달라 확인 필요입니다.

고객 그룹이나 지역 매핑이 바뀌면 어떻게 하나요?

매핑 테이블의 행만 고치면 되고 큐브와 화면은 그대로입니다. 매핑을 고쳐도 이미 확정된 문서의 금액은 바뀌지 않고 집계 묶음만 바뀝니다.

이 앱의 결과를 최종 판단으로 써도 되나요?

이 앱은 업무 처리와 점검을 돕는 도구입니다. 수익 인식을 포함한 회계 판단은 회사와 감사인이 하고, 세무 신고는 회사와 세무 대리인이 합니다. 화면의 차이와 예외는 점검 필요 표시이며 원인은 담당자가 확인해야 합니다.

적용 시기나 범위는 정해져 있나요?

이 앱은 법으로 시기가 정해진 제도가 아니라 업무 도구입니다. 관련 기준서(IFRS 15)의 시행일과 문단은 원문으로 확인한 경우에만 적는 원칙이라 이 글에서는 다루지 않았고 확인 필요입니다. 도입 범위는 영업조직과 문서 유형 단위로 정할 수 있습니다.

샘플 데이터는 실제 고객 데이터인가요?

아닙니다. 고객 20곳 · 자재 10종 · 문서 1,302건 모두 가상으로 만든 검증용 샘플 데이터이며 일부 숫자는 대사 예외를 확인하려고 일부러 어긋나게 넣었습니다. 실제 고객사의 거래처나 금액은 쓰지 않았습니다.