1.Sales Document Types Configuration and Details

7/23/2019 1.Sales Document Types Configuration and Details

http://slidepdf.com/reader/full/1sales-document-types-configuration-and-details 1/26

Sales Document Types Configuration

A document type represents a type of transaction in the system. For example, a

Contract Transaction is represented in the system using a document type CT. Similarly

a quotation to a customer is created in the system using a document type QT. Thereason why different document types are used to represent different transactions is

because, each transaction behaves in a different way from another. A quotation behaves

differently from a Standard Order. Some examples are shown below.

Quotation ( QT )

o Does not require Credit Check to be performed.

o No Deliveries required directly for a quotation unless converted to an order.

o Not relevant for billing.

Standard Order ( OR )o Relevant for Deliveries and billing

o Relevant for Credit Check

o Different fields are required compared to a quotation ( For example, quote

validity dates not required )

o Generates material requirements to be passed on to MRP, whereas a quote does

not.

The document type QT controls the characteristics of the quotation document type.

Also, if there are slight modifications required, a copy of QT can be made – like ZQT –

and used. For example, when creating a quotation in a particular company, if credit

checks needs to be performed that particular feature can be enabled.

Configuration The transaction code to configure a document type is [VOV8] or use the menu path

[SPRO -> Sales and Distribution -> Sales Documents -> Sales Document Header ->

Define Sales Document Types ]

When creating new entries, as usual always try to choose an entry close to your

required document type and copy it. For example, if you want to create a quotation with

different characteristics, its always better to create the new document type as a copy of

QT. That way all the item category determination, schedule like determination etc arealready done for you – unless you create new item categories.



Let’s go through some of the controls inside a document type say OR (which is the document type for

a standard order). Not all controls are relevant, but we will try to cover the most important ones.Select the document type OR and click on the magnifying glass or double click on OR to learn more.



The controls are segregated into multiple sections.

1. Number Ranges has 4 fields

2. General Control has 12 fields3. Transaction Flow has 15 fields

4. Scheduling Agreement has 4 fields

5. Shipping has 5 fields

6. Billing has 9 fields

7. Requested Delivery Date has 6 fields

8. Contract has 10 fields

9. Availability Check has 1 fields

As you can see, not all these sections are relevant for all types of documents. For example, the

Scheduling Agreement or the Contract Sections are not relevant for OR document type.

Before going into the controls in the different sections, there are some basic controls has 4 fields

The sales document category signifies at a broad level which type of sales document this document

type belongs to. These are hard coded and cannot be changed. The only document categories possible

are

o Inquiry ( A ) IN

o Quotation (B) QT

o Order (C) ORo Item Proposal (D) PV

o Scheduling Agreement (E) DS

o Scheduling Agreement with External Service (F)

o Contract (G) QC, QUANTITY CONTRACT, QP, RENTAL CONTRACT

o Returns (H) RE

o Order without Charge (I)

o Credit Memo Request (K) CR

o Debit Memo Request (L) DR

o Independent Requirements plan (W) 01

o Master Contract (O) GK

Now if you need to create a new document type that resembles a Returns document, you would have

to select the document category as H – which stands for Returns. Because, the way a standard order

behaves from a return is very different. And the document category controls how it behaves.

Also a sales document can be blocked. An example is a scenario where a new promotion document

type has been created in 2000 and the business process has changed since 2005 that requires the

company to not use promotions any more. In order to force the order entry personnel not to use that

document type, the sales document can be blocked as shown in the picture below.



Number Ranges

The Number Range Internal Assignment is used to mention the number range that is to be used when

creating a sales document of this type. Transaction code [VN01] is used to define those number

ranges. Each of the documents created in the system need to have a unique number. This is defined

using the number ranges.

For example, the number range 01 in this case starts from 0000000001 to 0000199999. And the

current number is 12919

So, when the next document of type OR is created, the number would start with 12920.

Similarly, if external number ranges are used, the number ranges assigned to 02 would be used.

Item Number Increment This is the auto increment that is to be used when creating line items in the sales order. When a sales

order of type OR is created the line items that are automatically generated would start with 10 and go

in increments of 10, 20, 30 so on.

Sub-item Increment

If new items need to be entered in between ( Say for example, between 10 and 20 ), then that item will

have to start with atleast 10 + 1 = 11.



General Control

Reference Mandatory :Sales documents can be created with reference to other salesdocuments or other billing documents. This field signifies if a reference is mandatory. For example a

release order can only be created with reference to a contract. Similarly if your business dictates that

a sales order cannot be created without reference to a quotation, you can configure it here. The

possible values are

o No reference required ( Blank )

o With reference to inquiry (A)

o With reference to Quotation (B)

o With reference to Sales Order (C)

o Scheduling Agreement Reference (E)

o With reference to Quantity Contract (G)

o With reference to Billing Document (M)

Check Division When creating a sales order you can enter the sales organization, distribution channel and division.

However, it is possible that you enter materials belonging to different divisions in the sales order. You

can configure the system to either allow or disallow materials from different divisions be entered in

the sales order.

No Value ( blank) Allows materials of a different division at the line item level compared to the header level division

Dialog (1) & Error (2) This option will force the system to respond with either an error or a warning when a different division

is entered.

Probability



This field is rarely used and if used is used mostly in inquiries and quotations which are not actual

sales.

Credit Limit Check

There are different types of credit management that can be used in SAP SD. This field signifies whatkind of credit check need to be used for this kind of sales document.

Credit GroupCredit group 01 is defining for the sales order. This field is almost always set to 01 for all sales

documents. 02 for delivery, 03 for goods issue.

Output ApplicationFor standard sales document types, this is set to V1. Shipping documents have this field as V2, billing

documents as V3 etc.



Material entry control

Controls how the entry field for the material or material order number should be interpreted in the

sales order.

As we put blank for enter with mat. Number.

Item Division (In sales order item comes from the material)Indicates whether the division at the item level is proposed from the material master record of the

item or whether the division you enter in the sales document header also counts for all items.

If you mark this field, the system proposes the division from the material master record of the item. If

you leave the field blank, the division in the document header also counts for all items.

Read Info record

This field needs to be checked if this document type needs to use the Customer Material Info Record

(CMIR) .we can activate this field through tick mark or keep it blank.

Check Purchase Order Number



When the incoming Customer PO contains a duplicate PO number or if the order entry personnel is

creating a duplicate sales order ( with the same PO number ), this field can be used to force a check

for a pre-existing Purchase Order Number for that customer. There are only 2 options in this field. A

blank means no check. ‘A’ implies to do a duplicate check on existing PO numbers. Let’s set it to ‘A’ for

order type OR and see the difference.

o Create a sales order with PO # = “Bulk Order 123 for customer 1400.″

o Let’s create another order for the same customer with the same PO #. This time the system

would issue a warning message saying that the purchase order number “Bulk Order 123 already″

exists. This is a way of preventing duplicate POs from being entered in the system.

Enter PO Number

This check box is used to copy the Sales Order Number into the PO Number field. This could be used

when there is no Actual PO # from the customer but a number needs to be entered in the PO Number

field. To test this, just create a sales order and without entering a PO Number save the sales order.

Reopen the sales order and you will find the PO Number field will be filled with the Sales Order

Number automatically.

Commitment dates

Key that controls how the commitment quantities should be calculated per sales document type.

The commitment date is calculated using the delivery time for releases to contracts with delivery

times, or sales orders that refer to quotations containing delivery times. The committed quantity

results from the agreed delivery time or the confirmed quantity, according to the calculation rule set

here the following calculation rules are used for the commitment date:

• A: Consider agreed delivery time

Here, all required schedule lines are committed for the date that lies at the agreed distance

from the delivery time, according to the date on which the order was placed. If the customer

requests a later date, this can be confirmed. The confirmation does not affect the calculation.

If you do not enter a delivery time, the system does not calculate a committed quantity.• B: First confirmation date

The committed quantity is calculated according to the first confirmed quantities. If a delivery



time exists for the item, the system takes it into account, as in calculation rule A, and

confirms the earlier date. The commitment date is recalculated if the material, quantity, first

date, or delivery time change. The quantities confirmed then are valid once the document has

been saved.

• C: First confirmation date

Rule C is the same as calculation rule B but for new items. If you save a document again but

the system can confirm more for the customer, the more favorable situation will be saved as

the commitment. As in rule B, the commitment date will be recalculated if changes are made

to the material, quantity, requested delivery date, or delivery time.

• No entry

Commitment dates are not calculated or displayed

Transaction Flow

Screen sequence groupControls which screens you see during a particular transaction (forexample, creating a quotation) and in which sequence they appear. You can specify a screen sequence

group for the processing of inquiries and quotations. In this case, the screens and their sequence

would differ from the screen sequence for, say, creating a sales order.

Incompletion procedure The number that uniquely identifies the incompletion procedure. The incompletion procedure defines

a number of fields in which the user must enter information.

The system uses the incompletion procedure to determine which fields appear in the incompletion log

when the user does not enter information during sales order processing. In SD Customizing, you can

specify an incompletion procedure for each type of sales document.

Validity periods and customer purchase order numbers are required entries for both contracts and

scheduling agreements. In this case, the system automatically proposes the same incompletionprocedure for both types of document.



This field always in use at the time log of incompletion procedure determination. See the no 7 is use

for customer during the partner determination procedure, in partner function you will able to see the

error no of 7, and it has to be determine in log of incompletion procedure. Here for IN & QT = 10, For

OR, RO & CS IS 11, For CREDIT MEMO & RETURN ORDER IS 14 & For DEBIT MEMO IS 15, For

ITEM PROPOSAL/ PRODUCT PROPOSAL IS 16.

Transaction group

A grouping that allows you to control certain characteristics of a transaction according to sales

document type. The transaction group controls,

• the types of sales documents you can process with certain system transactions in sales

processing

• for which sales, shipping and billing documents the system should update reporting indices

(in tables TVIND and TINPA).

The transaction group that you enter in table T180 (Next screen processing), must agree with the

group that you enter in table TVAK (sales document types). If you leave the field blank in table TVAK,

then the system does not check the transaction group.



At here, we usually put 0 for OR, CS, RO, 1 for IN. 2 for QT, 5 for ITEM PROPOSAL OR PRODUCT

PROPOSAL (PV). FOR RE WE ALSO PUT 0, because return order can processed to the sales doc type

of OR, RO, CS.

Document Pricing Procedure

This field along with the customer pricing procedure determines the Pricing Procedure.

During pricing, the system determines the pricing procedure by taking into account

• The sales area

• The pricing procedure key in the header of the sales document type

• The pricing procedure key in the customer master record

The pricing procedure determines how the system carries out pricing for a particular sales document

(for example, which pricing condition records it accesses and in which sequence). in standard order

OR, we put (A) as the doc. Pricing procedure, for the new sales doc type we can put new doc. Pricing

procedure, define during the time pricing procedure determination.

Status Profile

Sales Documents have different statuses at the header level and item level. There are a set of pre-

defined Statuses that SAP uses. Also, you can define custom defined Statuses and define sequences

in which they go.

Alternate Sales Document Type

During order creation, you can change the document type on the fly. This again is a rarely used

feature and is tricky to use as well because of the constraints imposed on this feature. When creating

a sales transaction, we mention the document type upfront and SAP takes us to the right screen.

However, inside the sales order screen it is possible to change the sales order type by just clicking on

the radio button.



You can select the order type (highlighted in orange above) and if the constraints are fulfilled, the

order type can be changed. The configuration for the same is to have ZOR and ZTA as the alternative

document types in the sales order level.

Display RangeSpecifies the kinds of items that the system automatically displays during document processing.

You can specify, for example, that the system displays only main items and that it suppresses those

items that are dependent on others. In this case, you can still enter dependent items in the document.

However, the system does not display them.

F-code default for overview screenDetermines which overview screen you reach, during sales order processing, after you enter data in

the initial sales document screen. Customers frequently order goods from you using their own

numbers and descriptions for your products. You can set the default for the overview screen so that,

during order entry, you automatically arrive at the screen where you can enter the customers'

material numbers directly.

Incomplete Messages



This field allows the user to save the order irrespective of the messages in the incompletion log. Use

this feature when you want to force the user to not save the order without completing all the

necessary items as specified in the incompletion log of the sales document header and item. Through

the tick mark or left blank, we can activate this field.

Quotation Messages / outline agreement message: When creating sales orders, if there are outstanding quotations for the customer for this material, you

can configure the system to react differently based on the different options that are configured. The

possible options are self-explanatory.

A / B Check at Header / Item level

C / D Check at header / item level and copy if unique. This option is useful, if there is only 1

matching quotation that you just want to be copied into the sales order.

E / F Check at Header / Item Level and branch directly to selection list. This option is useful if there

are multiple quotations and you want the list of multiple quotations to be shown to the user creating

the order.

As an example, let’s set this field to E ( which checks for matches at the header level ) and try to create

2 quotations 20000036 and 20000037 for the customer 1400.

Now if we create a sales order for the same customer 1400, irrespective of the line items, the list of

open quotations are displayed.

However, if the option was set to F, this message would not have been shown until the

line items entered in the sales order matched the line items in the open quotations.

Add ref. to all contracts partner is authorized to release

You can set a supplementary indicator here if you would like to refer to additional contracts when youcreate the document.



• Indicator 'A'

In addition to the contracts the system has found, it also selects all the contracts in which the

sold-to party is stored as a partner authorized to release.

• Indicator 'B'

In addition to the contracts the system has found, it also selects all the contracts in which the

sold-to party is authorized to release according to the customer hierarchy.

Regardless of the indicator you choose, the system searches for contracts at header level using the

customer.

On/off switch for master contract messages

Field which controls whether the system checks for existing master contracts during contract

creation.

Set indicator A in this field if you want this check to be performed for a contract of this sales

document type. When you create a contract, a dialog box appears if master contracts exist for the

sold-to party you enter. You can branch from the dialog box to a list of the master contracts. You can

then select a suitable master contract to link your contract to.

Set indicatorB if, when the check determines only one suitable master contract exists, you want thismaster contract to be copied.

Set indicatorC if you want to branch directly the list of suitable contracts after the check has been

performed.

Sales and Distribution (SD)

A document that contains only header data.

Contracts for a customer are grouped as lower level contracts under one group master contract. The

master contract data is valid for all lower level contracts.



Shipping This section controls the delivery parameters.

Delivery Type This field contains the delivery document type that is used when a delivery is created for the sales

order. The standard delivery LF is used when creating a delivery document for the sales document of

type OR. For CS it would be BV, and for RO it would be LF, for return order RE, it would be LR. For iN,

QT, CR, DR, PV, Doc type no need of delivery type and shipping control. Keep this control blank.

Immediate DeliveryConsider the case of a rush order ( As soon as the order is created, the delivery needs to be created ).

Again, there are 2 cases here. Creation of the immediate delivery if stock is available and confirmed

and creation of the delivery irrespective of the stock situation. Rush order follows the first example. As

you can see in the screenshot below, as soon as the rush order is created and saved, the delivery is

automatically created ( Subject to availability )

Delivery block (document header)

Indicates if an entire sales document (a sales order, for example) is blocked for delivery.

The system can propose the delivery block indicator according to sales document type. You can also

enter a block manually in the header. A block in the header applies to the entire document. If you

want to block one or more specific items, you can enter the block at item level.

The delivery block at header level is only effective if this block is assigned to the corresponding

delivery type in the Customzing table (TVLSP). Regardless of the settings in Customizing, the delivery

block is always effective at schedule line level.

You can block delivery automatically for certain sales document types (for example, free of charge

deliveries) where it is important that someone checks the details before shipping takes place.



If you use a credit limit check, the system can automatically block delivery. You can change this block.

However, as soon as you change any of the values in the sales document, the system automatically

reapplies the delivery block.

Shipping Condition

A shipping strategy for delivery. If the shipping condition states, for example, that the goods must

reach the customer as soon as possible, the system proposes the fastest shipping point and route.

Specifies the shipping conditions that apply to this type of sales document.

The system proposes shipping conditions from the customer master record. The proposal from the

customer master record is overwritten by the shipping conditions that you define for a particular sales

document type in Customizing. The entry from Customizing is considered as a default value. If no

shipping conditions are set in Customizing for the sales document type, the shipping conditions of the

sold-to party are used.

You could, for example, specify different shipping conditions for- free-of-charge deliveries.

Shipment Cost Information Profile



The shipment cost information profile contains proposal values for the shipment cost information in

the sales order, such as the transportation planning point, the shipment type and the shipment cost

pricing procedure. You can also assign different transportation planning profiles to a shipment cost

information profile. These profiles are used to carry out different options for shipment cost

determination (deliveries are combined differently, or a different mode of transport is used) You can

change the proposal data in the shipment cost information.

Billing This section controls the billing parameters in sales order.

Proposed billing type for a delivery-related billing doc. The billing type that the system automatically proposes for this type of sales document during the

creation of billing documents (invoices, credit memos, etc.) that refer to deliveries.

You can specify a billing type in this field for sales document items that are relevant for delivery

(standard sales orders, would be the F2). Profarma order is F5, Cash Sales order is BV, Return Order

is RE.

Condition type for copying costs from line items

This is where you enter the condition type which you want to use to determine the results of the sales

order pricing for a sales and distribution document item.



• If you enter the condition type into the requirements class, this condition type is used for all

sales and distribution document items containing a requirements type, which indicates this

requirements class.

The definition of the condition type per requirement class allows you to determine different

condition types for the different items of a sales and distribution doc. For example, you could

carry out pricing for one item on the basis of a sales order pricing procedure, while the value

of the sales order pricing might only be forwarded statistically for another item in the same

document. The sales order costing refers to the sales order item.

• If you enter the condition type into the sales document type, this condition type is used for all

items in a sales document of this sales document type.

In the standard version of the SD system, two condition types are provided for the cost transfer of line

items:

• EK01

If you choose this condition type, the result of the sales order costing is first printed

to the pricing screen for the item. The value can be used as the basis for price

computation.

• EK02

If you choose this condition type, the result of the sales order costing is simply a

statistical value, which you can compare with the price. Take the following points into account:

• The condition type must have condition category 'Q' (costing).

• The condition type must agree with the condition type defined in the SD pricing procedure.

• If you also want to display the fixed cost part in the condition in addition to the full costs,

then enter a condition type in field "CondTypeIndFix".

The transfer of the fixed cost part improves the ability of the system to predict the profit

margin.

Proposed billing type for an order-related billing document



The billing type that the system automatically proposes when you create billing documents (invoices,

credit memos, etc.) that refer to sales orders. For CREDIT MEMO= G2, For DEBIT MEMO= L2, like so

on, in the case of return order RE= RE, AND OR & RO= F2, BV= BV.

You can specify a billing type in this field for sales document items that are not relevant for delivery

but that nevertheless require billing (for example, an item for a service, such as consultant hours).

Billing/Invoicing Plan Type

Controls which fields are offered for processing. It also specifies how billing is performed for the billing

dates in a billing plan of this type. The following options have been defined

• Periodic billing - the entire value to be billed is billed in full on each billing plan date

• Milestone billing - the total value to be billed is distributed between the individual billing plan

dates (the value billed on each date can be fixed amount or a percentage)

Periodic billing is used to bill rental or maintenance contracts.

Milestone billing is used to bill projects.



Billing type for intercompany billingSpecifies the billing type that the system automatically proposes when you create billing documents

for inter-company billing.

Here we used to put Billing doc. Type of (IV) for inter company billing,

Document payment guarantee procedure

This key identifies the document payment guarantee procedure for this sales document type.

The document payment guarantee procedure defines which payment guarantee procedure the system

automatically uses for a sales document type.

Within receivables risk management, the system determines the payment guarantee procedure taking

into account:

• the key for the document payment guarantee procedure in the header from the sales

document type

• the key for the customer payment guarantee procedure in the customer master.

You can define different payment guarantee procedures for your system. The payment guaranteeprocedure defines the type and sequence of the forms of payment guarantee that the system assigns

to sales document items.



Receivables risk management is only activated once the document payment guarantee procedure has

been defined.

Block

Indicates if the item is blocked for billing.

The system can automatically propose a billing block for sales documents that must be checked before

billing (for example, returns, credit and debit memo requests).

If the system proposes a block, you can change the block manually for each item. If the system does

not propose a block, enter one of values predefined for your system. If the item has more than one

schedule line, the block applies to each line. You can change the block for individual schedule lines.

IN DOC TYPE OF RE , CR, = 08, & DR = 09.

Payment card plan type

Specifies the payment plan type for payment cards. In the standard system, this is referred to as the

"payment card plan type".

The payment card plan type specifies how the sales documents to which it is assigned will be settled

for payment, in this case with one or more payment cards.



Note that you must assign the payment card plan type to all document types in which you will be

using payment cards. You cannot process payment cards until you have done so.

For Sales Doc type. OR and R0 we will put 03, & for the sales doc type CS, RE, CR, DR, IN, QT, PV, we

keep it blank.

Payment cards: Checking group - Sales document

Defines how the system carries out checks on payment card data in different SD documents.

This is done on the basis of checking group assignments to the different sales document types.

Requested delivery date/ pricing date / purchase order date



Lead Time in Days

Specify the number of days after the current date that the proposal for the requested delivery date in

the sales document should be. There is no possible entry, we can put the days as per requirement.

Date type (day, week, month, interval)

Identifies the date type internally in the system. When you create schedule lines for a sales document,

you can specify different formats for the delivery date (day, week, or month). This indicator enables

the system to refer to a particular format, independent of the language in which it appears on the user

interface.

Sales and Distribution (SD)

A definition of the date format used. The date type indicates whether the delivery date is expressed as

a day (date type D), a week (date type W), or a month (date type M).

In the Sales Doc. Type of CS & RO we put date type as 1, as both the doc type are using immediate

delivery of (X).

Proposed pricing date based on the requested dlv.dateEnter the date which you want the system to propose for the pricing date when a sales document is

created. You can overwrite the proposal in the sales document.

You want the day on which the contract becomes valid to be the date which is proposed as the pricing

date in the sales document. Therefore, in the standard version of the R/3 System, you would enter the

indicator B in this field.



Proposed valid-from dateSpecify the ID for the date which the system should propose for the valid-from date when, for

example, you enter a quotation.

Propose current date as requested delivery date

Indicates whether the system automatically proposes the current date as the delivery date.

Delivery date

The date on which goods are to arrive at the customer's premises.

Example

The delivery date can be the delivery date requested by the customer (desired delivery date) or the

date confirmed in the vendor's order acknowledgment or shipping confirmation (confirmed or

acknowledged delivery date).

Propose current date as purchase order date

Specifies whether the system automatically proposes the current date as the purchase order date.

Contract and Availiabilty Check



In this contract control we have to complete only two filed (1- billing request and check partner

authorization, contract is used for the special business process like rebate agreement. In rebate

agreement, we used to generate the Debit Memo, after complying the agreement between the clients

and customer. So in the billing request it has DR for Sales Doc. Type of OR. And check partner

authorization we put (A) because whether system check the partner during the time of Debit MemoIssue. Debit Memo always refer to sales doc type of OR.)

Check partner authorizations This check determines whether a partner is authorized to release against a contract.

Here you can specify whether the check is to be performed against the partners in the contract or the

partners in the customer hierarchy. If you do not want the check to be performed, leave the field

blank.

When you create a release order for a contract, the system determines whether a partner is authorized

to release against the contract. The check is performed at header level. Depending on the rule you

enter in this field, the system checks against one of the following:

• Partners in the contract



If the partner has the partner function AG (sold-to party) or AA (sold-to party authorized to

release) in the contract, the system accepts the partner as the sold-to party for the release

order.

• Partners in the hierarchy

If the sold-to party of the contract is at a higher level in the customer hierarchy to the partner

who wants to release against the contract, the system accepts the partner as the sold-to party

for the release order.

Note

If you create a contract with reference to another contract, the system does not run a check and it

copies all the partners created in the target contract. If you do not want it to do this, use copying

control in Customizing to change it.

Rest fields are use for the contract doc type, like GK, QC, and so on.

ATP: Business Transaction for ATPIn Availability Controls, it has only one filed is Business Transaction, it denotes entry makes it

possible to use the availability check settings in the APO planning system for this order type.

Using the business transaction, you can control in which business contexts a rule-based availabilitycheck is carried out. A rule-based availability check is therfore, as a rule, not sensible for a rush

order.

When called from the ERP system, this value is created using the order type for the sales order from

which calling takes place.

Date post:	17-Feb-2018
Category:	Documents
Upload:	rsnmurthy
View:	224 times
Download:	0 times