수출 리베이트 정산 다차원 분석 — 수출 솔루션 · IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호) 리베이트 충당과 정산 점검

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

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

수출 담당과 회계 담당이 월말마다 부딪히는 질문은 비슷합니다. 이번 달 리베이트 충당액은 얼마이고, 그중 정산이 끝난 것과 남은 것은 얼마인가, 그리고 연초 계획과 달라졌다면 무엇 때문인가입니다. 표준 화면으로는 청구 문서 조회(VF03), 고객 개별 항목(FBL5N), 수익성 분석(KE30)을 번갈아 열어 엑셀에서 붙이게 되고, 그 사이에 숫자가 서로 달라지는 일이 생깁니다.

이 화면은 청구 라인을 고객 · 제품 · 리베이트 유형 · 인코텀즈 등 차원 조합별 큐브로 묶고, 총매출 · 충당액 · 순매출 · 정산 지급액 · 미정산 잔액을 같은 기준으로 보여 줍니다. 리베이트를 변동대가로 보고 환불부채를 쌓는 관점은 IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)의 요구사항과 맞닿아 있으며, 화면은 그 집계와 점검을 돕는 도구입니다. 최종 판단은 회사와 감사인이 합니다.

한 줄 요약 — 수출 리베이트의 충당 · 정산 · 계획 차이를 한 큐브에서 보고, 칸에서 청구 라인까지 내려가며, 차이를 요인으로 나누고 사유를 남기는 다차원 분석 화면입니다.

핵심 포인트 일곱 가지

핵심 포인트	고객이 얻는 것	지금 방식이라면
① 축을 바꿔도 숫자가 갈라지지 않는 피벗	고객 · 제품 그룹 · 리베이트 유형 · 수출 국가 등 차원을 끌어다 놓아 행 3단계 · 열 2단계로 봅니다. 모든 축이 같은 큐브에서 나와 합계가 어긋날 자리가 없습니다.	고객별 · 국가별 · 유형별 리포트를 따로 만들고, 순매출이 서로 다르면 리포트를 맞추는 회의를 엽니다.
② 칸에서 청구 문서까지 한 번에	숫자를 누르면 그 금액을 만든 청구 라인이 열리고, 합계가 칸 금액과 같은지 그 자리에서 보입니다.	리포트를 닫고 VF03 이나 FBL5N 을 다시 열어 조건을 손으로 맞춥니다.
③ 계획 차이를 여섯 요인으로	매출 물량 · 외화 단가 · 환율 · 리베이트율 · 미계획 협약 · 계획 미이행으로 가릅니다. 어느 요인이 순매출을 끌어내렸는지 순서가 보입니다.	엑셀로 밤새 분해하고, 산식은 사람마다 다릅니다.
④ 충당액과 미정산 잔액을 한 표에서	총매출 · 리베이트 충당액 · 정산 지급액 · 미정산 잔액이 같은 기준으로 나란히 놓입니다. 환불부채가 어디에 쌓였는지 고객 단위로 확인합니다.	매출은 영업, 충당은 회계, 정산은 자금에서 따로 받아 월말에 붙입니다.
⑤ 차이 사유가 행에 남는다	사유가 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도, 다음 달에도 따라옵니다.	같은 질문을 매달 다시 하고, 지난달 답은 메일함에서 찾습니다.
⑥ 사람이 열지 않아도 도는 점검	규칙마다 임계값과 받을 역할이 붙어, 걸리면 보고가 대기함에 올라갑니다. 하루 한 번 제한과 활동 기록은 서비스가 맡습니다.	숫자가 나빠진 날 아무도 화면을 열지 않으면 그대로 지나갑니다.
⑦ 숫자는 모델에 맡기지 않는 AI 와 보고서	금액 · 비율은 서비스가 계산하고 AI 는 설명만 합니다. 보고 있는 범위로 PowerPoint 보고서까지 브라우저에서 만듭니다.	화면을 캡처하고 숫자를 옮겨 적어 보고서를 다시 만듭니다.

사례로 보는 효과

검증용 샘플 데이터(청구 라인 3,656줄, 큐브 387행, 2026년 1~9월)에서 순매출은 30,426백만원으로 연초 계획 30,686백만원보다 260백만원 적었습니다. 여섯 요인으로 나누면 계획 미이행 −1,030백만원이 가장 컸고, 미계획 협약 +763백만원이 이를 일부 메웠습니다. 매출 물량(+120)과 외화 단가(+39)는 오히려 계획을 웃돌았고, 환율은 −118, 리베이트율은 −34였습니다. 요인 여섯 개의 합은 총차이 −260과 오차 0으로 맞아, 어디를 먼저 점검할지가 순서대로 보입니다.

같은 데이터에서 리베이트 충당액은 1,223백만원(리베이트율 3.86%, 계획 3.78%)이고 정산 지급액 836백만원을 뺀 미정산 잔액이 387백만원입니다. 큐브와 원천 라인의 대사식 20건을 전수로 돌려 차이는 0건이었습니다.

도입하면 달라지는 것

마감 보고 준비 — 충당 · 정산 · 차이 표와 요인 분해, 사유, 보고서가 한 화면에서 나와 엑셀 취합이 줄어듭니다.
회의의 주제 — ‘어느 숫자가 맞나’가 아니라 ‘어느 고객의 정산을 먼저 확인할까’를 이야기합니다.
다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
놓치지 않는 점검 — 청구 후 90일이 지난 미정산 잔액처럼 규칙에 걸린 항목이 대기함에 올라옵니다.

이런 회사에 맞습니다

고객별 리베이트 약정(물량 소급 · 판촉 협력 · 조기결제 · 성장 장려)을 두고 여러 통화로 수출하는 제조 · 유통 기업, 그리고 영업 · 회계 · 자금 부서가 같은 숫자를 서로 다른 화면에서 맞추고 있는 조직에 맞습니다. 통화 수와 고객 수가 늘수록 엑셀 취합 비용이 커지므로 효과도 커집니다.

실행 화면

아래 화면은 검증용 샘플 데이터(가상 고객 · 가정 환율과 요율)로 실제 브라우저에서 찍은 것입니다. 금액 단위는 백만원이고, 화면 이름은 사용 순서대로 정리했습니다.

사용 방법

조회조건 입력 — 회사코드(필수), 시작 · 종료 기간(필수, 기본 2026-01~2026-09)을 확인합니다. 저장해 둔 레이아웃이 있으면 고릅니다.
조회 — 조회 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 기본 레이아웃에 자동 조회를 지정했다면 화면을 열 때 이미 조회되어 있습니다.
요약 확인 — 역할별 요약 탭(CEO · CFO · 영업 책임자 · 정산 책임자)에서 숫자 카드를 읽습니다.
탭 · 축 이동 — 차원 칩을 행과 열로 옮기고 필터로 범위를 좁힙니다. 이 단계는 서버를 다시 부르지 않습니다.
행 · 셀 클릭 상세 — 행을 누르면 차이 분해 차트가, 칸을 누르면 원천 청구 라인이 열립니다. 차이가 있는 행에는 사유를 남깁니다.
내보내기 — 상단의 CSV 는 현재 표를, AI 분석 창의 보고서 버튼은 PowerPoint 보고서를 내려받습니다.

무엇으로 만들었나

자리	무엇	왜 그렇게 두었나
화면	OpenUI5 기반 단일 화면. 조회 조건 · 레이아웃 보드 · 역할 요약 · 트리 표 · 차트 · 대화상자	표 · 차트 · 원천 라인이 한 화면에서 이어져야 숫자 근거를 따라갈 수 있습니다.
집계 · 판정 로직	큐브 피벗 · 차트 · 보고서를 각각 별도 모듈로 분리	축 전환 · 차트 · 보고서가 같은 큐브 값을 읽어 합계가 갈라지지 않게 합니다.
데이터 서비스	OData V2 서비스. 조회 조건은 `$filter`, 정렬은 `$orderby`, 원천 라인은 `$top` · `$skip` · `$inlinecount` 로 나눠 읽음. 요인 분해 · AI 해설 · 에이전트 실행은 서비스가 계산	금액 · 비율 · 요인은 서비스에서 한 번만 계산해 화면 · AI · 보고서가 같은 값을 씁니다. 운영 전환 때 서비스 주소만 바꾸면 되도록 화면은 서비스 구현과 분리했습니다.
저장 대상	사유와 레이아웃은 서비스에 쓰기. 에이전트 규칙 · 보고 · 실행 기록은 서비스가 보관	화면을 닫아도 남아야 하는 것만 서비스에 두었습니다.
테마	sap_horizon	SAP Fiori 화면과 같은 모양으로 이어지도록 했습니다.

SAP 표준 기능을 그대로 이어받은 부분 — 청구 문서 · 판매 오더 · 납품 · 회계 전표의 표준 데이터 구조를 그대로 읽고, 문서 번호 · 청구일 · 통화 같은 필드 이름도 표준을 따랐습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

1. 처음 열었을 때 — 조건 · 보드 · 피벗 틀

화면을 열면 조회 조건, 차원 칩을 놓는 레이아웃 보드, 피벗 틀이 한 화면에 보입니다. 조회 버튼을 누르면 같은 화면에서 표와 차트가 채워집니다.

**처음 연 화면** — 조회 전에도 조건 · 레이아웃 보드 · 피벗 틀이 보입니다

회사코드 1000과 기간 2026-01~2026-09, 비교 기준(연초 확정 리베이트 예산)이 미리 채워져 있습니다. 차원 칩은 ‘사용 안 함’ · ‘행’ · ‘열’ 세 칸 가운데 어디에 놓였는지로 표의 모양을 정합니다. 조회 버튼은 조회 조건 영역 오른쪽 끝에 있고 입력 칸에서 Enter 를 눌러도 같습니다.

기본 배치는 제품 그룹과 리베이트 유형이 행, 열은 비어 있습니다. 칩은 끌어서 다른 칸에 놓거나 눌러서 나오는 메뉴(행으로 · 열로 · 사용 안 함으로 · 앞으로 · 뒤로)로 옮깁니다. 행은 최대 3단계, 열은 최대 2단계까지 놓을 수 있습니다.

**조회 직후 피벗과 차트** — 조회 직후 — 제품 그룹별 순매출과 항목 비교 차트

집계 387건 · 원천 3,656줄에서 순매출 30,426백만원, 총매출 31,648백만원, 리베이트 충당액 1,223백만원, 리베이트율 3.9%가 나옵니다. 각 숫자 아래에 기준(연초 계획)과 대비 비율이 함께 적혀 있어 계획 대비 위치를 바로 읽습니다. 오른쪽 막대는 실적(파랑)과 기준(주황), 충당액(초록)을 나란히 보여 줍니다.

**머리 영역을 접은 화면** — 머리 영역을 접으면 요약 한 줄만 남습니다

조회 조건과 보드를 접으면 ‘회사 · 기간 · 행/열/항목 · 기준 대비 · 필터’를 한 줄로 요약해 보여 주고, 그 자리만큼 표와 차트가 넓어집니다. 접어도 조건은 그대로이므로 다시 펼쳐 바꾸고 조회하면 됩니다.

2. 경영 요약 — 역할마다 앞세우는 숫자가 다릅니다

같은 큐브를 네 역할이 서로 다른 눈으로 봅니다. 탭을 바꾸면 요약 숫자와 쪼개 보는 차원이 함께 바뀌고 서버를 다시 부르지 않습니다.

제품 그룹 · 리베이트 유형별 순매출과 총매출, 충당액, 리베이트율을 보고 리베이트가 매출에 주는 부담을 봅니다. 숫자 카드의 ‘기준’은 연초 계획이고 ‘대비’는 계획 대비 실적 비율입니다.

청구월별 순매출과 리베이트 충당액, 미정산 잔액, 리베이트율을 계획과 견주어 환불부채가 쌓이는 달을 점검합니다. 결산 전에 어느 달을 먼저 열어 볼지 정하는 용도입니다.

수출 국가 · 고객별 순매출과 매출 물량 · 외화 단가 요인을 앞세웁니다. 계획과 벌어진 국가와 고객을 찾는 데 맞습니다.

고객 · 인코텀즈별 미정산 잔액과 미정산율, 리베이트율 · 환율 요인을 앞세웁니다. 정산이 밀린 고객을 확인하는 화면입니다.

3. 축 전환과 범위 — 다시 조회하지 않고 다르게 묶기

차원 칩을 행과 열로 옮기는 일은 브라우저 안에서 끝납니다. 큐브를 한 번 읽어 둔 뒤 다시 묶기 때문에 축을 바꿔도 합계가 달라지지 않습니다.

제품 그룹 아래에 고객이 한 단계 더 들어가 행이 3단계까지 펼쳐집니다. 행 이름 칸의 화살표로 단계별로 접고 펴며, 합계는 위쪽 ‘전체 합계’ 행에 그대로 남습니다.

**고객을 열로 이동** — 고객 차원을 열로 이동 — 재조회 없이 다시 묶음

같은 고객 차원을 열로 옮기면 가로로 펼쳐집니다. 이 조작은 서버 요청 0건으로 끝나는 것을 확인했습니다. 열 조합 수는 고객 수에 따라 빠르게 늘기 때문에 상한(36개)을 두었습니다.

화면 아래쪽 차원 필터 단추를 누르면 그 차원의 값 목록이 열립니다. 값 옆에는 청구 라인 수가 붙어 있어 비중이 큰 값을 가려내기 쉽습니다. 큐브에 없는 값은 목록에 나오지 않습니다.

여러 값을 고르면 같은 차원 안에서는 ‘또는’, 차원 사이에서는 ‘그리고’로 묶입니다. 고른 값이 있는 필터 단추는 색이 바뀌어 지금 어떤 조건이 걸려 있는지 한눈에 알 수 있습니다.

필터를 적용하면 요약 카드와 표, 차트가 같은 범위로 다시 계산됩니다. 머리 줄의 집계 건수와 원천 줄 수도 함께 줄어 어느 범위를 보고 있는지 확인됩니다.

행 단계 수가 둘 이상이면 하위 차원으로 묶은 막대로 그려집니다. 세로축을 잘라 그린 경우에는 ‘막대 길이로 크기를 비교하지 마세요’라는 안내가 붙습니다.

표와 차트 사이의 손잡이를 끌어 두 영역의 너비를 바꿉니다. 열이 많을 때는 표를 넓히고, 차트로 설명할 때는 차트를 넓히는 식으로 씁니다.

4. 칸에서 청구 라인까지 — 숫자의 근거 확인

표의 칸을 누르면 그 금액을 만든 원천 청구 라인이 열립니다. 머리 줄에 셀 값과 원천 합계가 같은지 표시되므로 ‘이 숫자를 믿어도 되는가’를 그 자리에서 확인합니다.

**원천 라인 창** — 칸에서 원천 라인으로 — 셀 값과 원천 합계 일치 표시

창 위쪽에 ‘셀 값 = 원천 합계(원천 N줄) 일치’가 표시됩니다. 샘플에서는 반도체 장비 부품 칸이 원천 1,030줄이었고 셀 값과 원천 합계가 일치했습니다. 줄 수가 많으면 500줄씩 나눠 읽고 ‘더 보기’로 이어 봅니다.

청구 문서 번호와 청구일, 판매 오더, 자재, 수량 뒤에 환율, 리베이트율, 총매출, 충당액, 순매출, 미정산 잔액이 이어집니다. 문서 번호를 가지고 표준 청구 문서 조회(VF03)에서 같은 문서를 열어 대조합니다.

상단의 ‘기간별 요약’ 버튼은 청구월별 순매출 · 총매출 · 충당액 · 정산 지급액 · 미정산 잔액과 연초 계획을 한 표로 보여 줍니다. 어느 달에서 계획과 벌어졌는지 먼저 찾을 때 씁니다.

5. 계산항목 — 총매출에서 정산률까지

큐브의 기본 숫자들로 비율과 잔액을 즉석에서 만들어 표에 올립니다. 계산 식은 서비스가 알려 주는 목록에서 고르므로 사람마다 다른 산식을 쓰는 일이 없습니다.

보기 방식을 ‘단계 보기’로 바꾸면 항목이 위에서 아래로 총매출 → 충당액 → 순매출 → 정산 지급액 → 미정산 잔액 → 정산률 순서로 쌓입니다. 이 보기에서는 행 차원이 위에서부터 한 단계씩 펼쳐집니다.

측정값과 계산항목을 한 목록에서 고릅니다. 계산항목에는 ‘(계산)’이 붙어 구분되고, 기본은 네 항목이 선택되어 있습니다.

6. 기준 대비 차이 — 같은 표가 검토 회의 자료가 됩니다

기준 대비 스위치를 켜면 모든 칸이 실적 · 기준 · 차이 · 증감률로 바뀌고, 행을 누르면 차트가 차이 분해(워터폴)로 바뀝니다.

칸마다 실적 아래에 ‘기준 · 차이 · 증감률’이 작게 붙습니다. 금액과 비율 임계를 모두 넘는 칸만 색으로 표시해 모든 칸이 빨갛게 되는 일을 막았습니다.

반도체 장비 부품은 계획 13,491에서 실적 12,877로 614 적었습니다. 요인은 매출 물량 +10, 외화 단가 +34, 환율 −36, 리베이트율 −22, 미계획 협약 +125, 계획 미이행 −726입니다. 막대 색은 계획보다 늘면 초록, 줄면 빨강입니다.

차트 아래에 ‘요인 합계 / 총차이 (오차 0)’ 줄이 나옵니다. 요인 여섯 개를 더한 값이 총차이와 같은지 매번 계산해 보여 주므로, 분해가 어긋나면 그 자리에서 드러납니다.

차이가 있는 행에서 사유 버튼을 누르면 사유 구분(매출 물량 변경 · 외화 단가 변경 · 환율 · 리베이트율 변경 · 계획에 없던 협약 · 기타)과 내용을 적을 수 있습니다. 창에는 대상 행과 기간, 차이 금액이 함께 표시됩니다.

저장한 사유는 표의 사유 열에 아이콘으로 나타납니다. 사유는 조회 범위와 행 경로에 묶여 저장되므로 축을 바꾸거나 화면을 다시 열어도 같은 행에 붙어 있습니다.

7. AI 분석과 보고서 — 숫자는 서비스가, 설명은 AI 가

AI 분석은 지금 보고 있는 범위의 요약과 주요 발견을 보여 줍니다. 금액과 비율은 서비스가 계산한 값만 쓰고 AI 는 읽어서 설명합니다. 기본은 규칙 기반 해설이며 모델 연결은 설정으로 켭니다.

범위 줄(기간 · 필터), 분석 방식 표시, 요약 문장, 주요 발견 목록이 차례로 나옵니다. 두드러진 차이가 없으면 ‘두드러진 차이가 없습니다’로 끝나고, 표시하지 않은 항목이 있으면 그 사실도 적습니다.

아래로 내리면 ‘근거 수치’ 표가 나옵니다. 제품 그룹마다 순매출 실적 · 계획 · 미정산 잔액 · 리베이트 충당액 · 순매출 차이 · 등록된 사유가 한 줄에 있고, 반도체 장비 부품은 12,877 / 13,491 / −614입니다. 표 아래에는 금액은 서비스가 큐브에서 계산한 값이고 해설은 그 값을 읽어 정리한 것이라는 안내가 붙습니다. 창 아래의 보고서 버튼은 보고 있는 범위로 PowerPoint 보고서를 브라우저에서 만들어 내려받게 하며, 샘플에서는 6장짜리 파일이 열렸습니다.

8. AI 에이전트 — 사람이 열지 않아도 도는 점검

감시 규칙마다 지표와 기준값, 점검 주기, 받을 역할이 붙어 있습니다. 규칙에 걸리면 보고가 역할별 대기함에 올라가고, 실행 기록이 남습니다.

규칙마다 지표 · 기준값 · 점검 주기 · 받는 역할 · 사용 여부가 한 줄입니다. 순매출 계획 차이 금액(CEO), 리베이트율 상한 5%(CFO), 미정산 잔액 임계와 청구 후 90일 지난 미정산 잔액(정산 책임자), 리베이트율 요인 손실 금액(영업 책임자)이 기본으로 들어 있고 기준값은 입력 칸에서 바로 고칩니다. 위의 타이머 스위치는 화면이 열려 있는 동안 하루 1회만 점검하는 방식이며 기본은 꺼져 있습니다.

‘지금 실행’ 뒤 규칙에 걸린 항목이 받는 역할 이름과 함께 올라옵니다. 예를 들어 중국의 리베이트율 요인 손실은 영업 책임자에게, 청구 후 90일이 지난 미정산 잔액은 정산 책임자에게 갑니다. 보고마다 실행 번호와 시각이 붙고 역할 선택 상자로 역할별 대기함을 나눠 봅니다.

첫 실행이 실행 번호 · 시각 · 실행 주체(사용자) · 결과(실행함) · 발견 건수 8건과 ‘감시 규칙 5개 중 8건이 걸렸습니다’ 설명으로 남습니다. 실행 주체는 사용자 · 타이머 · 배치로 구분되어 누가 돌렸는지 추적할 수 있습니다.

**하루 한 번 제한** — 두 번째 실행은 하루 한 번 제한으로 건너뜀

‘지금 실행’을 눌러 규칙 5개 중 보고 8건이 올라왔고, 같은 날 다시 누르면 ‘오늘은 이미 실행했습니다’와 함께 건너뜀으로 기록됩니다. 하루 한 번 판정은 화면이 아니라 서비스가 맡습니다.

9. 레이아웃 저장과 복원 — 매달 같은 배치를 다시 만들지 않습니다

축 배치와 분석 항목, 필터를 이름을 붙여 저장합니다. 기본 레이아웃으로 지정하고 자동 조회를 켜 두면 화면을 열자마자 같은 모양의 표가 나옵니다.

이름을 적고 ‘기본 레이아웃으로 지정’과 ‘열 때 자동 조회’를 고릅니다. 창에는 저장될 내용(행 · 열 · 항목 · 기준 대비 · 필터)이 한 줄로 미리 보입니다.

저장한 레이아웃을 적용 · 이름 변경 · 삭제합니다. 기본과 자동 조회 지정 여부가 열로 나와 어떤 것이 시작 화면인지 확인됩니다.

**새로 고친 뒤 복원** — 새로 고친 뒤 기본 레이아웃과 자동 조회로 복원

화면을 새로 고치면 기본 레이아웃의 배치가 복원되고 자동 조회까지 실행되어 저장 당시의 조회 상태로 시작합니다. 저장 데이터가 깨졌을 때는 안내 메시지를 띄우고 기본 배치로 엽니다.

10. 좁은 화면과 한계

열 조합이나 행 수가 너무 많으면 표를 그리지 않고 이유를 알려 줍니다. 좁은 화면에서는 영역이 위아래로 쌓입니다.

열에 차원을 너무 많이 올려 열 조합이 108개가 되면 ‘최대 36개를 넘습니다. 열 차원을 줄여 주세요’라는 안내가 뜹니다. 표를 억지로 그리다 느려지는 일을 막는 한계입니다.

폭 390px에서는 조회 조건과 요약 카드가 한 열로 쌓이고 가로로 넘치지 않습니다. 단추는 손가락으로 누르기 좋은 크기를 유지합니다.

표가 먼저, 차트는 그 아래에 놓입니다. 표 행을 누르면 아래의 차트가 차이 분해로 바뀝니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 조회 조건을 $filter 로 만들어 서비스에 한 번 요청하고, 돌려받은 큐브를 브라우저에서 피벗합니다. 그 뒤의 축 이동 · 접기 · 펴기는 요청 없이 같은 큐브를 다시 묶을 뿐입니다. 원천 라인과 요인 분해 · AI 해설 · 에이전트 실행만 필요할 때 서비스에 다시 묻습니다.

판정 조건	결과 상태	사용자 조치
셀 값과 원천 라인 합계가 같음	일치	그대로 사용합니다.
셀 값과 원천 라인 합계가 다름	점검 필요	조회 범위와 필터를 확인하고 원천 라인을 대조합니다.
순매출 차이가 금액 임계와 비율 임계를 모두 넘음	차이 표시(색칠)	차이 분해에서 요인을 확인하고 사유를 남깁니다.
요인 여섯 개의 합이 총차이와 같음	검산 통과	요인별 점검 순서를 정합니다.
리베이트율이 감시 규칙 상한을 넘음	확인 필요(대기함 보고)	해당 고객의 약정과 청구 라인을 확인합니다.
청구 후 90일이 지난 미정산 잔액	점검 필요(대기함 보고)	정산 일정과 크레딧 노트 처리 상태를 확인합니다.
에이전트를 같은 날 다시 실행	하루 한 번 제한으로 건너뜀	대기함의 기존 보고를 확인합니다.

산출과 대사 흐름

단계	산출 · 대사식	SAP 데이터 지점
1 청구	총매출(원화) = 외화 매출 × 적용 환율	청구 문서 항목
2 충당	리베이트 충당액 = 총매출 × 약정 요율, 순매출 = 총매출 − 충당액	약정 조건(확인 필요) · 청구 문서
3 정산	정산 지급액 = 크레딧 노트로 처리된 금액, 미정산 잔액 = 충당액 − 정산 지급액	고객 개별 항목 · 회계 전표
4 대사	큐브 합계 = 원천 라인 합계(금액 5종 · 수량 · 라인 수 · 항등식 4종 · 요인 합계 · 통화별 외화 금액 8건, 모두 20건)	큐브와 원천 라인
5 차이 분해	계획 순매출 + 요인 6가지(매출 물량 · 외화 단가 · 환율 · 리베이트율 · 미계획 협약 · 계획 미이행) = 실적 순매출	연초 계획 · 큐브

조회조건

조회 조건	필수 여부	기본값 · 설명
회사코드	필수	1000. 큐브 · 기준 · 기간 요약을 읽는 `$filter` 조건입니다.
시작 · 종료 기간	필수	2026-01 ~ 2026-09. 청구월 범위(`ge` · `le`)이며 시작이 종료보다 늦으면 안내합니다.
비교 기준	고정	연초 확정 리베이트 예산
차원 다중 선택	선택	차원 안에서는 또는, 차원 사이는 그리고. 큐브에 있는 값만 보입니다.
표시 행 수	선택	기본 14행, 전체 선택 가능

결과 컬럼

컬럼	의미	산출식
총매출	외화 청구액을 원화로 환산한 금액	외화 매출 × 적용 환율
리베이트 충당액	환불부채로 인식한 리베이트	총매출 × 약정 요율
순매출	리베이트를 뺀 매출	총매출 − 충당액
정산 지급액	크레딧 노트 등으로 처리된 금액	정산 전표 기준(확인 필요)
미정산 잔액	아직 정산되지 않은 충당액	충당액 − 정산 지급액
기준 · 차이 · 증감률	연초 계획과 비교한 값	차이 = 실적 − 기준, 증감률 = 차이 ÷ 기준
리베이트율 · 정산률	충당과 정산의 비율	충당액 ÷ 총매출, 정산 지급액 ÷ 충당액

좁은 화면에서 달라지는 것

폭이 좁아지면 조회 조건 · 역할 요약 · 표 · 차트가 위에서 아래로 한 열로 쌓이고, 차트는 표 아래로 내려갑니다. 표는 가로로 밀어 보며, 대화상자는 화면 폭에 맞춰 줄어듭니다. 열 조합이 상한(36개)을 넘으면 표를 그리지 않고 열 차원을 줄이라는 안내를 먼저 보여 줍니다.

파일 구성

exprebate/
├─ index.html · Component.js · manifest.json
├─ controller/  화면 제어
├─ view/        화면 정의와 대화상자
├─ model/       피벗 · SVG 차트 · 보고서(PPTX) · 레이아웃 · 서식
├─ i18n/ · css/
└─ odata/       서비스 정의와 구현

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 화면의 숫자는 표준 화면과 같은 문서 · 필드에서 나오므로, 서로 맞춰 보며 쓰는 것이 기본입니다.

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

하고 싶은 일	SAP 표준	표준에서 걸리는 자리	이 앱이 하는 일
고객별 청구 문서 확인	VF03 청구 문서 조회, VA03 판매 오더 조회	한 문서씩 열어 보므로 고객 · 제품 · 월을 가로질러 합칠 수 없음	같은 문서 필드를 큐브로 묶어 축을 바꿔 보고 칸에서 문서로 내려감
고객 미결 · 크레딧 노트 대조	FBL5N 고객 개별 항목	리베이트 충당액과 정산 지급액을 같은 표에 놓는 화면은 없음	충당액 − 정산 지급액을 미정산 잔액으로 고객별로 보여 줌
수익성 관점의 순매출	KE30 수익성 분석 보고서	계획 대비 차이를 여섯 요인으로 나누는 단계는 없음	요인 분해와 검산 줄, 사유 저장
납품 조건(인코텀즈) 확인	VL03N 납품 조회	리베이트 지표와 같은 축으로 묶지 못함	인코텀즈를 차원으로 올려 리베이트율을 비교
리베이트 약정 조회	VBO3 리베이트 약정 조회	약정별 화면이라 수출 국가 · 통화 단위 모아 보기는 없음	약정 요율을 충당액 계산에 쓰고 고객 단위로 모아 봄
규칙에 걸린 항목을 먼저 알림	없음	없음	감시 규칙 · 대기함 · 하루 한 번 점검
역할별 요약과 보고서	없음	없음	CEO · CFO · 영업 · 정산 요약과 PowerPoint 보고서

T-code 별 연계 지점

T-code	이름	연계
VF03	청구 문서 조회	원천 라인 창의 문서 번호 · 청구일 · 금액이 같은 필드입니다. 이 앱 결과 → VF03 에서 문서를 열어 대조하고, VF03 값 → 이 앱의 원천 라인 창에서 같은 문서를 찾아 큐브 어느 칸에 들어갔는지 봅니다. 청구 문서의 법정 · 감사 대응은 표준에 남깁니다.
VA03	판매 오더 조회	원천 라인의 판매 오더 번호로 약정 조건과 오더 조건을 확인합니다.
VL03N	납품 조회	인코텀즈와 인도 조건을 차원으로 올려 리베이트율을 비교합니다. 인도 일자 기준의 매출 귀속은 표준 화면에서 확인합니다.
FBL5N	고객 개별 항목	정산 지급액과 미정산 잔액을 고객 단위로 대조합니다. 이 앱의 미정산 잔액 → FBL5N 의 크레딧 노트 처리 여부, FBL5N 의 미결 항목 → 이 앱 고객 행으로 오갑니다.
KE30	수익성 분석 보고서	고객 · 제품별 순매출을 맞춰 봅니다. 수익성 세그먼트 정의가 다르면 차이가 날 수 있어 대사 체계(운영 시점에 할 일)에서 정합니다.
VBO3	리베이트 약정 조회	충당액 계산에 쓰는 약정 요율의 원천입니다. 약정 변경은 표준 화면에서 하고 이 앱은 읽기만 합니다.
FB03	회계 전표 조회	정산 전표와 충당 전표를 열어 금액을 확인합니다.

기존 리포트를 없애야 하나? 없애지 않아도 됩니다. 법정 · 감사 · 세무 신고에 쓰는 표준 리포트는 그대로 두고, 이 화면은 마감 전 점검과 차이 설명에 씁니다. 숫자가 맞는지 확인한 뒤 엑셀 취합 작업만 줄이는 것이 현실적인 순서입니다.

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 만들고 Fiori 분석 화면이나 Analysis for Office 에서 소비하는 방식이 표준입니다. 이 앱도 같은 구조(기본 뷰 → 큐브 → 쿼리 → 권한 → 서비스)를 따라 설계했으므로, 운영에서는 표준 분석 쿼리와 같은 서비스 계층 위에 올라갑니다. 표준 분석 화면이 정해진 질문에 답한다면, 이 화면은 축을 바꿔 가며 ‘왜 그런가’를 따라가는 용도입니다. 표준 CDS 뷰 가운데 청구 문서 계열을 쓸 수 있지만 버전별 차이가 있어 확인 필요로 두고, 이 글의 코드는 원천 테이블 기준으로 썼습니다.

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

자리	손대는 일	비고
약정 요율 원천	조건 레코드에서 요율을 읽는 쿼리	약정 구조가 다르면 이 한 곳만 바꿉니다
리베이트 유형 매핑	유형 · 계정 · 설명을 매핑 테이블에서 관리	새 유형은 행 추가로 끝납니다
확장 필드	고객 계층 · 제품 계층 등 차원 추가	큐브 뷰에 필드를 더하고 쿼리에 노출
환산 규칙	청구일 · 월말 환율 선택	통화 환산 함수를 한 곳에 둡니다
권한	회사코드 · 영업 조직 권한 객체	권한 역할 한 곳에서 제어
커스텀 필드 · BAdI	청구 문서에 붙은 사용자 필드 읽기	필요한 경우에만 사용

요구사항 매핑표

기준서	요구사항	대응 기능	원천 데이터	비고
IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)	변동대가 추정과 환불부채	리베이트 충당액 · 미정산 잔액 집계	청구 문서 · 약정 조건(확인 필요)	점검 도구이며 회계 판단은 회사와 감사인이 합니다
IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)	추정 변경에 따른 재측정	계획 대비 차이 요인 분해	연초 계획 · 큐브	리베이트율 변경 요인으로 확인
IAS 21 환율변동효과(K-IFRS 제1021호)	외화 거래의 원화 환산	환율 요인 · 통화별 외화 대사	청구 문서 통화 · 환율	환율은 샘플의 가정값

CDS 구성

아래는 운영 SAP 에서 같은 화면을 받치는 CDS 설계입니다. 원천은 청구 · 판매 오더 · 납품 · 회계 전표의 표준 테이블이며, 약정 조건과 정산 원천은 확인 필요로 두고 별도 뷰(ZEXRB_AgreementRate · ZEXRB_SettledAmount)로 분리했습니다. 코드는 설계 스케치이며 운영 적용 전에 시스템 버전에 맞춰 확인해야 합니다.

뷰 레이어 구성

레이어	뷰	하는 일	왜 나누나
기준	ZR_ExportRebateTypeMap(매핑 테이블 포함)	리베이트 유형 · 계정 · 설명	새 유형을 뷰 수정 없이 행 추가로 처리
차원	ZI_ExportRebateCustomer	고객 이름 · 수출 국가 · 지역	이름 변경이 큐브에 번지지 않게
기본	ZI_ExportRebateBilling	청구 라인 · 원화 · 외화 · 환율	큐브와 드릴스루가 같은 라인을 공유
큐브	ZI_ExportRebateAccrual → ZC_ExportRebateCube	충당 · 정산을 라인에서 구하고 차원 조합별로 합산	화면 합계가 한 원천에서만 나오게
쿼리	ZC_ExportRebateQuery	행 · 열 · 필터와 항목 이름	화면별로 쿼리만 바꿈
권한	ZA_ExportRebateAuth	회사코드 권한 제어	권한을 한 곳에서 관리
서비스	ZSD_ExportRebate	OData V2 노출	노출 범위와 이름 관리

① 리베이트 유형 매핑 테이블 — ZEXRB_TYPEMAP · ZR_ExportRebateTypeMap

유형 코드가 어느 환불부채 계정과 매출 차감 계정으로 가는지를 정하는 자리입니다. 운영에서는 회계가 이 테이블의 계정 값을 확정해야 화면의 충당액이 전표와 맞습니다. 유형이 늘 때 뷰를 고치지 않도록 코드가 아닌 데이터로 둡니다.

" ─────────────────────────────────────────────────────────
" ZEXRB_TYPEMAP — 리베이트 유형 매핑 테이블
" 역할 : 유형 코드 → 설명 · 환불부채 계정 · 매출 차감 계정
" 나눈 이유 : 새 유형이 생겨도 뷰를 고치지 않고 행만 추가
" ─────────────────────────────────────────────────────────
@EndUserText.label : 'Export rebate type mapping'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zexrb_typemap {
  key client       : abap.clnt not null;
  key rebate_type  : abap.char(6) not null;   " VOL · PROMO · EARLY · GROW
  type_text        : abap.char(40);
  liab_account     : abap.char(10);           " 환불부채 계정
  contra_account   : abap.char(10);           " 매출 차감 계정
  valid_from       : abap.dats;
  valid_to         : abap.dats;
}

" 매핑 조회용 뷰 — 이후 뷰는 이 뷰만 바라본다
@AccessControl.authorizationCheck : #NOT_REQUIRED
define view entity ZR_ExportRebateTypeMap
  as select from zexrb_typemap
{
  key rebate_type    as RebateType,
      type_text      as RebateTypeText,
      liab_account   as LiabilityAccount,
      contra_account as ContraAccount,
      valid_from     as ValidFrom,
      valid_to       as ValidTo
}

② 청구 라인 기본 뷰 — ZI_ExportRebateBilling

청구 문서 항목을 헤더와 묶어 원화 환산에 필요한 금액 · 통화 · 환율을 함께 읽습니다. 통화 필드에 @Semantics.currencyCode, 수량에 단위를 붙여 뒤 단계의 집계에서 통화 혼합 합산이 일어나지 않게 합니다.

" ─────────────────────────────────────────────────────────
" ZI_ExportRebateBilling — 청구 라인 기본 뷰
" 역할 : 청구 문서 항목을 원화 · 외화 금액과 함께 읽는다
" 나눈 이유 : 큐브와 드릴스루가 같은 라인을 공유
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : 'Export rebate - billing line'
define view entity ZI_ExportRebateBilling
  as select from vbrp
    inner join   vbrk on vbrk.vbeln = vbrp.vbeln
{
  key vbrp.vbeln                       as BillingDocument,
  key vbrp.posnr                       as BillingItem,
      vbrk.bukrs                       as CompanyCode,
      vbrk.fkdat                       as BillingDate,
      left( vbrk.fkdat, 6 )            as BillingMonth,
      vbrk.kunag                       as Customer,
      vbrk.inco1                       as Incoterms,
      @Semantics.currencyCode: true
      vbrk.waerk                       as TransactionCurrency,
      vbrp.aubel                       as SalesOrder,
      vbrp.matnr                       as Material,
      vbrp.arktx                       as ItemText,
      @Semantics.quantity.unitOfMeasure: 'BaseUnit'
      vbrp.fkimg                       as BillingQuantity,
      vbrp.vrkme                       as BaseUnit,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      vbrp.netwr                       as NetAmountFc,
      vbrk.kurrf                       as ExchangeRate
}

③ 차원 뷰 — ZI_ExportRebateCustomer

고객 이름 · 수출 국가 · 지역을 한곳에 모읍니다. @Analytics.dataCategory: #DIMENSION 으로 분석 쿼리가 필터 값 목록으로 바로 쓰게 하고, 이름은 텍스트 요소로 연결합니다.

" ─────────────────────────────────────────────────────────
" ZI_ExportRebateCustomer — 고객 · 제품 그룹 · 사업부 차원
" 역할 : 이름과 계층을 한 곳에서 붙인다(수출 국가 · 지역 포함)
" 나눈 이유 : 차원 이름 변경이 큐브에 번지지 않게
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'Customer'
@EndUserText.label : 'Export rebate - customer dimension'
define view entity ZI_ExportRebateCustomer
  as select from kna1
{
  @ObjectModel.text.element : [ 'CustomerName' ]
  key kna1.kunnr  as Customer,
      kna1.name1  as CustomerName,
      kna1.land1  as ExportCountry,
      kna1.regio  as Region,
      kna1.brsch  as Industry
}

④ 충당 · 정산 라인 — ZI_ExportRebateAccrual

청구 라인에 약정 요율을 곱해 충당액을 구하고 정산 지급액을 붙입니다. 약정 요율 뷰와 정산 금액 뷰는 원천 확정 전이라 이름만 두었고, 확정되면 이 뷰의 조인 두 곳만 바뀝니다. 통화 환산은 이 뷰에서만 합니다.

" ─────────────────────────────────────────────────────────
" ZI_ExportRebateAccrual — 충당 · 정산 라인
" 역할 : 청구 라인마다 약정 요율로 충당액을 구하고 정산 지급액을 붙인다
" 나눈 이유 : 충당과 정산이 한 라인에서 만나야 미정산 잔액이 나온다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : 'Export rebate - accrual and settlement'
define view entity ZI_ExportRebateAccrual
  as select from ZI_ExportRebateBilling as b
    inner join   ZEXRB_AgreementRate    as a on  a.Customer      = b.Customer
                                             and b.BillingDate  between a.ValidFrom and a.ValidTo
    left outer join ZEXRB_SettledAmount as s on  s.BillingDocument = b.BillingDocument
                                             and s.BillingItem     = b.BillingItem
    association [1..1] to ZR_ExportRebateTypeMap as _Type on _Type.RebateType = a.RebateType
{
  key b.BillingDocument,
  key b.BillingItem,
      b.CompanyCode,
      b.BillingMonth,
      b.Customer,
      b.Incoterms,
      a.RebateType,
      b.TransactionCurrency,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      cast( b.NetAmountFc * b.ExchangeRate as abap.curr(23,2) )                         as GrossAmount,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      cast( b.NetAmountFc * b.ExchangeRate * a.Rate as abap.curr(23,2) )                as RebateAccrual,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      cast( coalesce( s.SettledAmount, 0 ) as abap.curr(23,2) )                         as SettledAmount,
      cast( 'KRW' as abap.cuky )                                                        as CompanyCodeCurrency,
      _Type
}

⑤ 분석 큐브 — ZC_ExportRebateCube

차원 조합별 총매출 · 충당액 · 순매출 · 정산 지급액 · 미정산 잔액을 합산합니다. 화면의 모든 합계는 이 큐브에서 나오므로 이 뷰의 합산식이 곧 숫자의 정의입니다.

" ─────────────────────────────────────────────────────────
" ZC_ExportRebateCube — 분석 큐브
" 역할 : 차원 조합별로 총매출 · 충당액 · 순매출 · 정산 · 미정산을 합산
" 나눈 이유 : 피벗이 읽는 한 가지 원천. 화면 합계는 모두 여기서 나온다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : 'Export rebate - cube'
define view entity ZC_ExportRebateCube
  as select from ZI_ExportRebateAccrual as r
  association [0..1] to ZI_ExportRebateCustomer as _Customer on _Customer.Customer = r.Customer
{
  key r.CompanyCode,
  key r.BillingMonth,
  key r.RebateType,
  key r.Customer,
  key r.Incoterms,
  key r.TransactionCurrency,
      r.CompanyCodeCurrency,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( r.GrossAmount )    as Gross,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( r.RebateAccrual )  as Rebate,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( r.GrossAmount ) - sum( r.RebateAccrual ) as Net,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( r.SettledAmount )  as Settled,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( r.RebateAccrual ) - sum( r.SettledAmount ) as OpenAmount,
      _Customer
}
group by r.CompanyCode, r.BillingMonth, r.RebateType, r.Customer,
         r.Incoterms, r.TransactionCurrency, r.CompanyCodeCurrency

⑥ 분석 쿼리 — ZC_ExportRebateQuery

화면에 보일 행 · 열 · 필터를 정합니다. 청구월은 필수 범위로 두어 대용량 조회가 조건 없이 돌지 않게 합니다.

" ─────────────────────────────────────────────────────────
" ZC_ExportRebateQuery — 분석 쿼리(Consumption)
" 역할 : 화면에 노출할 행 · 열 · 필터와 항목 이름을 정한다
" 나눈 이유 : 큐브는 그대로 두고 화면별로 쿼리만 다르게 만든다
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : 'Export rebate analysis'
@UI.headerInfo : { typeName : 'Rebate', typeNamePlural : 'Rebates' }
define view entity ZC_ExportRebateQuery
  as select from ZC_ExportRebateCube
{
  @AnalyticsDetails.query.axis : #FREE
  @Consumption.filter : { selectionType : #RANGE, mandatory : true, multipleSelections : false }
  @UI.selectionField : [ { position : 10 } ]
  key BillingMonth,

  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true }
  @UI.lineItem : [ { position : 20 } ]
  RebateType,

  @AnalyticsDetails.query.axis : #FREE
  Customer,
  @AnalyticsDetails.query.axis : #FREE
  Incoterms,
  @AnalyticsDetails.query.axis : #FREE
  TransactionCurrency,

  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '총매출'
  Gross,
  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '리베이트 충당액'
  Rebate,
  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '순매출'
  Net,
  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '미정산 잔액'
  OpenAmount
}

⑦ 접근 제어 — ZA_ExportRebateAuth

큐브와 쿼리 모두에 회사코드 조회 권한(F_BKPF_BUK)을 겁니다. 권한이 없으면 행이 아예 돌아오지 않아 화면에서 따로 숨길 필요가 없습니다.

" ─────────────────────────────────────────────────────────
" ZA_ExportRebateAuth — 접근 제어(DCL)
" 역할 : 회사코드 조회 권한이 있는 사용자에게만 행을 보여 준다
" 나눈 이유 : 권한을 쿼리마다 따로 두지 않고 한 역할로 제어
" ─────────────────────────────────────────────────────────
@EndUserText.label : 'Export rebate authorization'
@MappingRole : true
define role ZA_ExportRebateAuth {
  grant select on ZC_ExportRebateCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
  grant select on ZC_ExportRebateQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩 — ZSD_ExportRebate

쿼리와 원천 라인, 고객 차원을 OData V2 로 노출합니다. 게시 뒤 화면의 서비스 주소만 운영 주소로 바꾸면 샘플에서 확인한 조작이 그대로 이어집니다.

" ─────────────────────────────────────────────────────────
" ZSD_ExportRebate — 서비스 정의와 바인딩
" 역할 : 쿼리와 원천 라인을 OData V2 로 노출
" 나눈 이유 : 서비스 이름과 노출 범위를 한 곳에서 관리
" ─────────────────────────────────────────────────────────
@EndUserText.label : 'Export rebate analysis service'
define service ZSD_ExportRebate {
  expose ZC_ExportRebateQuery   as RebateAnalysis;
  expose ZI_ExportRebateBilling as BillingLine;
  expose ZI_ExportRebateCustomer as Customer;
}
" 서비스 바인딩(ADT 에서 생성): ZSB_ExportRebate_V2 — 바인딩 유형 OData V2 - UI, 게시 후
" 서비스 활성화(/IWFND/MAINT_SERVICE) 또는 바인딩 게시로 화면에서 호출

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않으면 화면 숫자와 표준 화면 숫자가 서로 다른 이유를 설명하기 어렵습니다.

해야 할 일	무엇을 정하나	정하지 않으면	누가
약정 조건 원천 확정	리베이트 약정의 요율 · 유형 · 유효 기간을 어느 조건 레코드에서 읽을지	충당액이 약정과 다르게 계산됨	영업 · 회계
환불부채 · 매출 차감 계정 매핑	리베이트 유형별 부채 계정과 매출 차감 계정	충당 전표와 화면 숫자를 맞출 수 없음	회계
정산 원천 확정	정산 지급액을 크레딧 노트 · 회계 전표 가운데 무엇으로 볼지	미정산 잔액이 실제와 어긋남	회계 · 자금
환율 유형과 환산 시점	청구일 환율 · 월말 환율 중 무엇으로 환산할지	환율 요인과 표준 화면 숫자가 어긋남	회계 · 자금
인코텀즈별 통제 이전 시점	매출 인식 시점과 청구 월 기준	월 귀속이 달라 계획과 비교가 틀어짐	회계 · 영업
부호 규칙	반품 · 크레딧 노트의 부호	순매출이 이중으로 줄거나 늘어남	회계
차원 범위	고객 계층 · 제품 그룹 · 사업부 중 차원으로 올릴 것	열 조합이 상한을 넘거나 필요한 축이 없음	영업 · IT
권한 설계	회사코드 · 영업 조직별 조회 범위	조회 범위가 넓어 정보가 노출됨	IT · 감사
대사 체계	표준 화면과 맞출 항목과 허용 차이	숫자 차이가 날 때 어디를 볼지 정해지지 않음	회계 · IT
성능 기준	집계 위치 · 필수 파라미터 · 응답 시간 기준	조회가 느려져 쓰지 않게 됨	IT
전송과 서비스 활성화	전송 요청 순서, 서비스 게시, 화면의 서비스 주소 교체	화면이 샘플 서비스를 계속 바라봄	IT
감시 규칙과 배치	규칙 · 기준값 · 받을 역할과 배치 등록	알림이 오지 않거나 너무 많이 옴	영업 · 정산 · IT

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

검증용 샘플 데이터(청구 라인 3,656줄 · 큐브 387행 · 2026년 1~9월)에서 큐브 합계와 원천 라인 합계를 요청 시점에 다시 합산해 대사식 20건을 돌렸습니다. 차이는 모두 0이었고 의도적 예외도 없었습니다.

대사식	검사 건수	차이
금액 5종 — 총매출 · 충당액 · 순매출 · 정산 지급액 · 미정산 잔액	5건	0건
수량 · 라인 수	2건	0건
항등식 4종 — 순매출 · 미정산 잔액 등	4건	0건
요인 합계 = 총차이(6요인)	1건	0건
통화별 외화 금액	8건	0건
합계	20건	0건 (최대 차이 0원 · 의도적 예외 0건)

도입 포인트의 사례와 같은 숫자입니다. 순매출 30,426백만원은 계획 30,686백만원과 −260 차이이고, 여섯 요인(+120 · +39 · −118 · −34 · +763 · −1,030)의 합이 −260으로 오차 0입니다. 반도체 장비 부품 칸은 원천 1,030줄의 합계와 셀 값이 일치했습니다. 날짜 범위 $filter 는 41행을 정확히 걸러 냈습니다.

운영 데이터로 갈 때

청구 라인이 수천만 건이면 큐브 합산은 화면이 아니라 데이터베이스에서 해야 합니다. 쿼리의 청구월을 필수 범위로 두고, 회사코드 · 청구월에 맞는 접근 경로(인덱스)를 확인하며, 원천 라인은 500줄씩 나눠 읽는 방식을 그대로 씁니다. 응답 시간 기준은 도입 전에 정해 두고, 느린 조합은 열 조합 상한과 필수 필터로 막습니다. 월 마감 직후처럼 조회가 몰리는 시점은 집계 결과를 미리 만들어 두는 방법도 검토합니다.

자주 묻는 질문

도입을 검토하는 분들이 자주 묻는 26가지를 주제별로 모았습니다.

숫자와 산식

이 화면의 숫자는 실제 회사 데이터인가요?

아닙니다. 검증용 샘플 데이터이며 고객 · 문서 번호 · 환율 · 요율은 모두 가상 또는 가정값입니다. 청구 라인 3,656줄을 큐브 387행으로 묶었고 기간은 2026년 1~9월입니다. 운영 데이터로 가려면 약정 조건과 정산 원천을 확정하고 서비스 주소를 바꿉니다.

순매출 · 충당액 · 미정산 잔액은 어떻게 계산하나요?

총매출은 외화 매출에 적용 환율을 곱한 원화 금액입니다. 리베이트 충당액은 총매출에 약정 요율을 곱하고, 순매출은 총매출에서 충당액을 뺀 값입니다. 정산 지급액은 크레딧 노트 등으로 처리된 금액이며 미정산 잔액은 충당액에서 정산 지급액을 뺍니다. 모든 계산은 서비스가 하고 화면은 그 값을 보여 줍니다.

계획 대비 차이의 여섯 요인은 무엇인가요?

매출 물량, 외화 단가, 환율, 리베이트율, 미계획 협약, 계획 미이행입니다. 계획 순매출에 여섯 요인을 더하면 실적 순매출이 되도록 나눕니다. 샘플에서는 +120 · +39 · −118 · −34 · +763 · −1,030이며 합은 총차이 −260과 같습니다. 요인 합계와 총차이를 매번 대조해 오차를 화면에 표시합니다.

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

청구 문서의 통화와 환율로 원화를 만들고, 환율 요인은 계획 환율과 실제 환율 차이로 분리합니다. 샘플의 환율은 모두 가정값입니다. 운영에서는 청구일 환율과 월말 환율 가운데 무엇을 쓸지 먼저 정해야 하며, 정한 기준은 환산 규칙 한 곳에만 둡니다.

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

대사식 20건을 요청 시점에 다시 합산해 비교합니다. 금액 5종, 수량과 라인 수, 항등식 4종, 요인 합계, 통화별 외화 금액 8건이 대상이며 샘플에서는 차이가 0건이었습니다. 칸을 눌러 원천 라인을 열면 그 칸의 값과 원천 합계가 같은지도 바로 표시됩니다.

리베이트율이 계획보다 높게 나오면 무엇을 보나요?

리베이트율이 계획 3.78%보다 높은 3.86%인 샘플에서는 요인 분해의 리베이트율 요인(−34)과 미계획 협약(+763)을 함께 봅니다. 그다음 해당 고객의 원천 라인을 열어 약정 요율이 적용된 문서를 확인합니다. 원인이 약정 변경이면 사유를 남겨 다음 달에도 따라오게 합니다.

화면과 조작

축을 바꾸면 서버에 다시 요청하나요?

아니요. 조회 때 큐브를 한 번 읽고 그 뒤의 축 이동 · 접기 · 펴기는 브라우저에서 다시 묶습니다. 고객 차원을 열로 옮기는 조작에서 서버 요청이 0건인 것을 확인했습니다. 그래서 축을 바꿔도 합계가 달라지지 않습니다.

행과 열에 몇 개까지 놓을 수 있나요?

행은 3단계, 열은 2단계까지입니다. 열 조합이 36개를 넘으면 표를 그리지 않고 열 차원을 줄이라는 안내를 먼저 보여 줍니다. 행이 너무 많을 때도 같은 방식으로 필터를 걸라고 알려 줍니다.

조회 버튼은 어디에 있나요?

조회 조건 영역 오른쪽 끝에 있습니다. 입력 칸에서 Enter 를 눌러도 같고, 기본 레이아웃에 자동 조회를 지정하면 화면을 여는 즉시 조회됩니다.

사유는 어디에 저장되고 언제까지 남나요?

사유는 조회 범위와 행 경로에 묶여 서비스에 저장됩니다. 축을 바꿔도 같은 행에 붙어 있고 화면을 다시 열어도 남습니다. 샘플에서는 저장 뒤 새로 고쳐도 같은 행에 사유 아이콘이 보이는 것을 확인했습니다.

CSV 로 내려받으면 무엇이 담기나요?

현재 표를 그대로 내려받습니다. 행 경로와 선택한 항목이 열로 담기며 기준 대비를 켠 상태면 기준 · 차이도 함께 들어갑니다. 금액 단위는 화면과 같은 백만원입니다.

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

폭 390px에서 조회 조건 · 요약 · 표 · 차트가 한 열로 쌓이고 가로로 넘치지 않습니다. 차트는 표 아래로 내려가며 표는 가로로 밀어 봅니다. 열이 많은 분석은 넓은 화면이 편합니다.

분석 기능

AI 분석이 숫자를 만들어 내나요?

아닙니다. 금액과 비율은 서비스가 계산하고 AI 는 읽어서 설명합니다. 기본은 규칙 기반 해설이며 모델 연결은 서비스 설정으로 켭니다. 어느 방식으로 분석했는지는 창에 표시됩니다.

AI 에이전트는 누가 언제 실행하나요?

사용자가 ‘지금 실행’을 누르거나, 타이머를 켜 둔 화면이 열려 있는 동안 하루 한 번 실행합니다. 운영에서는 같은 규칙을 배치로 돌릴 수 있습니다. 같은 날 다시 실행하면 서비스가 하루 한 번 제한으로 건너뛰고 실행 기록에 남깁니다.

어떤 규칙이 기본으로 들어 있나요?

규칙 5개입니다. 제품 그룹별 순매출 계획 차이 금액 초과(CEO), 고객별 리베이트율 상한 초과(CFO), 고객별 미정산 잔액 임계 초과와 청구 후 90일이 지난 미정산 잔액 초과(정산 책임자), 수출 국가별 리베이트율 요인 손실 금액 초과(영업 책임자)입니다. 규칙마다 지표 · 기준값 · 받을 역할이 붙고 샘플 실행에서는 8건의 보고가 역할별 대기함에 올랐습니다.

PowerPoint 보고서는 어떻게 만들어지나요?

AI 분석 창의 보고서 버튼을 누르면 보고 있는 범위의 표와 차트를 브라우저에서 PowerPoint 파일로 만들어 내려받습니다. 외부 서비스에 올리지 않으며 샘플에서는 6장짜리 파일이 열렸습니다. 숫자는 화면과 같은 값입니다.

레이아웃은 몇 개까지 저장하나요?

이름을 붙여 여러 개 저장하고, 하나를 기본으로 지정하며, 자동 조회를 켤 수 있습니다. 저장 데이터가 깨져 읽을 수 없으면 안내 메시지를 띄우고 기본 배치로 엽니다.

도입과 운영

도입하면 어떤 효과가 있고 누가 쓰나요?

수출 영업 · 정산 · 회계 · 자금 담당이 같은 큐브의 숫자를 같은 기준으로 봅니다. 마감 전 점검과 차이 설명에 쓰는 엑셀 취합이 줄고, 회의에서 숫자 맞추기 대신 대응을 논의하게 됩니다. 시간 절감률 같은 수치는 회사마다 달라 이 글에서는 제시하지 않습니다.

적용 시기와 범위는 어떻게 되나요?

확인된 사실만 적습니다. 화면은 IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)의 변동대가와 환불부채 관점으로 충당과 정산 상태를 점검하도록 만든 분석 화면입니다. 시행일과 경과 규정은 이 글에서 다루지 않으며 회사와 감사인이 확인할 사항입니다.

표준 T-code 와 어떤 관계인가요?

표준 실행은 SAP 표준 T-code 가 담당하고 이 화면은 조회 · 검증 관점을 더해 확장합니다. 청구 문서(VF03), 고객 개별 항목(FBL5N), 수익성 분석(KE30) 등의 값을 같은 문서 · 필드에서 읽어 서로 맞춰 봅니다. 기존 표준 리포트를 없앨 필요는 없습니다.

데이터 원천과 정합성은 어떻게 보장하나요?

청구 · 판매 오더 · 납품 · 회계 전표의 표준 테이블에서 큐브와 원천 라인을 같은 원천으로 만듭니다. 화면은 큐브 합계와 원천 합계를 매번 대조하며, 어긋나면 ‘점검 필요’로 표시합니다. 약정 조건과 정산 원천은 도입 때 확정해야 하는 항목입니다.

운영 SAP 에 연결하려면 무엇이 필요한가요?

CDS 뷰와 분석 쿼리, 접근 제어, 서비스 정의를 전송하고 서비스를 게시한 뒤 화면의 서비스 주소를 바꿉니다. 그 전에 약정 조건 원천, 계정 매핑, 환율 기준 같은 정하는 일이 먼저입니다. 소요는 회사의 약정 구조와 전송 절차에 따라 달라 일정으로 단정하지 않습니다.

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

회사코드 조회 권한을 접근 제어 역할 한 곳에서 겁니다. 권한이 없으면 행이 돌아오지 않으므로 화면에서 따로 숨기지 않습니다. 에이전트 보고도 받을 역할별 대기함으로 나뉘어 있습니다.

대용량이면 느려지지 않나요?

수천만 건이면 합산을 데이터베이스에서 하고 청구월을 필수 범위로 둡니다. 원천 라인은 500줄씩 나눠 읽고, 열 조합과 행 수에는 상한이 있습니다. 응답 시간 기준은 도입 전에 정해 두세요.

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

유형과 계정 매핑은 매핑 테이블의 데이터이므로 행을 바꾸면 됩니다. 차원 추가는 큐브 뷰에 필드를 더하고 쿼리에 노출하는 일이며 화면은 서비스가 알려 주는 차원 목록을 읽어 칩을 만듭니다. 구조가 크게 바뀌면 대사식도 함께 점검합니다.

이 화면의 결과를 그대로 회계 처리나 세무 신고에 써도 되나요?

점검 도구이며 최종 판단은 회사와 감사인이 합니다. 세무 신고는 회사와 세무 대리인 · 관세사가 판단하며 법정 · 감사용 숫자는 표준 화면과 전표를 기준으로 합니다. 이 화면은 마감 전 점검과 차이 설명을 돕습니다.

수출 리베이트 정산 다차원 분석 — 충당 · 정산 · 계획 차이를 한 화면에서 따라가는 월마감

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

핵심 포인트 일곱 가지

사례로 보는 효과

도입하면 달라지는 것

이런 회사에 맞습니다

실행 화면

사용 방법

무엇으로 만들었나

1. 처음 열었을 때 — 조건 · 보드 · 피벗 틀

2. 경영 요약 — 역할마다 앞세우는 숫자가 다릅니다

3. 축 전환과 범위 — 다시 조회하지 않고 다르게 묶기

4. 칸에서 청구 라인까지 — 숫자의 근거 확인

5. 계산항목 — 총매출에서 정산률까지

6. 기준 대비 차이 — 같은 표가 검토 회의 자료가 됩니다

7. AI 분석과 보고서 — 숫자는 서비스가, 설명은 AI 가

8. AI 에이전트 — 사람이 열지 않아도 도는 점검

9. 레이아웃 저장과 복원 — 매달 같은 배치를 다시 만들지 않습니다

10. 좁은 화면과 한계

화면 뒤에서 일어나는 일

산출과 대사 흐름

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

파일 구성

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

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

T-code 별 연계 지점

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

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

요구사항 매핑표

CDS 구성

뷰 레이어 구성

① 리베이트 유형 매핑 테이블 — ZEXRB_TYPEMAP · ZR_ExportRebateTypeMap

② 청구 라인 기본 뷰 — ZI_ExportRebateBilling

③ 차원 뷰 — ZI_ExportRebateCustomer

④ 충당 · 정산 라인 — ZI_ExportRebateAccrual

⑤ 분석 큐브 — ZC_ExportRebateCube

⑥ 분석 쿼리 — ZC_ExportRebateQuery

⑦ 접근 제어 — ZA_ExportRebateAuth

⑧ 서비스 정의와 바인딩 — ZSD_ExportRebate

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

자주 묻는 질문

숫자와 산식

화면과 조작

분석 기능

도입과 운영