외화 매출채권 회수·환율 영향 다차원 분석 — 예정 대비 순회수액 차이를 요인으로 가르는 수출 채권 관리

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

수출 채권 회의의 질문은 매월 같습니다. 예정 대비 얼마나 덜 걷혔나, 왜 덜 걷혔나, 누가 무엇을 챙겨야 하나. 지금 이 세 답은 표준 조회 화면 · 밤새 만든 엑셀 · 회의 메모로 흩어져 있습니다. 이 앱은 세 답을 한 화면에 붙여, 회수 현황을 만드는 손일을 줄이고 “어느 숫자가 맞나” 하는 회의를 없앱니다.

핵심 포인트 여덟 가지

총차이 30,642백만원의 몫 — 환율이 아니라 청구 규모와 회수 지연

예정 순회수액 493,849백만원 대비 실적 463,208백만원으로 30,642백만원이 모자랐다는 사실까지는 표준 리포트도 말해 줍니다. 다섯 요인으로 가르면 청구 규모 −23,482 · 회수율(지연) −23,782 · 환율 +3,811 · 환가료·수수료 +41 · 미계획 +12,771(백만원)이며, 환율은 오히려 도움이 됐습니다. 금액만 보았다면 “환율 때문에 덜 걷혔다”로 끝났을 회의가, 어느 고객의 청구가 얼마나 늦게 걷히는지를 정하는 회의로 바뀝니다.

검산 조건 — 다섯 요인의 합은 총차이와 어긋나지 않아야 하며 화면이 매번 그 등식을 보여 줍니다. 예정 행이 없는 조합은 억지로 나누지 않고 미계획으로 따로 세웁니다. 반올림 때문에 표시 합계가 1 차이 날 수 있습니다.

도입하면 달라지는 것

• 마감 보고 준비 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나" 보다 "어느 고객 · 통화부터 챙길 것인가" 를 이야기합니다.
• 다음 기간으로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 감시 — 화면을 열지 않아도 규칙에 걸린 항목이 대기함에 올라옵니다.

이런 회사에 맞습니다

• S/4HANA 를 쓰면서 수출 채권 회수와 환율 영향을 엑셀로 맞추고 있는 회사.
• USD · EUR · JPY · CNY 등 여러 통화로 청구하고 L/C · D/A · D/P · T/T 를 섞어 쓰는 수출 비중이 큰 회사.
• AI 를 쓰고 싶지만 숫자의 출처를 통제해야 하는 영업관리 · 자금 · 채권 조직.

여섯 가지 기능과, 그것이 없을 때 생기는 일

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

리포트에서 가장 비싼 질문은 "이 숫자 맞아?" 입니다. 만드는 쪽에서 먼저 대사식을 세워 전수로 돌린 결과입니다.

대사식 6종 전부 차이 0. 화면 쪽은 따로 자동화로 돌려 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 문서 합계가 같은지를 다시 잽니다.

도입 후 쓰는 순서

1. 회사코드와 청구월 범위를 고르고 조회를 누릅니다. 필요하면 고객 · 통화 · 회수 방식 같은 차원 값을 여러 개 골라 범위를 좁힙니다.
2. 레이아웃 보드에서 차원을 행 축 · 열 축으로 끌어다 놓습니다. 행 축은 3단계, 열 축은 2단계까지 쌓입니다.
3. 궁금한 칸을 누르면 그 금액을 만든 청구 문서 라인이 열립니다. 칸 값과 원천 합계가 같은지 머리에 바로 보입니다.
4. 비교 기준을 예정 대비로 켜면 같은 표가 차이 리포트가 됩니다. 차이가 난 행에는 사유를 적어 둡니다.
5. 차이 분해 탭에서 그 차이가 왜 생겼는지를 다섯 요인으로 봅니다.
6. 짜 둔 축은 이름을 붙여 저장해 둡니다. 기본 레이아웃으로 지정하면 다음에 열 때 그 배치로 시작합니다.

실행 화면

실제로 돌아가는 화면 28종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

사용 방법

1. 조회조건 — 회사코드 · 시작 청구월 · 종료 청구월을 확인합니다. 기본은 전체 기간이고, 예정 기준은 고정으로 표시됩니다.
2. 조회 — 오른쪽 위 파란 조회 버튼을 누르거나 입력란에서 Enter 키를 누릅니다. 조회 전에도 레이아웃 보드와 빈 피벗 틀이 보입니다.
3. 역할별 요약 — 청구액 · 순회수액 · 회수율 · 외환차손익과 예정 대비 값을 봅니다. 역할(CFO · 영업 · 자금 · 채권)을 바꾸면 앞세우는 지표가 바뀝니다.
4. 축 바꾸기 — 차원 칩을 눌러 행 · 열 · 사용 안 함으로 옮기거나 끌어다 놓습니다. 서비스를 다시 부르지 않습니다.
5. 칸 · 행 누르기 — 칸은 원천 청구 문서 라인을 열고, 행 이름은 차트와 요인분해를 그 행 기준으로 바꿉니다.
6. 내려받기와 저장 — 현재 피벗은 CSV 로(변동 사유 포함), 축 구성은 이름을 붙인 레이아웃으로 남깁니다.

무엇으로 만들었나

처음 열었을 때 — 틀이 먼저, 값은 조회 뒤에

조회를 누르기 전에도 조회조건 · 레이아웃 보드 · 피벗 틀이 서 있고, 조회하면 같은 자리에 값과 차트가 채워집니다.

조회 전에도 빈 화면을 주지 않습니다. 조회조건 · 레이아웃 보드 · 피벗 틀이 먼저 서 있고 값만 비어 있어서 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 기간은 2026-01 ~ 2026-09, 회사코드는 1000 이 기본입니다.

조회하면 청구 라인 9,026줄이 큐브 1,070행으로 묶여 들어옵니다. 위쪽 역할별 요약에는 청구액 606,522백만원과 순회수액 463,208백만원, 회수율 76.0% 가 보이고 예정 대비 값이 작게 붙습니다. 행을 펼치면 하위 차원으로 내려가고 차트도 함께 바뀝니다.

고객을 행 축으로, 청구 통화를 열 축으로 옮긴 모습입니다. 이때 서비스를 다시 부르지 않고 브라우저가 들고 있는 큐브를 다시 묶으므로 총합 463,208 은 그대로이고 네트워크 요청은 0건입니다. 열에 올린 차원이 있으면 첫 분석 항목만 열에 펼쳐 보입니다.

표를 넓게 보고 싶을 때 머리 영역을 접습니다. 접은 상태에서도 기간 · 분석 항목 · 건수가 한 줄로 남아 지금 무엇을 보고 있는지 잃지 않습니다.

경영 요약 — 역할을 바꾸면 앞세우는 지표가 바뀐다

같은 큐브를 역할 네 가지의 눈으로 봅니다. 역할을 바꿔도 다시 조회하지 않습니다.

청구액 · 순회수액 · 회수율 · 외환차손익 네 지표가 앞에 오고 행 축은 도착 권역 › 도착 국가입니다. 작은 글씨로 예정 값과 대비율이 붙어 한 줄로 달성 여부를 읽습니다.

행 축이 고객으로 바뀌고 미회수 잔액이 앞으로 옵니다. 국가가 같아도 고객별로 회수 속도가 다르다는 점이 바로 드러납니다.

행 축이 청구 통화 › 회수 방식입니다. 외환차손익과 환가료·수수료율이 앞에 와서 어느 통화와 방식에서 비용이 큰지 확인합니다.

결제 조건 30 · 60 · 90일별로 미회수 비중이 어떻게 다른지, 가중 회수일수가 몇 일인지를 봅니다. 연체 관리의 출발점이 되는 화면입니다.

축 전환과 범위 — 열 두 단계, 다중 선택, 차트 너비

축은 보는 사람이 바꾸고 범위는 차원 값을 여러 개 골라 좁힙니다.

청구 통화에 이어 회수 방식을 열로 올려 통화 × 방식의 교차표를 만듭니다. 열 조합 수가 상한을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 뜹니다.

도착 국가를 눌러 중국 · 일본 · 싱가포르처럼 여러 개를 고릅니다. 큐브에 있는 값만 올라오고 차원 안에서는 or, 차원 사이에서는 and 로 묶입니다.

필터 버튼에 선택 개수가 붙고 요약 지표와 표와 차트가 모두 좁혀진 범위로 바뀝니다. 서비스를 다시 부르지 않고 같은 큐브를 걸러 쓰기 때문입니다.

표가 넓을 때는 차트를 줄이고 차트를 크게 볼 때는 표를 줄입니다. 값은 브라우저에만 남으므로 다른 사람 화면에는 영향이 없습니다.

칸에서 원천 청구 문서까지

숫자를 의심할 때 다른 화면을 열지 않도록, 칸에서 곧바로 문서 라인으로 내려갑니다.

전체 합계의 순회수액 칸을 누르면 원천 청구 라인 9,026줄 중 첫 500행이 열리고 "셀 값 463,208 = 원천 합계 463,208 일치" 가 적힙니다. 라인에는 청구 문서 · 전기일 · 만기일 · 회수일 · 선하증권 · 고객 · 회수 방식 · 결제 조건 · 인코텀즈 · 통화 · 청구액(외화) · 인식 환율이 있습니다. 더 보기로 이어 읽습니다.

서비스가 원천 라인을 청구월별로 합산한 값입니다. 7월 이후 회수율이 급격히 낮은 것은 결제 조건 때문에 기준일 현재 아직 회수 전인 청구가 많기 때문이며, 9월분은 전부 미회수입니다.

계산항목 — 전기되지 않는 단계를 행으로

회수분 인식액 · 순회수액 · 회수율 같은 단계는 원장에 전기되지 않습니다. 식으로 정의해 계산항목으로 둡니다.

순회수액 = 회수액 − 환가료·수수료, 회수율 = (청구 − 미회수) ÷ 청구처럼 서비스가 식을 풀어 줍니다. 비율 계산항목은 합계 행에서도 분자 · 분모를 먼저 합산한 뒤 나누어 평균의 평균 오류를 피합니다.

기준 대비 차이 — 차이 모드, 변동 사유, 워터폴, 요인분해

예정 대비를 켜면 같은 표가 차이 리포트가 됩니다.

색은 숫자의 크기가 아니라 순회수액에 준 영향 방향으로 칠하며, 금액과 비율을 둘 다 넘을 때만 칠합니다. 외환차손익은 예정에 값이 없어 예정 0 으로 비교되므로 해석에 주의가 필요합니다.

환율 · 지연 · 물량 · 수수료 · 분쟁 · 기타 중에서 고르고 내용을 적습니다. 키가 축 배치가 아니라 범위와 행 경로이므로 축을 바꾸거나 다음 기간에도 같은 행에 따라옵니다. CSV 와 AI 근거에도 실립니다.

청구 규모 −23,482 · 회수율(지연) −23,782 · 환율 +3,811 · 환가료·수수료 +41 · 미계획 +12,771 로 가르고 맨 아래 검산 줄이 "요인 합계 −30,642 / 총차이 −30,642 (오차 0.00) ✓" 를 매번 적습니다.

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

AI 는 숫자를 만들지 않습니다. 서비스가 계산한 값을 읽어 설명합니다.

현재 범위의 요약과 핵심 발견 다섯 건이 나옵니다. 원인은 단정하지 않고 점검 필요 항목만 제시하며, 이미 사유가 적힌 차이는 건너뜁니다.

대상 · 실적 · 예정 · 차이 · 사유 열이 그대로 보여 해설이 어떤 숫자에서 나왔는지 확인합니다. API 키는 앱 · 설명서 · 블로그 어디에도 두지 않습니다.

현재 범위의 표지 · 요약 · 핵심 발견 · 기간별 표 · 차트 · 근거를 담은 6장짜리 .pptx 를 만듭니다. 파일은 PowerPoint 에서 열리는 것을 python-pptx 로 확인했습니다.

AI 에이전트 — 규칙, 대기함, 활동 기록

감시 규칙에 걸리면 받을 역할의 눈으로 보고를 대기함에 올립니다.

규칙마다 임계값 · 점검 주기 · 받을 역할 · 사용 여부가 있고 임계값은 화면에서 고칩니다. 판단과 기록은 화면이 아니라 서비스에 있습니다.

이 자료에서는 한 번 실행에 20건이 걸렸습니다. 각 보고에는 제목 · 본문 · 심각도 · 행 경로가 있고 역할 필터로 걸러 봅니다. 문구는 모두 "점검 필요" 수준입니다.

첫 실행은 20건, 두 번째는 "하루 1회 제한으로 건너뜀" 이며 둘 다 활동 기록에 시각 · 주체 · 결과 · 건수로 남습니다. 운영에서는 같은 호출을 배치가 대신 부릅니다.

레이아웃 저장과 복원

축 · 조회조건 · 측정값 · 표시 행 수 · 접힘 상태를 이름 붙여 저장합니다.

기본 + 자동 조회로 저장하면 다음에 열 때 조회된 채로 시작합니다. 저장 값은 서비스에 남아 새로 고침해도 다시 보입니다.

기본으로 지정한 레이아웃에는 별표가 붙습니다. 자주 쓰는 배치는 이름을 붙여 두고 회의 때 불러 씁니다.

좁은 화면과 한계

창이 좁으면 차트를 감추지 않고 표 아래로 내립니다.

휴대폰 폭에서도 같은 리포트를 봅니다. 표는 좌우로 밀고 차트는 아래에서 이어 봅니다.

열 축에 고객 · 결제 조건 · 회수 방식 같은 값이 많은 차원을 올리면 조합이 상한 36을 넘습니다. 이때는 반쯤 그린 표 대신 안내가 나오므로 필터로 범위를 먼저 좁힙니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 위의 화면들이 어떤 규칙으로 그렇게 움직이는지를 자리별로 적었습니다.

피벗이 만들어지는 다섯 단계

1. 큐브 받기 — 회사코드와 청구월 범위로 큐브 1,070행을 한 번 읽습니다. 조회할 때만 부릅니다.
2. 행 묶기 — 행 축 차원을 순서대로 적용해 트리를 만듭니다(최대 3단계).
3. 열 만들기 — 열 축 차원의 값 조합으로 열을 세웁니다(최대 2단계). 합계 열은 두지 않습니다. 표가 가로로 늘어나 차트 자리를 먹기 때문입니다.
4. 칸 채우기 — 행 묶음 × 열 조합마다 측정값을 더합니다. 합계 칸이 어긋날 수 없는 이유는 모든 칸이 같은 큐브 행에서 나오기 때문입니다.
5. 계산항목 붙이기 — 순회수액 · 회수율 · 외환차손익처럼 차원으로는 나오지 않는 값을 식으로 계산해 붙입니다. 계산항목은 7종입니다.

축을 바꿀 때와 칸에서 문서로 내려갈 때

축을 바꾸면 2단계부터 다시 돌 뿐 서비스를 다시 부르지 않습니다. 반면 칸을 눌러 청구 문서 라인으로 내려갈 때는 그 칸의 행 경로와 열 조합을 그대로 조회 조건으로 바꿔 서비스를 부르며, 한 번에 500행씩 끊어 읽습니다. 머리에는 건수와 합계가 적히고, 합계가 눌렀던 칸 값과 같아야 정상입니다.

차이 판정 규칙

모든 판정은 ‘점검 필요’ · ‘확인 필요’ 수준이며 원인을 단정하지 않습니다.

산출 · 대사식 순서

1. 순회수액 = 회수액(원화) − 환가료·수수료
2. 회수율(%) = (청구액 − 미회수 잔액) ÷ 청구액 × 100
3. 외환차손익 = 회수액(원화) − 회수 외화액 × 청구 인식 환율
4. 미회수 비중(%) = 미회수 잔액 ÷ 청구액 × 100 · 가중 회수일수 = Σ(회수일수 × 회수액) ÷ 회수액
5. 차이 요인 다섯 가지 — 청구 규모 · 회수율(지연) · 환율 · 환가료·수수료 · 미계획. 합이 총차이와 같은지 매번 검산합니다.

조회조건

결과 컬럼

칸을 눌러 내려간 청구 문서 라인에는 아래 컬럼이 나옵니다. 금액은 원화 기준이고 외화 금액은 청구 통화 그대로 보여 줍니다.

좁은 화면에서 달라지는 것

창이 좁으면 차트를 감추지 않고 표 아래로 내립니다. 조회조건은 한 줄씩 쌓이고 레이아웃 보드의 칩은 메뉴로 옮깁니다. 표가 가로로 넘치면 표 안에서만 밀려 보이고 페이지 전체는 밀리지 않습니다. 끌어다 놓기가 불편한 손가락 화면을 위해 모든 이동은 칩 메뉴로도 됩니다.

파일 구성

./
├─ index.html · Component.js · manifest.json · readme.html
├─ controller/ · view/ · model/ (큐브 묶기 · 차트 · 보고서)
├─ css/ · i18n/
├─ media/ (소개 영상 · 포스터 · 자막)
└─ odata/ (서비스 정의 · 계산 모듈 · 샘플 자료)

SAP 표준 기능 확장 포인트

이 앱은 표준을 대체하지 않고, 표준이 끊기는 자리만 이어 붙입니다. 먼저 표준만으로 되는 일과 되지 않는 일을 가릅니다.

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

T-code 별 연계 지점

표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 두고, 끊기는 자리만 이어 붙이는 쪽으로 구성했습니다.

표준 업무와 이 앱이 맞물리는 자리

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 앱은 그것들과 경쟁하기보다 같은 CDS 큐브를 읽는 또 하나의 화면으로 놓입니다. 큐브 뷰와 분석 쿼리를 운영에서 CDS 로 올리면 Analysis for Office 에서도 같은 숫자를 볼 수 있습니다.

다만 이 화면이 하는 일 — 축을 끌어다 놓는 피벗, 칸에서 문서까지의 드릴스루, 예정 대비 요인분해, 행에 남는 사유, 감시 에이전트 — 은 한 화면에 묶여 있다는 점이 다릅니다. 표준 분석 앱의 정확한 이름과 제공 범위는 릴리스마다 달라 확인 필요로 둡니다.

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

지표 정의

CDS 구성

운영 전환에서 화면이 읽을 CDS 뷰를 레이어별로 정리하고 코드를 공개합니다. 코드는 구조를 보이기 위한 스케치이며 필드 이름과 값은 고객 시스템 기준으로 확인이 필요합니다.

뷰 레이어 구성

① 예정 테이블 — 요인분해의 기준

예정 환율과 예정 회수 비율이 이 테이블에서 갈립니다. 요인분해의 기준이 되므로 운영 전환에서 가장 먼저 합의해야 합니다.

" ─────────────────────────────────────────────────────────────
" ZARFX_PLAN : 외화 매출채권 예정(회수 계획) 테이블
" 역할   : 청구월 × 고객 × 통화 × 방식 조합의 예정 청구 외화 · 회수 외화 · 예정 환율
" 나눈 이유: 예정은 전표에서 나오지 않는 유일한 자료이므로 원천을 따로 둔다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '외화 채권 예정'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zarfx_plan {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key version    : abap.char(8) not null;          " 예정 버전
  key period     : abap.char(7) not null;          " YYYY-MM
  key customer   : kunnr not null;
  key currency   : waers not null;
  key method     : abap.char(2) not null;          " LC · DA · DP · TT
  key terms      : abap.char(3) not null;          " 결제 조건 일수
  billed_fc      : abap.curr(15,2);
  collect_fc     : abap.curr(15,2);
  plan_rate      : abap.dec(9,4);                  " 예정 환율
  plan_fee_rate  : abap.dec(7,5);
}

② 차원 뷰 — 고객과 국가

고객 한 행에 국가와 권역 · 텍스트를 붙입니다. 값 도움말과 필터가 이 뷰를 보게 해 두면 큐브에서 join 을 한 번만 겁니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFxCustomer : 고객 차원
" 나눈 이유: 국가 · 권역 매핑을 큐브마다 반복하지 않는다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '고객 차원'
@ObjectModel.representativeKey : 'Customer'
@Analytics.dataCategory : #DIMENSION
define view entity ZI_ArFxCustomer
  as select from I_Customer as c
{
  @ObjectModel.text.element : ['CustomerName']
  key c.Customer,
      c.CustomerName,
      c.Country,
      " 권역은 국가 → 권역 매핑이 필요하다 (확인 필요 : 고객사 기준 매핑 테이블)
      case c.Country when 'US' then 'NA'
                     when 'DE' then 'EU' when 'NL' then 'EU'
                     else 'AS' end as Region
}

③ 항목 뷰 — 청구 라인과 정산

청구 품목 한 줄에 정산 정보를 붙이고 원화로 환산합니다. 이 뷰의 한 줄이 드릴스루가 여는 문서 라인입니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFxItem : 청구 라인 + 정산(회수) + 환산
" 확인 필요 : I_BillingDocumentItem · I_OperationalAcctgDocItem 의 필드명은
"            릴리스마다 다르므로 View Browser 로 실제 이름을 확인한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '외화 채권 항목'
define view entity ZI_ArFxItem
  as select from I_BillingDocumentItem as i
    inner join   I_BillingDocument     as h on h.BillingDocument = i.BillingDocument
    left outer join I_OperationalAcctgDocItem as a
                 on  a.CompanyCode  = h.CompanyCode
                 and a.ClearingAccountingDocument is not initial
                 and a.InvoiceReference = h.BillingDocument
{
  key i.BillingDocument,
  key i.BillingDocumentItem,
      h.CompanyCode,
      h.BillingDocumentDate                         as PostDate,
      h.SoldToParty                                 as Customer,
      i.TransactionCurrency                         as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      i.NetAmount                                   as BilledFc,
      a.ClearingDate                                as CollDate,
      @Semantics.amount.currencyCode : 'Currency'
      a.AmountInTransactionCurrency                 as CollectedFc
}

④ 실적 큐브 — 차원 조합으로 집계

화면이 브라우저에서 하던 묶음을 DB 로 내립니다. 환산은 항목 단위로 한 번 하고 합산합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFxActualCube : 청구월 × 고객 × 통화 × 방식 조합별 집계
" 나눈 이유: 합산은 DB 에서, 환산은 항목 단위로 — 평균의 평균 오류를 피한다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '외화 채권 큐브(실적)'
define view entity ZI_ArFxActualCube
  as select from ZI_ArFxItem as i
  association [1..1] to ZI_ArFxCustomer as _Customer on _Customer.Customer = i.Customer
{
  key i.CompanyCode,
  key cast( substring( cast( i.PostDate as abap.char(10) ), 1, 7 ) as abap.char(7) ) as Period,
  key i.Customer,
  key i.Currency,
      _Customer,
      @DefaultAggregation : #SUM
      count( * )                                   as Lines,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( i.BilledFc )                            as BilledFc,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      sum( i.CollectedFc )                         as CollectedFc
}
group by i.CompanyCode, i.PostDate, i.Customer, i.Currency

⑤ 예정 큐브 — 같은 키 모양으로

예정 데이터를 실적 큐브와 같은 키로 집계합니다. 키가 어긋나면 예정이 실적 옆에 붙지 않고 따로 떠 미계획 요인으로 잡힙니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFxPlanCube : 예정 큐브
" 나눈 이유: 실적 큐브와 키 모양을 같게 맞춰 union 이 아니라 join 으로 붙인다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '외화 채권 큐브(예정)'
define view entity ZI_ArFxPlanCube
  as select from zarfx_plan as p
{
  key p.bukrs     as CompanyCode,
  key p.version   as Version,
  key p.period    as Period,
  key p.customer  as Customer,
  key p.currency  as Currency,
      @DefaultAggregation : #SUM
      p.billed_fc  as PlanBilledFc,
      @DefaultAggregation : #SUM
      p.collect_fc as PlanCollectedFc,
      p.plan_rate  as PlanRate
}

⑥ 통합 큐브 — 차이를 한 곳에서 정의

실적과 예정을 붙여 차이를 한 번만 정의합니다. 화면 · 분석 도구 · 배치가 같은 정의를 읽습니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFxCube : 실적 + 예정 + 요인
" 나눈 이유: 요인분해 식을 화면 · 도구마다 따로 쓰지 않는다
" 요인 : 청구 규모 · 회수율(지연) · 환율 · 환가료·수수료 · 미계획
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '외화 채권 큐브(통합)'
define view entity ZI_ArFxCube
  as select from ZI_ArFxActualCube as a
    left outer join ZI_ArFxPlanCube as p
      on  p.CompanyCode = a.CompanyCode and p.Period = a.Period
      and p.Customer = a.Customer       and p.Currency = a.Currency
{
  key a.CompanyCode, key a.Period, key a.Customer, key a.Currency,
      a.BilledFc, a.CollectedFc, p.PlanBilledFc, p.PlanCollectedFc, p.PlanRate,
      " 청구 규모 요인 = (실적 청구 외화 − 예정 청구 외화) × 예정 회수 비율 × 예정 환율
      case when p.Period is null then 0
           else ( a.BilledFc - p.PlanBilledFc )
                * ( p.PlanCollectedFc / p.PlanBilledFc ) * p.PlanRate end as BillEffect,
      " 미계획 = 예정 행이 없는 조합의 실적 순회수액 (원화 환산 후 합산)
      case when p.Period is null then 1 else 0 end                       as IsUnplanned
}

⑦ 분석 쿼리 — 행 · 열 축과 계산 측정값

표준 분석 도구가 그대로 띄우는 쿼리입니다. 화면의 기본 배치(행 권역 › 국가, 열 없음)를 여기서도 같게 둡니다.

" ─────────────────────────────────────────────────────────────
" ZC_ArFxQuery : 분석 쿼리
" 나눈 이유: 필터 · 기본 배치 · 계산 측정값을 쿼리에 두어 도구가 달라도 같게 보이게 한다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '외화 채권 다차원 분석'
@Analytics.query : true
define view entity ZC_ArFxQuery
  as select from ZI_ArFxCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key CompanyCode,
  @AnalyticsDetails.query.axis : #ROWS
  key Customer,
  @AnalyticsDetails.query.axis : #COLUMNS
  key Currency,
  @UI.lineItem : [{ position : 10 }]
  @AnalyticsDetails.query.decimals : 0
  BilledFc,
  @AnalyticsDetails.query.decimals : 0
  CollectedFc,
  @AnalyticsDetails.query.decimals : 1
  cast( 0 as abap.dec(5,1) ) as CollectRate   " 확인 필요 : 계산 측정값으로 정의(청구 대비 회수)
}

⑧ DCL — 집계를 읽는 자리에 건다

권한은 집계를 읽는 자리에 걸어야 합니다. 드릴스루에만 걸면 합계에서 뺄셈으로 남의 숫자가 새어 나옵니다.

" ─────────────────────────────────────────────────────────────
" ZI_ARFXCUBE : 통합 큐브 접근 제어
" 나눈 이유: 회사코드 · 영업조직을 집계 단계에서 제한한다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '외화 채권 큐브 권한'
@MappingRole : true
define role ZI_ARFXCUBE {
  grant select on ZI_ArFxCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 시점에 해야 할 일

합의가 먼저인 여섯 가지

위 여섯 가지는 코딩이 아니라 합의입니다. 합의가 끝나면 기술 작업은 CDS 뷰(큐브 · 예정 · 분석 쿼리 · 권한)를 만들고 화면을 올리는 일로, 블로그에 코드와 함께 공개해 두었습니다.

검토에서 자주 나오는 질문

검증 결과

대사식 6종 전부 차이 0. 화면 쪽은 따로 자동화로 돌려 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 문서 합계가 같은지를 다시 잽니다.

운영 데이터로 갈 때 — 청구 라인이 수천만 건이면

청구 라인이 수천만 건이 되면 브라우저가 큐브를 통째로 읽는 방식은 쓰지 못합니다. 집계는 반드시 DB(CDS 큐브)에서 하고, 화면은 조회조건으로 범위를 좁힌 결과만 받습니다. 청구월 · 회사코드는 필수 조회 파라미터로 두고 기간 범위를 제한합니다.

드릴스루는 한 번에 500행씩 끊어 읽습니다. 큐브 키에 쓰는 차원 필드에는 인덱스를 고려하고, 응답 시간 기준(예: 조회 3초 이내)을 합의해 기준을 넘는 조합은 범위를 좁히게 안내합니다. 이 기준은 환경마다 달라 확인 필요로 둡니다.

자주 묻는 질문

숫자와 산식

화면과 조작

분석 기능

도입과 운영