SAP 수입 3자 대조 차이 다차원 분석 — 발주 · 입고 · 송장 차이를 요인으로 가르고 B/L 라인까지 추적하는 수입 구매 대사

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

수입 담당자가 월 마감 전에 가장 자주 받는 질문은 “발주한 금액과 받은 금액과 청구받은 금액이 왜 다르냐”입니다. 구매 오더 화면에서 발주 조건을, 입고 화면에서 받은 수량을, 송장 화면에서 청구 내용을 각각 열어 볼 수는 있지만, 세 문서를 B/L 한 건씩 나란히 놓고 어느 단계에서 얼마가 어긋났는지를 한눈에 보여 주는 자리는 표준 화면 어디에도 따로 없습니다. 그래서 대개 엑셀에 세 자료를 붙여 넣고, 공급사별 · 플랜트별로 나누어 눈으로 대조합니다. 환율이 움직이거나 선적분과 입고분이 엇갈리는 달에는 이 작업이 마감 일정을 잡아먹습니다.

이 앱은 그 대조를 한 화면에 모았습니다. B/L 라인 4,126건을 차원 조합별 큐브로 묶어 공급사 · 원산지 · 플랜트 · 운송수단 같은 축으로 끌어다 놓고, 숫자를 누르면 원천 라인까지 내려가며, 예정(발주) 금액과 실적(송장) 금액의 차이를 입고 수량 · 초과 청구 · 단가 · 환율 · 청구 조정 · 발주 없음 여섯 요인으로 갈라 보여 줍니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 대상 영역은 수입 발주 · 입고 · 송장 3자 대조이며, 연결되는 기준서는 따로 없어 이 영역 이름으로 적습니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터(가상 회사의 2026년 4월~9월 송장분, B/L 라인 4,126건)에서 송장 금액은 92,271,984,981원, 발주 기준 예정 금액은 88,896,270,391원으로 총차이는 +3,375,714,590원(+3.8%)입니다. 총차이만 보면 “3.8% 더 청구됐다”에서 멈추지만, 여섯 요인으로 가르면 모습이 달라집니다(단위 백만원).

입고가 모자란 만큼 금액이 줄었는데도 총차이가 늘어난 것은, 받지 않은 수량에 대한 청구(초과 청구 +5,555.3)와 발주 없는 청구(+2,429.4)가 그보다 컸기 때문입니다. 어느 요인부터 담당자에게 확인해야 하는지가 숫자로 좁혀집니다. 이 사례의 숫자는 어디까지나 가정값으로 만든 검증용 자료의 결과이며, 실제 회사의 효과를 약속하는 수치가 아닙니다.

도입하면 달라지는 것

• 마감 전 대조 작업 — 세 문서를 엑셀에 붙여 키로 잇던 일이 사라지고, 차이가 큰 공급사부터 열어 보는 일로 바뀝니다.
• 회의의 주제 — “어느 숫자가 맞나”가 아니라 “이 초과 청구를 누구에게 확인할 것인가”를 이야기합니다.
• 다음 달로 이어지는 기록 — 차이 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 감시 — 화면을 여는 사람이 없어도 규칙에 걸린 공급사 · 플랜트가 대기함에 올라갑니다.
• 구매 · 물류 · 자금이 같은 숫자를 봄 — 역할에 따라 먼저 보이는 지표만 다를 뿐 같은 큐브에서 나옵니다.

이런 회사에 맞습니다

원자재나 부품을 해외 공급사에서 들여오며 결제 통화가 둘 이상이고, 선적(B/L)과 입고와 송장의 시점이 엇갈리는 일이 잦은 제조 · 유통 회사에 맞습니다. 수입 구매 담당, 물류 담당, 자금 담당, 그리고 월 마감에서 매입 채무 차이를 설명해야 하는 경영지원 조직이 같은 화면을 보는 구성을 가정했습니다. 수입 비중이 작거나 발주 · 입고 · 송장이 한 번에 맞아떨어지는 거래가 대부분이라면 표준 화면만으로도 충분할 수 있습니다.

실행 화면

실제로 돌아가는 화면 26종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다. 모든 공급사 이름 · B/L 번호 · 환율 · 단가는 가정값입니다.

사용 방법

1. 조회조건 입력 — 회사코드(필수)와 시작 · 종료 송장월(필수)을 정합니다. 공급사 · 원산지 · 플랜트 같은 차원 값은 선택이며 비우면 전체입니다.
2. 조회 — 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 기본 레이아웃에 자동 조회를 지정했다면 열자마자 조회된 상태로 시작합니다.
3. 요약 확인 — 임원 요약에서 역할을 바꾸면 앞에 놓이는 지표가 바뀝니다. 다시 조회하지 않습니다.
4. 탭 · 축 이동 — 차원 칩을 행 축 · 열 축으로 끌어다 놓거나 칩의 화살표 버튼으로 옮깁니다. 표시 항목 · 금액 단위 · 비교 기준도 같은 줄에서 바꿉니다.
5. 칸 클릭 상세 — 숫자 칸을 누르면 그 금액을 만든 B/L 라인이 열립니다. 비교를 예정 대비 차이로 바꾸면 요인 워터폴을 볼 수 있습니다.
6. 내보내기 — 피벗과 원천 라인 목록은 CSV 로, AI 분석 창의 현재 범위 표와 차트는 PPTX 보고서로 내려받습니다.

무엇으로 만들었나

처음 열었을 때 — 틀이 먼저 보입니다

조회조건부터 피벗까지가 한 화면에 세로로 쌓입니다. 조회 전에도 틀이 먼저 서 있어서 무엇을 고르면 무엇이 채워지는지 미리 보입니다.

조회를 누르기 전에도 빈 화면을 주지 않습니다. 조건 영역 · 요약 · 분석 축 · 표 틀이 먼저 서 있어서, 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 필수 조건은 회사코드와 시작 · 종료 송장월 셋이고, 나머지 차원 값은 비우면 전체입니다.

경영 요약 — 자리마다 다른 화면

같은 큐브에서 나온 같은 숫자인데, 보는 사람의 자리에 따라 먼저 보여야 할 지표가 다릅니다. 요약은 역할을 갈아 끼울 수 있게 두었습니다.

같은 큐브에서 나온 같은 숫자라도 보는 사람의 자리에 따라 먼저 보여야 할 지표가 다릅니다. 역할 선택은 화면 안에서만 일어나므로 서버를 다시 부르지 않고, 고른 역할은 쪼개 보는 기본 차원도 함께 바꿉니다.

CFO 관점은 플랜트 기준입니다. 송장 금액 · 입고 금액(예정 단가) · 청구 초과 금액(7,091.0백만원) · 송장 단가가 앞에 오고, 플랜트별 초과 상위와 절감 상위가 이어집니다. 청구 초과 금액은 송장 금액에서 입고 금액(예정 단가)을 뺀 값으로, 점검 대상을 고르는 첫 기준입니다.

구매 책임자에게는 기준이 공급사로 바뀌고 청구율(송장 금액 ÷ 입고 금액)이 지표로 들어옵니다. 상위에 오른 공급사는 판정이 아니라 “확인 필요” 후보이며, 원인은 아래 요인 워터폴과 원천 라인에서 확인합니다.

축 전환과 범위 — 같은 표를 다른 각도로

차원 칩을 행 축 · 열 축으로 옮기면 표가 바로 다시 묶입니다. 큐브를 한 번 읽어 와 브라우저에서 다시 묶으므로 축을 몇 번 바꿔도 서버 부하가 늘지 않습니다.

대조 결과는 일치 · 단가 차이 · 입고 전 청구 · 청구 조정 · 입고 부족 · 입고 초과 · 발주 없는 청구 일곱 가지입니다. 공급사 한 곳을 펼치면 그 공급사의 차이가 어떤 종류인지가 월별로 나뉘어 보입니다. 숫자는 백만원 단위가 기본입니다.

칩은 드래그 앤 드롭으로도, 칩의 화살표 버튼으로도 옮길 수 있습니다. 행 축은 3단계, 열 축은 2단계까지 쌓입니다. 축을 바꾸는 동안 서비스는 다시 부르지 않습니다 — 큐브가 이미 브라우저에 있고, 축을 바꾸는 일은 그 칸들을 다시 묶는 일이기 때문입니다.

세 단계를 쌓으면 트리가 깊어지고 합계는 각 단계에서 그대로 유지됩니다. 어느 공급사의 어느 종류 차이가 어느 분기에 몰렸는지를 한 표에서 따라갑니다.

송장월을 행으로, 공급사를 열로 바꾸면 같은 숫자가 시간 흐름 중심의 표가 됩니다. 어느 쪽이 읽기 편한지는 질문에 따라 다르므로 바꾸는 비용을 없앴습니다.

접힌 트리를 한 번에 펼치면 가장 아래 단계까지 숫자가 보입니다. 표 아래의 표시 행 수와 원천 라인 읽는 단위로 한 번에 다루는 양을 조절하고, 그 아래 검산 영역에서 큐브 합계와 원천 라인 합계를 비교할 수 있습니다.

차트는 외부 라이브러리 없이 SVG 로 그립니다. 같은 큐브 값을 쓰므로 표와 차트의 숫자가 어긋날 수 없고, 위의 “요인 워터폴” 탭과 CSV 버튼으로 보기를 바꾸거나 내려받습니다. 표 위에는 “검산: 요인 합 − 총차이 = 0원”이 함께 표시됩니다.

칸에서 B/L 까지 — 숫자를 의심할 때

집계 표의 숫자를 믿으려면 그 숫자를 만든 원천이 보여야 합니다. 칸을 누르면 그 금액을 만든 B/L 라인이 열리고 합계가 맞는지 검산됩니다.

맨 위에 칸의 값과 읽은 라인의 합이 같은지 표시됩니다(“같습니다”). 라인에는 B/L 번호 · 발주 · 입고 · 송장 번호와 수량 · 단가 · 환율이 한 줄에 놓여 문서를 거슬러 올라가기 쉽습니다. 두 값이 다르면 머리에 불일치로 표시됩니다.

예정 대비 차이 — 같은 표가 대조 리포트가 된다

비교 기준만 바꾸면 같은 표가 예정(발주) 대비 차이 리포트가 됩니다. 총차이는 워터폴로 여섯 요인에 나뉘고, 차이가 난 행에는 사유를 남길 수 있습니다.

비교는 실적만 · 예정 대비 차이 등으로 바꿉니다. 바꾸면 같은 표의 칸마다 예정과의 차이와 증감률이 붙고, 오른쪽 차트는 요인 워터폴로 바뀝니다.

막대 하나가 요인 하나입니다. 입고 수량 −6,144.7, 초과 청구 +5,555.3, 단가 +222.5, 환율 +1,274.1, 청구 조정 +39.2, 발주 없음 +2,429.4(백만원). 맨 아래 검산 줄이 “요인 합 − 총차이 = 0원”을 매번 보여 줍니다.

송장 금액이 늘어난 방향이면 붉게, 줄어든 방향이면 초록으로 표시합니다. 금액과 비율 중 하나만 넘으면 색을 입히지 않아 사소한 차이로 화면이 붉어지지 않습니다. 임계는 화면에서 조정합니다.

환율 · 단가 · 청구 조정 같은 원인을 고르고 메모를 남깁니다. 사유의 키는 축 배치가 아니라 조회 범위와 행 경로이므로, 축을 바꾸거나 트리를 다시 펼쳐도 같은 행이면 사유가 따라옵니다.

저장한 사유는 서비스에 기록되어 화면을 새로 고쳐도 남습니다. 사유가 없는 점검 대상 행은 AI 분석에서 “사유 필요”로 따로 표시됩니다.

AI 분석과 보고서

AI 분석은 숫자를 만들지 않습니다. 서비스가 계산한 값을 읽어 문장으로 옮기고, 읽은 내용을 표와 차트가 담긴 보고서로 내려받게 합니다.

금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고, 문장은 그 숫자를 읽어 옮깁니다. 그래서 모델 연결을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다. 결과는 표와 차트를 담은 PPTX 보고서로 내려받을 수 있습니다.

AI 에이전트 — 사람이 열지 않아도

감시 규칙을 주기마다 돌려 걸린 건을 받을 사람의 눈으로 다시 적어 대기함에 올립니다.

미입고 청구 수량 비율 · 환율 영향 · 플랜트 송장 초과 · 단가 요인 · 운송수단별 미착 금액 다섯 가지입니다. 규칙마다 받을 사람(구매 · 자금 · CFO · 물류)이 붙어 있고, 임계값은 화면에서 고칩니다.

실행하면 걸린 공급사 · 플랜트가 보고로 올라옵니다. 보고에는 어떤 규칙에 어떤 숫자로 걸렸는지와 근거가 함께 적힙니다. 판단과 기록은 화면이 아니라 서비스에 있습니다.

하루 한 번 제한을 서버 기록이 판정하므로 화면을 여러 번 열어도 같은 보고가 쌓이지 않습니다. 누가 언제 실행했는지가 기록에 남습니다.

레이아웃 저장과 복원

짜 둔 축은 이름을 붙여 저장해 두면 다음에 열 때 그 배치로 시작합니다.

기본 레이아웃으로 지정하면 다음에 열 때 그 배치로 시작합니다. “열 때 자동 조회”를 함께 지정하면 열자마자 조회까지 끝낸 상태로 시작합니다.

역할별로 자주 쓰는 배치를 이름으로 남겨 두고 불러 씁니다. 저장은 서비스에 기록됩니다.

기본 레이아웃에 자동 조회를 지정해 둔 경우의 모습입니다. 지정하지 않으면 조회 버튼을 누를 때까지 틀만 보입니다.

좁은 화면과 한계

휴대폰에서도 같은 리포트를 보고, 한 화면에 그릴 수 있는 범위에는 상한이 있습니다.

창이 좁아지면 차트를 감추지 않고 표 아래로 내려 같은 리포트를 봅니다. 가로 스크롤 없이 조건 · 요약 · 표가 위에서 아래로 이어집니다.

좁은 화면에서도 같은 피벗과 같은 숫자를 봅니다. 칸을 누르면 원천 라인이 열리는 동작도 그대로입니다.

열 축을 잘못 잡아 열이 42개가 되면 “열이 42개라 앞의 36개만 보여 줍니다”라고 안내합니다. 화면이 멈추거나 조용히 잘리는 일을 막기 위한 상한이며, 행 축을 줄이거나 필터로 범위를 좁히면 해소됩니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스에서 큐브(차원 조합별 합계)와 예정(발주) 값을 한 번 읽어 옵니다. 이후 축을 바꾸는 일은 모두 브라우저가 그 값을 다시 묶는 일이라 서버를 부르지 않습니다. 칸을 눌렀을 때만 그 칸의 조건으로 원천 라인을 읽어 오고, 요인분해 · AI 해설 · 에이전트 실행은 서비스 함수로 계산합니다.

금액 계산 — 라인에서 한 칸까지

대조 결과 일곱 가지 — 판정 조건 · 결과 상태 · 사용자 조치

요인분해 — 합이 총차이와 같다

라인마다 발주 조건에서 송장 조건으로 한 가지씩 바꿔 가며 같은 식을 다시 계산합니다. 순서는 입고 수량 → 초과 청구 → 단가 → 환율 → 청구 조정이고, 발주가 없는 라인은 송장 금액 전체를 “발주 없음” 요인에 넣습니다. 한 번에 한 요인만 바꾸므로 교차항이 남지 않고, 여섯 요인의 합은 총차이와 어긋나지 않습니다. 화면은 워터폴 맨 아래에 “요인 합 − 총차이 = 0원”을 매번 보여 줍니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 차트를 감추지 않고 표 아래로 내려 같은 리포트를 보여 줍니다. 가로 스크롤 없이 조건 · 요약 · 표가 위에서 아래로 이어지고, 칸 클릭 · 사유 · 에이전트 같은 동작은 그대로입니다. 한 화면에 그릴 수 있는 열 수에는 상한이 있어(36개), 넘으면 이유와 함께 앞부분만 보여 줍니다.

파일 구성

index.html · Component.js · manifest.json · readme.html
controller/   화면 제어 (Main · Base)
view/         화면 정의 (Main + 대화상자 조각 다섯 개)
model/        큐브 재집계 · SVG 차트 · 레이아웃 · 서식 · 보고서 생성 · 오류 처리
i18n/         문구
css/          스타일
media/        소개 영상
odata/        서비스 구성 파일과 샘플 데이터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준을 대체하지 않고, 표준이 이미 잘하는 일은 표준에 두며 끊기는 자리만 이어 붙입니다.

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

T-code 별 연계 지점

운영으로 옮길 때 기존 표준 조회나 리포트를 없애야 하느냐는 질문을 자주 받습니다. 답은 “없애지 않는다”입니다. 회계 전표 확인과 법정 · 감사 · 세무 신고 대응은 계속 표준 전표 기준으로 하고(세무 신고는 회사와 세무 대리인 · 관세사), 이 화면은 마감 전에 차이를 찾고 설명을 준비하는 점검 도구로 함께 둡니다.

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

이 화면의 큐브 · 쿼리 구성은 S/4HANA 의 CDS 분석 쿼리와 같은 방식(차원 · 측정값 · 쿼리 계층)으로 짜여 있어, 운영에서는 같은 구조를 CDS 로 올려 Fiori 분석 화면이나 Analysis for Office 에서 읽는 선택지도 열려 있습니다. 어떤 표준 분석 앱이 이 대조를 이미 제공하는지는 사용 중인 릴리스에 따라 다르므로 확인 필요로 두고, 이 글에서는 앱 이름을 단정하지 않습니다. 이 화면이 더하는 것은 B/L 단위 대조와 요인분해, 사유 기록, 감시라는 한 묶음의 흐름입니다.

분석 지표 정의표

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

CDS 구성 — 최대한 자세히

뷰 레이어 구성

운영 데이터에 연결할 때의 구성입니다. 아래 코드는 구조를 보이는 스케치이며, 실제 필드 · 테이블 연결과 B/L 정보의 원천은 시스템에서 확인이 필요합니다.

① 매핑 테이블 — 조건 유형과 인코텀즈를 데이터로 둔다

고객사마다 어떤 조건 유형이 청구 조정이고 어떤 인코텀즈가 해상 · 항공인지 다릅니다. 이를 코드에 박으면 고객마다 고쳐야 하므로 작은 매핑 테이블로 뺍니다. 운영에서 가장 먼저 채울 데이터입니다.

" ─── ZIMP_TM_COND ─────────────────────────────────────────
" 역할 : 조건 유형 → 청구 조정 구분 / 인코텀즈 → 운송 구분 매핑
" 이유 : 정책이 고객사마다 달라 코드가 아니라 데이터로 둔다
@EndUserText.label : '수입 3자 대조 조건 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_tm_cond {
  key client    : abap.clnt not null;
  key map_type  : abap.char(1) not null;   " C = 조건 유형, I = 인코텀즈
  key map_key   : abap.char(4) not null;   " 조건 유형 코드 또는 인코텀즈
  map_value     : abap.char(10);           " ADJ / SEA / AIR 등
  note          : abap.char(60);
}

② 원천 라인 뷰 — 세 문서를 B/L 라인 단위로 잇고 요인을 계산한다

입고 수량은 구매 오더 이력(EKBE)에서 합산하고 송장은 송장 품목에서 읽어 한 줄로 잇습니다. 요인 컬럼은 발주 조건에서 송장 조건으로 한 가지씩 바꿔 가며 계산하므로 여섯 요인의 합이 송장 금액 − 예정 금액과 같습니다. B/L 정보는 표준 구매 데이터에 없어 별도 원천(여기서는 가상의 정보 테이블)을 가정했습니다.

" ─── ZI_ImpTriMatchLine ───────────────────────────────────
" 역할 : 발주 · 입고 · 송장을 B/L 라인 단위로 잇고 요인 컬럼을 계산
" 이유 : 계산을 한 층에 모아야 큐브와 쿼리가 같은 숫자를 읽는다
" 주의 : B/L 정보 원천(zimp_bl_info)과 입고 · 송장 연결 키는 확인 필요
@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '수입 3자 대조 라인'
define view entity ZI_ImpTriMatchLine
  as select from zimp_bl_info as bl
    left outer join ekpo as po on  po.ebeln = bl.ebeln and po.ebelp = bl.ebelp
    left outer join ZI_ImpGrSum as gr on gr.ebeln = bl.ebeln and gr.ebelp = bl.ebelp
    left outer join ZI_ImpIvSum as iv on iv.ebeln = bl.ebeln and iv.ebelp = bl.ebelp
{
  key bl.bl_no                              as BlNo,
  key bl.item_no                            as ItemNo,
      bl.ebeln                              as PurchaseOrder,
      iv.lifnr                              as Supplier,
      po.werks                              as Plant,
      iv.waers                              as Currency,
      iv.budat_ym                           as InvoiceMonth,
      po.menge * po.netpr * po.wkurs        as PoAmount,
      gr.menge * po.netpr * po.wkurs        as GrAmount,
      iv.menge * iv.price * iv.kursf + iv.adj_amt as IvAmount,
      case when po.ebeln is null then 'NOPO'
           when iv.menge > gr.menge and iv.price = po.netpr then 'SHORT'
           when iv.price <> po.netpr then 'PRICE'
           when iv.adj_amt <> 0 then 'ADJ'
           else 'MATCH' end                 as DiffType,
      " 요인: 입고 수량 → 초과 청구 → 단가 → 환율 → 청구 조정 → 발주 없음
      gr.menge * po.netpr * po.wkurs - po.menge * po.netpr * po.wkurs                as FactQtyR,
      (iv.menge - gr.menge) * po.netpr * po.wkurs                                    as FactUnbill,
      iv.menge * (iv.price - po.netpr) * po.wkurs                                    as FactPrice,
      iv.menge * iv.price * (iv.kursf - po.wkurs)                                    as FactFx,
      iv.adj_amt                                                                     as FactAdj
}

③ 차원 뷰 — 이름은 연관으로 읽는다

큐브에 이름 컬럼을 복제하지 않고, 차원 뷰를 만들어 연관(association)으로 읽습니다. 공급사 · 플랜트 · 구매그룹이 각각 하나씩 생기며 아래는 공급사 예입니다. 표준 마스터 뷰의 필드명은 릴리스에 따라 다르므로 확인 필요입니다.

" ─── ZI_ImpSupplierDim ────────────────────────────────────
" 역할 : 공급사 차원 (코드 · 이름)
" 이유 : 큐브에는 코드만 두고 이름은 이 뷰의 연관으로 읽는다
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'Supplier'
@EndUserText.label: '공급사 차원'
define view entity ZI_ImpSupplierDim
  as select from I_Supplier
{
  @ObjectModel.text.element: ['SupplierName']
  key Supplier,
      @Semantics.text: true
      SupplierName
}

④ 큐브 뷰 — 차원 조합별로 합한다

화면의 피벗이 읽는 층입니다. 측정값은 합계로 집계하고 금액에는 통화 의미를 붙입니다. 결제 통화가 여럿이므로 원화 환산 금액을 라인 층에서 이미 계산해 두고 여기서는 합만 합니다.

" ─── ZI_ImpTriMatchCube ───────────────────────────────────
" 역할 : 차원 조합별 측정값 합계 (피벗의 원천)
" 이유 : 집계를 서비스가 아니라 큐브에서 해야 합계가 한 곳에서 정해진다
@Analytics.dataCategory: #CUBE
@EndUserText.label: '수입 3자 대조 큐브'
define view entity ZI_ImpTriMatchCube
  as select from ZI_ImpTriMatchLine
  association [0..1] to ZI_ImpSupplierDim as _Supplier on $projection.Supplier = _Supplier.Supplier
{
  key InvoiceMonth, key Supplier, key Plant, key Currency, key DiffType,
      @Semantics.currencyCode: true
      cast('KRW' as abap.cuky)                         as LocalCurrency,
      @DefaultAggregation: #SUM @Semantics.amount.currencyCode: 'LocalCurrency'
      sum(IvAmount)                                    as InvoiceAmount,
      @DefaultAggregation: #SUM @Semantics.amount.currencyCode: 'LocalCurrency'
      sum(GrAmount)                                    as GrAmountAtPoPrice,
      @DefaultAggregation: #SUM @Semantics.amount.currencyCode: 'LocalCurrency'
      sum(PoAmount)                                    as PlannedAmount,
      @DefaultAggregation: #SUM @Semantics.amount.currencyCode: 'LocalCurrency'
      sum(FactFx)                                      as FxFactor,
      _Supplier
}
group by InvoiceMonth, Supplier, Plant, Currency, DiffType

⑤ 분석 쿼리 — 화면이 필요한 모양

조회조건과 축 배치를 쿼리에서 정의합니다. 화면은 이 쿼리를 읽는 서비스 하나만 바라봅니다. 필수 조건은 회사코드와 송장월 범위입니다.

" ─── ZC_ImpTriMatchQuery ──────────────────────────────────
" 역할 : 조회조건 · 축 배치 · 필터를 정의하는 소비 층
" 이유 : 화면과 큐브 사이에 계약 층을 둬야 큐브가 바뀌어도 화면이 안 바뀐다
@Analytics.query: true
@EndUserText.label: '수입 3자 대조 분석'
define view entity ZC_ImpTriMatchQuery
  as select from ZI_ImpTriMatchCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #RANGE, multipleSelections: true }
  Supplier,
  @AnalyticsDetails.query.axis: #ROWS
  DiffType,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter: { mandatory: true, selectionType: #INTERVAL }
  InvoiceMonth,
  @AnalyticsDetails.query.axis: #COLUMNS
  InvoiceAmount,
  PlannedAmount
}

⑥ DCL — 집계 단계에서 권한을 건다

드릴스루에만 권한을 걸면 합계에서 뺄셈으로 남의 숫자가 새어 나갑니다. 큐브 층에 걸어 집계 자체가 권한 범위로 제한되게 합니다. 사용하는 권한 오브젝트와 필드는 회사 권한 설계와 맞춰 확인 필요입니다.

" ─── DCL ZI_ImpTriMatchCube ───────────────────────────────
" 역할 : 플랜트 · 구매그룹 기준 접근 제한
" 이유 : 합계에서 남의 숫자가 새지 않도록 집계 층에서 건다
@EndUserText.label: '수입 3자 대조 권한'
@MappingRole: true
define role ZI_ImpTriMatchCube {
  grant select on ZI_ImpTriMatchCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑦ 서비스 정의 · 바인딩 — 화면이 읽는 문

쿼리를 서비스로 노출하고 OData V2 UI 서비스로 바인딩합니다. 활성화는 서비스 관리 화면(/IWFND/MAINT_SERVICE) 또는 바인딩 게시로 하며, 화면의 manifest 서비스 주소만 이 주소로 바꾸면 연결됩니다.

" ─── Service Definition ───────────────────────────────────
@EndUserText.label: '수입 3자 대조 서비스'
define service ZUI_ImpTriMatch {
  expose ZC_ImpTriMatchQuery as TriMatch;
  expose ZI_ImpSupplierDim   as Supplier;
}
" Service Binding : ZUI_ImpTriMatch_V2 (OData V2 - UI)

⑧ 요인 합 검산 쿼리 — 합이 총차이와 같은지 매번 본다

요인 합과 총차이의 차이를 집계하는 검산용 쿼리입니다. 0 이 아니면 라인 층의 계산식 또는 입력 데이터에 문제가 있다는 신호이므로 대사 체계에 포함합니다.

" ─── ZC_ImpTriMatchCheck ──────────────────────────────────
" 역할 : 요인 합 - (송장 금액 - 예정 금액) 검산
" 이유 : 요인분해가 틀리면 어느 숫자도 믿을 수 없다
@EndUserText.label: '요인 합 검산'
define view entity ZC_ImpTriMatchCheck
  as select from ZI_ImpTriMatchLine
{
  key InvoiceMonth,
      sum(IvAmount) - sum(PoAmount)                                              as TotalGap,
      sum(FactQtyR) + sum(FactUnbill) + sum(FactPrice) + sum(FactFx) + sum(FactAdj) as FactorSum
}
group by InvoiceMonth
" 발주 없는 라인은 별도 요인(NOPO)으로 합산 - 라인 층에서 분기 필요

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영 데이터에 연결할 때 먼저 정해야 하는 항목입니다.

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

검증용 샘플 데이터 전수로 대사식을 돌린 결과입니다. 도입 포인트의 사례(총차이 +3,375.7백만원, 요인 합 차이 0원)와 같은 숫자입니다.

의도적 예외: 발주가 없는 라인 106건(송장 금액 2,429,417,612원)은 “발주 없음” 요인으로 분리했으며 위 차이 건수와 별개입니다. 이 검증은 가정값으로 만든 샘플 자료에서의 결과이고, 실제 운영 자료의 대사는 연결 후 같은 식으로 다시 돌려야 합니다.

운영 데이터로 갈 때

B/L 라인이 수십만~수백만 건이 되면 큐브를 화면에서 한 번에 읽는 방식에는 상한이 필요합니다. 집계는 큐브 뷰(DB 층)에서 하고 화면은 집계 결과만 읽도록 두며, 조회조건의 회사코드와 기간은 필수로 유지하고, 원천 라인은 칸을 눌렀을 때 그 칸의 조건으로만 읽습니다. 응답 시간 기준(예: 조회 몇 초 이내)은 시스템 규모와 함께 정하며 이 글에서는 수치를 약속하지 않습니다. 화면에 둔 열 수 상한과 표시 행 수 · 원천 라인 읽는 단위가 그 안전장치입니다.

자주 묻는 질문

도입 상담과 데모에서 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영