SAP Sales and Distribution (SD) is one of the most popularly used modules that is imparted in the SAP SD Certification program towards better data and work management in enterprises.
The entire data in the sales document lies at 3 levels. They are header data, item data, and schedule line data.
Header data: Any information which is applicable to the entire document is called header data. For example, sold-to-party, ship-to-party, document currency, shipping conditions, unloading point, sales office, sales group, Incoterms, payment terms, etc.
To see the header data select the icon “display document header details” in the overview screen or in the same overview screen from the main menu select, go toàheaderàselect the required view.
Item data: The general data entered at the header level by default applies to all the items in the sales document. Still, each item in the document will be having its own related information called item data. For example, material code, description, order quantity, the unit of measure, plant, weight, ship-to-party, etc.
Even though the data is copied from header to item, if required it can be changed at the item level. But those are specific to that particular line item only for which they have been made.
To see the item data select the line item and select the icon “item details” or from the main menu select; go toàitemàselect the required view.
Schedule line data: It always gives information about the delivery dates and corresponding confirmed qualities. Depending on the availability of the material, each item in the sales document will have one or more schedule lines.
To see the schedule line data, first, go to item data and then select the tab page “schedule lines”.
During the sales document processing, the system automatically retrieves the data at all the 3 levels in the following way.
Header level: At this level, the system retrieves the data from the customer master record. When we enter sold-to-party in the sales document then the system goes to the corresponding master data of that sold-to-party and check whether all the partners are the same or they differ. If all the partners are the same, the system retrieves the entire data from the sold-to-party record itself. If the partners differ, the system retrieves the different details from different master records. For example, certain details like sales area, sales office, sales group, currency, shipping conditions, etc. will be copied from the sold-to-party record, certain details like unloading point, receiving point, etc will be copied from the ship-to-party record and certain other details like Incoterms, payment terms, etc will be copied from payer record.
Item level: At this level, the system determines the data in different ways as described below.
Certain information like material description, unit of measure, weight, material group, etc. will be determined from the corresponding material master record, and certain other details like payment terms, Incoterms, unloading points, etc are copied from header data.
The pricing information of the material will be determined from conditions master data.
For each item, the system determines the plant from one of the following master records by searching in the sequence in which they are specified.
Schedule line level: At this level, the system proposes the delivery dates and the corresponding confirmed dates and the corresponding quantities by checking the availability of the material and also by considering different lead times.
|
Creating the sales document with reference
Example: Creating sales order with reference to quotation.
Step-1: Creating a quotation.
Path: logisticsàsales and distributionàsalesàquotationàVA21-create.
Step-2: Create an order with reference to the quotation.
Document flow: When the documents are created with reference, the system forms a flow of documents in which if we know one document no., with the help of the icon “display document flow” we can see the remaining document no’s created with reference.
Status of a sales document: For each sales document we have 3 different statuses. They are;
The status of a document depends on the status of items in that document. If the status of all the items is open, the status of the document is open. If the status of all the items is completed, the status of the document is completed. If the status of any one of the item in the document is either open (with the other items having the status-completed) or being processed, the status of the document is being processed.
The status of the item depends on the quantity that has been referenced. If the entire quantity is referenced the status of the item is completed. If the partial quantity is referenced the status of the item is being processed. If the item is not at all referenced the status will be open.
To see the status of a document select the button “status overview” in document flow or select the tab page “status” in the header data. To see the status of an item select the tab page “status” in the corresponding item data.
Controlling the data in the sales document: The data that exists at all the 3 levels in the sales document has to be controlled as per the business requirements of the client. For this, we have the following controlling parameters in the sales document.
Sales document type: The data at header level is controlled by the sales document type.
Item category: In a sales document we can process different items like standard items, third party items, BOM items etc. Depending on the item the data at item level has to be changed. For this, we have the controlling parameter item category.
Schedule line category: The data at the schedule line level which provides the information about the delivery dates and the corresponding confirmed quantities is controlled by the schedule line category.
In a business process we have different sales transactions like inquiries, quotation, sales order, returns order, agreement etc. Each sales transaction has its own purpose and usage. For example, the sales transaction quotation is not relevant for shipping and billing whereas the other sales transaction sales order is relevant for both shipping and billing.
For each sales transaction, we create a corresponding sales document in the SAP system. While creating the sales document we have to specify the sales transaction for which that sales document is created. This is controlled by sales document type which is the representation of sales transactions in the SAP system. Each sales document is processed by using a sales document type which helps the system in further processing of that document. The no. of sales document types that we need to define depends on the business requirements of the client.
Defining sales document types:
Path: SPROàsales and distributionàsalesàsales documentsàsales document headeràdefine sales document type.
Example:
The functionality of sales document type:
Document category: Specifies the classification for different types of documents that we process in the sales and distribution system. i.e., the document category specifies whether that document is representing inquiry or quotation or sales order or returns order etc. The document category determines how the system stores and keeps a track of the document data.
Example:
Sales document block: By using field we can block a sales document type, so that the users cannot process the sales process by using that document type.
If a sales document type is blocked, we cannot create new sales document of that document type. But those documents that have been already created before setting the block can be changed or displayed.
Number range internal/external assignment: Specifies the no. ranges that either the system (if it is internal) or the user (if it is external) uses for giving no’s for sales documents when they are saved.
Defining no. ranges for sales documents:
Path: SPROàsales and distributionàsalesàsales documentsàsales document headeràdefine no. ranges for sales documents.
Select the button “change interval” and create the required the no. ranges.
Item no. increment: Specifies the value by which the item no’s in the sales document increases when the system automatically generates item no’s for the materials. If required the user can manually enter item no. for the material in the sales document.
Sub-item increment: Specifies the value by which the sub-item no. is incremented in the sales document.
Note: If we leave this field blank, the sub-item no. will be incremented by a value by which the main item no. is incremented.
Reference mandatory: Specifies whether the sales document must be created with reference to another document. If it has to be created with reference, we shall also specify with reference to which document it has to be created.
Item division: If we check this field, the division at the item level in the sales document will be determined from the corresponding material master record. Otherwise, the division entered at the header level will be copied by default to all the items in the document.
Check division: Specifies whether the system reacts with a message or warning or error message if the division at the item level in the sales document differs from the division at the header level. If the business requirement is to restrict selected customers from placing orders from certain divisions, we shall get an error in the sales document if the item division deviates from the header division.
Probability: Specifies the percentage of order quantity that can be transferred to inventory management for material requirements planning. If required we can maintain different order probabilities for different customers in the corresponding customer master data on the sales tab page under the sales area data view.
Check credit limit: Specifies whether the system carries out the credit limit check during the sales document processing. It is not required to carry out the credit limit check for certain sales document types like IN, QT, RE, and CS. But it is always a best practice to carry out a credit limit check for the sales documents types like OR and RO.
Credit group: Specifies which transaction has to be blocked for processing if the credit limits are exceeded. The standard credit group to block the sales order if the credit limits are exceeded is ‘01’.
Output application: The application specifies for which transactions the output has to be issued for all the sales transactions the output application is ‘V1’.
Read info Record: When we enter the customer material no. in the sales document, the system automatically determines the original material no. For this we have to check this field in the definition of the corresponding sales document type.
Check purchase order no: Specifies how the system reacts if the PO no. entered in a sales document already exists for another document.
Note: If multiple documents have same PO no. the system reacts with a warning message or no message. If the requirement is to get error message, this enhancement is to be done by the ABAPER by using “user exits”.
Enter PO no: If we check this field, the sales document no. will be automatically determined as PO no. if that sales document is saved without PO no.
Screen sequence group: Specifies which are to be displayed during the sales document processing. The screen sequence group is a standard value given by SAP which controls the set of information that has to be displayed while creating the sales document.
Example:
‘AG’ for inquiry and quotation.
‘AU’ for the sales order.
‘RE’ for returns.
Incompletion procedure: The incompletion procedure specifies which fields are mandatory in the sales document.
Transaction group: Specifies a grouping that allows you to control certain characteristics of a transaction according to sales document types. The transaction group controls which sales document types shall be processed with which transaction codes.
Example:
‘0’ for orders.
‘1’ for inquiry.
‘2’ for quotation.
| Checkout Our Blog on SAP SD Interview Questions |
If a sales document type has the transaction group ‘0’, it shall be processed with the transaction code ‘VA01’, if the transaction group is ‘1’ it shall be processed with ‘VA11’, if the transaction group is ‘2’ it shall be processed with ‘VA21’ etc.
Document pricing procedure: It enables the system to automatically determine a corresponding pricing procedure depending on the document type during sales document processing.
Display range: Specifies whether the system displays only main items or all the items in the sales document.
F-code for overview screen: Specifies which overview screen (item overview or item detail or ordering party etc) we reach after specifying the data on the initial screen.
Quotation messages: We can specify a value for this field to receive the message informing that open quotations exists while creating the sales documents. Depending on the value we specify for this field, the system searches for open quotations in the sales document either at header level for the customer or at item level for the material.
Note: It is always a best practice to use this functionality for OR, never use it for IN and depending on the requirement use it for QT also.
Outline agreement messages: Same as above but used for open agreements.
Message master contracts: Same as above but used for contracts.
Incompletion messages: If we check this field we cannot save the sales document if it is incomplete.
Delivery type: Here we need to specify the corresponding delivery type of the sales document type so that while creating the delivery document with reference to sales document the system automatically determines the delivery type from this field. For example, for the sales document type ‘OR’ the corresponding delivery document type is ‘LF’.
Note: It is not required to specify any shipping data for certain sales documents like IN, QT.
Delivery block: Here we can specify the reason for which the sales document has to be blocked for delivery. Whatever the reason that we specify here, this will be automatically propose for the field delivery block.while creating the sales document in the overview screen. To deliver the blocked sales order the user has to remove the delivery block in that sales document. But the authorization for releasing the block will be given for the selected users only.
Depending on the requirements we can define our own delivery blocking reasons. For this go to;
Path: SPROàlogistics-executionàshippingàdeliveriesàdefine reasons for
blocking in shippingàdeliveries: blocking reasons/criteria.
Go to “new entries” and create.
Shipping conditions: If we specify shipping conditions for this field in the definition of the document type, while creating the sales document the system determines shipping conditions from this field only but not from the customer master.
Note: While creating the rush orders the goods must be deliver immediately to all the customers. So for all the customers in rush order the shipping conditions must be same i.e. immediately. For this reason we specify the shipping conditions as “immediately” in the definition of document type “RO” so that while creating rush order the shipping conditions will be same for all the customers which will be “immediately”.
Immediate delivery: Specifies whether the system shall automatically creates delivery the moment we save the sales document (as in the case of CS and RO) or we have to create the delivery separately (as in the case of OR).
Delivery/order-related billing type: Here we need to specify the corresponding billing type. So that the system automatically determines the billing types while creating the billing document either with to order or delivery. For example, ‘F2’ is the billing type for creating invoices with reference to order or delivery.
Note: It is not required to specify any billing data for certain sales documents like IN and QT.
Billing block: Here we can specify a required reason for blocking the sales document for billing process. While creating the sales document it will be automatically blocked the billing because of the reason specified here.
Propose delivery date: If we check this field, the system automatically proposes the current date as requested delivery date in the sales document.
Lead time in days: Specifies the no. of days into future that the system uses to propose the requested delivery date in the sales document.
Proposal for pricing date: Specifies the date that will be automatically propose as pricing date in the sales document. The system determines the pricing into sales document depending on the pricing date. By using this field we can specify whether the current date shall be proposed as pricing date or the requested delivery date shall be proposed as pricing date.
Propose PO date: If we check this field the system automatically proposes the current date as PO date in the sales document.
PO date is the date on which the customer has placed purchase order and “document date” which is in the header data is the date on which the sales order is created for that purchase order in the SAP system. The system considers document date only for tracking the data while generating the reports.
Proposed valid from date: Specifies the date that will be automatically proposed as ‘valid from’ date while creating certain sales documents like quotations.Save the sales document type.
The data that we maintain at the item level in the sales document is controlled by item category. Depending on the document in which an item is entered and depending on the item that is entered in the document the requirements may change.
Example-1: The same item has to be processed in different ways in different sales documents. For example, if a standard item is entered in quotation (QT) it is not relevant for shipping (SH) and billing (BL) but relevant for pricing. If the same material is processed in sales order (OR) it is relevant for shipping, billing and pricing.
Example-2: The same item has to be processed in different ways in the same document. For example, if we offer free goods for an item, the main quantity has to be priced but not the free goods quantity even though the material is same.
Order
Example-3: Different items are to be processed in different ways in a sales document. For example, if we enter a third-party item in the sales order the system shall automatically create a purchase requisition which is not required for a standard item.
To full-fill all such sales requirements we need to define different item categories with the corresponding functionalities and make sure that the system automatically determines an appropriate item category for the items during the sales document processing (assigning item categories).
So, every item entered in a sales document will have an item category and that item will be processed as per the functionality maintained for that item category.
Defining item categories:
Path: SPROàsales and distributionàsalesàsales documentsàsales document itemàdefine item categories.
Example:
Standard item
AFN-Inquiry.
AGN-Quotation.
TAN-Order.
Free good item
AFNN-Inquiry.
AGNN-Quotation.
TANN-Order.
TAS-Third party item.
Completion rule: Specifies whether the status of a quotation or contract item is completed. For example, we can specify that the status of a quotation item is completed if the entire quantity is referenced or the status of the item is completed with the 1st reference itself or we can also specify that it is not relevant for completion.
If it is not relevant for completion, for a quotation item we can create multiple sales orders irrespective of the quantity.
Billing reference: Specifies whether the item is relevant for billing or not. If it is relevant for billing it also specifies the reference document for creating the billing document. i.e., we shall specify whether the billing document has to be created with reference to sales order or with reference to delivery document etc.
Note: Certain items in inquiry and quotation are not relevant for billing document. So the corresponding item categories AGN and AFN are not relevant for billing. But the item category TAN used in sales order must be relevant for billing.
Billing block: Here we can specify the reason for which the item shall be blocked for billing process.
Note: If we specify the billing block for the sales document types, all the items in that document will be blocked for billing. Whereas if we specify the billing block in the item category, that particular item in the document using this item category will be blocked for billing.
Pricing: Specifies whether the item is relevant for pricing or not. If we specify the value ‘X’ the item becomes relevant for pricing. For all the item categories used for standard item in different documents we shall specify the value ‘X’ for this field.
For a free good item we shall specify the value ‘B’ which specifies that it is also relevant for pricing but give 100% discount on the net price to make the net value of the item as zero.
Business item: If we check this field, the business data at item level is allowed to differ from the business data at header level in the sales document.
Note:
Any information related to sales, shipping and billing is called business data.
The business data of a return item shall not be changed. For this we shall not check this field in the item category of return item.
Schedule line allowed: Specifies whether we can have the schedule line data in the sales document.
Note: Certain items such as the items in credit memo request (CR) should not have schedule line data. For this we shall not check this field in that corresponding item category ‘G2N’.
Item relevant for delivery: Specifies whether the text item is relevant for delivery.
To make the text item as relevant for delivery, we shall check this field in that corresponding item category “TATX”. We need to make the item category ‘TATX’ as text item by specifying the value ‘B’ (text item) for the field “item type”.
If we leave field “item type” blank it becomes standard item.
Returns: If we check this field, the item becomes a returns item.
Note:
Weight/volume relevant: If we check this field the weight and volume of the item will be determined into sales document from the corresponding material master record.
Note: In the sales document the weight and volume of the item will be displayed on the shipping tab page in the corresponding item data.
Credit active: Specifies whether the item is relevant for credit management activities.
Note: The items processed in the sales order are relevant for credit sale. For this we shall check this field in that corresponding item category ‘TAN’. But the items processed in the cash sales transaction are not relevant for credit management activities. For this we must not check this field in that corresponding item category ‘BVN’.
Determine cost: If we check this field, the cost of the item will be determined during pricing in the sales document. The system displays the cost of the item in the sales document by using the condition type ‘VPRS’.
Automatic batch determination: If we check this field, the system automatically determines the corresponding batch no. for the item in the sales document.
Rounding permitted: If we check this field, the order quantity of the item will be rounded depending on the rounding profile specified in the master record.
Note: For certain items like free good items and return items the order quantity shall not be rounded. For this we must not check this field in those item categories.
Order quantity=1: If we check this field, the order quantity for each line item will be limited to one.
Incompletion procedure: Specifies which fields are mandatory in the sales document at item level.
Partner determination procedure: Specifies the corresponding partner determination procedure in order to get the partner functions into sales document at item level.
Note: As we have configured partner determination procedure to get the partner functions into customer master record, in the same way we shall also configured the partner determination procedure to get the partner functions into sales document at header level and item level. The standard procedure to get the partner functions for sales document header is ‘TA’ and for the sales document item is ‘N’. To configure these procedure go to;
Path: SPRO--->sales and distribution --->basic functions---> partner determination --->setup partner determination.
Setup partner determination for sales document header.
Here we have to configure the partner determination procedure and assign it to the sales document type to get the partner functions at header level in the sales document.
Setup partner determination for sales document item.
Here we shall configure the procedure and assign it to the item category to get the partner functions at item level in the sales document.
Text determination procedure: Specifies the corresponding text determination procedure to determine the text at item level in the sales document
Item category determination: During the sales document processing the system automatically determines a corresponding item category for the items. For this we have to configure item category determination where we have to assign the item category to a given combination of fields. For this assignment, go to;
Path: SPRO--->sales and distribution--->sales--->sales documents--->sales document item--->assign item categories.
| Sales document type | Item category group | Usage | Higher level item category | Default item category |
| IN | NORM | - | - | AFN |
| IN | NORM | - | AFN | AFNN |
| QT | NORM | - | - | AGN |
| QT | NORM | - | AGN | AGNN |
| OR | NORM | - | - | TAN |
| OR | NORM | - | TAN | TANN |
| CS | NORM | - | - | BVN |
| CS | NORM | - | BVN | BVNN |
| RE | NORM | - | - | REN |
| RE | NORM | - | REN | RENN |
| CR | NORM | - | - | G2N |
| DR | NORM | - | - | L2N |
| RO | NORM | - | - | TAN |
| OR | BANS | - | - | TAS |
If require we can define our own item category groups. For this, go to;
Path: SPROàsales and distributionàsalesàsales documentsàsales document itemàdefine item categoriesàdefine item category groups.
Example for item category assignment:
Sales document types:
ZIN: document category is ‘C’ (Sales order).
ZQT: document category is ‘A’ (Inquiry).
ZOR: document category is ‘B’ (Quotation).
Item categories:
ZAFN: Relevant for ‘completion rule’.
Not relevant for ‘billing’.
(Free good item category is ‘ZAFNN’).
ZAGN: Not relevant for ‘completion rule’.
Relevant for ‘billing’.
(Free good item category is ‘ZAGNN’).
ZTAN: Not relevant for ‘completion rule’.
Not relevant for ‘billing’.
(Free good item category is ‘ZTANN’).
| Sales document type | Item category group | Usage | Higher level item category | Default item category |
| ZQT | NORM | - | - | ZTAN |
| ZQT | NORM | - | ZTAN | ZTANN |
| ZOR | NORM | - | - | ZAFN |
| ZOR | NORM | - | ZAFN | ZAFNN |
| ZIN | NORM | - | - | ZAGN |
| ZIN | NORM | - | ZAGN | ZAGNN |
Note: During the item category determination whatever the item category that is assigned as “manual item category”, with that we can replace the default item category in the sales document.
The data at schedule line level in the sales document is controlled by schedule line category. Depending on the requirement we shall define different schedule line categories with the corresponding functionalities to be used for different sales documents.
Defining schedule line categories:
Path: SPROàsales and distributionàsalesàsales documentsàschedule lineàdefine schedule line categories.
Example:
AT-inquiry schedule line category.
BM-quotation schedule line category.
CN, CP, CV-sales order schedule line categories.
DN-returns schedule line category.
Functionality of schedule line categories:
Delivery block: By using this field we can block a delivery block for the particular item in the sales document by using this schedule line category.
Movement type: Specifies the logical or physical movements of materials leading to a change in the stock level or resulting in the consumption of the material. i.e., with the help of movement type the SAP system understands whether the stock of the material has to be increased or decreased during the business transaction.
SAP has already provided different movement types to be used in different business transactions where each movement type has its own effect on the inventory of the material.
Examples:
This movement type will reduce the stock of the material when the sale of the material is taking place.
These two movement types are used for taking back the stock from the customer (returns). If we use the movement type 651 the stock will be updated under the “restricted use” in the plant. So that it cannot be used for sales. Certain materials like damages can be taken back from the customer with the movement type 651. Where as if we take back the material with the movement type 653, the stock will be updated under “unrestricted use” in the plant. So that it can be used for sales.
If we take back the material with this movement type, the stock will be updated in the plant as quality inspection stock.
Item relevant for delivery: Specifies whether the item is relevant for delivery or not. For example, certain items such as in inquiry and quotation are not relevant for delivery. For this we must not check this field in those corresponding schedule line categories ‘AT’ and ‘BN’ respectively. But the items in sales order and returns order etc are relevant for delivery. For this we shall check this field in those corresponding schedule line categories.
Order type: Specifies the document type ‘NB’ for creating the purchase requisition. We shall specify the document type ‘NB’ for this field to create the purchase requisition for the third-party item. For this the schedule line category is ‘CS’. In the definition of schedule line category ‘CS’, we have to specify the value ‘5’ (third-party) for the field item category which specifies that the stock of the third-party item will not be affected as the third-party item is directly delivered to the customer by the vendor.
Incompletion procedure: Specifies which fields are mandatory at schedule line level in the sales document.
Requirements/assembly: If we check this field, the requirement order quantities will be transferred from sales and distribution to inventory management. So that the inventory people can plan the material by the date requested by the customer.
Note: It is not required to transfer the requirements from certain sales documents like inquiry, quotation and returns order. For this we shall not check this field in those corresponding schedule line categories.
Availability: If we check this field, the system carries out the availability check for the material in the sales document.
Note: It is not required to carry out the availability check for the returns item. For this we shall not check this field in that corresponding schedule line category ‘DN’.
Product allocation: If we check this field, the product allocation (stock reservation) will be activated for the items when we save the sales document.Save the schedule line category.
Schedule line category determination: During the sales document processing the system can automatically determine a corresponding schedule line category for the items. For this we have to configure the schedule line category determination where we have to assign the schedule line category to a given combination of fields. For this assignment, go to;
Path: SPRO--->sales and distributionàsales--->sales documentsàschedule lines--->assign schedule line categories.
Go to “new entries” and assign the schedule line category to the combination of “item category” and “MRP type”.
Example:
| M-10(NORM) | M-11(NORM) |
| (TAN) | (TAN) |
| MRP TYPE : VV | MRP TYPE : ND |
| (Forecast based planning) | (No planning) |
| Availability Check | No Availability Check |
| Transfer of requirements | Transfer of requirements |
| Schedule line category : CP | Schedule line category : CN |
Material: M-10 (standard item):
Item category is ‘TAN’.
For this material MRP type is ‘VV’ (forecast based planning) which means that while creating the sales order availability check shall be taking place and requirements must be transferred to inventory management. For this, we shall define a schedule category ‘CP’ in which we shall check the fields “requirements/assembly” and “availability”.
Material: M-11 (standard item):
Item category is ‘TAN’.
MRP type is ‘ND’ (no planning) which means that the material is manufactured after receiving the order only. So while creating the sales order no need to check the availability of that material but the requirements shall be transferred to inventory management for the production of the material. For this, we shall define a schedule line category ‘CV’ in which we shall check the fields “requirements/assembly” but shall not check the field “availability”.
While creating the sales order for m-10 the system shall determine the schedule line category ‘CP’ whereas it shall determine ‘CV’ for m-11. For this the following category determination must be done.
| Item category | MRP type | Schedule line category |
| TAN | VV | CP(CF) |
| TAN | ND | CV(CK) |
Note: During the schedule line category determination whatever the schedule line category that is assigned as “manual schedule line category”, with that we can replace the default schedule line category in the sales document.
For In-depth knowledge on SAP SD click on:
You liked the article?
Like: 0
Vote for difficulty
Current difficulty (Avg): Medium
TekSlate is the best online training provider in delivering world-class IT skills to individuals and corporates from all parts of the globe. We are proven experts in accumulating every need of an IT skills upgrade aspirant and have delivered excellent services. We aim to bring you all the essentials to learn and master new technologies in the market with our articles, blogs, and videos. Build your career success with us, enhancing most in-demand skills in the market.
