Sales Documents

Concept of Sales Document
When a customer places an order for goods or services in an organisation the organisation creates a sales order. This sales order is called a sales document in the SD Module. Example: When we visit a showroom for purchasing a refrigerator we select a specific model and pay for it. When we pay for it the refrigerator details like model no. , colour, manufacturer, and price are specified in the document. Such a document containing details of a sold product is a sales document. In SD module a sales document is very important because the processing of various other documents such as invoice, delivery depends on it.

Sales Order Process
A sales order is a sales document or agreement which is created when a customer places an order in an organisation to receive goods or services. The process of extracting the relevant details from customer and material master records and creating a sales order is known as sales order process. Manually specifying there details in sales order is lengthy and time consuming.

Common Sales document types
A sales document type helps identify various business processes. Common sales doc types include : 
    

Standard Order(SO) Returns (RE) Free of Charge Delivery (FD) Credit Memo Debit Memo Quotation

Content of Sales document
Header Level 
  

Represents header of sales document Stores data related to customer,material,sales area and organisation Information specified at the header level is stored in the VBAK system table Entire sales document is affected if any changes made at this level

Item Level 
Represents information about material or item e.g. order qty.  Stores data related material  Information specified at the item level is stored in the VBAP system table

Schedule Level 
Represents date, time and quantity to be delivered to a customer.  Information specified at the schedule line level is stored in the VBEP system table

Sales Document Header
Sales Doc Type : Specifies the functionality of a sales document. e.g. free of charge delivery & return delivery specify different functionalities of a sales document. 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. The reason 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. We can define sales doc type in two ways : i. creating a new sales doc type ii. copying & modifying an existing sales doc type

Document Category : Indicates to the system the type of document e.g. Document category C indicates to the system that it is a sales order instead of quote. Specifies a classification for different types of document that we can process in sales and distribution system. The document category determines how the system stores, keeps track of document data. Ex: A-Inquiry, B-Quotation, C-order The only document categories possible are
y y y y y y y y y y

Inquiry Quotation Order Item Proposal Scheduling Agreement Scheduling Agreement with External Service Contract Returns Order without Charge Credit Memo Request

y y y

Debit Memo Request Independent Requirements plan Master Contract

Document Block : Blocks the document for processing but can be used by the business Note: If a sales doc type is blocked the user cannot create new sales document of that type, but sales doc already created before setting the block can be changed or displayed. 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 System Internal & External Number Range : Specifies the number ranges with the help of which either the system (if it is internal) or the user (if it is external) can give a number for the sales doc.

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 No. Increment : Indicates the increase in the items in the sales order e.g. items in sales order may increase in increment of 10

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 thereafter. Sub item Increment : Indicates the increase in the sub-items in the sales order Note: If we do not specify any value here the sub-item number increment as the main item.

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 : Indicates whether it is mandatory to create the doc with reference to any other document .The indicator also specifies which type of document should be used as reference. e.g. Sales order created with reference to quotation The possible values are With reference to inquiry With reference to Quotation With reference to Sales Order Scheduling Agreement Reference With reference to Quantity Contract With reference to Billing Document Item division : If we check this field the division ate item level in the sales document will be determined from corresponding material master record, otherwise the division entered at Header level applies for all the items in the sales document. Check division: Specifies whether and how the system reacts if the division at the item level differs from the division at header level during sales document processing Ex: we can block some divisions for a customer. 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 Allows materials of a different division at the line item level compared to the header level division

Error/ Dialog This option will force the system to respond with either an error or a warning when a different division is entered.

Read info record : If we check this field then only the system considers customer material info record. Check PO number: Specifies whether the system checks if the PO number exists for other sales document. 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.
y

Create a sales order with PO # = "Bulk Order 123" for customer 1400.

y

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. Check credit limit: Specifies whether the system carries out credit limit check for the customers during sales document processing. This field signifies what kind of credit check need to be used for this kind of sales document. Credit Group : This field is almost always set to 01 for all sales documents.

Transaction Flow

Document Pricing Procedure: This field along with the customer pricing procedure plus the relevant sales

area determines the Pricing Procedure to be used.

Screen Sequence Group : controls the way data is displayed and in what sequence

Display Range : Determines what items in the sales order are displayed e.g. all items or only the header items for a BOM. Function Code for overview screen : It is the function code that determines what data and layout we see in the sales order e.g. item overview or item detail.

Quotation Messages : 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 lists of open quotations are displayed. 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.

Message master contract : Checks or determines if any master contracts exist while creating a a sales doc type contract . Product Attribute Messages: system warns to check manually entered products for the attributes. This is done to see if the ship to party accepts them. In case of automatic material entry such as in case of material determination, this check is ignored. 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 constraint are fulfilled, the s order type can be changed. The configuration for the same is to have ZOR and ZTA as the alternative document types 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.

Shipping

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.

Immediate Delivery : Consider 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)

Shipping Conditions : The shipping conditions are proposed by the customer master record. If any entry existed in this field here then this entry would be considered and would have overwritten those in the customer master record. The shipping condition value is used to determine the shipping point. Billing Dlv-rel billing type : This indicates that the document is relevant for invoicing and for delivery related invoicing, the system automatically uses billing doc. type as F2 Order-rel bill type : When an order-related invoice is possible the system will automatically use billing doc. type F2. This happens when we wish the order relevant and delivery relevant products to be invoiced at the same time. Billing Block : There is no automatic posting of a billing block on the sales order. Billing block indicates that the order cannot be billed until the block is removed. It is a safety feature. For example we may have a background job that creates invoices. When the order is saved, this background job will see the order and then invoice it if it is for order related billing. Using the billing block will prevent this from happening until the order has been checked and the billing block explicitly removed. Billing Plan Type : It is either periodic billing, where the entire value to be billed till date is billed in full on the billing plan date(e.g. rent agreement) or milestone billing, where the total value to be billed is distributed between the individual billing plan dates(e.g. for a on project based on project milestones, where the value billed on each date can be a fixed amt. or a percentage) Payment Guarantee Proc : Indicates to the system what form of guarantee procedure to use in this sales doc.(refer to credit management) Payment Card plan : It is essential setting if we want the system to accept payment cards in the sales order process. Checking group: Used to determine how the system carries out the checking of payment card data.

Settings affecting the requested delivery date Lead Time in days : It is the requested delivery date in the sales order. It is usually left as a zero in most instances. Propose delivery date : checked to propose the current date as the delivery date. Date type : allows the user to set the format of the delivery schedule line date for internal system use e.g. date, week, month, etc. Proposal for pricing date : Allows us to specify the valid-from date for the pricing of the reference document, or the requested delivery date or the current date. Propose PO Date : proposes current date as the purchase order date

Assignment of Sales Areas to Sales Doc.
If the sales doc. types created are permitted to be used by all sales areas, there is no need to create settings. However we may need to assign sales doc type to specific sales areas in some cases e.g. if a unique sales doc. type is used for all sales orders from a specific sales org.

Creating Order Reasons for Sales Doc.
Order reasons are the reasons why a customer is purchasing or using a sales document.This is helpful in determining the trigger which creates the sales order which if further helpful in analysis. The order reasons can be sales call , good price , or in case of returns they can de poor quality or damaged material .

Sales Order Item Categories
An organisation divides its good & services into various categories, such as free of charge items or discounted items. These categories under which the items are placed are known as item categories. SAP ERP provides various standard item categories. We can use a single item category for multiple sales documents depending on sales doc. types. Defining an Item Category An item category can be defined by either 
defining new item category  copying & modifying existing item category

Unlike the sales doc type which is entered manually into the sales order at order creation, the item category is automatically determined by the system. It is then able to be changed manually in the sales document, if required.

Business Data Item type - controlling indicator to the system. This field is left blank for standard items. Completion rule used to determine when the item is deemed to be complete. For standard processing this is left blank Special stock indicator set for items that are processed as special stock. e.g. if we use consignment stock at customer s site, the indicator reads W. For standard processing, it is left blank. Billing relevance works with billing doc. type to if this item is relevant for delivery-related or orderrelated billing. Thus is we set this as A then this means that this item is relevant for delivery-related billing. Items that don t have a delivery will use order-related billing. Billing plan type defines if the item does milestone or periodic billing. Pricing Indicator used by the system to propose if this item is relevant for pricing. e.g. text item is not relevant for pricing. Statistical Value - used if we want to calculate the total values of all items at the header level but at the same time

Sign up to vote on this title
UsefulNot useful