SAP 수출 은행 수수료·환가료 다차원 분석 리포트 — 네고·추심 때 은행에 내는 돈을 환가료부터 하자 수수료까지 계획 대비로 읽는 수출 대금 회수 비용 분석

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

수출 대금 회수 회의의 질문은 늘 비슷합니다. 은행에 얼마를 냈나, 어느 은행 · 어느 결제 방식에서 더 나갔나, 계획보다 은행 비용이 늘었다면 환가 일수가 길어서인가 요율이 올라서인가 서류 하자 때문인가. 지금 이 답은 판매오더(VA03) · 청구(VF03) 화면과 은행 통보서, G/L 개별 항목(FBL3N), 엑셀로 흩어져 있어 매달 숫자를 모아 맞추는 데 시간이 듭니다.

이 앱은 수출 매입(네고 · 추심) 품목을 은행 비용 관점으로 한 번 읽어 큐브로 만들고, 같은 큐브에서 표 · 차트 · 요약 · 드릴스루 · 계획 대비 · 요인분해를 모두 그립니다. 축을 바꿔도 서버를 다시 부르지 않고, 칸을 누르면 그 금액을 만든 네고 문서 라인이 열려 “어느 숫자가 맞나” 하는 회의를 줄입니다. 이 글의 모든 숫자는 가상의 검증용 샘플이며 환가료율 · 수수료율 · 임계값은 가정값입니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 계획보다 237백만원 늘어난 은행 비용의 요인

검증용 샘플에서 총 은행 비용은 계획 13,802백만원, 실적 14,040백만원으로 총차이가 +237백만원(+1.7%) 였습니다. 합계만 보면 “조금 늘었다”에서 끝납니다. 아홉 요인으로 가르자 미계획 매입(+327백만원) 이 가장 크고, 계획했지만 이행되지 않은 매입은 −83백만원으로 차이를 줄이고 있었습니다. 서로 반대로 움직이는 두 요인이 합계 안에서 상쇄되고 있었다는 뜻입니다.

이야기 요소도 심어 두었습니다. 샘플의 E은행은 7월부터 환가료율이 0.32%p 올랐고, C은행은 6월부터 서류 하자 건당 수수료가 14% 올랐습니다. 거래은행 × 월 축으로 놓으면 이 두 은행이 어느 달부터 계획에서 벌어졌는지가 표에서 바로 보이고, 요인분해에서는 각각 환가료율 요인과 하자 건당 수수료 요인이 커집니다. 서류 하자 수수료는 실적 99백만원으로 계획 57백만원의 1.7배, 전신료는 295백만원으로 계획 239백만원보다 많았습니다. 이 숫자는 원인을 확정하지 않으며, 어디를 먼저 점검할지와 어떤 사유를 남길지를 정하는 단서입니다.

분해에는 조건을 걸었습니다. 요인 합계와 총차이가 1원이라도 어긋나면 화면이 오류로 표시합니다. 같은 조합이 계획과 실적 한쪽에만 있으면 억지로 나누지 않고 미계획 매입 · 계획 미이행으로 따로 세웁니다. 회의에서 “이 숫자 맞아?”라는 질문에 바로 답할 수 있다는 뜻입니다.

도입하면 달라지는 것

• 회의의 주제 — “어느 리포트 숫자가 맞나”가 아니라 “어느 은행 · 어느 결제 방식에서 계획이 벌어졌나”를 이야기합니다.
• 분석 준비 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 화면 캡처가 줄어듭니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 매달 같은 설명을 처음부터 다시 하지 않습니다.
• 놓치지 않는 점검 — 화면을 열지 않은 날에도 규칙에 걸린 항목은 받을 역할의 대기함에 올라갑니다.

이런 회사에 맞습니다

신용장 네고 · 서류인도 · 서류지급 방식을 섞어 수출 대금을 회수하고 거래은행이 여러 곳인 제조 · 유통 회사, 환가 일수와 서류 하자 때문에 은행 비용이 계획과 벌어지는 일이 잦은 자금 · 수출 담당 조직, 그리고 수출 은행 비용을 월 단위로 계획과 견주어 경영진에 설명해야 하는 경영지원 조직에 맞습니다. 거래 통화가 여러 개여도 통화별로 나누어 대사합니다.

실행 화면

사용 방법

1. 조회조건 입력 — 회사코드(필수, 기본 1000)와 시작 · 종료 기간(필수, 기본 2026-01 ~ 2026-09)을 정합니다. 비교 기준은 은행 비용 계획 버전으로 고정돼 있어 바꿀 수 없습니다.
2. 조회 — 조회 버튼은 조회조건 영역의 오른쪽 끝에 있고 입력칸에서 Enter 를 눌러도 됩니다. 조회는 큐브를 한 번 읽는 동작이며 이후 축을 바꿔도 다시 읽지 않습니다.
3. 요약 확인 — “집계 N건 · 원천 N줄”으로 읽은 규모를 보고, 역할(CEO · CFO · 영업 책임자 · 자금 책임자)을 바꿔 앞세우는 지표를 확인합니다.
4. 축과 항목 정하기 — 레이아웃 보드에서 차원 칩을 끌어 행 · 열 · 사용 안 함 칸에 놓습니다. 행은 최대 3단계, 열은 최대 2단계입니다.
5. 표 읽기 — 행의 화살표로 아래 차원으로 내려가고, 기준 대비를 켜면 칸마다 계획 · 차이 · 증감률이 붙습니다.
6. 필터 — 필터 버튼 줄에서 차원 값을 여러 개 고릅니다. 같은 차원 안은 or, 차원 사이는 and 입니다.
7. 칸 · 행 클릭 상세 — 칸을 누르면 원천 문서 라인이 열립니다. 차이가 난 행에서는 변동 사유 버튼으로 사유를 남깁니다.
8. 분석 도구 — 상단 버튼은 레이아웃 → AI 분석 → AI 에이전트 → 기간별 요약 → CSV 순서입니다. 보고서(PowerPoint)는 AI 분석 창에서 내려받습니다.
9. 내보내기 — 지금 표의 행 · 열 · 항목 그대로 CSV 로 저장합니다.
10. 자동 조회 — 기본 레이아웃에 자동 조회를 지정해 두면 화면을 여는 순간 조회된 채 시작합니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤로 만들고, 금액과 판정은 서비스가 계산합니다. 화면은 서비스가 준 숫자를 합산하고 배치만 합니다.

OData 서비스 이름은 소문자 expbankfee_srv 이고 엔티티셋 15개 · 펑션 3개로 구성됩니다. 앱 본체는 manifest 에 선언한 서비스만 바라보고, 샘플 데이터는 test/ 폴더 안에만 있습니다.

처음 열었을 때 — 조회 전에도 틀이 먼저 보입니다

조회조건 · 레이아웃 보드 · 피벗 틀은 조회 전부터 보입니다. 조회 한 번으로 큐브를 읽고 나면 축을 바꿔도 서버를 다시 부르지 않습니다.

회사코드와 시작·종료 기간만 정하면 되고, 기본값은 회사코드 1000 · 2026-01 ~ 2026-09 입니다. 쓰지 않는 차원 9개가 왼쪽 칸에, 행 축에는 제품 그룹 › 거래은행이 올라 있습니다. 아직 조회 전이라 표는 비어 있고 안내 문구만 보입니다. 조회 버튼은 조회조건 영역의 오른쪽 끝에 있고 Enter 로도 조회됩니다.

집계 1,237건(원천 7,734줄)을 한 번 읽어 표 · 오른쪽 차트 · 상단 지표 4개를 그립니다. 총 은행 비용은 14,040백만원, 은행 비용률은 청구액 대비 0.72%, 네고·추심 수수료는 2,656백만원입니다. 각 숫자 아래 작은 글씨는 계획 값과 대비입니다.

거래은행을 열 축으로 옮긴 모습입니다. 총합은 그대로이고 열 머리글만 은행별로 바뀝니다. 이 동작은 네트워크 요청이 0건이며 브라우저에 올라온 큐브를 다시 묶는 것입니다.

표와 차트에 더 많은 공간을 주고 싶을 때 머리 영역을 접습니다. 접힌 줄에는 회사코드 · 기간 · 행 · 열 · 항목 수가 남아 지금 보고 있는 범위를 잊지 않게 합니다.

경영 요약 — 역할이 바뀌면 보는 숫자가 바뀝니다

역할은 CEO · CFO · 영업 책임자 · 자금 책임자 네 가지이고, 앞세우는 지표와 기본으로 쪼개 보는 차원이 달라집니다. 역할을 바꿔도 다시 조회하지 않습니다.

CFO 는 월별로 은행 비용이 어떻게 흘렀는지를 봅니다. 표는 매입월 단위로 풀리고, 지표는 총 은행 비용 · 환가료 · 네고·추심 수수료 · 서류 하자 수수료입니다.

영업 책임자는 은행 비용이 어느 고객 · 국가에서 크게 나가는지를 봅니다. 매입 1건당 은행 비용과 서류 하자 발생 비율이 지표입니다.

자금 책임자는 돈을 앞당겨 받는 비용을 봅니다. 평균 환가 일수와 환가료 연 환산율이 지표이고, 표는 거래은행 › 결제 방식입니다.

축 전환과 범위 — 은행 · 결제 방식 · 고객을 끌어다 놓습니다

차원 칩을 끌어 행 · 열 · 사용 안 함 칸에 놓습니다. 행은 최대 3단계, 열은 최대 2단계이며 열 조합이 36개를 넘으면 안내하고 막습니다.

제품 그룹 아래로 거래은행이 펼쳐진 표입니다. 집계 행의 값은 아래 행의 합과 같고, 소계가 어긋나지 않는지는 검증 단계에서 차원별 43건을 따로 대사했습니다.

열에 두 차원을 쌓은 모습입니다. 열 조합 수는 36개를 넘을 수 없고, 열 축에 차원이 있으면 분석 항목은 첫 항목만 펼쳐 보입니다.

필터 버튼 줄에서 차원을 누르면 값 목록이 열립니다. 이름과 코드, 원천 라인 수가 함께 보여 어느 값이 큰지 알고 고를 수 있습니다.

같은 차원 안에서는 or, 차원 사이에서는 and 로 걸립니다. 필터가 걸린 표와 차트와 요약이 같은 범위로 줄어듭니다.

표와 차트 사이 손잡이를 끌어 너비를 바꿉니다. 바꾼 너비는 브라우저가 기억합니다.

칸에서 원천 문서까지 — 숫자의 출처를 바로 봅니다

칸을 누르면 그 금액을 만든 원천 네고 문서 라인이 열리고, 위쪽 줄이 칸 금액과 원천 합계가 같은지 알려 줍니다.

칸의 행 경로와 열 조합이 그대로 질의 조건이 되어 청구 문서 · 품목 단위 라인이 열립니다. 위쪽에 칸 금액과 원천 합계가 일치한다는 줄이 뜨고, 라인에는 매입액 · 환가 일수 · 환가료율 · 환가료 · 수수료가 보입니다.

기간별 요약 대화상자는 월별 건수와 총 은행 비용의 실적 · 계획을 한 표로 보여 줍니다.

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

비율과 단가는 전표에 없으므로 계산항목으로 만들어 행에 올립니다. 분자와 분모를 먼저 합산한 뒤 나눠 소계에서도 맞습니다.

계산항목을 열로 놓은 표입니다. 평균 환가 일수는 매입액 가중 평균이고, 환가료 연 환산율은 환가료를 매입액 × 일수로 나눠 연 기준으로 바꾼 값입니다.

단계 보기는 총 은행 비용을 구성 항목으로 풀어 한 열에 세로로 보여 줍니다. 어느 구성이 합계를 키웠는지 한눈에 봅니다.

계획 대비 차이 — 같은 표가 은행 비용 회의 자료가 됩니다

기준 대비 스위치를 켜면 칸마다 실적 · 계획 · 차이 · 증감률이 붙습니다. 금액 임계와 증감률 임계를 둘 다 넘을 때만 색을 칠합니다.

칸 안에 기준 값과 차이, 증감률이 작은 글씨로 붙습니다. 비용이 늘어난 칸은 빨강, 줄어든 칸은 초록입니다.

차이가 난 행의 사유 버튼을 누르면 사유 구분과 내용을 적는 창이 열립니다. 사유는 조회 범위와 행 경로를 키로 저장됩니다.

저장한 행에는 표시가 붙고, 축을 바꾸거나 다시 열어도 같은 행에 따라옵니다. CSV 와 AI 근거 표에도 함께 실립니다.

선택한 행의 계획에서 실적까지를 아홉 요인으로 이은 워터폴입니다. 요인 합계와 총차이를 대조한 검산 줄이 함께 보이며, 어긋나면 오류로 표시합니다.

AI 분석과 보고서 — 같은 숫자를 읽고 설명합니다

AI 는 서비스가 계산한 숫자를 읽어 설명만 합니다. 기본은 규칙 기반 해설이며 외부 모델 연결은 꺼진 채 시작합니다.

현재 범위의 요약과 핵심 발견을 쓰고, 해설이 읽은 근거 표를 펼쳐 볼 수 있습니다. 숫자를 새로 만들지 않고 서비스가 준 값만 인용합니다.

보고서 버튼을 누르면 브라우저가 현재 범위의 표와 차트를 담은 .pptx 파일을 직접 만들어 내려받습니다. 서버에 파일을 남기지 않습니다.

AI 에이전트 — 감시 규칙과 대기함

사람이 화면을 열지 않아도 규칙에 걸린 항목을 받을 역할의 대기함에 올립니다.

규칙은 5개입니다: 총 은행 비용 계획 차이 금액, 은행 비용률 상한, 평균 환가 일수 상한, 환가료 연 환산율 상한, 서류 하자 수수료 금액. 임계값과 사용 여부는 바꿀 수 있습니다.

대기함의 보고는 받을 역할 · 규칙 · 대상 행 경로 · 금액을 담습니다. 행 경로로 이동해 해당 칸을 바로 점검합니다.

같은 날 두 번째 실행 요청은 서버가 건너뜀으로 판정하고, 사유와 첫 실행 번호를 기록합니다. 화면은 이를 안내 토스트로 보여 줍니다.

레이아웃 저장과 복원

축 · 조회조건 · 항목 · 접힘 상태를 이름 붙여 저장하고 기본 레이아웃과 자동 조회를 지정합니다.

이름을 붙여 저장하고, 기본으로 쓸지와 열 때 자동 조회할지를 고릅니다.

저장한 레이아웃 목록에서 기본 지정을 바꾸거나 삭제합니다.

자동 조회를 지정해 두면 화면을 여는 순간 저장한 축으로 조회된 채 시작합니다.

좁은 화면과 한계 — 표를 반쯤 그리지 않습니다

좁은 화면에서는 차트가 표 아래로 내려가고, 열 조합이 한도를 넘으면 안내하고 막습니다.

폭 390px 에서는 조회조건과 레이아웃 보드가 세로로 쌓입니다.

차트가 표 오른쪽에서 아래로 내려오고 표는 가로로 스크롤됩니다.

열 조합이 36개를 넘으면 안내 문구를 띄우고 표를 반쯤 그리지 않습니다. 행 노드 500개 초과도 같습니다.

화면 뒤에서 일어나는 일

금액과 비율은 모두 서비스가 계산합니다. 아래는 화면이 색을 칠하고 검산하고 감시하는 규칙입니다. 임계값은 검증용 샘플에서 정한 가정값입니다.

칸 색칠 · 검산 · 감시 판정 로직

산출식과 대사식

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭이 좁아지면 조회조건과 레이아웃 보드가 세로로 쌓이고 차트는 표 아래로 내려갑니다. 표는 가로로 스크롤되며, 열 조합이 한도를 넘으면 표를 반쯤 그리지 않고 안내합니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ controller/  BaseController.js · Main.controller.js
├─ view/        Main.view.xml · fragments/ (조회 · 사유 · AI · 에이전트 · 레이아웃 · 필터 대화상자)
├─ model/       cube.js(피벗) · chart.js(SVG 차트) · pptx.js(보고서) · layout.js · formatter.js · ErrorHandler.js
├─ css/ · i18n/
├─ odata/expbankfee_srv/   metadata.xml · service.js · engine.js · json/
├─ media/       intro.mp4 · intro_poster.jpg · intro_chapters.vtt
├─ test/        검증 전용 — 샘플 데이터로 화면을 띄우는 진입점
└─ readme.html

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 그래서 운영으로 옮긴 뒤에도 기존 표준 리포트를 없앨 필요가 없고, 법정 · 감사 · 신고 대응에 쓰던 화면은 그대로 둔 채 이 앱을 분석과 월간 회의용으로 병행합니다.

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

T-code 별 연계 지점

정리하면 이 앱 결과의 숫자가 의심스러울 때는 칸 → 원천 라인 → 문서 번호 → 해당 표준 T-code 순서로 내려가고, 표준 화면의 값을 이 앱에서 다시 보려면 같은 문서의 청구일 · 고객 · 거래은행으로 조회 범위를 좁힙니다.

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

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

분석 지표 정의

CDS 구성 — 뷰 · 코드 · 운영 작업까지

아래 코드는 운영 시스템에 옮길 때의 출발점으로 쓰는 스케치입니다. 표준 데이터 구조(청구 · 판매오더 문서)를 그대로 읽고, 회사마다 달라지는 지점은 “확인 필요”로 표시했습니다.

뷰 레이어 구성

① 은행 약정 기준 테이블 — 환가료율과 수수료율을 정하는 곳

은행 비용은 약정이 정합니다. 환가료율 · 수수료율 · 최저 수수료 · 전신료를 뷰 안에 숫자로 박아 두면 약정이 바뀔 때마다 뷰를 고쳐 이송해야 하므로 테이블로 뺍니다. 샘플은 가정값이며, 운영에서는 은행과 맺은 약정을 넣습니다.

@EndUserText.label : '수출 은행 약정 기준'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zebf_bankterm {
  " ─────────────────────────────────────────────────────────────
  "  ZEBF_BANKTERM — 거래은행 · 결제 방식별 약정 요율
  "  이렇게 나눈 이유: 요율은 은행과 회사가 정하는 값이라 코드가 아니라 데이터로 둔다.
  " ─────────────────────────────────────────────────────────────
  key client    : abap.clnt not null;
  key bank      : abap.char(10) not null;    " 거래은행 코드
  key instr     : abap.char(3)  not null;    " LCN 신용장 네고 · DAB 서류인도 · DPB 서류지급
  key valid_from: abap.dats not null;
  disc_rate     : abap.dec(7,4);             " 환가료율(연 %)
  comm_rate     : abap.dec(7,4);             " 네고 · 추심 수수료율(%)
  min_comm      : abap.dec(13,2);            " 최저 수수료
  cable_fee     : abap.dec(13,2);            " 전신 · 우편료(건당)
  dscr_fee      : abap.dec(13,2);            " 서류 하자 수수료(건당)
  waers         : abap.cuky;
}

② 네고 품목 뷰 — 라인마다 환가료와 수수료를 파생하는 기본 뷰

모든 집계는 이 뷰의 한 줄(청구 품목)에서 출발합니다. 청구 헤더 · 품목과 판매오더를 연결하고 약정 기준표를 붙여 라인마다 환가료 · 수수료 · 하자 수수료 · 전신료를 만듭니다. 거래은행 · 결제 방식 · 매입일 · 만기까지 일수를 어느 필드에서 가져올지는 회사 구성에 따르므로 주석에 확인 필요로 남겼습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 네고 품목(은행 비용 관점)'
@ObjectModel.usageType: { serviceQuality: #X, sizeCategory: #XXL, dataClass: #TRANSACTIONAL }
define view entity ZI_ExportBankFeeItem
  as select from vbrp
    inner join   vbrk on vbrk.vbeln = vbrp.vbeln
    left outer join zebf_bankterm as _t
        on  _t.bank  = vbrp.zz_bank            " 확인 필요 — 거래은행 필드
        and _t.instr = vbrp.zz_instr           " 확인 필요 — 결제 방식 필드
{
  " ─────────────────────────────────────────────────────────────
  "  ZI_ExportBankFeeItem — 청구 품목 한 줄 = 매입(네고 · 추심) 한 줄
  "  이렇게 나눈 이유: 큐브 · 계획 · 쿼리가 모두 같은 라인에서 출발해야 합계가 갈라지지 않는다.
  " ─────────────────────────────────────────────────────────────
  key vbrp.vbeln                      as BillDoc,
  key vbrp.posnr                      as Item,
      vbrk.fkdat                      as BillDate,
      vbrp.zz_negdate                 as NegDate,       " 매입일 — 확인 필요
      vbrk.kunag                      as Customer,
      vbrk.inco1                      as Incoterms,
      vbrp.matkl                      as ProdGroup,
      vbrp.aubel                      as SoDoc,
      vbrk.waerk                      as Currency,
      vbrp.zz_bank                    as Bank,
      vbrp.zz_instr                   as Instr,
      vbrp.zz_days                    as Days,          " 매입일부터 회수 예정일까지 일수
      @Semantics.amount.currencyCode: 'Currency'
      vbrp.netwr                      as FcValue,
      vbrp.zz_negamt_krw              as NegAmt,        " 매입액(원화)
      _t.disc_rate                    as DiscRt,
      cast( vbrp.zz_negamt_krw * _t.disc_rate / 100 * vbrp.zz_days / 360
            as abap.dec(15,0) )       as Disc,          " 환가료
      cast( greatest( vbrp.zz_negamt_krw * _t.comm_rate / 100, _t.min_comm )
            as abap.dec(15,0) )       as Comm,          " 네고 · 추심 수수료
      cast( case when vbrp.zz_dscr_flag = 'X' then _t.dscr_fee else 0 end
            as abap.dec(15,0) )       as Dscr,          " 서류 하자 수수료
      cast( _t.cable_fee as abap.dec(15,0) ) as Cable   " 전신료
}
where vbrk.fkart = 'F2'        " 청구 유형 — 수출 청구 유형은 회사 정함, 확인 필요

③ 차원 뷰 — 거래은행 · 결제 방식의 값과 텍스트

레이아웃 보드와 필터가 보여 주는 값 목록은 차원 뷰가 줍니다. 값과 텍스트를 한 곳에서 내려 주면 화면의 값 도움말, 큐브의 그룹 기준, 쿼리의 필터가 같은 목록을 바라봅니다.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 은행 비용 차원 — 거래은행'
@Search.searchable: true
define view entity ZI_ExportBankFeeBankDim
  as select distinct from ZI_ExportBankFeeItem
{
  @ObjectModel.text.element: ['BankName']
  key Bank                              as Bank,
      @Search.defaultSearchElement: true
      @Semantics.text: true
      cast( Bank as abap.char(40) )      as BankName      " 은행 이름은 은행 마스터에서 — 확인 필요
}

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 은행 비용 차원 — 결제 방식'
define view entity ZI_ExportBankFeeInstrDim
  as select distinct from ZI_ExportBankFeeItem
{
  key Instr                             as Instr,
      case Instr when 'LCN' then '신용장 네고'
                 when 'DAB' then '서류인도(D/A)'
                 when 'DPB' then '서류지급(D/P)' end  as InstrName
}

④ 큐브 — 차원 조합별 합계와 통화 환산

큐브는 라인을 차원 조합으로 묶어 합계를 만듭니다. 화면은 이 결과를 한 번 읽어 브라우저에서 다시 묶으므로, 읽는 단위가 문서 수가 아니라 조합 수에 비례합니다.

@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 은행 비용 큐브(실적)'
define view entity ZI_ExportBankFeeCube
  as select from ZI_ExportBankFeeItem
{
  " ─────────────────────────────────────────────────────────────
  "  ZI_ExportBankFeeCube — 매입월 × 은행 × 결제 방식 × 제품 × 고객 × 인코텀즈
  "  이렇게 나눈 이유: 합계는 여기서 한 번만 만든다. 화면 · 쿼리 · 보고서가 같은 값을 읽는다.
  " ─────────────────────────────────────────────────────────────
  key substring( NegDate, 1, 6 )      as Period,
  key Bank, key Instr, key ProdGroup, key Customer, key Incoterms,
      @DefaultAggregation: #SUM  sum( Disc )   as Disc,
      @DefaultAggregation: #SUM  sum( Comm )   as Comm,
      @DefaultAggregation: #SUM  sum( Dscr )   as Dscr,
      @DefaultAggregation: #SUM  sum( Cable )  as Cable,
      @DefaultAggregation: #SUM  sum( Disc + Comm + Dscr + Cable ) as Total,
      @DefaultAggregation: #SUM  sum( NegAmt ) as NegAmt,
      @DefaultAggregation: #SUM  sum( NegAmt * Days ) as DayAmt,   " 평균 환가 일수의 분자
      @DefaultAggregation: #SUM  count( * )    as Lines
}
group by substring( NegDate, 1, 6 ), Bank, Instr, ProdGroup, Customer, Incoterms

⑤ 계획 뷰 — 실적과 같은 차원 조합으로 맞춘 비교 기준

계획은 실적과 같은 차원 조합으로 맞춰야 칸마다 차이가 나옵니다. 어느 한쪽에만 있는 조합은 억지로 나누지 않고 미계획 매입 · 계획 미이행 요인으로 따로 세웁니다.

@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 은행 비용 계획'
define view entity ZI_ExportBankFeePlan
  as select from zebf_plan                  " 계획 원천은 회사 정함 — 확인 필요
{
  key version  as Version,                  " 예: BNK26
  key period   as Period,
  key bank     as Bank, key instr as Instr,
  key prodgrp  as ProdGroup, key customer as Customer, key inco1 as Incoterms,
      @DefaultAggregation: #SUM  sum( plan_total ) as Total,
      @DefaultAggregation: #SUM  sum( plan_negamt ) as NegAmt,
      @DefaultAggregation: #SUM  sum( plan_lines )  as Lines
}
group by version, period, bank, instr, prodgrp, customer, inco1

⑥ 분석 쿼리 — 화면이 읽는 하나의 입구

화면과 분석 도구가 읽는 입구를 쿼리 하나로 모읍니다. 회사코드와 기간은 필수 변수로 두어 전체를 읽지 않게 합니다.

@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 은행 비용 분석'
define view entity ZC_ExportBankFeeQuery
  as select from ZI_ExportBankFeeCube
{
  @AnalyticsDetails.query.axis: #ROWS    @AnalyticsDetails.query.display: #KEY_TEXT  Bank,
  @AnalyticsDetails.query.axis: #ROWS    Instr,
  @AnalyticsDetails.query.axis: #COLUMNS Total,
  @AnalyticsDetails.query.axis: #COLUMNS Disc,
  @AnalyticsDetails.query.axis: #COLUMNS Comm,
  @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }  Period,
  Customer, ProdGroup, Incoterms
}

⑦ 접근 제어(DCL) — 합계로 남의 숫자가 새지 않게

권한은 큐브 이전 단계인 기본 뷰에 겁니다. 드릴스루 라인에만 걸면 전사 합계에서 자기 몫을 빼는 방식으로 남의 숫자가 드러날 수 있기 때문입니다.

@EndUserText.label: '수출 은행 비용 — 판매 조직 권한'
@MappingRole: true
define role ZI_ExportBankFeeItem {
  grant select on ZI_ExportBankFeeItem
    where ( VKORG ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
    " 판매 조직 표준 권한 오브젝트 — 회사 권한 설계에 따라 확인 필요
}

⑧ 서비스 정의와 바인딩 — 화면이 부르는 주소

쿼리와 차원 뷰를 서비스로 노출하고 OData V2 로 바인딩합니다. 화면은 manifest 의 서비스 주소만 알면 되므로, 운영으로 옮길 때 이 주소만 바꿉니다.

@EndUserText.label: '수출 은행 비용 분석 서비스'
define service ZUI_ExportBankFee {
  expose ZC_ExportBankFeeQuery as CubeSet;
  expose ZI_ExportBankFeePlan  as PlanSet;
  expose ZI_ExportBankFeeBankDim  as BankDim;
  expose ZI_ExportBankFeeInstrDim as InstrDim;
  expose ZI_ExportBankFeeItem  as ItemSet;
}
" 서비스 바인딩: OData V2 - UI, 이름 expbankfee_srv (소문자) — 활성화 후 manifest 주소 교체

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 정하지 않으면 막히는 순서대로 적었습니다.

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

검증용 샘플 전수에 대해 대사식을 돌렸고 차이는 모두 0건이며 의도적 예외는 없습니다. 도입 포인트의 사례와 같은 숫자입니다.

큐브 대사식 20종은 모두 차이 0이고, 원천 라인 7,734줄의 항등식도 차이 0입니다. 화면 쪽은 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 원천 합계가 같은지를 실제 브라우저로 따로 확인했습니다.

운영 데이터로 갈 때

청구 문서가 수천만 건이 되면 집계 위치가 가장 먼저 중요해집니다. 큐브는 데이터베이스에서 집계하고 화면은 집계 결과만 읽습니다. 회사코드와 기간은 필수 조건으로 두어 전체를 읽지 않게 하고, 필요하면 월 단위 사전 집계 뷰를 둡니다. 인덱스는 청구일 · 판매 조직 · 고객 중심으로 점검하고, 드릴스루는 500줄씩 이어 읽습니다. 응답 시간 기준과 최대 조회 기간은 도입 시 함께 정합니다.

자주 묻는 질문

도입을 검토하시는 분들이 가장 자주 물으시는 질문을 숫자와 산식 · 화면과 사용 · 분석 기능 · 도입과 운영 순으로 모았습니다.

숫자와 산식

화면과 사용

분석 기능

도입과 운영