SAP GUI & Customer Master Data

Working in SAP GUI

 Each function in the SAP system has a transaction code associated with it.
 A transaction code consists of letters, numbers, or both. You enter transaction codes in the command
field.

Command field
for T Codes

 /n - To end the current transaction (Caution: Unsaved changes are lost without warning)
 /i - To delete the current session
 /o - To generate a session list
 /nend - To log off from the system
 /nex - To log off from the system without a confirmation prompt (Caution: Changes that were not saved
are lost without warning)
SPRO (SAP Project Reference Object)

SAP Reference IMG – SAP Reference Implementation Guide

Key in SPRO T code in

command field and
Press Enter.

SAP Reference IMG

 DATA in SAP

SAP DATA

System Application
Relevant Relevant
Data Data

Application Customizing
Data Data

Transaction
Master Data
Data
 System relevant - Data that is only maintained by SAP. Any changes to data in such a table
constitute a modification, because the overall system behavior is controlled by entries in
these table

 Application relevant - Data that is specific to a particular customer

installation/implementation.

 Application data - Data which is created during the normal course of business.

 Customizing data - Data that defines the behavior of your SAP environment for individual
modules

 Transaction data - Data which is created in large numbers almost on a daily basis during a
normal business operation.
Master data

 Master data is the core data that is used as a base for any transaction.
 If you are producing, transferring stock, selling, purchasing, doing physical inventory,
whatever your activity may be, it requires certain master data to be maintained.

 Examples
 Material master data
 Customer master data
 Vendor master data
 Pricing/conditions master data
 Warehouse management master data (storage bin master data)
SD Master data – Core elements

MA
ME

TE
TO

RI
S
Master

CU

AL
data
PRICING
 Role of consultants

 As a consultant we have to give training to core user, so we should have

knowledge of customer master data.
 We decide how the customer master data should look like for end users.
 Strong knowledge of customer master data will help while configuring sales
business processes.
 Customer Master Data

General Data
(SD & FI)

Sales & Distribution Data Company Code

(SD) Data
(FI)
 Views in CMD

 General data – SD & FI – SD (Payment transactions & Control data)

 Company code data – FI
 Sales area data – SD
 As a consultant we have to give training to core user, so we should have
knowledge of customer master data.
 First SD User will create customer with sales data and send it to FI user. Then FI
user will enter FI related data.
T Code Customer central Company code data Sales area data

Create XD01 FD01 VD01

Change XD02 FD02 VD02

Display XD03 FD03 VD03

 General data

 Address
 Marketing
 Control data
 Contact person
 Unloading point
 Payment transactions
 Export data
 Address Tab - Address TAB consists of the personal info of the customer. i.e. his name,
address and communication details.
 Marketing Tab
Nielsen ID - Nielsen id will be used to track the customers who are located in market
survey regions
Ex - Whenever we are launching new products we do market survey in specific regions.
If the customers are located in market survey regions then we have to maintain this field.
Customer classification - Classifying the customer based on their sales turnover.
Help in discounts
Helps to fix credit limits.
Industry - classifying the customer based on the industry they belong to.
Reporting
Help to offer discounts
Industry code - Sub classification of industry.
 Regional market - Dividing the customer in local market into A class or B class or C
Class based on the revenue it generates. The main purpose of this field is reporting.
 Key figures - Key figure will be used to compare the Last year sales with present year
sales. In annual sales field we maintain last year sales.
 Legal status - This field controls whether customer is Pvt Ltd, or Public Ltd.
Unloading point tab
 It is the physical location where we unload the goods at customer place.
 Unloading point will be used to plan the delivery for customers.
 Good receiving hours – Specifies the time of customer’s goods receiving hours.
 Contact person - Employee of customer who is responsible for various activities.
 Reconciliation account
 Reconciliation Accounts are G/L accounts that receive postings from a subsidiary
ledgers.
 Transactions data are not posted directly to recon accounts. Example of recon
accounts are Accounts Receivable, Accounts Payable and Fixed Assets G/L. 
 For accounts receivable G/L the subsidiary ledger is the customer account. 
 All transactions with the customers are posted directly to the customer account
and the recon account is automatically updated. 
 All normal transactions to the customer e.g. sale of goods are posted to the
recon account defined in the customer master data.
 T Code – FS00
 Net balance of customers (sub-ledger) should always reconcile with net balance
in GL recon account in finance (main ledger).
 Terms of payment
 Terms of payment is used in SAP to determine the due date and discount
calculation.
 Terms of payment is a mutual agreement between buyer and seller
 T Code – OBB8
 Day limit - This field is used to specify the particular term of payment is valid
from which particular date.
 Example 1 – Payment Term T001
 Day Limit   – 20
 Discount – 5 %
 As per above details system will consider this payment terms for the invoices
posted in system ON or BEFORE 20th date in every month and applies 5% cash
discount. The discount won’t be applicable for invoices posted after 20th in month.
 Example 2 – Payment Term T001
 Day Limit   – 31
 Discount – 2 %
 As per above details system will consider the invoices for 21st to 31st and applies
the 2% discount
 Baseline date calculation
 Fixed day - This field signifies the “calendar fix day” for base line date calculation.
 Additional months - Value maintained here is used to add the calendar month
for base line date calculation.

 In above case the base line date would be 15th of the next month.
 Block key - The value maintained in this field signifies the block key for payment.
If block key is maintained here the system proposes the block key along with
terms of payment.
 Payment methods - If user wants to maintain the payment method here other
than customer/vendor master it can be maintained here as an identifier.
 No Default: Selecting “No Default” here means system prompts
user to enter baseline date as own.
 Posting date: Selecting this means posting date mentioned will be
same as “Baseline Date”.
 Document date: Selecting this means document date mentioned
will be same as “Baseline Date”
 Entry date: Selecting this means “Systems Date” will be same as
“Baseline Date”
Sales area data
 Sales district - It is a sub-classification of sales office, for the purpose of
generating sales report.
 Customer group - Grouping of customers who will share the same attributes in
volume they buy.
 P1 – Bulk dealer, P2 – Medium dealer & P3 – Low dealer
 The purpose of customer group are reporting & pricing.
 ABC Classification – Classified based on Turnover, Payment history etc
 The purpose can be for reporting and response time for queries.
 Currency - If the customer is located outside the country then we maintain
customer currency.
 This conversion will be happened based on exchange rate.
 Switch off rounding - If we check this, system will not perform rounding while
creating sales order. Quantity Decimals
 Order probability - After placing the order what is the chance that the customer
will not cancel the order.
 Item proposal - If customer is regularly placing order for similar items then instead of entering
the items manually into sales document every time, we prepare a list and call the list while
creating a sales order.
 T Code – VA51 & Std Item proposal type – PV.
Exchange rate type
 When bank sells dollar, exchange rate might be $1= 65 INR 
 But when bank buys dollar, exchange rate might be $1= 70 INR
Hence different exchange rate is used for different purposes.
Above example can be represented as,
 Transaction: Bank sells dollar      Exchange rate type used: B
 Transaction: Bank buys dollar      Exchange rate type used: G
Exchange rate is maintained per exchange rate type as shown below
 Exchange rate type B, 1 $= 65 INR
 Exchange rate type G, 1$= 70 INR
 Hence different exchange rate types can be used for different business transactions.
 Whenever a currency conversion has to happen, first thing decided by system is what exchange-
rate-type is going to be used
 Standard exchange rate type is M.
 PP Customer procedure - This field will be used for cross selling concept or
product proposal concept.
 Cross selling – A & Product proposal – B
 Product proposal is automatic determination of item proposal in sales document.
 Price group - Grouping of customers who will share the same pricing attributes.
The purpose of this field is to maintain discounts.
 Price list - Grouping of customers who will share the same base price.
 Ex - Distribute pricelist & institution pricelist.
 Customer statistics group - This field controls whether to update customer sales
data into LIS
 Delivery priority - This field will be used for classifying the customers into high
delivery priority, medium delivery priority, and low delivery priority.
 The purpose of this field is it will help to process Back orders and rescheduling.
 Backorder processing - Whenever high delivery priority customer place order, if
stock is not available then we go back to the open orders of low priority
customer and cancel the confirmation of low delivery priority and assign to high
delivery priority customer.
 Order combination - This field is prerequisite to combine multiple orders into
single delivery.
 Shipping condition (MMD) + Plant + Loading group (MMD) -> Shipping points
 Delivering plant – CMIR -> CMD -> MMD
 Relevant for POD - If we check this, system will not allow to create invoice for the
customer until we receive acknowledgement from the customer.
 T Code to receive POD - VLPOD
 POD Time frame
 Maximum partial deliveries allowed per item.
 If partial delivery is not allowed then maintain C.
 If we want to allow partial delivery then maintain either Blank or D.
 Unlimited tolerance - if we check this then system will allow increasing or
decreasing the quantities in delivery document without any limitation.
 Under delivery tolerance - If we maintain some percentage here then system will
allow to decrease the quantity in delivery document up to that percentage, if the
percentage exceed then system will give warning message.
 Over delivery tolerance - If we maintain some percentage here then system will
allow increasing the quantity in delivery document up to that percentage, if the
percentage exceed system will give warning message or error massage.
Invoice dates
 Invoice dates – If the clients requirement is, invoice to be generated only on specific date
of every month
 T Code – OVR4
 Remove work days & Specify special rules
 Invoicing list dates - Consolidating all invoices raised during a particular month into one
and sending it to payer, it’s called as invoice list.
 T Code to create invoice list – VF21
 Incoterms – International commercial terms
 It is an international commercial terms which is an agreement between Consigner and
Consignee.
 Incoterms specifies who is responsible for freight charges, insurance charges, loading
charges etc.
 FOB – Seller takes responsibility until boarding on ship including transportation and
loading cost. From that point buyer takes responsibility including unloading and transport
cost to destination
 Account assignment group - This field is one of the parameter to determine the
G/L A/C while posting invoice values into accounting.
 Tax classification - This field controls whether customer is liable for TAX or not.
 Views in CMD

 General data – KNA1

 Company code data – KNB1
 Sales area data – KNVV
 Partner determination procedure

 Partner type – Stake holders who make positive and negative impact in the
business
 Partner function – The role the partners play in business process
 SP – Sold-To Party
 SH – Ship-To Party
 BP – Bill-To Party
 PY - Payer
 CP – Contact person
 KB – Credit rep
 ER – Employee resp
 Partner type

 KU - Customer
 AP - Contact person
 LI – Vendor
 PE – Personnel number
 US – Author
If we check mandatory then if any of the partner function is missing then system will not allow
saving the customer master.
If we check not modifiable then system will not allow changing the partner function in customer.
 Account group

Main purposes of account group are

 Field selection – Req, Supress, Optional and display
 Number ranges T Code – XDN1
 One-time customer
 Partner determination procedure
 O/p Determination procedure
 Text determination procedure
 Customer pricing procedure
 T Code – OVT0
 The standard account group for sold to party is “0001”, Ship to party is “0002”,
Payer is “0003” and Bill to Party is “0004”.
CMIR