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 

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 typeV_TVEPZ_V - Assignment of requirement type to TransactionV_TVEP_V  - Schedule line category OVZ2      - Define Checking GroupV_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               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 BillingMilestone 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 havebeen billed :

Order  Item  Turbine    100,000

Billing Plan

Billing date Description    %  Value  Billing Block   Milestone   Billing Status01-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             x01-05-95     Acceptance    30  30,000      x             x01-06-95     Final invoice ..    ..        x

Network/Activities

Milestone    Estimate      ActualAssembly     01-03-95      01-03-95Maintenance  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)   

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)