가격 워터폴 점검 — 정가에서 포켓 매출까지, 가격이 새는 단계와 고객군을 찾는 수익성 분석
단계별 누수율과 정책 한도 비교 · 거래 한 건의 가격 워터폴 · 고객군·월·단계 점검 표 · 정합성 대사 9종 — 소개 영상과 실제 화면 7종, 그리고 CDS 코드까지
소개 영상블로그 목차 순서대로 · 자막 포함8개 장면음성 안내·자막조회 → 거래 명세 → 가격 단계 → 월별 추이 → 상세 → 대사 → 정리
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
수익성 회의에서 정가 대비 손에 남는 포켓 매출이 줄어드는 문제에 직면하고 계십니까? 이 앱은 정가에서 시작하여 리베이트, 현금할인 등 모든 차감을 반영한 포켓 매출을 자동 계산하고, 가격 누수율을 정책 한도와 비교하여 점검이 필요한 거래와 고객군을 한눈에 파악하도록 돕습니다.
핵심 포인트 일곱 가지
| 핵심 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 정가-포켓 매출 자동 계산 | 정가에서 거래 할인, 리베이트, 현금할인, 크레딧노트까지 모든 차감을 순차적으로 반영하여 최종 포켓 매출을 산출합니다. 누수액, 누수율, 포켓 마진율을 자동으로 계산합니다. | 판매 오더, 청구, 수익성 보고서, 별도 엑셀 작업을 통해 단계별 금액을 수작업으로 합쳐야 합니다. |
| ② 정책 한도 기반 누수 점검 | 고객군별 허용 누수율, 승인 할인율, 목표 마진율 등 정책 기준과 앱이 계산한 누수율, 할인율, 마진율을 비교하여 점검이 필요한 대상을 식별합니다. | 할인율이 승인 한도 안이더라도, 리베이트와 크레딧노트가 겹치면 누수율이 정책을 넘는 상황을 놓칠 수 있습니다. |
| ③ 고객군·월·단계별 수익성 분석 | 전체 평균에 숨겨진 고객군별, 월별, 가격 단계별 누수율 차이를 명확하게 보여주어, 가격 누수가 큰 영역을 파악하고 효율적인 개선 방향을 탐색합니다. | 전체 평균만 보거나, 거래 한 건을 따라가는 방식으로는 특정 고객군이나 월의 누수를 종합적으로 보기 어렵습니다. |
| ④ 9가지 정합성 대사 자동 검증 | 거래·고객군·월·단계 사이의 합계가 서로 맞는지를 9가지 정합성 식(예: 정가 − 거래할인 = 청구액 등)으로 전수 검사하며, 그 결과를 대사 탭에서 즉시 확인하여 숫자의 신뢰도를 확보합니다. | 단계별 금액을 합치는 과정에서 수작업 실수가 발생할 가능성이 크며, 합계가 맞는지 일일이 확인해야 합니다. |
| ⑤ SAP 표준 데이터 연동 및 확장 | SAP 표준 판매 오더(VA03), 청구 문서(VF03), 수익성 보고서(KE30)의 데이터 구조를 활용하여 정합성을 유지하고, 그 위에 누수 계산과 점검 관점을 추가하여 SAP 표준 기능을 보완 확장합니다. | 각 T-code 화면을 일일이 열어 조건을 확인하고, 수익성 보고서를 본 후 정산 내역은 별도 엑셀로 이어 붙여야 합니다. |
| ⑥ 점검 필요 거래 및 영역 안내 | 정책 한도를 넘어서는 거래, 고객군, 월, 가격 단계에 '점검 필요'를 명확히 표시하여, 어디부터 분석을 시작해야 할지 직관적으로 알려줍니다. 원인을 단정하지 않고 확인 대상을 제시합니다. | 복잡한 데이터 속에서 어떤 거래나 고객군이 문제가 되는지 파악하기 위해 데이터를 일일이 분석해야 합니다. |
| ⑦ 상세 워터폴 및 연관 거래 조회 | '점검 필요' 거래를 클릭하면 정가에서 포켓 마진까지의 워터폴을 상세하게 보여주어 어느 단계의 차감이 큰지 한눈에 파악하고, 같은 월·고객군 거래를 동시에 비교하여 맥락을 이해합니다. | 특정 문제 거래를 발견해도 그 상세 내역과 연관 거래를 한 화면에서 보기가 어렵습니다. |
사례로 보는 효과
검증용 샘플 데이터 분석 결과, 전체 누수율이 15.41%로 무난해 보여도 고객군별로는 10.84%에서 20.88%까지 차이를 보였습니다. 이 앱은 9가지 정합성 식을 690건 전수 검사하여 모든 계산값이 정확함을 확인합니다.
도입하면 달라지는 것
- 수작업 엑셀 데이터 취합 및 검증 부담 감소
- 가격 누수 발생 원인과 책임 소재 명확화
- 수익성 개선을 위한 실질적인 액션 플랜 수립
- 관리회계 데이터의 신뢰도와 활용도 증대
이런 회사에 맞습니다
정가 대비 포켓 매출 하락으로 고민하는 기업, 복잡한 차감 구조로 가격 누수 파악이 어려운 재무/관리회계/영업 팀, SAP 표준 확장을 통한 심층 수익성 점검을 원하는 CFO에게 적합합니다.
숫자를 믿을 수 있는가 — 검증 결과
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
앱 정보
| 항목 | 내용 |
|---|---|
| 업무 영역 | 관리회계(CO) — 수익성 분석 |
| 관련 기준서·대상 영역 | 대상 영역 수익성 분석(가격 워터폴·누수) |
| 표준 T-code | KE30 · KE24 · VA03 · VF03 |
| 화면 성격 | 조회·점검 화면 |
| 데이터 연동 | OData V2 |
| 테마 | sap_horizon |
실행 화면
실제 브라우저에서 찍은 화면 7종입니다. 숫자는 검증용 샘플 데이터이며 실제 회사 값이 아닙니다.
처음 열었을 때 — 어디부터 볼지 좁히기
조회조건을 정하고 조회하면 요약과 고객군별 점검 표가 나옵니다.
맨 위 조회조건에서 회계연도(필수)와 월 범위, 고객군, 제품군, 점검 결과를 고르고 오른쪽 끝의 조회 버튼을 누릅니다. 요약 카드는 정가 매출 1,811.2백만 원, 포켓 매출 1,532.1백만 원, 누수율 15.41% 처럼 금액 가중으로 계산한 값입니다. 아래 표에서 "점검 필요" 배지가 붙은 행부터 보면 됩니다. 기본값은 회계연도 2026, 나머지는 전체입니다.
점검 결과를 "점검 필요"로 고르면 기준을 넘은 행만 남아 어느 고객군·월부터 열어 볼지 바로 좁혀집니다. 전체로 되돌리면 그 조건은 서비스에 보내지 않습니다. 건수는 각 탭 이름 옆 숫자로 확인합니다.
거래 한 건에서 — 정가에서 포켓 마진까지
숫자를 의심할 때는 거래 단위로 내려가 단계마다 얼마가 빠졌는지 봅니다.
거래 한 건이 한 줄입니다. 거래 할인율이 승인 할인율을 넘거나 누수율이 정책 허용 범위를 넘으면 점검 필요로 표시하고, 판정 내용은 같은 줄의 설명에 적힙니다. 열 머리를 눌러 정렬하고, 고객군과 제품군 조건으로 범위를 줄입니다.
거래 행을 누르면 정가에서 거래 할인, 리베이트, 현금할인, 크레딧노트를 차례로 뺀 워터폴이 열립니다. 어느 단계의 차감이 큰지가 한눈에 보입니다. 아래에는 같은 월, 같은 고객군의 거래가 함께 나와 비슷한 거래와 견줄 수 있습니다.
단계와 월로 — 새는 길과 시기 찾기
같은 데이터를 단계와 월 축으로 다시 모아 어디서, 언제 새는지 봅니다.
막대는 정가를 100%로 두었을 때 각 단계 금액의 비율입니다. 단계 한도는 거래 할인 9.0%, 리베이트 4.5%, 현금할인 1.2%, 크레딧노트 1.2%이며 이를 넘는 달에는 점검 필요가 붙습니다. 전체 기간 평균 비율은 거래 할인 9.44%, 리베이트 4.02%, 현금할인 1.10%, 크레딧노트 0.85%입니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
숫자 맞춰 보기 — 대사 결과
점검 결과를 믿어도 되는지, 계산 자체가 맞는지 확인하는 자리입니다.
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
화면 뒤에서 일어나는 일 — 판정 규칙
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
산출 순서
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
조회조건
| 조회조건 | 서비스에 보내는 조건 | 필수·기본값 | 적용 탭 |
|---|---|---|---|
| 회계연도 | Gjahr eq '2026' | 필수 · 기본 2026 | 모든 탭 |
| 전기 월 시작·종료 | Period ge … and Period le … | 선택 · 둘 다 있으면 범위 한 쌍 | 모든 탭 |
| 고객군 | CustGrp eq 'C1' | 선택 · 전체면 조건 생략 | 고객군별 점검 · 거래 명세 |
| 제품군 | ProdGrp eq 'P2' | 선택 · 전체면 조건 생략 | 거래 명세 |
| 점검 결과 | CheckStatus eq 'CHECK' | 선택 · 전체면 조건 생략 | 고객군별 점검 · 거래 명세 · 가격 단계 · 월별 추이 |
결과 컬럼
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
SAP 표준 기능 확장 포인트
표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 두고, 단계별 누수를 한 화면에서 이어 보는 자리만 더합니다.
표준으로 되는 것과 이 화면이 더하는 것
| 하고 싶은 일 | SAP 표준 | 이 화면이 더하는 관점 |
|---|---|---|
| 거래의 정가·조건 확인 | 판매 오더 표시(VA03) | 그 거래가 포켓 매출까지 얼마나 새는지를 같은 줄에서 계산 |
| 청구액·크레딧노트 확인 | 청구 문서 표시(VF03) | 청구액 이후 차감(리베이트·현금할인·크레딧노트)을 이어 붙여 포켓 매출 산출 |
| 고객·제품별 수익성 보고 | 수익성 보고서 실행(KE30) | 정책 허용 누수율·목표 마진율과 견준 점검 표시 |
| 개별 항목 확인 | 수익성 분석 개별 항목 표시(KE24) | 점검 필요 거래에서 확인할 근거 문서로 오가는 동선 |
| 법정·감사 대응 | 표준 거래 그대로 | 이 화면은 내부 관리 점검용이며 법정·감사 자료를 만들지 않음 |
T-code 별 연계 지점
| T-code | 이름 | 연계 |
|---|---|---|
| KE30 | 수익성 보고서 실행 | 고객·제품 단위 매출과 공헌이익을 이 화면의 고객군·제품군 집계와 나란히 대조합니다. 두 화면의 정가 매출이 맞는지가 첫 대사 지점이며, 화면에서 의심 가는 고객군을 KE30 에서 같은 조건으로 다시 봅니다. 법정·감사 대응은 표준에 남깁니다. |
| KE24 | 수익성 분석 개별 항목 표시 | 수익성 분석에 전기된 개별 항목에서 거래 할인·리베이트 금액을 확인합니다. 화면의 거래 단위 금액을 개별 항목과 맞춰 봅니다. |
| VA03 | 판매오더 표시 | 점검 필요 거래의 정가 조건과 승인 할인 조건을 확인합니다. 승인 할인율을 넘은 거래(P2)의 근거 확인에 씁니다. |
| VF03 | 청구 문서 표시 | 청구액과 크레딧노트 처리 내역을 확인합니다. 포켓 매출의 출발점인 청구액을 맞춰 보는 자리입니다. |
운영에 옮길 때 기존 보고서를 없앨 필요는 없습니다. 표준 보고서는 그대로 두고, 이 화면은 월마다 누수가 큰 곳을 먼저 가려내는 용도로 병행하면 됩니다.
S/4HANA 분석 스택과의 자리
S/4HANA 의 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 같은 원천 위에서 집계를 보는 도구입니다. 이 화면은 그 가운데 "정책 기준과 견주는 점검"을 한 화면에 모은 것으로, 아래 CDS 구성에서 보듯 큐브와 분석 쿼리를 SAP 표준 방식으로 만들고 화면은 서비스로 읽습니다. 표준 분석 앱을 쓰는 회사라면 같은 큐브를 두 화면이 함께 쓸 수 있습니다.
확장 포인트 — 운영에서 실제로 손대는 자리
| 자리 | 무엇을 손대나 | 비고 |
|---|---|---|
| 정책 기준값 | 고객군별 허용 누수율·승인 할인율·목표 마진율 | 회사의 가격 정책 문서가 기준이며 유효 시작일로 이력을 둡니다. |
| 고객군·제품군 매핑 | 고객 마스터의 고객 그룹과 자재 그룹을 화면의 차원으로 연결 | 매핑이 바뀌면 집계 단위가 바뀌므로 변경 절차가 필요합니다. |
| 리베이트 정산 원천 | 조건 계약 정산액을 거래 단위로 배분하는 기준 | 원천 확인 필요 — 회사마다 정산 방식이 다릅니다. |
| 확장 필드 | 정책 예외 사유, 승인 번호 같은 회사 고유 필드 | 커스텀 필드를 큐브에 노출해 화면에 한 열로 더합니다. |
| 권한 | 회사코드·영업조직 단위 접근 제한 | 집계 단계에 권한을 걸어야 합계로 새지 않습니다. |
분석 지표 정의
이 화면은 특정 기준서 요구사항을 점검하는 것이 아니라 수익성 분석 영역의 내부 관리 점검 도구이므로, 요구사항 매핑표 대신 분석 지표의 정의를 적습니다.
| 지표 | 정의 | 산출식 | 원천 데이터 | 비고 |
|---|---|---|---|---|
| 포켓 매출 | 차감을 모두 반영한 뒤 손에 남는 매출 | 청구액 − 리베이트 − 현금할인 − 크레딧노트 | 청구 문서 · 조건 정산 · 대금 정산 | 정산 원천 확인 필요 |
| 누수율 | 정가 중 차감으로 사라진 비율 | (정가 − 포켓 매출) ÷ 정가 × 100 | 가격 조건 · 청구 문서 | 정책 허용 누수율과 견줌 |
| 거래 할인율 | 정가 대비 청구서 표시 할인 비율 | 거래 할인 ÷ 정가 × 100 | 가격 조건 | 승인 할인율과 견줌 |
| 포켓 마진 | 포켓 매출에서 표준원가를 뺀 값 | 포켓 매출 − 표준원가 | 자재 표준원가 | 음수면 P3 |
| 포켓 마진율 | 포켓 매출 대비 포켓 마진 | 포켓 마진 ÷ 포켓 매출 × 100 | - | 목표 마진율과 견줌 |
| 단계 비율 | 정가 대비 단계별 금액 비율 | 단계 금액 ÷ 정가 × 100 | - | 단계 한도와 견줌 |
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
도입 검토 중에 자주 나오는 질문을 숫자와 산식, 화면과 조작, 판정과 해석, 도입과 운영 네 묶음으로 정리했습니다.
숫자와 산식
이 화면은 무엇을 점검하나요?
정가에서 포켓 매출까지 가격이 어느 단계에서 얼마나 새는지를 거래·고객군·월·단계 단위로 다시 계산해, 정책 허용 누수율과 승인 할인율, 목표 마진율에 견주어 보는 화면입니다. 기준을 넘는 항목을 점검 필요로 표시할 뿐 원인을 단정하지는 않습니다.
포켓 매출은 어떻게 계산하나요?
정가 매출에서 거래 할인을 빼 청구액을 구하고, 청구액에서 리베이트, 현금할인, 크레딧노트를 차례로 뺀 값입니다. 거래마다 같은 식을 쓰고, 고객군·월 합계도 거래 합계에서 다시 구합니다.
누수율과 거래 할인율은 어떻게 다른가요?
거래 할인율은 청구서에 찍힌 할인만 정가로 나눈 값이고, 누수율은 리베이트·현금할인·크레딧노트까지 포함해 정가 중 사라진 비율입니다. 할인율이 한도 안이어도 누수율이 정책을 넘을 수 있어 둘을 따로 판정합니다.
요약 카드의 누수율은 평균인가요?
아닙니다. 누수액 합계를 정가 합계로 나눈 금액 가중 값입니다. 거래별 비율을 평균내면 작은 거래가 과하게 반영되므로 합계 ÷ 합계로 계산합니다.
정책 허용 누수율에 3%p 를 더하는 이유는 무엇인가요?
정책 값 바로 위에서 점검 표시가 쏟아지면 현업이 표시를 무시하게 됩니다. 이 샘플에서는 정책 허용 누수율에 3%p 여유를 더한 값을 넘을 때만 점검 필요로 표시합니다. 여유 폭은 회사가 정할 값입니다.
숫자가 맞는지 어떻게 확인하나요?
거래·고객군·월·단계 사이의 합계가 서로 맞는지를 정합성 식 9가지로 전수 검사하고 대사 탭에서 보여 줍니다. 검증용 샘플 데이터에서는 검사 690건 모두 차이가 0건이었습니다.
화면과 조작
조회 버튼은 어디에 있나요?
조회조건 영역 안, 입력 칸들의 가장 오른쪽에 있습니다. 회계연도 입력 칸에서 Enter 키를 눌러도 조회되고, 화면을 처음 열면 한 번 자동으로 조회합니다.
전체를 고르면 무엇을 서비스에 보내나요?
아무것도 보내지 않습니다. 고객군이나 제품군을 전체로 두면 그 조건은 서비스에 보내는 필터에서 빠집니다.
행을 누르면 무엇이 열리나요?
정가에서 거래 할인, 리베이트, 현금할인, 크레딧노트를 차례로 뺀 워터폴과 판정 내용, 같은 월·고객군의 거래 명세가 한 창에 열립니다. 어느 단계의 차감이 큰지를 이어서 확인할 수 있습니다.
점검 필요로 표시된 거래만 따로 볼 수 있나요?
조회조건의 점검 결과를 점검 필요로 고르면 해당 행만 남습니다. 건수는 탭 이름 옆 숫자로 확인합니다.
결과를 엑셀로 가져갈 수 있나요?
각 탭의 CSV 내려받기로 현재 조회 결과를 UTF-8 CSV 로 받을 수 있습니다. 조회조건이 반영된 결과가 내려옵니다.
판정과 해석
점검 필요로 표시된 거래는 잘못된 거래인가요?
아닙니다. 정책 기준을 넘었으니 확인해 보라는 표시입니다. 계약상 정당한 예외일 수도 있으므로 최종 판단은 점검 도구가 아니라 회사가 합니다.
월 점검은 어떤 기준으로 표시하나요?
한 달에 점검 필요 거래가 8건 이상이면 그 달을 점검 필요로 표시합니다. 이 기준은 샘플 데이터 규모에 맞춘 값이어서 운영 건수에 맞게 다시 정해야 합니다.
가격 단계 한도는 무엇인가요?
정가 대비 단계별 금액의 허용 비율로, 이 샘플에서는 거래 할인 9.0%, 리베이트 4.5%, 현금할인 1.2%, 크레딧노트 1.2%입니다. 한도를 넘는 단계와 월에 점검 필요가 붙고, 실제 한도는 회사 정책으로 정합니다.
포켓 마진이 음수인 거래는 어떻게 보나요?
포켓 매출이 표준원가에 못 미친다는 뜻이며 P3 로 표시합니다. 단가나 표준원가가 갱신되지 않았는지, 어느 차감 단계가 컸는지를 상세 창에서 확인합니다.
이 화면이 원인까지 알려 주나요?
원인은 알려 주지 않습니다. 어느 거래, 어느 단계, 어느 달이 기준을 넘었는지까지 좁혀 주고, 원인 판단은 승인 내역과 계약 조건을 보고 사람이 합니다.
도입과 운영
적용 시기나 대상 범위에 정해진 것이 있나요?
이 화면은 특정 기준서 요구사항을 점검하는 것이 아니라 수익성 분석 영역의 내부 관리 점검 도구이므로 정해진 적용 시기는 없습니다. 도입 범위와 정책 기준값은 회사가 정합니다.
표준 T-code 를 대신하나요?
대신하지 않습니다. 거래 확인은 VA03 · VF03, 수익성 보고는 KE30 · KE24 가 계속 담당하고, 이 화면은 단계별 누수를 정책과 견주어 한 화면에서 이어 보는 관점을 더합니다.
운영 데이터로 연결하려면 무엇이 필요한가요?
정책 기준 테이블, 조건 요소와 리베이트 정산의 원천 확인, 고객군·제품군 매핑, 권한 설계, 서비스 게시가 필요합니다. 앱 설정에 선언한 서비스 주소만 운영 서비스로 바꾸면 화면 코드는 그대로 쓸 수 있습니다. 소요 기간은 조건 원천이 얼마나 정리되어 있는지에 크게 좌우되어 일반화하기 어렵습니다(확인 필요).
데이터 원천과 정합성은 어떻게 보장하나요?
정가와 청구액은 청구 문서, 차감은 가격 조건과 정산 내역, 표준원가는 자재 평가에서 읽는 것을 전제로 합니다. 화면 안에서는 단계별 합계가 서로 맞는지 정합성 식으로 검사하고, 표준 보고서와는 KE30 정가 매출 비교로 대사합니다.
권한과 보안은 어떻게 설계하나요?
영업조직과 회사코드 단위 권한을 CDS 접근 제어로 집계 단계에 겁니다. 상세 조회에만 권한을 걸면 전체 합계와 자기 몫의 차이로 다른 조직 숫자를 짐작할 수 있기 때문입니다.
전표가 수천만 건이어도 쓸 수 있나요?
거래 단위 조회는 기간과 고객군을 필수 조건으로 걸어 건수를 제한해야 하고, 집계는 큐브에서 서비스가 계산하도록 둬야 합니다. 샘플 데이터는 거래 108건이라 운영 규모의 성능은 별도로 확인해야 합니다.
고객군이나 제품군 체계가 바뀌면 어떻게 하나요?
매핑 규칙을 바꾸면 집계 단위가 달라지므로 변경 절차와 과거 기간의 재집계 기준을 먼저 정해야 합니다. 화면 코드는 차원의 코드와 이름을 서비스에서 받으므로 매핑이 바뀌어도 코드를 고칠 일은 많지 않습니다.
점검 도구의 결과를 감사나 공시에 쓸 수 있나요?
이 화면은 점검 도구이며 최종 판단은 회사와 감사인이 합니다. 법정·공시 대응에 쓰는 숫자는 표준 거래와 보고서에서 만들고, 이 화면은 내부 관리 점검 용도로 씁니다.