수입 신용장(L/C) 수수료 다차원 분석 — 개설·인수 수수료의 계획 대비 차이를 여섯 요인으로 가르고 원천 라인까지 내려가는 수입 자금 점검

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

수입 신용장 수수료 점검의 질문은 늘 같습니다. 수수료가 계획보다 얼마나 늘었나, 왜 늘었나, 누가 무엇을 확인해야 하나. 신용장은 개설할 때 개설 수수료가, 인수할 때 인수 수수료가, 서류에 하자가 있거나 조건을 바꾸면 가산 수수료가 붙고, 외화 금액은 환율을 곱해야 원화 대상 금액이 됩니다. 한 건씩은 작은 금액이지만 은행 · 결제 조건 · 공급사 · 통화가 섞이면 합계가 왜 움직였는지 설명하기 어렵습니다. 환율 영향은 IAS 21 환율변동효과(K-IFRS 제1021호) 관점에서도 따로 볼 필요가 있습니다.

지금은 구매오더(ME23N), 송장(MIRO), 공급사 개별 항목(FBL1N)을 번갈아 열고 엑셀에서 은행 통지서와 신용장별로 수수료를 다시 맞춰 보는 방식이 많습니다. 이 앱은 그 자리에 같은 데이터를 한 번 묶은 큐브를 놓고, 축을 바꿔 가며 보고, 칸에서 원천 수수료 라인까지 내려가고, 계획과의 차이를 여섯 요인으로 가르는 점검 화면을 더합니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 수수료 +402.3백만원 증가의 이유

검증용 샘플 데이터(2026년 4월~9월, 수수료 라인 3,077건 · 신용장 1,073건) 기준으로 수수료는 계획 2,763.5백만원에서 실적 3,165.8백만원으로 +402.3백만원(+14.6%) 늘었습니다. 합계 리포트는 여기까지 말해 줍니다. 이 앱은 그 다음을 답합니다 — 여섯 요인으로 가르자 증가분의 약 58%(+232.0)가 직전 계획에 없던 신용장 라인에서 났고, 그 다음이 대상 금액(+68.4)과 요율(+61.2)이었습니다. 환율은 +28.9, 정액과 가산은 합쳐도 작았습니다.

요인의 크기는 샘플 데이터의 가정값에서 나온 것이며, 실제 환경의 크기를 말하는 것이 아닙니다. 중요한 것은 같은 화면에서 “어느 요인이 얼마” 가 바로 나온다는 점입니다.

도입하면 달라지는 것

• 월 점검 준비 — 요인분해 · 사유 · 보고서가 한 화면에서 나오므로 엑셀 취합과 캡처 작업이 줄어듭니다.
• 회의의 주제 — “어느 시트 숫자가 맞나” 가 아니라 “어느 은행 · 어느 조건을 어떻게 할 것인가” 를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아, 매달 같은 설명을 처음부터 다시 하지 않습니다.
• 놓치는 날이 없는 감시 — 아무도 화면을 열지 않은 날에도 규칙에 걸린 숫자는 받을 사람에게 올라갑니다.

이런 회사에 맞습니다

해외에서 원자재 · 상품을 들여오며 신용장으로 결제하고 여러 은행과 거래하는 회사, 은행 수수료를 엑셀로 맞추고 있는 자금 · 회계 조직, 그리고 구매 · 자금 · 물류가 수수료 숫자를 함께 확인해야 하는 경영지원 조직에 맞습니다. 이 화면은 점검 자료이며, 수수료의 회계 처리와 세무상 취급은 회사와 감사인이 판단합니다.

실행 화면

실제로 돌아가는 화면 32종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 어떻게 읽는지를 아래에 적었습니다. 모든 캡처는 가상의 검증용 샘플 데이터로 찍었습니다.

사용 방법

1. 조회조건을 넣습니다. 회사코드(필수)와 시작 · 종료 기간(필수)을 고르고, 필요하면 개설은행 · 공급사 같은 차원 값을 여러 개 골라 범위를 좁힙니다. 비워 두면 전체입니다.
2. 조회를 누릅니다. 조회조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 를 누릅니다. 자동 조회는 저장한 레이아웃에서 지정한 경우에만 화면을 열 때 실행됩니다.
3. 요약을 봅니다. 경영 요약에서 수수료 합계 · 총 수수료율 · 대상 금액 · 가산 비중을 계획과 함께 보고, 역할을 바꿔 앞세우는 지표를 바꿉니다.
4. 축과 탭을 옮깁니다. 차원 칩을 끌어다 놓아 행 · 열을 짜고, 표시 항목 · 금액 단위 · 비교 기준을 바꿉니다. 결과 영역에서는 표와 막대 · 요인 워터폴을 오갑니다.
5. 행이나 칸을 눌러 내려갑니다. 숫자 칸을 누르면 원천 수수료 라인이 열리고, 차이 모드에서 행 이름을 누르면 그 범위로 요인분해가 계산되며, 사유 칸을 누르면 변동 사유를 적습니다.
6. 내보냅니다. 결과 영역의 CSV 버튼은 피벗을, 드릴스루 창의 CSV 버튼은 읽은 원천 라인을 내려받습니다. AI 분석 창에서는 PPTX 보고서를 만듭니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤과 직접 그린 SVG 차트로만 짰고, 서비스 쪽은 OData V2 규격을 따르는 서비스 한 벌입니다. 아래는 모델 구성 수준으로 적은 구성입니다.

처음 열었을 때

조회조건부터 피벗까지가 한 화면에 세로로 쌓입니다. 머리 영역은 접을 수 있어서, 축을 짜는 동안에는 펼쳐 두고 숫자를 볼 때는 접어 표와 차트를 넓게 씁니다.

빈 화면을 주지 않습니다. 틀이 먼저 서 있어서 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 봅니다. 회사코드 1000, 기간 2026.04 ~ 2026.09 가 기본값이고 조회 버튼은 조회조건 영역의 오른쪽 끝에 있습니다.

행은 자재그룹, 열은 개설월이 기본 배치입니다. 값은 백만원 단위의 수수료 합계이며, 괄호 없는 숫자 옆에 계획 대비 증감이 붙습니다. 이후 축을 바꾸는 일은 서버를 다시 부르지 않고 브라우저에서 합니다.

칩을 끌어다 놓거나 화살표 버튼으로 옮깁니다. 행 축은 최대 3단계, 열 축은 최대 2단계까지 쌓입니다. 쓰지 않는 차원은 왼쪽 칸에 모아 둡니다.

서버를 다시 부르지 않으므로 반응이 즉시입니다. 행 · 열 바꾸기와 기본 축 버튼으로 언제든 되돌릴 수 있고, 총합은 축을 바꿔도 같습니다.

접힌 줄에는 지금 어떤 범위를 보고 있는지가 남아 있어, 범위를 잊은 채 숫자를 읽는 일을 막습니다.

경영 요약 — 역할마다 앞세우는 숫자가 다르다

경영 요약은 역할을 바꾸면 앞세우는 지표와 기본 행 축이 바뀝니다. 같은 큐브에서 나온 숫자이므로 역할을 바꿔도 다시 조회하지 않습니다.

계획 초과 상위와 미달 상위가 나란히 보여 어디부터 볼지 정해 줍니다. 샘플 전체 총 수수료율은 약 0.30% 입니다.

어느 공급사 건에서 수수료 부담이 큰지를 먼저 봅니다. 결제 조건 재협상이나 발주 방식 조정이 필요한 후보를 고르는 자리입니다.

은행마다 요율과 가산 비중을 비교해 약정 협의의 근거로 씁니다.

서류 하자나 조건변경이 몰리는 곳을 가려 선적 서류 준비 절차를 점검합니다.

축 전환과 범위

차원은 열 개가 넘고, 각 차원은 값을 여러 개 골라 범위를 좁힐 수 있습니다. 어떻게 쌓고 좁혀도 합계가 갈라지지 않는 것이 이 절의 기준입니다.

열 조합이 너무 많아지면 더 추가할 수 없고, 읽을 수 없는 표를 그리지 않도록 막습니다.

같은 차원 안에서는 or, 차원 사이에서는 and 로 묶입니다. 선택한 범위는 조회 조건 요약 줄에 표시됩니다.

범위를 좁혀도 같은 큐브에서 거르는 것이므로 합계가 일관됩니다. 좁힌 상태에서 요인분해를 보면 그 범위의 차이만 가릅니다.

칸에서 원천 수수료 라인까지

집계 화면에서 가장 많이 나오는 말은 이 숫자의 근거가 무엇이냐는 것입니다. 숫자 칸을 누르면 그 칸을 이룬 신용장 품목 라인이 열립니다.

읽는 단위는 표시 행 수와 별도로 정할 수 있고, CSV 로 내려받을 수 있습니다.

샘플 검증에서 확인한 6칸 모두 같았습니다.

차이 열이 모두 0 입니다. 요약 표에서 개설월별 대상 금액 · 수수료 · 계획 · 가산 라인 수를 한눈에 봅니다.

계산항목 — 차원으로는 나오지 않는 행

총 수수료율이나 가산 비중은 합산으로는 안 나옵니다. 칸마다 분자와 분모를 각각 합산한 뒤 나누어야 하기 때문입니다.

비율을 행으로 평균 내면 숫자가 틀어집니다. 서비스가 내려주는 토큰 식으로 칸마다 다시 계산합니다.

구성비도 같은 방식입니다. 합계 행에서도 맞는 비율이 나옵니다.

계획 대비 차이 — 같은 표가 월 점검 자료가 된다

비교 기준을 바꾸면 같은 표가 차이 리포트가 됩니다. 칸마다 계획 · 실적 · 차이 · 차이율이 붙습니다.

붉은색은 수수료를 늘린 쪽, 초록색은 줄인 쪽입니다. 임계는 금액 100만원 · 비율 10퍼센트가 기본이며 샘플의 가정값입니다.

검산 줄이 요인 합 − 총차이 = 0원 으로 표시됩니다. 계획 2,763.5백만원에서 실적 3,165.8백만원까지 +402.3 입니다.

전체가 아니라 특정 은행이나 자재그룹만 따로 가를 수 있고, 어느 범위에서도 검산 줄은 0 입니다.

원인 요인과 차이 금액이 함께 저장됩니다.

사유는 조회 범위와 행 경로를 키로 서비스에 저장되어 새로 고침해도 남고, CSV 와 AI 분석 근거에 함께 실립니다.

AI 분석과 보고서

표 위 AI 분석은 지금 보고 있는 범위를 읽어 줍니다. 금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고, 해설은 그 숫자를 문장으로 옮길 뿐입니다.

외부 AI 연결을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다. 판단은 사람이 합니다.

근거 표의 숫자는 화면 숫자와 같은 출처입니다. 표와 차트를 담은 PowerPoint 보고서(표지 · 요약 · 핵심 발견 · 차트 · 표 · 근거)를 브라우저에서 바로 내려받습니다.

AI 에이전트

화면을 열어야만 점검되는 구조는 놓치는 날이 생깁니다. 에이전트는 감시 규칙을 돌려 걸린 항목을 받을 역할의 대기함에 올립니다.

샘플에는 여섯 개가 있습니다. 개설은행 가산 비중 상한, 결제 조건별 요율 상한, 공급사 하자·변경 라인 비율, 대상 금액 · 환율 · 요율 요인 영향 임계입니다.

같은 숫자도 받는 사람에 따라 다시 적어 올립니다. 자금 책임자는 은행 관점, 구매 책임자는 공급사 관점입니다.

하루에 한 번만 실행되고, 두 번째 실행은 제한됨으로 판정되어 기록됩니다. 판단은 서비스가 하므로 배치 잡이 같은 호출을 해도 결과가 같습니다.

레이아웃 저장과 복원

축을 짜 두고 다음에 또 쓰려면 저장해 두어야 합니다.

기본 레이아웃과 자동 조회를 지정할 수 있습니다.

기본 표시가 붙은 항목이 화면을 열 때 쓰입니다.

저장한 행 축이 그대로 복원됩니다.

좁은 화면과 열 조합이 많은 구성

표는 가로로 스크롤됩니다. 다만 축을 짜는 일은 넓은 화면이 편합니다.

조합이 상한을 넘으면 표를 반쯤 그리는 대신 범위를 좁히라는 안내를 보여 줍니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스에서 큐브와 계획을 한 번 읽어 와 브라우저가 들고 있고, 축을 바꾸는 모든 조작은 그 위에서 일어납니다. 칸을 눌러 원천 라인으로 내려갈 때만 서비스를 다시 부릅니다. 이때 칸의 조건이 그대로 조회 조건이 됩니다.

수수료 산출과 점검 규칙

신용장 품목(라인) 단위로 수수료를 요율 수수료 · 정액 수수료 · 하자·조건변경 가산으로 나누어 계산하고 그 합을 큐브에 묶습니다. 아래 판정은 모두 “점검 필요” 수준의 안내이며, 수수료의 회계 처리는 회사와 감사인이 판단합니다.

산출 순서

1. 수수료 대상 금액 = 외화 금액 × 환율
2. 요율 수수료 = 대상 금액 × 요율 ÷ 100 (개설 · 인수 라인)
3. 수수료 합계 = 요율 수수료 + 정액 수수료 + 하자·조건변경 가산
4. 총 수수료율 = 수수료 합계 ÷ 대상 금액 × 100, 가산 비중 = 가산 ÷ 수수료 합계 × 100

요인분해 처리 단계와 대사식

계획값에서 실적값으로 한 번에 한 요인씩 바꿔 같은 식을 다시 계산합니다. 요인은 대상 금액 · 요율 · 환율 · 정액 수수료 · 하자·조건변경 가산 · 계획 없던 건의 여섯 가지이고, 요인 합은 총차이와 같습니다. 대사식은 네 가지입니다: 큐브 합계 = 원천 라인 합계, 계획 큐브 합계 = 원천 라인 계획 열 합계, 라인 수수료 재계산 = 저장 수수료, 요인 합 − 총차이 = 0.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

이 화면은 표와 차트를 한 줄에 나란히 두고 씁니다. 창이 좁아지면 차트를 감추지 않고 표 아래로 내려, 휴대폰에서도 같은 리포트를 봅니다. 표는 가로로 스크롤됩니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json · readme.html
├─ view/ · controller/ · model/ (cube · chart · layout · pptx · formatter · ErrorHandler)
├─ i18n/ · css/ · media/ (소개 영상 · 포스터 · 챕터)
├─ odata/lcfee_srv/ metadata.xml · service.js · core.js · json/*.json
└─ test/ (검증 전용 — 앱 본체는 읽지 않습니다)

SAP 표준 기능 확장 포인트

이 앱은 표준을 대체하지 않고 표준이 비어 있는 자리를 채웁니다. 어디까지가 표준이고 어디부터가 이 앱인지를 표로 적었습니다.

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

신용장 개설 조건 확인, 송장 입력, 공급사 개별 항목 조회는 표준 화면으로 충분합니다. 표준으로 어려운 것은 같은 수수료를 은행 · 결제 조건 · 공급사 · 통화로 돌려 보면서 계획과의 차이를 요인으로 설명하는 일입니다.

T-code 별 연계 지점

요구사항 매핑표

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

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

CDS 구성

운영 연결에서는 샘플의 서비스 대신 CDS 뷰가 같은 모양의 OData 서비스를 냅니다. 아래 코드는 구조를 보여 주는 스케치이며, 테이블 · 필드 이름은 고객사 환경에서 확인하고 고쳐 씁니다.

뷰 레이어 구성

① 분류 매핑 테이블과 계획 스냅숏 테이블

수수료 유형과 결제 조건 분류는 코드가 아니라 테이블 행으로 둡니다. 계획은 매 기간 시작 때 스냅숏으로 고정해야 차이 비교가 흔들리지 않습니다. 테이블 이름과 필드는 스케치이며 고객사 구조에 맞춰 정합니다.

@EndUserText.label : '수입 L/C 수수료 분류 매핑'
define table zimp_lcfee_map {
  key client     : abap.clnt not null;
  key map_type   : abap.char(8) not null;   " FEETYPE / TERM / BAND
  key code       : abap.char(10) not null;
  valid_from     : abap.dats;
  valid_to       : abap.dats;
  group_text     : abap.char(40);
}
@EndUserText.label : '수입 L/C 수수료 계획 스냅숏'
define table zimp_lcfee_plan {
  key client     : abap.clnt not null;
  key plan_ver   : abap.char(5) not null;
  key lc_no      : abap.char(12) not null;
  key item_no    : abap.numc(3) not null;
  plan_amt_fc    : abap.curr(15,2);
  plan_fee_rate  : abap.dec(15,4);
  plan_fx        : abap.dec(15,5);
}

② 공급사 차원 뷰

공급사 이름은 마스터에서 읽어 큐브와 분리합니다. 차원 뷰를 따로 두면 이름이 바뀌어도 큐브를 다시 만들 필요가 없습니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
define view entity ZI_ImpLcFeeSupplier
  as select from lfa1
{
  key lifnr as Supplier,
      name1 as SupplierName,
      land1 as Origin
}

③ 수수료 라인 기초 뷰

신용장 개설 조건과 은행 수수료 전표를 품목 단위 한 줄로 모으는 기초 뷰입니다. 대상 금액 · 요율 · 수수료 구성은 여기서 파생합니다. 원천 테이블의 필드는 환경마다 다르므로 확인이 필요합니다.

@AccessControl.authorizationCheck : #CHECK
define view entity ZI_ImpLcFeeLine
  as select from ekko as h
    inner join   ekpo as i on i.ebeln = h.ebeln
    left outer join zimp_lcfee_open as o on o.ebeln = i.ebeln and o.ebelp = i.ebelp
{
  key h.bukrs                              as CompanyCode,
  key o.lc_no                              as LcNo,
  key o.item_no                            as ItemNo,
      h.lifnr                              as Supplier,
      i.werks                              as Plant,
      h.waers                              as Currency,
      o.bank                               as Bank,
      o.open_date                          as OpenDate,
      o.amt_fc                             as AmountFc,
      o.fx_rate                            as FxRate,
      o.fee_rate                           as FeeRate,
      cast( o.amt_fc * o.fx_rate as abap.curr(23,0) )                         as LcAmount,
      cast( o.amt_fc * o.fx_rate * o.fee_rate / 100 as abap.curr(23,0) )      as BaseFee,
      o.fixed_fee                          as FixedFee,
      o.extra_fee                          as ExtraFee
}

④ 실적 큐브

기초 뷰를 차원 조합으로 더한 큐브입니다. 측정값마다 합계 집계 방식을 선언하고 통화 필드를 붙입니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수입 L/C 수수료 실적 큐브'
define view entity ZI_ImpLcFeeActualCube
  as select from ZI_ImpLcFeeLine
{
  key CompanyCode,
  key substring( OpenDate, 1, 6 ) as OpenPeriod,
  key Supplier,
  key Plant,
  key Bank,
  key Currency,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      LcAmount,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      BaseFee,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      FixedFee,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      ExtraFee,
      @Aggregation.default : #SUM
      1 as LineCount
}

⑤ 계획 큐브

실적 큐브와 같은 차원 · 같은 측정값 이름으로 계획 스냅숏을 묶습니다. 이름과 차원이 같아야 두 큐브를 나란히 놓고 차이를 낼 수 있습니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수입 L/C 수수료 계획 큐브'
define view entity ZI_ImpLcFeePlanCube
  as select from zimp_lcfee_plan as p
{
  key p.plan_ver                                     as PlanVersion,
  key p.lc_no                                        as LcNo,
      @Aggregation.default : #SUM
      cast( p.plan_amt_fc * p.plan_fx as abap.curr(23,0) ) as PlanLcAmount,
      @Aggregation.default : #SUM
      cast( p.plan_amt_fc * p.plan_fx * p.plan_fee_rate / 100 as abap.curr(23,0) ) as PlanBaseFee
}

⑥ 분석 쿼리

행 · 열 기본 배치와 계산 측정값을 선언합니다. 총 수수료율은 합산이 아니라 분자와 분모를 각각 더한 뒤 나누는 식으로 둡니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 L/C 수수료 분석'
@Analytics.query : true
define view entity ZC_ImpLcFeeQuery
  as select from ZI_ImpLcFeeActualCube
{
      @AnalyticsDetails.query.axis : #ROWS
  key Bank,
      @AnalyticsDetails.query.axis : #ROWS
  key Supplier,
      @AnalyticsDetails.query.axis : #COLUMNS
  key OpenPeriod,
      @EndUserText.label : '요율 수수료'
      BaseFee,
      @EndUserText.label : '수수료 대상 금액'
      LcAmount,
      @EndUserText.label : '요율 수수료율(%)'
      @AnalyticsDetails.query.formula : 'BaseFee / LcAmount * 100'
      @AnalyticsDetails.query.decimals : 3
      cast( 0 as abap.dec(9,3) ) as BaseFeeRate
}

⑦ 권한 (DCL)

집계 화면에서 권한을 드릴스루에만 걸면, 권한 없는 사람이 전체 합계와 자기 몫의 차이를 빼서 다른 범위의 숫자를 알아냅니다. 그래서 큐브를 읽는 자리에 겁니다. 권한 객체 이름은 환경에 맞게 확인합니다.

@EndUserText.label : '수입 L/C 수수료 큐브 권한'
@MappingRole : true
define role ZI_IMPLCFEEACTUALCUBE {
  grant select on ZI_ImpLcFeeActualCube
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( Plant )       = aspect pfcg_auth ( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의

쿼리를 OData 서비스로 게시하는 자리입니다. 서비스 바인딩에서 OData V2 를 선택해 게시하고, 활성화 후 화면 쪽 manifest 의 서비스 주소를 바꿉니다.

@EndUserText.label : '수입 L/C 수수료 분석 서비스'
define service ZUI_ImpLcFeeAnalysis {
  expose ZC_ImpLcFeeQuery as LcFeeQuery;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 전수로 돌렸습니다. 아래는 이 사례(가상 샘플 데이터) 기준 결과입니다.

모든 대사식이 차이 0 입니다. 의도적으로 섞어 둔 예외는 “계획 없던 라인” 375건이며, 오류가 아니라 요인으로 분리해 합계에 포함했습니다. 화면 쪽은 이와 별도로 브라우저 자동화로 돌려 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 라인 합계가 같은지, 변동 사유와 레이아웃이 새로 고침 뒤에도 남는지를 확인했습니다.

운영 데이터로 갈 때 — 수수료 라인이 수백만 건이면

이 사례는 수수료 라인 3,077건이 큐브 11,752행이 됩니다. 라인이 늘어도 큐브 행 수는 라인 건수가 아니라 차원 조합 수를 따라갑니다. 문제는 조합이 많을 때입니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

AI 분석과 에이전트

도입과 운영