SAP 법인세 세액공제 회계처리 점검 — IAS 12·IAS 20, 이월 공제의 이연법인세자산과 회사 정책별 효익을 다시 계산해 장부와 대조한다

개발 배경

결산 때 세무팀과 회계팀이 같은 질문으로 다시 만납니다. 올해 받은 세액공제를 우리 정책대로 처리했나, 쓰지 못하고 넘긴 공제는 자산으로 올려도 되나. 세액공제는 법인세에서 직접 빼는 방식도, 정부지원처럼 이연수익으로 두고 자산의 내용연수에 걸쳐 나누어 반영하는 방식도 쓰입니다. 투자세액공제처럼 IAS 12 법인세(K-IFRS 제1012호)와 IAS 20 정부보조금(K-IFRS 제1020호)이 처리 방법을 직접 정하지 않는 공제는 회사가 정책을 정하고 일관되게 적용하는 것이 점검의 핵심입니다. 사용하지 않은 세액공제 이월분은 미래 과세소득이 있을 가능성이 높은 범위에서 이연법인세자산으로 인식합니다. 두 기준서 원문의 정확한 표현은 원문으로 다시 확인해야 합니다.

문제는 이 점검이 보통 엑셀에서만 이뤄진다는 점입니다. 표준 화면은 계정 잔액과 전표 라인을 보여 주지만 "이 공제에는 어떤 정책이 적용됐고, 그 정책대로 다시 계산하면 장부와 같은가"는 계산해 주지 않습니다. 이 앱은 그 시트가 하던 일, 곧 공제 항목마다 적용 정책을 회사 정책과 비교하고, 이월분의 이연법인세자산과 법인세 효익을 정책대로 다시 계산해 장부와 맞춰 보는 일을 한 화면에 옮겨 둔 것입니다. 이 화면은 분류·집계·대사를 돕는 점검 도구이고, 처리 방식과 인식 여부의 최종 판단은 회사와 감사인이 합니다.

같은 공제가 해마다 다른 방식으로 처리되기 쉽다

공제 유형별 정책은 한 번 정하지만, 실제 전표는 담당자가 바뀌고 공제 종목이 늘면서 어긋납니다. 투자 공제는 이연수익법으로 두기로 했는데 한 건만 법인세 감소법으로 올라가 있는 식입니다. 이 앱은 공제 유형마다 회사 정책을 놓고 항목별 적용 정책과 나란히 보여, 정책이 다른 항목을 같은 표에서 바로 가려냅니다.

이월 공제의 자산 인식은 숫자 하나로 끝나지 않는다

이월 공제를 이연법인세자산으로 올리려면 미래에 그 공제를 쓸 만큼의 과세소득 추정이 필요합니다. 장부 자산이 이월 잔액과 같더라도 추정 사용액보다 크다면 한도를 넘은 부분이 생깁니다. 이 앱은 항목마다 이월 롤포워드(기초 + 발생 − 사용 − 소멸)를 다시 계산하고, 재계산 DTA 는 이월 잔액과 미래 사용 가능 추정액 중 작은 값으로 구해 장부 DTA 초과분을 따로 보여 줍니다.

효익이 맞는지는 정책마다 다른 산식으로 봐야 한다

법인세 감소법이면 당기 사용액에 이연법인세자산 증감을 더한 값이 효익이고, 이연수익법이면 발생액을 상각연수로 나눈 값이 효익입니다. 한 표 안에 두 방식이 섞여 있으면 담당자는 항목마다 다른 산식을 손으로 돌려야 합니다. 이 앱은 적용 정책에 맞는 산식을 서비스가 한 번에 적용해 장부 효익과 재계산 효익, 그 차이를 같은 열에 놓습니다.

"점검 필요"는 이유를 문장으로 말해야 쓸모가 있다

점검 대상이 "불일치" 한 줄로만 나오면 담당자는 결국 근거를 직접 열어 봐야 합니다. 이 앱은 정책 불일치, DTA 초과, 효익 차이 중 무엇이 걸렸는지를 점검 내용에 문장으로 남기고, 그 항목의 분개 명세를 같은 창에서 열어 줍니다. 판단을 대신하지 않고 판단에 필요한 재료를 한 자리에 두는 것이 이 화면의 일입니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 넣고 필요하면 공제 유형·적용 회계정책·공제 항목·확정일 범위·점검 결과를 고릅니다. 비워 두거나 "전체"를 고른 조건은 적용되지 않습니다.
2. 조회 — 조회 버튼을 누르거나 회계연도 칸에서 Enter 를 누릅니다. 화면을 처음 열 때는 기본 조건으로 자동 조회됩니다.
3. 요약 확인 — 판정 항목 수, 이연수익법 적용 항목 수, 점검 필요 항목 수, 장부 DTA 초과분 합계, 대사 차이 건수를 먼저 봅니다.
4. 탭 이동 — 공제 항목별 판정 → 공제 유형별 집계 → 효익 분개 명세 → 정합성 대사 순서로 근거 쪽으로 내려갑니다.
5. 행 클릭 상세 — 항목 행을 누르면 정책·이월·DTA·효익 재계산 값과 해당 항목의 분개 명세가 한 창에 열립니다.
6. 내보내기 — 현재 탭의 결과를 화면의 컬럼 이름과 표시 형식 그대로 UTF-8 CSV 로 내려받습니다.

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

화면에 나오는 숫자는 서비스가 계산하고, 그 계산을 서비스와 무관한 코드로 한 번 더 계산해 비교했습니다. 검사는 대사식 5종을 두 회계연도에 걸쳐 돌린 88건이며 차이는 0건입니다. 화면의 소계와 검증 스크립트 결과도 일치했습니다.

샘플 데이터에는 점검 필요 항목이 일부러 6건 들어 있습니다(2026년 통합투자세액공제 — 연구시설 · 연구·인력개발비 세액공제 — 신성장·원천기술 · 연구·인력개발비 세액공제 — 국가전략기술 · 외국납부세액공제, 2025년 환경설비 투자 세액공제 · 통합고용 세액공제). 이는 판정이 제대로 걸러내는지 보기 위한 의도적 예외이며 대사 차이와는 따로 기록했습니다. 금액·공제 종목·전표는 모두 가상이고 단위는 백만원입니다.

무엇으로 만들었나

실행 화면

아래 화면은 모두 검증용 샘플 데이터(가상, 단위 백만원)로 실제 렌더링한 것입니다. 화면 순서는 실제로 쓰는 순서를 따랐습니다.

처음 열었을 때와 점검 필요 항목 좁히기

조회조건과 요약, 첫 탭이 한 화면에 나오고, 점검 결과 조건 하나로 다시 확인할 항목만 남길 수 있습니다.

회계연도는 필수이고 기본값은 2026년입니다. 화면을 열면 자동으로 한 번 조회하므로 아무것도 누르지 않아도 10개 공제 항목의 판정 행이 보입니다. 조회 버튼은 조회조건 오른쪽 끝에 있고 회계연도 칸에서 Enter 를 눌러도 같은 조회가 됩니다. 요약 지표에서는 "점검 필요" 건수와 "장부 DTA 초과분"을 가장 먼저 보면 됩니다. 두 숫자가 0 이면 이번 조건 범위에서는 다시 확인할 공제가 없다는 뜻입니다.

샘플에서는 2026년 기준 4건이 남습니다. 행마다 회사 정책과 적용 회계정책, 기말 이월, 장부 DTA 와 재계산 DTA, 장부 효익과 재계산 효익이 나란히 있어 어느 값이 걸렸는지 한눈에 읽힙니다. 점검 내용 칸에는 정책 불일치, DTA 초과, 효익 차이 중 무엇인지가 문장으로 적힙니다. "점검 필요"는 원인이나 위반을 단정하는 표시가 아니라 다시 확인하라는 신호입니다.

유형으로 접고 분개 명세로 내려가기

공제 항목 판정을 유형 단위로 접어 보고, 장부 효익의 근거가 되는 전표 단위 분개까지 내려갑니다.

유형별 회사 정책(샘플에서 투자는 이연수익법, 나머지는 법인세 감소법)이 함께 표시되어, 같은 유형 안에서 처리 방식이 섞여 있는지 바로 보입니다. 유형 합계의 발생액은 항목 합계와 같아야 하며 이 관계는 대사에서 따로 확인합니다. 점검 필요 항목 수가 있는 유형은 첫 탭으로 돌아가 해당 항목을 눌러 보면 됩니다.

한 공제 항목의 분개 합계는 그 항목의 장부 법인세 효익과 같아야 합니다. 장부 숫자를 의심할 때 가장 먼저 내려오는 탭이며, 명세의 전표번호는 표준 전표 조회에 그대로 넣어 원본을 확인할 수 있습니다. 분개 구분 컬럼으로 공제 사용·자산 증감·상각 중 어느 분개가 합계를 만들었는지 가를 수 있습니다.

대사로 확인하고 상세로 사유 읽기

네 층의 합계가 서로 맞는지 확인하고, 점검 필요 항목은 상세 창에서 사유와 분개를 함께 읽습니다.

이월 롤포워드, 유형 집계, 재계산 효익 분해, 분개 합계 두 가지가 서로 맞는지를 화면이 스스로 매번 다시 잽니다. 차이 건수가 0 이 아닌 줄이 있으면 그 줄의 좌변·우변을 보고 어느 층에서 어긋났는지를 찾습니다. 샘플 데이터에서는 이 대사가 모두 0 으로 나오도록 만들었고, 점검 필요 항목은 대사 차이와 분리해 따로 기록했습니다.

목록에서 이미 본 숫자를 창 안에서 다시 풀어 보여 주는 화면입니다. 정책, 이월 롤포워드, 장부와 재계산 DTA, 장부와 재계산 효익, 점검 내용이 같은 창에 있어 "왜 점검 필요인가"가 바로 읽힙니다. 창을 닫으면 조회조건과 스크롤 위치가 그대로 남아 다음 항목으로 이어 갈 수 있습니다.

좁은 화면에서 본 모습

표는 컬럼을 줄이지 않고 가로 스크롤로 같은 내용을 보여 줍니다. 노트북 분할 화면이나 태블릿에서도 판정 컬럼이 빠지지 않는다는 점이 중요합니다. 조회 버튼과 초기화 버튼은 좁아져도 조회조건 바로 옆에 남습니다.

좁은 화면에서도 컬럼은 줄지 않고, 조회조건·요약 지표의 배치만 바뀝니다. 아래에서 설명하는 판정 규칙과 조회조건은 화면 폭과 무관하게 같습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 입력한 조건으로 표준 필터 객체를 만들어 서비스에 보내고, 서비스는 이월 내역과 정책 설정, 분개 명세를 읽어 항목 단위로 판정까지 끝낸 행을 돌려줍니다. 화면은 받은 행을 그대로 표에 연결하고, 정렬과 스크롤도 서비스가 처리합니다. 요약 지표 중 "장부 DTA 초과분"만 서비스의 함수를 한 번 더 불러 받아 옵니다.

회계처리 판정 규칙

회사 정책은 공제 유형별로 정해 두는 샘플 설정이며(투자 세액공제는 이연수익법, 연구·인력개발·고용·기타는 법인세 감소법) 회사의 실제 정책에 맞게 바꿔야 합니다. 두 기준서 원문이 투자세액공제의 처리 방법을 정하는지 여부와 구체 표현은 확인 필요입니다.

산출 순서와 대사식

1. 기말 이월 = 기초 이월 + 당기 발생 − 당기 사용 − 당기 소멸
2. 재계산 DTA — 회사 정책이 법인세 감소법이면 min(기말 이월, 미래 사용 가능 추정액), 이연수익법이면 0
3. DTA 초과분 = max(장부 DTA − 재계산 DTA, 0)
4. 재계산 효익 — 법인세 감소법이면 당기 사용 + (재계산 DTA − 기초 DTA), 이연수익법이면 당기 발생 ÷ 상각연수(소수 첫째 자리 반올림)
5. 장부 효익 — 적용 정책이 법인세 감소법이면 당기 사용 + (장부 DTA − 기초 DTA), 이연수익법이면 이연수익 상각 분개 금액
6. 효익 차이 = 장부 효익 − 재계산 효익
7. 점검 결과 — 정책 불일치 · DTA 초과 · 효익 차이 중 하나라도 있으면 점검 필요, 그 밖은 정상

대사식은 다섯 가지입니다. R01 기초 + 발생 − 사용 − 소멸 = 기말 이월, R02 유형별 발생액 = 항목별 발생액 합계, R03 재계산 효익 = 사용 + (재계산 DTA − 기초 DTA) 또는 발생 ÷ 상각연수, R04 장부 효익 = 효익 분개 명세 합계, R05 장부 DTA 기말 − 기초 = DTA 분개 합계입니다. 금액 단위는 백만원이며 소수 첫째 자리까지 다룹니다. 미래 사용 가능 추정액(미래 과세소득 전망), 상각연수, 회사 정책은 회사가 정하는 값이며 확인 필요입니다.

조회조건

대사 탭은 회계연도만 조건으로 받고, 효익 분개 명세 탭은 적용 회계정책·점검 결과 조건을 적용하지 않습니다.

결과 컬럼

좁은 화면에서 달라지는 것

폭이 줄면 조회조건이 여러 줄로 나뉘고 요약 지표도 줄바꿈됩니다. 표는 컬럼 수를 줄이지 않고 가로 스크롤을 줍니다. 상세 창은 화면 폭에 맞춰 줄어들며 닫으면 이전 조회 상태가 그대로 남습니다.

파일 구성

화면 앱
├─ 시작 파일 · 앱 설정 · 컴포넌트
├─ 화면 정의(메인 화면 · 상세 창)
├─ 컨트롤러(조회·정렬·상세·내보내기)
├─ 모델 보조(표시 형식 · 오류 처리)
├─ 문구 · 스타일
└─ 서비스 구현(항목 판정 · 유형 집계 · 대사 · 초과분 합계 함수)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 아래 표는 표준 화면으로 충분한 일과 이 앱이 더하는 관점을 나란히 놓은 것입니다.

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

T-code 별 연계 지점

운영 전환 시에도 기존 리포트를 없앨 필요는 없습니다. 표준 화면은 법정·감사 대응의 기록으로 그대로 두고, 이 앱은 결산 전에 정책 일관성과 이월 공제의 인식 범위를 다시 확인하는 용도로 나란히 씁니다.

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

이 앱의 계산은 CDS 큐브와 분석 쿼리로 옮길 수 있게 나뉘어 있습니다. 표준 Fiori 분석 앱이나 Analysis for Office 에서 같은 쿼리를 읽으면 같은 판정이 나오고, 이 앱의 화면은 그 위에서 점검 흐름(조회 → 점검 필요 좁히기 → 상세 → 대사)을 맡습니다. 표준 CDS 뷰의 이름과 필드는 릴리스마다 다를 수 있어 이 글에서는 원천 테이블 기준으로 쓰고, 표준 뷰 사용 여부는 확인 필요로 둡니다.

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

요구사항 매핑

CDS 구성

아래는 같은 판정을 S/4HANA 의 CDS 로 옮길 때의 구성안입니다. 샘플 앱의 서비스 로직과 같은 규칙을 뷰 단계로 나눈 것이며, 객체 이름은 설명을 위한 가상의 이름입니다. 표준 CDS 뷰의 이름과 필드는 릴리스별 확인 필요이고, 여기서는 원천 테이블을 직접 읽는 형태로 적었습니다. 코드는 구성의 뼈대를 보이기 위한 것으로 실제 시스템에서 활성화 전에 문법과 필드를 확인해야 합니다.

뷰 레이어 구성

① 회사 정책표 — 공제 유형별 정책과 상각연수를 정하는 자리

세액공제를 법인세 감소법으로 볼지 이연수익법으로 볼지는 표준 마스터에 없는 회사 결정입니다. 이 값이 코드에 묻히면 정책을 바꿀 때마다 이송이 필요하므로 테이블로 뺍니다. 운영에서는 이 표가 비어 있거나 틀리면 정책 불일치 판정 전체가 무의미해지므로 가장 먼저 합의해야 하는 객체입니다.

" ─────────────────────────────────────────────────────────────
"  ZTXCR_POLICY — 공제 유형별 회사 정책
"  역할 : 공제 유형마다 회사가 택한 회계처리 정책과 이연수익법 상각연수를 보관
"  이렇게 나눈 이유 : 정책은 회사 결정이고 바뀔 수 있다. 코드에 두면 정책 변경이
"         곧 이송이 되므로 현업이 변경 이력과 함께 고치는 테이블로 둔다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '세액공제 회사 정책'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table ztxcr_policy {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key credit_typ : abap.char(3) not null;   " INV / RND / EMP / OTH
  valid_from     : abap.dats not null;      " 정책 적용 시작일
  policy         : abap.char(3) not null;   " TAX(법인세 감소법) / DEF(이연수익법)
  life_years     : abap.int1;               " 이연수익법 상각연수
  changed_by     : syuname;
}

② 공제 이월 내역 — 기초·발생·사용·소멸을 보관하는 자리

이월 롤포워드의 원천입니다. 세무 신고 자료와 맞춰야 하는 숫자이므로 항목별로 한 줄을 두고, 소멸 예정 연도와 미래 사용 가능 추정액을 같은 행에 둡니다. 원천이 되는 표준 테이블은 확인 필요이며 여기서는 회사 자료 테이블로 적었습니다.

" ─────────────────────────────────────────────────────────────
"  ZTXCR_CARRY — 공제 항목별 이월 내역
"  역할 : 항목별 기초 이월·당기 발생·당기 사용·당기 소멸과 소멸 예정 연도,
"         미래 사용 가능 추정액(회사 판단)을 연도별로 보관
"  이렇게 나눈 이유 : 롤포워드는 세무 자료와 맞춰야 하므로 전표에서 역산하지 않고
"         확정 값을 따로 둔다. 장부(전표)와 다른 출처여야 대사가 의미가 있다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '세액공제 이월 내역'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table ztxcr_carry {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key gjahr      : gjahr not null;
  key credit_no  : abap.char(3) not null;
  credit_typ     : abap.char(3) not null;
  applied_policy : abap.char(3) not null;   " 실제 적용한 정책
  @Semantics.amount.currencyCode : 'ztxcr_carry.waers'
  open_amt       : abap.curr(15,2);
  @Semantics.amount.currencyCode : 'ztxcr_carry.waers'
  claimed        : abap.curr(15,2);
  @Semantics.amount.currencyCode : 'ztxcr_carry.waers'
  used_amt       : abap.curr(15,2);
  @Semantics.amount.currencyCode : 'ztxcr_carry.waers'
  expired_amt    : abap.curr(15,2);
  @Semantics.amount.currencyCode : 'ztxcr_carry.waers'
  probable_use   : abap.curr(15,2);         " 미래 사용 가능 추정액
  expire_year    : gjahr;
  waers          : waers;
}

③ 효익 분개 기준 뷰 — 전표 라인을 공제 항목에 붙이는 자리

장부 DTA 와 장부 효익은 전표에서 나옵니다. 이 뷰는 원장 라인에서 법인세비용·이연법인세자산·이연수익 계정만 골라 분개 구분을 붙이고 한 줄에 모읍니다. 판정과 대사가 같은 원천을 읽게 하는 것이 목적이며, 계정 매핑은 회사 설계이므로 확인 필요입니다.

" ─────────────────────────────────────────────────────────────
"  ZI_TxcrJournal — 효익 분개 기준 뷰
"  역할 : 원장 라인 중 세액공제 관련 계정을 골라 분개 구분(사용·자산 증감·상각)을
"         붙이고 공제 항목 키와 함께 한 줄에 모은다
"  이렇게 나눈 이유 : 장부 효익·장부 DTA·분개 대사가 모두 같은 줄을 읽어야
"         같은 숫자에서 출발한다. 계정 매핑은 아래 case 한 곳에서만 바꾼다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '세액공제 효익 분개'
define view entity ZI_TxcrJournal
  as select from acdoca as a
  inner join ztxcr_acctmap as m
    on m.saknr = a.racct
{
  key a.rldnr                      as Ledger,
  key a.rbukrs                     as CompanyCode,
  key a.gjahr                      as FiscalYear,
  key a.belnr                      as AccountingDocument,
  key a.docln                      as LedgerGLLineItem,
      m.credit_no                  as CreditNo,
      case m.line_kind
        when 'U' then 'USED'       " 공제 사용
        when 'D' then 'DTA'        " 이연법인세자산 증감
        when 'A' then 'AMORT'      " 이연수익 상각
        else 'OTHER' end           as LineKind,
      a.budat                      as PostingDate,
      @Semantics.amount.currencyCode : 'Currency'
      a.hsl                        as Amount,
      a.rhcur                      as Currency
}
where a.rldnr = '0L'

④ 판정 큐브 — 공제 항목 단위로 정책·한도·효익을 계산하는 자리

판정이 한 곳에서 일어나는 객체입니다. 이월 내역에 정책표를 붙이고, 분개 뷰를 항목별로 접어 장부 DTA·장부 효익을 구한 뒤 재계산 값과 비교합니다. 판정을 뷰에 두면 어떤 소비자가 읽어도 같은 결론이 나옵니다. 정책별 산식(법인세 감소법·이연수익법)이 case 로 갈리는 부분이 이 객체의 핵심입니다.

" ─────────────────────────────────────────────────────────────
"  ZR_TxcrCheckCube — 공제 항목 판정 큐브
"  역할 : 이월 롤포워드, 재계산 DTA, DTA 초과분, 정책별 재계산 효익, 효익 차이,
"         점검 결과를 공제 항목 단위로 계산
"  이렇게 나눈 이유 : 판정을 화면이나 쿼리에 두면 소비자마다 결론이 달라질 수 있다.
"         계산은 큐브에서 한 번, 노출은 쿼리에서 한다
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '세액공제 판정 큐브'
define view entity ZR_TxcrCheckCube
  as select from ztxcr_carry as c
  inner join ztxcr_policy as p
    on  p.bukrs      = c.bukrs
    and p.credit_typ = c.credit_typ
  left outer join ZI_TxcrJournalSum as j
    on  j.CompanyCode = c.bukrs
    and j.FiscalYear  = c.gjahr
    and j.CreditNo    = c.credit_no
{
  key c.bukrs                                     as CompanyCode,
  key c.gjahr                                     as FiscalYear,
  key c.credit_no                                 as CreditNo,
      c.credit_typ                                as CreditType,
      p.policy                                    as CompanyPolicy,
      c.applied_policy                            as AppliedPolicy,
      c.open_amt + c.claimed - c.used_amt - c.expired_amt   as CarryAmt,
      j.BookDta                                   as BookDta,
      case p.policy
        when 'TAX' then least( c.open_amt + c.claimed - c.used_amt - c.expired_amt,
                               c.probable_use )
        else cast( 0 as abap.curr(15,2) ) end     as ExpectedDta,
      case p.policy
        when 'TAX' then c.used_amt + ( least( c.open_amt + c.claimed - c.used_amt - c.expired_amt,
                                               c.probable_use ) - j.OpenDta )
        else div( c.claimed, p.life_years ) end   as ExpectedBenefit,
      j.BookBenefit                               as BookBenefit,
      case when p.policy <> c.applied_policy then 'POLICY'
           when j.BookDta >  case p.policy when 'TAX'
                  then least( c.open_amt + c.claimed - c.used_amt - c.expired_amt, c.probable_use )
                  else 0 end then 'DTA'
           else 'OK' end                          as CheckReason
}

⑤ 분석 쿼리 — 조회조건과 점검 결과를 노출하는 자리

큐브는 계산만 하고, 어떤 조건을 받고 어떤 컬럼을 보일지는 쿼리가 정합니다. 회계연도를 필수 파라미터로 받고, 유형·정책·점검 결과를 필터로 노출합니다. 화면의 조회조건이 이 쿼리의 필터와 같은 이름을 쓰면 서비스 교체가 쉬워집니다.

" ─────────────────────────────────────────────────────────────
"  ZC_TxcrCreditQuery — 공제 항목 점검 쿼리
"  역할 : 판정 큐브의 컬럼 중 화면이 쓰는 것만 노출하고 조회조건을 정의
"  이렇게 나눈 이유 : 계산 변경과 화면 노출 변경의 영향 범위를 나누기 위해
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '세액공제 점검 쿼리'
define view entity ZC_TxcrCreditQuery
  with parameters
    @Consumption.derivation : { lookupEntity : 'I_FiscalYear' }
    P_FiscalYear : gjahr
  as select from ZR_TxcrCheckCube
{
  @AnalyticsDetails.query.axis : #ROWS
  key CreditNo,
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : false }
  CreditType,
  @Consumption.filter.selectionType : #SINGLE
  AppliedPolicy,
  @Consumption.filter.selectionType : #SINGLE
  CheckReason,
  @AnalyticsDetails.query.axis : #COLUMNS
  CarryAmt, BookDta, ExpectedDta, BookBenefit, ExpectedBenefit
}
where FiscalYear = $parameters.P_FiscalYear

⑥ 접근 제어 — 회사코드 단위로 조회 범위를 거는 자리

세액공제는 회사별 세무 정보라 권한을 가장 아래에서 한 번만 걸어 모든 탭과 쿼리에 적용합니다. 상위 뷰마다 따로 걸면 한 곳이 빠졌을 때 다른 회사의 숫자가 보일 수 있습니다.

" ─────────────────────────────────────────────────────────────
"  ZR_TxcrCheckCube — 접근 제어(DCL)
"  역할 : 사용자의 회사코드 권한 범위 안의 행만 판정 큐브에서 읽히게 함
"  이렇게 나눈 이유 : 계산이 일어나는 큐브에서 한 번 걸어 모든 소비자에 적용
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '세액공제 판정 큐브 접근 제어'
@MappingRole : true
define role ZR_TXCRCHECKCUBE {
  grant select on ZR_TxcrCheckCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의 — 쿼리를 OData 로 노출하는 자리

화면은 서비스 바인딩 주소만 알면 되도록 쿼리를 서비스 정의로 묶습니다. 바인딩을 OData V2 로 게시하고 화면 설정의 서비스 경로를 이 주소로 바꾸면 화면 코드는 그대로 운영 서비스에 붙습니다.

" ─────────────────────────────────────────────────────────────
"  ZUI_TxcrCheck — 서비스 정의
"  역할 : 공제 항목·유형·분개 명세·대사 쿼리를 한 서비스로 묶는다
"  이렇게 나눈 이유 : 화면은 바인딩 주소 하나만 알면 되고, 쿼리가 늘어도
"         화면 설정은 바뀌지 않는다
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '세액공제 점검 서비스'
define service ZUI_TxcrCheck {
  expose ZC_TxcrCreditQuery as CreditSet;
  expose ZC_TxcrTypeQuery   as TypeSet;
  expose ZC_TxcrLineQuery   as LineSet;
  expose ZC_TxcrReconQuery  as ReconSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 일곱 가지는 코딩이 아니라 합의이며, 합의가 끝나면 기술 작업은 위 뷰를 만들고 서비스를 게시하는 일입니다.

운영 데이터로 갈 때

전표가 수천만 건인 환경에서는 원장 라인을 매번 훑지 않도록 회계연도를 필수 파라미터로 받고, 분개 합계는 항목 키와 연도 기준으로 먼저 접어 둡니다. 세액공제 관련 계정은 범위가 좁으므로 계정 매핑표로 먼저 거른 뒤 조인하고, 첫 조회 응답 시간 기준(예: 몇 초 이내)은 회사와 합의해 성능 시험으로 확인합니다. 구체 수치는 환경에 따라 달라 이 글에서 단언하지 않습니다.

자주 묻는 질문

숫자와 판정, 화면과 조작, 표준 연계와 분석, 도입과 운영 순서로 묶었습니다.

숫자와 판정

화면과 조작

표준 연계와 분석

도입과 운영