■ Customer Vendor Accounts
ㅁ Customer Account Group
ㅁ Field Status of Fields in Master Record
ㅁ Control of the Field Status(2)
- 우선순위 : Suppress > Display > Requried > Option
- account group, transaction
ㅁ Control of the Field Status (3)
- customer vender master code field 결정 요소 3가지
1. account group
2. transaction
3. company code
ㅁ AP/AR Account Groups의 Controls
1. The number ranges of the accounts
2. The status of the fields in the master record
3. If the account is a one time customer or vendor.
A. Regular Versus One-time Accounts
ㅁ Dual Control Principle
- 이중 체크 룰
ㅁ Clearing Customer/Vendor
- 채권 채무 상계거래선, 매출매입 동시 거래선
* Account Control (Client Level > Customer, Vendor master record)
* Clearing with Vendor, Customer(Payment transaction)
ㅁ Alternative Payer/Payee
- 대리납부인/대리수취인(Payer/Payee)
* Client Level - Paym. Trans > Alt Payer Cust. Y
or
* Company code level > Alt. Payee. Vender
ㅁ Head Office/Branch
ㅁ Customer/Vendor Account : Unit Summary
1. the structure of customer and vendor accounts
2. the similarities and differences between customer and vendor accounts
3. control and maintain customer and vendor accounts
4. name and explain different relationships between customer/vendor accounts
■ Special G/L Transaction
ㅁ Special G/L Transactions Concepts/Customizing(Contents)
* What is a Special G/L Transactions: Overview
- Freely definable offsetting entries
- Noted items
- Statistical postings
* Configuration of Special G/L Transactions
ㅁ Special G/L Transaction - Alternate Reconciliation Acct
- [P.K + Acct + Amount] + Special G/L Indicator
- 일반적인 G/L 거래이외에 일어나는 G/L 거래 (Ex. 선수금, 선급금)
ㅁ Different Types of Business Transactions
* With down payments
- 선수금, 선급금 관련
* With bilss of exchange
- 어음 관련
* Other
- 미수금, 미지급금, 예수금
ㅁ Special G/L Transaction Types
- There are three types of special G/L transactions, and their relationship to the general ledger is the key distinction
1. Automatic, statistical offsetting entry
2. Noted items
3. Free offsetting entry
ㅁ Sp. G/L Type : sta. Offsetting Entry(Automatic)
- Two line items with posting to a predefined offsetting account
- Ex. 예수보증금 : 보증금을 미리 받는것 (cust)
- Ex. 지급보증금 : 보증금을 미리 주는 것(vend)
- BS에 표시가 되지 말아야 되는 특징
- G/L로는 업데이트 되지만 B/S에 표시가 되지 않는 statistical한 목적의 offsetting 계정
ㅁ Special G/L Types : Noted Items
- A line item is created without updating the account balances in the general ledger
- 한 줄에 라인아이템에 생성됨
- Ex) 선급 요청(vend) : 벤더쪽에서 구매부에 물품에 대한 선급금을 요청 > 구매부가 재무부에 요청 > 재무부 선급금 지급 시점
- Ex) 선수 요청 (cust) : 영업부에서 cust에게 선수금을 요청하는 것 > 선수금 수령
- 선급 요청시 생겼다가 선급급 지금관련된 Document가 생성되는 시점에 클리어 되어 없어지기 때문에 G/L 계정 balance로 전혀 업데이트 되지 않는다.
ㅁ Special G/L Types : Freely Definable Offsetting Entries
- Freely definable offsets are two line entries where the offsetting line item account is entered at the time of the entry.
- Ex) 선수금 거래 : cust와 물품거래 계약을 맺으면서 cust로 부터 미리 돈을 받는 것
선수금 수령시 > A/R Invoice 생성 > 선수금 상계 > 대금 수금
- Ex) 선급금 거래 : vend와 물품거래 계약을 맺으면서 AP invoice 시작 이전에 선급금을 벤더에게 돈을 미리 지불
선급금 지급 시 > A/P invoice 생성 > 선급금 상계 > 대급 지금
ㅁ Configuration of Special G/L Transaction
- Special G/L transactions are already maintained in the standard system
Customer 거래유형 Special G/L Indicator Vendor 거래유형
선수금 A 선급금
선수요청 F 선급요청
예수보증금 G 지급보증금
받을어음 W 지급어음
1. Pre-configured special G/L indicators
- Example :
A - Down payment
B - Guarantees
C - Bill of excharge rec.
D - Reserve for bad debt
2. Special G/L account
3. Noted item(?)
4. Posting keys
5. Down payment, Bill of Exchage. or Other
ㅁ Special G/L Transactions : Definition of Properties and Accounts
- IMG 세팅내용
ㅁ Automatic Statistical Offsetting-Posting
ㅁ Special G/L : Account Control
ㅁ Special G/L Transactions : Posting Key
- 변경할 수 없게 미리 세팅이 되어 있다.
ㅁ Down Payment(선수금) Processing : Example
ㅁ Bill of Exchange(어음) Example (Without Charges)
- W : 받을 어음
- X : 할인 어음
- Y : 배서 어음
- Z : 부도 어음음
ㅁ Special G/L Transactions : Summary
- Explain what special G/L transactions are
- Distinguish between various types of special G/L transactions
- Describe functions for special G/L transactions
- Configure special G/L transactions
■ Open Item Clearing
ㅁ Clearing (Contents-목차)
- Open Item Clearing (2가지 방식)
- Incoming and Outgoing Payments (수금, 지급)
- Payment Differences (수금, 지급 차이)
- Exchange Rate Differences (환차 손/익)
ㅁ Clearing : Objectives
- Clear an account (2가지)
- Post various payments and payment differences (2가지 방식)
- Explain exchange rate differences (환차 손/익 거래)
- Reset cleared items
ㅁ Opent Item Clearing : Objectives
- Describe the clearing process
* Open Item Clearing 방식
- Clear an account
- Post with clearing
ㅁ Open Item Clearing
- Open Item Clearing : 언제가는 정산되어야 할 미결항목
* 2가지 방식
1) Clearing an account : open item으로 관리되는 여러건의 line item을 동일한 계정과목 레벨에서 클리어 처리하는 방식,
즉 잔액을 제로로 갖는 여러개의 Open line item들을 동일한 계정과목 레벨에서 클리어 처리하는 방식
2) Post with clearing : 포스팅과 함께 바로 클리어 처리되는 방식
ㅁ Posting with Clearing
- Step
1. Entered manually (주로 bank account, 차변에 A/R을 처리하기 위해)
2. Selected (customer account)
3. Created automatically (대변에 클리어할 open item 자동 생성)
4. Cleared
ㅁ Account Clearing
- 잔액을 제로로 갖는 Open item들을 동일한 계정과목 레벨에서 찾아서 클리어 처리하는 방식
- Account Clearing을 대표하는 open item Clearing 방식
: A/R Invoice에 대한 credit memo가 발생했을 경우에 A/R Open Item과 Credit Memo에 따른 바대변에 기표된 A/R Open Item을 서로 Clearing 처리하는 방식
- Document line item 에 차/대변이 나타나지 않는다.
ㅁ Automatic Clearing Program
@ 동일한 계정, 동일한 통화, 동일한 Special Indicator, 동일한 Assignment Field에 오는 value값을 갖는 oepn item을 그룹핑 해서 차변/대변 sum 값이 제로이면 클리어, 그렇지 않으면 클리어 하지 않음 등등 (보통 ZUONR이 많이 활용됨)
* Functions of clearing
- Groups Items per account together
- If balance is zero, Items are marked for clearing
* Prerequisites for clearing
- Accounts must be managed on an open Item basis
- Accounts to be cleared must be defined
* Items not cleared
- noted Items
- statistical postings, down payments, bills of exchange
- Items with withholding tax entries (원천세를 가지고 있는 Line Items)
ㅁ Sort Field also known as Allocation Field (Assignment와 같은 필드)
ㅁ Incoming and Outgoing Payments : Objectives
- Post various incoming and outgoing payments
- Reset cleared documents
ㅁ The Manual Payment Process
1.Document hearder
1) Payment header
2) Bank data
3) Select open items
2. Process open items
1) Activeate items
2) Activate cash discount
3. Post
1) Display overview
2) Post
ㅁ Document Header : Payment Header
ㅁ Document Header : Bank Data
ㅁ Document Header : Open Item Selection
ㅁ Process Open Items
ㅁ Posting Payments
1. Overview details
2. Simulate to review automatically generated items
Correct any mistakes
3. Post
ㅁ Automatic Postings When Clearing Open Items
- Cash discounts paid or received
- Cash discount clearing (net method)
- Tax adjustments
- Exchange rate differences
- Bank charges
- Clearing entries for cross-company code payments
- Over-or underpayments within tolerances
ㅁ Resetting Cleared Items
- 잘못 클리어된 아이템을 되돌리는 방법
1. Only Resetting
- 클리어 처리된, 즉 수금 또는 지급 처리된 다큐먼트는 그대로 둔 상태에서 상태만 클리어 상태에서 오픈 상태로 되돌리는 방식
2. Reset & Reverse
- Cleared Document 자체를 역분개 시켜 A/R 을 다시 살리는 방식
ㅁ Payment Differences : Objectives
* payment difference : 수금, 지급시 발생하는 차이
- Post payment differences
- Describe tolereance groups and their role for posting payment differences
- Create partial and residual payments
- Create reason codes
ㅁ Torelance Groups
* Tolerances : rules that define acceptable differences during posting
- 수금, 지급시 발생하는 차이를 정의
* 종류
- Tolerance Group for Employees
1, Upper limits for posting procedures
2. Permitted Payment Differences
- Tolerance Groups or Customers/Vendors
1. Permitted Payment Differences
ㅁ Configuration of Tolerance Groups
1. Define the group per company code
* Employees -> 직무, 직급별 그룹핑
- Staff Account 1
- Staff Account 2
- Accounting Supervisor
* Customer/Vendors -> 그룹핑
- Good customers/vendors
- Not so good customers/vendors
- Cash only customers/vendors
2. Define tolerances
* permitted payments differences
3. Assign tolerance groups
* User master records
* Customer/Vendor master records
ㅁ Permitted Payment Differences
ㅁ Payment Differences
ㅁ Partial and Residual Payments : 부분 수금 처리할 때 사용
* Partial Payment : 두 개의 Line item 이 여전히 오픈
- both items remain on the account
* Residual Item :
- payment term
> from cleared item
> fixed payment term
- new document referencing originals
* Charge off difference
ㅁ Reason Codes
ㅁ Exchange Rate Differences : 환율차이
ㅁ Realized Exchange Rate Differences
- 환차 손익
ㅁ Account Determination
- 환차손 관련 계정 결정 로직
ㅁ Clearing Summary
- Two basic transactions are used for clearing
> Clearing an account
> Posting with Clearing
- For every clearing transaction a clearing document is created
- Payment differences may be processed automatically or manually
- Posting payment difference are controlled by entries in tolerance groups.
■ Receivables
1. Receivables :외화/채권/채무에 대한 평가
2. TR
- Check Deposit : 수표
- MBS(Manual Bank Statement) : 은행 거래원장을 기초로 하여 메뉴얼로 회사의 해당 거래 계좌에 입금과 지급 내역을 컨트롤 하기위한 것
- EBS(Electronic Bank Statement) : 펌뱅킹
MBS는 펌뱅킹에 로직을 가지고 있음
ㅁ Receivables : Unit Objectives
- Run the foreign currency revaluation
외화평가 작업 수행
- Post and explain the handling of doubtful receivalbles.
사고채권 처리, 사후 대손 처리
- Locate and manage the relevant customizing in the IMG
ㅁ Foreign Currency Valuation and the Sorted List
1. SAPF100 -> 외화 평가 프로그램
* 기능들
- Valuning open items in foreign currency at key date
- Different receivalble and payable, G/L accounts
-> Parallel currencies can be valued separately.
Parallel currencies = editional local currency
즉, 회사가 회사를 대표하는 커런시로 (company code currency)로컬 커런시를 정의할 수 있다.
우리나라의 경우 korea won, 예를 들어 한국에서 사업을 영위하는 외투법인이 미국에 있는 본사에 결산 보고 할때는 USD로 해야함.
로컬커런시 이외에 멀티 컴퍼니를 위한 로컬 커런시를 별도를 하나를 둘수 있는데 이것이 Parallel currencies 이다.
- Determining the valuation difference : 평가 차이 결정
-> Only as a list, no posting entries : 시뮬레이션 기능
-> Valuation at balance sheet key date + reversal : without update 방식
-> Balance sheet key date valuation with update : 역분개를 하지 않는 with update 방식
(note : only for fiscal year-end, no reversal document)
- Direct posting, batch input only when error or "without update"
* 외화평가 방법 2가지
1). without update
- 평가일 즉 기말현재 외화평가를 하고나서 그 평가를 그 다음날 역분개 시키는 방식
* 월중에는 without update 방식을 사용
2). with update
- 평가를 하고 그 다음날 역분개를 하지 않는 방식
@ 주의사항 : fisical year end(연말)에만 사용해라, 이 방식을 사용하면 역분개 내역이 그 다음년도에 반영되기 때문이다.
2. SAPF101
- Listing Receivables and Payables
* 기능
1. 채권/채무 장단기 대체 기능
2. 적자 채권/채무 자동 조정
3. 기중에 변경된 reconcilation account를 자동으로 변경 후에 recon계정으로 조정해주는 기능
4. 관계 회사간에 채권/채무를 상계처리
ㅁ Currencies (통화)
* Check currency codes
* Set up decimal places for currencies
* Check exchange rate types
* Maintain currency spreads
* Define rounding rules for currencies
* Define translation factors for currency translation
* Enter exchange rates
ㅁ Exchange Rate Types
* Type : Use
- B : Bank selling rate
- G : Bank buying rate
- M : Average rate
ㅁ Spreads
ㅁ Customizing : Valuation Methods
ㅁ Valuation (without Update)
ㅁ Valuation (with update)
ㅁ Customizing :Account Determination for Open Item Exchange Rate Differences
ㅁ Receivables : Unit Summary
- 외화 평가 관련 수행
* Run the foreign currency revaluation.
* Locate and manage the relevant customizing in the IMG
ㅁ Check Deposit : Unit Objectives
At the conclusion of this unit, you will be able to :
* Explain the technical procedure for depositing checks
* Enter checks using the check deposit list and print the list
* Create and run batch input sessions
* Postprocess postings (if batch sessions are defective)
# SAP Cash Management의 범주
1. 유동성 예측(Liquidity Forecast)
1) 특징 : Customer/Vender master에 있는 Cash Management Grp 및 Terms of Payment의 정보를 기반으로 CUST와 VEND의 수입 및 지출 관련 유동성을 예측하는 기법
- CUST : Sales Order > 배달지시서 > Picking > Packing > Good issue > Billing (S/O 생성시 인식된 마스터의 지급조건 및 C.M Grp의 정보가 입금시점까지 관리 되므로 각 단계별 입금 예정일 관리가 가능하다)
- Vend : P/R > P/O > 입고(검수) > 매입 세금계산서 수령 > 지급
(P/O 생성시 인식된 마스터의 지급조건 및 C.M Grp의 정보가 지급시점 까지 관리 되므로 각 단계별 지급 예정일 관리가 가능하다)
2) 예측기간 : 판매 > 입금/구매 > 지급 까지의 각 단계별로 유동성을 예측하므로 중기의 유동성예측(1 - 24 Weeks)에 적합함.
3) 한계 : CUST/VEND 별로 Cash Management Grp을 한 개만 설정해야 한다는 한계가 이씀.
예) A CUST : 내수거래선 이면서 동시에 수출 거래선인 경우 : Grp의 복수 관리가 곤란. (따라서 내수/수출 동시 거래선의 내수/수출과 관련된 Liquidity Forecasting을 하려면 거래선을 각각 등록해야 한다는 한계가 있는 것임.)
-> 실제로는 Fund Mgn't의 자금 수지표를 많이 사용한다.
2. 현금관리 Position (Cash Position)
1) 특징 : Bank Account 또는 Bank Clearing Acount Master에 있는 Planning Level 정보를 가지고 각 은행별 입금/지출 유형별로 유동성 예측을 하는 기법
- 전재조건 : 은행별 Bank 계정이 입금 지급 유형별로 다양하게 Setting되어 있어야 한다. (예: 113100 -> F0[은행 입금]/113101->B1(수표출금)/113102->B2(수표이체) 등)
2) 예측기간 : 각 은행관련 계정을 Positing 하면서 입력한 Value Date를 기초로 은행별 입금/지급 내역을 관리하므로 초 단기 유동성 예측 (1-2 Days)에 적합함.
3) 정보제공 유형 : 은행별 -> 입급/지급 유형(Planning Level)별 -> 은행계좌별 -> 일자별 입금 지출 내역
3. Check Deposit/Manual Bank Statements
1) Check Deposit : 거래처로 들로부터 수표를 대량으로 수금할 경우 거래처 건별로 수금처리 하는 것은 현실적으로 곤란함
(해결책) : 입금 Transaction 유형별로 수금 자동분개 key를 IMG에서 Setting
-> 거래 유형과 수금한 수표 내역만 입력하면 수금관련 분개 자동으로 일어남.(수금 처리만 가능)
-> Manual Bank Statement를 사용하는 회사는 거의 이 기능을 사용하지 않음. 기능상 M.B Statement가 더 광범위 하기 때문.
2) Manual Bank Statement : 주로 은행과 연결된 Firm Banking을 사용하는 회사에 이 개념이 적용됨. 즉, 은행에서 입금 및 지급과 관련된 Transaction 은행거래내역을 회사로 전송하면 회사에서 은행의 Raw Data를 SAP 기준 Data로 변환하여 입금/지급. Transaction 유형별로 미리 부여된 자동 분개 Setting에 따라 자동으로 입금/지급에 대한 분개를 일으킴. (입금 및 지급이 모두 처리 가능)
ㅁ Check Deposit-Concept
1) 기능 :
거래처로부터 수금한 수표 여러 장을 Transaction Code별로 자동으로 입금 처리하기 위한 수금처리 방식
2) Account Assignment 방식 :
임시계정 : 입금은 됐지만 미결로 남아 있는 경우에 사용
3) Batch Input Session 생성 Logic
1. Check Deposit과 관련된 Session
> Bank Posting Session : Bank 및 Bank Clearing계정 생성과 관련된 Session, 예) Bank 1,000 / Bank-Clearing 1,000
> Sub Ledger Session : 외상매출 계정과 관련된 Session, 예) Bank-Clearing 1,000 / A/R 1,000
2. Bank Clearing 계정을 쓰지 않는 경우에는 A/R이 상계 되면서 직접 Bank 계정으로 Posting되므로 Posting Area 1번만 IMG에 정의 하면 된다. 예) Bank 1,000 / A/R 1,000 -> Transaction 수행 시 Session Name은 Bank Posting Seesion Name으로 정의하고 돌리면 됨.
