SAP 수출 관세 환급 다차원 분석 — 신청·수령·미환급 잔액과 계획 대비 차이 요인까지 한 화면에서

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

수출 관세 환급 담당이 매달 받는 질문은 비슷합니다. 돌려받을 관세가 얼마인가, 그 가운데 얼마를 신청했고 얼마가 들어왔나, 왜 계획과 다른가. 지금 이 세 답은 표준 문서 화면 · 관세사 자료 · 입금 내역 · 엑셀로 흩어져 있습니다. 이 앱은 세 답을 한 화면에 붙여 잔액이 어디에 묶였는지 바로 보이게 합니다. 수출용 원재료 관세 환급 관리 업무의 신청 준비와 잔액 점검에 쓰는 도구입니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 총차이 562만 원 속의 일곱 요인

전체 기간(2026-01~2026-09)을 계획과 견주면 환급 대상 실적은 37억 5,490만 원, 연초 확정 계획은 37억 4,927만 원으로 총차이가 562만 원(0.15%)뿐입니다. 표준 리포트로 보면 “계획대로 갔다”로 끝납니다. 그런데 일곱 요인으로 가르면 미계획 대상 +2억 8,368만 원, 관세율 −2억 1,803만 원, 환율 +1억 749만 원, 수출 물량 −8,619만 원, 계획 미이행 −7,364만 원, 소요량 −3,049만 원, 과세가격 단가 +2,279만 원이 서로 상쇄하고 있었습니다. 합은 정확히 +562만 원이고, 화면의 검산 줄이 오차 0을 보여 줍니다.

잔액 쪽도 같습니다. 환급 대상 대비 미환급 잔액은 9억 9,949만 원(26.6%)으로 계획의 잔액 3억 원(8.0%)보다 크고, 그 가운데 기한 경과 미신청(LATE) 500줄이 3억 733만 원입니다. 이 500줄은 점검 화면이 무엇을 보여 주는지 확인하려고 검증용 샘플 데이터에 일부러 넣은 예외 목록입니다.

도입하면 달라지는 것

• 마감·점검 준비 — 신청·수령·잔액 표, 요인분해, 사유, 보고서가 한 화면에서 나오므로 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”보다 “어느 요인을 누가 확인하나”를 이야기하게 됩니다.
• 기한 관리 — 기한 경과 미신청 금액이 세관별로 모여 보이므로 신청 준비 순서를 정하기 쉽습니다.
• 기록 — 사유와 레이아웃이 남아 같은 설명을 처음부터 다시 하지 않습니다.

이런 회사에 맞습니다

원재료를 수입해 가공한 뒤 수출하면서 관세 환급을 관리하는 제조·수출 기업, 환급 신청과 수령을 엑셀로 관리하고 있어 잔액이 어디에 묶였는지 한눈에 보기 어려운 관세·경영지원 조직, 통화가 여러 개라 환율이 환급 대상에 주는 영향을 따로 보고 싶은 재무 조직에 맞습니다. 환급 요건과 신청 가능 여부는 회사와 관세사가 판단하며, 이 화면은 그 판단 전에 숫자를 점검하는 도구입니다.

실행 화면

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

사용 방법

1. 조회조건 입력 — 필수는 회사코드와 시작·종료 기간(선적월)입니다. 선택인 비교 기준은 연초 확정 환급 대상 계획입니다.
2. 조회 실행 — 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 레이아웃에 “열 때 자동 조회”를 켜 두면 화면을 열 때 바로 조회됩니다.
3. 요약 확인 — 역할별 요약(CEO·CFO·구매·관세 담당)과 표 위 요약에서 환급 대상, 수령액, 미환급 잔액, 잔액률을 먼저 읽습니다.
4. 축 이동 — 차원 칩을 끌어 행·열·사용 안 함 칸으로 옮기고, 칩 메뉴로 값 선택과 순서 변경을 합니다. 열 조합은 최대 36개입니다.
5. 항목·기준 대비 — 분석 항목과 계산 항목을 고르고 기준 대비를 켜면 차이와 요인분해가 열립니다.
6. 행·칸 클릭 — 행을 누르면 차트(항목 비교·차이 분해)가, 숫자 칸을 누르면 원천 줄 창이 열립니다.
7. 내보내기 — CSV 버튼으로 현재 표를, 보고서(PPTX)로 분석 결과를 내려받습니다.

무엇으로 만들었나

앱 정보

처음 열었을 때 — 조건 하나로 시작

조회조건부터 표까지가 한 화면에 쌓입니다. 필수는 회사코드와 기간뿐이고, 조회는 버튼이나 Enter 키로 실행합니다.

조회 전에도 빈 화면을 주지 않습니다. 회사코드와 시작·종료 기간(선적월)이 기본값으로 채워져 있고, 조회 버튼은 조건 영역 오른쪽 끝에 있습니다. 비교 기준은 연초에 확정한 환급 대상 계획 하나뿐이라 따로 고를 것이 없습니다.

조회를 누르면 요약과 표가 함께 뜹니다. 기본 배치는 행이 선적월, 열이 원산지이고 항목은 환급 대상 관세, 수령액, 미환급 잔액, 미환급 잔액률입니다. 합계 줄의 미환급 잔액이 9억 9,949만 원, 대상 대비 26.6%로 나오며, 모든 칸은 같은 큐브에서 나오므로 합계가 어긋나지 않습니다.

선적월을 열로 옮긴 모습입니다. 이미 읽어 온 큐브를 브라우저에서 다시 집계하므로 서버를 다시 부르지 않고, 총합도 그대로입니다. 칩을 누르면 같은 일을 메뉴로도 할 수 있습니다.

접은 한 줄에는 회사·기간·행·열·항목·기준 대비 여부·필터 수가 담깁니다. 축을 짜는 동안에는 펼쳐 두고, 숫자를 들여다볼 때는 접어 두는 식으로 씁니다.

경영 요약 — 역할마다 먼저 볼 숫자

같은 큐브를 CEO·CFO·구매·관세 담당이 각자 먼저 읽는 순서로 요약합니다.

같은 숫자라도 보는 사람마다 먼저 읽는 순서가 다릅니다. CEO 요약은 규모가 큰 제품그룹과 원재료그룹을 앞에 세우고, 미환급 잔액이 회수 계획에 주는 영향을 짧은 문장으로 알려 줍니다. 역할을 바꿔도 서버를 다시 부르지 않습니다.

CFO 요약은 시간 축입니다. 선적월마다 신청과 수령이 얼마나 따라왔는지, 계획 대비 미환급 잔액이 어디서 벌어졌는지를 한 줄씩 보여 줍니다. 회수 속도를 점검하는 용도이며 확정 수치가 아닙니다.

구매 담당은 계획에는 있었는데 실제로는 생기지 않은 환급 대상(계획 미이행)에 관심이 있습니다. 원산지와 원재료 그룹으로 나눠 어디서 계획이 비었는지 보여 줍니다.

관세 담당 요약은 목표 신청 기한이 지났는데 신청하지 않은 금액을 세관별로 모아 보여 줍니다. 실제로 신청이 가능한지, 어떤 서류가 필요한지는 관세 담당과 관세사가 확인할 일입니다.

축 전환과 범위 — 끌고, 고르고, 맞춘다

열 개 차원을 행·열·사용 안 함 칸으로 옮기며 같은 숫자를 다른 각도로 봅니다.

열에 제품그룹과 선적월·원산지처럼 차원을 쌓으면 열이 조합 수만큼 늘어납니다. 조합이 36개를 넘으면 표를 그리지 않고 안내하므로 화면이 끝없이 넓어지는 일은 없습니다.

칩의 메뉴에서 값 선택을 열면 그 차원의 값과 줄 수가 목록으로 나옵니다. 고른 값만 남기는 필터는 서버를 부르지 않고 이미 읽은 큐브에서 걸러냅니다.

원산지를 몇 곳만 남긴 모습입니다. 합계가 선택값의 큐브 합과 같은지는 자동 시험으로 매번 확인합니다. 필터 수는 접은 머리 한 줄에도 표시됩니다.

표를 넓게 보고 싶을 때와 차트를 크게 보고 싶을 때가 다릅니다. 손잡이를 끌어 비율을 바꾸면 다음에 열어도 같은 너비로 돌아옵니다.

칸에서 환급 문서까지

표의 숫자는 눌러서 내려갈 수 있습니다. 원천 줄이 칸 금액과 맞는지 그 자리에서 확인합니다.

숫자를 의심하는 순간 다른 화면을 열 필요가 없습니다. 칸을 누르면 그 칸의 조건(선적월·원산지 등)을 그대로 들고 원천 줄 창이 열립니다.

줄마다 환급 문서와 품목, 수출·수입 신고 번호, 선적일, 신청일, 수령일, 환급 대상·신청·수령·감액·미환급 금액이 보입니다. 창 위의 합계가 눌렀던 칸의 금액과 같은지 바로 비교됩니다. 줄이 많으면 더 보기로 이어 읽습니다.

선적월 아홉 달을 한 장으로 모은 요약입니다. 라인 수, 원산지 수, 수량, 환급 대상, 신청, 수령, 감액, 미환급 잔액에 계획 대비 대상과 잔액이 나란히 놓입니다.

계산 항목 — 비율과 미수령을 표에 얹는다

금액 항목 위에 산식을 얹어 수령률과 미환급 잔액률 같은 비율을 같은 표에서 봅니다.

계산 항목은 분석 항목 위에 얹는 산식입니다. 신청 후 미수령, 수령률, 미환급 잔액률, 감액·불인정률, 신청률, 수출 단위당 환급 대상을 고를 수 있고, 분모가 0이면 칸을 비워 둡니다.

기준 대비 차이와 요인분해 — 같은 표가 점검 자료가 된다

연초 확정 계획과 견주면 같은 표가 차이 점검표가 되고, 차이를 일곱 요인으로 가를 수 있습니다.

기준 대비를 켜면 칸마다 실적과 함께 기준 값, 차이 금액, 차이율이 붙습니다. 색은 금액과 비율 두 임계를 모두 넘을 때만 입혀서 작은 차이로 화면이 알록달록해지지 않습니다.

차이가 큰 행의 사유 칸을 누르면 사유 구분(환율·기타 등)과 내용을 적는 창이 열립니다. 사유는 조회 범위와 행 경로에 묶여 저장되어, 새로 고친 뒤에도 같은 행에 남습니다.

행을 누르면 오른쪽에 계획 대비 환급 대상 차이를 일곱 요인으로 가른 워터폴이 나옵니다. 총차이는 작아도 요인끼리 서로 상쇄하는 경우가 많아, 계단을 보면 무엇이 무엇을 가렸는지 드러납니다.

요인은 수출 물량, 소요량, 과세가격 단가, 관세율, 환율, 미계획 대상, 계획 미이행입니다. 표 아래 검산 줄이 요인 합계와 총차이를 나란히 적고 오차를 보여 주며, 이 앱의 모든 범위에서 오차는 0입니다.

AI 분석과 보고서

숫자는 서비스가 계산하고 문장은 그 숫자를 읽어 만듭니다. 근거 수치와 보고서까지 한 흐름입니다.

AI 분석은 현재 보고 있는 범위의 금액을 서비스가 먼저 계산한 뒤 그 숫자로 문장을 만듭니다. 모델을 쓰지 않는 규칙 기반 해설이 기본이라 같은 범위에서는 늘 같은 문장이 나옵니다.

근거 수치는 대상, 환급 대상 실적과 계획, 미계획 대상, 계획 미이행, 대상 차이, 등록된 사유로 이뤄집니다. 해설을 믿을지 말지는 이 표와 대조해 판단합니다.

지금 보는 범위의 표와 차트, 해설을 담은 보고서가 브라우저 안에서 만들어집니다. 서버에 파일을 남기지 않으며 열어 보면 장 수와 숫자가 화면과 같습니다.

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

감시 규칙에 걸린 금액을 받을 역할 앞으로 올려 줍니다.

규칙은 계획 대비 환급 대상 차이 금액, 계획 미이행 금액, 미환급 잔액률 상한, 기한 경과 미신청 금액, 환율 영향 임계 다섯 가지입니다. 규칙마다 기준값과 받는 역할, 사용 여부를 고칠 수 있습니다.

첫 실행에서 규칙에 걸린 17건이 역할별 받은 보고로 올라왔습니다. 받는 사람의 눈으로 다시 적은 제목과 본문, 금액, 행 경로가 붙어 있어 눌러서 해당 자리로 갈 수 있습니다.

지금 실행은 언제든 누를 수 있고, 타이머는 화면이 열려 있는 동안 하루 한 번만 점검합니다. 같은 날 두 번째 실행은 건너뛰었다고 기록에 남습니다.

레이아웃 저장과 복원

한번 짠 배치는 이름을 붙여 저장하고 다음에 그대로 꺼냅니다.

축 배치와 항목, 보기 방식, 기준 대비 여부를 이름을 붙여 저장합니다. 기본 레이아웃으로 지정하거나 열 때 자동 조회를 켤 수도 있습니다.

저장한 레이아웃이 목록으로 나오고 기본·자동 조회 여부를 바로 고칩니다. 이름 변경과 삭제도 이 창에서 합니다.

저장된 레이아웃을 고르면 행·열·항목이 그대로 돌아옵니다. 기본 레이아웃에 자동 조회를 켜 두면 화면을 여는 순간 조회된 채로 시작합니다.

좁은 화면과 한계

휴대폰 폭에서의 배치와 표를 그리지 않는 상한을 보여 줍니다.

휴대폰 폭에서는 표와 차트가 위아래로 쌓입니다. 표는 가로로 밀어 보고, 손잡이는 세로 배치에서는 쓰지 않습니다.

열 차원을 둘 이상 쌓아 조합이 72개가 되면 상한 36개를 넘었다고 알리고 표를 그리지 않습니다. 차트도 함께 멈추며 열 차원이나 선택값을 줄이라는 방법을 알려 줍니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스는 회사코드와 기간 조건으로 집계 큐브와 계획을 읽어 옵니다. 이후 행·열 이동, 값 선택, 계산 항목, 역할 전환은 모두 읽어 온 큐브를 브라우저에서 다시 집계하는 일이라 요청이 늘지 않습니다. 칸을 누를 때만 그 칸의 조건으로 원천 줄을 읽고, 사유·레이아웃·규칙을 저장할 때만 쓰기 요청이 나갑니다.

판정 로직 — 줄의 상태와 해야 할 일

원천 줄마다 환급 대상 관세를 구하고 신청·수령 진행에 따라 아래 상태로 나눕니다. 점검용 분류이며 확정이 아닙니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭 390px 기준으로 표와 차트가 위아래로 쌓이고 표는 가로로 밀어 봅니다. 손잡이는 가로 배치에서만 쓰고, 칩 메뉴와 창은 화면 폭에 맞춰 좁아집니다.

파일 구성

index.html · Component.js · manifest.json
controller/   Main.controller.js
model/        cube.js · chart.js · pptx.js · layout.js · formatter.js
view/         Main.view.xml · fragments/(창 9종)
i18n/         한국어 문구
css/          style.css
odata/        서비스 로직 · 메타데이터 · 샘플 데이터 파일
media/        소개 영상 · 포스터 · 재생 지점

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준이 잘하는 확인과 신고 대응은 표준에 두고, 끊기는 자리만 이어 붙입니다.

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

T-code 별 연계 지점

운영 전환 때 기존 리포트를 없앨 필요는 없습니다. 이 앱 결과에서 표준 T-code 로 원천을 확인하고, 표준 화면의 값을 이 앱에서 다시 보는 오가는 길이 열려 있는 상태로 함께 둡니다. 법정·감사·세무 신고 대응은 표준에 남겨 둡니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정해진 보고 양식을 안정적으로 내는 데 강합니다. 이 앱은 그 옆에서 축을 바꿔 가며 신청·수령·잔액을 점검하고 계획 대비 차이를 요인으로 가르는 용도입니다. 특정 Fiori 앱과의 대응 관계는 확인하지 못해 적지 않았습니다.

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

분석 지표 정의표

CDS 구성 — 최대한 자세히

아래 코드는 구현 참고용 스케치입니다. 표준 테이블 이름은 확인한 것만 썼고, 회사마다 달라지는 원천은 “확인 필요”로 남겼습니다.

뷰 레이어 구성

① 매핑 테이블 — 원재료와 수출제품을 잇는 기준

환급 대상 금액은 수출제품 한 개에 원재료가 얼마나 들어갔는지(소요량)에서 출발합니다. 이 기준을 코드 안에 두면 바뀔 때마다 이송해야 하므로 테이블로 뺍니다. 테이블은 현업이 유지보수하고, 변경 이력이 남도록 변경자·변경일을 둡니다.

@EndUserText.label : '원재료-수출제품 소요량 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zdrw_matmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key matgroup   : abap.char(3) not null;   " 원재료 그룹
  key prodgroup  : abap.char(3) not null;   " 수출제품 그룹
  req_qty        : abap.dec(13,4);          " 제품 단위당 원재료 소요량
  req_unit       : meins;
  changed_by     : syuname;
  changed_at     : timestampl;
}

② 수출 선적 기준 — 송장과 출고

선적월은 출고일 기준으로 잡고, 수량과 금액은 수출 송장 품목에서 가져옵니다. 두 뷰를 나눈 이유는 출고 문서와 송장이 일대일이 아닐 수 있기 때문입니다.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 송장 품목'
define view entity ZI_ExportBillingItem
  as select from vbrk
    inner join vbrp on vbrp.vbeln = vbrk.vbeln
{
  key vbrk.vbeln                      as BillingDocument,
  key vbrp.posnr                      as BillingItem,
      vbrk.bukrs                      as CompanyCode,
      vbrk.fkdat                      as BillingDate,
      vbrp.matnr                      as Material,
      @Semantics.quantity.unitOfMeasure: 'BaseUnit'
      vbrp.fkimg                      as BillingQuantity,
      vbrp.vrkme                      as BaseUnit,
      vbrk.waerk                      as DocumentCurrency
}
" 출고일(LIKP-WADAT_IST)은 ZI_ExportDelivery 에서 읽는다. 수출 판별 조건(수출 송장 유형)은 확인 필요.

③ 환급 신청 원천 — 원천 테이블은 확인 필요

환급 신청·수령·감액을 어디서 읽는지는 회사마다 다릅니다. 이 객체는 화면이 필요로 하는 모양만 정해 두고, 원천은 “확인 필요”로 남겨 도입 때 채웁니다.

@EndUserText.label: '환급 신청 문서 (원천 확인 필요)'
define view entity ZI_DrawbackClaim
  as select from <확인 필요: 환급 신청 원천>
{
  key DrawbackDocument,
  key DrawbackItem,
      ExportDeclaration,
      ImportDeclaration,
      ClaimDate,
      ReceiptDate,
      @Semantics.amount.currencyCode: 'Currency'
      ClaimAmount,
      ReceivedAmount,
      ForfeitAmount,
      Currency
}

④ 환급 줄 큐브 — 줄 단위 대상과 상태

줄마다 환급 대상을 산출하고 상태(수령·신청 후 미수령·신청 전·기한 경과·감액)를 붙입니다. 상태 판정이 이 층에서 정해지므로 화면과 에이전트가 같은 기준을 씁니다.

@Analytics.dataCategory: #CUBE
@EndUserText.label: '환급 줄 큐브'
define view entity ZI_DrawbackItem
  as select from ZI_ExportBillingItem as bill
    association [0..1] to ZI_DrawbackClaim as _Claim
      on _Claim.ExportDeclaration = $projection.ExportDeclaration
{
  key bill.BillingDocument,
  key bill.BillingItem,
      bill.CompanyCode,
      cast(substring(bill.BillingDate, 1, 6) as abap.char(6))  as ShipPeriod,
      @Aggregation.default: #SUM
      cast(bill.BillingQuantity as abap.dec(15,3))              as Qty,
      /* 환급 대상 = 수량 × 소요량 × 과세가격 단가 × 관세율 × 환율 — 입력 원천은 확인 필요 */
      @Aggregation.default: #SUM
      cast(0 as abap.curr(15,0))                                as EligibleDuty,
      @Aggregation.default: #SUM
      _Claim.ClaimAmount                                        as ClaimAmount,
      @Aggregation.default: #SUM
      _Claim.ReceivedAmount                                     as ReceivedAmount,
      case
        when _Claim.ReceiptDate is not initial then 'RCV'
        when _Claim.ClaimDate   is not initial then 'CLM'
        else 'OPN'
      end                                                       as DrawStatus,
      _Claim.ExportDeclaration
}

⑤ 계획 뷰 — 연초 확정 환급 대상

계획은 실적과 같은 차원 키를 갖고 있어야 기준 대비와 요인분해가 한 번에 맞습니다. 계획 원천은 회사의 계획 테이블이나 파일 업로드 등 다양해서 확인 필요로 둡니다.

@Analytics.dataCategory: #CUBE
@EndUserText.label: '환급 대상 계획'
define view entity ZI_DrawbackPlan
  as select from <확인 필요: 연초 확정 계획 원천>
{
  key CompanyCode,
  key PlanVersion,
  key ShipPeriod,
  key MaterialGroup,
  key ProductGroup,
  key Origin,
  key Customs,
      @Aggregation.default: #SUM
      PlannedEligibleDuty
}

⑥ 분석 쿼리 — 화면이 읽는 소비 뷰

화면은 이 뷰 하나로 큐브를 읽습니다. 필터가 필요한 필드를 여기서 정해 두면 서비스 필터와 화면 조건이 같은 이름을 씁니다.

@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '환급 다차원 분석 쿼리'
define view entity ZC_DrawbackQuery
  as select from ZI_DrawbackItem
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key CompanyCode,
  @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
  key ShipPeriod,
      @AnalyticsDetails.query.axis: #ROWS
      DrawStatus,
      @AnalyticsDetails.query.axis: #COLUMNS
      Qty, EligibleDuty, ClaimAmount, ReceivedAmount
}

⑦ 권한 — 회사코드 단위 접근 제어

권한은 드릴스루에만 걸면 집계 합계의 뺄셈으로 새어 나갑니다. 집계를 만드는 쿼리에서 걸어야 합니다.

@EndUserText.label: '환급 분석 회사코드 권한'
define role ZC_DrawbackQuery {
  grant select on ZC_DrawbackQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 부르는 서비스

쿼리를 서비스로 노출하는 마지막 층입니다. 바인딩을 게시하고 화면 manifest 의 서비스 주소를 이 서비스로 바꾸면 운영 연결이 끝납니다.

@EndUserText.label: '환급 분석 서비스'
define service ZUI_Drawback {
  expose ZC_DrawbackQuery as DrawbackQuery;
  expose ZI_DrawbackPlan  as DrawbackPlan;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

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

검증용 샘플 데이터(원천 6,256줄, 환급 문서 1,048건)에서 대사식을 전수로 돌렸고 차이는 모두 0입니다. 도입 포인트의 사례와 같은 숫자입니다.

운영 데이터로 갈 때

수천만 건 규모에서는 큐브 집계를 데이터베이스에서 하고, 회사코드와 기간을 필수 파라미터로 두며, 선적월·차원 키에 맞는 인덱스와 응답 시간 기준을 먼저 정해야 합니다. 이 샘플은 큐브 802행으로 전체를 읽어 오는 구조라 규모가 커지면 서버 쪽 집계로 옮기는 것이 맞고, 그 측정은 운영 데이터로 다시 해야 합니다.

자주 묻는 질문

숫자와 산식, 화면 조작, 분석 기능, 도입과 운영 순으로 모았습니다. 점검 도구이며 최종 판단은 회사와 감사인이, 세무 신고는 회사와 세무 대리인·관세사가 합니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영