Pricing

The price is a very important function in SAP. It can also be very difficult to grasp, but the underlying concepts are fairly simple. Prices of items are determined mainly by a process called the Condition Technique. The technical situation is so called because it operates using a set of conditions or elements that work together to determine the price of an item.

In SAP, the technique is used to organize and manipulate the key elements that determine the price of the material to arrive at an overall price that includes the basic price, discounts, surcharges and taxes.

The price of a line (that is, a variable amount of material) is determined by a combination of 5 elements. They are:

1. The sale
2. The type of document
3. The sales organization
4. Division, and
5. The distribution channel

Combining these elements with the base material determines the total price.

Pricing Procedure

A price is determined for a material through the use of a pricing procedure, the highest level element of pricing. Each item uses a specific pricing procedure, determined by a unique combination of the five elements above. This selection is set up in the Implementation Guide (IMG).

To see how the pricing procedure for a transaction is made goto Tools –> AcceleratedSAP –> Customizing –>Project Management –>SAP Reference IMG –>Sales and Distribution –>Basic Functions –>Pricing –>Pricing Control –>Define and Assign Pricing Procedures –>Define Pricing Procedure Determination or use the transaction Code: OVKK.

The pricing procedure is unique for the sales area, plus the document pricing procedure key A, and the customer pricing procedure key 1. The document pricing procedure key is in the header of the sales document, while the customer pricing procedure key is in the customer master record. This adds up to the five elements described previously. The field to the right of the pricing procedure is the condition type automatically proposed by the system.

Condition Types

The condition type is at he heart of the condition technique in SAP R/3. Essentially, a condition represents a major aspect or representation in R/3 of pricing activity in your organization. For example, there may be a condition type for the basic price of a material, there may be another condition type to determine a material discount, a customer discount, or a sales promotion. A material’s price might then be determined by a combination of condition types used within a pricing procedure.

To examine existing condition types, as used in an order, do the following:

• Pull up a previously created order
• Click in the box to the left of the item.
• Select Item –> Pricing F7 from the menu.
• Click on the button and examine the header of the next screen.

Returns and Credit Memos

Customer dissatisfaction with some percentage of provided products and services is an unhappy fact of life in organizations. When this occurs, the sales organization is required to provide solutions to clients in a variety of ways. In some cases, the customer may just try to return the product for credit. In other cases, the product may be damaged in transit, and it is not worth returning to the organization. In this case, the client may request the credit for the damaged equipment. Both scenarios are the subjects of the two following years.

When a customer requests for a return, it is treated as a type of order and handled in R/3’s sales function. While products may be returned in R/3 without a corresponding past order, in our example, we will assume that a previous order has been placed and is being returned.

A credit memo is also treated as a type of order and handled in R/3’s sales function. In this instance, the customer may have received a product that was damaged or ruined on delivery. Hence, it makes little sense to return the actual product or material, given that the customer’s version of events is accepted. We likewise assume that a previous order has been placed and credit is being sought.

Availability Check & TOR in Sales

in SAP, Availability check is one of the key functionality in sales document processing. The confirmation of delivery of goods to customer while entering a sales document is carried out on the basis of this check. Availability check can be carried out on the deadline of goods availability that would be necessary to consider the picking, packing and shipping time. Availability check can only be carried out if transfer of requirements take place for goods from sales to purchase or production.

Requirements generated in Sales & Distribution need to be transferred to material requirements planning to ensure the quantities ordered are available to be delivered on time to Customer. This is called transfer of requirements (TOR).

Understand more about

1. Types of Availability Check
2. Replenishment Lead time
3. Control parameters
4. Scope of check
5. Process flow
6. Transfer of Requirements in SD
7. Control elements in TOR

download the document on Availability Check & Transfer of requirements_Sales (610)

Availability Check in Delivery

Availability check in SAP Delivery is initiated during creation and check is done for the picking date. The check is carried out on the same criteria as in Sales order processing. Availability check at delivery level is carried out for following reasons. Check may not have done for items at order level and hence needs to be done at delivery stage. Although check may have been carried out in order the availability situation may have changed due to various unknown reason. Dynamic check at this stage would ensure correct status in termsof availability so that further actions after delivery i.e. Picking, Packing etc are not affected.

Control elements for availability are same as in sales documents

• Checking Group
  Checking group specifies in combination with checking rule the scope of availability check. It is maintained in material masterin Plant view and copied on to sales documents.
• Checking Rule
  A Checking rule is assigned to each transaction and in combination with checking group define what movements are considered for availability check. These are predefined in system
• Delivery Item category
  Additional check exists at delivery item category level to control if availability should be checked or not.

Prerequisites

Following prerequisites need to be fulfilled for availability check to take place

• Control elements in Sales and Distribution are maintained in customizing and assigned.
• Availability check switched on at requirement class and deliveryitem category level.
• Plant should be defined at document item level.
• Checking group should be maintained in material master on Sales/plant screen in Availability check field.

Scope of Check

Elements that can be included in availability check are

• Stock
  • Safety Stock
  • Stock in Transfer
  • Quality Inspection stock
  • Blocked Stock
• Inward/Outward movement of goods
  • Purchase orders and requisitions
  • Planned orders and Production orders
  • Reservations
  • Dependent requirements
  • Sales and Delivery requirements

The elements that need to be included depend on the scenario for which availability check is being set.

Process Flow

System determines date for availability check on basis of earliest material availability date of all schedule lines in delivery.

If there is insufficient stock following is system behavior

• Sufficient quantity of material not available by material availability date, a delivery quantity ‘0’is entered in delivery. If item category of delivery permits ‘0’quantity then it would be included else item would not be allowed in delivery.
• Quantity available of material is lower than order quantity, system would enter available quantity as delivered quantity and order would get updated accordingly. If partial delivery is not allowed, this would be noted in delivery creation log.

Billing in Sales and Distribution

In SAP Sales & Distribution, Billing represents the final processing stage for any business transaction. Billing is linked with Order and delivery processing and information is available at each stage.
Billing transactions can be assigned a specific sales area from where the bill would be generated towards the customer. An interface to Accounting exists from Billing hence company code needs to be associated with Billing document.

Billing Document is always created with reference to a preceding document, either an Order, Delivery or Credit/Debit memo request.Billing documents have following structure.

• Header
  Header data has information valid for entire document like Payment terms, Document currency etc.
• Items
  Items contain data like Material no, billing qty Net value of item, weight volume etc.

Billing document is controlled by Billing Type. Major functions in Billing are controlled by Billing type. Different billing types are provided in system for different business transactions.

• F1 Order Related Invoice
• F2 Delivery Related Invoice
• F5 Proforma Invoice
• G2 Credit Memo
• L2 Debit Memo
• S1 Cancellation Invoice
• IV Intercompany Invoice

Methods used in Billing

• Individual Billing Document :A single Billing document is created for each sales document, example one Invoice per delivery. In copy control routine can be defined to have an individual billing document.
• Collective Billing: Collective Billing combines different documents (orders / deliveries) into a single Invoice document provided certain data specified is common across these source documents. The Header data appearing in billing document must be same.

Invoice Split

Split Invoices are to be created separately according to some predefined criteria even for items originating from same source document invoice split can be used.In copy control requirements can be defined with split criteria to ensure sales orders or deliveries are not combined into a collective billing document.

Integration into Accounting

Integration of Billing Document in Sales & Distribution with Accounting is one of the main integration points in system. Here integration consists forwarding billing data to Financial Accounting (FI –Accounts Receivable) & Controlling (CO) module. On creation of billing document system can automatically create documents for General Ledger (G/L) in FI-AR, Profit Center, Profitability Analysis (CO-PA) & Cost Accounting. System can post entries from Billing documents to relevant accounts via ‘Account determination’. Costs and revenue can be posted to following accounts

• Customer Accounts receivables.
• Revenue accounts
• Sales deductions
• Accrual accounts for rebates etc.
• General Ledger accounts.

Reference number and Assignment number can be carried from Billing document to Financial document to be used as reference when incoming payments are posted from customer. Billing document can get blocked for accounting for two reasons i.eif it is set in customizing to block for the billing type or if errors occur in account assignment. System has provided with a tool to analyze errors in account determination with which errors can be corrected and billing document released to accounting. For certain Billing documents or certain scenarios it is required that Billing documents be first checked by relevant authorities prior to releasing it to accounting, in such cases automatic block is setup in customizing.

In integration with Controlling, costs and revenues from billing document data can be transferred to following sub-ledger accounts

• Profit & Cost center
• Extended General Ledger
• Make-to-order Sales orders
• Profitablity(CO-PA)
• Projects

Customization for activation of Controlling area and integration needs to be setup for transfer to take place.

Invoice List

Invoice List is a functionality within billing provided by system to create, at specified time intervals or on specific dates, a list of billing documents, to be sent to a Payer. Billing documents in Invoice list can be individual or collective documents.

Standard system includes two type of invoice lists:

• LR –For Invoice and Debit memo’s
• LG-For Credit Memo’s Invoice

Billing Plan in Sales and Distribution

In SAP, various business scenarios there is requirement to Bill customers on some specific dates or specific periods, this is achieved by Billing Plan in system.A Billing plan is a schedule of individual billing dates for single item, it can also be defined at Header level applying to entire sales document. In System there are types of Billing plans –Periodic & Milestone billing plan, which are used depending on the business scenario.

Billing plan processing in system has following functions available:

• Automatic Creation of Billing dates
• Pricing
• Billing Block
• Billing rule in case of Milestone billing
• Billing status
• Exchange rate determination

These functions are available at Item level and also at Header level so that they can be applied to all items in the document.

Periodic Billing

It means billing a total amount for each individual billing date in the plan defined. Like in a rental contract with a customer, system would propose schedule of monthly rental payments.

• Start & End dates, Period (monthly, quarterly, annually), Horizon are important for billing date determination.
• These dates can be proposed by system based on settings in customization for Billing plan type Alternatively they can be manually changed in sales document.

Milestone Billing

It means distributing total amount to be billed over multiple billing dates based on specific milestones defined. This is used for billing projects like Construction or Engineering, which involve milestones marking completion of different stages of work. For Each billing date in milestone billing plan, it can be specified if date is Fixed or always updated with actual date. Updated with actual date if date is earlier than planned date.

Billing Plan Controls

Following parameters in customizing control Billing plans in Sales:
Billing Plan Type: Basic control of billing plan is by Billing plan type. It contains the rules for date determination for start & end dates of billing schedule. It also contains rule for determining horizon for the plan.
Standard system has following billing types:

1. Milestone billing
2. Periodic billing

Date Description: These are for information purpose to describe the various purpose for billing plan usage.
Date Category: Date category in turn defines Billing rule, Date description, Billing block, and is used to define data for each billing date that appears in billing plan.
Proposed Date Category: Default date category assigned to Billing plan type by which it can be proposed by system in billing plan.
Proposed Date: Used in Milestone billing where a proposal can be used as reference during order processing and changed as required.

Complaints and Returns in SAP SD

In SAP Sales and Distribution, Customer complaints are a part of any sales cycle in business. Complaint processing and resolution thus need to be covered in system and in long term lead to customer delight. In Sales & Distribution there are various methods provided for processing Customer complaints depending on the scenario. Analysis for complaints is also provided in system as standard feature.

Free of Charge Subsequent Delivery
If a Customer complains of receipt of wrong quantity, additional quantity can be sent free of charge via this sales order.Although it is called FOC Subsequent delivery it is a sales order which is created with reference to original sales order and involves further delivery creation.In Standard system ‘SDF’isorder type for Subsequentdelivery free of charge.

Returns

Returns are a normal part of sales in any business. A return in system is a sales document used in complaint processing when customer sends the goods back due to various reasons.

• If customer sends goods back which had been sold a return is created in system along with reason for the material.
• Goods are taken back in stock and a credit memo is issued to customer for the amount billed after verification of complaint and goods is carried out.
• Return is another type of Sales document and is processed similar to sales documents

Debit memo Request

Debit Memo Request is a sales document used in complaints processing to request debit for a customer. If for example the price calculated for a customer was too low due to some reason, a debit memo request can be created. Debit memo request is like another sales document like standard order which is used to create the debit memo when the amount is actually debited to customer. DR is order type for Credit memo requests in standard system.

Blocking or Rejecting Complaints

Blocking Complaints
In system via customizing it can be set to have default delivery or billing blocks for such order types used for complaint processing. This control feature allows checks to be carried out on complaints before processing.
Rejecting Complaints
Various reasons of rejection are available which can be used to reject complaints at Item level in sales order. These can be communicated to customer via outputs.

Credit Management in SAP SD

Credit Management enables you to minimize the credit risk yourself by specifying a specific credit limit for your customers. You can take the financial pulse of a customer or group of customers, identify early warning signs, and enhance your credit-related decision-making. Credit control area is basic organizational unit that represents the area where customer credit is awarded and monitored.

Types of Credit Check:

• Simple check
• Automatic credit check –It has additional checks for credit control

Transactions related to Credit Monitoring

• Credit Overview for company code –F.31
• Customers with missing credit data –F.32
• Blocked SD documents –VKM1
• Release of blocked Sales order –VKM3
• Release of blocked deliveries –VKM5

Delivery Processing in SAP Sales and Distribution

Delivery forms the central object in Logistics Execution module. Outbound delivery supports all shipping activities like Picking / Packing, Transportation & Goods Issue. In outbound delivery process planning of shipping information is recorded and further activities like delivery scheduling etc. are initiated. Outbound delivery is created with reference to Sales order, Stock Transport Order, Subcontract order, Project or without any reference. In standard cycle Outbound delivery connects the sales order to billing and forms core part of Shipping activities.

Structure of Delivery

Delivery structure in system like any other sales document consists of Header and many items as visible in following figure.General data for entire document like shipping point ship-to party, route is at Header level. Data like material number,delivery quantity, plant &storage location specifications, weights & volumes of individual items etc. are in Item level data. Delivery document in system has a user friendly interface which facilitates easy navigation and switching between screens. Important data in a deliveries is contained in following three screens which in turn have several tabs.

• Overview Screen
  Presents user with main Header data of document and links to other screens to which user can navigate.
• Header Screen
  Screen has tab of various important header data which applies to the entire document. Eg. Of tabs shown below
• Item Screen
  Item screen displays data on individual items in a delivery. Item screen also has various tabs containing various relevant data.

During delivery creation data is copied from master records or previous documents in process flow. When delivery is created without reference, data from Ship-to party and material master is picked up. When delivery is created with reference, data is picked up from preceding document.

Delivery Types

Basic control of outbound deliveries is based on delivery types. Various delivery types are provided in system to cater to varying business scenarios:

LF Outbound Delivery
LO Outbound Delivery without reference
LB Delivery for subcontracting
LR Returns Delivery
NL Replenishment Delivery
NLCC Replenishment Cross Company
EL Inbound Delivery

Delivery Item Categories

Item categories in delivery control item behavior, these are copied from order item and same as item category in sales order. When delivery is created without reference they are determined in delivery via item category determination. Some standard delivery item categories are as under:

• TAN Standard Item
• TANN Free of Charge Item
• TATX Text Item
• DLN Standard item without reference
• KBN Consignment fill-up
• KLN Service free of Charge
• TAXT Text Item

Delivery Features

Partial & Complete Delivery

In business scenarios customer specifies if complete or partial delivery of order is acceptable.

• Complete Delivery: Complete delivery for a customer can be marked by indicator in Customer master or Sales order header, thereby when system creates delivery message is displayed if user tries to create partial deliveries. Indicator is ‘X’.
• Partial Delivery: If Customer allows for partial deliveries for an item, corresponding indicator can be setup in Customer master Shipping data or in Sales document header.

Order Combination
This is actually a feature in Order to combine orders, order items or partially deliveries of individual order items in one delivery if this is agreed with customer. Order combination indicator has to be setup in Customer master or order header & order items & schedule lines must have following common criteria

• Shipping point
• Ship-to party
• Incoterms
• Sales Organization

Delivery Groups

Outbound deliveries can be combined into groups. These grouped deliveries can then be identified by group number. These groups are created manually and utility of these groups include that outputs can be processed for entire group or group can be processed for picking etc. An outbound delivery can belong to several groups if required.

Free Goods in SAP SD

In Sales processing in various Industry sectors it is required to supply certain goods for free additionally or supply customer with a portion of goods for free. Free Goods functionality in system caters to these requirements and enables business to enhance sales operations.

Different Types of Free Goods

Inclusive Bonus Quantity:
In this type of Free Goods, the customer only pays for some of the Goods ordered, rest of goods being free of charge. This is also called as Inclusive free goods. Two options are available in system for Inclusive bonus quantity. The quantity of free goods can be shown as a separate item or be included in the same line item in sales document.

Exclusive Bonus Quantity:
In this type the customer pays for the goods ordered and is additionally given extra goods free of charge. So in this case, a larger quantity is delivered than ordered and additional quantity delivered is not charged. The material supplied additionally need not be the same as materials ordered in this case.

Process Free Goods

For Free goods processing condition needs to be set up in system. ‘NA00’is Free goods condition type available in standard system. Conditions are maintained by standard Condition technique and can be maintained at various levels i.e. Customer/Material, Customer Hierarchy/Material etc. Free goods agreement is setup with validity period and various controls are available for system behavior of free goods while maintaining condition records. These are explained in user guide. Based on condition records set, these are automatically determined in Sales order and can be copied on to Delivery and Billing document as separate line items. An item in sales document becomes free of charge when 100% markdown is applied on the item. With this the prices are visible however there is no net price applicable. Standard system contains condition type ‘R100’for this purpose.In Inclusive Free Goods case without item generation the total price is adjusted in a way to effectively have no charge for quantity of free goods in the item. This is controlled by a condition ‘NRAB’ available in system and assigned in pricing procedure.

Material Determination in SAP SD

In SAP Sales and distribution When a product is under engineering change or there is a bug and you have another product, which is acceptable as replacement, then material determination can be used to set this scenario. Old product can be replaced by new product as per the launch date of the product. Material determination is also called as “Product selection”.

It uses condition technique for material. Material determination procedure is based on the sales document type. With condition technique, criteria can be defined and condition records can be maintained. Standard material determination procedure for order type OR is A00001. Standard material determination condition type is A001.

With standard setup, condition record for swap materials is maintained for “material entered”. It means in standard SAP, material determination is triggered when material is entered in the sales order. Additional criteria can be added by customizing condition type A001. Material condition records are maintained in the main transaction menu in master data.

Swapping can be based on certain business conditions. These are called as Substitution reasons. For each substitution reason, you can define substitution strategy. SAP System will automatically replace product as per material determination record after carrying out availability check or can give list of substitute products for users to check and select or replace material without availability check.

It can also control whether both substituted and substitute material can be displayed in the sales order or only substitute material is to be displayed in the sales order. It controls printing of substituted or substitute material on output types like order confirmations. In delivery, no material determination is carried out for items copied from the order. Material determination in a delivery is carried out for new items if material determination has been activated for the corresponding sales document type.

Incompletion Log during Sales Order Creation

The data entered during the Sales document creation flows to the subsequent documents like delivery & billing. Hence it is important that data required for further processing is not missed out. System usually proposes most of the data from various master records, however some important data or proposed data can be entered / modified manually. To guarantee that important data is not missed out in sales document creation, SAP system has provided with Incompletion logs where such missing data is logged and can be pointed to user for completion.

Incompletion log is a useful tool which can be used by users to have all the necessary data maintained in sales document.What data should be checked in which sales document is controlled in customizing and differs among the type of sales document. The controls in customizing also present a user friendly option of taking the user to relevant screen to complete the missing data. Saving a sales document with incomplete data also depends on the type of sales document. Example an incomplete quotation can be saved but not a sales order.

SAP Sales and Distribution Tasks

1. How to carry out availability during sales and shipping?
2. How to Create a billing document and billing plan?
3. How to work with Complaints and returns?
4. How to maintain customer master?
5. How to work with Delivery creation and delivery scheduling?
6. How to provide free goods discount?
7. Working with incomplete sales documents?
8. How to work with inter-company sales scenario?
9. Working with Listing and Exclusion
10. Listing the sales documents
11. Working with material determination
12. Working on material master creation
13. Output controls
14. Partner determination in Sales and Distribution
15. How to handle pricing in deliveries
16. Overall pricing user guides
17. Revenue account determination in Sales & Distribution
18. How the routes are determined in the sales orders
19. Sales Order creation and change
20. Viewing sales documents blocked for billing or delivery
21. Working with taxes
22. working with third party processing

Download the documents on SAP SD Sales and Distribution End User Manuals (798)

Partner Determination in SAP SD

Any business operation involves contact between many legal and other persons who interact between each other and business entity to perform various functions. Partner determination in Sales & Distribution helps in display of these business partners in various business transactions and their relationships in the system. It contains a set of rules that govern how system works with business partners during transaction processing.

Partner determination in sales and distribution can be set up for the following activities:

• Customer Master
• Sales Document Header
• Sales Document Item
• Delivery
• Shipment
• Billing Header
• Billing Item
• Sales Activities (CAS)

Partner Type is required for classification of partner functions in few basic categories. Any new partner types created needs to be assigned a partner type and one thing to note is that partner types are delivered with system and no new ones can be created like Customer (KU), Vendor (LI), Contact person (AP) etc., Partners belonging to multiple partner types require corresponding no of master records, eg. If a partner buys as well as sells goods/services to business entity it requires creation of both customer and vendor master records.

Partner Functions

Partners can be assigned to partner functions in Customer master record which can be determined in subsequent sales documents. For a customer some partner functions are made obligatory for processing of sales documents, this is controlled in customizing. (refer Customizing guide) Partner functions are classified or grouped using partner types, eg. Customer, Vendor, Contact Person, etc. Partner functions in system are represented by two character code which can be alphanumeric, eg. SP (Sold-to Party), SH (Ship-to Party) etc.

Partner Determination Procedure

There are various partner objects like Customer master, Sales document, item category etc. A partner procedure can control which partner functions would be available or are required for a partner object. Various partner procedures can be created in the system for the partner objects. Each Partner object has particular key to which partner determination procedure is assigned, eg. For Customer master it is assigned to Account group, for Sales document header it is assigned to Sales document type. In the partner determination procedure there are various controls against the partner functions which determine how the partner is determined and behaves. Like, Partner function can be made mandatory, It can be controlled if Partner can be modified or not and Source and origin of partner can be controlled. Also, SAP system has predefined partner procedures, these can be utilized or new created based on specific requirements.

Working with Payment Cards in SAP

Payment Card is used for cash-free payment used in variety of business transactions, from buying goods at local store to procuring goods and services on behalf of company. Payment Cards are nowadays indispensable to customers and an important mode of payment for business. Payment Card processing in SAP system offers a wide range of functions in Sales & Distribution, integration of payment card activities into sales, delivery & billing. Exchange of information with clearing houses for authorization can be set up during sales processing.

In Sales & Distribution, Payment card is entered in sales order and used throughout cycle.

Main payment cards categories used in system are:

• Credit Cards: Used for purchasing with regular billing & extended credit.
• Customer Cards: Used to buy goods from specific merchant or group of merchants.
• Debit Cards: Used to purchase with direct debit from bank account.
• Procurement Cards: Issued on behalf of companies to employees for purchasing items up to a given amount.

In Sales order system provides option of entering one payment card for entire amount or using multiple cards to split amount value in case of credit limit being reached on single card. System has checks to ensure that card entered corresponds to numbering system of card company. System also checks for expiration date and issues warning for near term expiring cards. A message is issued when authorization of card is successful, on failure order is blocked.

Delivery document does not carry any card information directly. System does check following information in delivery relevant to payment cards. All expired authorizations are detected and reauthorized. Any changes to delivery quantity are covered by authorizations that were granted in sales order. In case authorizations are not valid anymore, system sets the status in Sales order for delivery as ‘Not Approved’.

Payment Card attached to Billing header in billing document contains items with detailed card information. System copies this information from Sales Order and determines. Cards to be billed from payment card plan. The order in which they are to be billed. Billing amounts on each card in case of multiple cards. On release of billing document to Accounting, payment card data , billing amount & authorization information is copied on to accounting document for settlement.

Payment card interface acts as a bridge between SAP system and financial institution’s software. Interface system has supports following features:

• Converting data from SAP system to financial institution’s structure.
• Communication protocols between payment card application server and financial institution.
• Converting data from financial institution’s structure to SAP system structure.
• Time out scenarios etc.

All major clearing houses and financial institutions are covered for transmitting card data.

Revenue Account Determination

When billing data is transferred from SD to FI-AR (Financial Accounting –Accounts Receivables), G/L Accounts for posting sales revenue, sales deductions, freight, taxes,can be determined automatically

• Different criteria can be set for account determination like
• Chart of accounts
• Sales organization
• Account assignment group for payer
• Account assignment group for material
• Account key

Account assignment group of payer allows to do certain postings for a customer or group of customers to specific G/L accounts. like, Discounts offered to corporate and retail customers can be posted to different G/L accounts so that they can be tracked separately.

Account assignment group of material allows to do certain postings for a material or group of materials to specific G/L accounts. like, Sales revenue for bye-products need to be posted to G/L account different than for the main products so that revenues can be evaluated and reported differently.

Account keys are assigned to condition types in pricing procedure. Some of the standard account keys are ERL- Sales Revenue, ERS – Sales deduction & ERF – Freight Value.

Standard system has Account Determination procedure ‘KOFI00’available with following condition types:

• KOFI –Without controlling
• KOFK –With controlling

Account determination takes place during posting of billing document to Financial Accounting. Account determination procedure is assigned to billing type from where the revenue account determination is triggered.

Sales Order Processing

SAP Sales order processing is at the core of Sales & Distribution module. Sales allows execution of various business transactions which get recorded in system as sales documents. There are four basic groups of sales documents:

• Customer Inquiries and quotations
• Sales orders
• Agreements like contracts and scheduling agreements.
• Complaints like returns and credit & debit memo requests.

Sales order processing in turn triggers basic functions like availability check, pricing, credit check etc. Other subsequent documents like delivery & billing can be generated from sales order based on business requirements.In SAP system the sales order is linked with previous and subsequent documents like a chain and can be viewed in document flow storing history of events.

Customer Inquiry

Customer Inquiry is part of pre-sales process, it represents in SAP ssystem the request of customer for a sales quotation or information. Customer inquiries created in system can be used for subsequent sales processing, these are also used when record of complete sales cycle is necessary. An inquiry in system contains one or more items consisting of quantity of material or service as asked by customer. Quantity specified by customer can be split in different schedule lines and dates. Pricing conditions are determined as maintained in records. Inquiry document gets status as ‘Complete’once it is used as reference for quotation.

Qutotation

Quotation represents an offer which is legally binding to deliver the product or provide a service in some fixed conditions. In the specified time period of quotation company needs to agree to the conditions. Quotations can be referenced from Inquiries and also copied on to sales orders as a reference via Copy control. These are normally used when companies are dealing with Government or large organizations. In system where quotations are created analysis can be done to check quotations to sales order conversion ratio for Sales analysis. Like inquiries the order quantities can be split in multiple schedule lines and pricing data is also available.

Sales Document Structure

Sales documents including inquiry and quotation explained earlier have the same basic structure. Any sales document is made up of a document header and any no of items. Items can in turn be divided in schedule lines. General data applicable to entire document is recorded at header level like Sold to party, Document currency. Item data applies to specific items like Material no, delivering plant etc. Schedule line data contains information needed for delivery. Sales document in system has a user friendly interface which facilitates easy navigation and switching between screens.

Sales order is a contractual agreement between a sales organization and a Sold-to party on delivering product or providing service on agreed terms. The creation of sales document hence requires that all proper terms are available, to aid this system proposes much of the data from various sources i.e

• Data from Master records
• Data determined from system
• From preceding documents

Various features in sales order processing are provided in system which are common across sales documents.

• Making Fast changes: This function allows changes for several or all items at same time. Data that can be changed with this function include: Reason for rejection, Plant, Delivering block, Billing block, Delivery date, Delivery priority.
• Additional Data: Sales document contains Additional data A and B tabs which contain fields like Customer group 1-5 and Material group 1-5, these can be copied from Customer and material master respectively and can be used for analysis or inputs in pricing etc.
• Displaying Changes: This is an important feature in sales order which helps in displaying changes made to sales document, which can be very useful for audit purpose. It displays a list with following points
  • Situation before and after change.
  • Change date and time
  • User name of person making changes.
• Derivation of Sales Area: Processing of any sales document is for a sales area and derivation of sales area is important. If Sales area is not specified at initial screen this can be derived from Sales area of Sold-to party or Ship-to party customer master record. For customer belonging to multiple sales areas system prompts for user input in a dialog box.
• Item Proposal: To aid the user and reduce time system can propose items in sales order from two sources, Existing document like quotation or sales order and an Item proposal.

Special Sales Orders

Cash Sales: Standard system has order type CS (or BV) for cash sales. On creation of Cash sales order by sales employee system proposes current date for delivery and billing, on saving of order system creates delivery of type BV immediately in background and Invoice output from cash sales order is printed. The output type for this in standard system is RD03. Delivery can be processed manually as it is already picked up. Billing index is created and invoice can be created by an background job. The order type can be customized in configuration to suit specific business process as required.

Rush Order: Rush order is a special sales order where Customer picks up the goods or company delivers the goods on the same day as order is placed. In standard system sales document type RO is used on saving of which creates delivery of type LF immediately. Goods are picked and goods issue posted. Invoice is created later and papers are posted.

Routes

Route in SAP means the path the material takes to move from company dispatch point to customer unloading point. Routes in system determine the means of transport involved and has an impact on transportation scheduling. Determining the proper route for item to be delivered to customer has impact on the overall scheduling of material. Routes can be initially determined for an item in order and re-determined in delivery if required.

Route determination in order is dependent on following factors:

• County and Departure Zone of shipping point.
• Shipping condition from sales order which is in turn determined from customer master.
• Transportation zone from material master record of particular sales organization & plant.
• Country and Transportation zone of ship-to party

Routes can be redetermined in delivery based on weight and volume of materials and as maintained in customization.