SAP 부가가치세 통합 관리 — 세금계산서 전표화부터 분기 정산 · 대사까지 한 앱에서 처리하고 승인하는 부가세 운영

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

부가가치세 업무의 질문은 분기마다 같습니다. 이번 분기 세금계산서가 모두 전표가 되었나, 납부(환급) 세액은 얼마이고 원장과 맞나, 누가 승인했고 무엇이 아직 남았나. 지금 이 세 답은 표준 전표 입력 화면, 세액 집계 엑셀, 승인 메일과 정산 메모로 흩어져 있고, 신고 일정이 가까워질수록 사람이 이어 붙이는 일이 늘어납니다. 이 앱은 세 답을 하나의 흐름으로 붙입니다. 세금계산서를 전표로 만들고, 승인하고, 분기 정산 문서를 만들고, 대사 규칙으로 원장과 맞춰 보고, 남은 예외를 정리하는 일을 한 화면 묶음 안에서 합니다. 신고서 작성과 최종 판단은 회사와 세무 대리인의 몫으로 두고, 그 앞단의 처리 · 승인 · 점검을 책임집니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 신고 전에 드러난 미전송 세금계산서와 시산표 차이

검증용 샘플 데이터(가상)에서 대사를 돌리자 국세청 전송이 끝나지 않은 채 전표화된 세금계산서 5건이 R7 예외로 잡혔고(최대 차이 73,711,000원), 회사 2000 의 시산표에서는 차변과 대변이 4,000원 어긋난 것이 R6 예외로 나타났습니다. 둘 다 월마감이나 신고 직전에 눈으로 찾기 어려운 종류의 차이입니다. 반대로 큐브 합계와 문서 라인 명세 합계는 48개 조합 모두 차이 0, 기말 잔액 항등식도 불일치 0건이었습니다. 앱이 보여 주는 숫자가 원천과 어긋나지 않는다는 점을 먼저 확인한 다음에야 예외를 이야기할 수 있기 때문입니다.

도입하면 달라지는 것

• 신고 준비 — 전표화 · 승인 · 정산 · 대사가 한 화면 흐름에서 이어져 엑셀 취합이 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나" 보다 "이 예외를 어떻게 정리할까" 를 이야기합니다.
• 책임의 기록 — 승인자와 처리자가 상태 이력과 감사 로그에 남습니다.
• 놓치는 날이 없는 점검 — 미전송 · 미정산 · 한쪽만 입력된 전표가 규칙에서 먼저 걸립니다.

이런 회사에 맞습니다

S/4HANA(또는 ECC)에서 매출 · 매입 세금계산서를 월 수백 건 이상 처리하고, 법인이나 사업장이 둘 이상이어서 분기 정산이 법인별로 갈리는 회사에 맞습니다. 처리 담당(재무 · 세무), 승인자(팀장 · 본부장), 관리자(세율표와 규칙 관리)가 나뉘어 있고, 불공제 매입세액이 원가 부서로 배부되는 구조라면 영역 간 연계의 효과가 큽니다. 반대로 세금계산서가 월 수십 건 안팎이고 한 사람이 전 과정을 맡는 조직이라면 표준 화면과 간단한 대사표로도 충분할 수 있습니다.

실행 화면

사용 방법

1. 상단 선택 — 오른쪽 위에서 회사(기본 전체) · 기간(기본 2026-09) · 사용자를 고릅니다. 선택값은 모든 화면에 적용되고, 사용자를 바꾸면 역할(조회자 · 처리자 · 승인자 · 관리자)에 맞게 버튼이 달라집니다.
2. 조회조건 입력 — 부가세 분석 화면은 기간(부터 · 까지)과 지표가 필수이고 비교 기준 · 계산 항목 · 필터는 선택입니다. 문서 처리 · 기준정보 화면은 검색어 · 상태 · 유형이 선택 조건입니다.
3. 조회 실행 — 분석 화면의 조회 버튼은 조회 조건 영역 오른쪽 끝에 있습니다. 문서 처리 · 기준정보 화면의 검색창은 Enter 키로 바로 검색합니다.
4. 요약 확인 — 개요 화면의 타일 10개와 결산 단계별 진행, 분석 화면의 큐브 합계 · 명세 합계, 시산표 화면의 점검 결과를 먼저 봅니다.
5. 탭 · 축 이동 — 기준정보, 시산표 · 재무제표, 이력 · 감사 · 권한의 탭을 차례로 확인하고, 분석 화면에서는 차원 칩을 행 · 열 칸으로 끌어 옮깁니다.
6. 행 · 셀 클릭 상세 — 문서 행을 누르면 차변 · 대변, 상태 이력, 연결 문서가 열리고 가능한 버튼이 보입니다. 분석 표의 칸을 누르면 원천 문서 라인까지 내려갑니다.
7. 내보내기 — 문서 · 대사 예외 · 기준정보 목록은 엑셀 내보내기, 분석 결과는 표 CSV 와 PPT 보고서로 받습니다.

일괄 실행은 먼저 ‘모의 실행’으로 대상과 금액을 확인하고(저장 안 됨), 이상이 없으면 ‘실행’합니다. 대사 예외는 조정 전표 · 보류 · 허용 종결 중 하나로 조치한 뒤 ‘대사 실행’을 다시 하면 해소 여부가 판단됩니다.

무엇으로 만들었나

앱 정보

처음 열었을 때 — 숫자는 타일에서 먼저 읽는다

숫자는 현재 선택한 회사 · 기간에 따라 바뀌며, 타일의 색은 점검이 필요한 정도를 뜻합니다. 기본은 회사 전체 · 2026-09 입니다.

처리자와 승인자는 보이는 할 일이 다릅니다. 사용자를 바꿔 같은 화면이 어떻게 달라지는지 확인해 보세요.

기준정보 관리 — 세금계산서 원장 · 세율표 · 계정 · 결산 과업

전송 상태가 ‘대기’ 또는 ‘점검 필요’인 행은 대사 R7 의 대상입니다. 표는 열이 많아 좁은 화면에서는 일부가 행 아래로 펼쳐집니다.

세율표를 바꾸면 R2(세액 = 공급가액 × 세율) 대사의 기준도 함께 바뀝니다. 샘플의 세율 10% · 0% 는 가정값입니다.

서브원장 잔액과 총계정 잔액이 다른 계정은 R1 예외의 후보입니다. 계정이 재무제표 라인에 연결되어 있는지도 여기서 봅니다.

17개 과업이 회사 · 기간마다 있어 합계 340건입니다. 선행 과업이 끝나지 않으면 시작 버튼이 열리지 않습니다.

과업 정의를 바꾸면 이후 기간에 생성되는 결산 과업에 반영됩니다. 이미 생성된 과업은 그대로 남습니다.

문서 처리와 승인 — 승인 버튼은 승인자에게만 보인다

유형(매출 · 매입 · 대손 · 정산 · 조정 · 원가 · 자금)과 상태로 거르면 승인 대기 건을 바로 찾을 수 있습니다. 행을 누르면 상세가 열립니다.

버튼은 현재 사용자의 역할과 문서 상태에 따라 달라집니다. 작성자 본인의 문서에서는 승인 버튼이 열리지 않습니다.

대상 세금계산서를 고르면 공급가액과 세액이 자동으로 채워집니다. 열린 기간이 아니면 작성할 수 없습니다.

시산표와 재무제표 — 차대 일치와 기말 항등식

점검 줄에 시산표 차변 · 대변 차이가 나오며, 회사 2000 에는 검증용으로 넣은 4,000원 차이가 R6 예외로 보입니다.

모든 계정이 재무제표 라인에 연결되어 있어야 자산 = 부채 + 자본이 맞게 나옵니다. 연결이 빠지면 R5 가 예외로 잡습니다.

일괄 실행 — 모의 실행 합계와 실행 결과가 같다

유형 · 기간은 필수이고 회사는 비우면 전체입니다. 지난 실행 이력에서 어떤 유형을 언제 돌렸는지 확인합니다.

모의 실행은 아무것도 저장하지 않습니다. 같은 조건으로 실행하면 이 합계와 같은 문서가 만들어지고, 다시 실행해도 중복은 생기지 않습니다.

대사와 예외 조치 — 규칙 7건이 남기는 예외

허용 범위를 넘은 규칙은 차이 건수가 0 이 아닌 값으로 보입니다. 규칙 이름을 누르면 해당 예외 목록으로 이동합니다.

조치 후 ‘대사 실행’을 다시 누르면 해소 여부가 판단됩니다. 허용 종결과 보류는 사유를 남겨야 합니다.

부가세 분석 — 조건 · 표 · 차트 · 요인분해 · 해설

기본은 최근 3개월 · 지표 2개이며 행은 계정, 열은 원인입니다. 차원 칩을 다른 칸으로 끌어 놓으면 배치가 바뀝니다.

이름을 누르면 해당 항목의 전표 명세가 열려 합계가 맞는지 확인할 수 있습니다. 오른쪽 차트는 첫 지표의 상위 항목이며 구분선을 끌어 폭을 조절합니다.

기준(계획 대비 · 직전 기간 대비)을 바꿔 다시 분해할 수 있습니다. 요인 합계가 전체 차이와 다르면 줄이 경고로 바뀝니다.

해설은 점검 참고용 문장이며 ‘점검 필요’처럼 원인을 단정하지 않는 표현을 씁니다. 모델 연결은 기본으로 꺼져 있습니다.

영역 간 연계 — 재무 문서가 만든 원가 · 자금 문서

매입 전표를 전기하면 불공제 세액의 원가 문서가 따라 생성됩니다. 역처리하면 선으로 이어진 연계 문서도 함께 되돌려집니다.

영역을 원가로 거르면 재무 문서에서 파생된 원가 문서만 남습니다. 자금 영역에서는 정산 뒤 만들어진 납부(환급) 문서를 봅니다.

이력 · 감사 · 역할 — 누가 언제 무엇을 했나

결과가 오류인 건만 거르면 거절된 요청을 찾아볼 수 있습니다. 조회자가 보낸 쓰기 요청이 거절된 기록도 남습니다.

문서 번호를 누르면 작성 → 검토 → 승인 → 전기 순서와 처리자 · 승인자를 시간순으로 확인합니다.

직무 분리 규칙(자기 승인 금지 · 2인 승인)이 상태 전이표와 함께 보여 사용자 전환으로 직접 검증해 볼 수 있습니다.

점검은 하루 한 번만 실행되며, 걸린 것이 없어도 실행 이력이 남습니다. 호출 주체(사람 · 화면 타이머 · 배치)가 함께 기록됩니다.

좁은 화면 — 390px 에서도 한 열로 읽힌다

메뉴 버튼으로 왼쪽 메뉴를 펼치고 접습니다. 가로 스크롤 없이 한 열로 읽히도록 확인했습니다.

화면 뒤에서 일어나는 일

이 앱이 쓰는 산출 · 대사식은 아래 순서입니다. 숫자가 어디서 만들어지고 어디서 맞춰 보는지를 따라가면 화면의 값을 그대로 읽을 수 있습니다.

1. 세액 산출 — 세액 = 공급가액 × 세율(세율표). 영세율 매출은 세율 0, 불공제 매입은 세액 전액을 원가로 배부합니다. (R2)
2. 공제세액 안분 — 공통매입은 불공제 비율로 나누어 공제세액 = 세액 − 불공제세액. 불공제 세액은 원가(영역 간 연계)로 배부됩니다. (R3)
3. 전표화와 원장 대사 — 전표화된 미정산 세액(서브원장) = 부가세예수금 · 부가세대급금 총계정 잔액. (R1)
4. 분기 정산 — 납부(환급) 세액 = 매출세액 − 대손세액 − 공제 매입세액. 정산 문서를 전기하면 해당 분기 세금계산서가 정산 완료로 표시되고 자금 문서가 따라 생성됩니다. (R4)
5. 시산표 · 재무제표 점검 — 차변 = 대변, 기말 = 기초 + 차변 − 대변 + 조정, 모든 계정이 재무제표 라인에 연결. (R5 · R6)
6. 국세청 전송 점검 — 전표화된 세금계산서의 전송 완료 여부. (R7)

대사 규칙 — 판정 조건 · 결과 상태 · 사용자 조치

허용 범위를 넘으면 예외가 생기고, 예외는 조치 중 → 해소 또는 보류, 허용 종결로 정리됩니다. 점검 결과는 ‘점검 필요’로 표시하며 원인을 단정하지 않습니다.

문서 상태 전이와 직무 분리

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 왼쪽 메뉴가 접히고 표는 필요한 열만 보입니다. 나머지 열은 행 아래로 펼쳐 볼 수 있고, 분석 화면의 차트는 표 아래로 내려옵니다. 화면이 가로로 넘치지 않도록 확인했습니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json · readme.html
├─ view/ (Main · Home · Master · Docs · Tb · Batch · Recon · Analysis · Flow · Audit)
├─ controller/ · fragment/ · i18n/ · css/
├─ model/ (Api · ErrorHandler · formatter · cube · chart · pptx)
├─ media/ (소개 영상 · 포스터 · 재생 지점)
└─ odata/ (서비스 정의 · 업무 규칙 · 엔티티셋별 샘플 데이터)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래는 어느 일을 표준에 두고, 어느 자리를 이 앱이 더하는지를 나란히 놓은 표입니다.

표준으로 되는 것과 이 앱이 더하는 것

T-code 별 연계 지점

맞닿은 표준 T-code 마다 이 앱이 이어받는 데이터, 두 화면 숫자를 맞춰 보는 지점, 오가는 방법을 적었습니다. 법정 · 감사 · 세무 신고 대응은 표준에 남겨 두므로 기존 표준 리포트를 없앨 필요는 없습니다.

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

이 앱의 분석 모듈은 CDS 큐브와 분석 쿼리를 읽는 구조(아래 “CDS 구성”)라서, S/4HANA 에서 CDS 분석 쿼리를 쓰는 환경이라면 같은 뷰를 다른 분석 도구와 함께 읽을 수 있습니다. 표준 분석 앱이나 Analysis for Office 와는 쓰는 목적이 다릅니다 — 그쪽은 자유 분석, 이 앱은 처리 · 승인 · 대사 흐름 안에서 숫자를 확인하는 자리입니다. 표준 제공 분석 앱의 구체 이름과 적용 범위는 확인하지 못해 적지 않았습니다(확인 필요).

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

분석 지표 정의표

세율 · 신고 서식 · 세법 조문은 이 글에서 단정하지 않습니다. 샘플의 세율 10% · 0% 는 가정값입니다.

CDS 구성

뷰 레이어 구성

기준 데이터에서 서비스까지 일곱 층으로 나눴습니다. 위로 갈수록 의미가 분명해지고, 아래 층의 이름 변경이 위로 번지지 않습니다.

① ZVAT_TAXMAP — 세금 코드 매핑 테이블

이 앱에서 가장 먼저 정해야 하는 데이터입니다. 세금 코드가 과세인지 영세율인지 불공제인지, 매입이라면 공통매입인지를 코드가 아니라 테이블 행으로 둡니다. 고객사마다 코드 체계가 달라 SQL 안에 like 'O%' 같은 조건을 박아 넣으면 이식이 되지 않습니다. 이 테이블이 비어 있으면 아래 모든 뷰가 같은 결과를 내지 못합니다.

" ───────────────────────────────────────────────────────────────
"  ZVAT_TAXMAP : 세금 코드 → 부가세 구분 매핑
"  역할 : 어떤 세금 코드가 매출 과세 · 영세율 · 매입 공제 · 불공제 인지를 정한다
"  이렇게 나눈 이유 : 세금 코드 체계는 고객사 설정이라, 조건을 뷰에 박지 않고
"                    테이블 행으로 두어 현업(세무팀)이 직접 관리하게 한다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '부가세 세금 코드 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zvat_taxmap {
  key client     : abap.clnt not null;
  key mwskz      : mwskz not null;            " 세금 코드
  key valid_from : abap.dats not null;        " 적용 시작일
  valid_to       : abap.dats;
  vat_kind       : abap.char(1);              " O 매출 · I 매입
  tax_class      : abap.char(4);              " STD 과세 · NIL 영세율 · EXM 면세
  deductible     : abap_boolean;              " 공제 가능 여부
  common_purch   : abap_boolean;              " 공통매입(안분 대상)
  rate_pct       : abap.dec(5,2);             " 세율(%) — 세율표와 대사(R2)에 쓴다
}

② ZVAT_INVOICE — 세금계산서 원장(앱 소유 테이블)

표준 전표(BKPF · BSEG · BSET)에는 “국세청에 전송했는가”, “정산이 끝났는가” 같은 상태가 없습니다. 그래서 세금계산서 한 장이 전표와 어떻게 이어지는지, 전송과 정산이 어디까지 갔는지를 앱 소유 테이블로 둡니다. 대사 R7(전송 ↔ 전표화)과 R1(원장 ↔ 총계정)이 모두 이 테이블에서 시작합니다.

" ───────────────────────────────────────────────────────────────
"  ZVAT_INVOICE : 세금계산서 원장
"  역할 : 세금계산서 1장 = 1행. 전표 연결 · 전송 상태 · 정산 완료 표시
"  이렇게 나눈 이유 : 표준 전표에 없는 "전송 · 정산" 상태를 앱이 책임지고,
"                    전표 쪽 값은 키(bukrs · belnr · gjahr)로만 연결한다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '부가세 세금계산서 원장'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zvat_invoice {
  key client      : abap.clnt not null;
  key invoice_id  : sysuuid_x16 not null;
  bukrs           : bukrs;
  kind            : abap.char(3);              " OUT 매출 · IN 매입 · BAD 대손 채권
  period          : abap.char(7);              " 귀속 기간 YYYY-MM 형식
  @Semantics.amount.currencyCode : 'zvat_invoice.waers'
  base_amount     : abap.curr(15,2);           " 공급가액
  @Semantics.amount.currencyCode : 'zvat_invoice.waers'
  tax_amount      : abap.curr(15,2);           " 세액
  waers           : waers;
  send_status     : abap.char(4);              " DONE · WAIT · CHK(점검 필요)
  belnr           : belnr_d;                   " 연결된 전표(전표화 전에는 비어 있음)
  gjahr           : gjahr;
  settled_doc     : abap.char(20);             " 분기 정산 문서(정산 전에는 비어 있음)
}

③ ZI_VatAccount — 계정 · 재무제표 라인 차원

분석 축이 되는 계정은 이름과 재무제표 라인을 함께 읽어야 합니다. 라인에 연결되지 않은 계정이 있으면 대사 R5 가 예외를 만들므로, 이 차원 뷰가 “라인이 없는 계정”을 숨기지 않고 그대로 드러내도록 left outer join 으로 읽습니다.

" ───────────────────────────────────────────────────────────────
"  ZI_VatAccount : 계정 차원
"  역할 : 계정 · 계정명 · 재무제표 라인을 한 행으로
"  이렇게 나눈 이유 : 라인 연결 누락을 숨기지 않기 위해 outer join 으로 읽는다
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'Account'
@EndUserText.label : '부가세 계정 차원'
define view entity ZI_VatAccount
  as select from ska1
    left outer join zvat_fsmap as _map on _map.saknr = ska1.saknr
    left outer join skat       as _txt on _txt.saknr = ska1.saknr
                                      and _txt.ktopl = ska1.ktopl
                                      and _txt.spras = $session.system_language
{
  @ObjectModel.text.element : [ 'AccountName' ]
  key ska1.saknr        as Account,
      @Semantics.text : true
      _txt.txt50        as AccountName,
      _map.fs_line      as FsLine,                       " 비어 있으면 R5 예외 대상
      case when _map.fs_line is null then 'X' else '' end as NoLineFlag
}

④ ZI_VatTaxLine — 세금 데이터 인터페이스 뷰

원천 테이블의 필드 이름(hwbas · hwste · mwskz)을 이 뷰 한 곳에서만 읽고, 위쪽 뷰는 의미 있는 이름(BaseAmount · TaxAmount)만 씁니다. 세금 코드는 매핑 테이블을 association 으로 이어 두어 “이 줄이 영세율인가”를 조건문이 아니라 조인 결과로 알 수 있게 합니다. 세액의 부호와 통화는 여기서 확정합니다.

" ───────────────────────────────────────────────────────────────
"  ZI_VatTaxLine : 세금 라인 인터페이스 뷰
"  역할 : 세금 데이터(BSET) + 전표 헤더(BKPF) + 세금 코드 매핑
"  이렇게 나눈 이유 : 원천 필드명은 이 뷰에서만 읽고, 위 뷰는 의미 이름만 쓴다
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '부가세 세금 라인'
define view entity ZI_VatTaxLine
  as select from bset
    inner join bkpf on  bkpf.bukrs = bset.bukrs
                    and bkpf.belnr = bset.belnr
                    and bkpf.gjahr = bset.gjahr
  association [0..1] to zvat_taxmap as _Map
      on  _Map.mwskz = bset.mwskz
      and _Map.valid_from <= bkpf.budat
      and ( _Map.valid_to is null or _Map.valid_to >= bkpf.budat )
{
  key bset.bukrs                         as CompanyCode,
  key bset.belnr                         as AccountingDocument,
  key bset.gjahr                         as FiscalYear,
  key bset.buzei                         as TaxItem,
      bset.mwskz                         as TaxCode,
      bkpf.budat                         as PostingDate,
      left( bkpf.budat, 6 )              as PostingPeriod,
      bkpf.waers                         as TransactionCurrency,
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      bset.hwbas                         as BaseAmount,       " 공급가액(과세표준)
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      bset.hwste                         as TaxAmount,        " 세액
      _Map.vat_kind                      as VatKind,
      _Map.tax_class                     as TaxClass,
      _Map.deductible                    as IsDeductible,
      _Map
}

⑤ ZI_VatCube — 분석 큐브

화면의 피벗과 드릴스루가 모두 이 큐브 한 벌에서 나옵니다. 합계가 어긋날 자리가 없다는 말은 “축을 바꿔도 같은 뷰를 다시 집계할 뿐”이라는 뜻입니다. 매출세액과 공제 매입세액은 case 로 가르고, 불공제 세액은 공제 가능 여부(IsDeductible)로 나눕니다. 이 큐브의 합계는 화면의 “큐브 합계”와 문서 라인 명세 합계를 맞춰 보는 검증의 기준이 됩니다.

" ───────────────────────────────────────────────────────────────
"  ZI_VatCube : 부가세 분석 큐브
"  역할 : 기간 · 회사 · 계정 · 세금 구분 축으로 세액을 집계
"  이렇게 나눈 이유 : 모든 분석 화면이 같은 집계를 읽어 합계가 갈라지지 않는다
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '부가세 분석 큐브'
define view entity ZI_VatCube
  as select from ZI_VatTaxLine as t
{
  key t.CompanyCode,
  key t.PostingPeriod,
  key t.TaxClass,
  key t.VatKind,
      t.TransactionCurrency,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      sum( t.BaseAmount )                                                      as BaseAmount,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      sum( case when t.VatKind = 'O' then t.TaxAmount else 0 end )             as OutputTax,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      sum( case when t.VatKind = 'I' and t.IsDeductible = 'X'
                then t.TaxAmount else 0 end )                                   as InputTaxDeductible,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      sum( case when t.VatKind = 'I' and t.IsDeductible = ''
                then t.TaxAmount else 0 end )                                   as InputTaxNonDeductible
}
group by t.CompanyCode, t.PostingPeriod, t.TaxClass, t.VatKind, t.TransactionCurrency

⑥ ZC_VatQuarterQuery — 분석 쿼리(Consumption)

큐브 위에 조회조건과 화면 노출 정보를 얹는 층입니다. 기간과 회사를 필수 필터로 두면 대용량에서도 무제한 집계가 일어나지 않습니다. 납부(환급) 세액은 저장하지 않고 쿼리에서 매출세액 − 공제 매입세액으로 계산합니다(대손세액은 별도 지표로 합산).

" ───────────────────────────────────────────────────────────────
"  ZC_VatQuarterQuery : 분기 부가세 분석 쿼리
"  역할 : 필수 필터(기간 · 회사)와 계산 지표(납부 · 환급 세액) 정의
"  이렇게 나눈 이유 : 계산은 쿼리에, 집계는 큐브에 두어 책임을 나눈다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '분기 부가세 분석'
@Analytics.query : true
@VDM.viewType : #CONSUMPTION
define view entity ZC_VatQuarterQuery
  as select from ZI_VatCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, mandatory : true, multipleSelections : false }
  key PostingPeriod,
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key CompanyCode,
  @AnalyticsDetails.query.axis : #ROWS
  key TaxClass,
  @AnalyticsDetails.query.axis : #COLUMNS
  OutputTax,
  @AnalyticsDetails.query.axis : #COLUMNS
  InputTaxDeductible,
  @AnalyticsDetails.query.axis : #COLUMNS
  InputTaxNonDeductible,
  @AnalyticsDetails.query.axis : #COLUMNS
  @EndUserText.label : '납부(환급) 세액'
  OutputTax - InputTaxDeductible as PayableTax          " 양수 납부, 음수 환급
}

⑦ ZC_VatQuarterQuery — DCL(접근 제어)

권한은 집계 단계에서 걸어야 합니다. 드릴스루 결과에만 걸면 합계에서 남의 회사 숫자를 뺄셈으로 알아낼 수 있습니다. 샘플의 역할 4종(조회 · 처리 · 승인 · 관리)은 운영에서 PFCG 역할과 권한 객체로 옮겨 이 DCL 과 연결합니다.

" ───────────────────────────────────────────────────────────────
"  ZC_VatQuarterQuery : 접근 제어(DCL)
"  역할 : 회사 코드 단위로 조회 범위를 제한
"  이렇게 나눈 이유 : 집계 단계에서 걸어 합계로 남의 숫자가 드러나지 않게 한다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '분기 부가세 분석 — 접근 제어'
@MappingRole : true
define role ZC_VATQUARTERQUERY {
  grant select on ZC_VatQuarterQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ ZUI_VatHub — 서비스 정의와 승인 액션(RAP)

화면은 서비스 한 개만 바라봅니다. 승인과 전기 같은 처리는 RAP 액션으로 노출해 서비스가 직무 분리(작성자 ≠ 승인자, 5천만 원 이상 2인 승인)를 다시 확인하게 합니다. 이 서비스 정의를 Binding 으로 게시하면 화면의 manifest.json 서비스 주소만 바꿔 운영에 연결할 수 있습니다.

" ───────────────────────────────────────────────────────────────
"  ZUI_VatHub : 서비스 정의 + 승인 액션(동작 정의)
"  역할 : 분석 쿼리와 문서 처리를 하나의 서비스로 노출하고
"        승인 · 전기 · 역처리 규칙을 서버에서 판정한다
"  이렇게 나눈 이유 : 화면의 버튼 숨김은 편의일 뿐, 권한 판정은 서버에 둔다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '부가가치세 통합 관리 서비스'
define service ZUI_VatHub {
  expose ZC_VatQuarterQuery as QuarterQuery;
  expose ZR_VatDocument     as Document;
}

managed implementation in class zbp_r_vatdocument unique;
strict ( 2 );
define behavior for ZR_VatDocument alias Document
persistent table zvat_document
lock master
authorization master ( instance )
{
  create; update;
  field ( readonly ) DocumentStatus, ApprovedBy, PostedAt;
  action ( features : instance ) submitForReview result [1] $self;
  action ( features : instance ) approve         result [1] $self;   " 작성자 본인 · 금액 구간 검사
  action ( features : instance ) reject parameter ZA_VatReason result [1] $self;
  action ( features : instance ) post            result [1] $self;
  action ( features : instance ) reverse parameter ZA_VatReason result [1] $self;
  validation checkSegregation on save { create; update; }
}

코드는 구조를 보이는 스케치이며 고객사의 세금 코드 · 계정 체계 · 릴리스에 따라 확인이 필요합니다. 표준 CDS 뷰 이름은 확인하지 못한 것을 쓰지 않고 원천 테이블 기준으로 적었습니다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 열두 가지가 정해져야 샘플이 아닌 실제 원장으로 연결됩니다.

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

검증용 샘플 데이터 전수에 대사식을 돌린 결과입니다. 규칙별 차이 15건은 모두 의도적으로 넣은 예외이고, 예기치 않은 차이는 0건입니다. 도입 포인트의 “사례로 보는 효과”가 같은 숫자입니다.

• 서비스 · 화면 점검 통과: 엔티티셋 36종 모두 데이터 존재, 키 없는 엔티티 0건, 필터 · 정렬 · 건수 제한 동작, 날짜 필터 동작.
• 업무 흐름 점검: 처리자 생성 → 검토 요청 → 같은 사용자 승인 거절 → 승인자 2단계 승인 → 전기 → 역처리(반대 문서 연결), 허용되지 않는 전이와 조회자 쓰기 거절, 일괄 실행 모의 합계 = 실행 합계(재실행 중복 없음), 대사 → 예외 조치 → 재대사.
• 화면 점검: 테마 sap_horizon, 조회 버튼 위치, 조회자 전환 시 쓰기 버튼 숨김, 390px 메뉴 접힘, 서비스 미연결 안내. 분석 PPT 보고서는 python-pptx 로 열림.

운영 데이터로 갈 때

세금계산서와 전표가 수천만 건이 되면 집계를 서비스 메모리가 아니라 CDS 큐브(데이터베이스 안)에서 해야 합니다. 분석 쿼리의 기간 · 회사 필터를 필수로 두고, 드릴스루는 건수 상한과 페이지 조회로 제한하며, 큐브의 집계 키(기간 · 회사 · 세금 구분)에 맞는 인덱스를 둡니다. 응답 시간 기준은 실제 건수로 측정해 정하고, 일괄 실행은 표준 일괄 처리 대상 건수에 맞춰 분할합니다.

자주 묻는 질문

도입을 검토할 때 자주 나오는 질문 24개를 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

권한과 직무 분리

도입과 운영