[MM 프로젝트 회고] ① BP (구매처) 생성

해당 시리즈는 약 한 달 동안 진행한 SAP MM 프로젝트의 각 단계를 직접 구현하며 겪은 과정을 회고 형식으로 정리한 글이다.

목차

1. 서론
  1.1 구매 프로세스
  1.2 구매 전표
  1.3 왜 입고의 대변은 GR/IR 임시계정일까?
  
2. 구매처 생성
  2.1 구매처 생성의 역할
  2.2 구매처 계정그룹 (SPRO)
  2.3 구매처 번호범위 설정 (SPRO)
  2.4 구매처 생성 (FK01)
    - 공급업체 마스터 3계층 : LFA1, LFB1, LFM1
  
3. 구매처마스터 3계층 설계
  3.1 총계정원장의 조정계정 (AKONT)
  3.2 지급조건 (ZTERM)
  3.3 세금코드 (MWSKZ)
    - 세금코드는 단순히 세율을 결정해주는 값이 아니라, 거래의 세무처리 방향을 결정해준다
    - 그래서 세금코드를 도메인으로 설계했다

1. 서론

1.1 구매 프로세스

SAP 모듈 중 MM은 자재 관리 모듈로, 기업의 자재 구매, 입고, 보관, 출고, 자재 관리를 위한 다양한 기능을 제공한다.

이때 MM은 대부분 위 사진과 같은 구매 프로세스 과정을 거친다.

구매 프로세스 과정
PR (구매요청생성) - PO (구매오더 생성) - GR (공급업체로부터 자재 입고) - IR (송장 수령) - 지급처리

기업에 따라 PR 없이 바로 PO를 생성하는 경우가 있다고 하지만, 대개 위 사진의 과정을 거쳐 구매오더를 처리해준다.

1.2 구매 전표

그렇다면 MM의 구매 프로세스 중,
회계적 사건이 발생하여 분개 처리가 필요한 단계는 총 몇 가지일까?

구매요청생성? 구매오더 생성? 입고? 송장? 지급?

정답은 총 3가지로,
입고 - 송장 - 지급 단계이다.

그럼 이제부터 각 단계별로

• 회계적 사건이 발생하는지 여부와
• 발생한다면 어떤 분개가 이루어지는지

를 위주로 차례대로 살펴보겠다.

먼저 회계적 사건의 사건적 정의부터 살펴보자.

1) 기업의 자산, 부채, 자본, 손익에 변화를 가져오는 모든 경제적 활동
2) 해당 활동을 금액으로 측정 가능

다시 MM의 구매 프로세스를 생각해보자.

구매요청생성 (PR)과 구매오더 생성(PO)은 데이터베이스 입장에서 새로운 구매오더에 대한 레코드 한 건이 추가는 되겠지만, 기업의 자산/부채/자본/비용/수익 그 어떤 것에도 영향을 주지 않기 때문에 회계적 사건이 아닌 것이다.

따라서 이 두 단계는 모두 회계적 사건이 아니다.

그렇다면 입고는 어떨까?

입고는 실제로 자재가 창고에 들어오는 시점이며,
이는 곧 재고자산의 증가를 의미한다.
따라서 복식부기의 원리에 따라 차변에 자산의 증가가 온다는 것을 쉽게 유추할 수 있다.

그렇다면 자연스럽게 이런 질문이 생길 것이다.

입고의 대변에는 무엇이 와야 하나?

입고에 대한 대가로 현금이 지급되어 현금의 감소일까? 혹은 외상으로 상품을 매입했기에 부채인 외상매입금일까?

놀랍게도 정답은 둘다 아닌, GR/IR '임시계정'이다.

입고의 분개
차) 자산의 증가, 대) GR/IR

1.3 왜 입고의 대변은 GR/IR 임시계정일까?

정답부터 말해보자면, 자재는 도착(입고)했으나, 거래처로부터 송장(Invoice)이 아직 도착하지 않아 확정 채무(외상매입금)를 인식할 수 없는 시차 때문이다.

예를 들어보자. 선박회사 A가 선박비품을 베트남 회사로부터 구입했다고 해보자. 이때 선박비품이 우리 창고에 도착했지만, 베트남 회사의 문제가 생겨 송장이 30일 뒤에 온다고 해보자.

그럼 입고 입장에서 송장비용이 정확히 책정될 30일동안 계속 기다리며 입고 처리를 안할 수 있겠는가?

당연히 정답은 아닐 것이다.

즉, 입고 시점에서는 부채 금액이 확정되지 않았기 때문에 외상매입금을 바로 인식할 수 없고,
대차평균의 원리를 맞추기 위해 GR/IR 이라는 임시계정을 사용하는 것이다.

이제 입고까지 모두 살펴보았다. 그렇다면, 입고의 그다음 단계인 송장은 어떨까?

송장 수령 단계는 구매오더에 기반해 송장 전기일, "세금처리" 후, "송장문서"를 생성하는 단계이다.

이때는 세금처리를 했기에 부가세 비용이 발생하고, 입고와 달리 확정채무를 측정할 수 있기에, 입고의 대변인 GR/IR을 송장의 차변에 두어 상계한 뒤, 대변에는 확정된 채무인 외상매입금을 작성해주면 된다.

송장의 분개
차) GR/IR , 대) 외상매입금
차) 부가세

현재 송장까지 모두 살펴보았다. 그럼 구매 프로세스의 마지막 단계인 지급 단계를 살펴보자.

지급 단계에서는 송장에서 발생한 외상매입금을 실제로 현금 등으로 지급하는 단계이다. 그렇기 때문에 외상매입금을 상계하여 부채가 감소하고, 실제로 현금을 지출한다고 가정해보면, 지급의 분개는 아래와 같다.

지급의 분개
차) 외상매입금, 대) 현금

서론이 길었다.

그럼 이제 위 구매 프로세스 중 첫번째인 구매처 생성을 어떻게 만들고 설계했는지 살펴보자.

---

2. 구매처 생성

2.1 구매처 생성의 역할

구매처 생성은 단순히 거래처/공급업체를 하나 더 만드는 작업이 아니라,

• 계정그룹을 통해 거래처의 유형을 정의하고,
• 해당 유형에 맞는 번호범위 체계와
• 일반/회사코드/구매조직 단위로 분리된 데이터 구조를 확정하는 단계이다.

2.2 구매처 계정그룹 (SPRO)

구매처 계정그룹은

• "해당 벤더가 어떤 유형의 거래처인지 정의하고"
• "어떤 번호범위 키(SNRO)를 사용할지를 결정하는 기준이다."

구매처 계정그룹은 거래처의 특성(국내, 해외, 1회성 등)을 구분지을 뿐만 아니라, 공급업체 마스터 데이터의 번호 범위(Number Range)와 화면 필드 상태 (필수/선택/숨김)을 결정지어주는 필드이다.

계정그룹 (KTOKK) 도메인

위 사진은 구매처 마스터 테이블(ZLFA109)의 구매처 계정그룹 필드인 KTOKK를 강조한 이미지이다.

본 프로젝트에서는 구매처 계정그룹을 다음과 같이 카테고리화하였다.

• 1000 : 국내
• 2000 : 해외
• 3000 : 개인
• 4000 : 부서
• 5000 : 법인카드
• 6000 : 금융기관
• 9000 : 1회성

이처럼 계정그룹을 숫자 체계로 구분함으로써,
계정그룹 번호만 보아도 거래처의 성격을 즉시 파악할 수 있도록 설계하였다.

또한, 구매처 계정그룹에 따라 이후 생성될 구매처 번호의 시작 값 역시 자동으로 결정되도록 구성하였다.
예를 들어 국내 구매처(1000번)는 1000000000번대, 해외 구매처(2000번)는 2000000000번대 번호가 부여된다.

마지막으로, 구매처 계정그룹에 따라 구매처 생성 화면의 필드 상태를 제어하였다.

• 국내(1000): 개인번호 필드 제외, 나머지 필드 표시
• 해외(2000): 개인번호·사업자번호 필드 제외
• 개인(3000): 사업자번호 필드 제외

이렇듯 구매처 계정그룹을 통해 거래처 성격, 구매처 번호 생성 규칙, 필드 상태 제어 등을 할 수 있다.

참고로, 본 프로젝트는 (주) 와플대학의 실제 거래처 유형에 따라, 구매 방식·회계 처리·입력 항목이 서로 달랐기 때문에 구매처 계정그룹 단계에서부터 거래처를 명확히 구분해 설계하였다.

2.3 구매처 번호범위 설정 (SPRO)

구매처 번호범위는

• 계정그룹에 의해 결정되는, 번호범위 키로 관리된다.
• 구조
  계정그룹
  └─ 번호범위 키
  └─ 실제 번호범위 (시작~끝, 내부/외부)

앞서 언급했듯이,
구매처 계정그룹에 따라 사용할 번호범위 키가 결정되며,
해당 번호범위 키에 의해 실제 구매처 번호의 범위가 확정된다.

이때 번호범위는 티코드 SNRO에서 설정가능하고, 자동 채번 방식을 사용한다.

2.4 구매처 생성 (FK01)

구매처 생성은

• FK01 티코드에서 사용자가 계정그룹을 선택하는 순간, 이미 해당 구매처의 번호범위 설정은 결정된 상태이다.
• 구매처 데이터는 단일 테이블이 아닌,
  일반 정보 / 회사코드 / 구매조직 단위로 3 Layer 테이블로 저장된다.

공급업체 마스터 (Vendor Master, BP)는 크게 3가지 항목인 일반데이터, 회사코드데이터, 구매조직데이터로 구분한다.

각각 어떤 기준으로 나누는지와 왜 3계층으로 데이터값을 관리하는지 알아보자.

공급업체 마스터 3계층 : LFA1, LFB1, LFM1

공급업체 마스터 (Vender Master)는 자재의 구입 및 조달에 필요한 회사나 구매책들에 대한 정보가 담긴 기준 정보이다.

예를 들어, 내가 TV를 생산하는 회사에서 부품을 사와야 하는 구매담당이라고 해보자. 그럼 이때 Vendor Master는 제품을 생산하는데 필요한 부품회사들이 된다.

즉, 공급업체 마스터는 구매처들의 모임이라고 볼 수 있다.

공급업체 마스터 데이터는

• Client level에서 관리되는 General Data
• Company level에서 관리되는 Accounting Data
• Purchasing Organization으로 나뉘는 Purchasing Data 로 나눌 수 있다.

먼저, General Data는 말그대로 Company Code에 적용되는 기준/기본 정보들을 말한다. 예를 들어 Vendor의 이름, 주소, 지역, 전화번호, 사용언어 등을 말한다.

그다음 Accounting Data도 단어에서 알 수 있듯이, Vendor와의 거래 시에 회계처리에 필요한 데이터가 저장된다. 예를 들자면, 회사에서 어떻게 Vendor에 지불할 것인지 (지급조건), 어떤 회계계정(외상매입금, 미지급금..)을 사용할 것인지 를 들 수 있다.

위 회계정보들은 동일한 회사일지라도 복수의 지역에 걸쳐 사업을 운영한다면, 각 지역마다 별도의 회사코드를 설정해야 한다.
예를 들어 와플대학 본사, 와플대학 부산지점, 와플대학 서울지점이 모두 각각 서로 다른 회계처리를 한다면 각 회계정보를 서로 다르게 저장해야 한다는 말이다.
왜냐하면, 회사코드 데이터(Accounting Data)는 회사의 경영단위 (재무제표를 산출하는 단위)이기 때문이다.

마지막 Purchasing Data는 구매처(Vendor)의 물품을 구입하고자 할 때 사용되는 데이터를 말한다.
예를 들자면 구매조직, 구매그룹, 세금코드 가 있다.

이때, 구매조직은 구매단가 등 구매 관련 합리적인 결정을 하는 그룹이다. 즉, 구매계약을 담당하는 주체이다.

반면, 구매그룹은 실제 구매 활동을 담당하는 담당자나 팀을 말한다. (ex : 구매1팀, 구매2팀)

---

지금까지 구매처 생성의 역할과 그 내용 (구매처 계정그룹, 구매처 번호범위, 3계층 데이터 구조)를 표준 기준으로 살펴보았다.

이제부터는 실제 프로젝트에서 구매처 마스터 3계층을 설계하면서 중요하게 봤던 부분들을 중심으로 정리해보려고 한다.

3. 구매처마스터 3계층 설계

본 프로젝트에서는 구매처마스터 테이블을 표준과 같이, 일반 데이터 테이블 (ZLFA109), 회사코드 데이터 테이블 (ZLFB109), 구매조직 데이터 테이블 (ZLFM109)로 나눴다.

그림 2-1. 일반데이터 테이블 (ZLFA109) 은 앞서 구매처 계정그룹 도메인에서 설명할 때 언급했던 테이블이다.

그림 2-2. 회사코드 데이터 테이블 (ZLFB109) 은 회사의 경영단위로 특히 총계정원장의 조정계정 (AKONT)과 지급조건 (ZTERM) 을 강조하였다.
이 내용은 아래에서 다시 살펴보겠다.

그림 2-3. 구매조직 데이터 테이블 (ZLFMA09) 은 구매하고자 할 때 사용되는 데이터로, 세금코드 (MWSKZ) 를 강조하였다.
이 내용 또한 아래에서 살펴보겠다.

아래에서는 앞에서 언급한 회사코드 데이터(총계정원장 조정계정, 지급조건)와 구매조직 데이터의 세금코드 도메인에 대해 살펴본다.

3-1. 총계정원장의 조정계정 (AKONT)

• 총계정원장 계정과 보조원장 계정 마스터데이터

  

  SAP의 계정(Account)는 크게 총계정원장과 보조부원장으로 구성되며, 보조원장은 4가지인 공급업체, 고객, 자산, 자재 계정이 있다.

  이때, G/L 계정은 총계정원장을 뜻하며 재무제표에 바로 반영된다.

  반면, 보조원장 계정은 각 거래처/고객/자산/자재별 상세 관리용 마스터테이블 (보통 3계층)을 저장하며,
  거래처인 경우 매입채무계정(부채), 고객인 경우 매출채권 계정(자산)의 내용을 저장한다.

  
  

• 조정계정은 보조부원장의 합계를 자동으로 총계정원장에 반영해주는 G/L 계정이다.

  조정계정은 거래처/고객별로 쌓인 보조부원장 데이터를 모아서, 재무제표용 G/L 계정에 총액으로 반영해주는 계정이다.

  보조부원장에서는 매입채무나 외상매출금같은 계정값들을 하나의 숫자로만 저장하지 않고, 거래처나 고객 하나하나를 기준으로 잔액을 따로 저장한다.

  보조부원장 중 하나인 공급업체 마스터를 예로, 아래와 같은 매입 거래가 발생한다고 가정해보자.

  • 거래처 A : 외상 매입 1,000
  • 거래처 B : 외상 매입 2,000
  • 거래처 C : 외상 매입 500

  이때 보조부원장에는
  "매입채무 = 3500"이라는 한 줄의 데이터가 저장되는 것이 아니라,

  • 거래처 A에게 빚진 금액 : 1,000
  • 거래처 B에게 빚진 금액 : 2,000
  • 거래처 C에게 빚진 금액 : 500

  처럼 거래처별로 나뉜 채무정보가 각각 저장된다.

  반면, G/L 계정은 재무제표 작성을 위한 근거가 되는 장부이기 때문에, 보조부원장처럼 '누구에게 대한 부채인가?'는 관심이 없고, 총 매입채무가 얼마인지만 필요하다.

  그래서 SAP는 보조부원장에 거래처별 채무가 하나씩 쌓일 때마다, 그 금액을 '매입채무'라는 G/L 계정에 '자동'으로 합산해주는데, 이때 사용되는 G/L 계정이 바로 조정계정이다.

• 그래서 왜 공급업체마스터의 조정계정은 전부 '채무'일까?

  

  구매처 마스터는 "우리 회사의" 공급업체를 관리하는 마스터이기에, 우리는 나중에 대금을 지급해야 하고 이때 공급업체별 채무가 발생한다.

  즉, 거래처 보조부원장에서 발생한 금액이 어떤 성격의 부채로 총계정원장에 집계될지를 결정하기 위해, 조정계정 도메인에 외상매입금(국내/수입/기타), 지급어음, 미지급금(국내/외화/법인카드), 미지급비용(지급이자/비용/퇴직금/상여금), 미지급배당금, 미지급법인세로 나눴다.

  당연하게도, 모두 부채이다.

  그럼 이제 AR 프로세스에서의 고객 마스터의 조정계정은 모두 자산임을 쉽게 유추할 수 있을 것이다.

  왜냐하면 고객 마스터는 "우리 회사"의 고객을 관리하는 마스터이기에, 해당 고객은 우리 회사가 제공한 상품/서비스에 대한 대금을 지급해야 한다. 즉, 고객마스터에서의 금액은 우리 회사가 회수할 권리이기에 자산에 해당한다.

  
  

• FI 입장에서 보는 조정계정

  앞에서 "조정계정이 보조부원장의 거래내역을 총계정원장으로 자동으로 반영"해준다고 했다. 그런데 그게 정확히 어떤 메커니즘인지 궁금했는데, 아래에서 정리해보자!

  FI에서 매출이나 매입 전표를 입력할 때,
  사용자는 G/L 계정번호를 직접 입력하지 않고
  Customer 혹은 Vendor 코드만 입력하면, 전표가 완성된다.

  아래 사진은 매출전표에서,
  Customer Master(고객마스터)의 코드만 입력하면,
  Customer 코드를 통해 조정계정(AKONT)을 읽어와,
  보조부원장의 거래(Customer)와 총계정원장의 집계(G/L 계정)을 동시에 처리하는 핵심 흐름이다.

  

  (0207 추가수정)
  - 보조원장(고객마스터,공급업체마스터..)의 코드만 입력하면, 
    SAP는 보조원장의 AKONT 필드를 참조해, 총계정원장에 반영할 G/L 계정을 결정하고,
    동시에
      - 보조부원장(Open item)
      - 총계정원장(G/L Line item)
      을 같은 전표 안에서 함께 생성한다.
  
  - 그럼 보조부원장의 AKONT가 총계정원장의 계정번호와 동일하다는 보장은?
     
     AKONT필드는
      1) FI 총계정마스터에 실제로 존재하는 G/L 계정인가?
      2) 해당 G/L 계정이 Vendor용이 맞는가?
          Recon. account for account type = Vendors.
           즉 공급업체마스터면 Vendors에 해당하는 영역이 맞는가?

  위 사진 속 매출전표는 아래와 같은 분개를 생성하기 위함이다. 어떻게 아래 분개가 전표에 저장될지 살펴보자.

  차) 매출채권 XXX, 대) 매출액 XXX

  
  

  매출전표 완성 흐름

  1. 전표 입력으로 가장 먼저 보조부원장 내역을 입력하는 이유

  AR 전표에서 매출이 발생했을 때, 중요한 정보는 두 가지이다.
  - 얼마를 받아야 할까?
  - 누구에게서 받아야 할까?

  그래서, 매출채권은 단순히 금액만 저장하는 G/L 계정이 아니라, 고객별로 미수 금액을 추적해야 하는 Open item이다.

  즉, 차변에 "매출채권"이라는 계정만으로는 부족하고, 어느 고객의 매출채권인지가 반드시 함께 저장되어야 한다.

  
  

  2. Customer 코드를 입력하면, 조정계정을 읽어온다.

  전표 입력시, 사용자가 Customer 코드를 입력하면,
  SAP는 내부적으로 회사코드 레벨의 Customer Master 데이터를 읽는다.

  이때 확인하는 핵심 필드가 AKONT (조정계정) 이다.

  AKONT에는 "이 고객의 매출채권을 어떤 G/L 계정으로 집계할 것인지"가 G/L 계정번호로 저장되어 있다.

  
  

  3. 조정계정을 읽어와, 보조부원장 + 총계정원장 2가지를 함께 처리한다.

  SAP는 AKONT에 적힌 G/L 계정번호를 가져와 데이터 일관성과 오류를 줄이기 위해, 다음 두 가지를 동시에 처리한다.

  • 보조부원장 (Sub Ledger)
    → 고객별 Open Item 데이터 생성

  • 총계정원장 (Main Ledger)
    → 조정계정(G/L)에 금액 집계

  이때, 사용자는 G/L 계정을 직접 입력하지 않고 Customer 코드만 입력했지만,
  결과적으로 전표는 정확한 G/L 계정 + 고객별 보조부원장을 함께 반영한다.

  이제 "조정계정이 보조부원장의 거래를 총계정원장에 자동 반영한다"는 의미를 어렴풋이 알 수 있을 것이다.

  
  

  4. 전표 생성할 때, 조정계정 입력을 막아둔 이유

  "조정계정은 반드시 Customer/Vendor/Asset 등 마스터 코드값을 정확히 입력해야만, 각 마스터에 연결된 G/L 계정이 들어온다."

  이게 이유다.

  FI 전표 화면에서 조정계정 G/L 번호를 직접 입력하는 것을 막아뒀기 때문에, SAP는 더욱 안전해진다.

  • G/L 계정에는 합계를 저장
  • 보조부원장에는 상세(Open item)을 저장
  • 두 원장의 금액 불일치를 구조적으로 차단

내용이 길었다. 다시 논점으로 돌아와보자.

아래 사진은 AR과 AP에서의 조정계정이 각각 차변과 대변에 반영되는 내용이다.

아래 사진을 다시 보자.

공급업체 마스터의 조정계정 도메인이 왜 채무인지 이제 알겠다.

3.2 지급조건 (ZTERM)

AP에서의 지급조건은 거래 발생 이후, 대금을 언제 지급할지를 정의한 기준이다. 아래 송장에서의 세금코드와도 연관이 깊다.

본 프로젝트에서는 지급일을 당월/익월 여부와 10일·25일 등 실제 업무에서 자주 사용하는 지급 시점을 기준으로 지급조건 도메인을 구성했다.

3.3 세금코드 (MWSKZ)

이제 마지막으로 구매조직 데이터 테이블의 세금코드(MWSKZ) 위주로 살펴보자.

세금코드 도메인 내용을 알려면, 우선 송장 단계부터 먼저 살펴보자.

아래 사진은 본 프로젝트에서 구현한 송장 생성 화면 중 일부이다.
송장 단계에서는 전기일을 기준으로 선택한 지급조건 값에 따라 만기일이 결정된다.

이때 전기일, 지급조건, 세금코드를 집중해서 볼 것이다.

1. 전기일
→ 이 거래를 어느 회계 기간에 인식할지

2. 지급조건
→ 언제 돈을 실제로 지급할지 (ex: M001 당월 10일)

3. 세금코드
→ 이 거래의 세무적 성격이 무엇인지

세금코드는 단순히 세율을 결정해주는 값이 아니라, 거래의 세무처리 방향을 결정해준다.

세금코드 도메인을 정하는 이유를 정확히 알기 위해, 먼저 매입불공제의 사전적 의미부터 정리해보자.

매입불공제란, 매입 거래와 관련하여 부담한 부가가치세 중 세법상 요건을 충족하지 못해 매출세액에서 공제받지 못하는 부가가치세를 말한다.

부가가치세는 재화나 용역이 생산·유통되는 각 단계에서 창출되는 부가가치에 대해 과세되는 세금으로, 사업자는 매출 시 발생한 매출세액에서 매입 시 부담한 매입세액을 차감하여 납부하거나 환급받는다.

다만, 사업과 무관한 지출이거나 적격 증빙이 없거나, 세법상 공제가 제한된 거래의 경우 해당 매입세액은 매입불공제로 처리되어 공제받을 수 없다.

매입불공제에 대한 감을 잡았으니, 다시 송장 처리 내용으로 돌아가보자.

세금코드 도메인이 중요해지는 경우를 예시로 들어보겠다.

- 전기일 : 12월 14일
- 지급조건 : +30일
- 실제 지급/처리 시점 : 다음 해 1월 

이 경우, 회계상 거래는 12월로 인식되었지만 세무 신고 타이밍이 1월로 어긋나면서, 해당 매입세액이 정상 공제 대상에서 벗어나게 된다..

그결과, 원래는 공제받았어야 할 부가세가 매입불공제처럼 처리되어 자칫하면 세금을 더 부과해야 하는 일이 발생할 수 있게 되는 것이다.

이때! 세금코드가 빛을 발한다.

송장 단계에서 선택되는 세금코드는 단순 부가세율을 계산하기 위함이 아니라, 이 거래를 세무적으로 어떻게 처리할 것인지를 시스템에 명확히 알려주는 기준이다.

즉, 전기일과 지급조건으로 인해
회계 인식 시점과 실제 처리 시점이 어긋날 가능성이 있는 상황에서도
세금코드를 통해 해당 매입 거래가

• 정상적인 매입세액 공제 대상인지
• 애초에 공제가 불가능한 거래인지

를 송장 입력 시점에 선택할 수 있다.

그래서 세금코드를 도메인으로 설계했다.

본 프로젝트에서는
송장 처리 시점에 입력자의 판단이나 실수로 세무 처리 방향이 달라지는 것을 방지하기 위해, 구매조직 데이터 테이블에 세금코드를 도메인값으로 제한했다.

진짜 마지막으로 세금코드 각 도메인값의 의미는 아래와 같다.

• V1 매입일반 10%
  일반적인 과세 매입 거래로, 정상적인 매입세액 공제 대상이다.
• V2 매입계산 0%
  계산서 대상 거래로, 부가세 자체가 발생하지 않는 매입
• V3 매입영세 0%
  영세율 적용 거래로, 세액은 없지만 신고대상이 되는 매입
• V4 매입불공제
  세법상 매입세액 공제가 허용되지 않는 거래로, 부가세는 환급대상이 아닌 비용으로 처리됨
• V5 매입고정자산
  고정자산 취득과 관련된 매입 거래로,
  일반 매입과 구분해 관리한다.

참고 링크

https://blog.naver.com/weblogic1/30082771303

https://economic-diary.tistory.com/entry/FI%EB%AA%A8%EB%93%88-Reconciliation-Account#google_vignette

https://blog.naver.com/u58jt4fspiygvckm/224055344590