Sales & Distribution Process

Sales & Distribution Processes EGN 5620 Enterprise Systems Configuration Spring, 2013

Sales & Distribution Process
ECC 6.0 January 2008 Sales & Distribution Process Engage in pre-sales activities Create quotations and send to customers Create sales orders Schedule & deliver Bill customer (by invoice) Receive payment from customer Handle sales order return During sales order processing, the system carries out basic functions, such as: Monitoring sales transactions Checking for availability Transferring requirements to materials planning (MRP) Delivery scheduling Calculating pricing and taxes Checking credit limits Creating printed or electronically transmitted documents (confirmations and so on) Depending on how your system is configured, these functions may be completely automated or may also require some manual processing. The data that results from these basic functions (for example, shipping dates, confirmed quantities, prices and discounts) is stored in the sales document where it can be displayed and, in some cases, changed manually during subsequent processing. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Sales & Distribution Process SAP Implementation EGN 5620 Enterprise Systems Configuration

Business Process Integration
ECC 6.0 Business Process Integration January 2008 FI SD MM Transactions Org Data Master Data FI MM SD Rules FI MM SD FI In the Business Process Integration class we use the stool as a metaphor for the SAP structure. There are four basic components needed to run execute SAP. Three of these are the legs of the stool: org data, master data, and rules. These ‘hold up’ the transactions. Transactions cannot be run unless these are setup. The legs are typically configured during the implementation process. During BPI 1 we will setup the stool for Finance, Materials management and Sales and Distribution. MM SD January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Pen Incorporated Procure for Sales Order
ECC 6.0 January 2008 Pen Incorporated Procure for Sales Order Pre-Sales Activity Sales Order Delivery Billing General Ledger Accounts Purchase Requisition Purchase Order Goods Receipt In Inventory Plant or Warehouse Invoice Receipt Availability Check NO YES Goods to Delivery Goods from Purchase Order Inventory Postings Accounts Receivable Payable Can start out with a pre-sales activity Then to Order processing Became an order Check inventory – If not… Buy Receive Goods Assign to sales order Send to customer Bill customer Pay Vendor Account for all activities General ledger either the balance sheet or income statement January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Business Process Integration
ECC 6.0 Business Process Integration January 2008 SD Process Transactions We are now going to run some material management transactions - Purchasing January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SAP Sales Order Process (Order-to-Cash)
ECC 6.0 January 2008 Integration SAP Sales Order Process (Order-to-Cash) Sales Process Check Availability Sales Order Entry Sales Quotation Entry Delivery Note & Pick Materials Pre-Sales Activities Pack Materials Not unlike the procure to pay process, this is completely configurable. You decide how you want the order to cash process to work and configure the system appropriately May start with Sales Order Check inventory If you do not have inventory –procurement process or production process Pick materials: from inventory Pack material: (optional) pack in box appropriate box or other Post Goods Issue (Title transfer) Invoice Customer –Create Accounts Receivable Collect Money Post Goods Issue Receipt of Customer Payment Invoice Customer January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SAP SD Process Engage in pre-sales activities
ECC 6.0 January 2008 SAP SD Process Engage in pre-sales activities Create quotations and send to customers Create sales orders, item proposal, or scheduling agreement Schedule delivery and create delivery note Create/send invoice to customer (billing) Receive/post payment from customer Handle sales order return During sales order processing, the system carries out basic functions, such as: Monitoring sales transactions Checking for availability Transferring requirements to materials planning (MRP) Delivery scheduling Calculating pricing and taxes Checking credit limits Creating printed or electronically transmitted documents (confirmations and so on) Depending on how your system is configured, these functions may be completely automated or may also require some manual processing. The data that results from these basic functions (for example, shipping dates, confirmed quantities, prices and discounts) is stored in the sales document where it can be displayed and, in some cases, changed manually during subsequent processing. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3: Create Sales Order A sales order contains all of the information needed to process customers request. The steps for creating a sales order: Pricing Credit limit check Availability Check Delivering Schedule Shipping point and route determination Transfer of requirements to MRP foreign trade and license processing

SD3-1: Pricing SAP can display pricing information at both the header and the line item level for sales order. It enables the user to program varied pricing procedures to meet individual organizations needs. The pricing is extendable; it can be attached, or extended to external pricing programs or elements outside SAP for pricing. It also allows Gross to Net pricing: This allows discounts and reductions from the ‘master’ price.

ECC 6.0 January 2008 SD3-2: Credit Check SAP provides an efficient means to implement credit management It is integrated with Financial Accounting (FI), via credit control area It automatically alerts when a credit check fails A large number of outstanding receivables or bad debts can have a not inconsiderable impact on company performance. Using Credit Management, you can minimize your credit risk by defining a credit limit for your customers. This is especially important if you do business with customers in financially unstable sectors or countries, or trade with countries that are politically unstable or that adopt a restrictive exchange rate policy. Integration If you implement the Accounts Receivable (FI-AR) application component to manage your receivables, but a non-SAP system for sales and distribution processing, Credit Management enables you to assign a credit limit to each customer. When you post an invoice (in FI-AR) the system then checks whether the amount exceeds the credit limit. Facilities like the credit master sheet or early warning list help you monitor the customer’s credit situation. If you implement both the Accounts Receivable (FI-AR) and Sales and Distribution (SD) application components, you can specify in Customizing when (at the point of order, delivery, goods issue and so on) and to what extent a check on the customer’s credit limit is to take place. You can define automatic credit limit checks according to a range of criteria and in line with your company’s requirements You can also define at what point the system carries out these checks (order, delivery, goods issue, and so on). The credit representative is automatically alerted to a customer’s critical credit situation as soon as order processing starts. The relevant employees can be automatically notified of critical credit situations via internal mail. Your credit representatives are able to check a customer’s credit situation quickly and reliably, and, in line with the appropriate credit policy, to decide whether the customer should be granted credit. Using Credit Management you can work in distributed systems. A distributed system is one with central financial accounting and non-central sales and distribution on several sales and distribution computers. Credit and risk management takes place in the credit control area. According to your corporate requirements, you can implement credit management that is centralized, decentralized, or somewhere in between. For example, if your credit management is centralized, you can define one credit control area for all of your company codes. If, on the other hand, your credit policy requires decentralized credit management, you can define credit control areas for each company code or each group of company codes. Credit limits and credit exposure are managed at both credit control area and customer level. Credit and risk management takes place in the credit control area. According to your corporate requirements, you can implement credit management that is centralized, decentralized, or somewhere in between. Credit limits and credit exposure are managed at both credit control area and customer level. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-2: Credit Check A large number of outstanding receivables or bad debts can have a considerable impact on company performance. The user may minimize credit risk by defining a credit limit for customers by using Credit Management. This is especially important if a company does business with customers in financially unstable sectors or countries, or engages in trading with countries that are politically unstable or that adopt a restrictive exchange rate policy. A large number of outstanding receivables or bad debts can have a not inconsiderable impact on company performance. Using Credit Management, you can minimize your credit risk by defining a credit limit for your customers. This is especially important if you do business with customers in financially unstable sectors or countries, or trade with countries that are politically unstable or that adopt a restrictive exchange rate policy. Integration If you implement the Accounts Receivable (FI-AR) application component to manage your receivables, but a non-SAP system for sales and distribution processing, Credit Management enables you to assign a credit limit to each customer. When you post an invoice (in FI-AR) the system then checks whether the amount exceeds the credit limit. Facilities like the credit master sheet or early warning list help you monitor the customer’s credit situation. If you implement both the Accounts Receivable (FI-AR) and Sales and Distribution (SD) application components, you can specify in Customizing when (at the point of order, delivery, goods issue and so on) and to what extent a check on the customer’s credit limit is to take place. You can define automatic credit limit checks according to a range of criteria and in line with your company’s requirements You can also define at what point the system carries out these checks (order, delivery, goods issue, and so on). The credit representative is automatically alerted to a customer’s critical credit situation as soon as order processing starts. The relevant employees can be automatically notified of critical credit situations via internal mail. Your credit representatives are able to check a customer’s credit situation quickly and reliably, and, in line with the appropriate credit policy, to decide whether the customer should be granted credit. Using Credit Management you can work in distributed systems. A distributed system is one with central financial accounting and non-central sales and distribution on several sales and distribution computers. Credit and risk management takes place in the credit control area. According to your corporate requirements, you can implement credit management that is centralized, decentralized, or somewhere in between. For example, if your credit management is centralized, you can define one credit control area for all of your company codes. If, on the other hand, your credit policy requires decentralized credit management, you can define credit control areas for each company code or each group of company codes. Credit limits and credit exposure are managed at both credit control area and customer level. Credit and risk management takes place in the credit control area. According to your corporate requirements, you can implement credit management that is centralized, decentralized, or somewhere in between. Credit limits and credit exposure are managed at both credit control area and customer level. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3-3: Availability Check
Determines the material availability date Considers all inward and outward inventory movements Allow for 3 methods of delivery One-time delivery ( on- time one-time delivery) Complete delivery (possibly delayed one- time delivery) Delayed proposal (allows partial delivery schedule)

ECC 6.0 January 2008 SD3-3: Availability Check In determining the material availability the following elements can be included in the availability check Safety stock Stock in transfer Quality inspection stock Blocked stock Restricted use stock All movements of stock The following elements can be included in the availability check: Stock safety stock stock in transfer quality inspection blocked stock Inward/Outward movement of goods purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-3: Availability Check Availability are affected by inward & outward movements of goods: purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements The following elements can be included in the availability check: Stock safety stock stock in transfer quality inspection blocked stock Inward/Outward movement of goods purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-3: Availability Check One-time delivery Deliver on the requested delivery date In this section, SAP checks whether the requested delivery date can be kept to. If stock of the material is available to make a delivery on the requested delivery date, the stock quantity is confirmed here. If there is no stock available, confirmed quantity zero is displayed. The following elements can be included in the availability check: Stock safety stock stock in transfer quality inspection blocked stock Inward/Outward movement of goods purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-3: Availability Check Complete delivery In this section, SAP checks whether there will be sufficient stock for complete delivery at a later date: If there is sufficient stock available at a later date to cover the required quantity in the sales document, the system proposes the date here. If the system determines that complete delivery cannot be made at a later date, no date is proposed in this section. The following elements can be included in the availability check: Stock safety stock stock in transfer quality inspection blocked stock Inward/Outward movement of goods purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-3: Availability Check Delayed proposal In this section, SAP checks whether and for which dates partial deliveries can be made. Partial deliveries are displayed for different dates. These dates are based on the planned inward and outward movements of stock. During an availability check which takes replenishment lead time into account, the date on which replenishment lead time ends is displayed if insufficient stock means that no partial deliveries can be made before replenishment lead time ends. The following elements can be included in the availability check: Stock safety stock stock in transfer quality inspection blocked stock Inward/Outward movement of goods purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3-4: Delivery Scheduling
ECC 6.0 January 2008 SD3-4: Delivery Scheduling SAP can automatically schedule essential shipping activities, using backward and forward scheduling rules. It uses defined activity times to schedule delivery activities. During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept. The terms used in scheduling are defined below. You must distinguish between times (time duration) needed to carry out certain activities dates that are calculated on the basis of these times Times Values based on past experience of the shipping department are entered in the system in the form of transit times, loading times, pick/pack times, and transportation lead times: The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The following deadlines are of importance for delivery processing: You must start picking and packing activities on the material availability deadline. This deadline must be selected early enough in advance so that the goods are ready by the given loading deadline. The transportation scheduling deadline is the date on which you must start to organize the transportation of the goods. This deadline must be selected early enough to ensure that the means of transport is available by the loading deadline. The loading deadline is the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading. After the time required for loading the goods (loading time) has expired, goods issue can be carried out. The goods issue deadline is the date on which the goods leave the company in order to arrive punctually at the customer location. The delivery deadline is the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer. The delivery deadline can be the customer's requested delivery deadline or the confirmed delivery date (that is, the earliest date on which you can deliver goods to the customer). If backward scheduling determines a date in the past as the date on which a schedule line becomes due for shipping or if the material will not be available on the date calculated, the system automatically carries out forward scheduling to determine the earliest possible shipping deadline. For example, starting from the current date, the system calculates the loading deadline, the goods issue deadline, and then the confirmed delivery date. It does this by adding together the shipping times mentioned above. When you change a sales document, such as adding schedule lines or rescheduling, the system carries out delivery scheduling for all the schedule lines, new and old. Because the material availability date lies in the past for backlog schedule lines, the system performs forward scheduling. This may have the undesired affect of the system rescheduling lines that may have already been confirmed. You can specify for each sales document type that the system is to schedule deliveries only backwards. With no forward scheduling, you can better recognize backlogs in production and the customer receives goods on time. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-4: Delivery Scheduling Terms used in scheduling are defined below. Transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. Loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. Pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. Transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept. The terms used in scheduling are defined below. You must distinguish between times (time duration) needed to carry out certain activities dates that are calculated on the basis of these times Times Values based on past experience of the shipping department are entered in the system in the form of transit times, loading times, pick/pack times, and transportation lead times: The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The following deadlines are of importance for delivery processing: You must start picking and packing activities on the material availability deadline. This deadline must be selected early enough in advance so that the goods are ready by the given loading deadline. The transportation scheduling deadline is the date on which you must start to organize the transportation of the goods. This deadline must be selected early enough to ensure that the means of transport is available by the loading deadline. The loading deadline is the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading. After the time required for loading the goods (loading time) has expired, goods issue can be carried out. The goods issue deadline is the date on which the goods leave the company in order to arrive punctually at the customer location. The delivery deadline is the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer. The delivery deadline can be the customer's requested delivery deadline or the confirmed delivery date (that is, the earliest date on which you can deliver goods to the customer). If backward scheduling determines a date in the past as the date on which a schedule line becomes due for shipping or if the material will not be available on the date calculated, the system automatically carries out forward scheduling to determine the earliest possible shipping deadline. For example, starting from the current date, the system calculates the loading deadline, the goods issue deadline, and then the confirmed delivery date. It does this by adding together the shipping times mentioned above. When you change a sales document, such as adding schedule lines or rescheduling, the system carries out delivery scheduling for all the schedule lines, new and old. Because the material availability date lies in the past for backlog schedule lines, the system performs forward scheduling. This may have the undesired affect of the system rescheduling lines that may have already been confirmed. You can specify for each sales document type that the system is to schedule deliveries only backwards. With no forward scheduling, you can better recognize backlogs in production and the customer receives goods on time. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-4: Delivery Scheduling The following 5 deadlines are of importance for delivery scheduling: Material availability deadline: must start picking and packing activities on the material availability deadline. This deadline must be selected early enough in advance so that the goods are ready by the given loading deadline. 2. Transportation scheduling deadline: the date on which you must start to organize the transportation of the goods. This deadline must be selected early enough to ensure that the means of transport is available by the loading deadline. During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept. The terms used in scheduling are defined below. You must distinguish between times (time duration) needed to carry out certain activities dates that are calculated on the basis of these times Times Values based on past experience of the shipping department are entered in the system in the form of transit times, loading times, pick/pack times, and transportation lead times: The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The following deadlines are of importance for delivery processing: You must start picking and packing activities on the material availability deadline. This deadline must be selected early enough in advance so that the goods are ready by the given loading deadline. The transportation scheduling deadline is the date on which you must start to organize the transportation of the goods. This deadline must be selected early enough to ensure that the means of transport is available by the loading deadline. The loading deadline is the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading. After the time required for loading the goods (loading time) has expired, goods issue can be carried out. The goods issue deadline is the date on which the goods leave the company in order to arrive punctually at the customer location. The delivery deadline is the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer. The delivery deadline can be the customer's requested delivery deadline or the confirmed delivery date (that is, the earliest date on which you can deliver goods to the customer). If backward scheduling determines a date in the past as the date on which a schedule line becomes due for shipping or if the material will not be available on the date calculated, the system automatically carries out forward scheduling to determine the earliest possible shipping deadline. For example, starting from the current date, the system calculates the loading deadline, the goods issue deadline, and then the confirmed delivery date. It does this by adding together the shipping times mentioned above. When you change a sales document, such as adding schedule lines or rescheduling, the system carries out delivery scheduling for all the schedule lines, new and old. Because the material availability date lies in the past for backlog schedule lines, the system performs forward scheduling. This may have the undesired affect of the system rescheduling lines that may have already been confirmed. You can specify for each sales document type that the system is to schedule deliveries only backwards. With no forward scheduling, you can better recognize backlogs in production and the customer receives goods on time. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-4: Delivery Scheduling 3. Loading deadline: the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading. After the time required for loading the goods (loading time) has expired, goods issue can be carried out. 4. Goods issue deadline: the date on which the goods leave the company in order to arrive punctually at the customer location. During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept. The terms used in scheduling are defined below. You must distinguish between times (time duration) needed to carry out certain activities dates that are calculated on the basis of these times Times Values based on past experience of the shipping department are entered in the system in the form of transit times, loading times, pick/pack times, and transportation lead times: The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The following deadlines are of importance for delivery processing: You must start picking and packing activities on the material availability deadline. This deadline must be selected early enough in advance so that the goods are ready by the given loading deadline. The transportation scheduling deadline is the date on which you must start to organize the transportation of the goods. This deadline must be selected early enough to ensure that the means of transport is available by the loading deadline. The loading deadline is the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading. After the time required for loading the goods (loading time) has expired, goods issue can be carried out. The goods issue deadline is the date on which the goods leave the company in order to arrive punctually at the customer location. The delivery deadline is the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer. The delivery deadline can be the customer's requested delivery deadline or the confirmed delivery date (that is, the earliest date on which you can deliver goods to the customer). If backward scheduling determines a date in the past as the date on which a schedule line becomes due for shipping or if the material will not be available on the date calculated, the system automatically carries out forward scheduling to determine the earliest possible shipping deadline. For example, starting from the current date, the system calculates the loading deadline, the goods issue deadline, and then the confirmed delivery date. It does this by adding together the shipping times mentioned above. When you change a sales document, such as adding schedule lines or rescheduling, the system carries out delivery scheduling for all the schedule lines, new and old. Because the material availability date lies in the past for backlog schedule lines, the system performs forward scheduling. This may have the undesired affect of the system rescheduling lines that may have already been confirmed. You can specify for each sales document type that the system is to schedule deliveries only backwards. With no forward scheduling, you can better recognize backlogs in production and the customer receives goods on time. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-4: Delivery Scheduling 5. Delivery deadline: the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer. The delivery deadline can be the customer's requested delivery deadline or the confirmed delivery date (that is, the earliest date on which you can deliver goods to the customer). During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept. The terms used in scheduling are defined below. You must distinguish between times (time duration) needed to carry out certain activities dates that are calculated on the basis of these times Times Values based on past experience of the shipping department are entered in the system in the form of transit times, loading times, pick/pack times, and transportation lead times: The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The following deadlines are of importance for delivery processing: You must start picking and packing activities on the material availability deadline. This deadline must be selected early enough in advance so that the goods are ready by the given loading deadline. The transportation scheduling deadline is the date on which you must start to organize the transportation of the goods. This deadline must be selected early enough to ensure that the means of transport is available by the loading deadline. The loading deadline is the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading. After the time required for loading the goods (loading time) has expired, goods issue can be carried out. The goods issue deadline is the date on which the goods leave the company in order to arrive punctually at the customer location. The delivery deadline is the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer. The delivery deadline can be the customer's requested delivery deadline or the confirmed delivery date (that is, the earliest date on which you can deliver goods to the customer). If backward scheduling determines a date in the past as the date on which a schedule line becomes due for shipping or if the material will not be available on the date calculated, the system automatically carries out forward scheduling to determine the earliest possible shipping deadline. For example, starting from the current date, the system calculates the loading deadline, the goods issue deadline, and then the confirmed delivery date. It does this by adding together the shipping times mentioned above. When you change a sales document, such as adding schedule lines or rescheduling, the system carries out delivery scheduling for all the schedule lines, new and old. Because the material availability date lies in the past for backlog schedule lines, the system performs forward scheduling. This may have the undesired affect of the system rescheduling lines that may have already been confirmed. You can specify for each sales document type that the system is to schedule deliveries only backwards. With no forward scheduling, you can better recognize backlogs in production and the customer receives goods on time. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 SD3-4: Delivery Scheduling An item consists of one or more schedule lines. The schedule line contains all the data that is needed for a delivery. For example, a customer orders 20 units of a particular material which you enter as one item in the sales order. However, you can only deliver 10 pieces now and the remaining 10 pieces next month. So you need to schedule two deliveries. The data for these deliveries (dates, confirmed quantities) are stored in two separate schedule lines. The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3.4: Delivery Scheduling
ECC 6.0 January 2008 SD3.4: Delivery Scheduling Structure of sales documents Header Line Item # 1 Schedule Line # 1 Schedule Line # 2 All sales documents have basically the same structure. They are made up of a document header and any number of items. The items can in turn be divided into any number of schedule lines. Header data The general data that is valid for the entire document is recorded in the document header. For example, Number of the sold-to party Number of the ship-to party and the payer Document currency and exchange rate Pricing elements for the entire document Delivery date and shipping point Item data Whereas data in the document header applies to all items in the document, some data applies only to specific items. This data is stored at item level and includes the: Material number Target quantity for outline agreements Number of the ship-to party and the payer (an alternative ship-to party or payer can be defined for a particular item) Plant and storage location specifications Pricing elements for the individual items Schedule line data An item consists of one or more schedule lines. The schedule line contains all the data that is needed for a delivery. For example, a customer orders 20 units of a particular material which you enter as one item in the sales order. However, you can only deliver 10 pieces now and the remaining 10 pieces next month so you need to schedule two deliveries. The data for these deliveries (dates, confirmed quantities) are stored in two separate schedule lines. In sales documents where delivery data is not relevant, for example, contracts, credit and debit memo requests, the system does not create any schedule lines. Data recorded in the schedule lines includes the: Schedule line quantity Delivery date Confirmed quantity Line Item # 2 Schedule Line # 1 January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3-5: Shipping Point and Route Determination
ECC 6.0 January 2008 SD3-5: Shipping Point and Route Determination A shipping point is determined for each line item A delivery can only be processed from one shipping point Routes - route to be traveled & transit time are determined using customized rules Routes can be used to simply define transit time In this step, you define the shipping points in your company or edit shipping points that already exist. In order to adapt the functional scope of a shipping point to the organization in your company, you should process the following check list: The shipping point is the top level in the organization for shipping. A shipping point can be allocated to several plants. A shipping point can be divided into several loading points. A delivery is always initiated from exactly one shipping point. Thus, all items of a delivery belong to one shipping point. Groups of deliveries also belong to exactly one shipping point. You can influence delivery scheduling via allocation to departure zones. The shipping point can be proposed automatically during order processing depending on the plant, loading group and shipping condition. A shipping point has an address. The shipping point is used as a selection criterion for lists of deliveries and the work list deliveries. The shipping point is used as a selection criterion for processing deliveries like printing, picking or goods issue. You can determine the printer destination for messages differently for every shipping point on account of shipping documents. Using routes, you can combine sales order items according to shipping criteria. The system determines routes automatically for a sales order item and can repeat the procedure for a delivery (see section Route determination). In order to define routes, proceed as follows: Define the modes of transport. Define the shipping types. Define the transportation connection points and maintain the relevant data on the detail screen. Define the routes and route stages. You can also maintain the route stages for several stages. The SAP System determines routes automatically for each sales document item. It determines the itinerary and mode of transport in shipping. Routes are determined depending on the following criteria: Country and departure zone (departure zone of the shipping point) Shipping conditions agreed in the sales order The shipping condition is defined in shipping point determination. Transportation group of the material Country and transportation zone (receiving zone) of the ship-to party The SAP System copies the route from the sales document item into the delivery at header level. To define route determination, you must edit the following points: Define transportation zones for each country. These transportation zones can be either departure zones for the shipping point or receiving zones for the ship-to party. Assign the departure zones to the shipping points. Define transportation groups for the materials. Specify the routes to be selected according to the given criteria in sales processing. Define the delivery types for which route determination should be repeated and set the necessary indicator in the appropriate delivery types. Define the weight groups. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3-6: Transfer of requirements to MRP
ECC 6.0 January 2008 SD3-6: Transfer of requirements to MRP Sales order is transferred to MRP as a Customer Independent Requirement (CIR). If a deficit is found, SAP will propose a purchase req. or planned order to fulfill the shortage after running MRP or MPS. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. The following elements can be included in the availability check: Stock safety stock stock in transfer quality inspection blocked stock Inward/Outward movement of goods purchase orders purchase requisitions planned orders production orders reservations dependent reservations dependent requirements sales requirements delivery requirements Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3-6: Transfer of requirements to MRP

SD3-7: Foreign Trade and License Processing
ECC 6.0 January 2008 SD3-7: Foreign Trade and License Processing Predefined trade areas — NAFTA, EU Automated reporting for trade areas Automated controls License management Embargo lists Control by customer, country, product, point in time As countries move increasingly toward a global market economy, businesses become more involved in and influenced by foreign trade. This affects not only the vendor and customer relationship, but that of foreign subsidiaries within a single company. With this opening of market opportunities come regulations, licenses, import tariffs, and an increasing amount of paperwork required by government agencies and other legal entities. SAP Retail provides extensive support for world-wide export/import trade as well as deliveries within specific trade areas (such as the EU or NAFTA), thus automating the burdensome paperwork and freeing your shipping and receiving departments to concentrate on moving merchandise quickly. R/3 functionality includes: Maintenance of data specific to foreign trade in the following master records: Customer master Vendor record Article master Purchasing info record Copying data specific to foreign trade into purchasing and sales documents Data interface for the retrieval of export-specific data Export control Government reporting Preference procedures January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD3: Create Sales Order The sales order document is made up of three primary areas: Header Data relevant for the entire sales order: customer data, total cost of the order, number of the sold-to party, number of the ship-to party and the payer, document currency and exchange rate, pricing elements for the entire document, delivery date and shipping point order Line Item Information about the specific product: Ex: material and quantity, cost of an individual line Schedule Lines Uniquely belongs to a Line Item, contains delivery quantities and dates for partial deliveries

SD3: Create Sales Order Item Data
ECC 6.0 January 2008 SD3: Create Sales Order Item Data Whereas data in the document header applies to all items in the document, some data applies only to specific items. This data is stored at item level and includes the: Material number Target quantity for outline agreements Number of the ship-to party and the payer (an alternative ship-to party or payer can be defined for a particular item) Plant and storage location specifications Pricing elements for the individual items Schedule line data The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route. The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item. The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material. The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

DS3: Create sales order: item proposal
ECC 6.0 January 2008 DS3: Create sales order: item proposal If a customer frequently orders the same combination of materials, SAP can store the frequently used data as an item proposal in the system. During sales order processing, the user can copy all or some of the materials and quantity data from the item proposal directly into the sales order (document) Item proposal can be assigned to one or multiple customer master records If a customer frequently orders the same combination of materials, or if you recommend a particular selection of products for an opening order, you can store the frequently used data as an item proposal in the system. If you wish, the item proposal may also include proposed order quantities. During sales order processing, you can then copy all or some of the materials and quantity data from the item proposal directly into your document (sales order, quotation, and so on). In addition, you can assign a particular item proposal to one or more specific customer master records. The system can then automatically propose the number of the assigned item proposal whenever you process sales orders for the relevant customers. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD4: Schedule delivery and create Delivery notes
ECC 6.0 January 2008 SD4: Schedule delivery and create Delivery notes Initiates the delivery process Control mechanism for the process Changes to delivery are allowable - products, quantities Integrated with the Material Management (MM) and Finance (FI) modules Each step in the delivery process updates the delivery note status Picking Packing Loading Post Goods Issue Once the sales order is entered the delivery notes starts the delivery process. Along with most processes in SAP it is configurable and can be tailored per order or customer. As soon as the material availability date or the transportation scheduling date for a schedule line is reached, the schedule line becomes due for shipping. When you create an outbound delivery, you initiate shipping activities such as picking and transportation scheduling. In its role as central object of the goods issue process, the outbound delivery supports all shipping activities including picking, packing, transportation and goods issue. During the outbound delivery process, shipping-planning information is recorded, status of shipping activities is monitored and data accumulated during shipping processing is documented. When the outbound delivery is created, the shipping activities, such as picking or delivery scheduling, are initiated, and data that is generated during shipping processing is included in the delivery. Delivery Note January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Delivery/ Goods Issuing Reconciliation Account
No impact on Financial Accounting (FI) Sales quotation Sales order Materials Management (MM) and Financial Accounting (FI) Delivery/Goods Issuing Requisition – Nothing really happens unless we get the goods or pay for them The system does the transactions for you using the automatic account assignment When we receive these, it can match the receipt against the PO Debit Inventory (we now have additional inventory value) Credit GR/IR (we are going to owe/pay for that additional inventory) COGS: Cost of goods sold Credit is minus Debit is plus

SD4: Shipping Order Combination Partial Delivery Complete
Sales Order 1 Sales Order 2 Sales Order 3 Delivery 8…12 Partial Delivery Sales Order 4 Delivery 8…13 Delivery 8…14 Delivery 8…15 Complete Sales Order 5 Delivery 8…16

ECC 6.0 January 2008 DS5: Billing Overview SAP has the functions of processing credit/debit memos and rebates It automates invoicing, based on sales orders and/or deliveries It can create pro forma (paper) invoices It is integrated with Finance (FI) & Controlling (CO) It updates customer’s credit data January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

DS5: Billing Sales Invoice Sold To: Rushmore Group Sales Org: S001
ECC 6.0 DS5: Billing January 2008 Sales Invoice Sold To: Rushmore Group Sales Org: S001 Dist Channel: RE Division: 01 Conditions/Price: $120 The invoice generates 3 automatic accounting instructions: Credits the revenue account Debits the customer’s account Simultaneously debits the A/R reconcilliation account (total A/R) January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

DS5: Billing Methods Delivery based Invoicing Collective Invoicing
ECC 6.0 January 2008 DS5: Billing Methods Collective Invoicing Delivery based Invoicing Delivery 8…34 Delivery 8…33 Order 14 Order 9 Delivery 8…56 Invoice 9…68 Order 6 Delivery 8…20 Delivery 8…21 Invoice 9…45 Invoice 9…46 Split Order 32 Delivery 8…86 Invoice 9…92 Invoice 9…91 The following methods may be used in Billing: One individual billing document per sales document You can set the system to create one billing document for each sales document, e.g. one invoice per delivery. A collective billing document for several sales documents As long as certain data agrees, you can also combine different documents (orders and/or deliveries) fully or partially in a common billing document The following prerequisites must be met: the header data appearing in the billing document must agree the split conditions specified do not apply several billing documents for one or more sales documents ( invoice split) If you want to guarantee that invoices are created separately according to certain criteria, you can do this by defining certain split criteria. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 DS5: Billing Documents Billing document is the umbrella term for invoices, credit memos, debit memos, etc. Billing due list — builds a work list of invoices that should be generated Automatic posting to Financial Accounting (FI): debit to customer sub-ledger account and credit revenue account. Billing document is the umbrella term for invoices, credit memos, debit memos, pro forma invoices and cancellation documents. The invoice list lets you create, at specified time intervals or on specific dates, a list of billing documents (invoices, credit and debit memos) to send to a particular payer. The billing documents in the invoice list can be single or collective documents (collective invoices combine items from more than one delivery). The standard version of the SAP R/3 System includes two types of invoice lists: for invoices and debit memos for credit memos Like all parts of sales order processing in R/3, billing is integrated into the organizational structures. Thus you can assign the billing transactions a specific sales organization, a distribution channel, and a division. Since billing has an interface to Financial Accounting, the organizational structures of the accounting department, (the company codes as well as the sales organizations assigned to the company codes) are important. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 DS5: Billing Plans Periodic — total amount for a planned billing period Milestone — distributing the total amount over multiple billing dates - typically used with the project system (PS) Installment — evenly proportioned amounts and defined payment dates Resource related — consumed resources such as service or consulting Periodic billing means billing a total amount for each individual billing date in the plan. For example, if you are creating a rental contract, the system can propose a schedule of monthly rental payments, according to the length and conditions of the contract. Milestone billing means distributing the total amount to be billed over multiple billing dates in the billing plan. For example, you can use a billing plan for billing a make-to-order item that is assigned to a project in the SAP Project System. When you enter the project-related make-to-order item in the sales order (or assembly order), the system proposes a billing plan based on milestones defined for networks in the project. As each milestone is successfully reached, the customer is billed either a percentage of the entire project cost or simply a pre-defined amount. The installment plan allows the customer to pay in installments. With the installment plan the system creates one invoice for all installments. On the basis of this billing document you can print an invoice listing all the installments with the relevant payment dates and amounts to be paid by those dates. The installments are calculated by the system by taking a percentage of the total invoice amount for each installment. These percentages can be defined by your system administrator. The system takes into account any rounding differences for the last payment date. For each installment the system creates a customer line item in financial accounting. The installments are defined by the payment terms, which are controlled by the payment terms key. Your system administrator can define the following data for this key: the number of installments the payment dates the percentage of the billing value Resource-Related Billing The price for customer-specific services are not always defined in a contract as fixed prices, nor can they always be determined using standard pricing. This is the case if, for example, no empirical values exist for specific services, and therefore the services cannot be calculated adequately before conclusion of a contract. Typical examples of this are: Make-to-order production External plant maintenance in the service company Specific services such as consulting You carry out resource-related billing for these orders. In the billing document, single material, internal activities, and costs are assigned to the customer afterwards. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

SD6: Payment Payment is the final step in the sales order process.
SAP posts payments against invoices. The posting clears the liability in the A/R account and increases your bank account.

SD7: Handle Customer Return
ECC 6.0 January 2008 SD7: Handle Customer Return Sales Process Delivery Note Customer Return Order received Goods Receipt Payment to Customer If the customer complains, for instance, that the goods were faulty, you take the goods back to check them. Once you have checked the goods, you can implement one of the following activities: - Send the customer a credit memo - Make a subsequent delivery of the goods, free of charge Quality Inspection Create Credit Memo January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 SD7: Handle Customer Return January 2008 1 2 3 Order 14 Delivery 8…56 Return Order Return Delivery Invoice 9…68 Payment Credit Memo Quality Inspection Return to Inventory Sales returns processing manages merchandise that the customer has returned due to complaints. You enter the returned merchandise in the system and subject them to an analysis (in the laboratory, for example). When the analysis is complete, you use the results of that analysis to decide whether the merchandise can be reused. You can trace this procedure through the document flow for sales returns processing. There are 3 components in a return. The product(s) are ordered, delivered and invoiced (paid) There is a request for a return Return delivery An optional quality inspection is run Undamaged, unopened product is returned to stock inventory A credit memo is created and then paid for the returned merchandise according to the terms of returns After you have checked the goods, you can implement one of the following activities for the complaint: Approve it by deleting the block reject it by entering a reason for rejection. You should bear in mind the following: The quantity for which the customer should receive credit. The order quantity rather than the delivered quantity is used as the basis for the credit memo. If the customer returns only some of the goods and disposes of the remaining goods himself, you can still create a credit memo for the full amount. On the other hand, you can create a partial credit memo for certain items even if the customer returns the entire quantity. To do this, the quantity to be ordered in the return has to be reduced to the quantity to be credited. Whether the customer should receive a replacement. If the customer is to receive replacement goods, do not create a credit memo. You can enter a reason for rejection for the appropriate items in the return. You then create a free of charge subsequent delivery with reference to the return in order to send the replacement goods to the customer. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 SD7: Handle Customer Return January 2008 Returns document Billing block can be proposed Use the Order reason field to identify the reason for the return Full access to pricing and ability to re-price Return delivery Issues a goods receipt to place material into inventory The Sales Returns component is used to manage full products in the consumer products industry (for example, in the beverage industry) that the customer has returned due to a complaint. The complaints are all related to quality defects, not incorrect deliveries. The path that the returned merchandise takes often has to be tracked in detail – for example, returned beer first has to be sent to a lab (e.g. in a brewery) for inspection. Once the analysis of the returned merchandise is complete, the vendor or manufacturer determines · The status of the merchandise and whether it can be reused · Whether the customer will be credited for the merchandise and, if so, in what amount In practice, time delays occur between entry of the returns in the system, analysis, and settlement. The Sales Returns component gives you an overview of your physical warehouse stocks and the corresponding postings whenever you require. · You can enter sales returns with or without a reference to a previous sales (return) document. You can use the driver’s return delivery note, for example, as a template. · The system provides the order items from the sales returns document as a template for entering the results of the analysis. You can therefore immediately see which materials are pending for analysis and in which amounts. · You can link the results of the analyses with the entered order items from the sales returns document – individually or jointly, in full or partial quantities – and settle them immediately in the system. · You can create an empties credit memo immediately, without having to wait for the results of the analysis. The system generates a credit memo for the customer for the deposit value of the empties as soon as the allegedly defective merchandise is returned. Because the empties do not usually have any defects, you can credit the customer with the deposit value of the allegedly defective merchandise in advance. · The system checks whether your entries for the analysis items are permissible. · The system generates logs and updates the document flows that reflect the current status of sales returns processing. · The system generates the appropriate credit memos (SAP SD documents) and documents for warehouse stock postings (SAP MM documents) based on the results of the analysis. The system can create the documents immediately or later in background processing. If problems occur during background processing, you are notified via express mail. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 SD7: Handle Customer Return January 2008 Credit memo Billing block must be cleared from Return Posts to Financial Accounting (FI) Can be processed in batch (background) Can be processed collectively (grouped) The system can automatically propose a delivery or billing block when you enter a complaint. This may be necessary if one department enters complaints and another department reviews them. The system generates logs and updates the document flows that reflect the current status of sales returns processing. · The system generates the appropriate credit memos (SAP SD documents) and documents for warehouse stock postings (SAP MM documents) based on the results of the analysis. The system can create the documents immediately or later in background processing. If problems occur during background processing, you are notified via express mail. These returns can be processed one at a time or in batched. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

PEN, Inc. EGN 5620 Enterprise Systems Configuration
Sales & Distribution Processes PEN, Inc. EGN Enterprise Systems Configuration

Sales Quotation

Sales Order

SD Process: Billing Documents
At this point that the sales process is passed over to Financial Accounting to await payment. Creating Billing Documents Explicitly Purpose If you only have to bill specific orders or deliveries, you can carry out manual billing explicitly. When processing the billing due list, you do not need to enter the individual documents to be invoiced. The system lists the documents to be invoiced on the basis of the selection criteria you enter. It can also combine several deliveries in one invoice. Process Flow You select the function for creating a billing due list. You enter the selection criteria for the billing documents to be created. For example, enter billing type F2, if you only want to create invoices with this billing type. You then display the billing due list. The system uses the selection criteria to create the billing due list (a list of sales documents to be billed). You can now process this list, e.g. select some or all of the sales documents to be billed. You select the function for billing. The system creates the corresponding billing documents for the selected documents. Automatic Posting to Finance (next slide0

ECC 6.0 Document Flow January 2008 The document flow feature allows you to find the status of an order at any point in time. The SAP system updated the order status every time a change is made to any of the documents created in the customer order management cycle (Order to Cash). The sales documents you create are individual documents but they can also form part of a chain of inter-related documents. For example, you may record a customer’s telephone inquiry in the system. The customer next requests a quotation, which you then create by referring to the inquiry. The customer later places an order on the basis of the quotation and you create a sales order with reference to the quotation. You ship the goods and bill the customer. After delivery of the goods, the customer claims credit for some damaged goods and you create a free-of-charge delivery with reference to the sales order. The entire chain of documents – the inquiry, the quotation, the sales order, the delivery, the invoice, and the subsequent delivery free of charge – creates a document flow or history. The flow of data from one document into another reduces manual activity and makes problem resolution easier. Inquiry and quotation management in the Sales Information System help you to plan and control your sales. The system always updates the preceding documents. However, if you also want it to update the subsequent documents in the document flow, you must make the relevant settings in Customizing for copying control. Copying control and documents flow are defined for documents in: Sales support Sales Shipping Transportation Billing January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Exercises: (due date 3/6/2013)
144a. Create customer quotation Create sales order from sales quotation Check stock status Create delivery note for sales order Check stock status Picking materials on delivery note Post goods issue Check stock status Bill customer Post receipt of customer payment Review document flow Create Customer Material Info Record Create sales order using customer info record Create delivery for sales order Pick materials on delivery note

Exercises: 158. Post goods issue 159. Bill customer
160. Post receipt of customer payment 161. Create a scheduling agreement 162. Process deliveries for a scheduling agreement 163. Display scheduling agreement 164. Check stock status 165. Bill customer 166. Run customer credit check 167. Post receipt of customer payment

Sales & Distribution Process

Similar presentations

Presentation on theme: "Sales & Distribution Process"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Sales & Distribution Process

Similar presentations

Presentation on theme: "Sales & Distribution Process"— Presentation transcript:

Similar presentations

About project

Feedback