1
SAP SD TUTORIAL Web URL http://www.techhairball.com/concepts/SAP_S D_Tutorials.htm
2
Master Data in Sales and Distribution Purpose Sales processing is based on the following basic structures: •
Every company is structured in a certain way. In order to work with the SAP System your company structure has to be represented in the system. This is done with the help of various organizational structures.
•
In sales and distribution, products are sold or sent to business partners or services are performed for them. Data about the products and services as well as about the business partners is the basis for sales processing. Sales processing with the SAP System requires that the master data has been stored in the system. In addition to sales and distribution, other departments of the company such as accounting or materials management access the master data. The material master data is stored in a specific structure in order to allow access from these different views.
•
The processing of business transactions in sales and distribution is based on the master data. In the SAP System, business transaction are stored in the form of documents. These sales and distribution documents are structured according to certain criteria so that all necessary information in the document is stored in a systematic way.
Pricing and Conditions Purpose The term pricing is used broadly to describe the calculation of prices (for external use by customers or vendors) and costs (for internal purposes, such as cost accounting). Conditions represent a set of circumstances that apply when a price is calculated. For example, a particular customer orders a certain quantity of a particular product on a certain day. The variable factors here - the customer, the product, the order quantity, the date - determine the final price the customer gets. The information about each of these factors can be stored in the system as master data. This master data is stored in the form of condition records.
The Condition Technique in Pricing The condition technique refers to the method by which the system determines prices from information stored in condition records. In Sales and Distribution, the various elements used in the condition technique are set up and controlled in Customizing. During sales order processing, the system uses the condition technique to determine a variety of important pricing information. For example, the system automatically determines which gross price the customer should be charged and which discounts and surcharges are relevant given the conditions that apply.
Example of Pricing in the Sales Order The following figure shows how the condition technique works in the background to produce the pricing information. The diagram shows how the various elements in the condition technique work together.
3
1. The system determines the pricing procedure according to information defined in the sales document type and the customer master record. 2. The pricing procedure defines the valid condition types and the sequence in which they appear in the sales order. In the example, the system takes the first condition type (PR00) in the pricing procedure and begins the search for a valid condition record. 3. Each condition type in the pricing procedure can have an access sequence assigned to it. In this case, the system uses access sequence PR00. The system checks the accesses until it finds a valid condition record. (Although you cannot see this in the diagram, each access specifies a particular condition table. The table provides the key with which the system searches for records). 4. In the example, the first access (searching for a customer-specific material price) is unsuccessful. The system moves on to the next access and finds a valid record. 5. The system determines the price according to information stored in the condition record. If a pricing scale exists, the system calculates the appropriate price. In the example, the sales order item is for 120 pieces of the material. Using the scale price that applies to quantities from 100 pieces and more, the system determines a price of USD 99 per piece. The system repeats this process for each condition type in the pricing procedure determines a final price. For further information on the condition technique, see Introduction to the Condition Technique
Commodity Pricing Purpose You can use this component if you agree on complex pricing rules rather than fixed prices as part of your sales negotiations and these rules influence the product price as part of the system-aided sales process.
4
Implementation Considerations Complex pricing rules play an important role when, for example, you sell commodities (raw materials traded on the stock market). To perform commodity pricing, you need to connect a CRM system to your system landscape.
Integration The function requires a functioning Sales and Distribution (SD) component with pricing activated. The SD component must be connected to a CRM Sales component in the CRM system.
Features For more information, see Integration of Commodity Pricing in SD Sales Documents and Price Quotation.
Constraints This component does not support the following document types in the ERP system: •
Request for quotation
•
Quotation
•
Sales contract
Corresponding document types are available in the CRM system. This component does not support sales orders that you create in the ERP system with transactions or BAPIs. You must create sales orders in the CRM system; these are then automatically replicated in the ERP system.
Availability Check and Requirements in Sales and Distribution Processing Availability Check in Sales and Distribution Processing Requirements in Sales and Distribution Processing Availability Check in Shipping Availability Check against Product Allocation Available-to-Promise on the Internet
About the Availability Check in Sales and Distribution Processing
5 When you enter a sales order, you can only confirm the delivery of the goods for the required delivery date if the goods are available for all the necessary processing activities which take place before delivery: •
The shipping department must ensure that freight forwarding or another shipping company is advised early enough so that sufficient time remains for packing and loading to be carried out. An availability check can be carried out on the deadline date for availability for the goods.
•
The procurement department must ensure that the production and purchasing departments are advised of inadequate stock quantities so that goods can either be produced punctually or ordered. Sales transfers the information on materials ordered as requirements to material requirements planning. Requirements are planned outward movements of stock. The transfer of requirements informs production that goods must be produced, or advises purchasing that purchase requisitions have been created for which purchase orders must be created and sent to the suppliers. An availability check can only be carried out if these requirements are transferred.
Working with the Availability Check in Sales and Distribution Processing How the availability check is carried out is influenced by various factors. Among other things, these factors also determine the scope of the check. The scope of the check can be defined differently in the sales documents and in the deliveries. You can also specify whether the availability check takes replenishment lead time into account. For further information on working with the availability check, see Types of Availability Check in Sales and Distribution Processing Controlling the Availability Check in Sales and Distribution Processing Timing of the Availability Check in Sales and Distribution Processing Scope of the Availability Check in Sales and Distribution Processing Reactions to the Availability Check in Sales and Distribution Processing For further information on the availability check, see Availability Check in Shipping
Controlling the Availability Check in Sales and Distribution Processing You control the availability check using general and SD-specific control features.
6
General Control Features The following control elements need to be maintained in Customizing and in the material master record: •
Strategy group The allowed planning strategies (main strategy and further possible strategies) are combined in the strategy group. As of Release 3.0, the strategy group is specified in the material master record in the MRP 1 Screen. In Customizing, strategy groups are assigned, dependent on plant, to MRP groups. If the strategy group is missing in the material master record, it is determined on the basis of the MRP group, if it has been maintained. Up to Release 3.0, the strategy group is determined on the basis of the MRP group
•
MRP group The MRP group combines materials from the point of view of material requirements planning. This enables you to control planning for these materials in a particular way using, for example, the strategy group, consumption mode and planning period. You enter the MRP group in the material master in the MRP 1 screen. The strategy group is determined from the MRP group.
•
Planning Strategy The planning strategy specifies the requirements type for planning and customer requirements. This represents the decisive control feature for the interaction between Production Planning and Sales and Distribution.
•
MRP type and item category If no requirements type is found using the planning strategy, the system tries to determine a corresponding requirements type on the basis of the MRP type and the item category. Until 3.0C, determination of the requirements type via planning strategy has taken priority. This is not always the best option, however, as the following example will show. A requirements type is determined for a material, which causes availability to be checked against planning. In consignment stock processing, however, availability should be checked against stock. Until 3.0C the availability check had to be deactivated in these cases. As of Release 3.0C, you can determine how the requirements type is to be determined for each transaction by maintaining the Source field in Determination of requirement types using transaction in Customizing.
•
Requirements type The various requirements are identified by their requirements type. The requirements type refers to the requirements class and its control features.
7 •
Requirements Class The requirements class contains all control features for planning such as relevance for planning, requirements planning strategy and requirements consumption strategy. In addition, it is specified at a global level whether an availability check is to take place for the material in the sales and distribution documents on the basis of the ATP quantity (ATP = available to promise) and whether requirements are to be passed on. A finer degree of control can be obtained for sales documents using the schedule line category.
Control Features Specific to Sales and Distribution The following SD-specific control features need to be maintained in Customizing: •
Checking group The checking group controls whether the system is to create indivdual or collective requirements in sales and shipping processing. In addition, a material block for the availability check with transfer of requirements can be set here. The checking group can also be used to deactivate the availability check. This option was created especially for the assembly order so that when the bill of material is exploded in the assembly order, the individual components, if necessary, can be classified as non-critical parts as far as procurement is concerned. The checking group specifies in combination with the checking rule the scope of the availability check. It is proposed in the material master record on the basis of the material type and the plant, and copied into the sales and distribution documents.
•
Checking Rule You use the checking rule to control the scope of the availability check for each transaction in sales and distribution. You also specify whether the check should be carried out including or excluding replenishment lead time. The individual checking rules define by transaction, which stock and inward and outward movement of goods should be taken into account for the availability check.
•
Schedule line category You can control with the schedule line category whether an availability check and transfer of requirements should be carried out in the sales documents. The possible settings for this at schedule line level are dependent on the settings in the requirements class which is determined from the requirements type of the material.
•
Delivery item category The delivery item category can be used to control whether an availability check takes place in deliveries.
Prerequisites An availability check can only be carried out if the following prerequisites have been fulfilled: •
The control elements described above for the availability check must be maintained in Customizing for Sales and the relevant assignments made to the sales transactions
•
The availability check must be switched on at requirements class level and - for the availability check in the sales documents - at schedule line category level
8 •
A requirements type must exist by which the requirements class can be found
•
A plant must be defined. It can either be proposed from the customer or material master record or can be entered manually in the document.
•
A checking group must be defined in the material master record on the Sales/plant data screen in the Availability check field
Global and Fine Control in Customizing At the global requirements class level, the availability check can only be switched on in combination with the transfer of requirements. At schedule line level, the settings are proposed from the requirements class. If the availability check is switched on at requirements class level, it can be switched off at schedule line level. However, you cannot switch on the availability check at schedule line level, if it is switched off at requirements class level. You can make this setting at schedule line level. But the system ignores it and the setting for the requirements class applies. Also, at schedule line level when the availability check is switched on, the transfer of requirements can be switched off. For example, this makes sense for inquiries or sales information. The settings specific to schedule lines for performing an availability check are only relevant for sales documents. In the shipping documents, the settings from the requirements class and the delivery item category are used. As with the schedule line category, the availability check can be switched off as required in the delivery item category.
Blocking Logic There are two blocking concepts: •
Material block In Customizing, the Define material block for other users, step is used to determine, by checking group and transaction (order/delivery), whether a material master record should be blocked for other users during an availability check. The block is set at material-plant level and remains in place until you save the sales document.
•
Material block with quantity transfer
For performance-related reasons, the only time when it makes sense to set the material block with quantity transfer is when it is common for several users to work on the same material simultaneously. If this is not the case in your organization, you can work with the conventional blocking logic at material-plant level. In Customizing, the material block can be set with quantity transfer under Define checking group. If this block is active, the material is blocked only for the duration of the availability check when you create or change a sales and distribution document. Thus, it is possible for several users to process the same material simultaneously in various transactions without blocking each other. During the availability check, the material being used is blocked exclusively in the current plant as in a conventional block. If another user tries to process the blocked material in the corresponding plant while the availability check is being carried out, the system tries five times to block the material exclusively for this other transaction with a pause of about 1
9 second between each attempt. If the fifth attempt is unsuccessful, the check is terminated and the transaction remains unconfirmed. To confirm the transaction, the user must call up the availability check again. After completion of the check, the corresponding confirmed quantities are still blocked, but not exclusively. The material block is removed. The non-exclusive quantity block then supplies information to users working in other transactions, on the reserved quantities of the corresponding material being processed in the selected plant. The block entries are removed when processing is completed. If the transaction processed was saved, then the block entries were only removed after the relevant changes to the data base have been carried out. You create a sales order for a material. During the availability check, this material is blocked. After the availability check is completed, the block is removed. The quantity reserved for this transaction is recorded in the blocking table. This information can be assessed by all others who are working with this material. If you save the order, the blocked entries are cancelled. During manual backorder processing, a material with a quantity block is blocked exclusively so that an availability check for this material is no longer possible. If both of the blocking options are active, the block with quantity transfer takes precedence.
Timing of the Availability Check in Sales and Distribution Processing When you create an order, the system determines the required materail availability date on the basis of the customer’s requested delivery date. On this date, you must begin picking, packing, labeling, and loading the goods. Therefore, this is the date of significance for requirements planning on which the availability should be checked. The following data is required for determining this date: •
Route from the shipping point to the ship-to party location
•
Shipping point from which the goods are issued
•
Loading group from the material master record
•
Weight group determined from the order using the order quantity
Scheduling This data, which you have already entered in the system, means that scheduling can occur automatically. Since scheduling is carried out backwards from the requested delivery date, it is also called backward scheduling. If backward scheduling determines that the preparation for the shipping activities should have been started already to meet the customer's requested delivery date, the system then starts forward scheduling automatically from the current date. For more information on scheduling, see Transportation and Delivery Scheduling.
10
Scope of the Availability Check in Sales and Distribution Processing The following elements can be included in the availability check: •
Stock o o o o
•
safety stock stock in transfer quality inspection blocked stock
Inward/Outward movement of goods o o o o o o o o o
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. Requirements relevant for Sales and distribution are created in Sales and Distribution, whereas other elements in this list are created in Materials Management or in Production Planning. For further information on transfer of requirements, see Requirements in Sales and Distribution Processing.
Defining the Elements to be Included in Check A checking rule is assigned to each transaction. This rule in combination with the checking group controls the scope of the availability check. You can use the checking rules in Customizing for Sales to specify for the various transactions which of the elements listed above should be included in the availability check. For trading goods it does not make sense to include planned or production orders, for example, in the availability check. However, for products manufactured by your company these orders should be included in the check. For transactions such as make-to-order production, consignment or returnable packaging processing that create special stock, the availability check is performed against special stock. If it is defined by the checking rules that both sales and delivery requirements are taken into account in the availability check in sales documents but only delivery requirements are taken into account in the availability check in deliveries, there is a danger that quantities reserved in the sales documents are considered to be available by the availability check in the deliveries. This can lead to sales documents becoming backlogged.
11
Reactions to the Availability Check in Sales Documents If the goods ordered by the customer are not available on the requested date, the system branches automatically during sales document processing to a further screen where delivery proposals are offered for selection. The system determines these proposals on the basis of the availability situation. This screen also provides you with information on the scope of the check, the current ATP quantity, and the availability situation across all plants.
Availability Control On the Availability Control screen, you can choose between the following delivery proposals: •
One-time delivery on the requested delivery date In this section, the system 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. To copy this data into the sales document, select Edit → One-time delivery.
•
Complete delivery In this section, the system checks whether there will be sufficient stock for complete delivery at a later date: o o
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. When availability is checked including replenishment lead time, the date which is proposed in this section is the date on which the replenishment lead time period ends if the stock before the end of replenishment lead time does not cover the order quantity. When availability is checked excluding replenishment lead time, the system bases its calculations on the stock and the planned inward movements of stock. To copy this data into the sales document, select Edit → Complete delivery
•
Delivery proposal In this section, the system 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.
12 During an availability check which does not take replenishment lead time into account, the system displays the dates on which partial deliveries can be made with the available stock. To copy this proposal into the sales document, select Edit → Delivery proposal
The dates displayed in the sections complete delivery and delivery proposal are determined from the material availability date using forward scheduling and represent actual delivery dates.
Availability Across Plants You can display the availability situation in the various plants for which a material is maintained. To do this, proceed as follows:
1. Select Goto → Other plants on the availability control screen. The dialog box Plant Selection appears. All plants for which the material is maintained are displayed.
2. Mark the plants in which you want to check availability and select Check plants. You reach the Availability Check: Overview screen. The requirements quantity and the quantity which could be confirmed as well as some additional information is displayed in a separate line for each plant you selected.
3. If you require detailed information on the availability check for a particular line, select the relevant line and select Edit → Check availability. You reach the Date proposals dialog box where the detailed data is displayed.
4. You can select a plant with sufficient quantity for confirmation to be copied automatically into the Overview screen. Select the appropriate line and select Edit → Copy plant.
Using the user exit USEREXIT_PLANT_SELECTION in the Include RV03VFZZ you can make a preselection of the allowed plants. If you use this option, the Plant selection dialog box does not appear and the availability check is performed immediately for the allowed plants. If, on the basis of information resulting from the availability check, you want to deliver from a plant other than the one specified in the item, you must at present enter this plant manually in the item. In a later release, however, you will be able to select the plant directly from the list of plants.
Displaying the ATP Quantities
13 If you want to display the current ATP situation on the availability control screen, select Goto → Availability overview.
Displaying the Scope of the Check If you want to display the scope of the check (stock and inward/outward movements of goods taken into account during the availability check) from the availability control screen, select Goto → Scope of check.
Delivery Agreements in the Customer Master Record A customer may react in different ways to the fact that a complete delivery can not be provided for the required delivery date. You can define in the customer master record, the way a customer reacts to the inability to meet the requirements represented by the key data. •
The customer wants complete delivery of all items by the requested delivery date or at a later date. The complete delivery indicator is copied into the sales document from the customer master record. To find it, select Header → Business data on an overview screen or a header screen. You find the indicator in the Shipping section.
If the complete delivery indicator is set in the sales document, the individual items are automatically correlated when the document is saved if the schedule lines exist for various dates (that is, a delivery group is automatically created for the sales document items and the latest delivery date within this group becomes the group delivery date). For further information on delivery groups, see Combining Sales Document Items for Delivery. •
The customer only allows a certain number of partial deliveries for each item. The partial delivery indicator and the number of partial deliveries are copied into the sales document item from the customer master record. To find the indicators:
1. Go to the Business Data screen for this item. 2. Select Edit → Shipping details. The indicators are found in the Shipping section.
Performing the Availability Check Again Usually, an availability check is only performed when a sales document is created. If quantities or dates are changed in the document and availability needs to be checked again, the check is performed again automatically. However, you can also initiate an availability check manually.
Automatic Checks In the following situations, a new availability check is automatically carried out: •
Quantity change
•
Date change (requested delivery date, material availability date)
14 •
Change to the fixed data
•
After new delivery scheduling (for example, the route or shipping point has been changed)
•
Change of plant
•
Change of storage location or batch
•
Removal of blocks which affect requirements
•
Removal of reasons for rejection
Initiating a Check Manually In the sales document, you can initiate a new availability check manually. If you want to perform an availability check for all items in a sales document, select Sales document → Check availability on the header screen. If you want to check availability for an individual item, select Edit → Item availability.
Availability Check in Shipping About the Availability Check in Shipping Working with the Availability Check in Ship
About the Availability Check in Shipping When you create a delivery, an availability check is initiated for the picking date. This check is carried out along the same lines as in the sales order. It makes sense to carry out an availability check in the delivery for the following reasons. If you do not carry out an availability check for particular materials in the sales order, you should definitely check whether the order quantity is available and can be delivered when you create the delivery. Even if you have checked the availability situation in the order, it makes sense to check it once again in the delivery. The availability check is calculated using planned inward and outward movements of goods. Therefore the delivery situation might have changed in the meantime due to unforeseen circumstances, such as lost output. The availability check in the delivery takes any such changes into account.
Working with the Availability Check in Shipping When you create the delivery for a sales order, the sales order requirement is reduced by the delivery quantity. A delivery requirement which is transferred to material requirements planning is created at the same time. You can define whether delivery requirements are managed as
15 individual or collective requirements. Collective requirements can include, for example, requirements from all deliveries for one particular day or week. The availability check treats these delivery requirements as outward movements of goods. For further information on working with the availability check in shipping, see Controlling the Availability Check in Shipping Performing the Availability Check in Shipping For further information on the availability check in sales order processing, see Availiability Check in Sales and Distribution Processing. For further information on transfer of requirements in sales order processing, see Requirements in Sales and Distribution Processing.
Controlling the Availability Check in Shipping The same control elements are used for carrying out the availability check in deliveries as in the availability check in sales documents. The availability check in deliveries is dependent upon the requirements class which itself is linked to the requirements type of the material. In addition, delivery item categories can be used to control whether an availability check is performed in deliveries.
Prerequisites An availability check can only be carried out if the following prerequisites have been fulfilled: •
Control elements for the availability check must be maintained in Customizing and appropriately assigned to the sales and distribution transactions
•
The availability check and the transfer of requirements must be switched on at requirements class level and may not be deactvated at item level.
•
A plant must be defined at document item level
•
A checking group must be defined in the material master record on the Sales/plant data screen in the Availability check field
Performing the Availability Check in Shipping When you enter a delivery, the system carries out an availability check on the material availability date if the availability check is activated using the requirements class.
Which Elements are Taken into Account?
16 The following elements can be taken into account during an availability check in the delivery: •
Stock o o o o
•
safety stock stock in transfer quality inspection blocked stock
Inward/Outward movement of goods o o o o o o o o
purchase orders purchase requisitions planned orders production orders reservations dependent reservationsdependent requirements sales requirements delivery requirements
Process Flow The system determines the date on which the availability check should be carried out on the basis of the earliest material availability date of all the schedule lines in the delivery. If the system determines that insufficient stock will be available on that date, it responds as follows: •
If a material is not available for delivery by the material availability date, the system enters a delivery quantity of zero in the delivery. The item is only included in the delivery if the quantity zero is permitted for the item category.
•
If the quantity available of a material is lower than the order quantity, the system enters the available quantity as the delivery quantity. If a partial delivery is not allowed for the sales order, the fact that the delivery quantity is smaller than the order quantity is noted in the log for the delivery.
Blocking Confirmation of Quantities in Sales Documents In Customizing, using Block transfer of requirements by delivery block, you can specify that certain delivery blocks in the sales document header also block the confirmation of order quantities. If you enter such a delivery block in a sales order header, the system confirms the available quantity to show you the delivery options. If you save the document, however, the confirmed quantities are not saved. Your company could block confirmation for a customer if this customer's credit worthiness was questionable. The sales order in this case is not only classed as unconfirmed, it is also blocked for delivery.
17 Thus, no stock is reserved. The stock is still available for other customers. Although the order quantities are not confirmed, the system still transfers the requirements to material requirements planning. It is assumed that the delivery block will be removed at some point. The automatic transfer of requirements means that the order quantity can be confirmed at a later point in time. See also: Setting a delivery block
Setting a Delivery Block To set a delivery block at schedule line level which also blocks or defers the confirmation of order quantities, proceed as follows:
1. Select Overview → Shipping on the initial entry screen of the sales order. You reach the Overview - Shipping Data screen.
2. Enter a block which blocks or defers order quantity confirmations in the Delivery block field. Remember the differences between a delivery block at schedule line level and a delivery at header level (business data): For the delivery block at header level, the delivery type must be set in Customizing. The delivery block at schedule line level, however, is activated as soon as you enter it. If you want to see what would have been confirmed on the basis of the availability check if no delivery block with confirmation block had been set, select the relevant order items before you save the sales order and then select Item → Schedule lines. As soon as you save the sales order, all order quantities which have been confirmed by the availability check are reset to zero.
Removing a Delivery Block If you remove the delivery block or replace it with another delivery block which does not block confirmations, the system automatically performs a new availability check and confirms the available order quantities.
Deferring Confirmation of Quantities in Sales Documents In Customizing, using Requirements transfer per delivery block, you can specify that certain delivery blocks in the sales document header also defer the confirmation of order quantities, in that the deferral period is entered.
18 If, for example, you enter a delivery block in the sales order header and the oreder quantities can be confirmed within the deferral period specified, the system adds the deferral period to the current date, thus determining a material staging date. The requirements can, however, be passed on.
An order needs a letter of credit. The letter of credit will only be available in 14 days time, however. For this reason you want to block the order until the letter of credit arrives. You also do not want to reserve the material yet. In this case, a deferral period of 14 days must be entered in Customizing for the corresponding delivery block. You set the delivery block in the order header. The system carries out the availability check. The order quantity can be confirmed within the deferral period. The system adds 14 days to the current date and confirms the resulting, later date.
You can only use this option if scheduling is active for transportation and delivery. See also: Setting a delivery block
Rescheduling Sales Documents The following functions exist for rescheduling: •
Performing rescheduling
•
Evaluating rescheduling
Performing Rescheduling When rescheduling is performed, the open sales document items in the item index for the material are processed. The items found by this process are sorted according to the criteria delivery priority, date, document number, and item number and forwarded to the availability check. The results are then saved. Note the following constraint with regard to rescheduling and the combination of availability check against ATP logic and the check against product allocations. If you use the availability check against ATP logic and the check against product allocations, dates and quantities can only be redistributed in a restricted way. In SAP R/3 there is no information on which product allocation quantities in which periods are assigned to the sales order. The product allocation assignment is therefore missing. For that reason, when several sales orders are rescheduled, only the product allocation quantity of the sales order being checked each time can be released. If the product allocation quantities of all other periods are
19 already reserved, the sales order to be checked cannot be confirmed at any other time. Simulating Rescheduling You can carry out rescheduling in simulation mode. This can show you what would happen if you were to carry out rescheduling. The results are not saved, however. It only makes sense to carry out this function if you only want to check a very limited selection of documents. Credit Limit Block In the case of a credit limit block in the order header (delivery block reason '01'), a credit limit control is performed before the availability check if the special type of block affects requirements. The document can then only be processed further once the customer involved becomes creditworthy again. The results of the run are issued as a list and stored temporarily. They can be evaluated with the function ‘Evaluate rescheduling’. Selection Report There is a report in the standard system, that selects the documents relevant for rescheduling. If you want to create you own reports, contact your SAP consultant. Processing Parameters You can define the scope of the check using the parameter 'Unconfirmed documents required'. If this parameter is set, at least one document for this material must be unconfirmed if all documents for this material are to be included in the availability check. Otherwise (no unconfirmed documents exist for a material), no document for this material is included in the availability check. You can define that the delivery date entered when an order is created is used as a sorting criterion for the availability check using the parameter 'Sorting criterion deliv.date'. If this parameter is set, all orders of the same priority are sorted according to delivery date. Otherwise, sorting is performed by document creation date. Display Criteria The display criteria for the list can be defined under the menu option ‘List'. Improvements, deteriorations, and the complete list are the options. To be included in one of the two limited lists, an item must have undergone a date or quantity change. This means that an item can be included in both the improvements list and the deteriorations list. There is only an entry in the columns 'New date' and 'New confirmed qty’ if the fields 'Old date' and/or 'Old confirmed qty' have been changed. As the check for changes (date/quantity) is only performed by line in the original list, it is possible that an item which has become more overdue is included in the list of improvements. This occurs if, for example, the entire quantity can be delivered in one delivery but at a later date, as a comparison of quantities for this line reveals an increase. You must make sure that all required sales and distribution document types which are to be included in the item index have been correctly configured in Customizing. This means the item indexes for all SD document types which are to be included in the availability check must be activated.
Evaluating Rescheduling The evaluation function uses the list created by the function ‘Execute rescheduling’ as a work list. The outcome of the run is displayed in the form of a list. Display Criteria The display criteria for the list can be defined under the menu option ‘List'. The options are improvements, deteriorations, and the complete list. There is only an entry in the columns 'New date' and 'New confirmed qty’ if the fields 'Old date' and/or 'Old confirmed qty' have been changed. See also:
20 Performing Rescheduling of Sales Documents Evaluating Rescheduling of Sales Documents
Performing Rescheduling of Sales Documents
The program should only be run online in exceptional circumstances and even then with a very limited selection of documents, as it has a considerable effect on system resources. To perform rescheduling, proceed as follows:
1. In the entry screen, select Logistics → Sales/distribution → Sales. You reach the Sales screen.
2. Select Environment → Backorders → Rescheduling → Execute. You reach the Rescheduling in Sales: By Material screen where you carry out rescheduling. If you only want to simulate rescheduling, mark the Simulate field.
Background or Online Mode It is possible for both functions to be performed both in the background and online. We recommend you perform rescheduling in the background.
Evaluating Rescheduling of Sales Documents
You can only carry out this function after performing rescheduling. To evaluate rescheduling, proceed as follows:
1. In the entry screen, select Logistics → Sales/distribution → Sales. You reach the Sales screen.
21 2. Select Environment → Backorders → Rescheduling → Evaluate. 3. You reach the Rescheduling in Sales: Evaluation screen where you can carry out the evaluation.
Shortage Check If the availability check is carried out without the cumulative confirmed quantities or requirement quantities being taken into account, this can lead to more being confirmed than is available. The system checks whether ATP quantities arise in the period before the delivery date. If so, the new sales order reduces the ATP quantities if the ATP dates come befor the delivery date. If a planned inward movement of goods is delayed to a desired date after the confirmed date, then the confirmation of the sales order remains in place without a stock coverage being given. This is because a change to inward movement of goods does not necessarily change the order. In this situation, a newly created order could be confirmed because of the delayed inward movement of goods and lead to more being confirmed than is available.
Situation 1 Inward/outward moverment
Quantity
ATP quantity
Cumulative
Confirmed
ATP quantity
quantity
Stock
100
0
0
-
Planned order
100
0
-100
-
Sales order 1
-200
-
-
-200
ATP quantity
Cumulative
Confirmed
ATP quantity
quantity
Situation 2 Inward/outward moverment
Quantity
Stock
100
0
0
-
Sales order 1
-200
-100
-100
-200
Planned order
100
0
0
-
22
Sales order 2
-100
-
-
-100
In Situation 1, the first sales order is confirmed for its full quantity for a point in time before the planned order. In Situation 2, the planned order has now been delayed until after the delivery date for sales order 1. For the new sales order 2, the availabililty check reports an ATP quantity of 100, as the full quantity of the deferred planned order is still available and, according to this checking logic, sales order 1 cannot be supplied by this inward movement of goods. The example shows how an error is caused in confirmation by the deferring of a planned order. This causes the total of the confirmed quantities to exceed the total of all inward movement of goods. There are three possible ways of avoiding this error: •
Carring out a planning run
•
Rescheduling
•
Backorder processing
Since these functions are very time consuming, it is possible for orders to be delivered that should not be delivered at all according to their entry data. The shortage check is used to avoid this situation. You can define how the availability check is carried out under Define checking group in SD Customizing. The options are as follows: •
Set up check to take cumulative confirmed quantities into account The system takes into account the total of all confirmed quantities when calculating the cumulative ATP quantity. This means that new sales orders can only be confirmed if the total for inbound goods is greater than the total for confirmed quantities. We recommend that you work with the cumulative requirement quantities when you create sales orders.
•
Set up check to take cumulative requirement quantities into account The system takes into account the total of all open requirement quantities when calculating the cumulative ATP quantity. This means that new sales orders can only be confirmed if the total for inbound goods is greater than the total for requirement quantities. We recommend that you work with cumulated confirmed quantities when you change sales orders.
23
Processing Sales Documents in Backlog The backorder processing functions enable you to list relevant sales documents for specific materials and process them from the point of view of confirmation. You can assign available to promise (ATP) stock to outstanding order quantities. In addition, you can withdraw already confirmed quantities and reassign them to different items. For further information on backorder processing, see
backorder processing.
Displaying the Availability Situation in Sales Documents You can display the following information on the availability of a material: •
Stock for a material by storage location and plant
•
Stock for a material by plant
•
Availability for an item in the sales document
Stock for a Material by Storage Location and Plant To display the stocks:
1. Select Logistics → Materials management → Inventory management on the main menu screen. You reach the Inventory Management screen.
2. Select Environment → Stock → Stock overview. You reach the Stock Overview: Company Code/Plant/StLocation/Batch screen.
3. Enter your selection criteria and select Program → Execute. You reach the Stock Overview: Basic List. Stock is displayed here by plant, storage location and, if appropriate, by batch.
4. Place the cursor on a line of the stock list for which you want to access detailed information and select Edit → Choose. A window appears in which the individual stock for the line selected is listed. From this list, you can display the following additional information with the menu option Environment. •
Stock/requirements situation (current requirements)
24 •
Open purchase orders
•
Reservations
•
Material movements
•
Warehouse management (WM) stocks
To display this information, place the cursor on one of the lines below the company code level and select the appropriate menu option.
Stock for a Material by Plant To display the stocks:
1. Select Logistics → Materials management → Inventory management on the main menu screen. You reach the Inventory Management screen.
2. Select Environment → Stock → Plant stock avail. You reach the Plant Stock Availability screen.
3. Enter the material number and the plant. Then select one of the following values for the Scope of list field: Scope of List when you Display Plant Stock Availability Scope of list
Display
AA
Stock at plant level
BB
Stock at storage location level
CC
Stock at plant and storage location level
DD
Stock at plant and storage location leve with a few future stocks, such as: planned inward movements.
4. Select Program → Execute. You reach the screen on which the stock is displayed.
Availability for an Item in the Sales Document In the sales document, you can display the availability situation as follows:
1. On the overview screen or an item screen in the sales document select Environment → Availability. You reach the availability overview where the current availability situation with regard to ATP quantities are displayed. The requirements reduced by the sales document being
25 processed is simulated in the overview so that the availability situation is illustrated including this sales document.
2. Select Overview → Exit to return to the sales document.
Availability Check Against Product Allocation Product Allocation Availability Check against Product Allocation During Order Entry SD Display Availability Check Against Product Allocation
Product Allocation A precise planning and controlling mechanism is of the utmost importance for the execution of competitive order processing with guaranteed efficient and timely delivery to the customer of the required order quantity. Unforseen problems, such as production deficits or increased demand can have critical consequences for order processing and must be brought under control as soon as possible. Product allocation is a function provided by the SAP System for carrying out these control options intended to help your company to avoid critical requirement and procurement situations. This should enable you to keep production to a minimum at the same time as allowing you to react quickly to bottlenecks and changing market situations. In the SAP System, product allocations represent an ordered allocation of production for certain periods. Product allocations can be created according to various criteria (i.e., customer, regions). Product allocations are created in the logistics controlling area in the planning hierarchy (Logistics → Logist. controlling → Flexible planning → Planning create/change → Planning type: COMMIT for SAP standard planning type). Product allocations are always divided right up to the lowest level in the hierarchy. The basis for the planning hierarchy is info structure “S140”, which SAP issues as the standard info structure. It determines the criteria of the hierarchy. You can define your own info structures in Customizing for LIS (Logistics General → Logistics Information System → Reporting → Standard Analyses → Change settings). When creating product allocations, make sure that you use version number “000”.Because updates are carried out for this version number.
26 If a product allocation of 5000 pieces were to be entered at the material level as depicted in the diagram below, it would be automatically distributed among the lower levels (= consistent planning). Changes are possible at every level, but the other levels are still adjusted automatically.
As of Release 3.0F, it is possible to carry out an availability check against product allocations. The check is still carried out if neither the availability check nor transfer of requirements are activated in Customizing. This ensures, for example, that when production is low, the first customer does not get the full amount, resulting in following sales orders not being confirmed or being confirmed far too late. The check is carried out on the basis of the confirmed quantity from the ATP check against the corresponding product allocation. To get reliable information and to recognise critical situations, the actual requirements are compared with the planning product allocations throughout the entire product allocation period.
General Requirements To carry out availability check against product allocation, certain requirements must be met: •
Material master
•
In the material master, the product allocation determination procedure must be entered in the basic data screen for general data.
•
Statistics update In Customizing for the Logistics Information System, statistics updating must be set for the information structure. This is required at customer, material and header level. The update group must also be maintained in Customizing for the Logistics Information System.
•
In Customizing for SD, the settings must be made for availability check against product allocation. You will find the necessary steps described in the Implementation Guide in section “Availability check against product allocations”. This is where, the necessary Customizing activities for the statistics update are described.
Availability Check Against Product Allocation During Order Entry SD
27 The planning hierarchies for product allocations are created in logistics controlling. If the correct settings have been made in Customiuing, the system carries out an availability check against the ATP quantity in SD during order entry. If the availability check determines that the ATP quantity can fully or partially cover the order requirement, then a confirmed quantity is determined as the result of the check. The confirmed quantity is the basis for the availability check against product allocation, which is carried out along with the ATP check. The confirmed quantity from the ATP check is checked against the relevant product allocation. This ensures that the product allocation for this period is not exceeded. Required quantities that cannot be confirmed, because the product allocation for that period is used up, are postponed until the next period. The result of the product allocation check can change confirmed quantities that have already been determined. In this case you receive a message before branching to the availability control screen. For example, even though the material for an order for 100 pieces may be available in full for the required date according to the ATP check, it is only partially confirmed because the product allocation for that customer only had a value of 80 pieces remaining at the time of order entry. The confirmed quantity for the required quantity and an alternative delivery date is displayed on the control screen.
Unlike the ATP check, the check date for the availability check against product allocations is the planned delivery date for the customer and not the material availability date. The actual order quantities are updated in the planning hierarchy of the LIS. Comprehensive reporting tools and an early warning system in the LIS that has to be set in Customizing monitor the status of the product allocation period and report critical situations immediately.
Product allocation uses a blocking mechanism similar to quantity block in the ATP check: The check hierarchy of the corresponding product allocation object is only blocked exclusively during the check itself. Afterwards, the same object can also be used by other processes without the current procedure having been saved. The product allocation quantity used is, however, seen in all subsequent processes (via this blocking mechanism) to prevent over-confirmation.
Display Availability Check Against Product Allocation The system can carry out an availability check against product allocation automatically during order entry. When availability is low, you branch to the availability control screen automatically. From there, you can view the result of the product allocation. This is done as follows:
1. In the availability control screen, branch to the display of the availability situation with regards to product allocations via Goto → Product allocations.
28 2. By clicking on the "product allocation" symbol, you can view the product allocation that was checked against. You can see which product allocations are available for which periods, how much the product allocation has been used up by other orders and how much product allocation remains.
Available-to-Promise on the Internet Use An essential activity in many business processes within Logistics is the checking of available resources before making critical decisions or commitments. For customeroriented companies, it is vital that reliable information on the availability of resources can be access at all times. This is especially important in the sales department as before the salesperson can provide the customer with reliable dates, s/he requires immediate access to information on the availability of a product. The availability check in the SAP System provides decision support for a large number of logistics operations at all organizational levels, that is, at plant level, storage location level and at batch level. The check can be adjusted to suit the specific requirements of each company. This guarantees the necessary flexibility for dealing with the customer and within the company itself. For more information on the availability check refer to the SAP Knowledge Product Availability Check. The Internet Application Component Available to Promise has been created as an example scenario in the SD environment. The Available to Promise screen shows the results of the material availability check in a clear and simple overview. Type of Internet Application Component •
Business-to-Business
•
Consumer-to-Business
For customer-oriented companies, easily accessible information on material availability that can be read at a glance provides an important basis for making decisions in an increasingly competitive market environment. Therefore, many companies (especially in the high tech and consumer goods branches of industry) are keen to take advantage of the new opportunities provided by the Internet. They want the necessary support for their business processes, for example: •
Tools for the salesperson must be transparent and easy to use.
•
System information must be provided quickly and should be easy to understand.
If you work in Production Planning, in Sales and Distribution or if you are a customer and you use the Internet Application Component Available to Promise, you have the following advantages: •
You can access Available to Promise from anywhere in the world around the clock.
•
The layout of Available to Promise is simple and easy to use. For example, to select the product in which you are interested, you only have to select the line.
•
Using the Internet, the customer can access information on the available quantities for certain products without having to get in touch with the sales department of the company (if a customer master record has been created in the SAP System).
•
Vendors can see which products are still available and how much is still available. This means that they know when to anticipate necessary deliveries.
29
Prerequisites Authorizations/Security No special authorizations are required for this Internet Application Component. Internet Users
To trigger the Internet Application Component in the Internet, you must log on using your SAP user name and your password. If you are a customer, you also require a customer master record and a password of your choice in the SAP System. Using transaction SU05, you can create, change and delete passwords for Internet users. To specifically identify users, enter the object type KNA1 as well as the number of the SAP user master record or the customer number. Standard Settings and Default Values Browser
The browser used must be Java-enabled (for example, Netscape Navigator >3.0, Microsoft Internet Explorer > 3.0). The browser must also be set so that Java programs can run. Product Selection Using the Java Applet
You select a product for which you want to see Available to Promise using a Java applet. A Java applet is a small program that is loaded and executed on your PC along with the HTML page. When started, the Java applet loads the contents of the product catalog from two files saved in the Web server. Using the product hierarchy tree and a text search, you can select a product in the applet and copy it to the input field for the availability check. Using the text search functions in the applet, you can search for material numbers and descriptions. You can also carry out a generic search using ‘*’. If you enter “test”, for example, a search will be made for precisely this string. Entering “test*” triggers a search for everything that starts with with “test”. Entering “*test” triggers a search for everything that contains the string “test”. The search does not differentiate between lower and upper case characters. In problem cases, for example, if a file cannot be read or contains inconsistent data, the applet terminates and an error message is displayed in the status line of the browser. In the Netscape Navigator, this message also appears in the Java Console that can be displayed via the menu. Default Values for Input
Using the Java applet, you can preset certain parameters for accessing information from the SAP System. The contents of the applet are provided by the report PCATALOG which accesses the data in the product catalog which it saves as two files. Copy these files to the Web server. This procedure requires the maintenance of a product catalog in the SAP System. Here, make sure that materials are not assigned more than once. Furthermore, use the base unit of measure. (See also the SAP documentation on the product catalog.) Activities involved in including your own product catalog ...
1.
Create a product catalog in the SAP System’s product catalog maintenance screen.
30 2. 3. 4.
Use the report PCATALOG to create the input files for the Java applet. Place the input files for the Java applet on the Web server. Adjust the applet parameters on the HTML page to the new files.
Default Values for the Checking Rule
Information on material availability in the SAP System is given according to the scope of the check which is determined by the material’s checking group and the checking rule A of the sales department. See also the documentation on the function module, BAPI_MATERIAL_AVAILABILITY for tips on transferring special checking rules.
Features Modification Options You can change the layout of this Internet Application Component. Every change to the development objects used in the Internet Application Component is taken as a modification. Do not in any circumstances change the development objects of the standard system. Service Name
The service name of this Internet Application Component is CKAV. You can find all the relevant data under this service name in the SAP@Web Studio. Modification Options
The Java applet can be controlled using the following parameters: Parameter
Description
Example
Products (Essential parameter)
Path and file name for the product file. You must specify an absolute path (starting with ‘/’) that is valuated from the root directory of the Web server.
/sap/its/startpages/ckav/data/ materials.txt
Hierarchy (Essential parameter)
Path and file name for the file with the product hierarchy. You must specify an absolute path (starting with ‘/’) that is valuated from the root directory of the Web server.
/sap/its/startpages/ckav/data/ hierarchy.txt
BgColor (Optional)
Background color of the HTML C0C0C0 page that contains the applet. By specifying this parameter, the background of the tab (the area to the right of the two index cards) is displayed in the transferred colors. The color is specified as a hexadecimal number with 6 numbers. The format is the same as a color specification in the
31 HTML. However, note that you cannot enter a leading ‘#’.
The parameters are specified in the applet tag in the HTML page. With the above example data, the applet tag is as follows:
Development Objects
In the SAP System, the data exchange via the Internet is carried out using transactions and function modules. The following developments are required for creating and passing on service messages: Development class:
MDW1
Transaction:
CKAV
Function group for the screens:
W61V
Function modules:
BAPI_MATERIAL_AVAILABILITY
Data Output via the Internet Transaction Server
Data output is performed using the Internet Transaction Server (ITS). The data is merged with the output forms and made available on the Internet/intranet in HTML format. The output forms are in the subdirectory CKAV of the directory TEMPLATES. The following forms are used: SAPMAVCK_500.HTML SAPMAVCK_600.HTML SAPMAVCK_1100.HTML SAPMAVCK_1200.HTML SAPMAVCK_1300.HTML CKAV_D.HTRC CKAV_E.HTRC CKAV_J.HTRC The numbers in the names of the forms correspond to the screen numbers.
32
Credit and Risk Management (SD-BF-CM) Credit management Purpose Outstanding or uncollectible receivables can spoil the success of the company greatly. Credit Management enables you to minimize the credit risk yourself by specifying a specific credit limit for your customers. Thus you can take the financial pulse of a customer or group of customers, identify early warning signs, and enhance your credit-related decision-making. This is particularly useful if your customers are in financially unstable industries or companies, or if you conduct business with countries that are politically unstable or that employ a restrictive exchange rate policy.
Integration If you are using the Accounts Receivable (FI-AR) component to manage your accounting and an external system for sales processing, Credit Management enables you to issue a credit limit for each customer. Every time you post an invoice (created in FI-AR), the system then checks whether the invoice amount exceeds the credit limit. Information functions such as the sales summary or early warning list help you to monitor the customer’s credit situation. If you are using both the Accounts Receivable (FI-AR) component to manage your accounting and the Sales and Distribution (SD) component for sales processing, you can also use Credit Management to issue credit limits for your customers. You can make settings in Customizing to decide the scope of the check and at what stage in the process (for example, order entry, delivery or goods issue) a credit limit should take place. General information functions are also available for use with credit checks.
Features If you are using both the SD and FI-AR components, Credit Management includes the following features: •
• • • •
Depending on your credit management needs, you can specify your own automatic credit checks based on a variety of criteria. You can also specify at which critical points in the sales and distribution cycle (for example, order entry, delivery, goods issue) the system carries out these checks. During order processing, the credit representative automatically receives information about a customer’s critical credit situation. Critical credit situations can also be automatically communicated to credit management personnel through internal electronic mail. Your credit representatives are in a position to review the credit situation of a customer quickly and accurately and, according to your credit policy, decide whether or not to extend credit. You can also work with Credit Management in distributed systems; for example if you were using centralized Financial Accounting and decentralized SD on several sales computers.
33 You can find information about where to make Customizing settings for Credit and Risk Management in Settings for Credit and Risk Management
Risk Management for Receivables See Risk Management for Receivables in SD for information about managing risks for receivables.
Settings for Credit Management and Risk Management: Overview The table below lists the most important settings that you make in Customizing for Credit Management. The relevant Implementation Guide (IMG) provides a detailed description of the individual activities. Access via
Menu path
Accounting application
Accounting → Financial accounting → Accounts receivable → Credit management → Master data → Change
Enterprise Structure Customizing
Enterprise Structure → Structure maintenance → Definition → Financial
Settings for Creating credit data (Determine credit limit for customer) Credit control area
Credit control area
Accounting → Maintain
Credit Control
Area Company code - Credit control area
Enterprise Structure Customizing
Enterprise Structure → Structure maintenance → Assignment → Financial Accounting → Assign
and Financial Accounting Customizing
Company Code to Credit Control Area and Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Assign
Permitted Control Areas to Company Code Company code - Credit control area
Enterprise Structure Customizing
Enterprise Structure → Structure maintenance → Assignment → Sales and Distribution → Assign
Sales
34
Organization to Company Code Subdividing the credit control area
Credit representative groups
Financial Accounting Customizing
Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Define
Credit Representative Groups Credit representative
Financial Accounting Customizing
Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Define
Credit Representative Groups Risk category
Financial Accounting Customizing
Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Define
Risk
Categories Sending a document with SAPoffice
Defining credit limit checks for sales and distribution processing
Automatic credit control
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Credit Management/Risk Management Settings → Enter settings
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Credit Management → Define
Automatic Credit Control Risk management for receivables
Define form of payment guarantee
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Receivables risk management → Define
Forms of Payment Guarantee Define and assign payment guarantee procedures
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Receivables risk management → Define
Forms of Payment Guarantee
Risk Management for Receivables in SD Purpose As well as Credit Management, there are several other ways to guarantee payments including letters of credit, export credit insurance, and payment cards. These forms of payment guarantees are all integrated in the Risk Management for Receivables component, providing you with an efficient tool for guaranteeing the payment of all billing values that arise in sales and distribution processes.
Integration You can only use Risk Management for Receivables if you are also using the Sales and Distribution component.
Features
35 The following forms of payment guarantee are available in the Risk Management component: • • •
Documentary payment (for example, letters of credit). Payment cards Export credit insurance (external link)
The form of payment guarantee controls how you guarantee the payment of a sales document item (for example, using a private guarantee, payment card, unconfirmed or confirmed letter of credit, or export credit insurance). In the first step you can use a secure form of payment such as a letter of credit to try and minimize the payment risk as much as possible. If this is insufficient, you can turn to Credit Management to create a credit limit for restricting the risk. In this way, Credit Management enables you to secure values yet to billed that could not be guaranteed using a form of payment guarantee. The following graphic shows how credit and risk management work together to minimize your risks.
The vertical axis shows the size of the risk related to the type of guarantee on the horizontal axis. The risk decreases according to the type of payment guarantee in use. For example, the risk is greatest if you use no payment guarantees and is at a minimum when you use letters of credit. (See also Calculating the Credit Value).
For information about the different areas and Customizing settings you need in the Implementation Guide (IMG) for Credit and Risk Management, see Settings for Credit and Risk Management: Overview.
Customer Hierarchies Use With customer hierarchies you can now create flexible hierarchies to reflect the structure of customer organizations. For example, if your customer base includes multi-level buying groups,
36 cooperatives, or chains of retail outlets, you can create hierarchies to reflect the structure of these groups. You use customer hierarchies in order and billing document processing for partner and pricing determination (including rebate determination) and for creating statistics. You can use customer hierarchies to assign price conditions and rebate agreements to one of the customer’s subordinate levels, to ensure that all subordinate levels are valid for the customer. For each node that you indicate as relevant for pricing, you can create condition records for pricing. If one or more nodes in a hierarchy path for a sales order contain pricing data, this is automatically taken into account in pricing.
Integration You can also use customer hierarchies for evaluations in profitability analysis (CO-PA) and in the Sales Information System (SIS): To evaluate customer hierarchies with the sales information system and in the profitability analysis, you can maintain the field Hierarchy assignment on the Marketing tab page in the customer master record for a hierarchy customer. Here you can maintain 10 features for hierarchy customers (HIEZU01 to HIEZU10). You can use these to evaluate hierarchies statistically with up to 10 levels. (Field catalogue VHIE)
Note that the hierarchy assignment is statistical. If you change the customer hierarchy, you may need to change the hierarchy level manually in the customer master record in the Hierarchy assignment field.
Features A customer hierarchy is a flexible structure consisting of customers. Each customer - with the exception of the uppermost customer - refers to another customer at a higher level in the hierarchy (known as a higher-level customer). Customers that are assigned to higher-level customers are known as dependent customers. To be able to display organizational elements, that are not independent partners, you can assign pure hierarchy nodes (account group 0012) in the hierarchy. Specific data can be assigned to a hierarchy node (for example, address, price conditions, rebate agreements) and this then applies to all subordinate customers. As all nodes in a hierarchy are time-dependent, you can adapt the customer hierarchy to changes in the structure of a customer at any time. • • •
Customers can be reassigned in a hierarchy When reassigning a customer, all subordinate customers are moved with it You can add new customers to a hierarchy When you assign a new customer to an existing hierarchy, all pricing data, that applies to the higher-level hierarchy node, is automatically copied from the customer You can also remove customers from the hierarchy
See also: Customer Hierarchies and Pricing
37
Link between Sales and Distribution and Accounting By assigning sales organizations and plants you create a link between company codes and sales organizations. A plant, though always linked to one company code, can be assigned to different sales organizations. Within a company code several sales organizations can be active. Business transactions can also be carried out between different company codes (for example, during intercompany sales processing). The following figure displays possible assignments of company codes, sales organizations and plants.
Plants 1, 2 and 3 belong to company code 1. Sales organization 1 uses plants 1 and 2. Sales organization 2 uses plants 2 and 3. Sales organizations 1 and 2 can make cross-company sales for goods from plants 4 or 5.
Creating Customer-Material Information Records If a customer manages a material with a number that differs from the one your company uses, a customer-material information record is created.
Steps: Use the following steps to create a customer-material information record:
1. In the SD Master Data Screen select, Agreements → Cust.-material info → Create. You reach the Create Customer-Material Info Record screen.
2. Enter the customer number, the sales organization and a distribution channel. Thus, you can specify to which part of your organization the information record applies.
38 3. Press ENTER. You reach the Create Customer-Material Info Record: Overview screen 4. Edit the data screen by entering data in the following fields: – In the field Material enter the number which identifies the material in your company. – In the field Customer material enter the number that the customer uses to identify the material. 5. Press ENTER. The system adds the material description used in your company. Press Info record details to display the items created, and to enter shipping data, as well as partial delivery agreements.
6. If you want to maintain a text, select Goto → Texts in the Overview screen You reach the Text screen, where you can enter your text.
7. If you want to enter several lines of text, mark the text lines and select Edit → Detail, to get to the SAPscript editor.
8. Save your text after maintaining it in the SAPscript editor. You return to to the Text screen of the sales information record using Goto → Back. 9. Save the data record. In the message line, you receive the message that customer-material info record was saved.
Sales Master Data Screen Depending on the system you are using, choose System Standard SAP System SAP Retail
Menu path Logistics ® Sales and distribution ® Master data Master data
Creating Item Proposals Item proposals are created, if certain material combinations are often ordered and delivered in certain quantities. When creating item proposals, different materials with proposed quantities can be entered.
39 You can also adopt bills of material (e.g., configurable materials) into an item proposal. However, it is NOT possible to explode, or configure a bill of material in an item proposal. You can only carry this out when you are copying it into a sales order.
Steps: Use the following steps to create an item proposal:
1. In the SD Master Data Screen select, Products → Item proposal → Create. You reach the Create Item Proposal: Initial Screen.
2. Edit the data screen by at least entering data in the fields Item proposal type, Sales 3.
organization, Distribution channel and Division. Press ENTER . You reach the Create Item Proposal: Overview - Fast Entry screen where you enter the item proposal.
4. Create the item proposal by entering the materials and the quantities. In the field Description, you can define a search term which you can later use to retrieve the item proposal by using the matchcode.
If you want to create an item proposal for a bill of material, enter the header material without the component. When the item proposal is transferred to the sales document, the bill of material is then exploded or configured. Make sure that an item category is determined in the sales order that allow bill of material explosion or configuration. This is controlled in Customizing for the item category in the Structure scope field.
5. Press ENTER and save the item proposal. The system saves the item proposal and assigns an item proposal number. You receive the following system message: Item Proposal
- was saved You remain on the same data screen, where you can create another item proposal. Select Back to return to the initial screen.
Basic Functions in SD Purpose The most important basic functions are: • •
Pricing Availability Check
40 • • • • • •
Credit Management Material Determination Output Determination Text Processing Tax Determination Account Determination
Pricing and Conditions Purpose The term pricing is used broadly to describe the calculation of prices (for external use by customers or vendors) and costs (for internal purposes, such as cost accounting). Conditions represent a set of circumstances that apply when a price is calculated. For example, a particular customer orders a certain quantity of a particular product on a certain day. The variable factors here - the customer, the product, the order quantity, the date - determine the final price the customer gets. The information about each of these factors can be stored in the system as master data. This master data is stored in the form of condition records.
The Condition Technique in Pricing The condition technique refers to the method by which the system determines prices from information stored in condition records. In Sales and Distribution, the various elements used in the condition technique are set up and controlled in Customizing. During sales order processing, the system uses the condition technique to determine a variety of important pricing information. For example, the system automatically determines which gross price the customer should be charged and which discounts and surcharges are relevant given the conditions that apply.
Example of Pricing in the Sales Order The following figure shows how the condition technique works in the background to produce the pricing information. The diagram shows how the various elements in the condition technique work together.
41
1. The system determines the pricing procedure according to information defined in the sales document type and the customer master record. 2. The pricing procedure defines the valid condition types and the sequence in which they appear in the sales order. In the example, the system takes the first condition type (PR00) in the pricing procedure and begins the search for a valid condition record. 3. Each condition type in the pricing procedure can have an access sequence assigned to it. In this case, the system uses access sequence PR00. The system checks the accesses until it finds a valid condition record. (Although you cannot see this in the diagram, each access specifies a particular condition table. The table provides the key with which the system searches for records). 4. In the example, the first access (searching for a customer-specific material price) is unsuccessful. The system moves on to the next access and finds a valid record. 5. The system determines the price according to information stored in the condition record. If a pricing scale exists, the system calculates the appropriate price. In the example, the sales order item is for 120 pieces of the material. Using the scale price that applies to quantities from 100 pieces and more, the system determines a price of USD 99 per piece. The system repeats this process for each condition type in the pricing procedure determines a final price. For further information on the condition technique, see Introduction to the Condition Technique
Introduction to the Condition Technique Use This section describes the elements within the condition technique. It is organized to reflect the likely sequence of events that you go through when you implement pricing in Customizing. The standard SAP System includes predefined elements for routine pricing activities. For example, the standard system includes condition types for basic pricing
42 elements, such as material prices, customer and material discounts, and surcharges such as freight and sales taxes. In the case of each element, you can use the standard version, modify the standard version, or create entirely new definitions to suit your own business needs. The sequence of activities is generally as follows: ...
1. Define condition types for each of the price elements (prices, discounts, and surcharges) that occur in your daily business transactions. 2. Define the condition tables that enable you to store and retrieve condition records for each of the different condition types. 3. Define the access sequences that enable the system to find valid condition records. 4. Group condition types and establish their sequence in pricing procedures.
For more information about implementing and customizing pricing in sales order processing, see Customizing for Sales and Distribution. For a more technical description of how the condition technique works, see the Business Workflow documentation for Message Control.
Elements Used in the Condition Technique Condition Types Condition Tables Access Sequences Pricing procedures
Condition Types Use A condition type is a representation in the system of some aspect of your daily pricing activities. For example, you can define a different condition type for each kind of price, discount or surcharge that occurs in your business transactions. Example of a Condition Type You define the condition type for a special material discount. You specify that the system calculates the discount as an amount (for example, a discount of USD 1 per sales unit). Alternatively, you can specify that the system calculates the discount as a percentage (for example: a 2% discount for orders over 1,000 units). If you want to use both possibilities, you must define two separate condition types. The following figure illustrates how condition types can be used during pricing in a sales document.
43
In the example in the preceding figure, two discounts apply to the item in the sales order. The first discount is a percentage discount based on the quantity ordered. The second discount is a fixed discount based on the total weight of the item. You determine the calculation type for a condition type in Customizing. This determines how the system calculates prices, discounts and surcharges for a condition. When setting up condition records, you can enter a different calculation type than the one in Customizing. At present all available calculation types are permitted. The field ‘Calculation type’ can however not be accessed if this field is left empty. After the data release has been printed, if the field has not been completed manually, the proposal is automatically taken from Customizing. After this it is no longer possible to make manual changes. If you use different calculation types for what are otherwise the same conditions (for example, percentage, as a fixed amount or quantity-dependent), you do not have to define different condition types in Customizing. You can set a different calculation type when maintaining the individual condition records.
Condition Types in the Standard Version of the SAP System The standard system includes, among many others, the following predefined condition types: Condition type
Description
PR00
Price
K004
Material discount
K005
Customer-specific material discount
K007
Customer discount
K020
Price group discount
KF00
Freight surcharge (by item)
UTX1
State tax
44 UTX2
County tax
UTX3
City tax
Creating and Maintaining Condition Types You can change and maintain condition types provided in the standard version of the SAP System or you can create new condition types to suit the needs of your own organization. You create and maintain condition types in Customizing. To reach the condition type screen from the initial Customizing screen for Sales and Distribution: ...
1.
Basic Functions → Pricing → Pricing Control → Define condition types.
A dialog-box appears, listing the transaction options. Select the corresponding transaction for defining the condition types. 2. In the Conditions: Condition Types view, you can change existing condition types or create new ones.
Condition Tables Use A condition table defines the combination of fields (the key) that identifies an individual condition record. A condition record is how the system stores the specific condition data that you enter in the system as condition records. For example, when you enter the price for a product or a special discount for a good customer, you create individual condition records. Example of a Condition Table A sales department creates condition records for customer-specific material prices. The standard version of the SAP System includes condition table 005 for this purpose. The key of table 005 includes the following fields: •
Sales organization
•
Distribution channel
•
Customer
•
Material
The first two fields identify important organizational data and the last two fields express the relationship between customers and specific materials. When the sales department creates a condition record for a material price or discount that is specific to one customer, the system automatically uses condition table 005 to define the key and store the record. The following figure illustrates the connection between the condition table and the subsequent condition records.
45
Condition Tables in the Standard Version The standard system includes predefined condition tables and specifies them for each access in each predefined access sequence. Creating or Maintaining Condition Tables You can change and maintain the condition tables in the standard system. You can also create new condition tables to meet the needs of your own organization. You create and maintain condition tables in Customizing. From the initial screen of Customizing for Sales and Distribution, you reach the condition table screens by choosing Basic functions → Pricing → Pricing Control → Define condition tables. Then select the mode you want to work with (create, change, display). Information About Fields The fields that you choose to make up the key are called the selected fields. The fields from which you can make your selection are called the allowed fields. Selected Fields The preceding figure shows the fields that make up the key for condition table 005 (the table for customer/material condition records in Sales). The selected fields show organizational data, such as Sales organization.The fields Customer and Material define the relationship between a particular customer and material.
46 Field Catalog (Allowed Fields) When you select fields for the key, you must choose the fields from the list of allowed fields.
Making Changes to Condition Tables You can make limited changes to existing condition tables. For example, you can change the name of the table or the format of the fast entry screens for the condition records. (Fast entry screens are screens where you can quickly, on a single screen, create and maintain the condition records that refer to the condition table). Format of a Fast-Entry Screen The screen consists of header and item lines. Each item line represents a separate condition record. The header lines include the fields that are general to all item lines. When deciding on the format of the fast-entry screen, you can determine whether each field in the key appears as a line in the header or as an item line. Changing the Format of a Fast-Entry Screen To change the format of the Fast-Entry screen, choose F6 (Technical View) on the screen where you create or maintain a condition table. When you determine the format, you have the following possibilities: If you want the...
Do the following...
Field to appear as a header line
Leave the line field blank
Field to appear as an item
Mark the line field
Text for an item line to appear
Mark the text field
After you make changes to a condition table, choose F16 Generate) to regenerate the table.
Creating a New Condition Table You can create new condition tables to meet the pricing needs of your organization. When you create a new condition table, you select a combination of fields from the list of allowed fields. The selected fields define the key for the subsequent condition records. Before you select the fields for the key, there are two things to consider: •
The sequence (or hierarchy) of the fields
•
Which fields you want to appear in the header and item areas of the corresponding fastentry screens
Important Fields In sales, the fields you should take into consideration are Sales organization and Distribution channel. The sales organization is nearly always used as a criteria in pricing, because different sales organizations often want to use their own prices, discounts, and surcharges. If you use the sales organization as a criterion in pricing, you should also use the distribution channel. If you do not want to establish different prices, discounts, and surcharges for each distribution channel, use the field anyway. In
47 Customizing for Sales, you can use one distribution channel as a reference for all others (thereby sharing the same pricing data). Deciding the Sequence of Fields The order of the fields in a condition table affects the performance of the system during pricing. Two general guidelines will help you create an efficient condition table: ...
1. If you select fields that are connected to the structure of your organization (for example, sales organization and distribution channel), assign the fields according to the level of general applicability: Put the most general field, for example, the sales organization in the highest position and the most specific field in the lowest. 2. After organizational fields, place fields from the document header before those that come from the item level. (For example, Customer comes before Material)
After you have selected the fields for the key on the screen where you maintain and define condition tables, choose F16 Generate to generate the table in the system. Generation prepares the condition table for storing condition data.
Access Sequences Use An access sequence is a search strategy that the system uses to find valid data for a particular condition type. It determines the sequence in which the system searches for data. The access sequence consists of one or more accesses. The sequence of the accesses establishes which condition records have priority over others. The accesses tell the system where to look first, second, and so on, until it finds a valid condition record. You specify an access sequence for each condition type for which you create condition records. There are some condition types for which you do not create condition records (header discounts that you can only enter manually, for example). These condition types do not require an access sequence. A sales department may offer customers different kinds of prices. The department may create, for example, the following condition records in the system: 1.
•
A basic price for a material
1.
•
A special customer-specific price for the same material
1.
•
A price list for major customers
During sales order processing, a customer may, in theory, qualify for all three prices. The access sequence enables the system to access the data records in a particular sequence until it finds a valid price. In this example, the sales department may want to use the most favourable price for a certain customer. For this reason, it ensures that the system searches for a customer-specific price. The following figure shows how the system searches for the relevant record.
48
Access Sequences in the Standard Version of the SAP System The standard version of the SAP System contains access sequences that are predefined for each of the standard condition types. The names of the access sequences often correspond to the condition types for which they were designed. For example, the access sequence for a material discount (condition type K004) is also called K004.
Creating and Maintaining Access Sequences You create and maintain access sequences in Customizing. For more information, see the online Implementation Guide for Sales and Distribution. To reach the access sequence screen, go to the initial screen for Sales and Distribution Customizing and choose: ...
1.
Basic Functions → Pricing → Pricing Control → Define access sequences
Select the transaction that you want to execute (Maintain access).
Pricing Procedures Use The primary job of a pricing procedure is to define a group of condition types in a particular sequence. The pricing procedure also determines: •
Which sub-totals appear during pricing
•
To what extent pricing can be processed manually
•
Which method the system uses to calculate percentage discounts and surcharges
•
Which requirements for a particular condition type must be fulfilled before the system takes the condition into account
49
Example of a Pricing Procedure If a sales department processes sales orders for a variety of foreign customers, the department can group the customers by country or region. A pricing procedure can then be defined for each group of customers. Each procedure can include condition types that determine, for example, country-specific taxes. In sales order processing, you can specify pricing procedures for specific customers and for sales document types. The system automatically determines which procedure to use.
Pricing Procedures in the Standard Version of the SAP System The standard system contains pre-defined pricing procedures, which contain frequently used condition types along with their corresponding access sequences. You can, of course, modify these procedures or create your own from scratch.
Creating and Maintaining Pricing Procedures You create or maintain pricing procedures in Customizing for Sales. For more information on creating pricing procedures, see the online Implementation Guide for Sales and Distribution. To reach the pricing procedure screen from SD Customizing: ...
1. Choose Basic Functions → Pricing → Pricing control → Define and assign pricing procedures. 2. Select the transaction that you want to execute.
Credit and Risk Management (SD-BF-CM) Credit management Purpose Outstanding or uncollectible receivables can spoil the success of the company greatly. Credit Management enables you to minimize the credit risk yourself by specifying a specific credit limit for your customers. Thus you can take the financial pulse of a customer or group of customers, identify early warning signs, and enhance your credit-related decision-making. This is particularly useful if your customers are in financially unstable industries or companies, or if you conduct business with countries that are politically unstable or that employ a restrictive exchange rate policy.
Integration If you are using the Accounts Receivable (FI-AR) component to manage your accounting and an external system for sales processing, Credit Management enables you to issue a credit limit for each customer. Every time you post an invoice (created in FI-AR), the system then checks whether the invoice amount exceeds the credit limit. Information functions such as the sales summary or early warning list help you to monitor the customer’s credit situation.
50 If you are using both the Accounts Receivable (FI-AR) component to manage your accounting and the Sales and Distribution (SD) component for sales processing, you can also use Credit Management to issue credit limits for your customers. You can make settings in Customizing to decide the scope of the check and at what stage in the process (for example, order entry, delivery or goods issue) a credit limit should take place. General information functions are also available for use with credit checks.
Features If you are using both the SD and FI-AR components, Credit Management includes the following features: •
• • • •
Depending on your credit management needs, you can specify your own automatic credit checks based on a variety of criteria. You can also specify at which critical points in the sales and distribution cycle (for example, order entry, delivery, goods issue) the system carries out these checks. During order processing, the credit representative automatically receives information about a customer’s critical credit situation. Critical credit situations can also be automatically communicated to credit management personnel through internal electronic mail. Your credit representatives are in a position to review the credit situation of a customer quickly and accurately and, according to your credit policy, decide whether or not to extend credit. You can also work with Credit Management in distributed systems; for example if you were using centralized Financial Accounting and decentralized SD on several sales computers.
You can find information about where to make Customizing settings for Credit and Risk Management in Settings for Credit and Risk Management
Risk Management for Receivables See Risk Management for Receivables in SD for information about managing risks for receivables.
Settings for Credit Management and Risk Management: Overview The table below lists the most important settings that you make in Customizing for Credit Management. The relevant Implementation Guide (IMG) provides a detailed description of the individual activities. Access via
Menu path
51
Settings for Creating credit data
Accounting application
Accounting → Financial accounting → Accounts receivable → Credit management → Master data → Change
Enterprise Structure Customizing
Enterprise Structure → Structure maintenance → Definition → Financial
(Determine credit limit for customer) Credit control area
Credit control area
Accounting → Maintain
Credit Control
Area Company code - Credit control area
Enterprise Structure Customizing
Enterprise Structure → Structure maintenance → Assignment → Financial Accounting → Assign
and Financial Accounting Customizing
Company Code to Credit Control Area and Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Assign
Permitted Control Areas to Company Code Company code - Credit control area
Enterprise Structure Customizing
Enterprise Structure → Structure maintenance → Assignment → Sales and Distribution → Assign
Sales Organization to Company Code Subdividing the credit control area
Credit representative groups
Financial Accounting Customizing
Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Define
Credit Representative Groups Credit representative
Financial Accounting Customizing
Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Define
Credit Representative Groups Risk category
Financial Accounting Customizing
Financial Accounting → Accounts Receivable and Accounts Payable → Credit Management
→ Credit Control Account → Define
Risk
Categories Sending a document with SAPoffice
Defining credit limit
Automatic credit control
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Credit Management/Risk Management Settings → Enter settings
Sales and Distribution
Sales and Distribution → Basic Functions →
52
checks for sales and distribution processing
Customizing
Credit Management/Risk Management → Credit Management → Define
Automatic Credit Control Risk management for receivables
Define form of payment guarantee
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Receivables risk management → Define
Forms of Payment Guarantee Define and assign payment guarantee procedures
Sales and Distribution Customizing
Sales and Distribution → Basic Functions → Credit Management/Risk Management → Receivables risk management → Define
Forms of Payment Guarantee
Material Determination Use Material determination enables the automatic substitution of materials in sales documents during sales order processing. For example, during the course of a sales promotion, the system can, during sales order entry, automatically substitute a material that has promotional packaging. A consumer product may have a special wrapper for, for example, the Christmas season. Using material determination, the system substitutes the material only during the specified period. The following graphic illustrates the determination of a promotional product in the sales order.
In addition, you can use material determination if you want the system to automatically substitute, for example: •
customer-specific product numbers with your own material numbers
•
International Article Numbers (EANs) with your own material numbers
•
Substituting discontinued materials with newer materials
Output Determination (SD-BF-OC) Purpose The Output Determination component offers output functions for sales, shipping, transportation, and billing to help you manage sales transactions with your customers and within your company.
53 You can create sales activity output (for example, customer telephone calls, mailing campaigns) and group output (for example, freight lists). Your company employees can send and receive output. Output is directly linked to the corresponding sales transaction (for example, the system automatically sends an order confirmation via Electronic Data Interchange (EDI) as soon as the employee creates an order).
Integration The output determination component is used for output control. Output control is used to exchange information with internal and external partners. Output control includes the following functions, described in the cross-application (CA) - Output Control documentation: •
Output Determination
•
Output Processing
Features The system can automatically propose output for a sales and distribution document. You can change this output in the sales and distribution document. The system uses the condition technique to determine output. For more information on the condition technique, see Conditions and Pricing. See also: For further information on output, refer to the following documentation: Application
Documentation
Basis-Services
SAP Internet Mail Gateway SAP Communication: Configuration (BC-SRV)
Cross-Application Components
CA – Output Control BC - SAP Business Workflow SD – Sales and Distribution: WorkflowScenarios
For information on Customizing settings and examples, refer to Output Control Customizing in Sales and Distribution (SD) in the CA - Output Control documentation.
Texts in Sales and Distribution Purpose
54 In a business relationship, it is essential that business partners exchange information throughout the logistics chain. In sales and distribution, this exchange of information is supported by texts in master records and documents. You can maintain these texts for one particular customer or define them so that they can be used more flexibly. Texts can be used in many areas of sales and distribution: •
Sales notes for customers
•
Sales texts for materials
•
Explanations in order confirmations
•
Shipping instructions in deliveries
You can define as many text types as you require (sales texts, shipping texts, internal notes, supplement texts etc.) for master records and documents. You can take the settings for the texts from Sales and Distribution Customizing under Text control.
Features You store the texts that are to serve as information carriers in the system and in the output in the customer master record, the material master record, and in the sales and distribution documents. In addition the following processing and control functions are supported: •
Texts are proposed from the master records in the sales and distribution documents, if you have made the appropriate setting.
•
Texts can be copied from a reference sales and distribution document into another sales and distribution document (e.g. from an inquiry into a sales order or from an order into a delivery).
•
The copying of texts can be made language dependent, if required.
•
You can change copied texts.
•
You can integrate standard texts into the sales and distribution documents.
Creating Tax Records Steps: To create a tax condition record:
1. Choose Logistics → Sales/distribution → Master data. You reach the Sales Master Data screen.
55 2. Choose Pricing → Taxes → Create. You reach the data Select Countries for Maintaining Tax Conditions screen.
3. Position the cursor on the country for which you want to maintain a tax record and choose Tax records. 4. Enter the relevant data. 5. To save the tax record, choose Save.
Account Determination Use To be able to use revenue recognition, you should select several special general ledger accounts. Choose: Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Recognition
Determining the Revenue Account Revenue recognition uses revenue account determination. To set up revenue account determination, use transaction VKOA.
Determining Non-Billed Receivables Accounts The account for non-billed receivables is a special general ledger account, used to determine revenue which has been implemented but not yet billed. If you want to set up an account, join an account with non-billed receivables together with a customer reconciliation account which is a part of your chart of accounts. You can use the transaction OVUR for this. The standard system has the balance sheet account 142100 for non-billed receivables in the USA and in Canada (Accruals and Deferred Income).
Determining the Deferred Revenue Account The deferred revenue account is a special general ledger account, used to determine revenue which has been billed but not yet implemented. The system determines the deferred revenue account for a document item using standard SD account determination. Use the transaction VKOA for this.
You must enter the deferred revenue account number in the second column.
56
Output Determination (SD-BF-OC) Purpose The Output Determination component offers output functions for sales, shipping, transportation, and billing to help you manage sales transactions with your customers and within your company. You can create sales activity output (for example, customer telephone calls, mailing campaigns) and group output (for example, freight lists). Your company employees can send and receive output. Output is directly linked to the corresponding sales transaction (for example, the system automatically sends an order confirmation via Electronic Data Interchange (EDI) as soon as the employee creates an order).
Integration The output determination component is used for output control. Output control is used to exchange information with internal and external partners. Output control includes the following functions, described in the cross-application (CA) - Output Control documentation: •
Output Determination
•
Output Processing
Features The system can automatically propose output for a sales and distribution document. You can change this output in the sales and distribution document. The system uses the condition technique to determine output. For more information on the condition technique, see Conditions and Pricing. See also: For further information on output, refer to the following documentation: Application
Documentation
Basis-Services
SAP Internet Mail Gateway SAP Communication: Configuration (BC-SRV)
Cross-Application Components
CA – Output Control BC - SAP Business Workflow SD – Sales and Distribution: WorkflowScenarios
For information on Customizing settings and examples, refer to Output Control Customizing in Sales and Distribution (SD) in the CA - Output Control documentation.
57
Message Determination Use During message determination, the condition tables are searched for condition records according to the rules defined in Customizing (defining condition components) which correspond to the current application data. The current application data is transferred to Message Control from the application in the Communication Structure . In addition, the application also transfers the relevant Application Code and a Procedure as the highest condition components in the hierarchy. When the system finds a message, the following scenario occurs: • •
If the application provides functions for manual editing of messages, the message found is proposed to the user. The user can edit the message manually and make any changes required. The message (which may have been edited) is saved and is then immediately or later transferred to the processing program.
Prerequisites The Condition Components and Condition Records must be defined.
Features Message Determination: Processing Condition Component Hierarchies Condition Table Access
Activities For each object (document), if you want to...
You should read the section entitled...
send not more than one message to each partner
Strategy:"Exclusive Access Sequence"
send several messages to a partner in various functions or languages
Strategy:"Inclusive Access Sequence"
send several messages to a partner in the same function and language
Strategy Procedure
Condition Components and Condition Records Definition The tool that Message Control uses for message determination is well known in other applications (for example price determination and account determination in SD): condition technique. The condition technique uses condition components that determine with which method and with which application data the message is searched for. The following two diagrams show the hierarchy for the condition components.
58 Condition Components: Sample Hierarchy Condition Components: General Hierarchy
Structure The individual condition elements are: Application Code Field Catalog for Condition Keys Procedure Output Type Access Sequence Condition Table Condition Access
Message Determination: Processing Condition Component Hierarchies If a business application transfers a procedure for message determination to Message Control, all output types in the procedure are searched. The following diagram shows the output types Order confirmation and Internal mail in the procedure Order.
59
During message determination for an output type, the access sequence is processed, that is, all condition tables in this access sequence are accessed sequentially. In the above example, there are two condition tables (001 and 002) for the access sequence 0001 and therefore for the message Order confirmation. The order confirmation access sequence refers successively to the tables listed below with the corresponding keys: Table
Key
Indic. "Exclusive"
Condition table 001
Sales organization customer number
According to strategy: Set or not set
Condition table 002
Sales organization
No difference in example
Condition table 001 therefore contains more specific conditions (sales organization / customer number) than condition table 002 (only sales organization) for the sending of an order confirmation. In the case of an exclusive exit strategy for table 001, table 002 is no longer accessed when a condition from table 001 has been met. As there is not a third table behind table 002 in the access sequence, it makes no difference in this example if the exit strategy for this table is inclusive or exclusive. You can assign the following condition components with conditions written in ABAP:
60 •
Output type The value of the system return code at the end of the condition determines whether the condition table of this output type is accessed. If the result is negative (Return code <> 0), processing in the procedure continues, that is to say, the next output type in the procedure is processed.
•
Condition Table Access If the system return code is <> 0 at the end of the condition, processing of the access sequence continues.
Message Determination: Condition Table Access Order confirmations are searched for in the following diagram: 1. Message determination begins in the procedure V1000 with the output type BA00 and the assigned access sequence 0001. 2. In the access sequence the key of the condition table 001 is determined with the sales organization 0001 and the sold-to party "company 1". The condition table is read with this key. 3. If a condition record is found, the system proposes a message default with the attributes found in table NACH. 4. The message default (which may have been edited manually) is stored after document posting as a record in table NAST. The message is given a unique number for identification purposes. Condition access example
61
Message Processing Use For output (for example EDI dispatch) the message found is processed. This involves, for example, formatting (for printing). The current status of message processing can be seen in message status. Processing time can be used to set when message processing should be triggered.
Features The Message Status Record (table NAST) contains information about when to start processing programs and which parameters are used. When the processing program has been called, a processing status is written. You can therefore obtain an overview of the processing status of the messages (or conditions) valid for this object on the basis of an application object. Subsequent Processing Interface to Processing Programs Processing Log Formatting SAP script Messages Formatting mails
62
Message Control scenario: Processing
A particular customer’s credit limit being exceeded should cause the account history to be printed out. In this case, the processing program is the print formatting and output. A release message for a document is implemented in a processing program as a call to Business Communication Interface.
The following diagram shows the various processing options:
Entering Electronic Mails Manually in SD Documents 1. Choose Extras → Output → Header or Item in the document you are currently processing.
2. Enter the following data: – Mail in the Output type field – Output medium 7 in the Output medium field
63 – MP in the PartFunct. field – the user name of the mail recipient in the Partner field – the language in which the mail should be sent in the Language field
3. Choose Further data to enter the timing data for the electronic mail. 4. Choose Communication method to maintain the communication data for the electronic mail: - Mark either the Functional or Standard field (for mail that is not confidential) or the Confidential field. - Enter the transaction code with which the recipient can process the sales order. For example, enter VA02 to change a sales order or VA03 to display a sales order. - If you want to write a text to go along with the mail, choose Edit → Editor to reach the SAPscript Editor.
5. Choose Back to return to the output screen. The system sends the electronic mail at the time you have specified in the timing data.
How Sales Documents are Structured 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. The following graphic shows the structure of a sales document:
Header data
64 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
How Sales Documents are Controlled
65 During Customizing for Sales and Distribution, your system administrator defines various types of data for controlling the processing of sales documents. Data is defined on three different levels: •
According to sales document type
•
According to item category
•
According to schedule line category
At sales document level, for example, you can specify whether a credit check takes place for a particular type of document. In addition, you can specify whether a certain document type is automatically blocked and must first be reviewed before it can be processed further (a request for a credit memo, for example). At item category level, you can specify, for example, whether an item category is relevant for delivery or billing. The item categories used in a quotation, for example, would not be relevant for delivery or billing. Finally, schedule line categories can be defined according to how you want MRP requirements and the availability check to be carried out.
Sales Document Types The standard version of the SAP System includes a variety of pre-defined sales document types. During the implementation of your system, these standard definitions may be modified to suit the particular needs of your organization. In addition, you may add your own sales document types. The sales document types in the standard system include the following: Type of processing
Sales document type
Abbreviation
Presales
Inquiry
IN
Quotation
QT
Free-of-charge delivery
FD
Standard sales order
OR
Cash sale
BV
Rush order
SO
Quantity contract
CQ
Maintenance contract
WV
Rental contract
MV
Scheduling agreement
DS
Credit memo request
CR
Debit memo request
DR
Subsequent delivery, free-of-charge
SD
Returns
RE
Sales orders
Outline agreements
Complaints
66
Control Elements in Sales Document Types You can use control elements, configured in Customizing for Sales and Distribution, to define each sales document type in such a way that it is provided with its own range of functions. The document types can be tailored to meet the requirements of your company. You can modify the existing document types or you can create your own if those specified in the standard version of the SAP System do not meet the needs of your sales organization. Your system administrator is responsible for maintaining control elements. Your answers to the following questions help to decide how to define a particular sales document type: General data •
Can the document be entered only with reference to a preceding document?
•
Should the existing customer-material info record be taken into consideration?
•
Should the delivery date be proposed?
•
Must a customer number be entered when creating a document? For example, assortment modules can be entered without reference to a particular customer.
•
Which order probability is defined?
•
Should the division be taken from the material master record for every item or should an alternative division specified in the header take precedence over the item specifications?
1.
• How should the system respond if the division entered in the header deviates from the division in the items? •
Should a credit limit check be made?
•
From which number range should the document number for internal or external number assignment come?
•
Which fields are relevant for the incompletion log? The validity period, for example, is important for contracts and must therefore be specified in the document.
•
Can an incomplete document be saved or must all data be complete?
•
Which partner functions are allowed and which ones are mandatory?
Shipping data •
Which delivery type should the delivery resulting from the order have?
•
Should delivery schedulingbe carried out?
•
Should transportation scheduling be carried out?
•
Should a delivery block be set automatically for a specific reason? For example, a delivery block may be appropriate for a free-of-charge delivery.
•
You can define shipping conditions for a sales document type. These are copied into the document regardless of what is defined in the customer master record.
Billing data •
Which billing type should the invoice resulting from the order or the delivery have?
•
Should a billing block be set automatically for a specific reason? For example, a billing block may be appropriate if a credit memo request should first be checked before it is used as the basis for a credit memo.
67
Item Categories Item categories are defined to provide additional control functions for the sales documents and thus meet the demands resulting from different business transactions. A separate control is defined for each of these item categories. For example, the functions of a standard item are completely different from those of a free-of-charge item or a text item. The following graphic shows some of the item categories which are defined in the standard system. For instance, the first example displays the item categories for a standard item in the inquiry, in the quotation, and in the sales order.
Item Category Control The system uses an item category to process a material differently in each sales document type. For example, you can define a different control for a material in an inquiry and a material in an order. The following graphic shows an example of how a material is controlled in an inquiry and how it is controlled in an order.
68
In the inquiry, the standard item is priced but is not relevant for delivery. For the free-of-charge item, however, which is subordinate to the standard item, no pricing is carried out and it is not relevant for delivery. In the sales order, the situation is different. Both items are relevant for delivery but pricing is carried out only for the standard item.
Control Elements in Item Categories Depending on the sales document type, different item categories are allowed. The item categories can also be adapted using control elements to meet the special requirements of your installation. You can modify the existing item categories or you can create your own. Your system administrator is responsible for maintaining the control elements. The answers to the following questions form the basis for deciding how to define a particular item category:
General data •
Should pricing be carried out for the item?
•
When should an item be regarded as completed? A quotation item, for example, can only be regarded as completed if the entire quantity has been copied into a sales order.
•
Does the item refer to a material or is it a text item?
•
Are schedule lines allowed for the item?
69 •
May general business data, for example, the terms of payment at item level, deviate from those at header level?
•
Should a system message appear if the item cannot be fully delivered?
•
Which fields are relevant for the incompletion log?
•
Which partner functions are allowed at the item level and which are mandatory?
•
Which output (for example, an order confirmation) is allowed for the business transaction and which output determination procedure is used?
Shipping data •
Is the item relevant for delivery?
•
Should the weight and the volume of an item be determined?
Billing data •
Is an item relevant for billing?
•
Should the cost of the item be determined?
•
Is it a statistical item? The system prices statistical items, but they are not added to the value of the order. In other words, the customer is not charged for them.
•
Should a billing block be set automatically for an item? For example, this may be important for items whose prices have to be clarified before billing.
•
Is it a returns item?
Determining the Item Category The item category in the sales document depends on the sales document type and the material. An item category group is defined in the material master record. For example, in the standard SAP System, the item category group NORM is defined for materials kept in stock and the group DIEN for services and non-stock material. The following graphic shows how the system determines the item category. For a material with item category group NORM, the system determines the item category AFN for an inquiry (sales document type IN) and the item category TAN for a standard order (sales document type OR).
70
Determining the Item Category for Sub-Items Services and free goods can be entered as separate items or can be allocated to other items. An item which is allocated to another one is called a sub-item. Determining the item category for subitems depends on the higher-level item. If a free goods item is allocated to a standard item in a standard order (item category TAN), the item category TANN is used for the sub-item in the standard version of the SAP System, and the sub-item is processed as a free-of-charge item.
Schedule Line Categories The items in a sales document are divided into one or more schedule lines. These schedule lines differ from each other with respect to date and quantity. Different control elements are also defined for the schedule lines. For example, for some schedule lines, material requirements planning is not carried out; for other schedule lines, it is carried out. Also goods receipt, not goods issue, is posted for a schedule line defined in a returns document. The following graphic provides an overview of some of the item categories which are defined in the standard system.
71
Schedule Line Category Control The various schedule line categories are controlled in different ways: •
The schedule line AT in inquiries is used only for information.
•
No requirements are transferred and no availability check is carried out for the schedule lines BN and CN.
•
Requirements are transferred and the availability of the material is checked for the schedule lines BP and CP.
•
No stocks are managed for the schedule line categories BT, CT and CX. No goods issue is posted for the categories BT and CT. However, goods issue is posted for CX.
•
The schedule line categories BV and CV are controlled in the same manner as the categories BN and CN. However, requirements can be passed on for analysis purposes.
•
Goods receipt is posted for the schedule line DN in a returns document.
•
The schedule line categories CN, CP, CT, and CV are relevant for delivery; the other schedule line categories are not.
Control Elements for Schedule Line Categories Different schedule line categories are permitted according to the sales document type and item category you are using. You can use control elements to tailor the schedule line categories to
72 meet the special demands of your installation. You can also define new schedule line categories. Your system administrator is responsible for maintaining the control elements. The answers to the following questions form the basis for deciding how to define a particular schedule line category:
General data •
Which fields are relevant for the incompletion log?
•
Should a customer requirement be reported to purchasing or production?
•
Should an availability check be carried out?
•
Is it a schedule line for a returns document?
Shipping data •
Is the schedule line relevant for delivery?
•
Should a delivery block be set automatically for the schedule line? A delivery block is appropriate for free of charge deliveries.
Determining the Schedule Line Category The schedule line category depends on the item category of the corresponding item and the material requirements planning type (MRP) of the material. The MRP type of a material is specified in the material master record. Schedule line categories are proposed automatically based on values set in the appropriate table. You can make some manual changes to the entries in the sales document but you cannot change everything. When you enter another schedule line category, the system checks whether this category is allowed. For information on which schedule line categories are allowed in each case, see your system administrator.
Customer Inquiry/Quotation Purpose You can represent pre-sales business processes in the system using the functions for inquiries and quotations. Customer inquiries and quotations to the customer can be entered and monitored. For example, a customer inquires whether you have a certain product in your warehouse, how much it will cost, or whether the product will be available for a certain date. The inquiry is therefore a request from the customer for you to provide him with a sales quotation. A quotation presents the customer with a legally binding offer for delivering a product or providing a service within certain fixed conditions. The data you store in sales queries forms the basis of subsequent documents and, if you wish, sales analysis.
73 Creating and maintaining this kind of data may be useful under, for example, the following circumstances: •
You want to evaluate your pre-sales processing with reports and analysis. For example, you want to compare the value of a quotation against the value of subsequent sales orders and invoices and then evaluate the effectiveness of your planning process. Or you want to evaluate the success rate of quotation-to-order conversion by salesman or sales group.
•
Your sales organization deals with government agencies or large organizations and institutions who routinely send out for bids and requests for proposal. You want to record the entire sales cycle.
•
Your sales organization sells a wide range or low value products (for example, consumer products with a high turnover) but you wish to fix certain data for the presales phase if you are negotiating for larger contracts.
A company sends out quotations for equipping intensive care rooms in hospitals. The equipment can vary, depending on the hospital and other factors, but 40% of the components are standard. The company's sales staff copy the standard components into quotations from master data, along with standard texts (standard clauses, for example). Whenever possible, the staff copies the remaining components from existing quotations that resulted from similar queries. Alternatively, the staff can copy data from product proposals.
Implementation Considerations Before you can use sales queries, you must maintain the following: •
Master data for order probability by customer and document type
•
Relevant sales query document types
•
Copying requirements for document flow
•
Master data for alternative items (material determination)
You maintain document types and copying requirements in Customizing for Sales and Distribution. For more information about these functions, see the online Implementation Guide.
Features Sales queries let you enter and store all the important, sales-related information you use during sales order processing. Queries that are not complex can be entered quickly in the initial entry screen. The query can be entered from scratch or can be copied. For example, when the customer decides he wants a firm quote, you can copy a previously entered inquiry directly into a quotation. The inquiries and quotations entered in the system can be displayed and evaluated in a list. You can use selection criteria to limit the list which will give you a more selective display and processing. For analysis purposes, you can list all the quotations you processed during the last six months and examine those that were rejected and for what reasons. You can maintain a validity date in sales queries by which time the query should have been answered. The documents can then be monitored and evaluated according to this validity date,
74 which then allows you to evaluates the queries on time. In this way you are able to plan and implement the necessary subsequent activities according to the deadline. Instead of a material number you can also enter a text description of the material if, for example you can’t assign the materials to a customer call straight away. In one quotation for a material, you can offer the customer several options with differing pricing conditions and shipping times. If the quotation leads to a sales order, you can select an alternative item according to the customer’s requirements.
Cash Sales Implementation Considerations Cash sales is an order type for when the customer orders, picks up and pays for the goods immediately. The delivery is processed as soon as the order has been entered. A cash invoice can be printed immediately from the order and billing is related to the order. Receivables do not occur for the customer as they do for rush or standard orders, because the invoice amount is posted directly to a cash account.
Process Flow In the standard system, sales document type BV is saved for cash sales with immediate delivery type BV. When the sales employee creates a cash sale, the system automatically proposes the current date as the date for delivery and billing. Once the order has been posted, a delivery with type BV is created immediately in the background and the system prints a document that is used as an invoice for the customer. The invoice papers are controlled with output type RD03, contained in the output determination procedure for order type BV. If the customer has already received the goods, this delivery should not be relevant for picking. If the customer is to pick the goods up from a warehouse, the delivery should be relevant for picking. If the goods are to be sent, this can be processed by maintaining the delivery in the usual way. The system automatically creates a resource-related billing index which updates the billing due list. Billing document BV is created as the system processes the billing due list, but an invoice is not printed.
75
Once the customer has received the goods and is satisfied with them, the transaction is considered to be complete. We recommend that you post goods issue in the background using a program designed specifically for this purpose. You can then bill the transaction.
The cash sale can only be billed if the order quantity is the same as the goods issue quantity. If this is not the case, you need to adjust the cash sale document so that the delivered quantity and the quantity to be billed match. You use an order-related collective billing process to bill the cash sale, but an invoice is not printed. The sales order number is used as the reference for the accounting document, created in Financial Accounting.
Dealing with Problems and Complaints If the transaction does not run smoothly, manual intervention is necessary. For example, if the required quantity of goods is not found in the warehouse, you need to adjust the delivery quantity. Equally, if the customer is not prepared to pay the agreed price, because, for example, the goods are scratched, you can change the price in the cash sale document.
76 In extreme cases, you can delete the entire transaction, starting with the delivery. If the delivery is damaged before it is picked up but after it is paid for and there is no replacement stock, you can initiate a subsequent delivery. If you make changes to the cash sale, you can issue a new cash sale invoice using the repeat printout function.
Rush Order Implementation Considerations In a rush order transaction, the customer picks up the goods or you deliver the goods on the same day as the order is placed. In the standard system, when you save this sales document type, a delivery is automatically created and billing is related to the delivery.
Process Flow In the standard system, sales document type SO is saved for rush orders with immediate delivery type LF. Once the goods have been removed from storage, the goods are picked, and goods issue is posted. Once the billing documents are created (for example, in collective processing), invoice papers are printed and sent to the customer.
77
Complaints Implementation Considerations The following processes are available in complaints processing: •
Free-of-Charge Deliveries Although these are not complaints, they are offered as part of this component. A free-ofcharge delivery is used to send a customer a free sample of your products.
•
Free-of-Charge Subsequent Deliveries If the customer complains (for example, that they received the wrong quantity) you can send them the extra material later free of charge. This free-of-charge subsequent delivery always refers to a sales order.
•
Returns 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
•
Credit Memo Requests If the customer complains that the price was miscalculated (for example, too high) you request a credit memo for the appropriate sum, and you do not take the goods back.
•
Debit Memo Requests If prices were calculated as too low, you request a debit memo.
•
Invoice Correction Requests The invoice correction request works in the same way as credit and debit memo requests, but here you enter the price or quantity that should have been calculated. The system then calculates the difference and creates either a debit or a credit memo, depending on whether the difference is negative or positive.
Implementation Considerations You need this component for processing complaints, or for sending free samples or products to your customers.
Features All complaints can be approved or rejected. Once a complaint has been approved, you create either a credit or debit memo, depending on the type of complaint. If you reject a complaint, you can specify a reason for the rejection and this can be used as selection criteria for listing complaints.
78
Free-of-Charge Delivery Definition A sales document for delivering goods to a customer free of charge.
Use You can create free of charge deliveries for sending samples of your products to the customer. The system will then generate a delivery based on the free-of-charge delivery.
Structure A free-of-charge delivery is a type of sales document just like the standard order. For more information on sales documents, see Working With Sales Documents
Integration A free of charge delivery triggers a delivery.
Free-of-Charge Subsequent Delivery Definition A sales document used in complaints processing for making a subsequent delivery of goods to the customer, free of charge.
Use You can create a free-of-charge subsequent delivery if, for example, a customer receives too few goods, or if the goods have been damaged in the shipment. The system uses the free-of-charge subsequent delivery to create a delivery.
Structure A free-of-charge subsequent delivery is a sales document, like a standard order. For more information on sales documents, see Working With Sales Documents
Integration A free-of-charge subsequent delivery triggers the system to create a delivery.
Returns Definition
79 A return is a sales document used in complaints processing for when a customer sends goods back.
Use You enter a return in the system if the customer returns damaged goods, or goods that had been delivered for sale on approval. The return causes the system to: • •
Register the receipt of goods using a returns delivery, and post the goods to stock (for example, blocked stock). Create a credit memo, once you have checked the goods and approved the complaint.
Structure A return is another type of sales document like a standard order. For more information on sales documents, see Working With Sales Documents
Integration The return triggers the following functions: • •
Delivery (returns delivery) Billing (for creating a credit memo)
Credit Memo Request Definition A credit memo request is a sales document used in complaints processing to request credit for a customer.
Use If the price calculated for the customer was too high (for example, with the wrong scaled prices or because a discount was forgotten), you can create a credit memo request. The credit memo request can be automatically blocked for checking. Once it has been approved, you can remove the block. The system uses the credit memo request to create a credit memo.
Structure A credit memo request is another type of sales document like a standard order. For more information on sales documents, see Working with Sales Documents. A credit memo request starts the billing process.
Debit Memo Request
80
Definition A debit memo request is a sales document used in complaints processing to request debit for a customer.
Use You can create a debit memo request if the prices calculated for the customer were too low (for example, if the wrong scale prices were calculated). The debit memo request can be automatically blocked for checking. Once it has been approved, you can remove the block. The system uses the debit memo request to create a debit memo.
Structure A debit memo request is another type of sales document like a standard order. For more info rmation on sales documents, see Working With Documents.
Integration A debit memo request starts the billing process.
Invoice Correction Requests Definition A sales document used in complaints processing to correct the quantity or price of one or more items in an invoice.
The invoice correction request is the same as the differential credit memo in the SAP R/2 System.
Use You can create an invoice correction request if the wrong prices have been calculated for the customer. The invoice correction request can be automatically blocked by the system until it has been checked. The system calculates the difference between the amount that was originally calculated and the corrected amount for each item. Once it has been approved, you can remove the block. The system creates a credit memo with reference to the invoice correction request. If the remaining amount is positive, the total value does not have a + sign, if the remaining amount is negative, the total value has a – sign.
Structure
81 An invoice correction request is a type of sales order, like the standard order. For more information on sales documents, see Working With Sales Documents. An invoice correction request has the following structure: •
Header This contains the data that is relevant for the whole invoice correction request, such as sold-to party and payer, and the total value of the invoice correction request.
•
Item pairs Two items are automatically created for each item from the invoice, to be copied for the invoice correction request: o o
First: Credit item Second: Debit item
These contain the same value and quantity. In the credit item, the system credits the customer with the full value. If you change the debit item (for example, due to new pricing or a change in quantities), this results in a difference amount. In most cases, an invoice correction request is created with the aim that a credit memo is generated. In the standard system, the invoice correction request is therefore characterized as a credit memo request, which means that the system creates a credit memo based on the invoice correction request. In Customizing, you can change this, so that the invoice correction request is characterized as a debit memo request. In this case, the system creates a debit memo, based on the invoice correction request. You can change these settings in Customizing under Sales → S ales Documents → Sales document header → Define sales document types in the Sales document categ. field. Regardless of whether the invoice correction request is a credit or debit memo, the first item is always a credit item and the second is a debit item. If you want the system to generate a credit memo for a positive remaining amount, and a debit memo for a negative remaining amount, you need to set an additional sales document type in Customizing, for example, ZRK1 (invoice correction request for debit memos). This sales document should be characterized as a "debit memo request". In addition, you make the setting that this sales document type should be billed with a debit memo (for example, with the billing type L2 ). Before you create an invoice correction request, you need to consider from the very start what it should be generated for. If the aim is a credit memo, you use the sales document type RK for the invoice correction request, if the aim is a debit memo, you use the sales document type ZRK1 . You can find further information about setting up a new sales document type in the implementation guide (IMG) under Sales and Distribution → Sales → Sales Documents. You can find further information about setting up a billing type with which this sales document type should be billed in the IMG under Sales and Distribution → Billing → Billing Documents → Maintain Copying Cotrol for Billing Documents, Activity: Copying Control: Sales document to billing document.
82
Integration You create invoice correction requests with reference to an invoice.
Web Shop Use You use Web shops in ERP E-Commerce to sell your products via the Internet. You can maintain Web shops for your Business-to-Business (B2B) and Business-to-Consumer (B2C) scenarios. You define the content for your Web shop, that is, the products you wish to sell, in the ERP product catalog or an external catalog. You maintain the shop itself, for example which transactions, functions, and product catalog you wish to offer, in the Webbased Shop Management application. Once you have maintained a catalog and a Web shop you can sell your products via the Internet.
Prerequisites You have created a Web shop in the Shop Management application. For more information, see the Shop Management configuration documentation in SAP Solution Manager.
Features You can create and maintain your Web shops in the Shop Management application. You can do the following: •
Create a new Web shop
•
Copy the data of an existing Web shop
•
Search for a Web shop
•
Change, delete a Web shop
You can define various settings for your Web shop in the Shop Management application which will result in the view your customers and business partners see. The settings are grouped into three main areas: 1. •
General Information
Contains, for example, settings for language of Web shop, address format, and shop scenario. 2. •
Product Catalog
Contains, for example, settings the catalog variant and catalog price determination. 3. •
Transactions
Contains, for example, settings for the transaction types enabled in the web shop, and the sales organizational data. If you choose the Web shop scenarios for Internal Users (ERP E-Commerce) or Business-on-Behalf (Channel Management) in the General Information section, the system displays a fourth settings area in the Shop Management application, called Customers, which contains particular settings for these scenarios.
Backorder Processing
83 Using backorder processing, you can list sales documents relevant for requirements for particular materials and confirm them manually. You can assign available-to-promise (ATP) stock to outstanding order quantities. In addition, you can withdraw already confirmed quantities and reassign them to different items.
Backorder processing is only available for materials with individual requirements. Summarized requirements are usually used for materials sold in bulk quantities. Backorders for bulk products are not, as a rule, processed manually. The following display and processing functions are available for backorder processing: • •
Selecting Backordered Materials From a List Selecting Single Materials for Backorder Processing
See also: Availability Check in Sales and Distribution Processing
Selecting Backordered Materials From a List The selection list enables you to display information about the requirements for the selected materials. You can then select and process individual sales documents directly from the list.
Creating a List of Sales Documents for Backorder Processing To process backorders with a selection list, proceed as follows:
1. In the initial screen, choose Logistics → Sales and distribution → Sales. 2. Choose Environment → Backorders → Backorder processing → SD documents. 3. Enter you selection criteria (for example, the plant, sold-to party, purchase order number) and choose Program → Execute. The system displays a list of the materials that meet your selection criteria. For each material, you the list provides the relevant information for each corresponding sales document (for example, the first delivery date, order quantity, confirmed quantity, and open quantity). You can branch directly from the selection list into the individual sales documents. In addition, you can display the status, the document flow, and any changes made to the document. Select the documents that you want to process and select from the following options: • • • •
Environment → Environment → Environment → Environment →
Document to branch to an individual sales document Document status to display the document status Document flow to display the document flow Document changes to see the changes
Processing Backorders for Sales Documents
84 Backorder processing from the selection list always takes place by material. This means that if you select several materials in the list, the system processes each one in turn. If you want to reschedule in order to update the sales documents before you process the backorders, note that this may adversely affect system performance. Whenever possible, carry out rescheduling in the background. To process backorders with a selection list, proceed as follows:
1. Select the materials and sales documents in the selection list that you want to process and choose Edit → Backorders. This overview displays the requirements and received quantities, the quantity confirmed until now and the cumlated ATP (available-to-promise) quantity (the required and received quantities in stock still available for use) for each selected material, requirements/received date and MRP (materials requirements planning) element (such as the sales order). The requirements date generated by the sales document matches the material availability date.
2. Place your cursor on the MRP element that you wish to process and choose Edit → Change confirmation.
Note that you can only process the MRP elements for the lines that you selected in the list for which confirmed quantities exist. The MRP elements that you can process are highlighted. Deliveries cannot be processed as backorders so the overview does not contain any confirmed quantities for them. However, the system does take the size of the delivery quantities into account when calculating the ATP quantity. You reach the Backorder Processing: Change Confirmation screen where you can see the details of the MRP element you selected (in the Sales requirements section for sales documents). In addition to the order and item numbers and the material availability date, the following data is displayed for a sales order item: Field
Description
Open quantity
Quantity not yet delivered
Confirmed quantity
Quantity that has been confirmed in backorder processing
Total confirmed quantity
Total quantity confirmed for the sales order items (if there is more than one schedule line for the item, this is the total of all confirmed schedule lines)
ATP quantity
Quantity available for outwards goods movements
In the Sales requirements section, you can process the backorders in one of the following ways: • •
Distributing ATP Quantities Redistributing Confirmed Order Quantities
Choose Display to branch directly to the sales document.
85 Additional Functions The overview screen for requirements processing contains the following additional functions: Variable Views Scope of Check Exception Messages MRP Elements
Distributing ATP Quantities To distribute ATP quantities, proceed as follows:
1. In the Backorder Processing: Change Committed Quantity screen, you can distribute
2. 3. 4.
some or all of the ATP quantity by entering a quantity in the Committed field in the Sales requirements section of the screen. This quantity fulfills some or all of the requirements for the backordered item. Choose Enter to display the updated requirements situation. Choose Copy to confirm the data. Choosing Backorder processing → Save. If you selected more than one material in the selection list, the system automatically displays the next material you selected.
Example of Distributing ATP Quantities 140 pieces have been confirmed already for sales orders 14940, 14942 and 14981 in the unrestricted use stock. A backorder of 5 pieces exists for sales order 14943. Only 15 of the original order quantity of 20 pieces could be confirmed so the cumulative ATP quantity stands at 5. The backordered quantity of 5 pieces can be fulfilled from the (in this case identical) ATP quantity. You do this by entering 20 pieces to replace the original 15 in the Committed field and choosing Copy. The cumulative ATP quantity is now used up and stands at zero. Sales order 14943 is fully confirmed.
Redistributing Already Confirmed Order Quantities You can take back some or all of an already confirmed order quantity and reassign the quantity to a backordered item that has higher priority. To redistribute an already confirmed quantity in this way, proceed as follows:
1. In the Backorder Processing: Change Committed Quantity screen, reduce the quantity in the Committed field (in the Sales requirements section of the screen) by the amount that you want to assign to other backordered items. 2. Choose Enter to display the updated requirements situation. 3. Choose Copy to confirm the data. 4. Assign the freed up quantity to the appropriate backordered items using the procedure described above for distributing ATP quantities.
86
Variable Views for Backorder Processing You can select different views of backorder data. In addition to displaying a view of all data, you can also select a view of just the SD requirements, or just the reservations for production orders. The sales view shows you all the requirements that have resulted from sales orders. The production view shows you the requirements that have resulted from production orders. To change the view, select from the following alternatives: • • •
Settings → Total display to display all requirements Settings → Only SD requirements to display only sales requirements Settings → Reserv. for prod.ords to display only requirements for production orders
Displaying Scope of Check for Backorder Processing To display the scope of the check which the system carries out for backorder processing for a selected material, position the cursor on a line in the overview and choose Goto → Displ. scope of check.
Displaying Exception Messages If an exception message exists in the backorder processing overview for a particular MRP element, you can display the message by positioning the cursor on the relevant material and choosing Edit → Disp. except. message.
Displaying MRP Elements for Backorder Processing To display one of the MRP elements in the backorder handling overview, position the cursor on the relevant material and choose Environment → Display element.
Selecting Single Materials for Backorders As an alternative to processing backorders using a selection list, you can select the backorders for a single material. To process backorders for a single material, proceed as follows:
1. In the initial screen, choose Logistics → Sales and distribution → Sales. 2. Choose Environment → Backorders → Backorder processing → Material. 3. Enter a material number, a plant, and choose Enter.
87 You reach the Backorder Processing: Overview screen. You can process the backorders from this screen in the same way as if you were using the selection list.
Sales Order Entry in the Internet (SD-SLS-SO) Use A useful supplement to normal business transactions is the ability to accept purchase orders from customers over the Internet and forward them as sales orders to an SAP System. This is true for all kinds of business, such as catalogs, where the customer knows exactly what she or he wants and is probably only interested in comparing prices and receiving the goods quickly. Types of Internet Application Components Consumer to Business Advantages for your Customer: •
Your customer can order at any time of night or day
•
Your customer can enter purchase orders directly into their web server without having to make a telephone call or send a fax
•
Using the screen layout that you defined, your customer can enter data quickly and easily
•
Your customer can find out quickly about the most up-to-date prices and delivery times
•
Your customer can check the delivery status of the purchase order at any time
Advantages for you: •
You can design the layout of the screen so that the customer can enter data quickly and easily
•
You receive the sales order online, as soon as it has been entered
•
You are able to deliver the product rapidly, thanks to the short time span between entering the order and its arrival at your company
•
You can react very quickly to the sales order
•
You can ease congestion in sales order entry as peak times will be more dispersed
Prerequisites To enter an order in the Internet, the customer has to log on with his or her SAP customer number (or email address) and an initial password that you issued. The customer can replace the initial password with their own. The system asks for the customer number and password as soon as the customer assigns a product to shopping basket. New customers can register at this point by entering their information and the system assigns them an initial password that they can change later. Authorizations •
For customers with use master data in the SAP System and are logging on for the first time in the Internet: You can use transaction SU05 to create, change and delete passwords for the customer. In order to create a unique identification for the customer, enter object category KNA1 next to the customer number.
88 •
For new customers who do not have any master data in the SAP System and are logging on for the first time in the Internet: The system creates a customer master record in the SAP System with the data from the new customer. Essentially, the user just provides address data and additional information such as data for the company code and sales area are taken from a reference customer.
The reference customer is obligatory and you enter it as a global customer in the SAP System with the company code, organizational data, account group, and internal number assignment data. You store the reference customer as a parameter value for the parameter CSM in the master record for the global user. •
In the VW01.SRVC service file you can use the ~customeridentification customer ID switch to decide how the customer should log on - either with the customer number or the email address. The following values are permitted: − sapnumber (standard value) The customer has to enter his or her assigned customer number to buy products − email The customer can enter his or her email address and the SAP System then automatically finds the customer number by determining the customer master record for that address.
Material Group Authorization group WWW must be saved for the material group that is being offered on the Internet. You can save it in the material master in Customizing by going to Logistics General → Logistics Basic Data: Material Master → Material → Define Material Groups. If you want to offer several Internet application components in the same client, you can use the user parameter VBG (in combination with the SAP user) to control several material groups. Preallocated Data and Parameters All the authorizations for the Sales/Distribution object class must be maintained for the SAP user used by the Internet application component to log on to the SAP System via the Interaction Transaction Server (ITS9). You must also save certain parameters for this user. A sales order is created in your SAP System based on the sales order that has been entered in the Internet. The sales order contains certain mandatory entries that have to be completed when it is being created. This data is taken from the default parameters for the global user master record. The parameters are as follows: AAT (sales order type) VKO (sales organization) VTW (distribution channel) SPA (division) CSM (customer number of reference customer) VBG (service material group) If these parameters have not been completed, the system automatically enters the following values: AAT (sales order type): OR
89 VKO (sales organization): 001 VTW (distribution channel): 01 SPA (division): 01 VKB (sales office) from customer master VBG (material group): WWW
Features Service Name
The service name of this Internet application component is VW01 and you can find all the relevant files under the service name in SAP@Web Studio.
BAPIs The following Business Application Programming Interfaces (BAPIs) are used for this Internet application component: 1.• BAPI_SALESORDER_SIMULATE 2.• BAPI_SALESORDER_CREATEFROMDAT1
Sales Order Status in the Internet (SD-SLS-GF) Use Your customers can also see the status of their orders on the Internet. For example they can display their purchase orders, check whether shipping has been activated or whether the goods are already on their way. Types of Internet Application Components Consumer to Business Advantages for your Customer: •
Your customer can check the delivery status of the purchase order at any time
•
Customers can check the status directly in their web server without having to make a telephone call or send a fax.
Advantages for you: •
You can design the layout of the screen so that the customer can find information quickly and easily
•
The ability of customers to access their information on the Internet significantly reduces the workload for the order entry department, as there is no need to answer constant phone calls or faxes.
Prerequisites Authorizations/Security To enter an order in the Internet, the customer has to log on with his or her SAP customer number (or email address) and an initial password that you issued, which the customer can then replace with their own.
90 You can use transaction SU05 to create, change and delete passwords for the customer. In order to create a unique identification for the customer, enter object category KNA1 next to the customer number. All the authorizations for the Sales/Distribution object class must be maintained for the SAP user used by the Internet application component to log on to the SAP System via the Interaction Transaction Server (ITS9). You should establish whether you want to restrict the authorizations for order types if there any that you do not want the customer to see. Standard Settings and Preallocated Data You do not need to enter any additional data in order for the customer to check the status of the sales orders. The customer number with which the customer logs on also provides the date, while the customer can enter any other selection data such as the article, time period or order number directly.
Features Service Name
The service name of this Internet application component is VW01 and you can find all the relevant files under the service name in SAP@Web Studio.
BAPIs The following Business Application Programming Interfaces (BAPIs) are used for this Internet application component: •
BAPI_SALESORDER_GETSTATUS
•
BAPI_SALESORDER_GETLIST
•
BAPI_CUSTOMER_CHECKPASSWORT
Billing Plan Purpose A billing plan is a schedule of individual billing dates for a single item in a sales document. You can define a billing plan at header level, which is then valid for all items assigned to it. Depending on the kind of business process you are carrying out, the system can automatically propose one of two different types of billing plan: periodic billing or milestone billing.
91 • •
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 projectrelated 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.
During sales order processing, the system determines from the item category whether a billing plan is required and, if so, which type of plan: The type of billing plan that is determined at this point is set up in Customizing and cannot be changed in the sales document. For each billing plan you create, you can enter a freely-definable search term in the details screen of the billing plan in the sales document. When you save the document, the system automatically assigns a number that later uniquely identifies the individual plan. You can use the search term later to locate specific billing plans. Billing plans for rental contracts and billing plans for project-related milestone billing have different overview screens so that you can enter data relevant to your processing. For example, for milestone billing, you must be able to enter data to identify the individual milestones.
For more information about project milestones, see the Production Planning documentation about the Project System.
Installment Plan Use 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 folloowing data for this key: • • •
the number of installments the payment dates the percentage of the billling value
92 A customer buys a washing machine for USD 1,000.00. The customer makes a down payment of 20% - USD 200.00 The remaining amount is paid in monthly down payments of 13,33% over six months. Down payment: 1. February 1: USD 200 Monthly installments: 1. March 1: USD 133.33 1. April 1: USD 133.33 1. May 1: USD 133.33 1. June 1: USD 133.33 1. July 1: USD 133.33 1. August 1: USD 133,35 You can: • •
store the default payment terms key in the customer master record (on the Billing Sales Area screen, field: payment terms). overwrite the payment terms key in the sales order header or item (menu path Header or Item → Business data, field Payment terms)
You can use the payment terms key to print a suitable text on the order confirmation.
Working with User Exits Updating the document flow The total quantity to be billed is transferred to the sequential data record. Quantities which have already been billed are managed within the SAP system. This process is influenced by user exits. User exits directly influence the update of compressed document flow VBAPF in the system. This document flow accumulates quantities which have already been billed and compares them to new billing quantities. A new billing document is then created with the following quantity: Quantity to be billed = New quantity - quantity already billed Using user exits, you can specify the keys to which records of the compressed document flow are to be stored. The following user exits have been designed for the general billing interface: User exit
Description
Table VBAPFZZ
Used for adding customer-specific key fields to table VBAPF
Report RV45PFZZ
Used for adding customer-specific key fields from VBRK to internal work table FXVBAPF
Report RV60AFZA
Used for adding values in customer-specific key fields from interface structure XKOMFKGN or from cancellation VBRK in field list XVBAPF_KEY.
93
Following is an example of how user exits are used in the SAP IS-H: An interim settlement for 10 days (KWMENGE) is created for patient account 4711 (VBELN) on June 30. In this case, the invoice is paid by various payers. The payer ‘AOK Insurance’ agrees to pay 30% (=3 days) while patient 122 assumes the role of a second payer and pays the rest, 70% (=7 days). The following billing documents are created:
On July 30, a complete settlement is prepared for a total patient stay of 20 days. Without using user exits During the program run, a record is created in compressed document flow (VBAPF) with the cumulative quantity already billed from the interim settlement (=10 days).
In the final settlement, payer ‘AOK Insurance’ is billed for a total of 6 days (30% of 20 days). The compressed document flow (VBAPF) shows 10 days as already having been billed: the document flow without payer as key field cannot process percentage divisions. A new billing document 3 is created for payer ‘AOK Insurance’ with a billing quantity of -4:
Quantity to be billed = Quantity to be billed from KOMFKGN quantity already billed
94 6 days - 10 days = 4 days
Using user exits For a correct result in this case, the payer must be taken into account in document flow (VBAPF) for quantities which have already been billed. This can be accomplished by making the appropriate settings for these user exits: Transaction
Configuration
Table VBAPFZZ: → SE11
Object name: table VBAPFZZ Delete available fields Add field name KUNRG with data element KUNRG
Report RV45PFZZ
FORM USEREXIT_FXVBAPF_KEY.
→ SE38
MOVE VBRK_KUNRG TO FXVBAPF-KUNRG. ENDFORM.
Report RV60AFZA
FORM USEREXIT_XVBAPF_KEY.
→ SE38
MOVE XKOMFKGN-KUNRG TO XVBAPF_KEY-KUNRG. ENDFORM. FORM USEREXIT_XVBAPF_KEY_CANC. MOVE * VBRK-KUNRG TO XVBAPF_KEY-KUNRG. ENDFORM.
During the program run, two records are created in the compressed document flow with the cumulative quantity already billed from the interim settlement (=10 days).
95
In the final settlement, payer ‘AOK Insurance’ is billed for a total of 6 days (30% of 20 days). The compressed document flow (VBAPF) shows 3 days as already having been billed due to the setting for payer (KUNRG) in the user exits. A new billing document 4 is created for payer ‘AOK Insurance’ with a billing quantity of 3: Quantity to be billed = Quantity to be billed from KOMFKGN - quantity already billed from VBAPF that means 6 days -3 days = 3 days
Adding new partner functions You can define new partner functions for those existing in the standard (sold-to party, ship-to party, bill-to party, payer).
Copy new partner function ‘representative number’ from the interface. Use Report RV60AFZA as a user exit: FORM USEREXIT_AVBPAK_ADD. MOVE "VE" TO AVBPAK-PARVW. IF NOT XKOMFKGN-VRTNR IS INITIAL. AVBPAK-PERNR=XKOMFKGN-VRTRNR. ENDIF. APPEND AVBPAK.
96 It is not yet possible to use user exits for document flow update with new partner functions. See also: The topic on updating the document flow in Working with User Exits.
Deviating CpD address data In order to process deviating CpD address data in different partner functions using the general billing interface, you must modify the INCLUDE structure KOMFKZZ according to table structure KOMFKGN as well as the user exit USEREXIT_AVBPAK_CPD (Report RV60AFZB). There are, however, several limitations: • • •
The sold-to party (partner function AG) must be a CpD customer The bill-to party (partner function RE) must not be a CpD customer User exit USEREXIT_AVBPAK_CPD can only be used as delivered in the standard system
Another example: • • • •
The sold-to party is a CpD customer The CpD address is valid for the sold-to party and bill-to party, independent of whether the partners are CpD customers The ship-to party has a different CpD address Sample report RVAFS01 which creates the sequential file would then contain the following coding:
* CpD fields WA_KOMFKGN-CPD_PARVW1
=
‘AG’
WA_KOMFKGN-CPD_PARVW2
=
‘RE’
WA_KOMFKGN-CPD-ANRED
=
‘Mr.’
WA_KOMFKGN-NAME1 (length 30)
=
‘FIRST_CPD_NAME’
WA_KOMFKGN-LAND1
=
‘US’
WA_KOMFKGN-PSTLZ
=
‘99999’
WA_KOMFKGN-ORT01
=
‘New York’
* Different address - Ship-to party (CpD customer) WA_KOMFKGN-WE_PARVW = ‘WE’ WA-KOMFKGN-WE_ANRED
=
‘Ms.’
WA_KOMFKGN-WE_NAME1 (length 30)
=
SECOND_CPD_NAME
WA-KOMFKGN-WE_LAND1
=
‘US’
WA_KOMFKGN-WE_PSTLZ
=
‘9999’
WA_KOMFKGN-WE_ORT01
=
‘Boston’
97 TRANSFER WA_KOMFKGN TO DS_NAME1.... Partner functions in the billing document would appear as follows: Billing document FX Partner function Partner Name SP
Sold-to party
ODL-CPD
FIRST_CPD_NAME
BP
Bill-to party
ODL
FIRST_CPD_NAME
PY
Payer
ODL
Address in customer master
SH
Ship-to party
ODL-CPD
SECOND_CPD_NAME
To add a different CpD address for all partners other than the sold-to party, change the user exit. Another example: The sold-to party is a CpD customer The CpD address is valid for the sold-to party A different CpD address is valid for all other partners Sample report RVAFSS01 which creates the sequential file would then contain the following coding: * CpD fields WA_KOMFKGN-CPD_PARVW1 = ‘SP’ WA_KOMFKGN-CPD_ANRED
=
‘Mr.’
WA_KOMFKGN-NAME1 (length 30)
=
‘FIRST_CPD_NAME’
WA_KOMFKGN-LAND1
=
‘US’
WA_KOMFKGN-PSTLZ
=
‘99999’
WA_KOMFKGN-ORT01
=
‘New York’
* Different address - Ship-to party (CpD customer) WA_KOMFKGN-WE_PARVW = ‘XX’ (e.g. ‘BP’, ‘SH’, etc.) WA-KOMFKGN-WE_ANRED
=
‘Ms.’
WA_KOMFKGN-WE_NAME1 (length 30)
=
‘SECOND_CPD_NAME’
WA-KOMFKGN-WE_LAND1
=
‘CH’
WA_KOMFKGN-WE_PSTLZ
=
‘9999’
WA_KOMFKGN-WE_ORT01
=
‘Basel’
TRANSFER WA_KOMFKGN TO DS_NAME1. Partner functions in the billing document would appear as follows: Billing document FX Partner function Partner Name SP
Sold-to party
ODL-CPD
FIRST_CPD_NAME
BP
Bill-to party
ODL
SECOND_CPD_NAME
PY
Payer
ODL
SECOND_CPD_NAME
SH
Ship-to party
ODL-CPD
SECOND_CPD_NAME
User exit RV60AFZB appears as follows (changes can be identified by an ‘*’ at the beginning of the line): FORM USEREXIT_AVBPAK_CPD.
98
IF XKOMFKGN-WE_PARVW NE SPACE. LOOP AT AVBPAK. LOOP AT AVBPAK WHERE PARVW EQ XKOMFKGN-WE_PARVW. MOVE '00000000'TO AVBPAK-ADRNR. MOVE AVBPAK-PARVWTO AVBPAK-ADRNR(2). *MOVE XKOMFKGN-WE_PARVWTO AVBPAK-ADRNR(2). MOVE 'B' TO AVBPAK-ADRDA. MOVE 'X' TO AVBPAK-XCPDK. MODIFY AVBPAK. *ENDLOOP. CLEAR XVBADR. MOVE '0000000'TO XVBADR-ADRNR. MOVE AVBPAK-PARVWTO XVBADR-ADRNR(2). MOVE XKOMFKGN-WE_PARVWTO XVBADR-ADRNR(2). MOVE XKOMFKGN-WE_ANREDTO XVBADR-ANRED. MOVE XKOMFKGN-WE_NAME1TO XVBADR-NAME1. MOVE XKOMFKGN-WE_PSTLZTO XVBADR-PSTLZ. MOVE XKOMFKGN-WE_ORT01TO XVBADR-ORT01. MOVE XKOMFKGN-WE_LAND1TO XVBADR-LAND1. APPEND XVBADR. * Fehlerprotokoll (Error log) * PERFORM GN_CPD_CHECK USINGSY-SUBRC XKOMFKGN-WE_LAND1 *XKOMFKGN-WE_NAME1 *XKOMFKGN-WE_PSTLZ *XKOMFKGN-WE_ORT01. * *IF SY-SUBRC NE 0. EXIT. ENDIF. ENDLOOP. * ENDIF. ENDFORM.
Scheduling Agreements Purpose A customer scheduling agreement is an outline agreement with the customer containing delivery quantities and dates. These are then entered as schedule lines in a delivery schedule. You can either create schedule lines when you create the scheduling agreement or you can create them later. You fulfill a scheduling agreement by creating the deliveries in the schedule as they become due. You process deliveries for a scheduling agreement in exactly the same way as you process a
99 normal delivery. After you have carried out the delivery, the system updates the Delivered quantity field in the scheduling agreement item with the delivery quantity. The following graphic shows the document flow for scheduling agreements.
Integration You would use this component if you had outline agreements with the customer that contained future delivery quantities of materials that would be sent at certain times within a fixed time period. If you work with scheduling agreements for the component supplier industry you also need to choose the "Electronic Data Interchange" (EDI) component.
Features The same functions are at your disposal for processing scheduling agreements as there are for the sales order, including pricing and availability checks. In addition to the standard scheduling agreements you can also manage scheduling agreements for the component supplier industry, with their special features that include: • • • •
Working with scheduling agreements with EDI output Entering scheduling agreements in a forecast or just-in-time (JIT) delivery schedule Using different types of cumulative quantities Taking into account the automatic fiscal year change used by the component supplier
100 • • • •
Managing engineering change statuses Storing packing proposals Creating correction deliveries for the scheduling agreement Working with external service agents
Service Contracts Purpose You use service contracts to record the details of the service package that you have agreed to provide a service recipient with over a specified period of time. For example, you specify: • • • •
The routine service tasks which are to be performed on a piece of machinery you have sold or rented to a customer The prices which are to apply for these routine tasks For more information, see Standard Pricing in Service Contracts. The prices which are to apply for additional service tasks and for any spare parts required For more information, see Price Agreements in Service Contracts. The terms under which the contract can be cancelled For more information, see Cancellation Data in Service Contracts.
During the validity period of the service contract, you use the service contract as follows: • • • • •
To initiate automatic billing of the routine service tasks at regular intervals To determine whether a service request from the customer is covered by the service contract To determine which price agreements apply for service tasks not covered by the service contract To determine whether a cancellation request from the customer is valid To initiate follow-up actions before the service contract becomes invalid
Service Quotation Definition A presales document containing the terms under which you offer a particular service to a customer. To create a service quotation, choose one of the following processes: •
Create the service quotation directly in Sales and Distribution Use this option for straightforward service transactions, which do not require detailed planning.
•
Create a service order in Customer Service and then create a service quotation with reference to the service order
101 This option enables you to plan service activities more accurately and influence the costs that are forwarded to billing.
Use In the service quotation, you: • • •
Record details of the service to be performed Record the costs of the service Control how billing is performed You specify in the service quotation how the customer is to be billed for the services rendered via the billing form and the dynamic item processor profile.
Returns and Repairs Processing (CS) Purpose Returns and repairs processing provides you with a wide range of functions for managing all the necessary activities which repairing goods for a customer entails, from registering the repair request from the customer through to billing the customer for the services performed.
Process Flow
102 Repair Registration 1. Create the Repair Order: The customer informs you that he has goods that he would like you to repair. You record the details of the customer's repair request as the main item in a repair order. You enter the Serviceable material and, depending on the repair order type, a suitable Service Product as well. Repairs processing can also be initiated by a service or quality notification. You use the Action Box in the notification to create a repair order automatically. For more information on repairs processing using quality notifications, see Repairs Processing Using Quality Notifications. You can start repairs processing by sending the customer a service estimate for the costs of the repairs. For more information, see the Service Estimate. 2. Create a return order item for the serviceable materials: The return order item is created automatically on the basis of the Repair Procedure assigned to the repair request item in the repair order.
3. Posting Goods Receipt for Serviceable materials The customer either sends you the serviceable materials or you arrange to pick them up. When you receive the serviceable materials, you post goods receipt for the appropriate quantity. If inspection lot processing has been activated for the serviceable material, an inspection lot is created automatically for the repair order. For more information, see Repairs Processing Using Inspection Lots in QM 4. Post goods movement The serviceable materials are posted as sales order stock. If you are not using inspection lot processing, the serviceable materials are assigned to unrestricted use stock. We recommend that you post the serviceable materials to blocked stock for the duration of the repairs. Use movement type 344/E to make this posting. If you are using inspection lot processing, the serviceable materials are assigned to inspection stock for the duration of the repairs. 5. Perform the technical check Once you have posted goods receipt, you perform a technical check on the serviceable materials and decide what actions need to be taken to fulfill the customer's repair request. You can perform the technical check in one of the following ways:
103 o o o
If you are working with inspection lots, use the inspection lot that is created automatically when you post goods receipt. If you used a notification to initiate repairs processing, use the action box in the notification. If you are simply working with the repair order, perform the check manually.
6. Create Actions for Managing Repairs Processing The results of the technical check are reported back to the repair order. The actions, which need to be taken as a result of the technical check, are recorded as sub-items of the repair request item. Possible actions include: o o o
Perform repairs Scrap the goods Send temporary replacement
Depending on how you perform repairs processing, the switch from the repair registration stage to the repair start stage occurs: o
During inspection lot processing The actions are generated automatically when the results of the inspection lot are reported back to the repair order unless manual intervention is required.
o
During returns delivery processing The system proposes the possible actions when you call the change order function. You select the appropriate actions for the subsequent stage of repairs processing.
Repair Start 1. The service technician repairs the serviceable materials for which a repair item has been created. He refers to the service order that was created automatically for the repair item to obtain the following essential information: o o o
The materials required to perform the repairs The tasks to be performed The costs (for example, labor hours) involved
2. Loaner items (for example, for temporary replacements) become relevant for delivery and are included in the delivery due list. 3. The serviceable materials for which a scrap item has been created can be scrapped.
Repair Completion Confirmation 1. The service technician reports that he has completed the necessary repairs for the repair items in the repair order by: o o
Posting the repaired serviceable materials to unrestricted use stock using movement type 343/E Updating the status of the service order to "technically completed"
104 o
The repair order status is updated accordingly.
If you perform the repairs without using a service order, you must update the repair order status manually. 2. The system creates a delivery item for returning the serviceable materials to the customer. 3. The system may also create a pick-up item to arrange the return of any temporary replacements the customer may have had. 4. When you perform resource-related billing, a debit memo request item is entered automatically in the repair order.
Results 1. Delivery items are included in the delivery due list and the repaired serviceable materials are returned to the customer. When you post goods issue, stock is adjusted accordingly. 2. Loaner items can be returned to you with a returns delivery. For information on creating a returns delivery, see Posting Goods Receipt for Serviceable Materials. 3. The debit memo request item is included in the billing due list. The system creates a debit memo on the basis of the debit memo request item. 4. Costs collected in the service order and the repair order sub-items are settled to the repair request item. The data is forwarded to profitability analysis.
Repair Order Definition Sales document for recording all the business processes that are involved in processing faulty goods that a customer sends in for repair.
Structure
105 The repair order has the following structure: • •
Header in which you record data that applies to the entire document Repair request item in which you document the customer repair request The following information is recorded in the repair request item: o o o o o o
•
Material number of the Service Product Material number of the Serviceable material Costs Stock information Configuration data The repair procedure which the system uses to determine which actions it needs to generate for the repair request item
Actions that have to be performed in order to fulfill the customer repair request. o
The Repair Procedure that is assigned to the repair request item determines which actions are required.
Use You require a repair order to manage repairs processing. Depending on how repairs processing is performed in your organization, you can choose between one of the following repair order types in the standard system: •
RAS - Repair order with service product You use this type of repair order if you want to specify the repairs to be performed at the time of order entry. A repair order of the type RAS is incomplete until a service product is entered. You can: o o
Enter the service product directly in the Material field in the repair order Use the material determination function to find suitable service products via the material number of the serviceable material.
When you enter the service product and serviceable material in the repair request item, the system creates a return order item automatically for the serviceable material. The repair procedure controls this. •
RA - Repair order You use this type of repair order if you perform repairs according to the results of the technical check. You do not have to enter a service product at the order entry stage. After the technical check has determined what repairs need to be performed on the serviceable material, you can: o o
Enter the appropriate service product on the repair screen of the repair order Use the material determination function to find suitable service products via the material number of the serviceable material.
106
You must enter a service product in the RA repair order before the service technician can begin the repairs.
Service Product Definition Material that represents the customer's repair request. The service product is represented in the system by a material master record. Service products are measured in the unit of measure "piece". If required, you can define the service product as a configured or configurable material.
Use You enter the service product in the repair request item in the repair order. You can set up material determination so that when you enter the serviceable material in the repair request item, the system proposes the appropriate service products for selection. The service product is used to determine: •
What services the customer should pay for
•
How much these services cost
•
Which tasks are required to perform the services
Serviceable Material Definition Represents the goods to be repaired in repairs processing.
Use The serviceable material is recorded in the repair request item of the repair order. It is also added to the technical objects list for the repair request item. The system adopts the base unit of measure as the unit of measure for the serviceable material in the repair order. You use material determination condition records to link serviceable materials to suitable service products.
Repair Procedure Definition
107 Set of rules according to which actions are generated in the repair order. It is assigned in Customizing to the item categories that are relevant for repairs processing and is adopted in the repair request item in the repair order.
Structure The repair procedure contains the following control elements: •
Stages They represent the various phases of repairs processing.
•
Actions
They represent the activities that need to be performed to fulfill the customer repair request. You define repair procedures in the Customizing activity Define repair procedures. By assigning actions to stages, you set up the rules according to which the system determines what actions are required during a particular phase of repairs processing. In addition, you specify for each combination of stage and action whether the required actions are • • •
Actions that the system proposes automatically when a particular stage of repairs processing begins Actions that are generated automatically on the basis of repair codes that inspection lots, notifications or service orders report back to the repair order Actions that require approval and must be created manually
The following indicators have been defined for these purposes: •
Default In Customizing for the repair procedure, you set this indicator for combinations of stages and actions that do not involve inspection lots or services orders and, for which you require an action to be generated automatically. For example, at the repair registration stage, you require a return order item to be generated automatically. You activate this indicator for the stage 101 (repair registration) and the action 101 (return goods). In the repair order, a return order item is generated automatically when you create a repair request item.
•
Repair code Repair codes represent the information that the service technician reports back to the repair order after performing the technical check or completing the repairs. In Customizing for the repair procedure, they are assigned to combinations of stages and actions that involve inspection lots or service orders. The code initiates the generation of the appropriate action.
108
•
Manual If you use the manual indicator in the repair procedure, you always activate it in conjunction with the Repair code indicator. The Manual indicator prevents particular actions from being generated automatically when repair codes are reported back to the repair order from inspection lots, notifications and service orders. If you do not set the Manual indicator for a combination of stage and action to which a repair code is assigned, the system automatically generates the appropriate action on the basis of the repair code. If the technical check determines that goods cannot be repaired and should be scrapped, you need to contact the customer to find out whether you can scrap the goods or whether he wants the goods returned to him. In this case, you do not want the system to automatically create an action for scrapping the goods. Therefore, you need to activate the Manual indicator for the stage 101(repair start) and the action 107 (scrap goods). When the system reads the repair code that the inspection lot reports to the repair order, it determines that the scrap item is required. The system then checks the corresponding stage and action in the repair procedure and determines that the scrap item cannot be generated automatically. It does not generate that or any other required actions automatically. It does not update the status of the repair request item. To continue repairs processing, you must clarify whether the customer wants you to scrap the goods or return them to him. You must then create the required actions manually on the Repairs screen.
Material Determination in the Repair Order Use
109 You can use material determination in the following situations in the repair order: •
When you create an order to find suitable service products for the serviceable material you enter in the repair order
•
When actions are created automatically or manually o o
To find suitable service products for a serviceable material when a repair item is created To find suitable temporary replacements when a loaner item is created and the material for which a temporary replacement is required is no longer produced
Prerequisites At the Order Entry Stage You must make sure that the appropriate material determination procedure is assigned to the sales document type in Customizing for Sales and Distribution in the section Basic Functions -> Material Determination. You must create a material determination condition record in which you define: • • •
The material for which suitable service products are to be proposed The service products which are to be proposed in the repair order for this material Substitution reason 0007 for the condition record The substitution type A that is defined for substitution reason 0007 controls that the service product replaces the serviceable material as the leading item in the repair order.
When Actions are Created Automatically or Manually You must make sure that the appropriate material determination procedure is assigned to the relevant action in the Customizing activity Maintain actions. To be able to perform material determination for the repair item, you must define a material determination condition record as described above. To be able to perform material determination for the returnable item, you must create a material determination record in which you define: • •
The material to be substituted The material(s) which may substitute the material entered in the repair order
For more information, see
Material Determination.
Posting Goods Receipt for Serviceable Materials Use You post goods receipt to record that the serviceable materials have arrived at your plant. You can also record receipt of other goods such as loaner items.
Prerequisites
110 You require a repair order in which you have recorded the customer's repair request.
Procedure 1. Choose Logistics → Customer Service → Service Processing → Order → Customer 2.
repair → Returns delivery. On the Create Returns Delivery screen, enter the following information: o
Number of the repair order in the Repair order field You can search for the appropriate repair order using the RMA number.
o
Delivery type in the Delivery type field In the standard system, delivery type Returns delivery (LR) has been defined for this purpose.
o
Number of the shipping point in the Shipping point field
3. Choose Enter. 4. You reach the overview screen where you can post goods receipt by choosing Edit → Post goods issue. 5. Save the delivery.
Result Repairs Processing Using Inspection Lots When you post goods receipt for serviceable materials: • •
The items are automatically assigned to inspection stock An inspection lot is created automatically and initiates the technical check
Repairs Processing Without Inspection Lots When you post goods receipt for the serviceable materials: •
The items are automatically assigned to unrestricted use stock We recommend that you post the serviceable materials to blocked stock (using movement type 344E) before you start the repair process.
•
You must initiate the technical check manually
You can also create returns deliveries by choosing Outbound Delivery → Create in the Shipping menu.
Shipping Screen Depending on the system you are using, choose
111 System
Menu path
Standard SAP System
Logistics ® Logistics Execution ® Outbound process ® Goods issue for outbound delivery or Logistics ® Sales and distribution ® Shipping and transportation
SAP Retail
Logistics ® Retailing ® Merchandise logistics ® Logistics Execution ® Outbound process ® Goods issue for outbound delivery
Actions for Managing Repairs Processing Use The system uses the Repair Procedure that is assigned to the repair request item to determine what actions need to be taken to fulfill the customer's repair request. The actions are represented in the system as sub-items of the repair request item. The system determines the appropriate item categories for the sub-items using the item category usage and the item category of the higher level item (repair request item). The item category usage and the item category of the higher level item are assigned to the repair order type in the Customizing activity Assign Item Categories.
The item category usage is the action from the repair procedure with the prefix "R". For example, 101 (Repair registration) is the underlying action for item category usage R101.
Features In the standard system, the following sub-item types can be created: Sub-item
Is used to
Return order item
Manage return of goods to be repaired
Loaner item
Send temporary replacements to the customer
Repair item
Initiate repairs Depending on the requirements type, a service order may be created automatically for a repair item
Scrap item
Simply records that an item is to be scrapped. It does not manage the scrapping process.
Credit memo request item
Initiate the credit memo process for reimbursing customer for
112
irreparable goods Outbound delivery item
Return repaired goods to customer
Loaner pick-up item
Pick up temporary replacements from customer
Debit memo request item
Record data from resource-related billing
Activities Where possible, the system generates the required actions automatically. If any of the actions need to be approved before they can be performed, the system does not generate any of the actions automatically. (You control this in the repair procedure with the Manual indicator.) You must create these actions manually when you have the necessary approval to proceed. In this case, you select the type of action that you require from proposals made by the system.
The repair procedure prevents the system from generating a scrap item in the repair order automatically. The repair request item status remains "Business decision required" until you gain the customer's approval to scrap the serviceable material and create a scrap item manually for it.
Shipping (LE-SHP) Implementation Options Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles. In shipping processing, all delivery procedure decisions can be made at the start of the process by •
Taking into account general business agreements with your customer
113 • •
Recording special material requests Defining shipping conditions in the sales order
The result is an efficient and largely automatic shipping process in which manual changes are only necessary under certain circumstances.
Integration The Shipping component is integrated under the Logistics Execution component. Shipping is a subsequent activity of the Sales component.
Range of Functions The shipping module supports the following functions, which include but are not limited to: • • • • • • • • • • • •
Deadline monitoring for reference documents due for shipment (sales orders and purchase orders, for instance) Creating and processing outbound deliveries Planning and monitoring of worklists for shipping activities Monitoring material availability and processing outstanding orders Monitoring the warehouse's capacity situation Picking (with optional link to the Warehouse Management system) Packing deliveries Information support for transportation planning Support of foreign trade requirements Printing and transmitting shipping documents Processing goods issue Controlling using overviews of o o o
Deliveries currently in process Activities that still are to be carried out Possible bottlenecks
A list of deliveries posted as goods issue in the shipping department could be used to form a worklist for the billing department.
114
Transportation (LE-TRA) Purpose Transportation is an essential element in the logistics chain. It affects both incoming and outgoing goods. Effective transportation planning and processing ensure that shipments are dispatched without delay and arrive on schedule. Transportation costs play an essential role in the calculation of the price of a product. It is important to keep these transportation costs to a minimum so that the price of a product remains competitive. Efficient transportation planning and processing helps to keep these costs down.
Integration As illustrated in the following graphic, you can use the SAP transportation functions to plan and process: •
Incoming shipments in Materials Management based on purchase orders and shipping notifications
•
Outbound shipments in Sales and Distribution based on sales orders and deliveries
The graphic below illustrates this process:
115
Transportation planning and processing is based on the shipment document. This document facilitates the flow of information from the shipper to the customer and to any service agents who are involved in the business transaction.
Features The transportation component includes basic transportation processing functions: •
Transportation planning and shipment completion
•
Shipment costs calculation
•
Shipment costs settlement
•
Shipment costs calculation for individual customers
•
Billing of customer freight
•
Service agent selection
•
Management of means of transport and utilities
•
Follow-up and supervision of shipments
•
Management of shipment costs
These transportation functions can handle planning and processing for both inbound and outbound shipments. You can control and monitor the entire transportation process from the planning stage to goods issue at your shipping point (for outbound shipments) or vendor location (for inbound shipments), through to goods receipt at the customer location or your plant. Other available functions include: shipment costs calculation and settlement with the service agent, transfer to accounting, credit memo creation and invoice verification. This documentation describes procedures in outbound shipment processing. Unless specifically stated otherwise, the information here also applies to inbound shipment processing. Differences between the two will be pointed out where necessary. For more information about creating and processing inbound deliveries, see the Confirmations section of the documentation for Purchasing (MM-PUR).
116
