• No results found

SAP SD Sample Certification Questions in Sales Order Processing

N/A
N/A
Protected

Academic year: 2021

Share "SAP SD Sample Certification Questions in Sales Order Processing"

Copied!
19
0
0

Loading.... (view fulltext now)

Full text

(1)

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.

(2)

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.

(3)

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

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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

(9)

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.

(10)

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.

(11)

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?

(12)

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.

(13)

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?

(14)

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)

(15)

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

(16)

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.

(17)

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.

(18)

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

(19)

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)

References

Related documents

Seed production and recruitment were also related to regional climate factors, where it was possible to explain their variations through temperature (e.g. summer temperature)

After analyzing the findings, the study recommend the consistency trainings/capacity building so that to help managers/enterprise owners to understand the necessity

SELEX cycle usually involves five major steps of [i] co-incubation of an aptamer library with the target of interest to form aptamer-target complexes, [ii] partition of unbound

Because of their good activity and selectivity, and their high resistance towards deactivation and low activity for water-gas-shift reaction, supported cobalt catalysts are

❏ most common cause of death from congenital heart disease in first month of life. ❏ presents with circulatory shock and metabolic acidosis on closure of

The IEPE (ICP TM ) accelerometer sensor, known as the tri-axial seat accelerometer, used in this study was a VI-400Pro real time vibration analyzer.. This sensor was utilized

SB 909 – Income tax Checkoff – Developmental Disabilities Services and Support Fund – Designation The bill alters the designation of the “Developmental Disabilities Waiting

This article examines the historical relationship between real estate property market forces, which drive property earnings, and capital market forces, which largely determine