SAP 자금 솔루션 은행 거래 비용 다차원 분석 — 은행 수수료·환전 스프레드·이자·보증료를 끌어다 놓고 약정 대비 차이를 요인과 원천 명세까지

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

월말 자금 회의에서 은행 거래 비용은 늘 “작은 항목”으로 지나갑니다. 그런데 은행이 청구한 송금 수수료·전신료·환전 스프레드·이자·보증료는 은행이 여러 곳이고 외화 거래가 있으면 금세 수천 줄이 됩니다. 담당자가 받는 질문은 비슷합니다. 은행에 약정한 만큼만 청구되었나, 어느 은행·어느 서비스에서 벌어졌나, 그 차이는 물량 때문인가 요율 때문인가 환율 때문인가. 지금은 이 답이 은행 청구 명세 · 약정서 · 엑셀 · 표준 라인 항목 조회에 흩어져 있어, 합계표를 맞추는 일에 시간이 먼저 쓰입니다.

이 화면은 은행이 청구한 비용을 하나의 큐브로 묶어 축을 끌어다 놓고, 약정(예정) 비용과의 차이를 일곱 요인으로 갈라 보여 주며, 칸을 누르면 그 금액을 이루는 원천 청구 명세까지 내려갑니다. 특정 회계기준서를 구현한 것이 아니라 은행 계좌의 청구 명세와 약정 비용을 분석하는 업무 화면입니다. 그래서 하우스 은행 관리(FI12)·은행 계좌 명세 처리(FEBAN)·G/L 계정 라인 항목(FBL3N)·수작업 은행 명세 입력(FF67)을 대체하지 않고, 그 숫자를 이어받아 축을 바꿔 보고 차이를 설명하는 쪽을 맡습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 합계는 −0.2% 인데 해외송금은 +20.3% 였다

검증용 샘플 데이터에서 2026년 1월~9월을 조회하면 청구 비용 실적은 4,085,830천원, 약정은 4,094,559천원으로 차이가 −8,729천원(−0.2%) 입니다. 합계만 보면 약정을 잘 지킨 것처럼 보입니다. 거래 서비스 축으로 내려가면 해외송금은 약정 295,883천원에 실적 355,871천원으로 +59,988천원(+20.3%) 벌어져 있고, 같은 크기의 음수가 다른 서비스에서 이를 가리고 있었습니다. 해외송금 아래 한 은행(가상 이름)을 골라 요인분해를 켜면 차이 +21,456천원이 다음처럼 나뉩니다.

차이의 대부분(+20,472)이 약정표에 없는 조합에서 청구된 비용이었다는 점이 한눈에 보입니다. 요율이나 물량이 달라진 것이 아니므로, 확인할 곳은 은행의 요율 협의가 아니라 “새로 생긴 거래 종류나 약정 변경 통지가 있었는가”입니다. 검산 줄(약정 78,374 + 요인 합 − 실적 99,831)은 0 으로 표시됩니다. 숫자 검증도 같은 자리에서 합니다. 샘플 청구 명세 라인 6,634건으로 8가지 축 배치 × 3개 측정값, 총 1,350칸을 전수 대사했고 차이는 0건입니다(자세한 표는 CDS 구성의 검증 결과에 있습니다).

도입하면 달라지는 것

• 월말 은행 비용 점검 — 은행별·서비스별 비용표, 약정 대비 차이, 사유 정리가 한 화면에서 나와 엑셀 취합이 줄어듭니다.
• 회의의 주제 — “어느 합계가 맞나”가 아니라 “이 은행의 이 항목을 약정과 다시 맞춰 볼 것인가”를 이야기합니다.
• 다음 달로 이어지는 기록 — 변동 사유와 저장한 보기가 남아 같은 설명을 되풀이하지 않습니다.
• 놓치는 날이 없는 점검 — 감시 규칙에 걸린 비용률·약정 대비 차이·약정 외 청구·환전 스프레드 비중이 대기함에 올라옵니다.
• 숫자를 의심하는 비용 — 칸을 누르면 원천 청구 명세가 열리고 합계 일치가 표시되어, 표준 화면을 다시 열어 대조하는 일이 줄어듭니다.

이런 회사에 맞습니다

거래 은행이 여러 곳이고 원화와 함께 달러·유로·위안 같은 외화 송금·환전·무역금융·보증 거래가 있는 회사입니다. 은행별로 약정 요율과 감면 조건이 달라 월말마다 청구 명세와 약정을 엑셀로 대조해야 하는 자금팀·경영지원 조직에 맞고, 본사와 해외법인 사무소처럼 회사코드가 둘 이상일 때 은행 비용을 회사별로 가르는 일에도 쓰입니다.

실행 화면

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

사용 방법

1. 조회 조건 입력 — 위쪽 조회 조건에서 회사(다중 선택), 기간 시작·끝, 비교 기준(없음 또는 약정)을 정합니다. 모두 선택 사항이며 비우면 전체 범위입니다.
2. 조회 — 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 저장한 보기 가운데 “열면 바로 조회”로 지정한 것이 있으면 열리자마자 조회됩니다.
3. 요약 확인 — 조회 뒤 조건 영역은 한 줄 요약으로 접히고 청구 비용·거래 금액 대비 비용률·환전 스프레드·약정 대비 차이·감면율 카드와 피벗·차트가 나타납니다.
4. 보는 사람과 축 이동 — 경영·재무·자금·회계 버튼으로 관점을 바꾸고, 차원 칩을 행 축·열 축으로 끌어다 놓거나 X 로 뺍니다. 측정값·값 필터·표시 단위도 여기서 바꿉니다.
5. 칸 클릭 상세 — 표의 칸을 누르면 그 금액을 이루는 원천 청구 명세 라인이 열리고 합계 일치가 표시됩니다. 약정 차이를 켜고 행을 고르면 요인분해와 워터폴, 변동 사유·해설·에이전트를 이어서 씁니다.
6. 내보내기 — 표 상단의 CSV 로 현재 피벗을, 원천 라인 창의 CSV 로 라인 목록을, 해설 창의 보고서로 PowerPoint 를 내려받습니다.

무엇으로 만들었나

처음 열었을 때

조회 조건부터 피벗까지가 한 화면에 세로로 쌓입니다. 조회 전에도 틀이 서 있고, 조회 뒤에는 조건이 접혀 표와 차트가 자리를 넓게 씁니다.

조회 전에도 빈 화면을 주지 않습니다. 조건과 보드, 피벗 틀이 먼저 서 있고 표 자리에는 “조회 조건을 정하고 [조회]를 누르면 표가 채워집니다” 안내가 있어서, 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 기간은 2026년 1월~9월 전체가 기본이고, 비교 기준은 약정(P0)입니다.

조회를 누르면 요약 카드가 먼저 차고, 그 아래로 레이아웃 보드와 피벗이 함께 뜹니다. 기본 배치는 행 축 은행 › 거래 서비스, 열 축 분기, 측정값은 청구 비용(원화)입니다. 표 오른쪽 차트는 같은 값을 그린 것이라 표를 읽기 전에 모양부터 눈에 들어옵니다.

조회 뒤에는 조건이 한 줄 요약(회사·기간·비교 기준·단위)으로 접혀 표와 차트에 자리를 내줍니다. 조건을 바꾸고 싶으면 머리글을 눌러 다시 펼치고 조회를 한 번 더 누릅니다. 이때만 서버에서 큐브를 새로 읽습니다. 아래 보드는 쓰지 않는 차원은 보관함에, 쓰는 차원은 행 축(3단계까지)과 열 축(2단계까지)에 놓는 자리입니다.

차원 칩을 열 축 칸으로 끌어다 놓은 모습입니다. 다시 조회할 필요는 없습니다. 큐브는 이미 브라우저에 있고 축을 바꾸는 일은 그 행을 다시 묶는 일이기 때문입니다. 요약 카드의 합계가 그대로인 것이 이 점을 보여 줍니다.

경영 요약 · 축 전환과 범위

행 축 3단계·열 축 2단계까지 끌어다 놓고, 값 필터로 범위를 좁히고, 측정값과 계산 항목을 고릅니다. 이 단계의 모든 변경은 브라우저 안에서 일어납니다.

표 위의 모두 펼치기·모두 접기 버튼으로 트리를 한꺼번에 엽니다. 행이 많아도 표 행 수 설정(기본 12행)만큼 보이고 나머지는 스크롤합니다. 합계 줄이 맨 위에 있어 아래 행을 더하면 합계가 되는지 눈으로 확인할 수 있습니다.

값 필터 창은 차원(은행·거래 서비스·통화 등)을 고른 뒤 값을 다중 선택합니다. 각 값 옆의 숫자는 그 값에 걸린 큐브 행 수라서, 선택 전에 규모를 가늠할 수 있습니다. 선택 지우기로 한 번에 비웁니다.

은행 2곳만 고르면 청구 비용 합계가 2,083,077천원으로 줄고 약정 대비 차이 카드도 같은 범위로 다시 계산됩니다. 필터 버튼 옆에 “필터: 은행 2”처럼 걸린 조건이 표시되므로, 캡처한 화면만 봐도 어떤 범위의 숫자인지 알 수 있습니다.

계산 항목은 수수료·환전 스프레드·이자·보증료 같은 비용 구분별 합, 감면 전 비용, 감면율, 거래 금액 대비 비용률(bp), 건당 비용입니다. 식은 서버와 화면이 같은 정의를 쓰므로 어디서 계산해도 같은 값이 나옵니다. 여러 개를 고르면 열이 늘어납니다.

칸에서 원천 청구 명세까지

숫자를 의심하는 순간 가장 빠른 길은 칸을 누르는 것입니다. 그 금액을 이루는 청구 명세가 열리고 합계가 일치하는지 같은 자리에서 확인합니다.

칸 금액 66,024천원 위에 “표의 값과 일치” 표시와 라인 수 340건이 함께 보입니다. 라인에는 청구일·문서·은행·거래 서비스·비용 항목·통화·거래 금액·환율·요율(bp)·감면·청구 비용이 있어, 어느 거래의 어느 요율에서 나온 금액인지 바로 읽습니다. 창 아래 CSV 로 라인 목록을 내려받습니다.

약정 대비 차이 — 같은 표가 은행 협의 자료가 된다

약정 차이 스위치를 켜면 같은 표가 실적·약정·차이·차이율로 바뀌고, 행을 고르면 요인분해와 워터폴, 변동 사유까지 이어집니다.

금액 기준(기본 0.3백만원)과 비율 기준(기본 5%)을 모두 넘는 칸만 붉은색으로 칠해집니다. 합계가 −0.2%로 조용해도 해외송금처럼 +20.3% 벌어진 줄은 색으로 바로 드러납니다. 두 기준은 위쪽 입력 칸에서 바꿉니다.

왼쪽 막대가 약정 78,374, 오른쪽 막대가 실적 99,831이고 가운데 막대가 요인입니다. 약정 외 발생(+20,472)이 가장 높게 솟아 있어, 이 행의 차이가 어디서 왔는지 한눈에 읽힙니다. 양수는 초록, 음수는 빨강입니다.

요인은 물량·요율·환율·면제·감면·청구 시점·약정 외 발생·미발생이며 합하면 총차이 +21,456이 됩니다. 맨 아래 “검산: 약정 78,374 + 요인 합 − 실적 99,831 = 0”이 초록으로 켜져 있으면 분해가 맞은 것이고, 0 이 아니면 점검 필요로 바뀝니다.

구분(예: 요율 변경)은 목록에서 고르고 사유는 최대 500자까지 적습니다. 차이 금액이 창에 함께 떠 있어 무엇에 대한 설명인지 헷갈리지 않습니다. 사유는 서비스에 저장되어 같은 행을 다시 열면 이어서 고칠 수 있습니다.

“변동 사유를 저장했습니다” 안내가 잠깐 뜨고 행에 표시가 남습니다. 사유는 조회 범위와 행 경로에 묶여 있어 축을 바꾸거나 다시 조회해도 같은 행을 따라갑니다. 해설을 열면 사유가 있는 행은 건너뛰어 같은 말을 되풀이하지 않습니다.

보는 사람 — 경영 · 재무 · 자금 · 회계

같은 데이터를 네 관점으로 봅니다. 관점 버튼은 기본 축과 측정값을 바꿀 뿐 데이터를 바꾸지 않으므로, 오가도 합계는 같습니다.

경영 버튼을 누르면 위쪽에 이 관점이 묻는 질문이 한 줄로 적히고, 행 축은 거래 서비스 › 은행, 열 축은 분기로 놓입니다. 요약 카드의 약정 대비 차이를 먼저 읽는 사람을 위한 배치입니다.

행 축이 회사 › 은행, 열 축이 측정값으로 바뀌고 수수료·환전 스프레드·이자·보증료 합이 나란히 놓입니다. 데이터는 그대로이고 보는 순서만 달라서, 관점을 오가도 합계는 같습니다.

행 축이 은행 › 거래 서비스이고 열에 비용률과 청구 비용이 있습니다. 어느 은행의 어느 서비스가 거래 금액에 비해 비싼지를 bp 로 비교하는 자리입니다. 비용률은 청구 비용 × 10,000 ÷ 거래 금액입니다.

행 축이 비용 구분 › 비용 항목이고 열에 감면 전 비용·감면 금액·청구 비용이 놓입니다. 감면 전 비용 − 감면 금액 = 청구 비용이 줄마다 맞는지를 읽는 배치입니다. 차이가 있으면 점검 필요입니다.

AI 분석과 보고서

해설은 서비스가 계산한 숫자를 규칙으로 문장에 옮긴 것이며, 근거 표가 항상 같이 나옵니다.

“작성 방식: 규칙”이라고 표시된 것처럼, 숫자는 서비스가 큐브에서 계산해 넘기고 문장은 규칙으로 만든 초안입니다. 사유가 이미 적힌 행은 “건너뜀”으로 표시됩니다. 창 아래 보고서 PPTX 버튼으로 같은 내용을 PowerPoint 로 내려받습니다.

문장과 숫자를 바로 대조할 수 있게 한 자리입니다. 해설에 나온 금액은 모두 이 표에서 왔고, 표의 값은 큐브 집계와 같습니다. 모델이 문장을 매끄럽게 하는 경우에도 숫자는 이 표를 벗어나지 않습니다.

AI 에이전트

감시 규칙을 하루 한 번 점검해 걸린 항목을 대기함에 모읍니다. 하루 한 번 제한은 서버가 판정합니다.

규칙은 은행별 비용률 상한, 약정 대비 차이 임계, 약정 외 청구 한도, 환전 스프레드 비중 한도입니다. 각 규칙에는 대상 관점(자금·경영·회계·재무)이 붙어 있습니다. 실행하기 전에는 “오늘 아직 실행하지 않았습니다”와 빈 대기함이 보입니다.

“실행했습니다. 규칙 4개 중 4건이 걸렸습니다” 안내와 함께 대기함에 점검 필요 항목이 올라옵니다. 항목에는 지표 값과 임계값, 확인할 일(요율 변경 통지·감면 적용 여부)이 적혀 있습니다. 에이전트는 판단하지 않고 살펴볼 곳을 모아 줄 뿐입니다.

“오늘은 이미 실행했습니다(하루 한 번 제한). 내일 다시 실행할 수 있습니다”가 노란 안내로 뜹니다. 제한은 화면이 아니라 서버가 판정하므로, 화면을 새로 열거나 다른 기기에서 눌러도 같은 결과가 나옵니다.

레이아웃 저장과 복원

자주 쓰는 축과 필터를 이름 붙여 저장하고, 기본·자동 조회로 지정해 열자마자 같은 보기가 뜨게 합니다.

현재 보기 저장은 지금의 행·열 축, 측정값, 필터, 기준값을 이름 붙여 남깁니다. 기본 배치로 되돌리기는 저장 없이 처음 상태로 돌아갑니다. 에이전트 버튼 옆의 숫자(4)는 대기함에 쌓인 항목 수입니다.

보기 이름은 필수이고, 기본 보기로 지정하거나 열자마자 조회되게 할 수 있습니다. 저장하는 내용은 축·필터·기준값이며 표와 차트의 너비는 기기마다 달라 저장하지 않습니다.

저장한 보기를 고르면 축과 측정값, 필터가 그대로 복원됩니다. 기본·자동 조회로 지정한 보기는 표시가 붙고, 화면을 열면 바로 조회됩니다. 샘플 서버가 재시작되면 저장한 보기가 초기화되는 점은 운영 연결 때 저장소를 정하면서 확인합니다.

좁은 화면

390px 폭에서도 같은 기능을 쓰도록 배치가 바뀝니다.

휴대폰 폭에서도 같은 조건을 입력합니다. 회사·기간·비교 기준이 한 줄에 하나씩이고, 보는 사람 버튼과 차원 칩은 줄 바꿈으로 이어집니다. 가로 스크롤은 생기지 않습니다.

카드 폭이 줄어도 숫자는 줄바꿈 없이 읽히도록 두 열로 배치합니다. 피벗은 첫 열(행 이름)을 고정하고 오른쪽을 스크롤해 읽습니다.

넓은 화면에서 오른쪽에 있던 차트가 표 바로 아래에 같은 값으로 그려집니다. 열이 많은 구성은 넓은 화면이 편하므로, 좁은 화면에서는 보는 사람 버튼으로 열 수가 적은 관점을 고르는 것을 권합니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스가 원천 청구 명세 라인을 9개 차원(기간·회사·은행·거래 서비스·비용 항목·통화·거래 채널·비용 구분·사업부) 단위로 집계한 실적 큐브와 같은 구성의 약정 큐브를 한 번씩 돌려줍니다. 화면은 이 둘을 메모리에 두고, 이후 축·관점·단위 변경은 모두 브라우저 안에서 다시 합산합니다. 한 번에 읽는 큐브와 약정은 각각 최대 5,000행으로 제한해 범위가 너무 넓을 때 조건을 좁히도록 안내합니다(샘플은 실적 1,669행, 약정 1,561행). 칸을 눌렀을 때만 그 칸의 원천 라인을 건수 확인 후 쪽 나눠 읽어 옵니다.

청구 비용은 거래 금액 × 요율 − 약정 감면이며, 외화 거래는 거래일 환율로 원화 환산합니다. 계산 항목(수수료·환전 스프레드·이자·보증료·감면 전 비용·감면율·비용률·건당 비용)은 토큰 식으로 정의해 서버와 화면이 같은 식을 씁니다.

약정 대비 판정과 표시 규칙

이 화면은 점검 도구입니다. 색 표시와 해설은 살펴볼 곳을 좁혀 줄 뿐이며 최종 판단은 회사와 감사인이 합니다.

산출과 검산 순서

1. 원천 청구 명세 라인을 9개 차원 단위로 집계해 실적 큐브와 약정 큐브를 만듭니다. 금액·건수는 모두 기간 합입니다.
2. 청구 비용에서 약정 감면을 이미 뺀 값을 쓰고, 감면 금액은 별도 측정값으로 둡니다. 감면 전 비용은 둘을 더한 계산 항목입니다.
3. 약정과의 차이를 물량(거래 금액) · 요율 · 환율 · 면제·감면 · 청구 시점 · 약정 외 발생 · 미발생 일곱 요인으로 나눕니다. 환율 요인에 반올림 차이를 모아 검산을 맞춥니다.
4. 약정 + 요인 합 − 실적 = 0 인지 검산 줄로 확인하고, 큐브 합계와 원천 라인 합계를 기간 × 측정값으로 대사합니다(검산 기록 54건).

조회조건

서비스에는 기간과 값 필터가 Period>=202601;Period<=202609;Bank=B01,B02 같은 짧은 문법으로 전달됩니다.

결과 컬럼

좁은 화면에서 달라지는 것

• 조회 조건이 세로로 쌓이고 조회·초기화 버튼이 조건 아래에 놓입니다.
• 요약 카드는 두 열로 쌓이고, 차트는 표 오른쪽이 아니라 표 아래로 내려옵니다.
• 표 위 도구 줄의 버튼이 많으면 더보기(…) 메뉴로 접힙니다.
• 화면 전체의 가로 스크롤은 생기지 않으며, 표만 안쪽에서 스크롤합니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ controller/  BaseController.js · Main.controller.js
├─ view/        Main.view.xml · fragments/ (원천 명세 · 변동 사유 · 보기 저장 · 보기 관리 · AI 분석 · 에이전트 · 값 도움)
├─ model/       cube.js(피벗 엔진) · chart.js · layout.js · formatter.js · pptx.js · ErrorHandler.js
├─ css/ · i18n/ style.css · i18n.properties · i18n_ko.properties
├─ odata/       메타데이터 · 서비스 로직 · 계산 항목 식 · 샘플 데이터
├─ media/       소개 영상 · 대표 이미지 · 목차 파일
└─ readme.html

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준 화면으로 충분한 일은 표준에 두고, 표준에서 이어지지 않는 자리만 이 화면이 잇습니다.

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

T-code 별 연계 지점

맞닿는 표준 T-code 마다 이어받는 데이터와 대사 지점을 아래에 적었습니다. 운영으로 옮긴 뒤에도 기존 표준 화면은 없애지 않습니다. 이 화면의 숫자와 표준 화면의 숫자를 맞춰 보는 용도로 함께 씁니다.

이 앱의 결과에서 표준 화면으로 가는 길은 위 표의 “오가는 방법”과 같습니다. 반대로 표준 화면에서 본 수수료 합계는 이 앱의 은행 행에서 같은 기간의 청구 비용으로 다시 확인합니다. “기존 리포트를 없애야 하나”에 대한 답은 아니오입니다. 법정·공시·감사·세무 신고용 보고는 표준에 남겨 둡니다.

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

S/4HANA 에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 수단이 이미 있습니다. 이 화면은 그것들과 경쟁하기보다, 같은 CDS 큐브 위에서 “끌어다 놓는 축 전환 · 칸에서 원천 명세로 · 약정 대비 차이 요인”을 한 화면에 모으는 자리를 맡습니다. 같은 쿼리를 Analysis for Office 에서 열어도 숫자는 같아야 하고, 그 차이가 0 인지를 대사 항목으로 둡니다. 특정 Fiori 앱과의 연계는 확인하지 못한 범위라 이름을 적지 않았습니다(확인 필요).

분석 지표 정의표

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

CDS 구성

샘플 데이터로 돌던 화면을 운영 데이터로 옮기려면 같은 서비스 계약을 CDS 로 채웁니다. 아래 코드는 구조를 보여 주는 스케치이며, 원천 테이블과 필드는 고객사 시스템에서 확인이 필요합니다(확인 필요 표시).

뷰 레이어 구성

① 비용 계정 매핑 테이블

은행 비용 분석의 차원은 코드 사전에서 시작합니다. 어느 G/L 계정이 수수료이고 어느 계정이 환전 스프레드인지가 이 테이블 한 곳에서 정해지므로, 바뀌면 큐브의 모든 합계가 바뀝니다. 변경 관리를 가장 엄격하게 합니다.

" ───────────────────────────────────────────────
" ZBCST_FEEMAP : 비용 계정 → 비용 구분 · 거래 서비스 매핑
" 역할  : 큐브가 비용 구분을 읽는 유일한 기준표
" 이유  : 계정 체계가 바뀌어도 뷰를 고치지 않고 이 표만 고치도록
" ───────────────────────────────────────────────
@EndUserText.label : '은행 비용 계정 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbcst_feemap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key saknr      : saknr not null;     " 비용 계정(G/L)
  cost_cat       : abap.char(1);       " F 수수료 / S 환전 스프레드 / I 이자·보증료
  svc_id         : abap.char(3);       " 거래 서비스(해외송금·외환 매매 등)
  fee_id         : abap.char(4);       " 비용 항목
}

② 차원 뷰 — 은행

차원은 큐브에서 join 을 한 번만 걸도록 별도 뷰로 둡니다. 하우스 은행 마스터(T012 등)는 후보이며 실제 필드는 시스템에서 확인합니다.

" ───────────────────────────────────────────────
" ZI_BankCostBank : 은행 차원 (한 행 = 한 은행)
" 역할  : 은행 이름과 키를 한 곳에서 제공
" 이유  : 큐브·쿼리·값 도움말이 같은 이름표를 쓰게 함
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '은행 거래 비용 은행 차원'
@ObjectModel.dataCategory : #DIMENSION
@Analytics.dataCategory : #DIMENSION
define view entity ZI_BankCostBank
  as select from t012 as b                          " 확인 필요: 하우스 은행 마스터
{
  key b.bukrs           as CompanyCode,
  key b.hbkid           as Bank,
      @Semantics.text: true
      b.text1           as BankName                 " 확인 필요: 이름 필드
}

③ 원천 청구 명세 라인

드릴스루가 읽는 자리이자 모든 집계의 근원입니다. 청구 비용 = 거래 금액 × 요율 − 감면이며, 외화 거래는 거래일 환율로 원화 환산합니다. 이 뷰에서 틀리면 큐브와 약정, 요인분해가 모두 틀리므로 표준 라인 항목(FBL3N)과의 대사를 여기서 맞춥니다.

" ───────────────────────────────────────────────
" ZI_BankCostItem : 청구 명세 라인 (한 행 = 한 거래)
" 역할  : 거래 금액·요율·감면·환율·원화 청구 비용을 라인 단위로 제공
" 이유  : 칸 → 라인 드릴스루와 큐브 집계가 같은 원천을 보게 함
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 청구 명세 라인'
define view entity ZI_BankCostItem
  as select from bseg as s                          " 확인 필요: 은행 비용 계정 라인
    inner join   bkpf as h on h.bukrs = s.bukrs and h.belnr = s.belnr and h.gjahr = s.gjahr
    inner join   zbcst_feemap as m on m.bukrs = s.bukrs and m.saknr = s.hkont
    left outer join tcurr as r                      " 확인 필요: 환율 유형·환산 시점
      on r.kurst = 'M' and r.fcurr = h.waers and r.tcurr = 'KRW'
{
  key s.bukrs                          as CompanyCode,
  key s.belnr                          as DocumentNo,
  key s.buzei                          as LineNo,
      h.budat                          as BillDate,
      m.cost_cat                       as CostCategory,
      m.svc_id                         as Service,
      m.fee_id                         as FeeItem,
      h.waers                          as TxCurrency,
      @Semantics.amount.currencyCode: 'TxCurrency'
      s.wrbtr                          as TxAmount,   " 확인 필요: 거래 금액 기준 필드
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      cast( s.dmbtr as abap.curr(23,2) ) as CostLocal,  " 청구 비용(원화)
      h.hwaer                          as CompanyCurrency,
      s.zuonr                          as Channel,        " 확인 필요: 거래 채널 필드
      s.gsber                          as BusinessUnit,   " 사업부(사업 영역)
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      cast( s.dmbtr as abap.curr(23,2) ) as TxAmountLocal, " 확인 필요: 원화 거래 금액
      @Semantics.amount.currencyCode: 'CompanyCurrency'
      cast( s.dmbtr as abap.curr(23,2) ) as FreeLocal      " 확인 필요: 약정 감면액
}

④ 약정 큐브 — 같은 차원의 약정 비용

약정은 은행과 맺은 요율·감면 조건에서 계산한 예정 비용입니다. 실적과 같은 차원 구성이어야 칸마다 뺄 수 있습니다. 약정 마스터가 어디에 있는지는 고객사마다 달라 확인이 필요합니다.

" ───────────────────────────────────────────────
" ZI_BankCostPlan : 약정(예정) 비용 큐브 (버전별)
" 역할  : 약정 요율 × 약정 거래 금액 − 감면을 실적과 같은 9개 차원으로 집계
" 이유  : 약정 대비 차이를 칸 단위로 빼기 위해 차원을 일치시킴
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 약정 비용 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_BankCostPlan
  as select from zbcst_contract as c                " 확인 필요: 약정 마스터(요율·감면·버전)
{
  key c.version                       as Version,
  key c.period                        as Period,
  key c.bukrs                         as CompanyCode,
  key c.bank                          as Bank,
  key c.svc_id                        as Service,
  key c.fee_id                        as FeeItem,
  key c.waers                         as TxCurrency,
  key c.chan                          as Channel,
  key c.cost_cat                      as CostCategory,
  key c.bu                            as BusinessUnit,
      @DefaultAggregation: #SUM
      c.plan_cost                     as PlanCost,
      @DefaultAggregation: #SUM
      c.plan_volume                   as PlanVolume
}

⑤ 실적 큐브 — 9개 차원 집계

화면이 한 번에 읽는 단위입니다. 집계는 브라우저가 아니라 DB 에서 하고, 기간·회사 파라미터로 읽는 행 수를 줄입니다. 약정 외 발생과 약정만 있는 조합은 약정 큐브와 FULL OUTER 로 이어 차이 요인으로 분리합니다.

" ───────────────────────────────────────────────
" ZI_BankCostCube : 청구 비용 실적 큐브
" 역할  : 원천 라인을 9개 차원 단위로 합산 (청구 비용 · 거래 금액 · 감면 · 건수)
" 이유  : 화면이 축을 바꿔도 같은 합계가 나오도록 단일 집계 지점으로 둠
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 거래 비용 실적 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_BankCostCube
  with parameters
    p_from : abap.numc(6),
    p_to   : abap.numc(6)
  as select from ZI_BankCostItem as i
{
  key substring( cast( i.BillDate as abap.char(8) ), 1, 6 ) as Period,
  key i.CompanyCode,
  key i.Bank,
  key i.Service,
  key i.FeeItem,
  key i.TxCurrency,
  key i.Channel,
  key i.CostCategory,
  key i.BusinessUnit,
      @DefaultAggregation: #SUM
      sum( i.CostLocal )        as Cost,
      @DefaultAggregation: #SUM
      sum( i.TxAmountLocal )    as Volume,
      @DefaultAggregation: #SUM
      sum( i.FreeLocal )        as Free,
      @DefaultAggregation: #SUM
      count( * )                as LineCount
}
where substring( cast( i.BillDate as abap.char(8) ), 1, 6 ) between $parameters.p_from and $parameters.p_to
group by
  substring( cast( i.BillDate as abap.char(8) ), 1, 6 ),
  i.CompanyCode, i.Bank, i.Service, i.FeeItem, i.TxCurrency,
  i.Channel, i.CostCategory, i.BusinessUnit

⑥ 분석 쿼리 — 소비 뷰

화면이 보는 이름과 키를 정하는 자리입니다. 필터로 쓸 필드와 화면에서 보일 레이블을 여기서 주석으로 정하면, 서비스로 노출될 때 그대로 따라갑니다. 약정은 association 으로 걸어 차이 계산이 같은 키를 쓰게 합니다.

" ───────────────────────────────────────────────
" ZC_BankCostQuery : 은행 거래 비용 분석 쿼리 (Consumption)
" 역할  : 화면이 읽는 측정값·차원을 UI 주석과 함께 노출
" 이유  : 필터·정렬·레이블을 한 곳에서 정해 서비스 계약과 맞춤
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 거래 비용 분석'
@Analytics.query : true
define view entity ZC_BankCostQuery
  with parameters
    @Consumption.defaultValue: '202601' p_from : abap.numc(6),
    @Consumption.defaultValue: '202609' p_to   : abap.numc(6)
  as select from ZI_BankCostCube( p_from : $parameters.p_from, p_to : $parameters.p_to ) as c
  association [0..*] to ZI_BankCostPlan as _Plan
    on  _Plan.Period = c.Period and _Plan.Bank = c.Bank
    and _Plan.Service = c.Service and _Plan.FeeItem = c.FeeItem
{
      @AnalyticsDetails.query.axis: #ROWS
      @Consumption.filter.selectionType: #SINGLE
  key c.Period,
      @AnalyticsDetails.query.axis: #ROWS
      @Consumption.filter.selectionType: #MULTIPLE_RANGE
  key c.Bank,
      @AnalyticsDetails.query.axis: #ROWS
  key c.Service,
      @UI.lineItem: [{ position: 10 }]
  key c.FeeItem,
      @AnalyticsDetails.query.axis: #COLUMNS
      @AnalyticsDetails.query.decimals: 0
      c.Cost                     as BilledCost,
      @AnalyticsDetails.query.axis: #COLUMNS
      c.Volume                   as TradeVolume,
      c.Free                     as Waived,
      _Plan.PlanCost             as AgreedCost,
      _Plan
}

⑦ 권한 — 회사코드 단위

권한은 집계를 읽는 자리에 걸어야 합니다. 드릴스루에만 걸면 전사 합계와 자기 몫의 차이로 남의 숫자가 뺄셈으로 드러납니다. 회사코드는 표준 권한 객체로 확인하고, 은행 범위가 필요하면 권한 객체를 따로 설계합니다.

" ───────────────────────────────────────────────
" ZC_BankCostQuery (DCL) : 회사코드 단위 권한
" 역할  : 사용자가 볼 수 있는 회사코드 행만 반환
" 이유  : 집계 단계에서 걸어야 합계에서 남의 숫자가 새지 않음
" ───────────────────────────────────────────────
@EndUserText.label : '은행 거래 비용 권한'
@MappingRole : true
define role ZC_BankCostQuery {
  grant select on ZC_BankCostQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
    " 은행 범위가 필요하면 권한 객체를 설계해 and 조건으로 추가
}

⑧ 서비스 정의 — OData 로 내보내기

마지막으로 쿼리를 OData V2 서비스로 노출합니다. 화면이 읽는 엔티티셋 이름과 키를 이 정의가 정하므로, 화면의 서비스 계약과 같은 이름으로 맞춥니다. 요인분해·해설·에이전트 같은 서버 로직은 RAP 액션이나 함수로 같은 서비스에 붙입니다.

" ───────────────────────────────────────────────
" ZUI_BankCost : 서비스 정의 + 바인딩(OData V2 - UI)
" 역할  : 쿼리·원천 라인·차원을 엔티티셋으로 노출
" 이유  : 화면의 서비스 계약과 이름·키를 맞추기 위해
" ───────────────────────────────────────────────
@EndUserText.label : '은행 거래 비용 서비스'
define service ZUI_BankCost {
  expose ZC_BankCostQuery  as CubeSet;
  expose ZI_BankCostPlan   as PlanSet;
  expose ZI_BankCostItem   as ItemSet;
  expose ZI_BankCostBank   as BankSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

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

샘플 데이터 청구 명세 라인 6,634건(실제 청구 6,336 · 약정 외 발생 127 · 약정만 있고 청구 없음 171)으로 대사식을 전수로 돌린 결과입니다. 의도적 예외는 0건입니다.

샘플 데이터 기준 결과이며, 운영 데이터에서는 같은 대사식을 다시 돌려야 합니다. 환율은 샘플의 가정값입니다.

운영 데이터로 갈 때

은행 청구 라인이 수천만 건이면 집계는 브라우저가 아니라 DB 에서 해야 합니다. 큐브 뷰에서 기간·회사·은행 단위로 미리 집계하고, 조회 조건에서 기간과 회사를 필수로 받아 한 번에 읽는 행을 줄입니다. 화면은 큐브를 최대 5,000행까지만 읽도록 되어 있으므로 범위가 넓으면 조건을 좁히라는 안내가 뜹니다. 원천 라인은 칸을 눌렀을 때만 건수를 확인한 뒤 쪽 나눠 읽고, 응답 시간 기준은 도입 전에 정해 둡니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

분석 기능과 AI

도입과 운영