SAP 보험료 납부 자금 다차원 분석 리포트 — 납부 계획 대비 차이를 요인으로 가르고 원천 문서까지 내려가는 월 자금 점검

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

월 자금 회의의 질문은 늘 비슷합니다. 보험료로 이번 달 얼마가 나갔나, 계획과 얼마나 달랐나, 왜 달랐고 누가 무엇을 확인해야 하나. 지금은 이 세 답이 표준 화면 · 은행 자료 · 엑셀 · 회의 메모로 흩어져 있고, 보험 계약이 법인 · 은행 · 통화에 걸쳐 있을수록 숫자를 맞추는 일이 회의보다 길어집니다. 이 화면은 세 답을 한 화면에 붙여, 납부 현황을 만드는 손일을 줄이고 점검할 곳을 먼저 가리킵니다.

표준 실행은 SAP 표준 화면이 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 납부 계획 대비 차이를 일곱 요인으로 나누고, 사유를 행에 남기고, 기준을 넘은 숫자를 사람이 열지 않아도 대기함에 올립니다. 그리고 그 숫자가 원천 납부 라인과 어긋나지 않는지를 매번 스스로 대사합니다. 대상 영역은 보험료 납부 자금 점검이며, 회계 · 세무 판단은 이 화면이 아니라 회사와 감사인, 세무 대리인의 몫입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(2026년 1~9월, 법인 3개, 은행 5곳, 통화 5종)에서 순납입액은 855.31억 원, 납부 계획은 859.97억 원으로 총차이는 −4.66억 원(계획 대비 99.5%)였습니다. 합계만 보면 ‘계획보다 아주 조금 덜 나갔다’에서 끝납니다. 일곱 요인으로 가르면 모습이 달라집니다. 계획에 없던 납부가 +26.26억 원, 계획만 있고 납부가 나오지 않은 몫이 −34.12억 원으로 서로 크게 반대로 움직였고, 그 사이에서 약정 보험료 변동 −0.18, 환율 효과 −0.18, 추가 보험료 반영 +3.35, 환급·할인 효과 +0.20, 납부월 이동 0.00(억 원)이 남았습니다. 계획 + 요인 합 − 실적은 0 이며 화면이 이 검산을 매번 보여 줍니다.

반대로 움직이는 두 큰 요인이 서로를 가리고 있다는 사실은 합계 표에서는 보이지 않습니다. 이 차이를 ‘계획 외 납부’와 ‘계획 납부 미발생’으로 나누어 놓았기 때문에 회의가 ‘왜 조금 덜 나갔나’가 아니라 ‘계획에 없던 납부는 무엇이고, 나오지 않은 납부는 해지 · 갱신 불발 · 면제 · 협의 이연 중 무엇인가’로 시작할 수 있습니다. 원인은 이 화면이 단정하지 않으며 점검할 곳을 가리킵니다. 위 숫자는 모두 가상의 샘플 값입니다.

도입하면 달라지는 것

• 월 자금 회의 자료 — 차이 표 · 요인 분해 · 사유 · 검토 자료가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — ‘어느 숫자가 맞나’ 대신 ‘무엇을 할 것인가’를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 보기가 남아 같은 설명을 다시 하지 않습니다.
• 놓치지 않는 점검 — 아무도 화면을 열지 않아도 기준을 넘은 숫자가 대기함에 올라옵니다.

이런 회사에 맞습니다

재산종합 · 기계장비 · 배상책임 · 적하 · 신용보증 등 여러 보험 종류의 보험료가 정기적으로 나가고, 법인과 지급 은행, 통화가 여러 개라 월 단위로 계획과 실적을 맞춰 보는 회사에 맞습니다. 특히 납부 계획과 실제 납부가 다른 이유를 자금팀 · 회계팀이 매달 따로 설명해야 하는 조직, 그리고 표준 화면은 유지하면서 분석 관점만 더하고 싶은 SAP 운영 조직에 맞습니다. 반대로 보험 계약이 몇 건 안 되고 한 은행 · 한 통화뿐이라면 표준 화면과 엑셀로 충분할 수 있습니다.

실행 화면

검증용 샘플 데이터(가상의 법인 · 은행 · 보험 종류)를 실제 브라우저에서 찍은 화면 33종입니다. 그림을 누르면 크게 볼 수 있습니다.

사용 방법

1. 조회조건 입력 — 법인(비우면 전체), 기간 부터 · 까지(필수), 비교 기준(납부 계획과 비교 · 비교 안 함)을 정합니다.
2. 조회 — [조회] 단추를 누르거나 조건 칸에서 Enter 키를 누릅니다. 큐브는 이때 한 번만 읽고 이후 축을 바꿔도 다시 읽지 않습니다.
3. 요약 확인 — 위쪽 지표 카드와 조건 요약 한 줄을 봅니다. 조건 영역은 접을 수 있습니다.
4. 보는 사람 · 축 이동 — 경영 · 재무 · 자금 · 회계 중 관점을 고르고, 차원 칩을 행 축 · 열 축으로 올립니다(행 최대 3단계, 열 최대 2단계).
5. 행 · 칸 클릭 — 행을 펼쳐 하위 차원으로 내려가고, 칸을 눌러 원천 납부 문서 라인을 엽니다.
6. 차이 · 사유 — [계획 차이]를 켜 실적 · 계획 · 차이를 보고, 행을 골라 요인 분해를 확인하고, [변동 사유]로 사유를 적습니다.
7. 해설 · 에이전트 · 보기 저장 — [해설]로 근거 표가 붙은 초안과 보고서를, [에이전트]로 점검 규칙 실행을, [보기 저장]으로 배치 저장을 합니다.
8. 내보내기 — 오른쪽 위 [CSV]로 현재 표를 내려받습니다.

무엇으로 만들었나

화면은 SAP UI5 표준 컨트롤과 직접 그린 SVG 차트로 이루어져 있고, 데이터는 OData V2 서비스를 통해 가져옵니다. 서비스는 차원 · 측정값 · 큐브 · 납부 계획 · 원천 납부 문서 라인 · 큐브 검산 · 변동 사유 · 저장한 보기 · 에이전트 규칙 · 대기함 · 활동 기록 등 열네 가지 조회 대상과 세 가지 계산 호출(차이 요인 분해 · 해설 근거 · 에이전트 실행)로 나뉩니다.

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

화면을 열면 조회를 누르기 전에도 조회조건 · 보는 사람 · 차원 보관함 · 행 축과 열 축 · 피벗 틀이 먼저 뜹니다. 어디에 무엇이 놓이는지 눈으로 익힌 뒤 조회하게 하려는 구성입니다.

조건을 넣고 [조회] 단추(또는 Enter)를 누르면 큐브를 한 번 읽어 옵니다. 기간은 2026년 1월~9월이 기본이고 법인을 비우면 전체 법인입니다. 조회 전에는 숫자가 없다는 점이 분명하도록 틀만 보여 줍니다.

위 카드는 순납입액 855.31억 원, 최대 비중 보험 종류 45.6%, 지연 납부 비중 12.2%, 계획 대비 차이 −4.66억 원처럼 지금 범위의 요약입니다. 표와 차트는 같은 계산 결과를 그리므로 어느 쪽을 봐도 합계가 같습니다.

접어도 조건 요약 한 줄은 남아 지금 어떤 범위를 보고 있는지 잊지 않게 합니다. 회의 때 화면을 크게 띄워 놓고 이야기할 때 쓰는 모습입니다.

보는 사람 탭 — 앞세우는 숫자가 다릅니다

같은 큐브를 경영 · 재무 · 자금 · 회계 네 관점으로 읽을 수 있습니다. 탭을 고르면 첫 줄 안내와 기본 행·열 축, 기본 측정값이 그 사람의 질문에 맞게 바뀌며 다시 조회하지는 않습니다.

행은 보험 종류, 열은 분기입니다. 집중도 지수(2,854)가 카드에 함께 있어 한 종류에 쏠린 정도를 숫자로 말할 수 있습니다.

법인별로 추가 보험료가 어디서 반영됐는지, 환급·할인이 어디서 크게 났는지 점검할 곳을 가립니다.

지연 납부 비중과 기말 미납 잔액이 어느 은행 · 월에 몰렸는지 먼저 봅니다.

이견 보류 후 납부 건이 어느 보험 종류에 있는지 확인하고 표준 화면에서 처리하도록 이어 줍니다.

축 전환과 범위 — 보고 싶은 단면으로 바로

차원 보관함의 칩을 눌러 행 축 · 열 축에 올리고, 값 필터로 범위를 좁힙니다. 열 축은 두 단계까지입니다.

서버를 다시 부르지 않고 이미 읽어 온 큐브를 브라우저에서 다시 묶기 때문에 응답이 즉시입니다.

합계는 어느 배치에서도 같아야 하며, 그 검산은 아래 검증 절에 있습니다.

고른 값은 표뿐 아니라 요약 카드, 차트, 원천 라인에도 같은 범위로 적용됩니다.

필터 후 합계와 큐브 합계가 일치하는지 검증 절에서 확인했습니다.

같은 차트에서 지급 계획이 있으면 막대가 쌍으로 나옵니다.

넓은 열 구성은 표를 넓히고, 비교 차트가 필요하면 차트를 넓힙니다.

칸에서 원천 문서까지 — 숫자를 의심할 때의 길

표의 숫자 칸을 누르면 그 값을 만든 원천 라인이 열리고, 칸의 값과 원천 합계가 같은지 일치 여부가 나옵니다.

어느 은행 · 어느 달의 납부인지 라인마다 문서번호와 납부일, 약정 보험료, 거래통화 금액과 환율이 보입니다. 원천 라인에서 표준 화면으로 이동할 때는 문서번호를 씁니다.

라인 수가 많으면 위에서부터 일정 개수만 보이며, 전체는 CSV 로 받습니다.

기간별 요약은 서비스가 따로 계산한 값을 쓰며 카드와 같은 숫자입니다.

계산항목 — 식으로 정의한 비율

건당 순납입액, 추가 보험료 비율, 환급·할인율, 지연 납부 비중, 조기 납부 비중, 납부 비중을 계산항목으로 둡니다. 식은 측정값 이름으로 적고 서비스가 정의를 내려줍니다.

비율은 합계 행에서도 분자와 분모를 각각 더한 뒤 나누므로 행마다 평균을 내는 방식과 다릅니다.

측정값이 둘 이상이면 열 머리의 마지막 단계에 측정값 이름이 붙습니다.

납부 계획 대비 차이 — 같은 표가 자금 회의 자료가 됩니다

계획 차이 스위치를 켜면 같은 표가 실적 · 계획 · 차이 · 차이율이 됩니다. 금액 기준과 비율 기준을 모두 넘는 칸은 붉은 글씨로 표시됩니다.

색은 점검이 필요하다는 신호일 뿐 원인을 단정하지 않습니다. 금액 · 비율 기준은 화면에서 바꿉니다.

샘플에서는 계획 납부 미발생 −34.12억 원, 계획 외 납부 +26.26억 원, 추가 보험료 반영 +3.35억 원이 크게 보입니다.

검산 값은 0 이어야 하며 화면이 매번 같은 줄로 보여 줍니다. 0 이 아니면 요인 분해를 신뢰하기 전에 범위와 원천 라인을 점검해야 합니다.

같은 화면에서 범위만 바꿔 어느 달에 요인이 몰리는지 확인합니다.

사유는 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도 다시 열면 따라옵니다.

같은 질문을 매달 다시 하지 않도록 사유를 남기는 장치입니다. 사유의 정확성은 담당자가 점검해야 합니다.

AI 분석과 보고서 — 숫자는 서비스가, 설명은 그 위에서

해설 단추는 현재 범위의 요약과 핵심 발견 초안을 만듭니다. 금액과 비율은 서비스가 큐브에서 계산하고, 문장은 그 근거 표 위에서만 규칙으로 씁니다. 모델 연결은 설정 하나로만 켜며 기본은 꺼져 있습니다.

샘플에서 순납입액 855.31억 원, 계획 859.97억 원, 차이 −4.66억 원(계획 대비 99.5%)이고 가장 큰 요인은 계획 납부 미발생입니다. 외부에 쓰기 전에 숫자와 표현을 점검하세요.

보고서 PPTX 는 같은 해설과 요인 폭포를 담은 검토용 초안으로 내려받습니다.

AI 에이전트 — 사람이 열지 않아도 도는 점검

규칙마다 지표와 기준값, 받을 역할이 붙어 있고, 실행하면 걸린 항목이 대기함에 올라갑니다. 하루 한 번만 실행된다는 제한은 서비스가 판정합니다.

기준값은 샘플 값이며 운영에서는 자금팀 · 재무가 정해야 합니다 — 확인 필요.

에이전트는 판단을 대신하지 않고 점검이 필요한 항목을 알려 주는 역할입니다.

실행 이력은 AgentRunSet 에 남습니다.

보기 저장과 복원 — 회의마다 같은 모양으로

현재 축 · 측정값 · 보는 사람 탭 · 값 필터 · 계획 차이 설정을 이름을 붙여 저장하고 다시 적용합니다. 기본으로 두고 자동 조회를 켜면 화면을 열 때 바로 조회합니다.

저장한 보기는 LayoutSet 에 남아 다른 날에도 같은 모양으로 열립니다.

기본 보기는 하나만 둘 수 있습니다.

복원은 다시 조회하지 않고 받아 둔 큐브에서 다시 묶습니다.

한도 — 열이 너무 많을 때

열 조합이 36개를 넘으면 추가를 되돌리고 안내합니다. 표와 차트가 읽을 수 없는 상태가 되지 않도록 하는 장치입니다.

열 축에서 한 단계를 빼거나 값 필터로 범위를 좁힙니다.

화면 뒤에서 일어나는 일

조회 버튼은 큐브 · 계획 · 기간 요약 · 값 목록 · 측정값 · 계산항목을 한 번에 읽습니다. 피벗은 그 큐브를 브라우저에서 다시 묶고, 칸을 누르면 같은 조건의 원천 라인(ItemSet)을 따로 읽어 합계를 대조합니다. 차이 요인과 해설은 서비스가 계산해 돌려줍니다. 변동 사유 · 보기 · 에이전트 보고와 활동 기록은 서비스에 저장됩니다.

차이 요인 판정

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

좁은 화면에서는 요약 카드 · 표 · 차트가 세로로 쌓이도록 만들었고, 열이 많은 표는 가로로 넘겨 봅니다. 휴대폰에서도 조회 · 축 전환 · 칸 확인은 가능하지만 열 두 단계의 넓은 표는 큰 화면에서 보는 편이 낫습니다.

파일 구성

fi_app_folder/
├─ index.html · Component.js · manifest.json
├─ controller/ · view/ (+ fragments/)
├─ model/   cube.js · chart.js · pptx.js · layout.js · formatter.js · ErrorHandler.js
├─ css/ · i18n/
├─ odata/inscash_srv/  metadata.xml · service.js · calc.js · json/ (14개 엔티티셋)
├─ media/   intro.mp4 · intro_poster.jpg · intro_chapters.vtt
├─ test/    검증 전용(샘플 데이터로 화면을 여는 곳)
└─ readme.html

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 법정 · 감사 · 세무 신고 대응은 표준 화면에 그대로 두고, 이 화면은 월 자금 회의와 점검에 쓰는 분석 관점을 맡습니다.

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

T-code 별 연계 지점

운영 전환 시 기존 표준 리포트를 없앨 필요는 없습니다. 법정 · 감사 대응에 쓰는 표준 리포트는 그대로 두고, 이 화면은 월 회의 · 점검용으로 병행합니다. 두 화면의 숫자가 다르면 먼저 이 화면의 대사 줄(큐브 = 라인 합계)을 보고, 표준 화면과 같은 조건인지 확인하는 순서를 권합니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱 같은 도구는 범용 분석에 강합니다. 이 화면은 그 옆에서 보험료 납부 자금이라는 하나의 주제를 끝까지 파고드는 자리이며, 같은 CDS 큐브를 뷰 레이어로 두기 때문에 분석 스택과 중복되지 않고 이어집니다. 사용할 수 있는 표준 Fiori 앱의 이름과 범위는 운영 환경에서 확인 필요입니다.

표준 데이터 매핑 — 분석 지표 정의

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

CDS 구성 — 뷰 · 권한 · 서비스와 운영에서 할 일

화면이 읽는 데이터는 CDS 뷰 레이어에서 만들어집니다. 아래는 이 화면을 운영 시스템에 올릴 때의 뷰 레이어 설계와 코드 스케치입니다. 실제 필드와 표준 뷰 이름은 고객사 시스템에서 확인 필요이며, 코드는 구조를 보이기 위한 초안입니다.

뷰 레이어 구성

① 매핑 테이블 — 하우스 뱅크와 계정을 분석 차원에 잇는 기준

이 표가 은행 · 보험 종류를 분석 차원으로 바꿉니다. 코드로 박아 두지 않고 표로 둔 이유는 매핑이 바뀔 때 개발이 아니라 현업이 고치기 위해서입니다. 매핑이 빠진 항목은 ‘미분류’로 떨어져 합계에는 남고 차원에서만 따로 보입니다.

// 고객 네임스페이스 접두는 고객사 규칙에 따름 (<접두> 로 표기)
@EndUserText.label : '보험료 납부 은행 · 종류 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table <접두>_inscashmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key racct      : racct not null;     // 보험료 계정 — 확정은 고객사
  key hbkid      : hbkid not null;
  ins_kind       : abap.char(2);       // 보험 종류(분석 차원 값)
  bank_group     : abap.char(10);      // 은행 구분
  valid_from     : abap.dats;
  valid_to       : abap.dats;
}

② 기초 뷰 — 납부 문서 라인을 한 줄 한 줄 정리

원천 전표의 헤더와 라인을 이어 붙이고 매핑을 붙이는 층입니다. 이 층에서 라인 유형(정상 · 계획 외 · 납부월 이동 · 월말 미납)과 납부기한 대비 구분을 정합니다. 집계는 하지 않으므로 라인 합계 = 원천 합계가 이 층에서 보장돼야 합니다. 정확한 필드는 고객사 구성에서 확인 필요입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '보험료 납부 문서 라인'
define view entity <접두>I_InsCashItem
  as select from acdoca as a
    left outer join <접두>_inscashmap as m
      on  m.bukrs = a.rbukrs
      and m.racct = a.racct
{
  key a.rbukrs   as CompanyCode,
  key a.gjahr    as FiscalYear,
  key a.belnr    as DocumentNumber,
  key a.docln    as ItemNumber,
      a.budat    as PostingDate,
      a.rwcur    as TransactionCurrency,
      a.wsl      as TransactionAmount,
      a.hsl      as CompanyCodeAmount,
      m.ins_kind as InsuranceKind
}

③ 차원 뷰 — 이름과 정렬을 붙입니다

코드와 이름을 분리해 코드가 바뀌어도 이름 · 정렬이 함께 바뀌지 않게 합니다.

@EndUserText.label: '보험 종류 차원'
define view entity <접두>I_InsKindDim
  as select from <접두>_inskind
{
  key ins_kind as InsuranceKind,
      kind_txt as InsuranceKindText,
      sort_no  as SortNo
}

④ 큐브 — 차원 조합으로 묶고 원화로 환산합니다

월 · 차원 조합별 합계를 만듭니다. 외화는 라인마다 환산한 뒤 더합니다. 합계를 먼저 더한 뒤 환산하면 환율이 다른 라인이 섞여 값이 틀어지기 때문입니다. 환율 유형은 확인 필요입니다.

@Analytics.dataCategory: #CUBE
@EndUserText.label: '보험료 납부 실적 큐브'
define view entity <접두>I_InsCashCube
  as select from <접두>I_InsCashItem
{
  key CompanyCode, key FiscalYear,
  key substring(cast(PostingDate as abap.char(8)),1,6) as Period,
  key InsuranceKind, key TransactionCurrency,
  @Semantics.amount.currencyCode: 'TransactionCurrency'
  sum(CompanyCodeAmount) as NetAmount,
  count(*)               as LineCount
}
group by CompanyCode, FiscalYear, PostingDate, InsuranceKind, TransactionCurrency

⑤ 계획 큐브 — 실적과 같은 차원으로

계획은 실적과 같은 차원 · 같은 기간 단위로 둡니다. 원천은 계획 테이블 또는 유동성 예측 항목 중 고객사가 정하며 확인 필요입니다.

@Analytics.dataCategory: #CUBE
@EndUserText.label: '보험료 납부 계획 큐브'
define view entity <접두>I_InsCashPlanCube
  as select from <접두>_inscashplan
{
  key plan_version as Version,
  key period       as Period,
  key bukrs        as CompanyCode,
  key ins_kind     as InsuranceKind,
      sum(plan_amt) as PlanAmount
}
group by plan_version, period, bukrs, ins_kind

⑥ 분석 쿼리 — 화면이 읽는 모양

필터 · 행 · 열 후보와 측정값을 선언합니다. 화면 요구가 바뀌면 이 층에서만 바꿉니다.

@Analytics.query: true
@EndUserText.label: '보험료 납부 분석 쿼리'
define view entity <접두>C_InsCashQuery
  as select from <접두>I_InsCashCube
{
  @AnalyticsDetails.query.axis: #ROWS    InsuranceKind,
  @AnalyticsDetails.query.axis: #COLUMNS Period,
  @AnalyticsDetails.query.axis: #FREE    CompanyCode,
  NetAmount
}

⑦ 권한(DCL) — 집계 단계에서 거릅니다

회사코드 단위 권한을 집계 전에 겁니다. 드릴스루에만 걸면 남의 숫자가 합계로 새므로 큐브와 라인 뷰 모두에 같은 규칙을 둡니다.

@EndUserText.label: '보험료 납부 접근 제어'
@MappingRole: true
define role <접두>I_InsCashItem_DCL {
  grant select on <접두>I_InsCashItem
    where CompanyCode = aspect pfcg_auth(F_BKPF_BUK, BUKRS, ACTVT = '03');
}

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

화면이 부르는 엔티티셋 이름과 짝을 맞춥니다. 서비스 이름은 소문자 inscash_srv 입니다.

@EndUserText.label: '보험료 납부 서비스'
define service <접두>_InsCashSrv {
  expose <접두>I_InsCashCube     as CubeSet;
  expose <접두>I_InsCashPlanCube as PlanSet;
  expose <접두>I_InsKindDim      as DimValueSet;
}
// 바인딩: OData V2 - UI 서비스 (게시 후 화면의 manifest 주소와 맞춤)

운영 시점에 해야 할 일

위 항목은 코딩이 아니라 합의입니다. 합의가 끝나면 기술 작업은 CDS 뷰(큐브 · 계획 · 쿼리 · 권한)를 만들고 화면을 올리는 일입니다.

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

납부 점검에서 가장 비싼 질문은 ‘이 숫자 맞아?’ 입니다. 만드는 쪽에서 먼저 대사식을 세워 전수로 돌린 결과입니다(검증용 샘플 데이터 기준).

점검을 위해 일부러 넣은 예외 라인은 납부월 이동 243건, 계획 외 납부 182건, 계획 납부 미발생 188건, 기말 미납 209건이며 대사 차이와 분리해 센 값입니다. 서비스 로직은 6개 함수를 구현해 펑션 3종 호출, 날짜 필터(ge · le), 사유 · 보기 쓰기가 파일에 남는 것, 에이전트 하루 한 번 제한(LIMIT)을 확인했습니다.

운영 데이터로 갈 때

샘플의 5,018줄과 달리 운영 데이터는 라인 수가 훨씬 큽니다. 조회 조건은 모두 표준 $filter 로 서비스에 전달되므로 범위를 좁혀 읽는 것이 기본이며, 큐브를 브라우저에서 다시 묶는 방식의 한계(열 조합 36개, 표 행 수)는 화면에서 안내합니다. 대용량에서의 서버 측 집계 전환은 도입 시 점검이 필요합니다.

자주 묻는 질문

도입을 검토하시는 분들이 자주 물으시는 질문을 주제별로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영