WIP-[책] 알기쉽게 정리한 SAP FI S/4 HANA(개정판) - Customer / Vendor Accounts

최초 작성일: 25.08.11

최종 작성일: 

 

Customer/ Vendor Accounts

3-1. Customer/ Vendor Accounts Segment (View)

 

하나의 Customer Account는 하나의 General Data 부분 (혹은 Client 레벨의 Segment 혹은 View)과

각각 하나 혹은 여러 개 씩의 Company Code Data와 Sales Area Data가 있음

Company Code : 주로 재무부서에서 생성 하여 관리하는 필드 들로 전표 생성에 꼭 필요한 정보 저장

Sales Area Data : 주로 판매부서에서 생성 및 관리를 하며, 판매 오더를 생성하고 처리 하기 위하여 꼭 필요한 정보필드들을 저장하여 관리 함

 

하나의 Vendor Account는 하나의 General Data 부분 (혹은 Client 레벨의 Segment 혹은 View)과 각각의 하나 혹은 여러 개식의 Company Code Data와 Puchasing Organization Data를 가지고 있음

Puchasing Organization Data 부분은 주로 구매부서에서 생성 및 관리를 하며, 구매 오더를 생성할 수 있도록 해주는 기본적인 마스터 데이터 임

 

XD01 ~XD03 , XK01~XK03 -> BP로 변경됨

3-2. Vendor / Customer Account Group의 역할 및 특성 -> cloud public 상 bp는 찾았는데, customer, vendor는 못찾겠음

①Vendor나 Customer Account 생성 시에 사용가능한 Code 값의 NR 결정 - Internal, External

②Vendor 나 Customer Account의 필드 통제 가능

③One Time Account : 어쩌다 한번만 사용하는 Vendor나 Customer인 경우에는 굳이 한번의 사용을 위하여 Vendor/Customer Master 데이터를 생성하여 관리하지 않고 One Time Account Group을 생성하고 이 그룹에 일종의 dummy를 하나만 만들어 놓고 전표 입력 시에 이 Dummy Master 코드를 입력한 후에 필요한 Customer/Vendor의 관련 정보를 직접 입력하여 사용할 수있음 -> 이거 한번 해볼것 (뭔가 유용해보임)

 

3-3. Number Rage -> 이건 할 얘기가 많으니 삼성전기때 배운거 정리해서 적기

3-4. Dual Control Principle (Sensitive Fields) -> 이것도 한번 해보기(전에 현태부장님이 해보라고 했던 것 같음)

• Vendor 나 Customer Master 에는 사업자 등록번호, 주민번호 혹은 은행 계좌정보 등 중요하다고 생각되는 정보들이 포함되어 있음
• 이렇게 중요하다고 생각되는 필드들은 Sensitive Fields 라고 표현함
• 이런 필드 들에 대해서는 실제 수정(변경)하는 담당자와 확인(Confirm)하는 담당자를 별도로 구분하여 이중으로 변경관리 수행 가능 -> 이렇게 이중 관리할 필드로 설정한 이후에 변경(수정 혹은 신규)권한을 가진 사용자가 Customer를 생성하거나 변경하려고 할 때, 위에 정의한 Senstive Field일 경우에는 변경 후 저장을 하여도 저장이 되지 않고 임시저장의 형태로만 저장이 됨
• 이렇게 임시저장으로 변경된 항목은 FD08, FD09 에서 해당 트랜잭션에 대한 권한을 가진 사용자가 Confirm 작업을 수행해야만 정상적으로 저장이 되게 됨 (동일한 사용자가 변경하고 Confirm 할 수 없도록 되어 있음)

3-5. Vendor & Customer 상계 반제

• 특정 업체 중에서는 Vendor도 되고 Customer도 되는 경우가 있음 - AP, AR 전표 모두 발생
• 채권과 채무가 동시에 발생할 경우에는 Payment Run 작업을 통하여 대금을 지불할때 채권의 금액 만큼은 제외하고 채무 금액에 대해서 지불하기도 함 -> 1) automatic payment run이라는 자동지급 프로그램을 실행할 때, 시스템이 특정 업체에 대해서는 Customer 이자 Vendor라는 정보를 알 수 있어야 하는 데, KNA1-LIFNR과 LFA1-KUNNR로 연결 2) XD01 혹은 XK01상 'Clrg with cust/vendor' (clearing between customer and vendor) 필드에 체크가 되어 야 함
• 작업 처리 순서
  • 서로 자동 반제가 될 Customer Master과 Vendor Master 코드를 미리 생성함
  • Vendor 혹은 Customer Master 수정 화면에서 반제할 Customer 혹은 Vendor 코드 값 입력
  • 수정화면에서 'clrg with cust' 필드 체크
• Customer/Vendor 조회 레포트
  • 관련 T-CODE : SE38
  • 프로그램 명 : RFDKVX00, RFKKVZ00
  • 비고 : 해당 프로그램에서 반제 내역 확인 가능

3-6. Terms of Payment and Cash Discount -> 이건 나중에 체크해 볼것

• Terms of payement(지급조건)은 발생한 채권이나 채무에 대하여 입금 혹은 지급받는 기간과 할인율을 결정하는 필드 값
• Business Partner 들간에 서로 협의된 Invoice의 지불 혹은 입금 조건을 나타냄
• Vendor나 Customer 생성 시에 Company Code별로 설정을 해놓으면 관려 모듈에서 판매 오더나 구매 오더 생성시 해당 값이 자동으로 넘어옴
• 지급조건 필드는 FB02에서 변경가능하나, 이미 반제된 경우에는 수정 불가
  ※FB01(전표생성), FB02(전표수정), FB03(전표삭제)

Public Cloud 상 Terms of Payment 설정

 

 

 

3-7. Reconciliation Account (sap gui에서는 일단 조회가 안되고, 퍼클에서는 더 해봐야할듯)

• Recon. Account는 Reconciliation Account(조정계정)로서 전표입력 시 Vendor Master나 Customer Master 값을 직접 입력하면, 자동으로 해당 Vendor나 Customer에 대한 실제 사용할 G/L 계정코드를 연결하여 입력해 주는 용도로 사용
• display in BP Role을 반드시 FI Customer로 선택한 후에 해당되는 Company Code 내에서 Account Management 탭을 보면 Recon 계정코드가 설정되어 있는 것을 확인 가능
• Customer Master 코드값을 입력하면 자동으로 이 Customer Master에 저장된 Recon. Account인 매출채권 계정이 입력되도록 함 ( 매출 채권 - 매출, 매출이 발생하면 매출채권을 차변으로 발행되는 데, 이때 Customer master 코드 값을 입력하면 자동으로 이 Customer master에 저장된 Recon.account인 매출채권 계정이 입력되도록함)
• 이러한 Recon 계정은 customer 이나 vendor의 각각 company code data뷰로 생성 관리 가능 -> 하나의 customer 혹은 vendor라고 하더라도 Company code별로 Recon 계정은 서로 다르게 전표 처리 가능

고객한테 물건을 팔면 매출이 발생 하고 AR 발행 시 해당 고객을 선택하면 관련 계정이 자동으로 연동

 

3-8. Sort key -> 이것도 다시 ( 퍼클에서 안보임..)

• 전표 생성 시에 전표의 assignment 필드에 어떤 값이 자동으로 들어가게 할 것인지를 결정하고, 전표의 라인아이템 조회 시에 기본적으로 standatd line layout 설정시에 assignment 필드를 기준으로 sort하여 조회가 되게 

3-9. Head Office 외의 기타 필드 들 ( -> 퍼클에서는 head office 안보임)

• 본사코드로 레포팅의 용도로 사용됨. 예를들어 Customer Master에 head office 필드값을 'a'라고 입력을 해 놓으면 전표 개별항목 조회 레포트 등에서 'a'라고 집계되어 조회됨 (line item이나 sub-ledger에 모두 'a'라는 고객으로 집계됨) -> 보통 동일한 업체가 여러개의 사업자 등록번호로 여러개의 customer master로 분리되어 있을때 이 여러개의 회사의 head office 값을 동일한 값으로 저장해 놓으면 레포트에서 하나의 본사의 customer로 조회하여 레포팅 및 관리하는 용도로 사용
• alternative payer / alternative payee : general data 혹은 company code data에도 등록 가능 (둘다 등록한 경우에는 해당 company code에 등록된 값이 우선적으로 적용됨)

Public Cloud에서 관련 데이터 조회 결과 -> BP 역할에 따라 뷰가 달라짐 (너무나 당연하지만)