Availability Check and TOR

[Former Member]

Hello Gurus,

Can someone explain the process of availability check an tor.

Could you pls send me cofiguration doc. to my Id reddy.jagadeshwar@gmail.com

Thanks

Reddy

[Former Member]

HI

<b>Availability Check & TOR configuration is done hand in hand..</b>

<b>TOR AND AVAILABILITY CHECK</b>

To confirm the quantities for a particular line item in the sales order on particular day system carried out transfer of requirements (TOR) & AVAILABILITY check, so has to confirm the quantity on particular day as system should know what are there requirement of the sale order and delivery with MRP then system carries out availability check function, to confirm the quantity on particular day. Depending upon the IMG setting system carries out availability check function based on 3 methods:

A) Availability Check with ATP logic or against planning:

In ATP logic systems ATP Qty while carrying out availability check function for

Particular line item (ATP qty=warehouse stock +planned receipts planned issues)

Planned Receipts: EX: - purchase requisitions, purchase orders, stock in transfer stock at inspection etc.

Planned Issues: - EX: - open sales order & open delivers

B) Availability check against product allocation:

Availability check can be carried out against product allocations in which system automatically restrict the user to confirm the quantity beyond reserved quantities per particular customer. EX:- Availability qty =100, existing orders=10,then system automatically distributes to items evenly to the sales order.

C) Rule based Availability check:

Rule based availability check can be carried out based on the business transaction.

EX: - For normal sales order system has to carry out availability check for special sales order ex: - cash sales and rush order systems need not to be carry out availability check,

In rule based availability check system in which system carried out Global availability to promise in all plants. In this check system transfers the requirements to APO system where GATP takes place and the result of the availability check transferred to R/3 system. This process takes place with the transaction code CIF(central inter face) inR/3.After carrying out availability check function system proposes(by using ATP logic) default values of ATP check result to the user in a dialog box, in which system gives the choice to the user to take the decision in contest of insufficient stock.

a) One time delivery:

If the user chooses one time delivery and the order Quantity is 100 units system confirms 50 units then systems automatically confirms as a zero. If the user saves the document with the zero confirm qty then system trace the sales order as aback order (V_RA), which can be confirmed later by RESCHEDULLING (V_V2).

b) Complete Delivery:

If order Qty=100, Availability stock = 50, system says that remaining can be given after one week. Then if the user selects this option then system push up existing confirmed qty to after one week and the total qty can be confirmed after one week only.

c) Delivery Proposal:

If order qty=100, system confirms 50, and remaining 50 can be confirmed after one week. If the user chooses this option then system confirms 50 Qty today allows the user to delivery 50 quantities today remaining 50 can be delivered after one week.

CONFIGURATION SETTINGS FOR TOR:

Define Requirement Class:

Path: Img &#61664; S&D &#61664; Basic functions &#61664; Availability Check & Transfer of requirements &#61664; Transfer of requirements &#61664; Define Requirement classes

Requirement classes control MRP, Requirement consumption, strategy, relevance for planned. It specifics whether the availability check & TOR to be Called out for transactions. Ex: Sales Order

It determines whether requirements relevant for MRP or not, the allocation indicator from the sales view which controls the settlement of customers requirements with planned independent requirements. It determines the item b to be settled as an availability heck. Assignment, the settlement profiles the results analysis key. The TOR and Availability check functions are globally controlled using the requirement class for all the Sales documents. The values from the Requirements class are transferred to scheduled the of the sales documents class are transferred to scheduled the of the sales document default values and can be over written there.

Define Requirements Classes:

Requirement class defines whether the system has to carry out availability check based on the STP Qty. Ex:

Define Requirement Types:

Here we define requirement type, Ex: and Assign to Requirement class that we defined in the promote step.

Determination of Requirement types using Transaction:

Requirement type is going to be determined for sales document by following a search strategy. .

First System checks strategy group in MRP3 view if it trend requirement type then system takes from it, otherwise.

It will go to MRP group in MRP1 view, otherwise

It will check to Material type, otherwise

It will go to item Category + MRP type, otherwise

It will go to Item category only, otherwise

Finally system determines the transaction b not relevant for TOR & Availability check.

Choose Item category TAN+MRP type PD=Requirement type =0

Define Procedure for each schedule the category:

Here we define respective schedule the category of the sales documents, whether an availability check and TOR should be carried out. This setting is relevant for sales documents only. It is fine tuning of availability check for sales documents TOR & Availability check function can be activated at sales order level those are proposed in to schedule line category level. If u wants to deactivate TOR availability check function at schedule the category level and want to deactivate at requirement class level it b impossible.

Ex: If u wants to check availability w/o transferring the requirement we can use it.

Choose schedule line category CP & Activate Availability check, requirement & Product Allocation

Block Quantity confirmation in delivery Blocks:-

When we transfer requirements to MRP then confirmed quantities is also reserved for confirmed sales documents, if transaction is blocked for delivery the reserved quantities are also blocked so that the conformed quantities cannot be used by any other purpose. So has to avoid this situation we can block the transfer of requirements(TOR) for delivery blocks, in this case requirements transferred to MRP but will not be reserved, that will be cleared once we save the documents then system shows confirmed qty as zero.

When we remove the delivery block then system automatically carries out availability check & confirms the qty.

A) Deliveries: Blocking region for sales Area:

Here we define blocking regions for TOR ex:-credit limits

B) Reasons for scope of delivery blocks: TOR. Block:

Ex: - 01 credit limits-check confirmation block.

Maintain Requirements for TOR:-

Here we can define our own requirement with the help of ABAPer for TOR

Ex: - a) 102- prevent reservation in the event of credit block

b) 102-purchase requisitions.

System doesn’t create purchase requisitions for sales order line items if it has a credit limit.

Availability check:

Configuration setting:-

Availability check with ATP logic or against planning:-

Define checking group:

Checking group define what kind of requirement record system use to create when sales order & deliveries are processed for this material. We can create 2 kinds of requirements records

Individual requirement records: that means system creates requirement record for each S&D document.

Summarized requirement Records: That means system creates requirement records under certain condition in the material master record. There are 2 type of summarized requirement record:

Summarized requirement records for each day.

Summarized requirement records for each week

Define checking Action;

Here we define 01- daily requirement -B 02- Individual requirements -A

Where b-total record per day

A-single record per day

B) Define material Block for other users:

When 2 users tries to confirm the quantities for the sales order for same material at a time system will be confused to confirm the quantities both sales orders. So has to avoid this kind of situation we can block the materials from confirming the quantities for 2 users at a check, check block

C) Define checking group default values:

Checking group is going to be determined depending upon the material type & plant.

-Go to new entries, specify material type, ex;-FERT

& plant = checking group of availability check: 02

D) Carry out for Availability check:

Here we define checking rule for the Availability check & allocate them to the checking group. The checking rules specify the scope of the availability check. For a respective transaction, means which planned receipts & planned issues systems has to taken into consideration and also it determines whether system has to take RLT into consideration.

Action:

*Select checking group of availability check-02, checking rule=01

*Go to details icon, & check which planned receipts & planned issues system has taken into consideration for availability check

*save it, exit.

E) Define procedure by Requirement class:

Here we define requirement class whether on availability check & TOR should be carried out the setting that we carries out at requirement class level they are at global level. There settings automatically copied into define from of requirement class and vice versa.

Action:

*Choose requirement class: 041 & check availability check & TOR (requirement)

F) Define procedure for each schedule line category:

Here we carry out fine tuning setting for availability check at schedule line category level. Here we define whether system has to carry out Availability check for particular transaction.

Ex:- if we want to implement a availability check w/o TOR for a particular transaction. According to settings at requirement class level TOR & availability check function activate & those setting will be copied into the schedule time category by default, so that at schedule line category level we deactivated TOR

G) Determine procedure for each Delivery Item category:

H) Checking group for updating back orders:

[Lakshmipathi]

Hi Jagadeshwar

1. Availability Check

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.

The following elements can be included in the availability check:

· Stock

o safety stock
o stock in transfer
o quality inspection
o blocked stock

· Inward/Outward movement of goods

o purchase orders
o purchase requisitions
o planned orders
o production orders
o reservations
o dependent reservations
o dependent requirements
o sales requirements
o 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.

Transfer of Requriements

The following types of transfer of requirements exist:
· Transfer of requirements with individual requirements
· Transfer of requirements with collective requirements

In the material master record, you specify on the Sales/Plant Data screen in the Availability check field whether each requirement is forwarded individually to planning or whether the requirements for one material in one plant are be combined.

Individual Requirements

A line for individual requirements is created in the availability overview for each sales and distribution document and schedule line. This line contains the order quantity and the number of the document which created the requirement as well as the item number and the requirements class.

Individual requirements have the advantage that the initiating document can be identified (the initiating document is displayed in the availability overview for each requirement).

Collective Requirements

Collective requirements combine several requirements according to the following criteria:

· Plant

· Batch

· Storage location

· Date

· Transaction

· Requirements Class

Collective requirements can either be created daily or weekly. You can also use the checking group to control whether the requirements date for weekly created collective requirements is the Monday of the current week or the Monday of the following week.

In contrast to the individual requirements, the documents initiating the collective requirements cannot be directly identified.However, it can be indirectly determined from the list of orders for the material

In a later release, you will be able to break down collective requirements in the availability overview so that you can directly identify the initiating document for the requirements.

The collective requirements function is useful for dealing with a large volume of sales orders, as you obtain a clearer list of requirements and the system response time is also better.

The system automatically creates individual requirements for transactions which create requirements for special stock (for example, made-to-order stock, returnable packaging, or consignment goods) even if collective requirements have been specified by the checking group in the material master record.

Thanks

G. Lakshmipathi

[Former Member]

Hi Jagadeshwar Reddy,

Concept of availability check is to verify if the stock is available at the time of creation of sales order. If available, when it can be ready for delivery (as Packing, arranging for transportation, etc may have lead time) & if not available, when it would be available considering Packing, arranging for transportation, etc lead time.

Availability check whether material is available on required delivery date (backward scheduling) or not. If not available on required delivery date, system will propose next available date (forward scheduling).

The availability check and transfer of requirements can in principle be controlled independently of one another.When you create a sales document, the transfer of requirements and availability check can be carried out independently. The way in which these are controlled is dependent on th requirements class and schedule line category.

When you create a delivery, the availability check can only be carried out in combination with the transfer of requirements. Requirements, however, can be transferred without the availability check being carried out.

These control elements apply to sales documents and deliveries alike. The procedure and scope of the check can, however, be controlled separately for sales documents and deliveries, so that a different type of availability check is carried out in delivery processing as in sales order processing, for example. In sales documents, you can block order quantity confirmation (for certain delivery blocks), for instance.

For controlling transfer of requirements, you have to carry out the following steps:

1. Each requirement type has to be allocated to one requirement class only.

2. The transfer of requirements must be switched on at requirements class level, the sales documents at schedule line level.

3. You must define a check group. It is possible to have this check group proposed for the initial creation of a material master record.

4. Note that a plant must exist for transfer of requirements to be carried out at document item level.

1. Define Checking Groups

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Define Checking Groups

You define checking groups with which you specify the type of requirements records the system is to create when processing sales orders or deliveries

2. Define Material Block for Other Users

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Define Material Block for Other Users.

3 .Define Checking Groups Default Value

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Define Checking Groups Default Value.

4. Carry out Control for Availability Check

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Carry Out Control for Availability Check.

5. Define Procedure by Requirements Class

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Define Procedure by Requirements Class.

6. Define Procedure for Each Schedule Line Category

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Define Procedure for Each Schedule Line Category.

7. Determine Procedure for Each Delivery Item Category

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Determine Procedure for Each Delivery Item Category.

8. Checking Rule for Updating Backorders

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Checking Rule for Updating Backorders.

9. Define Default Settings

Menu Path: SPRO>SD>Basic Functions>Availability Check and Transfer of Requirements> Availability Check with ATP Logic or Against Planning>Define Default Settings.

Availability checks

1. Availability check is an integral part of the business process that determines if the required delivery quantity can be met on a required delivery date. For this purpose the system takes into account pre-delivery activities such as scheduling for picking or packing times and the time taken to produce or obtain the material. It also performs several background functions such as Backorder processing, rescheduling and ATP quantities.

2. Backorder processing: processing of a sales order that has not been fully confirmed or not confirmed at a certain delivery date.

3. Rescheduling: is a proposal of how – confirmed quantities already assigned to a sales order can be reassigned to other sales orders that have a higher priority.

4. Available to promise (ATP): is a process of checking the available quantities of a material. The ATP quantity consists of warehouse stock + planned receipts (incoming stock) – planned issues (outgoing stock). To examine stock on hand (CO09) proceed to logistics – sales & distribution – sales – environment – availability overview.

5. Replenishment lead time (RLT): is the time taken for the material to become available either internally (in house production) or externally (from a vendor). The most important things to consider during an external procurement are purchasing and MRP 2 (procurement) views of MMR where the processing time for purchasing, planned delivery time and goods receipt processing time are taken into account. On the other hand internal procurement is based on in house production time (MRP 2 view) goods receipt processing time or alternatively RLT time, which is found on MRP 3 view.

6. RLT (Replenishment Lead Time) is the time taken for the material to become available. RLT is only used when doing an ATP check (Available To Promise). The value of RLT for a material is specified on material master record.

7. There are three types of availability checks –

Check on basis of ATP quantities.

Check against product allocation.

Check against planning.

Configuring Availability check through Checking Groups –

1. The checking group + checking rule determine how the availability check is to be performed.

2. The checking group determines whether and how the system checks the stock availability and generates requirements for material planning. The checking group defines what type of requirements will be passed on i.e. summarized requirements (daily/weekly) or individual requirements for each sales order.

3. The checking rule applies to how the availability check is to be carried out at the transaction level. Note that you must define checking rules for each individual application such as for production orders for example. In Sales and Distribution, the checking rule is specified internally within the system and cannot be changed.

4. The checking rule, in conjunction with the checking group, determines the scope of the availability check for every business operation; that is, which stocks, receipts and issues are to be included in the availability check and whether the check is to be carried out with or without the replenishment lead time.

5. Briefly explaining the above – checking group determines which type of requirement to be passed on to MRP whether it be individual or summarized and checking rule which is at the transaction level and can be configured independently for each application module, determines which stocks, receipts and issues to be taken into account. For performing an availability check checking group has to work in conjunction with checking rule.

6. Advantages of individual processing over summarized processing –

Backorder processing is possible.

You can access (MD04) order, line and schedule line individually which gives a greater control on available stock and requirements placed on stock.

The system automatically uses individual requirements in case of special stock items.

7. Required data for the Availability check to be carried out –

The Availability check must be switched on at the requirement class level.

The Availability check must be set at the schedule line level.

A requirements type must exist by which the requirements class can be found.

A plant must be defined in the sales order for each schedule line item (in other words plant must be defined for every material in MMR).

A checking group must be defined in the material master record in the MRP3 screen in the availability check field.

8. Configuring Availability check and defining Checking Groups –

Checking groups are introduced into the sales order based on the setting in the material master record.

SAP standard checking groups are 01 – summarized requirements and 02 – individual requirements or you can create your own by copying the standard ones.

Total sales and total deliveries columns are there to configure a checking rule to sum up requirements to post to MRP either individually or by day or week.

Block quantity required can be set if you want several users to be able to process the material simultaneously in different transactions without blocking each other.

The no check indicator is CHECKED when you DO NOT want the system to carry out ATP check.

9. Defining material block for other users – the block check box is an indicator that enables you to block material master records of a particular material during the availability check and restrict other users from accessing same master record and reserve the material. If the block is not set, two users can confirm the same material at the same time for two different orders, not knowing if the stock is available or not. If you select this field, the material is blocked during the availability check and other users cannot: a) Make changes in the material master record. b) Create purchase orders for the material. C) Create orders for the material.

10. Defining default values for checking groups - Checking groups are introduced into the sales order based on the setting in the material master record.

However if there is no entry present in the material master record for the checking group, a default value can be set here, depending on material type and plant.

This default value will be used by the system depending on the material type mentioned in MMR and plant in sales order.

If an entry exists, this default value is over written by MMR.

11. Controlling Availability Check – in this section, you tell the system what stock on hand and what inward and outward movements of stock it must take into account when performing the availability check in addition to whether or not to consider the replenishment lead time.

12. These settings are based on the checking group that is assigned to the material master record and the checking rule that is predefined and assigned to the sales and distribution transaction.

13. These settings carry out control both for sales order and delivery as well. This is due to the fact that you may want to include specific stock or incoming stock for the sales order, yet at the time of the delivery only include physical stock on hand waiting to be shipped.

14. It is possible to indicate to the system that you would like the availability check NOT TO CHECK the stock at the storage location level. This indicator is used to set the scope of the availability check.

15. It is used to switch off the check at storage location level. You create a reservation for a particular storage location. However, the scope of the availability check is set in such a way as to exclude the storage location. In this case, the system carries out the check at plant level only and does not take the storage location into account that is specified in the reservation.

16. Should you not want the system to automatically check RLT, you may indicate so here. RLT is the time taken for a material to become available. It is only used when doing an ATP check and is taken from MMR.

17. Defining the elements in the availability check entirely depends on the business needs, but a few tips are given under –

When controlling the Availability check at the time of the sales order, a purchase requisition does not necessarily indicate by it is going to come into the plant.

A shipping notification on the other hand - a confirmed purchase order – is a good indicator of receiving stock on a specified date.

It is always recommended not to select the shipping notifications for the delivery requirements type as you may not actually receive the stock into plant or warehouse for which you are creating a delivery.

TRANSFER OF REQUIREMENT:

Controlling the Transfer of Requirements in Sales and Distribution Documents Locate the document in its SAP Library structure

Essentially, the same control elements are used for the transfer of requirements as are used for the availability check.

The following control elements are of significance:

• Requirements type

• Requirements Class

• Checking group

• Schedule line category

For further information on these control elements which are also important for the availability check, see Controlling the Availability Check in Sales and Distribution Processing.

Prerequisites

Transfer of requirements can be performed if the following prerequisites have been met:

• The control elements described above must be maintained in Customizing for Sales and the relevant assignments made to the sales transactions

• The transfer of requirements must be switched on at requirements class level and, in the case of transfer of requirements in the sales documents, at schedule line level

• A plant must be defined at document item level. This plant is either proposed from the material master record or you can enter it manually

• 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

When the transfer of requirements is switched on at requirements class level, it can be switched off at schedule line level. However, you cannot switch on the transfer of requirements 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. The settings for the requirements class are proposed at schedule line level.

Settings for the transfer of requirements specific to schedule lines are only relevant for sales documents. In the shipping documents, the settings for the requirements class apply. The requirements class is determined from the requirements type of the material.

Please go through the link given below

http://72.14.235.104/search?q=cache:qGdEmTcS6LgJ:help.sap.com/printdocu/core/Print46c/en/data/pdf/SD...Transferofrequirementandavailabilitycheck&hl=en&ct=clnk&cd=3

Please Reward If Really Helpful,

Thanks and Regards,

Sateesh.Kandula

[Former Member]

HI Jagadeshwar Reddy

CREDIT MANAGEMENT

Credit and risk management takes place in the credit control area. According to your corporate requirements, you can implement credit management that is centralized, decentralized, or somewhere in between.

An organizational unit that represents the area where customer credit is awarded and monitored. This organizational unit can either be a single or several company codes, if credit control is performed across several company codes. One credit control area contains credit control information for each customer.

For example, if your credit management is centralized, you can define one credit control area for all of your company codes.

If, on the other hand, your credit policy requires decentralized credit management, you can define credit control areas for each company code or each group of company codes.

Credit limits and credit exposure are managed at both credit control area and customer level. You set up credit control areas and other data related to credit management in Customizing for Financial Accounting. The implementation guide is under Enterprise Structure -> Definition or Assignment -> Financial Accounting and then Maintain credit control area. You assign customers to specific credit control areas and specify the appropriate credit limits in the customer master record.

Settings for determining the credit control area of a document. The settings of items 1 - 4 are taken into account according to their priority. The credit control area found is stored in field VBAK-KKBER.

1. Transaction OB38

Check which credit control area is assigned to the company code.

Company code:

Credit control area:

2. Transaction OVFL

Check which credit control area is assigned to the sales area.

Sales area:

Credit control area:

3. Transaction XD02 or VD02

Check which credit control area is assigned to the payer.

Payer:

Credit control area:

4. Transaction SE37

Is user exit EXIT_SAPV45K_001 being used?

5. Transaction OBZK

For the settings under items 2 - 4, field "All company codes" must be marked in Transaction

OB45, or the credit control area must be entered under the relevant company code in table

T001CM of the credit control areas allowed.

Company code:

Credit control areas allowed:

6. Settings for the credit checks

7. Transaction OVAK

Which settings do exist for the sales document type used?

Sales document:

Check credit:

Credit group:

8. Transaction OVAD

Which settings do exist for the delivery type used?

Delivery type:

Credit group for delivery:

Credit group for goods issue:

9. Transaction OB01

Credit management/Change risk category

Definition of the risk category for each credit control area. This risk category can be

assigned to a credit account by using Transaction FD32.

10. Transaction OVA8

Here, the individual credit checks for key fields

o credit control area

o risk category

o credit group are set. Take these key fields from the above settings and go to the detail

screen. In particular, check whether fields "Reaction" and "Status/block" are set

correctly. To carry out follow-up actions in case of a credit block, the credit check

status must be set (field "Status/block").

11. Transaction FD32

Credit master data for the payer of the relevant document.

Credit account:

Credit limit:

Risk category:

Currency:

12. Settings for updating the credit values Update of the credit values is required for the limit

check (static or dynamic credit limit check).

13. Transaction OVA7

Update of the credit value is active for the corresponding item type if the check box is marked. This field corresponds to

field "Active receivable" in Transaction VOV7.

Item type:

Active receivable:

14. Transaction V/08, Pricing

In the pricing procedure used for pricing, subtotal "A" must be entered in a line for

determining the credit value (mark the pricing procedure and doubleclick on "Control").

Usually, the net value plus taxes is used. This way the system is determined to use this

subtotal for credit pricing. The credit price is stored in field VBAP-CMPRE and used for

update and credit check.

You can find the used pricing procedure of the order under "Item -> Condition -> Analysis".

Pricing procedure:

Line with subtotal = 'A':

15. Transaction OB45

Which update group (field "Update") do you use in the relevant credit control area? The

default setting is "12". If you use another update group, check whether this is fine with

you. If you open an OSS message, please tell us the alternative update group.

Credit control area:

Update:

16. Transaction OMO1

Which kind of update did you choose for structure S066?

In any case, "Synchronous update (1)" has to be chosen as the kind of update.

All other settings will lead to errors.

Reward if useful to u