SAP SD Sample Certification Questions in Sales Order

Processing
To take the SAP SD certification, contact your local or regional SAP Education
training center at this url :
http://www.sap.com/services/education/index.epx
Caution: more than one answer may be correct.
Please mark ALL correct answers.
Question:
Which statements concerning goods issue are true?
A
B
C
D
E

Goods issue reduces requirements in materials planning

Goods issue posts value changes to the stock account in inventory accounting
Goods issue posts value changes to the stock account in asset accounting
Goods issue posts value changes to the tax account
Goods issue reduces warehouse stocks

Question:
Which of the following statements about billing are correct?
A. Invoice dates for creating invoices at certain times are maintained in the calendar.
B. You cannot carry out pricing again during billing.
C. A transaction-specific requirement, such as "deliveries must be combined in a
collective invoice" can be set to control
billing.
D. If there are several payers for one delivery, only one billing document is created for
each player.
Question:
How is the schedule line determined?
A.
B.
C.
D.

Item category and document type

Item category group and strategy group on the material master record
Item category and MRP type on the material master record
MRP Type and shipping point

Question:
When processing a billing due list, you have the following options:
A. The invoicing run can be started as a simulation run.
B. For performance reasons, the invoicing run via billing due list processing can only be
carried out in batch.

C. The invoice run can be carried out for delivery-related and order-related billing
documents simultaneously.
D. Order-related billing documents and delivery-related billing documents must always
be created separately.
Question:
How does the SAP system enable you to check the reason for documents not being
combined in a billing document?
A. Using the Spilt analysis function in the environment menu of the billing document.
B. Control of the document flow.
C. Control of the billing log.
Question:
How is the schedule line determined?
A.
B.
C.
D.

Item category and document type.

Item category group and strategy group on the material master record.
Item category and MRP type on the material master record.
MRP Type and shipping point.

Answers for SAP SD Certification Sample Questions

Question: Cutover strategy
Q: Please explain cut over strategy procedure? Will the system golive 100% at the
same time and cut the legacy system or will it be like 20% first day and 50% next
day like that ?
A: Cutover strategy depends upon how the organizations design their data load
strategies. Normally, you decide the sequence of Data loads for Configuration settings,
Master data, Transaction data which follows whom and then you make a copy of the
system as a Production system a day before and after checking the successful data loads,
you go-live 100% or partial again depending upon organizational setup and policies.

Topic Areas
General Questions (+)

Using the system

IMG (Implementation Guide)
Project Implementation
Enjoy SAP R/3 Overview
mySAP.com Overview
BW Overview

Organizational Structures (+)

Organizational Structures
Organizational elements
Master Data in Sales and Distribution (+)

Customers and Partners

Partner Determination
Material Master, Material Type
Condition Records
Effects of Master Data on the Customer Order Management Cycle

Sales (++)
Times in R/3 to calculate Delivery Dates
Processing Inquiries and Quotations
Sales Order Processing
Outline Agreements
Incompletion
Controlling Sales Documents
Copy Control
Special Business Transactions (Cash Sales, Rush deliveries, Consignment, Delivery
free of Charge)
Pricing (++)

Condition Technique in Pricing

Conditions
Pricing Configuration
Condition Records
Special Functions in Pricing
Agreements
Free Goods

 Taxes
Rebates
Shipping (++)

Shipping in the SD Process Chain

Organizational Units for Shipping and Warehouse
Controlling Deliveries
Shipping-Relevant Functions in the Order
Creating Delivery
Processing Delivery
Picking with WM transfer order
Packing
Goods Issue

Transportation (+)

Transportation in the SD Process Chain

Transportation Document
Transportation Control
Creation Options for Shipments
Transportation Planning and Processing
Shipment Cost Processing

Billing (++)

Billing in the SD Process Chain

Controlling the Billing Process
Data flow in Billing
Creating Billing Documents
Invoices, Credit memos, Debit memos
Types of Settlements
Billing Plans, Down payment processing, Installment plans
Account Determination
SD/FI Interface

Credit/Risk Management (+)

Organizational Units
Credit Control Area
Maintaining Credit Data
Controlling Credit Automatically
How Credit Blocks Affect Subsequent Functions
Components of Risk Management

Cross-Functional Customizig in SD (++)

 Output
Text Determination
Text Processing
Lists
Interface Modification (Account groups, Customer Master field selection, Material
Master field selection, Table Control, Transaction variants)
Material Determination
Special Business Transactions (+)

Shortage
Availability check
Partial Deliveries
Backorders
Third-Party Orders
Stock Transfer
Stock Transfer with SD
Cross-company Stock Transfer

Logistic Information System (+)

Data Warehouse Concepts

Standard Analyses
Information Structures
Update Rules

Integration with other modules (+)

Stock Transfer
Cross-Company Business Transactions
Processing of Complaints
Special Order Types
Basis in Integration (Project Experience or Participation in Case Study)

Sales and Distribution - Transfer of

Requirements

The MRP department is informed about the quantities and deadlines by

which incoming orders
should be delivered. The system checks the availability of the goods
based on the requested
delivery date of the customer and creates MRP records which contain all
necessary information
for passing on to planning. It ensures that the goods are available in
time for the delivery.
Materials planning transfers the reported requirements and creates
orders or purchase
requisitions from them etc.
For controlling transfer of requirements, you have to carry out the
following steps:
1. Each requirement type has to be allocated to one requirement class
only.
2. The transfer of requirements must be switched on at requirements
class level, the sales
documents at schedule line level.
3. You must define a check group. It is possible to have this check
group proposed for the
initial creation of a material master record.
4. Note that a plant must exist for transfer of requirements to be
carried out at document
item level.
OVZG

- Requirement class

It specifies the following points:

- whether an availability check and a transfer of requirements is
carried out for a
transaction (for sales documents, fine tuning using the schedule line
category is possible),
- whether the requirements are relevant for MRP,
- the allocation indicator from the sales view which controls the
settlement of customer
requirements with requirements
- whether an item is to be settled to an auxiliary account assignment,
- the settlement profile,
- the results analysis key.
(Use transaction SM30 for V_* configuration)
OVZH
- Requirements type
V_TVEPZ_V - Assignment of requirement type to Transaction
V_TVEP_V - Schedule line category
OVZ2
- Define Checking Group
V_TMVFU
- Define the checking group that the system proposes when you
create a new material
master record. You can overwrite the default value for the
checking group in the
material master record.

Steps for creating a new or changing an existing Billing

Document Types
Create/Change your Billing types configuration in VOFA.
Some of the IMG stuff are :1) To block automatic transfer of the billing document to accounting, mark the field.
Indicates whether the system blocks automatic transfer of the billing document to
accounting.
During document processing, you can manually transfer blocked billing documents to
accounting by selecting:
Billing -> Change -> Release accounting
2) Account determination procedure
3) Output determination procedure etc. ...
After customizing, use transaction VCHECKVOFA to check your configuration :1) Proforma billing types: If it is a proforma billing type, (VBTYP = U), the field must
be blank and the account determination procedure must be empty.
2) Cancellation billing document types: : A check is made to see if the cancellation
billing document type has the right VBTYP. An F2 invoice, for example, (VBTYP
'M')
can only be canceled with billing type S1 with VBTYP 'N' . A billing type with
VBTYP '5' can only be canceled with the VBTYP '6' and vice versa.
3) Cancellation billing document type partner functions A check is made to see if the
cancellation billing document type partner functions are empty or if those that
correspond to the billing type used are empty.
Next, make sure that you maintain the copy control for the Billing Types:
Sales documents in VTFA
Target
e.g. F1 - Invoice
F1 - Invoice

Source
OR - Standard Sales Order
ZOR - Your Sales Order

Billing documents in VTFF

e.g. G2 - Debit Memo F1 - Invoice
G2 - Debit Memo F2 - Invoice
Deliveries in VTFL
e.g. F1 - Invoice
LF - Delivery
F1 - Invoice
ZOR - Your Delivery
Usually for copy control, you let the rest of the settings remains as SAP defaults.
You only assign the new Billing Document Types.
After that use transaction VCHECKTVCPF to check your Copy control customizing.

Billing Block will not worked if you did not assign it

Define the possible block indicators in SM30 - V_TVFS
and
allocate them to the billing types concerned in SM30 - V_TVFSP.
Your Billing Block will not worked if you did not assigned it to the desired billing types.
You can auto block by :1. sales document type in transaction VOV8, fields Billing Block,
or
2. item categories in SM30 - V_TVAP, by filling the fields Billing Block.

Billing Plan for Milestone Billing

Milestone billing means distributing the total amount to be billed over
multiple billing
dates in the billing plan.
As each milestone is successfully reached, the customer is billed
either a percentage of
the entire project cost or simply a pre-defined amount.
During sales order processing, the system determines from the item
category whether a

billing plan is required and, if so, which type of plan

The type of billing plan that is determined at this point is set up in
Customizing and
cannot be changed in the sales document.
Billing plans for periodic billing and milestone billing plans for
project-related milestone
billing have different overview screens so that you can enter data
relevant to your
processing.
For example, for milestone billing, you must be able to enter data to
identify the
individual milestones.
IMG configuration requires :1.

Maintain billing plan types for milestone billing in OVBO.

2.

Define date description in SM30 - V_TVTB.

3.

Maintain Date Category for Billing Plan Type IN OVBJ.

4.

Allocate date category in SM30 - V_TFPLA_TY.

5.

Maintain date proposal for Billing Plan Type in OVBM.

6.

Assign Billing Plan Type to Sales Documents Type in OVBP.

7.

Assign Billing Plan Type to Item Categories in OVBR.

8.

Define rules for determining the date in OVBS.

Milestone billing is typically used for billing projects, such as plant

engineering and
construction projects. Such projects often include a series of
milestones that mark the
completion of different stages of the work. In the SAP R/3 System,
milestones are defined
in a network along with planned and actual dates for the completion of
work. The milestones
are also assigned to the billing dates in the billing plan.
Each milestone-related billing date is blocked for processing until the
Project System
confirms that the milestone is completed.
Delivery-relevant order items for which a milestone billing plan
applies are billed on the
basis of the requested delivery quantity and not on the total of the
confirmed quantities.

The connection between the project and the sales document item is made
in the individual
schedule lines of the item. Each schedule item can be assigned to a
network in a project.
To display the project-related data for a schedule line, proceed as
follows:
In one of the overview screens of the sales document, select
1.
2.

Item -> Schedule lines.

Mark the schedule line and select Procurement details.

The following figure shows an example of milestone billing where only

the Contract have
been billed :
Order

Item

Turbine

100,000

Billing Plan
Billing date Description
Billing Status
01-10-94
Contract
01-03-95
Assembly
01-04-95
Maintenance
01-05-95
Acceptance
01-06-95
Final invoice

Value

10
30
30
30
..

10,000
30,000
30,000
30,000
..

Billing Block
x
x
x
x

Milestone
x
x
x
x

Network/Activities
Milestone
Assembly
Maintenance
Acceptance

Estimate
01-03-95
01-04-95
01-05-95

Actual
01-03-95

For each billing date in a milestone billing plan, you can specify
whether the billing
date is:
1. fixed
2. always updated with the actual date of the milestone
3. updated with the actual date of the milestone, if the date is
earlier than the
planned billing date for the date

Define Tax Determination Rules

You specify the valid tax types in transaction OVK1. More than one tax type can be
defined for a country by defining the sequence.

The SAP System determines the taxes automatically within pricing.

In the standard SAP R/3 System, the elements of tax calculation are predefined (for
example, tax condition type "MWST" for taxes on sales and purchases).
Assign the plant for Tax Determination in OX10, using the country key, the SAP System
recognizes which tax type is valid for a plant and thus which taxes are relevant when
creating an SD document.
Define the Customer Taxes in OVK3, you will maintain the tax code in Customer
Master.
Define the Material Taxes in OVK4, which will then be maintain in Material Master.
For example :MWST GST
MWST GST

0
1

Tax Exempt
Liable for Taxes

Now, you define the Tax Determination in VK12.

VK12 - Domestic Taxes/Export Taxes
Condition Type

MWST

Customer Taxes
0
0
1
1

Material Taxes
0
1
0
1

Rate Taxes
0%
0%
0%
9%

In this example, if both the Customer Master and Material Master Tax code is 1, Tax will
be included when you create the Sales Order.

Tax Code in Customer Master / Sales Order

How can we maintain the Tax Code (Tax code - which we maintain in MWST
Condtion Records) in Customer Master or in Sales Order?
There are few points which I would like to remind you:
1) MWST is a tax condition which is applied to customer to whom we are selling. The
rate of tax is depend on various parameteres, whether is fully liable for tax or expemted
(in case of Defence Customer)
2) There are few parameteres which we apply tax condition. Whether customer is tax
liable? Whether material is tax exempted?

For example, if you are selling a goods which are free for tax to any customer, put the
Tax Indicator (at MMR as '0'). If your
material is tax liable pur the Tax Indicator (at MMR as 1). If your customer is not liable
for tax at all (like the case of Indian
Defence organisations) put the Tax Indicator (at CMR as 0) or 1 in case fully tax liable.
3) Now, at VK11 you need to mainatain your pricning conditions with all the
combinations like:
10
11
01
00
4) While maintaining your Material Master Records or Cusotmer Master Records, you
must identify, which are tax liable and which are tax exempeted.
5) In anycase, as a SAP standard Best Practises, while processing a sales order, you must
retrieve a Tax condition record from SAP database only and not entered Manually.
Accordingly, at V/06, the MWST condition Defintions, the field for 'Manual Entries', it
would be marked as - D (Not possible to process Manually).
Due to this setting, normally, you cannot maintain Condition tax code during sales order
processing. And in Cusotmer Master, you can only maintain Tax Indicator and not Tax
Code.
6) In case your client insists for Manual entry of Tax code during Sales Order processing,
you can change the field at point 5) above to C-Manual entry is priority instead of D.

Condition Exclusion which will be determined in the

billing document
The system can exclude conditions so that they are not taken into account during
pricing.
For example:
Material 4711 costs 150 USD. Some customers receive a discount of 10 USD per 100
pieces.
However, a specific customer can buy the material for 100 USD. Since this is a
particularly good price, the customer should not also have a discount of 10 USD per
100 pieces. Therefore, this discount is to be excluded from pricing.
To create a condition exclusion procedure which will be determined in the billing
document.

Assign the procedure to the pricing schema, and maintain copy control so that pricing is
not copied from Sales Order.
To achieve this, copy the standard pricing to a ZXXXX Pricing.
Define new document pricing procedure in SM30 - V_TVKV for billing.
Assign new document pricing procedures to billing types in SM30 - V_TVFK_PR
Define the Condition Exclusion Groups in OV31.
Assign the Condition type for the Condition Exclusion Groups in OV32.
Assign the Billing Pricing Procedure in VOK8 for the Condition Exclusion Groups.
When billing document is being created just enter manually your new price and the
pricing program logic will include only the higher price one, excluding the rest that are
lower price.

Pricing date based on delivery date

Used transaction VOV8.
This configuration is by order type.
There is a field called proposal for pricing date.
There you can select pricing date as requested delivery date.
A - Proposed pricing date based on the requested dlv.date (Header)
This control is set at the document level as oppose to the condition type level (PR00).
That means your other condition types such as surcharges and discounts are also
determined using the requested delivery date.
If your requirement is for PR00 to alone to be priced at delivery date then this will not
work.

How pricing date is determine in the sales order and

billing document? Where is the setting?

The pricing date is proposed based on the setting you make in the Sales document
configuration. ( T code : VOV8)
You have a field" Prop.f.pricing date " in the Requested delivery date / pricing date /
purchase order date segment.
Then you can choose the follwoing options:
Blank - Indicates the current date as the pricing date
A - Indicates the date based on the requested delivery date
B - Indicates the date based on the order validity start from date
And the pricing in the billing document is copied from thte sales order / Delivery
document..
It again depends on the setting u have in the copy control from order - billng or delivery billing.
In the copy control, in the item settings you have two fields relavant for this.
One is pricing source and the other is pricing type.
The pricing sources are generally the order. But if you want you can change it to other
values mentioned in the drop down,
but this values have no effect if the pricing type is B.
Any other value other than B in the pricing type will take the reference document price
mentioned in the pricing source field.
but for the pricing type B. The new price is determined in the billing order.

Sending a billing document by e-mail

First, your SAP system must be configure by the basis people in order for you to send an
external mail.
Whether it can send pdf or other file format will depends on the Mail Server you are
using.
The basis people must also maintain the conversion parameters so that SAP knows how
to convert the billing documents to be send as a pdf file or other desired format specified
by your company.
Finally, you have define the IMG in Maintain Output Determination for Billing
Documents (Output type MAIL)

Auto proposed all the dates when creating Sales Order

How can I make the system auto create all the Sales Order date during creation?
Each Sales Order can have different date proposal settings.
Follows this step to set the default Sales Order Type proposal date:
- Goto VOV8, double click on sales order type.
- Look and tick the fields Propose delivery date and Propose PO date.
After making the necessary IMG changes, you need to input the Delivery Plant field for
each Materials that you want the system to propose the default date.
To change the Materials field Delivery Plant:
Goto MM02, Select the View Sales: Sales Org. Data 1 and fill in the Delivery Plant.
Testing:
Now, try creating a new sales order for the material and SAP will auto proposed all the
dates in the sales order.

Mass Update of condition pricing

You can update the condition pricing for a range of sales order.
For e.g. if you create sales order for 15 months or so, and at the beginning of each year,
you have to update the prices for lots of sales orders.
Other than using VA02 and make an Update of the conditions at item level which is a big
work because you will have lots of open sales order after so many months.
Use VA05, select your Orders and on the result screen :click Edit- > Mass Change -> New Pricing (menu).
or
if you don't want to do that Online, write your own abap report and use Function
SD_BULK_CHANGE (check where-Used at SE37, Trace VA05 on how to fill the
parameters, Function MPRF => New Pricing)

SAP Billing - Combine Billing for deliveries with

different date

When using transaction VF04 or Billing (background), the date of the billing document
(e.g. the current date) must be entered (In VF04 : settings, default data.)
In VF06 or background: variant with parametrization) to avoid an unwanted split due to
the billing date.
This OSS notes is very helpful :11162 - Invoice split criteria in billing document
36832 - Invoice split in fields from the sales order

Make Material Master Price of a material as sales price

automatically
The first method is not to set the pricing condition VPRS as statistical.
Simply remove PR00 and it will work fine if you always use VPRS as your pricing base
inside the pricing procedure.
VPRS will reads both prices based on the price control in the material master.
Price control S for standard price.
Price control V for moving average price.
It is this simple if you do not have any other "Prices" in the price procedure.
However, if you are using one pricing procedure where for some items you price using
VPRS and some others using PR00, then you should use requirement routines to enable
the correct price condition type at the right time.
The second method involves more work as you need to write a formula (VOFM) to get
that information.
This is how it goes :1. Set VPRS to be the first step in the pricing procedure and to be subtotal B (as
standard).
2. Set PR00 with alt. calc. type formula, which sets the value of PR00 to be equal to the
subtotal B.
The routine (created with transaction VOFM) is:

RV64A901
FORM FRM_KONDI_WERT_600.
XKWERT = KOMP-WAVWR.
ENDFORM.
The pricing procedure than looks like that:
Step 1 VPRS statistical, subtotal B, reqt 4
Step 2 PR00 Altcty 600

SD material Determination based on availability check

For SD material Determination you can create a Substitution reason and on the
Strategy field, the following info. is available:
Product selection in the background is performed on the basis of the availability
check.
We want to have the material determination only in case on material shortage. We
expect the Substitution reason to give us this functionallity. It does not hovever
take the availabilty into account before substitution.
We thought the worse case is to create a ABAP which is linked to the "requirement"
field in the Procedure (OV13).
Has anyone had the same requirement? Is this a bug or just incorrectly
documented?
I also encountered this abnormally recently using material determination. In order to
combat the problem, the first product substitution should be for the original material. I've
illustrated this below:
Original Product: ABC
Substitutes: DEF, XYZ
In order to perform product substitution ONLY in the case of ATP failure for product
ABC, structure the Material Determination record as follows:
Material Entered: ABC Substitutes: ABC
DEF
XYZ
There seems to be a devaition at availability check and or on a conceptual note still.
Availability check can be configured both at requiremnt class and at the schedule line
categories level.

Whilst the availabilty check at the requirement class level via global and mandatory
configuration the schedule line catgry availability check deals with the order.
It is mandatory that the reqmnt class is flagged off for avlblty check and the schdelu line
cat need not be.
The following are the mandatory for Availability check to happen-1. Must be swithced on at the requirment class level and at the schedule line level.
2. Reqmnt type must exist by which a requiremnt class can be found
3. There must exist a plant and is defined
4.Checking group must be defined in Material Master records(it controls whthr the
system is to create individual or collective reqmnt)
A combination of checking gropup and checking rule will determine the scope of
availbaility check.

Difference Between Simple and Automatic Credit

Check Types
Explain in detail difference between simple and automatic credit check types. In
automatic check, difference between static and dynamic checks.
SIMPLE CREDIT CHECK : Tr.Code - FD32
It Considers the Doc.Value + Open Items.
Doc.Value : Sales Order Has been saved but not delivered
Open Item : Sales Order has been saved , Delivered, Billed & Transfered to FI, but not
received the payment from the customer.
Eg: Customer Credit Limit is Rs.1,00,000/Suppose Doc.Value + Open Item Value is Rs.1,10,000/Here credit limit exceeds then system reacts.
Options : A) Warning Message
B) Error Message (Sales Order won't be saved)
C) Error Message with Delivery Block

AUTOMATIC CREDIT CHECK : Give extra credit facilities to the particular

customer.
STATIC CREDIT LIMIT DETERMINATION :Checking Group + Risk Catageory +
Credit Control Area.
A) Credit Checking Groups : Types of Checking Groups.
01) Sales
02) Deliveries
03) Goods Issue
At all the above 3 levels orders can be blocked.
B) Risk Catageory : Based on the risk catageories company decide how much credit has
to give to the customer.
HIGH RISK (0001) : LOW CREDIT
LOW RISK (0002) : MORE CREDIT
MEDIUM RISK(0003) : Average Credit
Static Credit Check it checks all these doc value & check with the credit limit
1) Open Doc.Value / Sales Order Value : Which is save but not delievered
2) Open Delivery Doc.Value : Which is delivered but not billed
3) Open Billing Doc.Value : Which is billed but not posted to FI
4) Open Item : Which is transfered to FI but not received from the customer.
DYNAMIC CREDIT CHECK : 1) Open Doc
2) Open Delivery
3) Open Billing
4) Open Items
5) Horizon Period = Eg.3Months
Here the System will not consider the above 1,2,3& 4 values for the lost 3 months
Then assign the Sales Doc & Del Documents.
Sales Doc.Type(OR) + credit Check(0) + Credit Group (01)
Credit Limit Check for Delivery Type : Del.Type (LF) + Del Credit
Group (02) + Goods Issue Credit Group (03)