Invoice Verification 4

 

- 인보이스 라인이 Too many 인 경우 

 

 

- 추가의 Transaction Code이용하여 최소한의 인보이스 정보는 입력하고 시스템에서 검증 작업은 백그라운드에서 처리 후 일치되면 Posting 됨

 

- Settlement Program : RMBABGOO에 대한 Job을 걸어 

 

- Incorrect 인 경우 담당자가 Item List 수동으로 Change 후 직접 Post

  수동으로 수량 Change > 자동 검증 프로세스 > 다음 백그라운드 Job 까지 기다려서 Post  

 

 

 

- 우리가 입고된 내역을 기준으로 invoice를 자동 발행, 해당 결과를 업체에 송부, 업체에서 이를 보고 인보이스를 별도 발행 

  조건 : Material  단가의 Fluctuation 이 없는 경우, 납기가 frequent한 경우 

  Vendor 마스터에 ERS가 Check 되어있어야 해 (PO 생성시에 해지 Check 가능)

 

 

- EDI(인터페이스 되어 있어야 해)를 통해 Quotation 을 주거나 PO를 내거나 업체에서 invoice를 넘기고 이를 기반으로 포스팅도 가능

 

- GR/IR을 어떻게 관리할 건지 

 

- GR/IR은 입고 수량과 인보이스 처리 수량 차이가 Clearing Account에 담겨 

 

 - PO 100, 입고 50 인보이스 80 처리 

   앞으로 GR이 30 개 더 들어올 거다 GR/IR account를 Open해둬

 

- PO 100, 입고 100 인보이스 97

  앞으로 추가 인보이스 발행을 통해 3개 더 들어올 것 

 

만약 더 이상의 delivery가 없다 or 인보이스 발행이 없다하면 GR/IR을 Open된 상태가 아닌 GR/IR을 Maintain해야 해  

 

 

- GR/IR Maintain:

 GR/IR Open 된 수량(30)을 처리하고 

 그 차액을 재고에 반영

 

- Logistics와 FI 쪽 Doc 구분

 

Logistics

   Manaul : RD

   Automatic : RS

 

 FI

  Transaction Code별로 Doc Type 할당, Doc Type에 Num Range가 할당 

 

- MIRO 화면에 가면 R1이라는 Tax 세팅

  환차손/익은 별도 계정 or Price difference처럼 Stock에 반영할 지 결정

 

 

- Unplanned delivery cost를 stock에 반영 or 별도 GL 계정에 처리

  PO text를 인보이스 처리 담당자에게 보이게 할 건지 세팅 가능

 

 

- GL계정이나 Material에 바로 포스팅 할 경우

   Aggregation은 인보이스 아이템을 써머리 레벨로 볼 수 있게 하는 기능

 

 

- 인보이스는 한 화면에 보이기 힘들기 때문에 Variant를 몇 개 만들어서 사용자가 작업할 수 있도록

 

- 어떤 필드를 가지고 중복인지를 체크할 건지에 대한 세팅

  Vendor 마스터에도 이 부분 체크 되어 있어야 해 

 

- Payment에 Manual block

  각각의 키 값에 대해 tolerance

  아이템 별 Amount Block 

  Stochastic 통계적 Block 

 

- msg는 프린트할 수 있는 메세지

 

인보이스를 잘못끊어왔을 때 invoice reduction에 대한 메세지를 줘야해 

입고 기준의 인보이스를 끊고 이를 vendor에게 보낼 때 메세지 줘야해 

위탁 재고 역시 우리가 사용한 만큼 레포트를 뽑아서 vendor에게 줘야하므로 메세지 줘야해 

 

 인보이스 처리시 Price difference 발생할 경우 이메일 보낼 수 있는 기능

 

 

 

-  Authorizations and Profiles

   Tolerance Groups 이용한 권한 관리 지원