Chapter 7: Sales

The sales application in SAP SD deals with the business process involved with selling goods and services to the customer. A sales document is a vital component of the sales application that records and processes information related to a sales transaction and also marks the beginning of a sales cycle in the SAP system.

In Chapter 1, “Introduction to Sales and Distribution,” you saw a brief overview of the sales cycle and experienced the look and feel of a sales document. In this chapter, we will discuss in detail sales documents, including their use in the SAP system, how they are structured, and how to configure and control them from a sales transaction perspective. We will also briefly touch upon the various sales document types that are available in the standard SAP system, including inquiries, quotations, orders, debit/credit notes, and contracts, to name a few.

Sales Documents

In SAP, the sales cycle begins with the creation of a sales document. The sales document stores and processes the sales-related data and controls the overall processing of the sales transaction. When you receive an order from the customer, the information contained in that physical customer order—such as ordered goods or services, ordered quantity, shipping location, delivery date, and so on—is all stored in a sales document. This sales document then forms the basis for carrying out subsequent SD process steps such as delivery, billing, and accounting postings.

In SAP, sales document is a generic term. You can use a sales document to store and initiate processing for inquiries, quotations, sales orders, contracts, credit/debit notes, invoice corrections, free-of-charge delivery, and other similar sales processes that a user in the sales function deals with on a day-to-day basis. Each of these processes is identified and controlled using a specific sales document type in SAP; for instance, document type AF is for inquiries, AQ is for quotations, and OR is for standard orders.

Each sales document in SAP is assigned a unique document number that can be set internally by the SAP system or externally by the user or interface program that is electronically creating the sales order in the SAP system. You can set up incompletion checks in a sales document to ensure the user enters the data entry completely and to also stop the processing of subsequent steps if the document is found to be incomplete. Status management in the SAP system documents the current status of the object and also controls what subsequent process step may be carried out next. While processing a sales document, SAP also carries out various basic functions such as pricing, taxation, partner determination, availability check, output determination, and so on, which we’ve already discussed in previous chapters.

You can create, change, delete, and reject these sales documents in SAP. You can also create a sales document electronically using the ALE, IDOC, EDI, and BAPI technologies provided by SAP. We discuss these technologies in Chapter 14, “Advanced Techniques.”

Structure of a Sales Document

The structure of a sales document has three parts: a header structure that holds the information applicable to the whole document, an item structure that holds the information specific to an item, and a schedule line that stores the delivery schedule for the item. Data at the header level is valid for all the items. A sales document can have one header and one or multiple line items, and each line item further can have one or multiple schedule lines, as shown in Figure 7-1.

Origin of Data in a Sales Document

Apart from the data that you entered manually or that came via an interface program, data in a sales document originates from a variety of other sources:

From master data to sales document When you create a sales document, a majority of information required by the sales order is automatically derived by SAP from the master records of the customer and material number you provided on the sales document detail screen. Information derivation from the sold-to party master data includes pricing, shipping conditions, Inco terms, and so on. Information specific to the shipping location and taxation is pulled out from the ship-to party master, and information specific to the payment terms and credit checks is pulled from the payer master record. When the sold-to party performs all four partner functions for a sales document, all the partner-related data is pulled from the sold-to party master record. Information from the material master includes the delivery plant, weights, delivery priority information, and so on. Some miscellaneous information is also derived from various other master records such as the pricing master, customer–material info masters, output masters, and so on, based on the combination of customer and material numbers.

From document header to document item Data for document items originates from the document header. Once copied from the header to the items in a document, this data can be manually changed in the sales document. In such a case, the manually entered data takes precedence over the automatically derived data. For example, say you have an initial customer order received with a requested delivery date of 03/09/09 for all three items; with the standard SAP system behavior, the date 03/09/09 is copied from the sales document header to all the items. But then say customer later sends a request to deliver item 20 by 04/09/09, keeping the schedule for item 10 and 30 intact. To incorporate this request, you manually change the requested delivery date at the item level for item 20 to 04/09/09. This manual change now takes precedence over the requested delivery date initially copied from the header data. So, the header data and items 10 and 30 show the requested delivery date as 03/09/09, and item 20 has a requested delivery date of 04/09/09.

From source document to target document In SAP, data originated in the source document is copied to the target document. For example, when you create a sales order with reference to a quotation, SAP copies the data from the quotation document to the sales order. In this case, SAP will not do any derivation of data from the master records, and data copied from the quotation will be final. So, any changes made to the master data after creating the quotation will not be copied on to the sales order because the data for the sales order is copied from the quotation document that still contains the old information.

From customization settings to sales document SAP copies the defaults defined in the customization settings to the sales documents. Values such as the default billing type and the default delivery type are copied to the sales document so that SAP can use these defaults to perform the subsequent steps without any user intervention. This makes the process more automated.

Customizing Sales Documents

A sales document is controlled via its customization settings. The customization of a sales document involves the following steps:

In the following sections, we’ll cover each of these steps in detail.

Defining Sales Document Types

The first step in sales document customization is to define the sales document types that meet your business requirements. A sales document type in the SAP system helps you differentiate one kind of sales document from another. Whether a sales document is an inquiry, a quotation, a sales order, or any other kind of sales document, you can identify each one exclusively based on its document type. In the customization of a sales document type, you can define various settings that not only control the overall behavior of the sales document but also impact the subsequent process steps, such as delivery and billing.

To customize a sales document type, you can use the transaction code VOV8 or follow the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Header ⇒ Define Sales Document Types. For discussion purposes, we will be breaking the customization screen into multiple screenshots and will discuss in detail all the important fields on the customization screen. During this discussion, we will be using document type OR – Standard Order for analyzing the various settings on the customization screen. Let’s start with the General Control and Number Systems sections of the customization screen, as shown in Figure 7-2.

General Controls and Number Systems

In these sections of the screen, you define all the generic control settings required for your sales document type:

Sales Document Type This field represents the identifier and description for your sales document type. You can define your own sales document type by providing an identifier key that is a maximum of four characters, along with a meaningful description. In Figure 7-2, OR stands for the document type, and Standard Order is the description for the document type OR.

Sales Document Category The field SD Document Categ. classifies sales documents into various categories and enables the SAP system to provide status information about delivery and billing processing for the sales document. When you create your sales document via the copy with reference option, this category field enables the SAP system to provide the status information about the reference documents. You can use document category A for inquiries, B for quotations, C for orders, D for item proposals, E and F for scheduling agreements, G for contracts, H for returns, K for credit memo requests, and L for debit memo requests.

Sales Document Block When you select this field for a sales document type, the sales document type is blocked for further use and is no longer visible in the list of available document types for processing with sales document create transactions, such as VA01, for example. This is useful in situations where your document type has become obsolete and you don’t want the user to use it for transactional document creation by mistake. Always remember that once blocked in customizing, you cannot use that document type for creating new transactional documents, but the existing transactional documents can still be processed.

You can also use this field to mark a document type as relevant for automatic processing only. When you do so, the document type is no longer available for manual processing via maintenance transactions provided by SAP (VA01, for example). Rebate processing is one example where you do use this setting. Refer to Chapter 9, “Billing,” for more details on rebate processing.

You can make one of the following selections for this field:

• Leave the field blank if you do not want to block your sales document type.
• Select X when you want to block the document type.
• Select A to make the document available for automatic processing only.

Internal and external number range assignment In SAP, you control the document numbering for your sales document using a two-character number range key. When customizing this key, you specify the starting number and the ending number for the number range that then controls the document numbering for your sales document.

In Figure 7-2, value 01 in field No.Range Int.Assgt. represents the internal number range that the SAP system will use to assign the document numbering to your sales document. Similarly, the value 02 in the field No. Range Ext.Assg. will control the document numbering for your sales document when the number is assigned externally by the user or the interface program that is creating the sales order. You can define a number range for your document type by using transaction code VN01 or by following the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Header ⇒ Define Number Range For Sales Documents.

Item No. Increment Here you define the increments for an item number for your sales document. So if you set up an item increment as 10, then the first line in the sales document will have item 10, the second line will have item 20, and so on. Keeping a gap in item numbers is always good practice because it gives you some flexibility to insert a new line between two existing line items in a sales document.

Sub-item Increment The subitem concept exists for structured materials such as a bill of materials (BOM). A BOM allows you to process materials in a specified structure. For example, a computer can be sold as one piece or as multiple parts separately. When you sell it as one piece, you define a BOM to set up the main piece of the item as a computer, with a mouse, keyboard, CPU, monitor screen, and so on, as subitems of that main piece. When you create a sales order, you enter the BOM for the computer as a material in the sales order. This BOM automatically explodes into multiple lines of individual materials to be delivered. What item numbers these subitems get depends upon what setting you made when customizing for the subitems increment. As per the increment value shown in Figure 7-2 for subitems, each subitem will have an increment of 1.

Reference Mandatory Make a selection in this field if you want to create a document for your document type only by copying it from an existing document. For example, if your requirement says that a sales order can be created only with reference to a quotation document, you can choose B here for quotation to put this restriction on your sales order document type.

You can set up the SAP system to create a new sales document with reference to the following:

• A: An inquiry
• B: A quotation
• C: A sales order
• E: A scheduling agreement
• G: A contract
• M: A billing document

Remember that a selection in this field will only make it compulsory for the document to refer to an existing document. For the actual flow of data between the two documents, you also need to define the copy control between the documents.

Material Entry Type This field defines the expected input value for the material field during the sales order entry. When you select B in this field, SAP expects you to enter a material number and product catalog combination as a valid input for creating the sales order. Select A, and the SAP expectation changes to the material order number and product catalog combination. Keep the value in this field as blank if you are not working with product catalogs.

Item Division The Item Division check box is like an on/off switch that controls whether the division for an item in the sales order should originate from the material master or from the document header. When selected, it allows the item division to be copied from the material master data. If left unchecked, the item division is copied from the sales document header.

Check Division The Check Division field checks whether the division at the document header is different from the document items. The following options are available:

• Leave the field blank: Different divisions between the header and the items are allowed without any message to the user.
• Select 1: Divisions can be different, but a warning message is issued.
• Select 2: Divisions cannot be different, and an error message is issued.

Probability You use order probability to measure the success rate of a presales process. For example, you use the probability percentage to measure the possibility of a quotation converting into an order. In SAP, the probability is allowed for the inquiry and quotation document categories only. The expected order value is calculated as the net value of the line item multiplied by the probability rate for that line item divided by the total net value for all the line items in the quotation. So, for a quotation containing two items, one for $100 with a 40 percent probability and the other for $100 with a 60 percent probability, the total order value equals $200, but the expected order value equals $100. In other words:

(100 × 40% + 100 × 60%) ÷ 200

Read Info Record This check box controls the copying over of the customer-specific material description from the customer–material info record to the subsequent sales document. When selected in customizing for a document type, the customer–material info record gets copied to documents for that document type. We’ll cover customer–material info records in detail in Chapter 12, “Material Determination, Listing, Exclusions and Proposals.

Check Credit Limit This field helps you activate/deactivate credit checks for your document type. The available options are as follows:

• Blank: Select this if you do not want to run a credit check on your sales document type.
• A: This runs a simple credit check with a warning message displayed when a credit check for the document fails.
• B: This runs a simple credit check with an error message displayed when a credit check for the document fails.
• C: This runs a simple credit check and blocks the delivery for the sales document if the credit check for the document fails.
• D: This runs a rule-based automatic credit check. The value D in this field in Figure 7-2 represents that OR is using automatic credit checks.

We will cover credit checks and related settings in more detail in Chapter 11, “Credit Management.”

Credit Group In the standard SAP system, you can carry out the credit check at the sales order level and the delivery level and also while performing the goods issue step for your delivery. A credit group in the SAP system represents these levels. There are three credit groups available in standard SAP:

• 01 for sales orders
• 02 for deliveries
• 03 for goods issue

If you want to carry out credit checks, you need to assign your document type to its relevant category. For sales orders, the credit group is always 01. Refer to Chapter 11 for more details on credit checks and related customization settings.

Check Purchase Order Number The purpose of this field is to check for duplicate purchase order (PO) numbers during sales order entry. When you select A in this field, SAP gives a warning message during sales order creation if another sales document for same customer with the same PO number exists already. Leave this field blank if you do not want SAP to check for duplicate PO numbers.

Enter Purchase Order Number When you select this box in customizing for your document type, SAP enters the sales document number in the PO number field, provided that this field is blank when the document is saved. This is useful for scenarios such as return material authorization (RMA) wherein you would like to save your sales document number of the RMA document type in the PO field as a reference to be provided to the customer. The customer will use this number as a reference number for all their communications related to that specific RMA transaction.

Output Application An output application is a two-character identifier that controls the overall processing of output at the application level. If you want to carry out output determination for your sales document, then apart from the customization settings that you defined in Chapter 4, “Partner, Text, and Output Determination,” you also need to assign your document type to its relevant output application. For sales documents, the output application is V1.

Commitment Date Commitment dates are relevant for when your customer contracts have certain obligatory delivery dates to be met. This situation can exist most commonly in customer make-to-order production where there might be bottlenecks and you want SAP to give a commitment date in addition to a confirmed date and quantity. Select an entry in this field when you want SAP to calculate a commitment date for your sales document type.

Transaction Flow

Figure 7-3 represents the Transaction Flow section of the sales document type customization screen. Here you can customize the look and feel of the order entry screen, define the screen sequencing, and define the various transactional flow–related settings for your sales document. We’ll now give you a detailed look at the various fields on this screen.

Screen Sequence Group A data entry screen that you use for a contract document might not be relevant for a sales order, and vice versa. Therefore, based on the individual needs of the sales document categories, SAP has grouped the screens into various screen sequence groups. By choosing a screen sequence group for your document type in the field Screen Sequence Grp., you tell SAP what screens and fields should appear and in what sequence they should show up when you create the documents using your document type. In standard SAP, screen sequence group AG is available for inquiries and quotations, AU for sales orders, GA for credit and debit memo, KM for contracts, and RE for returns.

Display Range The value you select in this field controls which details for a structured item, such as a BOM, will be shown during the sales document display. If you choose UALL, both the main and subitems are displayed, and if you choose UHAU, only the main item is shown.

Incompletion Procedure As we mentioned earlier in this chapter, an incompletion procedure helps you check the sales document for incomplete data and stops the further processing steps such as delivery, billing, and so on, for the sales document, until the data in the sales document is complete. In Figure 7-3, value 11 in field Incompl.Proced. represents the two-character identifier for the incompletion procedure that is assigned to order type OR. Incompletion procedure customization and its assignment are explained in detail later in this chapter.

FCode For Overview Screen The selection made in the field FCode For Overv.Scr. tells SAP which overview screen to display first when you are processing a sales document. You have a choice to select either general overview (UER1), item overview (UER2), and ordering party overview (UBST).

Transaction Group There are six different transaction codes to process the six different varieties of sales documents in SAP, as shown in Table 7-1.

Table 7-1: Relationship Between Transaction Codes and Transaction Groups

Transaction Code	Transaction Group	Document Type
VA01, VA02, VA03	0	Sales orders
VA11, VA12, VA13	1	Inquiries
VA21, VA22, VA23	2	Quotations
VA31, VA32, VA33	3	Scheduling agreements
VA41, VA42, VA43	4	Contracts
VA51, VA52, VA53	5	Item proposals

Which transaction code to use for processing your document type will depend on what transaction group you choose while configuring your document type. So if you are configuring a sales document, make sure that you select 0 as the transaction group for your document type to process with transaction code VA01-VA03. Apart from this, the transaction group also controls updating the reporting indices in tables TINPA (Business Partner Index) and TVIND (Material & Validity Index).

Quotation Messages/Outline Agrmt Mess./Message: Mast.Contr./ProdAttr. Messages The purpose of these fields is to provide a message to the user during order creation if any open quotation, outline agreement, master contract, or product attributes exists. The available choices in these fields are self-explanatory.

Document Pricing Procedure In the field Doc. Pric. Procedure, you choose which document pricing procedure key to assign to your document type. The key you assign here will be one of the factors determining the pricing procedure for your sales document. At this point, if you feel the need for a quick revision/recall on the pricing procedure and its determination-related concepts, please refer to Chapter 5, “Pricing and Tax Determination.”

Status Profile In this field, you assign the default status profile for your document type. Using the status profile, you can define your own status management for a sales document or individual line items of a sales document. Suppose you want to set up a small workflow for your sales document wherein your sales document should be under the Initial status just after creation, should be under the In Process status when it is with the approval authority for approvals, should be under the Reassign status when it is reassigned back, and finally should show the status as Released when some authorized person releases it for further processing.

In a status profile, you define the status steps (in other words, the four statuses we mentioned earlier). For each status step, you define which business function you want to allow when the document is under the said status. Thus, each status step then controls what business function is allowed and what is not. So that only an authorized person can perform the status change, each status line within a status profile is linked to an authorization code. Only the users who have this authorization code assigned to their user roles can change the status of the document. You can assign this status profile to the sales document type or an item category type to make it work for a sales document or a line item, respectively. For defining and assigning your own status profiles, follow the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Define And Assign Status Profile. Define your own status profile by providing an eight-digit alphanumeric value and maintaining the various statuses.

Alternate Sales Document Types By making a selection in the field Alt.Sales Doc. Type1, you allow the user to switch between the document types during the sales order entry. This is really helpful in a telesales scenario where the telesales representative does not know whether the prospect customer will end up placing an order or an inquiry. With a choice to switch between the document types without leaving the document creation screen, the telesales representative can keep on entering the information as they talk with the customer and can choose the document type while saving the document. You can set up two alternate sales document types when customizing for your sales document type using the fields Alt.Sales Doc. Type1 and Alt.Sales Doc. Type2. Choose the sales document type in this field that you would like to use as an alternative sales document during sales order processing.

Incompletion Messages Unlike the incompletion procedure that allows you to save the incomplete sales document but disqualifies it for further processing steps such as delivery and billing, the Incomplet.Messages check box, when selected, prevents you from even saving the incomplete sales orders. You should select this only if you want SAP to stop an incomplete sales document from getting saved that was created using your sales document type.

Variant Transaction variants consist of a sequence of screen variants and are assigned to the transaction codes. Using these variants, you can change the normal behavior of various screens called in a transaction during document processing. You can change the “ready for input” status of the fields, hide and change the table control column attributes, hide menu functions, and hide the entire screens. You define the transaction variants using transaction code SHD0. If you would like to use a transaction variant for processing your document, then provide that transaction variant here in this field, or leave this field blank so SAP will use the standard variant.

Shipping and Billing Information

In this section of customizing a sales document type, you assign default values for delivery-related and billing-related fields. SAP then uses these defaults (as shown in Figure 7-4) while performing the subsequent steps of shipping and billing for your sales document.

Delivery Type Delivery Type here represents the delivery document type that you would like SAP to use while creating a delivery for your document. Choose a default delivery type only when your document is relevant for delivery. Leave this field blank if your sales document is not relevant for delivery such as with an inquiry, quotation, debit, or credit note request or any service-related billings. For document type OR, SAP uses delivery document LF.

Delivery Block When you make a selection in this field, SAP prevents your sales document from getting delivered until an authorized person checks the documents and releases them from the delivery block. For example, in case of free-of-charge deliveries, you might want to make someone responsible to validate and justify the reasons for free-of-charge delivery before the actual delivery happens. Delivery block customization is discussed in detail later in this chapter.

Shipping Conditions Make a selection in this field if you would like to copy the default shipping condition from the document type customization to your sales document. SAP copies shipping conditions from the customer master to the sales documents, but when you define a default in the sales document type, that default takes precedence over the customer master shipping condition.

Immediate Delivery When you make a selection in this field, SAP creates the delivery for your document immediately on saving the document. In the standard SAP system, this setting is generally used for cash sales and rush orders. You can select from the following available options:

• Select A for immediate deliveries.
• Select X for immediate deliveries only for confirmed quantity line items.
• Leave the field blank if you do not want to create immediate deliveries.

Dlv-Rel.Billing Type The SAP system will use the billing document type you enter in this field as a default billing document type when creating billings for your sales document type for delivery-relevant billing scenarios. A delivery-relevant billing refers to those scenarios where the sales cycle involves creating a delivery document before creating a billing document.

Order-Rel.Bill.Type Here you enter the default order-relevant billing document type that you want to use to bill your sales document. An order-relevant billing refers to a billing document created directly from a sales order without involving a delivery step in between. This refers to service billing orders and debit/credit note processes.

Intercomp.Bill.Type Here you enter the default intercompany billing document type that you want to use to bill your sales document in an intercompany scenario. An intercompany billing document records the sales transaction happening between the two companies of the same group.

Billing Block The purpose of this field is to block your sales document from getting billed. Make a selection in this field only when you want to prevent your sales document from getting billed until an authorized person checks the documents and releases them from the billing block, such as credit notes. Please note that the billing block you assign here will work at the header level and will be applicable throughout the sales document.

Billing Plan Type A billing plan controls the billing timelines and schedule of billing for periodic and milestone-based billing. In SAP, you can have a billing plan at the header level as well as at the item level. Make a selection in this field only when your sales document is either relevant for periodic billing or is a milestone billing and you want to keep the billing plan at the header level for your sales document type. For more details on billing plans, refer to Chapter 9.

Payment Guarantee Procedure A payment guarantee procedure controls the risk management settings for your sales document type. A letter of credit, bank guarantee, and export credit insurance are a few examples of risk management documents that are commonly used in foreign trade. Maintain the value in this field if your document type is relevant for risk management control.

Payment Card Plan Type and Checking Group Make a selection in these fields only when your sales document is relevant for payment cards processing. Payment cards are discussed in detail in Chapter 9. For standard orders of document type OR, SAP uses value 03 (Payment Cards) for the Payment Card Plan Type field and uses 01 (Standard) for the Checking Group field.

Requested Delivery Date/Pricing Date/Purchase Order Date

Figure 7-5 shows the set of fields from the sales document type customization screen where you maintain proposals for determining the requested delivery date, the pricing date, and the purchase order date for your sales document type. A requested delivery date is the date by which the customer expects to receive the delivery of the goods. It can be a date provided by the customer or proposed by the SAP system. A pricing date, on the other hand, helps in finding out the valid price for a sales document line item. We’ll now cover how these fields impact the determination of various dates in a sales document.

Date Type/Propose Delivery Date/Lead Time In Days These three fields control the value and display format for the requested delivery date field on the sales document:

• Date Type controls the display format of the requested delivery date. You can make selections from the list of available values and can set up the display of the requested delivery date to be a day format (day, month, year), a week format (week, year), and a month format (month, year).
• The Propose Deliv.Date check box, when selected, proposes the current system date as the requested delivery date for your sales document.
• Lead Time In Days postpones the requested delivery date by the number of days you enter in this field.

Proposal For Pricing Date The field Prop.F.Pricing Date helps in determining the pricing date for the sales document. From the list of available options, you can select A to have the pricing date equal the requested delivery date from the document header, you can select B to have the pricing date be valid from the date of the document header, you can select C to have the pricing date equal the contract start date from the document header or item, and you can leave the field blank to have the pricing date equal the current system date.

Propose PO Date Use this check box when you want to propose the current system date as the purchase order date for a sales document.

Proposal For Valid From Date The field Prop.Valid-From Date helps in determining the date value for the valid from date in the sales document. The fields on the sales document have no proposal when the value is left blank in customizing, they will be valid from today’s date when A is selected for the value in customizing, and will be valid from the date that equals the beginning of next month when the value B is selected in customizing.

The customization screen for the sales document type also contains a section for setting up contracts. We intentionally skipped that section of the customization here and will be covering that later in this chapter while discussing contracts.

Defining Item Categories

The next step in customizing a sales document is to define an item category. An item category controls the behavior of an item by controlling the various elements relevant for item processing, such as item price, delivery, ATP, transaction flow update, and so on. The customization settings that you define at the item category level determine how the item will behave within a sales document and how it will impact all the next steps in the sales document cycle.

By using customization settings for delivery relevancy, billing relevancy, and pricing relevancy in the item category setup, you can bring various flavors to an item to fit your business needs. For example, to set up an item category that should cater to free-of-charge deliveries, you can make a standard item relevant for delivery and billing but not relevant for pricing.

Standard SAP comes with a long list of predefined item categories that work for various business scenarios. You have item category AFN for document type AF (inquiry), item category AGN for document type AG (quotation), and so on. You can make use of these item categories if they match your business requirements or can create your own by copying from these standard item categories.

To define a sales item category, use transaction code VOV7 or follow menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Items ⇒ Define Item Categories. Let’s take a detailed look at the various fields shown in Figure 7-6 and their impact on line items in a sales document. For this chapter’s purposes, we will be covering the settings for standard item category TAN.

Business Data

Here you define business data for the item category. The following are the fields shown on this part of the screen:

Item Type In SAP, items are classified as text items, value items, or standard items:

Text items Text items are generally used for sending print materials such as flyers, catalogs, and so on, to the customer. These items are generally not billable to the customer and therefore are not relevant for pricing. Text items can be added directly to the sales order without requiring you to create a material master record first. In standard SAP, item category TATX is available for use with text items.

Value items SAP provides value items for scenarios where you bill your customer for a fixed lump-sum amount for the goods or services rendered. The value is fixed and does not change with changes in quantity, volume, weight, or time units associated with the material.

Standard items For all other scenarios, you use standard items in SAP. The pricing for a standard item takes into consideration the change in quantity, weight, volume, and time units associated with the material.

By selecting a value in the field Item Type, you classify your item category as one of the three items. Choose A to define your item as the value item, choose B for defining it as a text item, or keep this field blank to define your item category as a standard item.

Completion Rule The Completion Rule field controls the completion status for an item in inquiries, quotations, and contract documents. It tells that at what point in time your item will be considered completely processed. For example, choose A in this field for your quotation item category, and SAP will set the status of your quotation document as complete on its first reference by an order. Once the status is complete, you cannot refer to that quotation again for another order. The available options for this field in customizing are self-explanatory.

Special Stock Make a selection in this field when you want your item category to use the inventory of some special stock location. For example, in the case of consignment processing, the scenario demands billing the customer only for the stock quantity physically consumed by the customer from the consignment stock location. This stock at the consignment location is tracked in SAP using the special stock indicator W (Customer Consignment). Standard item categories KEN (Consignment Issue) and KRN (Consignment Returns) have the value W in this field. This helps SAP to use the stock from the customer consignment location for all the inventory-related postings during consignment issue and consignment returns processing. Customer consignment processing is explained in detail later in this chapter.

Billing Relevance Whether your item category is relevant for billing is controlled by the Billing Relevance field. Available choices for this field are self-explanatory. A few important ones are as follows:

• B for configuring the item category relevant for order-related billing
• A for delivery-related billing
• D for pro-forma billing
• I for billing plan–relevant billing

Leave the value blank in this field to configure your item category as not relevant for billing.

Billing Plan Type In this field, you enter a default billing plan type key for your item category that in turn will control the billing plan for your sales item. If your item category is relevant for periodic or milestone-based billing (billing relevancy = I), you need to assign the two-character billing plan identifier here. Item category WVN for use with warranties and maintenance contracts and item categories MVN for use with rental contracts use this setting. Contract documents are explained later in this chapter. For more details on billing plans, refer to Chapter 9.

Billing Block Using this field, you can default a billing block for your item category. When you create the sales document using the item category with a billing block set in customizing, the item in the sales document will get blocked for billing and can be billed only when an authorized person validates the sales item and removes the billing block. If your business requirement demands that the item should be blocked for billing by default, you should use this field.

Pricing Here you set the pricing indicator for your item category. A pricing indicator tells whether the item category is relevant for pricing and whether SAP should automatically carry out pricing for the item in the sales document that uses this item category. You can choose among the following indicators:

• X makes your item category relevant for standard SAP item pricing.
• A sets your item category relevant for pricing for empties.
• B applies free goods pricing to your item category.

Keep the value in this field blank to make your item category not relevant for pricing.

Statistical Value In SAP, item values are totaled up to calculate the document value at the header level. When you set a statistical value indicator for your item category, the item value does not roll up to the header for calculating the document totals. Unless you want your item values to act statistical, keep the value in this field blank so SAP can consider the item values while calculating the document totals. If you choose X, SAP performs no cumulation, and the value cannot be used statistically. If you choose Y, SAP likewise performs no cumulation, but the value can be used statistically.

Revenue Recognition and Delimit/Start Date These two fields control the revenue recognition and accrual processing for your item category. Keep the data in these two fields blank if your item category is not relevant for revenue recognition processing. For more details on revenue recognition including the explanation for these two fields, refer to Chapter 10, “Account Assignment and Revenue Recognition.”

Business Item This check box, when selected for an item category, allows the business data in the header and item for a sales document to be different. Select it when you want to allow different data between the header and the item for your sales document, and deselect it if you want the data to be same between the header and item.

Schedule Line When this check box is selected, it allows the item to have schedule lines. The Schedule Line tab in the sales document item level appears only when you select this check box when customizing for your item category. You need the schedule line only for those items that are relevant for delivery. Items that are not relevant for deliveries, such as credit note items, debit note items, and service items, do not need a schedule line. Text items as an exception can exist both with and without a schedule line.

Item Relevant For Delivery Text and value items do not contain schedule lines and therefore cannot be delivered as such. When the check box Item Relev.For Dlv is selected, it allows the text and value items to be relevant for delivery. By making them relevant for delivery, it does not deliver text items from stock but allows them to copy to the delivery document for informational purposes. Do not select this check box unless you are configuring an item category for text or value items that you want to make relevant for delivery.

Returns This check box tells whether the item in the sales order is a return item. Select this if you are setting up the item category for return goods or a similar process.

Weight/Volume Relevant This check box specifies whether SAP should calculate the weight and volume for the item.

Credit Active This check box tells whether the item is relevant for credit checks. Select this if you want to perform credit checks on your items.

Determine Cost Selecting this check box tells SAP to use the cost condition type VPRS in pricing to calculate the cost of the item. For more information on VPRS, refer Chapter 5.

General Controls

The next set of fields when customizing an item category are a few check boxes, as shown in Figure 7-7. These check boxes act as yes/no indicators and exercise some general controls over a sales document item with respect to batch determination and order quantity.

Automatic Batch Determination This check box controls the batch determination for an item. When selected for an item category, it tells SAP to use automatic batch determination to find out the matching batch for a material entered into a sales order line item. Use this only when your materials are batch relevant. You will learn about batch management in detail in Chapter 13, “Serial Numbers and Batch Management.”

Rounding Permitted check box This controls whether a required order quantity can be rounded to match the deliverable units. When selected, it activates the rounding feature for an item category, and vice versa. In addition, you also need to define a rounding profile and assign it to either a customer-material record or a material master record. A rounding profile consists of the threshold values and round-up/round-down percentage.

Order Qty = 1 Select this check box if you want the order quantity for each sales item to be limited to one per line item in the sales document.

Transaction Flow

The fields shown in Figure 7-8 control the transactional flow for an item in a sales document.

Screen Sequence Group A screen sequence group controls the fields that appear on various screens related to an item and the sequence in which these screens appear during the processing of a sales item. This field should always contain an N to represent the standard item screens, unless you have defined your own item screen sequence group and you want to use that instead of the standard.

Status Profile Select a value here only if you want to attach a default status profile to your item category. Using this status profile, you will be able to control the user-defined statuses for a line item in a sales document. For details about the status profile, please refer to the status profile explanations in the sales document type customization process, as explained earlier in this chapter.

Create PO Automatically This check box was available only for ALE in previous versions, but now it is also available for third-party PO creation. When selected, it creates a purchase requisition for a third-party schedule line and a purchase order in the background when you save the order. Select this check box only if your item category type is relevant for third-party order processing.

Incompletion Procedure/Partner Determination Procedure/Text Determination Procedure/Item Category Statistics Group If you take a look at Figure 7-8, you will see that the fields on the left in this group are not available for data entry here. This is because these fields are assigned to the item categories on their respective customization screens. For example, you assign the item incompletion procedure to an item category while configuring the incompletion procedure for a sales item. We’ll briefly summarize them here:

Incompletion procedure An item incompletion procedure will ensure that when you save the document, the required data for an item is duly filled in, and its incompletion status is complete.

Partner determination procedure An item-level partner determination procedure will ensure that the required partner data is present at the sales item level.

Text determination procedure An item text determination procedure will control what text fields should be determined for an item and how.

Item category statistics group An item category statistics group will control the update of item data in the logistics information system (LIS).

Bill of Material

Figure 7-9 shows the next set of fields in the customization of an item category. These fields control the variant configuration and bill of materials processing for an item category.

Structure Scope Entry in this field determines how a BOM is going to be processed in a sales document. You can choose from the following options:

• Select A to explode the single-level BOM.
• Select B to explode the multilevel BOM.
• Keep the value in this field blank for no BOM explosion.

Create Delivery Group Use this field when your item category is BOM relevant and you want to combine all the deliverable subitems of a BOM in one delivery group so as to deliver on the same date. When you select this check box, SAP groups the subitems into a delivery group with same dates. When you choose A in this field, SAP creates a delivery group with correlated schedule lines.

Manual Alternative This check box, when selected, allows the user to manually pick an alternative BOM for an item during the BOM explosion in a sales document, provided that multiple BOM exist for that item in SD.

Figure 7-10 shows the fields relevant for value contracts, repair management, and resource-related billings. You make a selection in these fields only when your item category type is relevant for any of these three processes. Contracts are explained later in this chapter, and repair/resource-related billing is out of scope of this book.

Setting Up an Item Category Determination

Before we set up the item category determination rule, we’ll discuss a few elements we are going to use in the determination process.

Item Category Group

An item category group is a grouping of various material types. An item category group is assigned to a material master through material types and is linked to SD via an item category determination rule. The item category group, together with item usage, a higher-level item category, and a sales document type, helps in the determination of the item category during sales order processing. A long list of item category groups comes with standard SAP, and they should be sufficient for any business need. Still, if you ever need to create a new item category group, you would do so by providing a four-digit or less alphanumeric key starting with the letter Z and by providing a description. To define a new item category group, follow the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Item ⇒ Define Item Category Groups. You can also define a default item category group for a material type by following the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Item ⇒ Define Default Values For Material Types.

Item Category Usage

This controls the usage of an item. For example, during automatic product selection, you use the Item category usage PHSP (product selection main item) and PSEL (product selection subitems) to differentiate the main item and subitems. To define an item category usage, follow the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Item ⇒ Define Item Category Usage.

Setting Up an Item Category Determination Rule

Unlike a sales document type where you manually enter the sales document type on the initial screen, an item category is determined automatically by SAP during sales order processing. This is made possible by assigning the item category to a determination key in customizing. You can assign an item category to the determination key by using transaction code VOV4 or following menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Item ⇒ Assign Item Categories. Figure 7-11 shows the customization screen for assigning an item category. The first four fields on the screen, Sales Doc Type (SA), Item Category Group (ItCGr), Item Usage (Usg.), and Higher-Level Item Category (HLevItCa), form a determination key. You can assign one default item category and up to 11 manual item categories to a determination key. During determination, the default item category automatically copies to the required item line in the sales document, but you can always override it with any of these 11 manual ones you assigned to the same determination rule in customizing.

How SAP Determines an Item Category

The process followed by SAP for determining an item category is explained in the following steps and is also graphically represented by Figure 7-12:

Defining Schedule Line Categories

The next step in customizing a sales document is to define a schedule line category. A schedule line consists of confirmed delivery quantities and corresponding confirmed delivery dates when these quantities can be delivered. A schedule line category controls this delivery scheduling process and impacts logistics by controlling various relevancy indicators and other values related to delivery, purchase requisition generation, availability check, goods movement, transfer of requirement, product allocation, and MRP applicability for an item. The behavior of a schedule line, whether to create delivery, by default blocked for delivery, whether to allow MRP, and so on, depends upon the configuration options you set when customizing the schedule line category.

You define a schedule line category by using transaction code VOV6 or by following the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Schedule Lines ⇒ Define Schedule Line Categories. Once you are at the customization screen, enter a two-digit alphanumeric key with a description to define your own schedule line category. Always remember to follow the rule of naming your objects with the prefix Z. Standard SAP provides a variety of schedule line categories, but still you may come across situations where you need to customize a schedule line category of your own. Let’s now take a look at various customization settings of a schedule line category, as shown in Figure 7-13.

Schedule Line Category Key and Type At the top of the screen shown in Figure 7-13, CN represents the schedule line category key, and No MRP represents the description for the schedule line category type.

Delivery Block The delivery block key that you enter in this field gets copied over as a default delivery block on the schedule line in the sales document. Select the delivery block, which you would like to default to your schedule lines.

Movement Type A movement type in SAP controls the “to and from” movement of goods and thus controls the inventory update. For instance, movement type 601 (Figure 7-13) is used for goods issue from the inventory, and therefore it reduces the inventory to the tune of delivered quantities. The SD module uses goods movement from 601 to 699. Select the relevant movement type for your schedule line category in this field.

Item Relevant For Delivery Indicator When selected, the check box item Rel.F.Dlv. allows the items attached to a schedule line to be relevant for delivery. Leave this field deselected for those schedule line categories where you do not want the items to be delivered such as inquiry- and quotation-related schedule line categories.

Movement Type 1-Step This field allows you to enter the movement type for one-step movement of goods.

Processes such as STO can have both single-step and two-step movement of goods possible. Example of a two-step process would be transferring goods from plant A to plant B, where step 1 is goods issue (GI) of goods from plant A and step 2 would be performing goods receipt (GR) in plant B when the goods are physically received in plant B. A one-step process would be transferring goods from plant A to plant B where step 2 is deemed performed when you perform GI from Plant A. In this case, you will not wait for goods to be received physically in plant B in order to perform the GR step. Rather GR at plant B will be automatically performed by SAP the moment you perform GI step at plant A. One-step process is generally used when the plants are physically located very close to each other and therefore cross plant movements need not involve two separate steps.

Order Type/Item Category/Account Assignment Category With ATP checks and TOR, you can check the availability of the goods in stock and can transfer the shortage requirement to PP or the Purchasing module for production planning or procurement. These three fields together allow the automatic creation of a purchase requisition for the requirements transferred from a sales order.

Purchase Requisition Delivery Schedule The check box P.Req.Del.Sched indicates whether the sales line item is relevant for delivery rescheduling. Keep this deselected for third-party orders processing because it is possible to have a direct shipment of goods from your vendor to your customer, and you do not require SAP to reschedule the delivery timelines in such a case. Use this when the goods come to your warehouse first and then move to a customer’s purchase order on receipt of the requirements from the sales order so that SAP can add those times into the delivery scheduling.

Incompletion Procedure The field Incompl.Proced. is for display only in the customization screen for schedule line categories. You enter a default value for an incompletion procedure for a schedule line in the customization of incompletion procedures.

Req./Assembly This check box acts as an on/off switch for transferring requirements. When selected, requirements from a sales order can be transferred to the PP or the Purchasing module by creating the relevant purchase order or purchase requisition. It also acts as a prerequisite for an availability check to happen. If you do not select the requirement field and select only the availability field, the check will not function.

Availability/Prod. Allocation When selected, this check box activates the availability check/product allocation for a sales order. For more details on availability checks, please refer to Chapter 6, “Availability Check, Transfer of Requirements, and Backorders.”

Setting Up a Schedule Line Category Determination

Just like an item category, schedule line categories are also determined automatically by SAP. This is made possible by assigning the schedule line categories to a combination of item categories and MRP type. The MRP type is stored in the MRP view of the material master record and is responsible for the requirement planning for the material. You can assign a schedule line category via transaction code VOV5 or via menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Schedule Lines ⇒ Assign Schedule Line Categories.

Figure 7-14 shows the customization screen for assigning a schedule line category. As you can see on this screen, the default schedule line category CN is assigned to item category TAN (Standard Item And MRP Type ND – No Planning). You can also assign three additional manual schedule line categories (field MSLCa) for your determination rule. When you create a sales order with a material line having item category TAN and if that material master has the MRP type ND, SAP automatically determines the schedule line category as CN. You can then overwrite it with any of these three manual schedule line categories values that you set up in customizing for schedule line category determination.

Setting Up Copy Controls

A copy control transfers the data from one document to another and thus saves on data entry time, automates the sales process, and reduces the chances of manual mistakes. It also updates the document flow and ensures easy traceability between the documents. For example, if you know the sales order number, you can trace the delivery document, billing document, and accounting posting for that sales document using the document flow generated via the copy control setups. If you know the accounting document number, you can still trace the whole flow back up to the sales document number from where the whole transaction started.

In a sales application, you can define copy control for the following:

• Copy from sales document to sales document (transaction code VTAA)
• Copy from billing document to sales document (transaction code VTAF)

You need to define a copy control from a sales document to another sales document when you want to copy one sales document’s data into another sales document such as when performing a copy from an inquiry to a quotation or from a quotation to an order. On the other hand, copying from a billing document to a sales document is usually set up in debit and credit notes scenarios where you want to create the debit or credit note request by copying data from a billing document.

Because a sales document is structured into header data, item data, and schedule line data, you need to maintain the copy control setup at all three levels. To maintain the copy control setup for a sales document, use transaction codes VTAA and VTAF, or follow the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Maintain Copy Control For Sales Documents. For this discussion, we’ll cover how to customize a copy control at all these levels, with the help of a sales document–to–sales document copy setup and by using copy controls for standard orders as an example.

Setting Up Copy Control: Header Data

A copy control customization screen consists of an overview screen and a detail screen. On the copy control overview screen, you define the source object from where you want to copy and you define the target object to which you want to copy. Figure 7-15 is an example of a copy control overview screen. Here, IN and QT represent the source document type, and OR represents the target document type. You can define a new copy source and target relationship by clicking the new entries button on the menu. The dialog structure menu shown in Figure 7-15 contains an icon for each of the levels for which you need to define a copy control setup. Double-clicking the icon will take you to the overview screen of the specified level. Currently the icon is on the header level, and we are maintaining the copy control at the sales header level.

A copy control setup primarily consists of three main elements: a data transfer routine, a requirement, and a few check boxes. A data transfer routine controls whatever data needs to be copied over, a requirement controls when (and when not) to copy data, and a check box field acts as an on/off switch to activate or deactivate a particular functionality during copy. Let’s take a look at all these elements with reference to Figure 7-16.

Data Transfer Routine (DataT field) A data transfer routine contains the ABAP code for the field-to-field transfer of data from the source object to the target object. Routines 051, 101, and 001 in Figure 7-16 specify that when the QT document is copied into an OR document, the general header data, the business data at the header level, and the partner data at the header level all will be copied from the source to the target document, in other words, from QT to OR.

Copying Requirements The Copying Requirements field controls when the data should be copied over and when it shouldn’t be. Here, copy requirement 101 tells SAP that the copy should happen only when the header partners of both the documents (in other words, QT and OR) matches each other. With this setting, if you go ahead and try to create an order for customer A from the quotation document of customer B, SAP will show an error on the document copy screen telling you that the sales document cannot be copied because the header data between the two documents are not same.

Copy Item Number check box The Copy Item Number check box controls whether item numbers should be copied from the source to the target. This setting makes sure that the item number for the item in the source and target documents is the same. Since this is selected in Figure 7-16, the item numbers will be copied over from QT to OR.

Complete Reference The Complete Reference check box, when selected, tells SAP to update the status of the source document as complete on the first reference of the source document by the target document. Once the source document status becomes complete, you will not be able to copy that source document again to any other target document.

Setting Up Copy Control: Item Data

Once the copy control is defined between the header for a source and target document type, you need to define the copy control between the relevant item categories for these two documents. Figure 7-17 shows the overview screen for item category copying. To reach this screen, click the Item icon shown on the left of Figure 7-16. Item category AGN on the screen is the source item category.

Figure 7-17: Item Overview screen for sales document–to–sales document copy

For the purposes of this chapter, we will analyze the standard item category AGN. To reach the detail screen shown in Figure 7-18, double-click the item category line AGN.

We’ll now discuss the customization fields shown in Figure 7-18 in detail, starting at the left of the lower pane:

Item-level data transfer routines Starting from the top, you can see the item-level data transfer routines 151, 102, and 002, which respectively ensure the copying of general data, business data, and partner data that’s relevant for the item.

FPLA FPLA contains the copy requirement for the data transfer of billing plans. If the check as per the copy requirements for FPLA is successful, the billing plan fields are copied from the source to the target item.

Copying Requirement Copying requirement 301 ensures that the rejected lines are not copied from the source item to the target item.

Copy Schedule Line The Copy Schedule Line check box, when selected, ensures that the schedule lines from the source item are copied to the target item.

Update Document Flow The Update Document Flow check box controls the updating of document flow during the copying.

Do Not Copy Batch The Do Not Copy Batch check box controls whether the batch can be copied from the source item to the target item.

Configuration The Configuration check box controls the copying behavior of configurable items. When you copy a configurable item from the source to the target document, the target document uses the configuration of the source document, and the BOM is not re-exploded. Now, if you change the source document, the target document also gets that change passed over. By using the available options in this field, you can change this behavior.

Re-explode Structure/Free Goods This option is used for BOM-based materials. When selected, this check box ensures that the main items are copied as such and the BOM is re-exploded in the target document with a new date and new quantities contained in the target document.

Positive/Negative Quantity This controls whether, during copying of an item, the quantity or the value of the item will have a positive impact, a negative impact, or no effect at all. For example, a contract to a return will have a negative effect, a quotation to an order will have a positive effect, an order to an order copy will have no effect, and so on.

Copy Quantity This controls what quantity should be copied from the source to the target document. You can choose between copying from the target quantity and copying from the order quantity, and you can even leave the field blank. If you do not choose any value in the field, SAP tries to determine the most appropriate quantity. For example, if you leave this field blank for a copy between QT and OR, then the open quotation quantity is determined and copied as the order quantity.

Pricing Type This controls how the pricing should behave during the copy between the source and the target. With the available options from the field, you can set the pricing to completely determined, partially determined and partially copied, or completely copied from the source to the document without any changes.

Cont. Item Copy Mode This sets the limits for the copy of the value contract items. You can select B to allow the copy of the value contract items and restrict the others from copying, or you can select A to restrict the value contract item from copying but allow other items to copy. You can also leave the field blank if you do not want to apply any restrictions.

Copy Product Selection This is relevant for product selections. By selecting a value here, you can set up whether the product selections should be copied over from the source to the target documents. For copying from an order to an order, do not copy the product selections from the source. Rather, you should leave the field blank so that the product selection is carried out again for the target document.

Campaign Determination The Campaign Determination field is related to the campaign determination in SD.

The next screen (Figure 7-19) represents the copy control at the schedule line level. This screen is pretty simple; the only requirements are to decide when to copy or when not to copy the schedule line and to set a data transfer routine to control what data to be copied.

Copy Control in Other Document Types in SAP SD

SAP provides the copy controls for deliveries and billing documents as well as for sales documents. Table 7-2 shows the various copy controls that you can set up in delivery and billing along with their transaction codes and menu paths.

Table 7-2: Transaction Codes and Menu Paths for Setting Up Copy Controls in Delivery and Billing Documents

Description	Transaction Code	Menu Path
Copy Control for Delivery Documents
Sales document to delivery document	VTLA	IMG ⇒ Logistics Execution ⇒ Shipping ⇒ Copying Control ⇒ Specify Copy Controls For Deliveries
Copy Control for Billing Documents
Billing document to billing document	VTFF	IMG ⇒ Sales And Distribution ⇒ Billing ⇒ Billing Documents ⇒ Maintain Copying Control For Billing Documents
Sales document to billing document	VTFA
Delivery document to billing document	VTFL

Delivery and billing documents are structured into a header and an item data only. Therefore, maintaining a copy control for these documents involves only two levels: a header copy and an item copy. Otherwise, the process is the same as you saw earlier for sales-to-sales copy. There will also be routines, requirements, check boxes, and fields for extra information to be copied over from source to target document during copying.

Common Sales Document Customizations

In addition to the settings that have we already defined in this chapter, there are various miscellaneous customization settings that you can define for sales documents. We’ll cover these other settings one by one.

Allowable Sales Doc by Sales Area

By default, the sales document types you create are available to be used across all sales areas. But if you ever want to use them only with a particular sales area, you then need to assign them to that sales area by following the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Header ⇒ Assign Sales Area To Sales Document Types. Next you will be presented with the activity dialog screens with the following four activities.

• Combine sales organizations
• Combine distribution channels
• Combine divisions
• Assign sales order types permitted for sales areas

These four activities need to be configured in the sequence they are explained next. Remember that all four steps are mandatory if you want to set up the sales document by sales area.

Combine sales organizations Here you assign your sales organization to a reference sales organization for the purpose of sharing the document types between the two. You can also reach this customization screen directly using transaction code OVAO. Figure 7-20 shows the customization screen for OVAO. Here, sales organizations 9090 and 9091 are set up to share the document types that are defined for sales organization 9090.

Combine distribution channels Here you assign your sales organization and distribution channel combination to a reference distribution channel for the purpose of sharing the document types. You can also reach this customization screen directly using transaction code OVAM. Figure 7-21 shows the customization setting for OVAM setup. Here, the sales organization and distribution channel combination for 9090-97 and 9091-97 will share the document types, whereas 9090-98 is set up to have its own document types.

Combine divisions Here you assign your sales organization and division combination to a reference division for the purpose of sharing the document types. You can also reach this customization screen directly using transaction code OVAN. Figure 7-22 shows the customization setting for OVAN setup. Here, as you can see, all the sales organization and division combinations for Galaxy US and Mexico are set up to share the document types that are defined for division 99.

Assign sales order types permitted for sales areas At the end, you assign the sales document types to the reference sales area. You can also reach this customization screen directly using transaction code OVAZ. Figure 7-23 represents this customization setting for Galaxy Musical Instruments. As you can see from the customization setup shown on this screen, we assigned the document types to sales areas 9090-97-99 and 9090-98-99. The document types that were assigned to 9090-97-99 will be shared between 9090-97-99 (the U.S. reseller sale) and 9091-97-99 (the Mexico reseller sale), whereas the document types defined for 9090-98-99 (U.S. direct sales) will be exclusively used by sales area 9090-98-99 only.

Converting the Language for Each Sales Document Type

In SAP, you can set up the language-specific identifier key for your document type. The menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Header ⇒ Convert Language For Each Sales Document Type. Figure 7-24 shows the customization screen with an example showing the sales document type key conversion into Chinese.

Defining Purchase Order Types

Your customer can send orders to you using various transmission services, such as phone, EDI, fax, mail, email, and so on. In SAP, you can define a four-character identifier key for each of these transmission methods that your customer has used to send the orders into your organization and thereby can take statistical reports on this basis. This is one of the factors an organization uses to determine whether its investment in electronic ordering techniques is showing any results. The menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Header ⇒ Define Purchase Order Types. Figure 7-25 shows the customization screen for defining the purchase order type.

Maintaining Order Reasons

The reasons that led the customer to place an order or returns for your product can be maintained in SAP as order reasons. A sales call, television advertisement, trade fair activities, excellent price, existing customer recommendation, and so on, are a few examples of order reasons. Be it an inquiry, quotation, sales order, contract, return, or any other sales document, you can use an order reason for all of them. An order reason helps you analyze your marketing and presales activities’ effectiveness and efficiency. It also help you judge your product performance in the market and capture quality failures and problems that led to customers returning your goods, so that you can improve in the future.

The transaction code is OVAU, and the menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Header ⇒ Define Order Reasons. For defining your own order reason, provide a three-character identifier for your order reason along with a meaningful description.

It is always best to define a naming convention before you create an order reason in SAP. Galaxy decided to use an alphabetic prefix for order reasons that will help them to easily identify the order reasons. Galaxy named all the order reasons that are applicable for returns processing with the prefix R and all the order reasons that are applicable for sales orders with the prefix S. Figure 7-26 shows the order reasons that were customized for Galaxy Musical Instruments.

Customizing Order Blocks

Order blocks are available in SAP to block a customer master record from being able to create a new sales document. For example, assume your customer is a defaulter, and you do not want any new order for this customer to be entered into your SAP system. You can simply assign an order block into the customer master record that blocks the customer from placing any order in SAP.

When customizing an order block, you first create the reason for which you would like to block your customer from placing further orders. You then assign this order blocking reason to the respective document types. Once set up, this order block reason can then be assigned to the respective customer master records that you want to block.

The menu path for setting up an order blocking reason is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Define And Assign Reasons For Blocking. You will be presented with activity dialog boxes where you can define blocking reasons and allocate them to sales order types.

Defining blocking reasons This activity allows you to define an order block. Figure 7-27 shows the customization screen for defining the order blocks. You can also reach this customization screen directly using transaction code OVAS. To define your own order block, provide a two-character identifier for your block reason along with a meaningful description.

Allocating blocking reasons to sales document types This activity allows you to assign the order blocks to their respective sales document types. Figure 7-28 shows the customization screen for assigning order blocks to document types. You can also directly reach this customization screen using transaction code OVAL. The assignment shown in Figure 7-28 represents the assignment for Galaxy Musical Instruments.

Reasons for Item Rejections

In SAP, you can reject individual line items of a sales document or a complete sales document (done by rejecting all the lines in it). You reject individual line items by entering a rejection reason for your line item on the Reasons For Rejection tab on the sales document overview screen. This way, you can provide different rejection reasons for different lines. Alternatively, using the fast-entry option in sales document change mode (the menu path is Edit ⇒ Fast Change Of ⇒ Reasons For Rejection), you can reject multiple lines at once, provided that they all belong to same rejection reason. What kind of subsequent functions (billing, printing, and so on) a rejected line can perform is controlled via customizing the rejection reason.

Defining Reasons for Rejections

To set up the rejection reasons, follow the menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Sales Document Item ⇒ Define Reasons For Rejection, or use the transaction code OVAG.

Figure 7-29 shows the customization screen for item rejection reasons.

Here is an introduction to the fields in Figure 7-29:

Rj This field represents the two-character identifier for a rejection reason. The key can be numeric or alphanumeric.

Description This field represents the logical description of the rejection reason.

NRP check box This field controls the printing of the rejected line. This checkbox, when selected for a rejection reason (and if that rejection reason is selected for a sales line in document), makes that sales line item not relevant for printing. This way you will restrict the rejected line to print on the order confirmation and other print outputs.

OLI check box This field controls the rejection for a resource-related billing document. When selected, this check box allows you to create a new sales document or new sales item line in an existing sales document for a rejected line, provided the rejected sales document or the line item was triggered via the resource-related billing process.

BIC check box This field controls the copy of the rejected line for billing purposes. This check box, when selected for a rejection reason (and if that rejection reason is selected for a sales line in document), makes that sales line item not relevant for billing.

Statistical By selecting a value from the list of available values for this field, you tell SAP whether the rejected line item value should be added to the header totals of the sales document or whether it should be used only as a statistic. The available selection values are self-explanatory.

Incompletion Procedure

As we progress in the sales cycle, data gets copied between the sales order, delivery, and billing documents, and it is required that the proper control is maintained so that any important information does not gets missed during the sales cycle processing. An incompletion procedure helps in identifying such missing data elements and gives you more control by stopping the sales cycle from proceeding if some of the key fields are missing in the sales cycle. You can set up an incompletion procedure to ensure the completeness of the following:

• Sales document at the header, item, and schedule line levels
• Delivery document at the header and item levels
• Sales activity
• Partner data (sales document, delivery document, and sales activity)

The configuration process starts with defining a status group that is assigned to individual fields in the incompletion procedure, and then this incompletion procedure is assigned to the sales document at the header, item, or scheduled line for which you customized the incompletion procedure. Figure 7-30 diagrams the customization involved in setting up an incompletion procedure.

Once set up in customizing, the incompletion log can be called automatically while saving the document or via the menu from the sales document screen. When the incompletion log is called, SAP checks whether the fields maintained in the incompletion procedure are filled up. It then creates a log for all the fields that are part of the incompletion procedure being assigned to that sales document and decides on the action to be taken. Action can be either to allow the incomplete document to be saved but blocked for further processing or to disallow the incomplete document from saving. The decisions related to further processing of the documents are controlled by the combination of statuses being chosen in the status group.

Incompletion configuration is a three-step activity:

We’ll now cover this configuration in detail.

Defining a Status Group

For this step, you choose the various available statuses such as general status, delivery status, billing status, pricing status, and so on, and put them into a status group (with a two-digit alphanumeric number), which controls what impact a particular field assigned to a particular status group will have on the document if it is part of an incompletion log. You can define a status group using transaction code OVA0 or following menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Incompletion Log ⇒ Define Status Groups. Figure 7-31 represents the customization screen for defining a status group. What impact each of these status fields, shown in the customization screen in Figure 7-31, has on your status group, and in turn on incompletion procedure, is explained in Table 7-3.

Table 7-3: Status Fields and Their Impacts

Status Field	Impact
General	Document or item is generally incomplete but can be processed further
Delivery	Delivery not possible for document or item
Billing	Billing not possible for document or item
Price	Order confirmation or billing not possible for the document
Goods movement	Goods movement not possible
Picking/put-away	Picking/put-away not possible for the document or item
Pack	Packing not possible

When working with status groups, first try using the default status groups provided by SAP such as 01, 02, and so on. If these status groups cannot serve the purpose, then create a new one by copying from any of these available status groups and using a Z prefix. Choose the necessary statuses required for your scenario in the new user-defined status group.

Defining an Incompletion Procedure

An incompletion procedure is a grouping of individual fields that are to be checked for completion during document processing in a sales cycle. You can define your incompletion procedure using transaction code OVA2 or following the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Incompletion Log ⇒ Define Incompletion Procedure. Figure 7-32 shows the incompletion procedure definition screen listing seven incompletion procedure groups provided by standard SAP.

For our configuration study, we’ll show the example of using the sales document header Incompletion – Group A.

Choose Sales – Header, and click the Procedures icon in the left window. The next screen will list all the available incompletion procedures for the Sales – Header group (Figure 7-33).

Choose incompletion procedure 10 (Inquiry/Quotation), and double-click the Fields icon on the left. The new screen (Figure 7-34) will show all the fields that are part of incompletion procedure 10.

Table Here you enter the name of the table whose field needs to be checked for completion. In Figure 7-34, sales document header tables VBAK and VBKD are being used for setting up the sales header incompletion procedure 10.

Fld Name Here you enter the name of the field from the table that needs to be checked for completion. In Figure 7-34, incompletion procedure 10 is configured for checking incompletion for the fields document date, quotation validity to, and document currency from table VBAK and the fields pricing date and terms of payment of table VBKD.

Description This is the description of the field.

Scr. This field stores the function code that displays the screen on which you can correct the error. When your document is incomplete, the system creates an incompletion log. When you select the incomplete item from the incompletion log for maintaining the missing value, the system uses the function code mentioned in this field to display the relevant screen where you can maintain the missing data.

Status This is the status group assigned to the individual field that will control the field behavior during sales order processing.

Warning This controls whether to show any warning to the user when the user does not make an entry in the required field.

Seq. This is the sequence in which the SAP system should check for the incomplete fields in the sales document.

If a need arise to change the incompletion procedures provided by standard SAP such as 10, 11, 12, and so on, as shown earlier, you can make a copy of the one that is a good match to your requirement and then save it with prefix Z. Now remove the fields that you don’t want to check for incompletion from this newly created Z procedure and add the fields that you want this Z procedure to check during incompletion with the required table, screen name, status group, warning, and sequence.

Assigning the Incompletion Procedure

The last step in configuring an incompletion procedure is to assign the incompletion procedure to the appropriate activity. The transaction code is VUA2, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Incompletion Log ⇒ Assign Incompletion Procedures. For the seven incompletion groups provided in the incompletion procedure, SAP provides seven different activity groups while assigning them. For example, the Sales Header Incompletion group corresponds to sales document types, the Sales Item Incompletion group corresponds to item categories, and so on.

So, in the Sales-Header incompletion group procedure configuration, the next step is to assign it to a sales document type. Go to T-code VUA2, and double-click Assign Procedures To The Sales Document Types, as shown in the Figure 7-35.

On the next screen, shown in Figure 7-36, assign the incompletion procedure to the required sales document type. Please note the field IC-Dialog in Figure 7-36. This field controls whether you can save an incomplete sales document.

To define an incompletion procedure for a sales document, you need to define the incompletion procedure for the sales document header, item, and schedule line and assign it to the respective sales document type, item category, and schedule line category.

Similarly, for activating an incompletion log in a delivery document, you need to define the incompletion procedure for both the delivery header and the item and assign it to the respective delivery document type and delivery item category.

The incompletion group for a partner needs to be defined to have the control on the partner data in the sales document flow (table VBPA). A partner incompletion procedure defined and assigned to a partner acts globally for the sales activity, sales document, and delivery document.

Calling the Incompletion Log

Once set up in customizing, the incompletion log can be called automatically while saving the document or via the menu Edit ⇒ Incompletion Log from the sales document, sales activity, or delivery document screen. Once called, the incompletion log generates a log screen and will show the list of fields that are missing values. The list comprises fields from the header, item, and schedule lines. Whether the document can or cannot be saved or processed further will depend upon the customizing settings you made in the incompletion procedure configuration. To maintain these fields, just select the check box next to the field and then click the Complete button on the top. This action will take you to the individual screen for each of the fields; keep pressing the F5 key on the keyboard to toggle between the screens that are to be maintained. Once all the fields are maintained, you can save the document to be processed further. Table 7-4 shows the reports available in standard SAP that you can use to generate the list of incomplete sales documents.

Table 7-4: Incompletion-Related Standard Reports Available in SAP

Transaction Code	Report Description
V.00	Incomplete SD documents
V_UC	Incomplete delivery documents

Delivery Blocks

Delivery block functionality in SAP allows you to block the sales order and delivery documents from further processing. You can apply the delivery blocks to the sales document either at the header level (Shipping tab) or at the schedule line level (Schedule Line tab). Further, you can assign the delivery block manually in the sales document, or the system can automatically propose it. For automatic proposal at the header level, the delivery block needs to be entered in the sales document type customization (VOV8). For autoproposal at the schedule line level, the delivery block needs to be entered in the schedule line customization (VOV6). Always remember that for the delivery block to be effective at the sales document header level, the delivery block assignment to the respective delivery type is a must. A delivery block at the schedule line can work even without this setting. You can also enter a default delivery block in the customer master data, and SAP will copy over the same delivery block to all the sales documents of the customer, thereby blocking the sales documents from getting delivered.

The menu path for setting up an order blocking reason is IMG ⇒ Logistics Execution ⇒ Shipping ⇒ Deliveries ⇒ Define Reasons For Blocking In Shipping. You will be presented with an activity dialog window where you can select the activity to define the delivery blocking reasons and the Delivery Blocks activity to allocate the delivery blocks to the delivery document types.

Defining Delivery Blocking Reasons/Criteria

The Deliveries: Blocking Reasons/Criteria activity allows you to define the delivery blocking reasons and criteria. Figure 7-37 shows the customization screen for defining the delivery blocking reasons. You can also reach this customization screen directly using transaction code OVLS. To define your own delivery block, provide a two-character identifier for your blocking reason along with a meaningful description, and select the relevant check boxes for the delivery blocking criteria.

Order You can use this check box to block the sales orders from getting delivered.

Conf. You can use this check box to block the order quantities from getting confirmed.

Print You can use this check box to block the output generation for sales documents that are blocked for delivery.

DDueList This check box helps you exclude the sales document blocked for delivery from the delivery due list.

Picki This check box stops the deliveries from getting picked that are under the delivery block.

Goods This check box stops the deliveries from getting PGIed that are under the delivery block.

Assigning Delivery Blocks to Delivery Document Types

The Delivery Blocks activity allows you to assign the delivery blocks to their respective delivery document types. Figure 7-38 shows the customization screen for assigning delivery blocks to delivery document types representing the assignment for Galaxy Musical Instruments.

This activity is required only if you want to use the delivery blocks for blocking the sales order from getting delivered. For scenarios where you want the delivery block to be applied at the sales order schedule line level or directly in the delivery document, this setting is optional.

Types of Sales Documents

We briefly touched on the sales cycle in Chapter 1 and discussed the customization for standard orders (document type OR) during our discussions on sales document customization.

Apart from the document type OR, standard SAP comes with the following preconfigured sales document types that you can use as-is or can use as a referencing template to create your own customized document types:

• Presales documents such as inquiries and quotations
• Order documents such as cash sales, rush orders, standard orders, and consignment orders
• Outline agreements such as contracts and scheduling agreements
• Complaint-processing documents such as debit/credit notes, invoice correction requests, sales returns, and free-of-charge and subsequent free-of-charge deliveries

We’ll take a quick look at each of these sales document types in the following sections.

Inquiries and Quotations

An inquiry is a request that a buyer places on the seller to get the required information about the seller’s products. It is an indication of the buyer’s interest toward the seller’s products. A customer inquiry may contain questions about the cost of a product, its availability on a particular date, use of a product, and so on. You reply to the customer’s inquiry by sending a quotation. A quotation usually contains information about the product price, any applicable terms and conditions, and the answers to any other question from the buyer’s inquiry.

Standard SAP provides document type IN for inquiries and QT for quotations, with the item categories AFN and AGN controlling the item data for inquiries and quotations, respectively. You can create an inquiry and quotation document for both goods and services. You can also use structured materials, such as bill of materials, in inquiries and quotations. While creating any of the two documents (IN or QT), you can give the choice to your customer by providing one or more alternatives for a particular product. To maintain an alternative for an item in an inquiry or a quotation document, enter the alternative item just below the main item with the reference number of the main item in the alternate item field on the alternate item line. Figure 7-39 shows this, where item 20 is the alternative for item 10.

If the customer quotation converts into a confirmed order and the customer has agreed on the alternative item, you can copy the alternative item into the sales order with reference to the quotation. To do so, you have to use the selection list function from the dialog box that appears when you copy a document with reference to another document. You can also maintain a validity period for your inquiry or quotations and thus can monitor the processing time of your inquiry and quotation process in SAP against the benchmarks that exist in your organization.

A quotation is copied from an inquiry or can be created stand-alone. Copy controls exist in standard SAP for IN-QT, IN-IN, and QT-OR for allowing the copy between an inquiry to a quotation, from an inquiry to an inquiry, and from a quotation to an order.

Sales Returns

A sales return or goods return is a process where the buyer sends back the goods to the seller and the seller credits the customer for the value of the goods by creating a returns billing document. The process involves creating a sales return document type followed by a returns delivery and a returns invoice/credit note.

You can create returns in SAP with or without reference to a billing document. If you want to create them with a reference to a billing document, make sure that you have copy control set up between the billing and sales documents to allow this copy for your sales document.

In standard SAP, sales document type RE with the default delivery document type LR and a default billing document type RE represents the sales return cycle. The SD document category is H, and the screen sequence group is RE. The document is under the default billing block that ensures the validation of the return document by an authorized person before giving credit to the customer. Since it is an inward movement of goods, the return documents are not relevant for credit checks.

The item category REN for returns processing is a standard return item relevant for delivery, billing, and pricing, and it allows schedule lines.

Debit and Credit Notes

Mistakes do happen in the processing of a sales transaction. This creates a need for an adjustment or correction process. Debit notes and credit notes are these adjustment documents in SAP. You create a debit note in SAP to debit the customer for any underbilled amount and a credit note to credit the customer for any overbilled amount, without involving any goods movement.

Underbilling and overbilling are not the only criteria for creating debit and credit notes. There may be various other reasons too. For example, you may have an agreement with your customer to get reimbursed for any expense you incurred on behalf of your customer with relation to the sales transaction, such as freight charges, insurance, and so on. In such cases, a debit note is also used for charging these actual expenses to the customer.

You can create a debit or credit note with a reference to a sales document, a contract, or a billing document, and you can even create one without a reference to any document. The structure of a debit and credit note document consists of a header and item. Since no delivery is involved, the schedule line category is not required. Because there is no delivery step involved in a debit or credit document and they straightaway hit accounting, organizations generally keep these documents under a default billing block. An authorized person then reviews these documents and releases the billing block. If you are not satisfied with this two-level validation process and need something like a release strategy, you can define one by using status profiles. For example, you can set up the user-defined statuses as initial, blocked, rejected, and released, and you can then provide the authorizations for these different individuals. Once the documents are approved or released from the billing block, they can be processed using billing process and posted to accounting.

In standard SAP, the document type CR with the document category K and billing type G2 exists for a credit note, and document type DR with document category L and billing type L2 exists for a debit note. The screen sequence group is GA, which controls the display of the screens in VA01, VA02, and VA03 transactions, which you use for the maintenance of credit/debit note request documents.

Item categories available in standard SAP are G2N, GFN and L2N, and LFN, where G2N and L2N are for normal sales order–related credit/debit documents, and GFN and LFN are for billing plan–related credit/debit sales documents. All these item categories are set up for order-relevant billing.

Invoice Corrections

Invoice corrections (document type RK) represent the process of adjusting or correcting the customer’s invoice. Unlike debit and credit sales documents where you create two separate documents (one for debit and one for credit), the document type RK allows you to create a single correction document for your invoice. The structure of the document consists of a header and item data. The item data always consists of two items. The first item is always a debit item, and the second is the credit item. The net invoice correction amount is a sum total of both the lines leading to an upward or downward revision of the original invoice amount.

A combination of the document category (value K) and the indicator field (value D) categorizes document type RK as an invoice correction document. The reference mandatory field in customizing for document type RK contains value M. This forces the document type to be created only with reference to an invoice document. The document type RK is not relevant for delivery and creates an order-relevant billing, G2. A default billing block exists in customizing for document type RK, which ensures proper validation by an authorized person before the RK document can be billed. The item categories G2N and L2N are available in standard SAP for use with the document type RK.

Free-of-Charge Delivery and Subsequent Free-of-Charge Delivery

Certain sales scenarios demand free-of-charge delivery of goods, such as samples. In standard SAP, you can send free-of-charge deliveries to your customer using sales document type FD (free-of-charge deliveries) and document type SDF (subsequent free-of-charge deliveries). You use transaction code VA01 for entering these documents into the SAP system.

Free-of-Charge Delivery (FD)

You use sales document type FD with default delivery type LF to send samples of your products to your customer. The sales cycle for FD only involves the order and delivery step and is not relevant for billing. In customizing, the document type FD is set up with document category I, which categorizes the sales document type FD as a free-of-charge order. For a free-of-charge delivery, the order reason is compulsory and is part of the incompletion procedure 13 assigned to the document type FD.

The item category is KLN and is set up as a standard item with schedule lines allowed so that you can perform an availability check and maintain schedule lines for free-of-charge deliveries. The item category is not relevant for pricing or credit checks and is also not relevant for billing. Since no billing is involved, the copy control setting exists only for copying a sales document to a delivery (copying FD to LF).

Subsequent Free-of-Charge Delivery (SDF)

SAP provides a free-of-charge delivery sales document (SDF), on the other hand, to handle situations where goods were billed to a customer but found damaged on arrival when received by customer. In some cases, it is not worth having these goods returned, and a subsequent delivery needs to be carried out. For example, as a result of a customer complaint, you now want to send a subsequent delivery to your customer free of charge. An SDF document is always created with reference to the original sales document and, similar to document type FD, involves only the order and delivery step. You don’t bill the customer a second time, and therefore the document is not relevant for billing.

From a customization standpoint, sales document type SDF is like a mirror image of document type FD with the major exception that referencing the original sales document is mandatory for an SDF sales order, and it need not access customer–material information records because all the values are supposed to flow from the reference sales order to the SDF document. The SAP system is capable of keeping track of how many quantities you copied from the reference document into the SDF document for delivering free to the customer.

The document type SDF also uses item category KLN and therefore, similar to FD, is relevant for delivery but not for billing and pricing. The copy control setting exists only for copying a sales document to delivery (copying SDF to LF).

Cash Sales

Cash sales is a special order type available in SAP to handle those business scenarios where the customer places the order, pays for the goods, and receives the delivery at the same time. An example of this business process would be an over-the-counter sale.

Process

You create cash sales using transaction code VA01. Once you save the sales document type, SAP automatically creates the delivery. You cannot save an incomplete cash sales document unless you maintain all the required entries. The customer may receive the delivery of the goods at the counter, they may pick up the goods from the warehouse, or you can even deliver the goods at the customer’s specified location. The delivery document can be configured to meet all these business needs. In a standard setup, though, it works as if the delivery is required at the counter.

Unlike the standard SAP process of taking the invoice printout from the billing document, the invoice printout for cash sales is generated from the sales document itself. The customer makes the payment against this document, and therefore the sales order number is also stored as a payment reference in the accounting entry for cash sales.

The billing for cash sales is an order-related billing; in other words, you create the billing with reference to a cash sales order and not with reference to the delivery document. Copy control for cash sales exists only between the order to delivery and the order to billing in standard SAP. While creating the billing document for cash sales, SAP also checks that the quantity ordered in the cash sales order should exactly match with the PGI quantity of the delivery. If the quantities do not match, you cannot create the billing document.

Since the invoice printout is generated from the sales document, the billing document is relevant only for posting the accounting entry. The accounting entry is passed into the revenue, and the offset goes to a cash account. If there are any cancellations, credit notes, returns, and so on, against cash sales, then that follows the standard SAP process.

Apart from the salient features mentioned earlier, the cash sales order cycle uses basic functions just like any other standard order. This includes an availability check, credit check, pricing, partner determination, and so on. Normally, for over-the-counter cash sales purposes, businesses use a one-time customer (account group CPD/CPDA). This helps them avoid the hassle of creating customer masters for cash customers.

Customization Settings in Cash Sales

In standard SAP, the sales document type CS with the default delivery document type BV and a default billing document type BV represents the cash cycle. You select the option for immediate delivery in the sales document type customization to achieve immediate delivery for document type CS. This triggers the delivery only the first time the document is saved, and therefore any changes in the quantity or any additions of new lines in the cash sales document will not create a subsequent delivery. So that the sales order for cash sales cannot be processed unless complete in all respects, the check box for an incompletion check is selected in the customization setting when assigning the document header incompletion procedure to the billing document type.

Item categories BVN and BVNN exist in standard SAP for cash sales. BVN is for a standard item, and BVNN is for a free-of-charge item. They both are relevant for order-related billings. This is what allows the document type CS to be created only with reference to an order and not a delivery. If you try creating the billing for CS using a delivery number, SAP gives you an error message telling you that you cannot generate a BV billing document from the BV delivery document.

To take the invoice printout from the sales document, output type RD03 is available in the standard output determination procedure for cash sales, which is V10001. To allow the retriggering of the invoice printout again if there is a change in the net value of the sales order, a requirement 14 is also assigned to the output type RD03 in the procedure V10001.

Copy control exists between the order to delivery (CS to BV) and the order to billing (CS to BV) to allow the delivery and billing documents to be created from the sales order CS. For the item-level copy control between order and billing, a copy routine 002 is assigned in standard SAP that ensures that the cash invoice is not created unless the quantity in the sales order CS matches with the PGI quantity of the delivery document CS.

Once the billing is created, the accounting posting happens by crediting the revenue, and offset entry is passed to the cash account. In general, SAP picks up the customer account from the billing document for offset entry, but in the case of cash sales, since the entry has to flow to the cash account, the account key EVV is assigned to the billing type BV when assigning the revenue account determination procedure customization. An entry for this account key, EVV, is then maintained in VKOA tables, and that triggers the accounting offset entry for the cash account for BV billing documents. Since the payment is collected against the invoice generated from the CS sales document, a reference of the same is required in the accounting entry being passed. This is achieved by selecting the value B in the assignment and the reference number field at the header-level copy control between order and billing.

Rush Orders

A rush order is a special order type provided by SAP to handle situations where you would like to create an immediate delivery from the sales order, for example, in same-day delivery scenarios. The moment an order is saved, a delivery document is created, and the warehouse can start processing the order. The billing for rush orders is created with reference to the delivery document, and the billing output is also generated from the invoice document.

From a customization standpoint, a rush order is like a mirror image of a standard order (order type OR); the only major exception is that the delivery document for a rush order is created immediately. You create a rush order using transaction code VA01. In standard SAP, the sales document type RO with default delivery document type LF and a default billing document type F2 represents the rush order cycle. You can still use all the item categories that you generally use with a standard order like TAN, TANN, and so on.

Consignment Processing

A consignment is a type of sales process where the goods are not sold to the customer in the first place. You manage the stock levels at a customer-consigned location. The customer consumes the goods on a needed basis from the location, and you bill the customer only for the goods consumed. The goods at the customer’s location are your property, and the transfer of ownership happens once they are consumed by and billed to the customer.

In SAP, the customer consignment location is represented by special stock locations within the plant, and the stock in these locations is tracked separately with a special stock indicator W (Customer Consignment Stock). The complete consignment cycle in SAP involves four document types. These document types are explained in the following sections.

Consignment Fill-Up

Consignment fill-up is the process under which you fill up the stock at the customer’s location. You create a consignment fill-up order using transaction code VA01. In standard SAP, the document type KB with item category KBN is available for consignment fill-up. The item category is relevant for delivery but not relevant for billing. When you do the PGI for a delivery for a consignment fill-up order, the consigned stock is moved from unrestricted stock to a special stock location. The ownership for the stock is still with you, and therefore there is no billing to the customer at this stage of the consignment sales cycle. Since the goods are moved within the plant from the regular storage location to a customer consigned location, there is no material valuation entry posted to accounting either.

Consignment Issue

Consignment issue is the process under which you bill the customer for the consumed stock from the consigned location. You create a consignment issue order using transaction code VA01. In standard SAP, document type KE with item category KEN is available for consignment issue. The item category is relevant for delivery and billing, and the special stock indicator in item category customization is set up to consume from special stock inventory W. The availability check is also performed against the consignment stock. When you do the PGI for a delivery for a consignment issue order, the consigned stock is depleted to the tune of the quantity delivered via the consignment issue order, and an accounting entry for material consumption is passed (cost of goods consumed). A billing document is generated with reference to the delivery document and posts the sales revenue into the accounting books.

Consignment Pickup

Consignment pickup is the process where you pick up the excess, slow-consuming, or unutilized stock from the consigned location and bring it back into your unrestricted inventory. You create a consignment pickup order using transaction code VA01. In standard SAP, document type KA with item category KAN is available for consignment pickup. The item category is relevant for delivery but not for billing. The special stock indicator in item category customization is set up to pick up from special stock inventory W. When you do the post goods receipt (PGR) for a delivery for a consignment pickup order, the consigned stock is depleted to the tune of the quantity picked up via the consignment pickup order, but no material-related accounting entry is passed because the stock is just moving from the consignment location within the plant to the regular storage location. No billing is created either.

Consignment Returns

Consignment returns is the process where you take returns for the goods that were originally billed to the customer via document type KE (Consignment Issue). You create a consignment returns order using transaction code VA01. In standard SAP, document type KR with item category KRN is available for consignment pickup. The item category is relevant for delivery and for billing. The special stock indicator in item category customization is set up as blank because the incoming stock is actually a customer return and not a pickup of your own inventory from a consignment location. When you do the PGR for a delivery for a consignment returns order, an accounting entry for a cost of goods sold (COGS) reversal is passed. A credit note is generated with reference to the delivery document, and it posts the sales returns entry into the accounting books.

Third-Party Order Processing

Third-party order processing is a type of sales process wherein your vendor directly supplies the goods to your customer, and you bill your customer for these goods on receipt of delivery proof from the vendor. The distribution of goods directly by your vendor to your customer provides you with benefits such as no inventory management, warehouse management, or transportation hassle; no storage cost; no special training or staff to handle the vendor’s product in your warehouse; and so on. Third-party processing provides your business, to an extent, with a low-cost approach toward achieving the same objectives as it would achieve by maintaining inventory in your own warehouse and distributing the goods yourself.

Process

As you can see in Figure 7-40, the process starts when you create a sales order with a line item relevant for third-party processing (a line item with item category TAS). SAP creates a purchase requisition (P/R) for this line item, which then converts it into a purchase order following the regular procurement process. The purchase order is released and is sent to the vendor, and the vendor supplies the goods to the customer and sends you an invoice for the goods delivered. You post the invoice receipt (I/R) against the purchase order via transaction code MIRO. This I/R then updates the VPRS cost and sales order billing status for the line item (I/R done—billing due), and the billing document is created for the delivered quantities as per the normal billing process.

Customization Settings

To support the third-party processing, standard SAP comes with item category TAS and schedule line category CS. Schedule line category CS contains the defaults for the purchase requisition type, item category, and account assignment and thus is responsible for triggering the P/R for the order line items. You can have one or more line items in the purchase requisition, depending upon how many schedule lines exist in your third-party line item in the sales order. So, a one-line item with two schedule lines means two individual line items in the purchase requisition.

Item category TAS comes with billing relevancy F, which means that the billing for the order item will be possible only when the I/R for the purchase order is posted. The indicator F also controls the billing status for the sales order, because the billing status remains not due for billing until you post the invoice receipt. This way, you bill multiple invoices to the customer based on the I/R quantities. Each I/R updates the invoicing status only for the quantity received by the I/R. If you don’t want to wait for the I/R posting for billing your customer, you can set up the billing relevancy for your third-party item category as B (relevant for order-related billing on the basis of the order quantity). In this case, the customer will be billed for the entire order quantity irrespective of the I/R processing.

You can configure SAP to do manual as well as automatic third-party order processing. If you normally fulfill the customer order from your own stocks and require case-to-case procurement only for a particular product via third-party processing, you can follow the manual process. In manual processing, you change the item category on the overview screen of the sales order to TAS, which then triggers the purchase requisition process. If you have a particular product that is always procured via a third party, you can set up an automatic process also. In an automatic process, you assign the item category group BANS on the Sales Data2 tab of the material master. In standard SAP, under item category determination rules, BANS is linked to item category TAS, and therefore when you create an order with a material having BANS, SAP automatically determines the item category as TAS.

When you create a third-party order, SAP takes into account the lead times for automatic delivery scheduling for the third-party line item in the sales order. This means that the time required by the vendor to deliver the goods and also the time taken by your purchasing department for processing the purchase order together impact the schedule line confirmation date for the corresponding third-party line item in the order.

When you create a purchase order using the purchase request corresponding to the third-party order line, SAP automatically updates the purchase order number in the document flow of the sales order. Any changes in the delivery dates or quantity thereafter in the purchase order automatically updates the confirmed quantity and confirmation date in the corresponding schedule line on the third-party sales order, but the reverse way is not allowed. Any changes in the quantity or date in the sales order does not change the purchase order quantity or delivery dates. It is therefore always suggested to make changes in the purchase order and not in the sales order. You can also use report SDMFSTRP to find any quantity differences that exist between the sales order and the purchase order.

If you want to copy any text from the sales order to the purchase order, enter that into the text field PO text at the sales order item level because this gets copied over to the purchase order item text field during the third-party processing.

Sales Contracts

A sales contract is a legal agreement that not only has all the essential elements of a sales order but also has a validity period. By signing a sales contract, the seller agrees to supply the goods and services to the customer, and the customer agrees to receive and pay for the goods and services as per the terms and conditions of the contract. The breach of a contract has its own consequences and can lead to penalties and other related fees. Because of its legally binding nature, a sales contract provides an exact picture of the current period of revenues and the future period of revenues and thus also serves as a revenue assurance tool to the companies.

A sales contract in SAP is nothing but another sales document type you define via transaction code VOV8, but with a few more functionalities that are made possible by the use of the set of fields available specifically for contracts.

You create a contract document in SAP using transaction code VA41 or menu path Logistics ⇒ Sales And Distribution ⇒ Sales Contract ⇒ Create. You can create a contract for goods as well as services. Unlike a sales order, a contract document does not contain a schedule line or requested delivery date. You maintain the validity of the contract using the Valid From and Valid To fields available at the header level on the contract entry screen. You can maintain the contract validity at the header level, and this validity is then applicable to the complete document. To capture the contractual data into a contract sales document, SAP provides a contract tab in the sales document customization transaction VOV8. To activate this contract tab for your document type, you need to make a selection when customizing the contract document type, as shown in Figure 7-41. You can have a header pricing procedure and an item pricing procedure for a contract. A contract in SAP can lead directly to a billing document (such as service contracts) or can be copied to an order followed by a delivery and then a billing document (quantity contracts).

Let’s take a look at these customizing fields in VOV8:

Pricing Procedure Condition Header/Pricing Procedure Condition Item Unlike a sales document, where you generally set up a pricing master record before creating the transactional sales document, the pricing for a contract can be set up while creating the contract document itself. This is really beneficial in situations where you sign up a fixed lump-sum value contract with your customer, leaving very limited space for setting up masters because each contract has a different price, and it does not follow any price list/rate card. Sometimes a service sale that includes a variant configuration also comes under this category. The header pricing procedure PABR01 with condition type PKAR and item pricing procedure PABR02 with condition type PPAR and PPAG are provided in the standard SAP system for such purposes. When you create the contract, the pricing is saved with a reference of the contract number.

Contract Profile Here you assign the default contract profile for your contract document that in turn controls the contract start and end dates rule, default validity period for the contract, cancellation procedure to be used when the contract is cancelled, subsequent action required in case the contract is expired or about to expire, and action date rule that calculates the date when that subsequent action is supposed to take place. You set up these date rules and the contract profile when customizing the contract data using menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data.

Billing Request Here you assign the billing request type that you would like to use to initiate the billing processing for your contract document.

Group Reference Procedure This field is relevant for the master contracts document setup. Here you assign a reference procedure that defines the rules according to which data from a master contract is copied over to lower-level contracts.

Contract Data Allowed Here you define whether your sales document type should allow the contract data screens to show up when you are entering a sales transaction using your sales document type. You can choose X to allow the contract data for the sales document, you can use Y to force the item contract data to flow from the header contract data, and you can leave the value in this field blank to suppress the contract data screens for your sales document type.

Follow Up Activity Type When a contract document is about to expire, you can use the follow-up action work list to trigger the subsequent follow-up activity. For example, you may define the follow-up activity as creating a quotation or mail to the account manager, or initiating a telesales call to customer, and so on. In SAP, follow-up activities can be identified based on the follow-up activity types. Here you enter the follow-up activity type that you want SAP to propose when you run the follow-up work lists.

Subsequent Order Type When you run the subsequent processing for an expired contract, SAP uses this field to automatically propose the default document type for subsequent processing such as a quotation for a new contract.

Check Partner Authorizations This field is used with quantity contracts with release orders. In real world, there may be situations where a customer may designate only a few branch offices to make a release against the sales contract, and therefore SAP provides you with the field check partner authorizations in the sales document type customization. If you select A in this field, SAP allows any partner in the quantity contract with partner type AG (sold-to party) or AA (party authorized to release) to release the contract. Selecting B in this field allows any partner to release the contract who holds a lower position in the customer hierarchy than the sold-to party of the contract. Leaving this field blank makes it wide open for any partners to release the contract.

Update Lower Level Contracts This check box is provided in SAP for master contracts. If you want to update the flow when a master contract is copied to a lower-level contract, select this check box in the customization of the master contract.

Common Customizations in Sales Contracts

We’ll now explain the various customization settings that are common for all the contract document types.

Define Validity Period Category

The validity period category is a two-character key that SAP uses to propose the validity periods in a contract. The key is assigned to a contract profile from where it defaults to the contract document. You can use the validity period category as one of the key terms in pricing determination for contracts and also in statistical evaluations on contracts.

You can define a validity period category key by using transaction code VOVO or by following the menu path IMG ⇒ Sales And Distribution ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Define Validity Period Categories. Figure 7-42 represents the customization screen for defining the validity period category.

To define your own validity period category, provide a two-character identification key starting with a Y or Z. Specify a validity period value and the unit for the validity period in the Val.Period and Unit Val.Period fields, and provide a meaningful description for your validity category. Available choices for Unit Val.Period are 1 (day), 2 (week), 3 (month), and 4 (year). For the Z5 validity period category in Figure 7-42, we maintained 2 as the validity period, chose 4 as the unit for the validity period, and provided a description, thus creating a two-year validity period represented by category Z5.

Rules for Determining Dates

Here you define the rules for determining the start and end dates for your contracts. The transaction code is VOVP, and the menu path is IMG ⇒ Sales And Distribution ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Define Rule For Determining Dates. Figure 7-43 and Figure 7-44 show the two-date determination rules that were defined for Galaxy Musical Instruments. Rule Z2 is for determining the end date for the contract as today’s date + two years, and rule Z1 determines the date when a follow-up action on the contract should be due, in other words, two months prior to the contract’s end date. Both the rules use factory calendar ZZ – factory calendar US (the one we defined in Chapter 2, “Enterprise Structure”) to determine the number of working days.

Controlling Contract Cancellations

Here you define the cancellation rules for your contracts. The setup activity involves setting up cancellation reasons, setting up cancellation procedures, setting up cancellation rules, and assigning cancellation rules to cancellation procedures.

Defining cancellation reasons Here you define various cancellation reasons that exist in your organization for terminating a contract. Once defined in customizing, you can use these cancellation reasons in contract documents to cancel a particular line item or to cancel a complete contract document. The transaction code is VOVQ, and the menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Control Cancellation ⇒ Define Cancellation Reasons. Figure 7-45 shows various cancellation reasons we created for Galaxy Musical Instruments.

Defining cancellation procedure A cancellation procedure is a four-character key that controls the cancellation process for a sales document. The transaction code is VOVM, and the menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Control Cancellation ⇒ Define Cancellation Procedures. Figure 7-46 shows the cancellation procedure that we created for Galaxy.

Defining cancellation rules Here you set up the contract’s cancellation-specific rules. The transaction code is VOVL, and the menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Control Cancellation ⇒ Define Cancellation Rules. Figure 7-47 shows the cancellation rule we created for Galaxy.

Assigning cancellation rules to cancellation procedures Finally, you assign the cancellation rules to cancellation procedures. The transaction code is VOVN, and the menu path is IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Control Cancellation ⇒ Assign Cancellation Rules And Cancellation Procedures. Figure 7-48 shows the cancellation procedure assignment for Galaxy.

Contract Profile

A contract profile controls the contract start and end dates rule, default validity period for the contract, cancellation procedure to be used when the contract is cancelled, subsequent action required in case the contract is expired or about to expire, and action date rule that calculates the date when that subsequent action is supposed to take place. You set up these date rules and contract profiles when customizing the contract data using menu path IMG ⇒ Sales And Distribution ⇒ Sales ⇒ Sales Documents ⇒ Contracts ⇒ Contract Data ⇒ Define Contract Profiles. Figure 7-49 shows the contract profile defined for Galaxy Musical Instruments.

Quantity Contracts

A quantity contract is a type of contract where your customer agrees to purchase a certain quantity of your product within a certain period of time but the information related to delivery scheduling, such as when, where, and how many quantities will be required, might not be available at the time of the contract. This delivery scheduling information is provided later by the customer as individual purchase orders referring to the sales contract. An example of the quantity contract is when, to get bulk-purchase benefits (discounts, for example), your customer’s head office signs a sales contract with you for a certain quantity of your product, at a particular rate, and with a year validity, but you receive the delivery schedule information from the individual branch offices in the form of release orders against the contract, as and when they require the product in the next one-year period.

In SAP, you handle the quantity contracts via document type CQ. Figure 7-50 shows the processing of a quantity contract in SAP. The process starts with the creation of a quantity contract using the document type CQ by providing all the necessary information into the contract such as the customer, contracted quantity, validity period, contracted rate, and so on. The contracted quantity of product is maintained in the target quantity field in the quantity contract. When you receive the individual customer purchase order, you create a release order with reference to the quantity contract using order type OR. SAP then maintains the released quantity in the order quantity field in the quantity contract, thus providing you with a control over contracted vs. released quantity. This also helps you in booking and backlogs reporting for quantity contracts. The release order also updates the document flow and is later processed like a normal sales order falling into delivery and billing.

Service and Maintenance Contracts

A service contract in SAP is used to record and process service-related transactions between the service provider and service recipient. These transactions can be periodic in nature or once-off services. Here are some examples:

• Periodic flat-rate services such as billing for monthly gym/club membership fees, monthly flat-rate contracted cell phone charges, monthly Internet/cable TV/telephone service usage charges, tuition fees, and any other such services that are billed periodically at a flat rate.
• Milestone-based billings on the completion of an event.
• One-time services such as installing and commissioning equipment at the customer site, performing a repair on a product, giving product-related service call/phone support, and providing professional services such as consulting, medical, legal, and so on.

You create a service contract in SAP using contract maintenance transaction code VA41. The document type for a service contract available in standard SAP is SC. Like any other contract, you can use validity periods and cancellation procedures in service contracts to handle the contract validity and cancellation processing. Service contracts do not involve a delivery document or schedule line category setup. These contracts are billed directly from the contract just like any other order-related billing documents. You can use the SC contracts with or without billing plans. Standard SAP provides the item category WVN, which is preconfigured for use with services that require a billing plan. You can have service contracts created with a milestone billing plan or with a periodic billing plan (refer to Chapter 9 for more details on billing plans).

Depending upon your business requirement, you may configure a service contract to bill services in advance or in arrears, on periodic time buckets, as one-time once-off charges, or on an event/milestone completion basis. A service contract also provides you with the flexibility of separating the revenue from the billing. You can bill the customer in advance or arrears and can recognize revenue separately in accounting in periodic buckets. We discuss revenue recognition in detail in Chapter 10.

When used with the customer service module in SAP, a service contract can be linked to technical objects (equipment, serial numbers, and functional location) and helps in storing the warranty information for a serialized unit. This information can then be used for validating warranty- and service-level coverage in the event you receive a service request for the product from the customer. Standard SAP provides material type DIEN for service items.

Summary

In this chapter, we walked you through the various details of a sales document. We covered the use of sales documents in the SD cycle, its structure, and its customization. We also discussed various sales-related business processes and the sales document types that are available in standard SAP to support these processes. In next chapter, we’ll discuss shipping and transportation processing.