SAP SD Sample Certification Questions in Sales Order Processing

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.

x

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)