SAP 세금·공과금 납부 자금 다차원 분석 — 어느 세목과 은행에 몰렸고 납부 예정에서 왜 벗어났는지를 한 화면에서 읽는 자금 점검

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

월말이 다가오면 자금 담당과 세무 담당이 받는 질문은 대체로 세 가지입니다. 이번 달 세금과 공과금으로 나갈 돈이 얼마인가, 어느 세목과 어느 은행에 몰려 있는가, 자금 계획에 잡아 둔 납부 예정보다 늘었다면 무엇 때문인가. 지금은 이 답이 지급 전표 조회, 세목별 신고서, 은행 이체 내역, 엑셀로 만든 자금 계획표에 흩어져 있어 한 사람이 한나절 맞춰 봐야 겨우 나옵니다. 부가가치세와 원천세, 법인세, 관세, 지방세, 사회보험료는 납부 시점과 납부 채널이 서로 달라서, 합계가 맞아도 어느 세목이 계획과 어긋났는지는 숫자가 아니라 사람의 기억에 의존하기 쉽습니다.

이 앱은 그 자리를 메웁니다. 세금·공과금 납부 한 건 한 건을 세목 · 납부 은행 · 법인 · 납부 채널 · 신고 구분 · 기한 대비 · 처리 단계 · 환급 상계로 묶은 큐브로 한 번 읽어 두고, 사용자가 축을 끌어다 놓으며 같은 숫자를 여러 각도로 봅니다. 납부 예정과 실적의 차이는 일곱 요인으로 갈라 보여 주고, 그 숫자가 원천 납부 라인과 어긋나지 않는지 매번 스스로 검산합니다. 이 화면은 점검 도구이며, 신고와 납부에 관한 최종 판단은 회사와 세무 대리인이 합니다. 관련 법령은 법인세법 · 부가가치세법 · 국세기본법 등 제도 명칭으로만 언급하며 조문 번호와 세율은 확인 필요입니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 자료(2026년 1~9월, 원천 납부 라인 3,597건)에서 실적 납부액은 1,303.96억, 납부 예정은 1,289.70억이었고 차이는 +14.26억(+1.1%)입니다. 총액만 보면 “조금 늘었다”로 끝나는 숫자지만 요인분해는 다른 이야기를 합니다. 신고 세액 증가가 +47.14억, 신고 세액 감소가 −31.03억, 가산세·지연이자가 +4.23억, 환급 상계가 −10.49억, 예정 외 신규 납부가 +15.12억, 예정 납부 미발생이 −10.71억으로 크게 오르내리다 서로 상쇄되어 +14.26억이 됩니다. 일곱 요인의 합이 총차이와 맞는지는 범위 39개(전체와 차원 값별)에서 모두 0으로 확인했습니다. 점검할 곳은 총액이 아니라 신고 세액을 예정과 다르게 신고한 건과 예정에 없던 납부가 생긴 건입니다.

도입하면 달라지는 것

• 월 자금 회의가 “표를 맞추는 시간”에서 “어느 세목이 왜 벗어났는지 보는 시간”으로 바뀝니다.
• 납부 예정과 실적의 차이를 사람이 기억에서 설명하지 않고, 요인과 근거 납부 라인으로 설명합니다.
• 가산세·지연이자와 기말 미납 잔액이 마감 뒤가 아니라 납부 기간 중에 대기함으로 올라옵니다.
• 변동 사유와 보기가 남아 담당자가 바뀌어도 같은 질문을 처음부터 다시 하지 않습니다.

이런 회사에 맞습니다

여러 법인이 세목별로 세금과 공과금을 납부하고, 납부 은행과 납부 채널(전자납부 · 자동이체 · 창구 등)이 나뉘어 있어 자금 담당과 세무 담당이 매달 계획표와 실제 납부를 대조하는 회사에 맞습니다. 관세 · 부가가치세 · 원천세처럼 월 단위로 반복되는 납부가 많고, 가산세나 환급 상계가 간헐적으로 끼는 곳일수록 효과가 큽니다. 반대로 납부 건이 적고 세목이 한두 개뿐이라면 표준 화면만으로 충분할 수 있습니다.

실행 화면

사용 방법

1. 조회조건 입력 — 기간(부터 · 까지)은 필수이며 기본은 2026년 1월~9월입니다. 법인은 선택이고, 비교 기준은 “납부 예정과 비교”가 기본입니다.
2. 조회 — 조회조건 상자 안의 파란 [조회] 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 기본 + 자동 조회로 저장한 보기가 있으면 화면을 열 때 자동으로 조회됩니다.
3. 요약 확인 — 위쪽 다섯 가지 지표를 봅니다. 보는 사람(경영 · 재무 · 자금 · 회계)을 바꾸면 먼저 놓이는 축이 달라집니다.
4. 탭과 축 이동 — 차원 칩을 끌어 행 축 · 열 축에 놓고, 측정값과 값 필터로 범위를 좁힙니다. 총합은 어떤 배치에서도 같습니다.
5. 행 · 칸 클릭 — 행을 누르면 오른쪽 차트가 그 행의 요인으로 바뀌고, 숫자 칸을 누르면 원천 납부 라인이 열립니다.
6. 내보내기 — [CSV]로 표를 내려받고, [해설]에서 읽은 내용을 PowerPoint 보고서로 받습니다.

무엇으로 만들었나

처음 열었을 때 — 조회 한 번으로 지표 · 표 · 차트가 함께 뜹니다

조회 전에도 조회조건과 레이아웃 보드, 피벗 틀이 먼저 보입니다. 기간을 정하고 조회를 누르면 같은 큐브에서 나온 지표 · 표 · 차트가 한 번에 채워집니다.

기간 2026년 1월~9월, 납부 예정과 비교로 조회한 첫 결과입니다. 지표 다섯 개는 납부액 1,303.96억, 최대 세목 비중 28.3%(부가가치세), 가산세·지연이자율 0.32%, 8일 이상 지연 납부 비중 8.4%, 예정 대비 납부 차이 +14.26억입니다. 모두 같은 큐브에서 나온 값이며 표와 차트도 한 번의 읽기로 함께 채워집니다.

조회를 누르면 조건 상자는 한 줄 요약(법인 · 기간 · 비교 기준 · 금액 단위)으로 접혀 표가 넓어지고, 막대를 누르면 이 모습으로 돌아옵니다. 법인을 비우면 전체 법인이며, 기간은 필수입니다.

보는 사람에 맞춰 바뀌는 첫 화면

같은 숫자를 경영 · 재무 · 자금 · 회계가 각자 다른 질문으로 봅니다. 보는 사람을 바꾸면 먼저 놓이는 축과 측정값이 바뀌고, 서버를 다시 부르지 않습니다.

재무 담당은 환급 상계를 뺀 순 세부담이 세목과 법인별로 어떻게 다른지 먼저 봅니다. 순 세부담은 본세에서 환급 상계를 뺀 계산항목이며, 합계 칸에서 다시 계산한 값입니다.

자금 담당은 어느 은행에서 얼마가 나가고 미납 잔액이 얼마인지 먼저 봅니다. 샘플에서는 가상 시중은행 A가 503.90억으로 가장 많고, 기말 미납 잔액은 8.78억입니다.

회계 담당은 정기 신고 · 예정·중간예납 · 수정·기한후 신고 가운데 가산세가 어디서 생기는지 먼저 봅니다. 수정·기한후 신고는 납부액 비중은 작아도 가산세·지연이자율이 높아 점검 필요 후보가 됩니다.

열 개 차원을 끌어다 놓고, 값으로 범위를 좁힙니다

차원 보관함의 칩을 행 축과 열 축으로 끌어다 놓으면 표가 바로 바뀝니다. 행 축은 3단계, 열 축은 2단계까지이며, 이 과정에서 서버를 다시 부르지 않습니다.

조회 때 읽어 둔 큐브를 브라우저가 다시 묶습니다. 어떤 배치로 바꿔도 총합은 1,303.96억으로 같고, 열 축의 기한 대비(기한 내 · 1~7일 지연 · 8일 이상 지연)로 늦게 낸 금액이 은행별로 어떻게 나뉘는지 봅니다.

값 필터에서 차원 하나를 고르면 읽어 둔 데이터 안의 값 목록이 라인 수와 함께 나옵니다. 차원 안에서는 or, 차원 사이에서는 and 로 걸러집니다.

필터를 적용하면 지표의 납부액도 선택한 은행 범위의 값으로 바뀝니다. 필터는 서버 재조회 없이 읽어 둔 큐브 안에서 걸러집니다.

칸에서 원천 납부 라인까지 — 표의 숫자를 눈으로 확인합니다

표의 칸을 누르면 그 금액을 만든 원천 납부 라인이 열립니다. 칸 금액과 원천 합계가 같은지 머리에 표시되므로 숫자를 믿고 쓸 수 있는지 그 자리에서 확인합니다.

상단에 “표의 값과 일치”가 표시되고 원천 합계가 칸 금액 131.61억과 같습니다. 기본은 500행씩 페이징하며, 라인마다 납부일 · 문서번호 · 납부 은행 · 세목 · 납부 채널 · 기한 대비 · 본세 · 가산세·지연이자 · 납부액이 보입니다. [CSV]로 내려받을 수 있습니다.

월별 납부액의 오르내림과 비중이 같은 데이터에서 재조회 없이 나옵니다. 월마다 납부 시점이 몰리는 세목을 찾는 데 씁니다.

계산항목 — 비율은 합계 칸에서 다시 계산합니다

가산세·지연이자율이나 지연 납부 비중처럼 비율은 칸마다 평균을 내면 틀립니다. 계산항목은 서비스가 정의한 식을 합계 칸에서 다시 계산합니다.

측정값을 여러 개 고르면 열 축에 측정값이 단계로 들어갑니다. 기말 미납 잔액은 기간을 합쳐도 끝 기간 값만 쓰는 측정값이라, 단순 합산한 값과 다릅니다.

납부 예정 대비 — 같은 표가 자금 회의 자료가 됩니다

예정 차이를 켜면 칸마다 실적 · 예정 · 차이 · 차이율이 나옵니다. 금액 기준과 비율 기준을 둘 다 넘을 때만 색을 칠하므로, 색이 칠린 칸은 정말 볼 가치가 있는 곳입니다.

기준값은 입력 칸에서 바꿀 수 있습니다. 샘플에서 관세는 +5.35억(+2.2%)으로 가장 크게 벗어났지만 비율 기준 5%에는 못 미쳐 색이 붙지 않습니다. 두 기준을 함께 보는 이유입니다.

아래 표의 일곱 요인과 검산 줄에서 예정 + 요인 합 − 실적 = 0 을 확인합니다. 부가가치세 행은 예정 365.98억에 신고 세액 증가 +13.13억 등이 더해져 실적 368.47억이 됩니다.

사유는 서비스에 저장되어 같은 조회 범위에서 다시 열 때 남아 있고 CSV와 해설 근거에도 실립니다. 사유 문구는 “점검 필요” 같은 표현으로 쓰는 것을 권합니다.

해설과 보고서 — 숫자는 서비스가, 문장은 초안으로

해설은 현재 범위를 읽어 요약과 점검 필요 항목을 정리합니다. 기본은 규칙 기반이며 모델 연결은 서비스 설정 하나로만 켜고 기본은 꺼져 있습니다. 해설은 숫자를 만들지 않습니다.

문장 속 숫자는 서비스가 계산한 값이고 문장 자체는 초안입니다. 이미 사유가 적힌 행은 건너뛰며, 해설에 쓴 숫자는 아래 근거 표를 펼쳐 확인합니다. [보고서 PPTX]는 현재 범위의 표와 차트를 담은 PowerPoint 를 브라우저 안에서 만들어 내려받습니다.

규칙에 걸리면 대기함으로 — 하루 한 번

에이전트는 감시 규칙을 점검해 걸린 항목을 받을 역할의 대기함에 올립니다. 실행은 하루 한 번으로 서버가 제한하고, 걸린 것이 없어도 활동 기록을 남깁니다.

규칙은 8일 이상 지연 납부 비중 5% 이상, 가산세·지연이자 1,500만원 이상, 납부액 예정 차이 5억원 이상, 기말 미납 잔액 8억원 이상입니다. 임계값은 샘플 설정이며 운영에서 조정합니다.

샘플에서는 규칙 4건 중 3건이 걸렸습니다. 대기함 보고는 받을 역할의 관점으로 쓰이고, 보고의 숫자는 서비스가 계산한 값입니다.

하루 한 번 제한은 화면이 아니라 서버가 판정하므로 화면을 여러 번 열어도 우회되지 않습니다. 운영에서는 배치 작업으로 같은 펑션을 호출하는 방식으로 연결하며, 이 글에서는 설명만 합니다.

짜 둔 축을 이름 붙여 저장해 둡니다

축 · 조회조건 · 측정값 · 표시 행 수 · 접힘 상태를 이름 붙여 저장합니다. 기본 보기로 지정하고 자동 조회까지 켜 두면 열자마자 조회된 채로 시작합니다.

저장 내용은 서비스의 보기 엔티티셋에 쌓이므로 사용자가 바뀌어도 같은 보기를 공유할 수 있습니다. 저장 전에 현재 축 배치 요약이 함께 보입니다.

메뉴의 “기본 배치로 되돌리기”는 저장한 보기를 지우지 않고 화면만 처음 배치로 돌립니다.

열 조합 상한과 좁은 화면

행 · 열 조합이 상한을 넘으면 반쯤 그린 표를 보여 주는 대신 범위를 좁히라는 안내를 띄웁니다. 좁은 화면에서는 차트가 표 아래로 내려갑니다.

이미 분기와 납부 채널이 열 축에 놓인 상태에서 하나 더 놓으려 하면 추가하지 않고 “열 축은 최대 2단계까지 둘 수 있습니다” 안내를 띄웁니다. 열 조합 수가 36을 넘는 경우에도 같은 방식으로 막습니다.

좁아지면 지표가 줄바꿈되고 조건 · 보관함이 세로로 놓이며 표가 아래로 내려갑니다. 표는 가로로 스크롤되고 위쪽 열 머리는 유지됩니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 CubeSet 과 PlanSet 을 기간 · 법인 조건으로 한 번씩 읽습니다. 이후의 축 전환 · 역할 전환 · 값 필터 · 예정 차이 켜기는 모두 읽어 둔 큐브 안에서 브라우저가 다시 계산하므로 서버를 부르지 않습니다. 칸을 눌렀을 때만 ItemSet 에서 원천 납부 라인을 읽고, 요인분해 · 해설 · 에이전트는 서버의 펑션이 계산합니다. 쓰기는 변동 사유 · 저장한 보기 · 대기함 확인 상태에만 일어납니다.

납부 예정 대비 차이가 요인으로 갈라지는 순서

요인분해는 원천 납부 라인 한 건마다 하나의 요인에만 속하게 해서 합이 총차이와 어긋날 수 없게 만듭니다. 라인 유형과 예정 · 실적의 있고 없음으로 순서대로 판정합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

720px 아래에서는 지표가 줄바꿈되고 조건 · 보관함이 세로로 놓입니다. 표와 차트는 위아래로 쌓이고 표는 가로로 스크롤됩니다. 390px 폭에서도 페이지 전체의 가로 스크롤은 생기지 않습니다.

파일 구성

앱 폴더/
  index.html · Component.js · manifest.json · readme.html
  controller/   화면 컨트롤러 (조회 · 축 · 드릴스루 · 요인분해 · 에이전트)
  view/         메인 화면과 대화창(원천 라인 · 변동 사유 · 해설 · 에이전트 · 보기 저장 · 값 필터)
  model/        재집계 · 차트 · 보기 저장 · 보고서(pptx) · 포매터
  css/ · i18n/
  odata/        서비스 정의(metadata) · 서비스 로직(service.js) · 공용 계산(calc.js) · 데이터
  media/        소개 영상 · 장면 목차

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래 표준 화면 구성은 시스템 버전에 따라 다를 수 있어 운영 시스템에서 확인이 필요합니다.

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

T-code 별 연계 지점

운영 전환 때 기존 표준 리포트를 없앨 필요는 없습니다. 법정 · 감사 · 세무 신고 대응은 표준 화면에 남겨 두고, 이 앱은 납부 쏠림 · 지연 · 예정 대비 차이를 내부에서 점검하는 자리로 씁니다.

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

이 앱의 큐브는 표준 CDS 분석 쿼리와 같은 구조(차원 · 측정값 · 쿼리 · 권한)로 설계했으므로, 운영에서는 표준 분석 기능과 나란히 둘 수 있습니다. 표준 Fiori 분석 앱의 이름과 제공 범위는 시스템 버전에 따라 달라 확인하지 못한 항목은 적지 않았으며 확인 필요입니다. 엑셀 연동 분석 도구로 같은 쿼리를 읽는 방식도 가능합니다.

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

분석 지표 정의표

CDS 구성 — 큐브부터 서비스까지

운영 데이터로 갈 때의 뷰 구성입니다. 객체 이름과 필드 이름은 설계 예시이며 실제 시스템 버전에 맞춰 확인 필요입니다. 표준 CDS 뷰 이름은 실재하는 것만 쓰고, 확인하지 못한 필드는 주석으로 표시했습니다.

뷰 레이어 구성

① 매핑 기준 테이블 — ZTX_TaxTypeMap

계정과 전표 유형을 이 앱의 세목 · 신고 구분 · 처리 단계로 바꾸는 표입니다. 운영에서 가장 자주 바뀌는 부분이라 코드가 아니라 데이터로 두었습니다. 매핑이 비면 납부가 전부 “기타”로 모여 분석이 무의미해집니다.

" ─────────────────────────────────────────────────────────────
" ZTX_TaxTypeMap — 세목 · 신고 구분 · 처리 단계 매핑
" 이렇게 나눈 이유: 매핑은 세무 담당이 바꾸는 데이터라 뷰 코드와 분리한다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '세목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table ztx_taxtypemap {
  key client     : abap.clnt not null;
  key glaccount  : abap.char(10) not null;  " 세금 · 공과금 계정
  key doctype    : abap.char(2) not null;   " 전표 유형
  tax_type       : abap.char(1) not null;   " V / W / C / D / L / I
  filing_code    : abap.char(1) not null;   " R 정기 · P 예정 · A 수정/기한후
  stage_code     : abap.char(2) not null;   " S1 신고 · S2 납부 · S3 정정 후 납부
}

② 차원 뷰 — ZI_PayBankDimension

은행 차원은 하우스 뱅크와 계정 ID를 묶어 은행 이름으로 보이게 합니다. 같은 은행의 여러 계좌가 하나의 은행으로 모여야 최대 은행 비중 같은 규칙이 의미가 있습니다.

" ─────────────────────────────────────────────────────────────
" ZI_PayBankDimension — 납부 은행 차원
" 이렇게 나눈 이유: 큐브는 은행 키만 알고, 이름과 정렬은 차원이 맡는다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '납부 은행 차원'
@ObjectModel.representativeKey : 'HouseBank'
@Analytics.dataCategory : #DIMENSION
@Metadata.ignorePropagatedAnnotations : true
define view entity ZI_PayBankDimension
  as select from t012
{
  key bukrs   as CompanyCode,
  key hbkid   as HouseBank,
      banks   as BankCountry,
      bankl   as BankKey
      " 은행 이름은 표준 은행 마스터에서 연결 — 필드명은 시스템 버전에 따라 확인 필요
}

③ 큐브 — ZI_TaxPayCube

세금·공과금 납부 한 건을 월 · 세목 · 은행 · 채널 · 신고 구분 · 기한 대비 · 처리 단계 · 환급 상계로 묶어 본세 · 가산세 · 환급 상계 · 납부액 · 미납 잔액을 집계합니다. 화면의 큐브 한 행이 이 뷰의 한 행입니다.

" ─────────────────────────────────────────────────────────────
" ZI_TaxPayCube — 월별 납부 큐브
" 이렇게 나눈 이유: 집계와 판정(기한 대비 · 신고 구분)을 서버에서 끝낸다.
" 원천: 표준 분개 항목 뷰 I_JournalEntryItem — 필드명은 버전에 따라 확인 필요
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '월별 납부 큐브'
@Analytics.dataCategory : #CUBE
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XL, dataClass : #MIXED }
define view entity ZI_TaxPayCube
  as select from I_JournalEntryItem as je
    inner join   ztx_taxtypemap     as mp on  mp.glaccount = je.GLAccount
                                          and mp.doctype   = je.AccountingDocumentType
{
  key je.CompanyCode,
  key je.FiscalYear,
  key je.AccountingDocument,
  key je.LedgerGLLineItem,
      substring(je.PostingDate, 1, 6)           as Period,
      mp.tax_type                               as TaxType,
      mp.filing_code                            as Filing,
      mp.stage_code                             as Stage,
      je.HouseBank                              as HouseBank,
      case
        when dats_days_between(je.DueCalculationBaseDate, je.PostingDate) <= 0 then 'O'
        when dats_days_between(je.DueCalculationBaseDate, je.PostingDate) <= 7 then 'S'
        else 'L'
      end                                       as LateClass,
      @Semantics.amount.currencyCode : 'Currency'
      cast( je.AmountInCompanyCodeCurrency as abap.curr(23,0) ) as PayAmount,
      je.CompanyCodeCurrency                    as Currency
}
" 모든 세금 · 공과금은 원화로 납부하므로 통화 환산 없이 합산한다.
" 외화로 신고한 관세는 신고서의 원화 환산액을 본세로 둔다. group by 는 쿼리 단계에서 수행.

④ 예정 큐브 — ZI_TaxPayPlanCube

납부 예정은 자금 계획 데이터에서 같은 축으로 집계합니다. 실적 큐브와 키가 같아야 차이 계산이 어긋나지 않습니다.

" ─────────────────────────────────────────────────────────────
" ZI_TaxPayPlanCube — 납부 예정 큐브 (버전 P0)
" 이렇게 나눈 이유: 실적 큐브와 같은 키 · 같은 측정값으로 맞춰 차이를 구한다.
" 원천: 자금 예정 FDES — 필드명은 시스템 버전에 따라 확인 필요
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '납부 예정 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_TaxPayPlanCube
  as select from fdes as pl
    inner join   ztx_taxtypemap as mp on mp.glaccount = pl.saknr
{
  key pl.bukrs                           as CompanyCode,
  key pl.dsart                           as PlanType,
  key pl.datum                           as PlanDate,
      'P0'                               as Version,
      substring(pl.datum, 1, 6)          as Period,
      mp.tax_type                        as TaxType,
      @Semantics.amount.currencyCode : 'Currency'
      pl.wrshb                           as PlanAmount,
      pl.waers                           as Currency
}

⑤ 분석 쿼리 — ZC_TaxPayQuery

화면이 읽는 단 하나의 입구입니다. 필터로 쓸 필드와 집계 방식을 여기서 정하고, 날짜 · 법인 필터는 필수로 둡니다.

" ─────────────────────────────────────────────────────────────
" ZC_TaxPayQuery — 분석 쿼리
" 이렇게 나눈 이유: 화면의 $filter 가 닿는 필드와 집계를 한곳에서 통제한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '세금·공과금 납부 분석'
@Analytics.query : true
@OData.publish : false
define view entity ZC_TaxPayQuery
  as select from ZI_TaxPayCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  Period,
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true }
  CompanyCode,
  @AnalyticsDetails.query.axis : #ROWS
  TaxType,
  @AnalyticsDetails.query.axis : #ROWS
  HouseBank,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Semantics.amount.currencyCode : 'Currency'
  sum( PayAmount ) as PayTotal,
  Currency
}
group by Period, CompanyCode, TaxType, HouseBank, Currency

⑥ 접근 제어 — ZR_TaxPayRole (DCL)

같은 쿼리를 읽어도 법인 · 은행 단위로 볼 수 있는 범위를 나눕니다. 권한 오브젝트와 필드 이름은 회사의 권한 설계에 맞춰 확인 필요입니다.

@EndUserText.label : '납부 분석 접근 제어'
@MappingRole : true
define role ZR_TaxPayRole {
  grant select on ZI_TaxPayCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}
" 은행 단위 제한이 필요하면 하우스 뱅크용 권한 오브젝트를 추가 조건으로 둔다 — 확인 필요

⑦ 서비스 정의 · 바인딩 — ZUI_TaxPay

쿼리를 OData V2 서비스로 게시합니다. 화면이 쓰는 서비스 주소는 이 바인딩을 활성화한 뒤 교체합니다.

@EndUserText.label : '세금·공과금 납부 분석 서비스'
define service ZUI_TaxPay {
  expose ZC_TaxPayQuery as TaxPayQuery;
  expose ZI_TaxPayCube  as CubeSet;
  expose ZI_TaxPayPlanCube as PlanSet;
}
" 바인딩 유형 OData V2 - UI 로 만들고 게시한다.
" 서비스 활성화는 서비스 관리 화면(/IWFND/MAINT_SERVICE)이나 바인딩 게시에서 한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하기 전에는 운영 데이터로 전환하지 않는 것을 권합니다.

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

같은 샘플 자료에서 대사식마다 전수로 돌린 결과입니다. 도입 포인트의 사례(범위 39개에서 요인 합이 총차이와 일치)와 같은 숫자입니다.

운영 데이터로 갈 때

납부 전표가 수천만 건이 되면 집계 위치가 중요해집니다. 월 범위와 법인을 필수 파라미터로 두고, 큐브는 월 단위로 미리 집계한 뷰에서 읽도록 하며, 날짜와 법인 필드에 맞는 인덱스나 집계 테이블을 둡니다. 화면은 큐브를 한 번 읽어 브라우저에서 다시 묶으므로 한 번에 읽는 행이 수천 행을 넘지 않게 쿼리의 필수 조건을 설계하고, 응답 시간 목표는 회사의 기준에 맞춰 정합니다.

자주 묻는 질문

도입 검토와 데모에서 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영