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 Goods issue reduces requirements in materials planning
B Goods issue posts value changes to the stock account in inventory accounting C Goods issue posts value changes to the stock account in asset accounting D Goods issue posts value changes to the tax account
E 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. Item category and document type
B. Item category group and strategy group on the material master record C. Item category and MRP type on the material master record
D. 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. Item category and document type.
B. Item category group and strategy group on the material master record. C. Item category and MRP type on the material master record.
D. 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
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
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 Source
e.g. F1 - Invoice OR - Standard Sales Order F1 - Invoice 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. Item -> Schedule lines.
2. 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 % Value Billing Block Milestone Billing Status 01-10-94 Contract 10 10,000 - x x 01-03-95 Assembly 30 30,000 x x 01-04-95 Maintenance 30 30,000 x x 01-05-95 Acceptance 30 30,000 x x 01-06-95 Final invoice .. .. x Network/Activities
Milestone Estimate Actual Assembly 01-03-95 01-03-95 Maintenance 01-04-95
Acceptance 01-05-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 0 Tax Exempt MWST GST 1 Liable for Taxes Now, you define the Tax Determination in VK12. VK12 - Domestic Taxes/Export Taxes
Condition Type MWST
Customer Taxes Material Taxes Rate Taxes
0 0 0 %
0 1 0 %
1 0 0 %
1 1 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: 1 0
1 1 0 1 0 0
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)
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.
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)