수입 신용장 사용·금융비용 다차원 분석 — 개설·선적 사용·잔액·이자를 한 큐브로 보고 예정 대비 차이를 여섯 요인으로 가르다

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

수입 신용장(L/C)을 쓰는 회사에는 두 가지 질문이 늘 남습니다. 개설해 둔 한도 가운데 실제로 선적에 쓴 것은 얼마이고 놀고 있는 것은 얼마인가, 그리고 그 사이에 은행에 낸 이자와 수수료는 예정보다 얼마나 늘었고 왜 늘었는가입니다. 개설 금액, 선적 사용, 미사용 잔액, 유산스 이자, 개설·인수 수수료는 모두 같은 신용장 라인에서 나오지만 보는 사람마다 기준 축이 다릅니다. 구매는 공급사로, 자금은 은행과 만기 구간으로, 물류는 인코텀즈와 선적 이행으로 읽습니다.

지금 방식은 대개 은행 통지서와 표준 화면의 전표를 건별로 열어 엑셀에 옮기고, 축마다 시트를 따로 만들어 합계를 맞추며, 예정 대비 차이는 별도 파일에서 손으로 분해하는 것입니다. 시트가 늘수록 같은 이름의 비율이 서로 다른 값으로 나오고, 차이의 원인을 설명하는 데 회의 시간이 쓰입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(가상 공급사 12곳 · 가상 은행 4곳 · 개설월 2026.04~2026.09 · 가정 환율과 이자율)에서 예정 금융비용은 45.37억원, 실적은 50.34억원으로 +4.97억원(+11.0%) 차이가 발생했습니다. 요인분해는 아래처럼 나뉩니다.

가장 큰 몫은 미계획 개설(+3.24억원)이고, 그 반대편에 사용 금액(−3.15억원)이 있어 둘이 서로 상쇄합니다. 이자율과 유산스 기간 요인은 합쳐 +2.02억원으로, 은행 약정 금리와 만기 조건을 점검해야 할 신호입니다. 순서를 바꾸면 요인별 금액은 달라질 수 있지만 합은 항상 총차이와 같습니다.

규모로 보면 개설 금액 5,343.20억원 중 4,528.69억원(84.8%)이 선적에 쓰였고 814.50억원(15.2%)이 미사용 잔액으로 남았습니다. 금융비용 50.34억원은 유산스 이자 34.80억원과 개설·인수 수수료 15.54억원의 합이며, 사용 금액 대비 금융비용률은 1.11%입니다.

도입하면 달라지는 것

• 마감 전 준비 — 공급사별 · 은행별 금융비용, 라인 확인, 요인분해가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞는가" 대신 "어느 요인을 점검할 것인가"를 이야기합니다.
• 다음 기간으로 이어지는 기록 — 변동 사유와 레이아웃이 남아 같은 설명을 되풀이하지 않습니다.
• 놓치지 않는 점검 — 화면을 열지 않아도 감시 규칙에 걸린 항목이 역할별 대기함에 올라옵니다.
• 역할별 시각 — CFO · 구매 책임자 · 물류 책임자 · 자금 책임자가 같은 큐브를 자기 기준 축으로 읽습니다.

이런 회사에 맞습니다

원재료나 설비 부품을 해외에서 수입하며 여러 은행에 신용장을 개설하고, 유산스(기한부) 결제로 이자와 수수료를 부담하는 제조·유통 회사에 맞습니다. 특히 개설 한도 대비 사용률과 미사용 잔액을 은행별 · 공급사별로 따로 관리해야 하거나, 금융비용 예정 대비 차이를 매월 설명해야 하는 자금팀 · 회계팀에 쓰임새가 큽니다.

실행 화면

사용 방법

1. 조회조건을 넣습니다. 회사코드(필수)와 시작 · 종료 개설월을 고릅니다. 차원 값을 비워 두면 전체 범위입니다.
2. 조회 버튼을 누르거나 Enter를 칩니다. 큐브가 한 번 읽혀 오고 차트와 피벗이 함께 그려집니다.
3. 임원 요약에서 전체 모양을 확인합니다. 역할(CFO · 구매 · 물류 · 자금)을 바꾸면 표시 항목과 행 축이 그 역할에 맞게 바뀝니다.
4. 탭과 축을 옮깁니다. 차원 칩을 끌어 행 축(최대 3) · 열 축(최대 2)에 놓으면 서버를 다시 부르지 않고 바로 다시 묶입니다.
5. 칸이나 행을 눌러 상세를 엽니다. 칸은 신용장 품목 라인으로, 차이 모드의 행은 변동 사유 입력으로 이어집니다.
6. 내보냅니다. 피벗과 라인은 CSV로, 분석 결과는 AI 분석 창의 PPTX 보고서로 내려받습니다.

무엇으로 만들었나

화면은 UI5 표준 컨트롤 위에 얹었고, 데이터는 OData V2 모델이 매니페스트에 선언된 서비스를 상대 경로로 읽어 옵니다. 서비스는 읽기 모델(큐브 · 예정 · 계산항목 · 차원 값 · 신용장 품목 라인)과 쓰기 모델(변동 사유 · 레이아웃 · 감시 규칙)을 함께 제공합니다.

처음 열었을 때 — 조회 전 틀에서 피벗과 차트까지

화면 맨 위에는 조회 조건, 그 아래 분석 축 보드, 임원 요약, 차트와 피벗이 세로로 쌓여 있습니다. 조회를 누르기 전에는 틀만 보이고, 조회하면 한 번에 채워집니다.

조회 조건에는 회사코드 1000과 개설월 2026.04~2026.09가 기본값으로 들어 있고, 차원 값은 "전체"입니다. 조회 버튼은 조건 영역 안 오른쪽 끝에 있습니다.

금융비용이 예정과 함께 표시되고 차이가 바로 보입니다. 지표는 선택한 역할에 맞춰 바뀝니다.

행을 펼치면 아래 단계가 열리고, 합계 열과 행은 어느 배치에서도 같은 총합을 가집니다.

행 축은 최대 3개 · 열 축은 최대 2개까지 받습니다. 칩은 끌어다 놓거나 화살표 버튼으로 옮깁니다.

이때 서버로 나가는 요청은 0건이었고, 총합은 옮기기 전과 같았습니다.

피벗을 오래 읽을 때 화면을 넓게 쓰도록 조건 · 축 영역을 접을 수 있습니다.

경영 요약 — 같은 큐브를 역할 네 가지로 읽는다

임원 요약은 역할을 바꾸면 기준 차원과 표시 항목이 함께 바뀝니다. 같은 6개월 · 같은 합계 위에서 CFO는 개설 은행, 구매 책임자는 공급사, 물류 책임자는 인코텀즈, 자금 책임자는 만기 구간을 기준으로 봅니다.

CFO 역할은 금융비용 · 금융비용률 · 사용률 · 이자 부담률을 개설 은행별로 읽고, 예정 초과 상위 은행을 함께 보여 줍니다.

구매 책임자 역할은 공급사별 개설 금액과 금융비용률을 놓고 예정 초과 상위 공급사를 봅니다.

물류 책임자 역할은 선적이 이행되지 않은 개설 잔액과 미사용 비율을 인코텀즈별로 봅니다.

자금 책임자 역할은 유산스 이자와 이자 부담률을 만기 구간별로 놓고 긴 만기 구간의 부담을 봅니다.

축 전환과 범위 — 끌어다 놓아도 총합은 그대로

열 축을 두 단계로 쌓거나 차원 값을 골라 범위를 좁혀도 서버를 다시 부르지 않습니다. 어떤 배치든 총합은 같아야 하며, 이 글의 검증에서도 축 배치를 바꿔 총합과 요청 건수를 확인했습니다.

열 축에 두 차원을 함께 놓으면 헤더가 조합으로 늘어납니다. 칸이 많아지는 만큼 열 폭은 좁아지고 가로 스크롤이 생깁니다.

개설월 · 분기 · 공급사 · L/C 유형 · 개설 은행 · 보증금 · 만기 구간 · 통화 · 인코텀즈 · 자재그룹 · 자재의 값을 고르면 선택한 값만 필터로 전달됩니다.

조회 조건 줄에 현재 범위가 요약됩니다. 좁힌 뒤 합계는 선택한 값들의 큐브 합과 같습니다.

차트와 피벗은 같은 값을 그리며, 폭 손잡이로 차트 영역의 너비를 조절할 수 있습니다.

좁은 화면에서는 위아래로 쌓입니다.

칸에서 신용장 라인까지 — 드릴스루

피벗의 칸을 누르면 그 금액을 만든 신용장 품목 라인이 열립니다. 라인은 한 번에 정해진 단위(기본 500건)로 읽고, 모두 읽으면 칸의 값과 라인의 합이 같은지 화면이 알려 줍니다.

칸의 값과 읽은 라인의 합이 같으면 "칸의 값과 라인 합이 같습니다"가 초록으로 표시됩니다. 검증에서 칸 4개 모두 일치했습니다.

라인이 읽는 단위보다 많으면 일부만 먼저 읽고 "아직 일부만 읽음"으로 표시하며, 더 읽기와 모두 읽기로 이어서 읽습니다.

검산 패널은 측정값 6개의 큐브 합계와 라인 합계를 비교하고, 아래에는 개설월별 라인 수와 금액이 놓입니다.

계산항목 — 금융비용률과 미사용 잔액 비율

계산항목은 서비스가 식을 내려 주고 화면이 칸마다 같은 식을 적용합니다. 금융비용률(%)은 금융비용을 선적 사용 금액으로, 사용률(%)은 선적 사용을 개설 금액으로, 이자 부담률(%)은 유산스 이자를 선적 사용 금액으로, 미사용 잔액 비율(%)은 잔액을 개설 금액으로 나눕니다.

값이 클수록 사용 금액 대비 부담이 큰 칸이며 점검 대상을 고르는 기준으로 씁니다.

합계 열은 구성 요소의 합과 같고, 계산항목과 측정값이 같은 값으로 대사됩니다.

예정 대비 차이 — 같은 표가 요인 분해 보고서가 된다

비교를 "예정 대비 차이"로 바꾸면 칸마다 예정 · 실적 · 차이 · 차이율이 붙고, 차트는 막대에서 요인 워터폴로 바뀝니다. 금액과 비율 임계를 둘 다 넘는 칸만 색이 칠해집니다.

붉은색은 비용을 늘린 칸, 초록은 줄인 칸입니다. 임계는 금액과 비율 둘 다 넘어야 색이 칠해집니다.

사유는 500자까지 적고 저장하며, 조회 범위와 행 경로에 묶여 보존됩니다.

사유가 적힌 행은 AI 분석의 점검 대상에서 빠집니다.

분해 범위를 좁히면 그 범위의 요인만 보이고, 요인 합 − 총차이 = 0원 검산 줄이 매번 표시됩니다.

미계획 개설과 사용 금액 막대가 가장 크고 서로 반대 방향입니다.

기준 대비 차이를 보는 동안에도 조회 조건과 축 보드는 그대로 위에 남습니다.

AI 분석과 보고서

AI 분석은 지금 조회한 범위를 읽어 요약과 점검 대상을 문장으로 써 줍니다. 기본은 외부 AI 서비스를 부르지 않는 규칙 기반 해설이며, 숫자는 서비스가 계산한 값만 그대로 문장에 옮깁니다.

요약은 신용장 1,660건 · 원천 라인 3,482건의 금융비용 50.34억원이 예정 45.37억원 대비 +4.97억원(+11.0%) 차이가 난다고 쓰고, 점검 대상마다 사유 확인이 필요하다고 끝맺습니다.

축 · 값 · 라인 수 · 예정 · 실적 · 차이 · 주된 요인이 상위 항목별로 나열됩니다.

버튼을 누르면 보고서 파일을 만들었다는 메시지가 뜨고 6장짜리 파일이 내려받아집니다. 파일은 서버에 남지 않습니다.

AI 에이전트 — 규칙이 곧 점검 대상

에이전트는 감시 규칙 5개를 정해 두고 하루 한 번 점검합니다. 규칙마다 임계값과 받을 역할이 붙어 있고, 걸린 항목은 그 역할의 대기함으로 올라옵니다. 임계값과 사용 여부는 화면에서 고칠 수 있습니다.

공급사 금융비용률 상한(1.4%) · 은행별 이자율·기간 요인(4천만원) · 선적 미이행 잔액(3억원) · 금융비용 예정 대비 초과(20%) · 91일 이상 유산스 이자(6천만원)입니다.

지금 실행하기를 누르면 규칙을 판정하고 걸린 항목을 보고로 올립니다. 검증에서 처음 실행은 4건의 보고를 올렸습니다.

같은 날 두 번째 실행은 LIMITED로 판정되어 새 보고 없이 기록만 남습니다.

레이아웃 저장과 복원

축 · 조회 조건 · 표시 항목 · 표시 행 수 · 접힘 상태를 이름을 붙여 저장하고 불러옵니다. 기본 레이아웃으로 지정해 두고 "열 때 자동 조회"를 켜면, 열자마자 조회된 채로 시작합니다.

저장 전에는 저장된 레이아웃이 없다는 안내가 보입니다.

별표는 기본 지정, 화살표는 적용, 휴지통은 삭제입니다.

열 때 자동 조회 덕에 조회 버튼을 누르지 않아도 채워진 채 시작합니다.

좁은 화면과 한계

휴대폰 폭에서는 열 폭과 패널이 접히고 대화 상자는 화면 전체로 열립니다. 큐브가 클 때를 위한 상한도 있어, 상한을 넘으면 화면이 안내 메시지로 범위를 줄이라고 알려 줍니다.

조건 · 축 · 임원 요약이 접힌 줄로 보이고, 값 열은 가로 스크롤 안에서 움직입니다.

"열이 84개라 앞의 36개만 보여 줍니다" 안내가 뜹니다. 열은 최대 36개, 행 노드는 최대 1,500개입니다.

화면 뒤에서 일어나는 일

한 번의 조회에서 서비스는 큐브(신용장 라인 단위 집계)와 예정 · 계산항목 · 차원 값을 돌려주고, 화면은 이를 칸 단위로 묶어 둔 뒤 축 배치에 맞게 다시 합산합니다.

1. 읽기 — 회사코드 · 개설월 범위 · 차원 값 필터로 큐브와 예정을 읽습니다. 큐브는 차원 조합 × 측정값 6개의 긴 형태(17,454행)이고, 예정은 16,530행입니다.
2. 묶기 — 긴 형태를 차원 조합 2,909개 칸으로 묶습니다. 이후 축을 바꾸는 일은 이 칸을 다시 합산하는 일입니다.
3. 계산항목 적용 — 서비스가 준 식을 칸마다 적용해 비율과 합계를 만듭니다.
4. 그리기 — 행 축 노드를 트리로 만들고 열 축을 헤더로 펼친 뒤 차트를 같은 값으로 그립니다.
5. 검산 — 큐브 합계와 라인 합계, 요인 합과 총차이를 화면 안에서 비교해 보여 줍니다.

축 전환 — 브라우저 재집계

요인분해 — 순차 대입과 검산

요인분해는 예정(t0)에서 시작해 사용 금액 → 적용 환율 → 유산스 기간 → 이자율 → 수수료 → 미계획 개설 순으로 실적 값을 하나씩 대입합니다. 각 단계에서 같은 금융비용 식을 다시 계산하므로 단계 차이의 합이 곧 총차이입니다.

드릴스루 — 칸과 라인 대사

감시 규칙 — 판정과 대기함

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

• 행 이름 열이 좁아지고 값 열은 그대로 읽히도록 가로 스크롤 안에서 움직입니다.
• 차원 값 선택 같은 대화 상자가 화면 전체로 열립니다.
• 차트와 피벗이 가로로 나란히 놓이지 않고 위아래로 쌓입니다.
• 임원 요약 지표는 줄바꿈되어 가로 넘침이 생기지 않습니다.

파일 구성

앱 폴더
├─ Component.js · manifest.json · index.html     앱 진입, 모델 선언(서비스 상대 경로)
├─ view/Main.view.xml                             화면 한 장(조회 조건 · 축 보드 · 임원 요약 · 차트와 피벗)
│   └─ fragment/                                 AI 분석 · 에이전트 · 레이아웃 · 변동 사유 · 라인 보기 대화 상자
├─ controller/                                    Main 컨트롤러 · 기본 컨트롤러
├─ model/                                         큐브 재집계 · SVG 차트 · 서식 · 레이아웃 직렬화 · PPTX 보고서 · 오류 처리
├─ odata/                                         서비스 정의 · 서비스 로직 · 샘플 데이터
├─ i18n/                                          화면 문구(한국어)
└─ css/                                           화면 보조 스타일(sap_horizon 의미 색 사용)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 신용장을 개설하고 전표를 만드는 일, 법정 · 감사 · 세무 신고에 쓰는 숫자를 확정하는 일은 표준 화면에 그대로 둡니다.

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

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 아니요. 운영 전환 뒤에도 표준 T-code와 기존 리포트는 법정 · 감사 · 세무 신고 대응과 문서 단위 확인에 그대로 둡니다.

기준서 요구사항과 화면의 대응 — K-IFRS 제1109호 금융상품 · 제1023호 차입원가

기준서의 요구사항은 명칭 수준으로만 적습니다. 이 화면은 분류 · 집계 · 대사를 돕는 조회 · 점검 도구이며, 요구사항을 어떻게 적용하는지의 판단은 회사와 감사인이 합니다. 시행일과 경과규정은 이 글에서 확인하지 않았으므로 확인 필요입니다.

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

S/4HANA의 분석은 CDS 큐브와 분석 쿼리를 중심으로, 그 위에 Fiori 분석 앱과 Analysis for Office 같은 도구를 얹는 구조입니다. 이 화면이 읽는 데이터도 같은 층(큐브와 쿼리)에서 나오도록 구성했으므로, 같은 쿼리를 다른 분석 도구에서 읽어도 숫자가 갈라지지 않습니다.

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

CDS 구성

아래는 운영 데이터로 갈 때의 구성 스케치입니다. 이름은 기능을 뜻하는 영문으로 짓고, 기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스 순서로 나눕니다. 실제 조인 조건과 필드는 시스템 구성에 맞춰 확인 필요입니다.

뷰 레이어 구성

① ZLCUSG_MAP — 기준 매핑 테이블

유산스 일수를 "30일 이내 · 31~60일 · 61~90일 · 91~120일 · 121일 이상" 같은 구간으로, 보증금 구분 코드를 이름으로 바꾸는 규칙을 코드가 아닌 테이블에 둡니다. 경계가 바뀌어도 뷰를 고치지 않습니다.

" ──────────────────────────────────────────────────────────
" ZLCUSG_MAP — 분석 기준 매핑
" 역할 : 만기 구간(BAND) · 보증금 구분(MARG) 코드를 축 값으로 변환
" 이렇게 나눈 이유 : 구간 경계와 구분 이름을 현업이 직접 유지하도록
" ──────────────────────────────────────────────────────────
@EndUserText.label : '수입 신용장 금융비용 분석 기준 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zlcusg_map {
  key client   : abap.clnt not null;
  key map_type : abap.char(4) not null;    " BAND : 만기 구간 / MARG : 보증금 구분
  key map_code : abap.char(10) not null;   " T1~T5 / M0 · M1 · M2
  day_from     : abap.int4;                " 구간 시작일수 (BAND 에서만 사용)
  day_to       : abap.int4;                " 구간 종료일수
  label        : abap.char(40);            " 화면에 보이는 이름
}

② ZI_LcUsageVendor — 공급사 차원

차원은 값과 이름을 한 곳에서 내려 주는 뷰입니다. 이 뷰가 있으면 "차원 값 선택" 대화 상자와 피벗 행 이름이 같은 텍스트를 씁니다.

" ──────────────────────────────────────────────────────────
" ZI_LcUsageVendor — 공급사 차원
" 역할 : 공급사 코드 + 이름 + 국가
" 이렇게 나눈 이유 : 큐브가 이름까지 들고 다니면 행 수가 늘어난다
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '공급사 차원'
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'Supplier'
define view entity ZI_LcUsageVendor
  as select from lfa1
{
      @ObjectModel.text.element: [ 'SupplierName' ]
  key lifnr as Supplier,
      @Semantics.text: true
      name1 as SupplierName,
      land1 as Country
}

③ ZI_LcUsageLine — 신용장 품목 라인

이 뷰에서 "라인식"의 재료가 정해집니다. 개설 금액, 선적 사용 금액, 이자, 수수료를 한 행에 두어 개설 − 사용 = 잔액, 이자 + 수수료 = 금융비용을 라인마다 검산할 수 있게 합니다.

" ──────────────────────────────────────────────────────────
" ZI_LcUsageLine — 수입 신용장 품목 라인
" 역할 : 개설 전표(opn) + 선적 인수 라인(shp) → 라인 단위 금융비용
" 이렇게 나눈 이유 : 라인식 대사의 기준을 큐브와 분리해 두면
"                    큐브 합계가 틀릴 때 라인에서 바로 원인을 찾는다
" 주의 : L/C 번호 보관 위치와 약정 금리 원천은 확인 필요
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 신용장 품목 라인'
define view entity ZI_LcUsageLine
  as select from acdoca as opn
    left outer join acdoca as shp
      on  shp.rbukrs = opn.rbukrs
      and shp.xblnr  = opn.xblnr
      and shp.lifnr  = opn.lifnr
  association [0..1] to ZI_LcUsageVendor as _Supplier
    on $projection.Supplier = _Supplier.Supplier
{
  key opn.rbukrs                              as CompanyCode,
  key opn.belnr                               as OpenDocument,
  key opn.docln                               as OpenItem,
      opn.lifnr                               as Supplier,
      opn.rwcur                               as TransCurrency,
      opn.budat                               as OpenDate,
      @Semantics.amount.currencyCode: 'TransCurrency'
      opn.wsl                                 as OpenFc,
      @Semantics.amount.currencyCode: 'TransCurrency'
      shp.wsl                                 as UseFc,
      cast( opn.hsl as abap.dec(23,0) )       as OpenAmt,
      cast( coalesce( shp.hsl, 0 ) as abap.dec(23,0) ) as UsedAmt,
      cast( opn.hsl - coalesce( shp.hsl, 0 ) as abap.dec(23,0) ) as BalAmt,
      _Supplier
}

④ ZI_LcUsagePlan — 예정 금융비용

예정은 구매오더 조건에서 읽은 사용 외화 · 환율 · 이자율 · 일수 · 수수료로 같은 식을 풀어 둔 값입니다. 실적과 같은 차원 키를 가져야 칸 단위로 비교됩니다.

" ──────────────────────────────────────────────────────────
" ZI_LcUsagePlan — 예정 금융비용
" 역할 : 구매오더 조건 → 예정 사용 외화 · 환율 · 이자율 · 일수 · 수수료
" 이렇게 나눈 이유 : 예정 기준이 사람마다 달라지지 않게 한 곳에서 정의
" 주의 : 예정 이자율 원천(약정서·시장금리)은 확인 필요
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 신용장 예정 금융비용'
define view entity ZI_LcUsagePlan
  as select from ekpo as po
    inner join   ekko as ph on ph.ebeln = po.ebeln
{
  key ph.bukrs                                as CompanyCode,
  key po.ebeln                                as PurchaseOrder,
  key po.ebelp                                as PurchaseOrderItem,
      ph.lifnr                                as Supplier,
      ph.waers                                as TransCurrency,
      ph.inco1                                as Incoterms,
      po.matnr                                as Material,
      po.matkl                                as MaterialGroup,
      cast( 0 as abap.dec(23,0) )             as PlanCostAmt  " 예정 이자·수수료 산식은 확인 필요
}

⑤ ZI_LcUsageCube — 큐브

라인을 차원 조합 × 측정값으로 집계합니다. 이자 계산은 이 뷰 한 곳에서만 하고, 화면과 분석 도구는 이 값을 그대로 읽습니다.

" ──────────────────────────────────────────────────────────
" ZI_LcUsageCube — 신용장 사용·금융비용 큐브
" 역할 : 라인을 11개 차원 조합별로 집계 (측정값 6개)
" 이렇게 나눈 이유 : 금융비용 계산을 한 곳에서 한 번만 하려고
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 신용장 사용·금융비용 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_LcUsageCube
  as select from ZI_LcUsageLine
{
  key CompanyCode,
  key Supplier,
  key TransCurrency,
  key substring( OpenDate, 1, 6 )             as Period,
      @DefaultAggregation: #SUM
      OpenAmt,
      @DefaultAggregation: #SUM
      UsedAmt,
      @DefaultAggregation: #SUM
      BalAmt
      // 이자 · 수수료 · 금융비용은 이자 산정 기준 확정 뒤 추가 — 확인 필요
}
group by CompanyCode, Supplier, TransCurrency, substring( OpenDate, 1, 6 )

⑥ ZC_LcUsageQuery — 분석 쿼리

행 · 열 축과 필터, 계산항목을 쿼리에 둡니다. 화면이 서비스에서 받는 계산항목의 식도 이 쿼리에서 정의합니다.

" ──────────────────────────────────────────────────────────
" ZC_LcUsageQuery — 분석 쿼리
" 역할 : 행 · 열 축, 필터, 계산항목(금융비용률 · 사용률 등)
" 이렇게 나눈 이유 : 화면과 분석 도구가 같은 쿼리를 읽도록
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 신용장 사용·금융비용 쿼리'
@Analytics.query: true
define view entity ZC_LcUsageQuery
  as select from ZI_LcUsageCube
{
      @AnalyticsDetails.query.axis: #ROWS
  key Supplier,
      @AnalyticsDetails.query.axis: #COLUMNS
  key Period,
      @AnalyticsDetails.query.axis: #FREE
  key TransCurrency,
      @AnalyticsDetails.query.formula: 'UsedAmt / OpenAmt * 100'
      OpenAmt,
      UsedAmt,
      BalAmt
}

⑦ ZC_LcUsageQuery — 권한(DCL)

권한은 집계 단계에 걸어야 합계로 다른 조직의 숫자가 새지 않습니다. 회사코드 단위가 기본이고, 은행 단위가 필요하면 조건을 더합니다.

@EndUserText.label: '신용장 쿼리 권한'
@MappingRole: true
define role ZC_LcUsageQuery {
  grant select on ZC_LcUsageQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

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

쿼리와 차원을 OData로 노출합니다. 화면은 이 서비스 주소만 알면 되고, 앱의 서비스 주소만 바꾸면 운영 데이터로 전환됩니다.

@EndUserText.label: '수입 신용장 사용·금융비용 서비스'
define service ZUI_LcUsage {
  expose ZC_LcUsageQuery  as LcUsageQuery;
  expose ZI_LcUsageVendor as Vendor;
}
// 바인딩 : OData V2 - UI 로 서비스 바인딩을 만들고 활성화 (이름은 시스템 규칙에 맞춰 확인 필요)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여섯 가지는 코딩이 아니라 합의입니다.

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

리포트에서 가장 비싼 질문은 "이 숫자 맞아?"입니다. 검증용 샘플 데이터로 대사식을 전수로 돌린 결과입니다.

선적 미이행(사용 0) 라인 364건과 계획 외 개설 라인 226건은 의도적 예외로, 대사 차이와 분리해 기록했습니다.

운영 데이터로 갈 때

1. 합의 — 위 여섯 가지 항목을 먼저 정합니다.
2. CDS 작성과 이송 — 기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스 순서로 만들고 이송합니다.
3. 서비스 활성화와 주소 교체 — 서비스를 활성화하고 앱의 서비스 주소만 바꿉니다.
4. 병행 대사 — 한두 기간은 표준 화면과 병행해 대사합니다.

자주 묻는 질문

숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영 순서로 모았습니다. 숫자는 모두 검증용 샘플 데이터 기준입니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영