SAP 협력사 대금 지급 자금 다차원 분석 리포트 — 지급 계획 대비 차이를 요인으로 가르고 원천 송장까지 내려가는 월 자금 점검

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

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

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

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(2026년 1~9월, 법인 3개, 은행 5곳, 통화 5종)에서 순지급액은 5,135.18억 원, 지급 계획은 4,964.07억 원으로 총차이는 +171.11억 원(계획 대비 103.4%)였습니다. 합계만 보면 ‘계획보다 3% 남짓 더 나갔다’에서 끝납니다. 일곱 요인으로 가르면 모습이 달라집니다. 계획에 없던 지급이 +320.42억 원, 계획만 있고 지급이 나오지 않은 몫이 −195.25억 원으로 서로 크게 반대로 움직였고, 그 사이에서 송장 금액 변동 +5.73, 환율 효과 +44.91, 추가 청구 반영 +8.07, 할인·상계 효과 −12.78, 지급월 이동 0.00(억 원)이 남았습니다. 계획 + 요인 합 − 실적은 0 이며 화면이 이 검산을 매번 보여 줍니다.

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

도입하면 달라지는 것

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

이런 회사에 맞습니다

원부자재 · 부품 · 설비 · 물류 · 용역 등 여러 공급사 구분에 정기적으로 대금을 지급하고, 법인과 지급 은행, 통화가 여러 개라 월 단위로 지급 계획과 실적을 맞춰 보는 회사에 맞습니다. 특히 계획과 실제 지급이 다른 이유를 자금팀 · 회계팀 · 구매팀이 매달 따로 설명해야 하는 조직, 그리고 표준 화면은 유지하면서 분석 관점만 더하고 싶은 SAP 운영 조직에 맞습니다. 반대로 공급사가 몇 곳 안 되고 한 은행 · 한 통화뿐이라면 표준 화면과 엑셀로 충분할 수 있습니다.

실행 화면

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

사용 방법

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

무엇으로 만들었나

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

처음 열었을 때

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

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

위 카드는 순지급액 5,135.18억 원, 최대 비중 공급사 구분 41.0%, 지연 지급 비중 14.5%, 계획 대비 차이 +171.11억 원처럼 지금 범위의 요약입니다. 표와 차트는 같은 계산 결과를 그리므로 어느 쪽을 봐도 합계가 같습니다.

법인 · 기간 · 비교 기준 · 금액 단위를 바꿀 때 펼칩니다. 조회 단추는 오른쪽 위에 있고 초기화 단추는 조건을 기본값으로 되돌립니다.

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

보는 사람 탭

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

법인별로 추가 청구가 어디서 반영됐는지, 할인·상계가 어디서 크게 났는지 점검할 곳을 가립니다. 탭을 바꿔도 다시 조회하지 않습니다.

지연 지급 비중과 기말 미지급 잔액이 어느 은행 · 어느 결제조건에 몰렸는지 먼저 봅니다. 기말 미지급 잔액은 기간을 합쳐도 끝 기간 값만 씁니다.

이견 보류 후 지급 건이 어느 통화에 있는지 확인하고 표준 화면에서 이어 처리하도록 안내합니다. 통화가 다른 거래통화 금액은 더하지 않습니다.

축 옮기기와 범위

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

차원 보관함의 칩을 행 축 · 열 축에 올리면 서버를 다시 부르지 않고 이미 읽어 온 큐브를 브라우저에서 다시 묶습니다. 행은 3단계, 열은 2단계까지입니다.

열 머리가 여러 줄로 나뉘어 분기별 · 지급기한 대비별 값이 한 표에서 비교됩니다. 합계는 어느 배치에서도 같아야 하며 그 검산은 검증 절에 있습니다.

값마다 원천 라인 수가 함께 보여 어느 값이 많이 쓰이는지 알 수 있습니다. 고른 값만 남기고 [적용]을 누르면 표 · 차트 · 카드가 같은 범위로 다시 그려집니다.

값 필터를 걸면 카드의 순지급액도 같이 바뀝니다(1,977.05억 원). 필터가 걸려 있다는 표시는 도구줄의 필터 칩으로 남습니다.

표 열이 많을 때는 차트를 좁히고, 차트를 크게 보여 줘야 할 때는 표를 좁힙니다.

계산항목

측정값 말고도 비율 · 평균 같은 계산항목을 열로 올릴 수 있습니다. 식은 서비스가 정의합니다.

계산항목은 서비스가 정의한 식(예: 지연 지급 비중 = 지급기한을 넘긴 순지급액 ÷ 순지급액)으로 계산하고, 합계 행도 같은 식으로 다시 계산합니다. 분모가 0이면 빈칸으로 둡니다.

비율은 행마다 분자 · 분모를 따로 더한 뒤 나누므로, 합계 행의 비율이 행 비율의 평균이 아니라는 점에 유의합니다.

원천 송장

숫자를 의심하는 순간 가장 빠른 길은 그 숫자를 만든 라인을 보는 것입니다. 칸을 누르면 같은 조건의 원천 라인이 열립니다.

라인마다 지급일 · 문서 · 법인 · 지급 은행 · 공급사 구분 · 결제조건 · 지급기한 대비 · 거래통화 금액 · 송장 금액이 보입니다. 표준 화면으로 이동할 때는 문서번호를 씁니다.

계획 대비 차이

비교 기준을 두면 같은 표가 실적 · 계획 · 차이 · 차이율이 됩니다. 행을 고르면 그 차이를 일곱 요인으로 가른 폭포가 나옵니다.

금액 기준(백만원)과 비율 기준(%)을 모두 넘는 칸만 붉게 칠합니다. 색은 점검이 필요하다는 신호일 뿐 원인을 단정하지 않으며 기준값은 화면에서 바꿉니다.

설비·공사 협력사는 계획 외 지급 +172.45억 원과 계획 지급 미발생 −74.09억 원이 크게 보입니다. 원인은 단정하지 않고 점검할 곳을 가리킵니다.

사유는 조회 범위와 행 경로에 묶여 저장되므로 축을 바꾸거나 다음 달에 같은 범위를 열어도 따라옵니다. 사유의 정확성은 담당자가 점검해야 합니다.

연필 표시가 있는 행은 해설이 건너뛰며 ‘이미 사유가 있다’는 문장을 대신 적습니다.

해설과 보고서

해설은 서비스가 계산한 숫자 위에 규칙으로 쓴 초안입니다. 문장마다 근거 표가 붙고, 같은 내용을 검토용 파워포인트로 받을 수 있습니다.

숫자는 서비스가 계산한 값이고 문장은 규칙으로 쓴 초안입니다. 모델 연결은 서비스 설정 하나로 켜며 기본은 꺼져 있습니다. 외부에 쓰기 전에 숫자와 표현을 점검하세요.

근거 표에 없는 숫자는 해설에 쓰지 않습니다. 표의 숫자와 원천 라인을 직접 확인한 뒤 판단하세요.

파일은 브라우저에서 바로 만들어지며 외부로 보내지 않습니다. 슬라이드의 숫자는 화면과 같아야 하고, 외부에 쓰기 전에 점검이 필요합니다.

에이전트

에이전트는 규칙을 판정해 점검이 필요한 항목을 대기함에 올릴 뿐 판단을 대신하지 않습니다. 하루 한 번 제한은 서버가 지킵니다.

규칙마다 기준값과 받는 사람(경영 · 재무 · 자금 · 회계)이 붙어 있습니다. 샘플 기준값은 운영에서 회사 기준으로 바꿔야 합니다.

에이전트는 판단을 대신하지 않고 점검이 필요한 항목을 알려 주는 역할입니다. 보고의 숫자는 서비스가 계산한 최근 기간 값입니다.

제한은 화면이 아니라 서비스가 판정하므로 화면을 여러 개 열어도 우회되지 않습니다.

보기 저장

자주 쓰는 배치는 보기로 저장해 두었다가 그대로 불러옵니다.

행 · 열 축, 측정값, 보는 사람 탭, 값 필터, 계획 차이 스위치와 기준값이 함께 저장됩니다.

기본 보기에 자동 조회를 켜 두면 화면을 열 때 바로 조회합니다.

한도와 좁은 화면

화면이 느려지거나 멈추기 전에 한도를 알려 주고, 좁은 화면에서는 세로로 쌓입니다.

화면이 느려지거나 멈추기 전에 한도를 알려 줍니다. 열 축에서 한 단계를 빼거나 값 필터로 범위를 좁히세요.

열이 많은 표는 가로로 넘겨 봅니다. 휴대폰에서는 조회와 요약 확인 위주로 쓰는 것을 권합니다.

차이 요인 판정과 화면 상태 규칙

일곱 요인의 산출 방식

조회조건과 결과 컬럼

파일 구성

app_folder/
├─ index.html · Component.js · manifest.json
├─ controller/ · view/ · model/(cube · chart · pptx · layout · formatter)
├─ css/ · i18n/
├─ odata/vendpay_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 <접두>_vendpaymap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key ktokk      : ktokk not null;     // 공급사 계정 그룹 — 확정은 고객사
  key hbkid      : hbkid not null;
  vend_grp       : 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_VendPayItem
  as select from I_OperationalAcctgDocItem as i
    left outer join <접두>_vendpaymap as m
      on  m.bukrs = i.CompanyCode
      and m.ktokk = i.SupplierAccountGroup   // 필드명은 고객사 구성에서 확인 필요
{
  key i.CompanyCode                   as CompanyCode,
  key i.FiscalYear                    as FiscalYear,
  key i.AccountingDocument            as DocumentNumber,
  key i.AccountingDocumentItem        as ItemNumber,
      i.PostingDate                   as PostingDate,
      i.TransactionCurrency           as TransactionCurrency,
      i.AmountInTransactionCurrency   as TransactionAmount,
      i.AmountInCompanyCodeCurrency   as CompanyCodeAmount,
      m.vend_grp                      as VendorGroup
}

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

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

@EndUserText.label: '공급사 구분 차원'
define view entity <접두>I_VendGroupDim
  as select from <접두>_vendgroup
{
  key vend_grp as VendorGroup,
      grp_txt  as VendorGroupText,
      sort_no  as SortNo
}

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

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

@Analytics.dataCategory: #CUBE
@EndUserText.label: '협력사 대금 지급 실적 큐브'
define view entity <접두>I_VendPayCube
  as select from <접두>I_VendPayItem
{
  key CompanyCode, key FiscalYear,
  key substring(cast(PostingDate as abap.char(8)),1,6) as Period,
  key VendorGroup, key TransactionCurrency,
  @Semantics.amount.currencyCode: 'TransactionCurrency'
  sum(CompanyCodeAmount) as NetAmount,
  count(*)               as LineCount
}
group by CompanyCode, FiscalYear, PostingDate, VendorGroup, TransactionCurrency

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

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

@Analytics.dataCategory: #CUBE
@EndUserText.label: '협력사 대금 지급 계획 큐브'
define view entity <접두>I_VendPayPlanCube
  as select from <접두>_vendpayplan
{
  key plan_version as Version,
  key period       as Period,
  key bukrs        as CompanyCode,
  key vend_grp     as VendorGroup,
      sum(plan_amt) as PlanAmount
}
group by plan_version, period, bukrs, vend_grp

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

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

@Analytics.query: true
@EndUserText.label: '협력사 대금 지급 분석 쿼리'
define view entity <접두>C_VendPayQuery
  as select from <접두>I_VendPayCube
{
  @AnalyticsDetails.query.axis: #ROWS    VendorGroup,
  @AnalyticsDetails.query.axis: #COLUMNS Period,
  @AnalyticsDetails.query.axis: #FREE    CompanyCode,
  NetAmount
}

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

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

@EndUserText.label: '협력사 대금 지급 접근 제어'
@MappingRole: true
define role <접두>I_VendPayItem_DCL {
  grant select on <접두>I_VendPayItem
    where CompanyCode = aspect pfcg_auth(F_BKPF_BUK, BUKRS, ACTVT = '03');
}

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

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

@EndUserText.label: '협력사 대금 지급 서비스'
define service <접두>_VendPaySrv {
  expose <접두>I_VendPayCube     as CubeSet;
  expose <접두>I_VendPayPlanCube as PlanSet;
  expose <접두>I_VendGroupDim    as DimValueSet;
}
// 바인딩: OData V2 - UI 서비스 (게시 후 화면의 manifest 주소와 맞춤)

운영 시점에 해야 할 일

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

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

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

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

운영 데이터로 갈 때

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

자주 묻는 질문

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

숫자와 산식

화면과 조작

분석 기능

도입과 운영