IMG Settings for SAP FI Credit Management

Explain credit control area and why do we create them. 

The Credit Control Area is an organizational unit that represents an area responsible for granting and monitoring credit. Credit information can be made available per customer within a credit control area.  One will use one credit control area that is four characters “JHEN”.  All of the available functionality for credit management will not be used since a service has already been provided. 

Stopping the billing process is not an option Organizational unit in an organization that specifies and checks credit limits for customers. A credit control area can include one or more company codes. It is not possible to assign a company code to more than one credit control areas.  Credit and risk management takes place in the credit control area. 

4.6x

OB45 - Maintain Credit Control Area 
A company code can be assigned to one credit control area.  However, a credit control area can be assigned to more than one company code.

OB38 - Assign Company Code to Credit Control Area. 
If your company have different business area, you can assign each with a Credit Control Area.  e.g.  0001 for BA-A, 0002 for BA-B, 0003 for BA-C etc.  In this case, the same customer master code can have different credit limits for the different Business Area.

OB01 - Define Credit Risk Categories.

OB02 - Define Account Clerk Groups

OB51 - Define Credit Representatives

OB39 - Define Intervals for Days in Arrears for Credit Management

Credit Limit Check & its configuration

Follow these steps:

1. Go to IMG - enterprise structure - definition - financial accounting - define credit control area.

2. Assignment of company code to credit control area & sales area to credit control area.

3. Go to OVAK select ur sales document type and in the check credit column choose from A B or C. D is for automatic credit control for which you have to maintain the credit group and risk categories.

4. In FD32 you select your customer and click on STATUS icon and press enter. here u maintain the credit amount allowed. but this is done by the Finance people.

5. Now when you create the sales order and if the amount exceeds the credit limit then u will get the message as you maintained in the TC OVAK.  Normally the system starts doing credit checks from the second sales. 
order. 
 

What are the different types of credit checks?

By Sunilmadho

Credit Check can be : 
1) Simple Credit Check 
2) Automatic Credit Control

Automatic Credit Control can be at various levels : 
1) Order 
2) Delivery 
3) Goods Issue

Automatic Credit Check is of many types : 
1) Static 
2) Dynamic 
3) MaximumDocument Value 
4) Maximum Open Items in percentage 
5) Oldest Open Item in number of days 
6) Crtitical fields change 
7) Highest dunning level, etc. 
You can create more.

Credit Check happens only in SD module, never in FI. Because the stage of the check is in the sales cycle, which exists in SD. FI guys will check the credit master sheets of the customer, the MIS, the analysis etc, review the credit limits of customers. But the check will happen only in SD, while creating order, delivery or doing the goods issue.

Difference Between Static and Dynamic Credit Check

Tell me the difference between Static and Dynamic Credit Checks.  
What is the difference between the Open Order Value used in Static check and the one used in Dynamic Check?

*Simple Credit Check :* Tr.Code - FD32

It Considers the Doc.Value + Open Items.

Doc.Value : Sales Order Has been saved but not delivered

Open Item : Sales Order has been saved , Delivered, Billed & Transfered to FI, but not received the payment from the customer.

*Static Credit Check* it checks all these doc value & check with the credit limit

1) Open Doc.Value / Sales Order Value : Which is save but not delievered

2) Open Delivery Doc.Value : Which is delivered but not billed

3) Open Billing Doc.Value : Which is billed but not posted to FI

4) Open Item : Which is transfered to FI but not received from the customer.

*Dynamic Credit Check*         1) Open Doc 
                                                   2) Open Delivery 
                                                   3) Open Billing 
                                                   4) Open Items 
                                                   5) Horizon Period = Eg.3Months

Here the System will not consider the above 1, 2, 3 & 4 values for the lost 3 months.          

Useful SAP Credit Management program

RVKRED06 - Background jobs for checking blocked credit management. 
If an order is no longer outside the horizon as defined in the dynamic credit check, (i.e. it is INSIDE the horizon) it can cause existing "good" orders to block. If you run this job every night, if you have your horizon set for 1 month it can cause a lot of blocks at beginning of month. Try to use 'W' for weekly horizon status.

RFDKLI10 - Customers With Missing Credit Data

RFDKLI20 - Reset Credit Limit for Customers

RVKRED77 - Reorganize SD credit data 
When updating errors occur, it enables you to reorganize the open credit, delivery and billing document values.

RVKRED08 -  Checking sales documents which reach the credit horizon 
You should runs this report periodically, usually at the start of a period. The report checks all the sales documents, which reach the dynamic credit check horizon. The period for the ‘date of the next credit check’ is proposed from the current date, with the help of the period split for open sales order values.

Releasing the Credit Block

These are the three transaction code you can used for releasing the SAP credit management block.

VKM3 - Sales Order

VKM5 - Delivery Order

VKM4 - Both Sales Order and Delivery Order

SAP SD Credit Management Tcodes

All business have their own credit management needs, SAP allows you to 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 the system carries out these checks.

SM30 - Table/View

• V_TVTW - Define Distribution Channel
• V_TVTA_KKB - Assign sales area to credit control area
• V_T014 - FI - Define Credit Control Area
• T001CM - FI - Assign Permitted Credit Control Area to company code

OVXG - Set up Sales Areas 
e.g.  Sales Organization 
                  Distribution Channel 
                              Division 
                  Distribution Channel 
                              Division

FD32 - Customer Credit Management

OVAK - Define credit limit check by sales document type

• Check Credit
• A - Credit limit check and warning message
• B - Credit limit check and error message (no sales order can be created)
• C - Credit limit check and delivery block (block delivery if hit credit limit)
• Options B and C -> used for checking open order values (when you create/change the sales order)
• D - Automatic credit control with open order values
• More control in transaction OVA8 - Automatic credit control
• You check for open orders and deliveries, or just open deliveries.
• or open order values with other options
• Credit group
• Allows you to combine different sales document types for the credit limit check

VKM1 - Blocked SD Documents - Finance have to released the delivery block

OVAD - Define credit limit check by delivery order

• whether the automatic credit check occurs at the time of delivery creation and/or goods issue

OVA7 - Define credit limit check by item category

• Set whether to include/exclude item category for credit limit check

OVA6 - Define credit group. You can groups together different business transactions which should be dealt with in the same manner with regard to the credit check.
You enter the credit groups when you configure the sales document types for credit management and define the (D - automatic credit check).

• SAP default credit groups
• 01 - credit group for sales order
• 02 - credit group for delivery
• 03 - credit group for goods issue

OVA8 - Automatic credit control - Double click on the line items

You can have the followings credit limit check :-

• Static

Depends on the customer total value of open orders, deliveries, billing documents and open items. 
 
• Open items

No of days open 
Overdue open items checks is based on the ratio of open items that are overdue by a certain number of days.

Max open items % 
The customer balance must not exceed a certain percentage. 
 

• Oldest open items

If you don't want to deliver to the customer at all when even only 1 invoice is overdue. 
Tick the Check for Oldest Open Item and Set the field Days oldest item = 1.

Days oldest item 
No of days allowed for overdue or payment terms.

Use of the credit check Oldest Open Item. If a user attempts to alter the order quantity of a released sales document 
that was previously blocked, it would be reblocked again by the system.  The system only reblocks the sales document if the new order quantity is above a certain % amount.

• Released documents are still unchecked

The preset % is whatever you want to set it as when configuring your automatic credit processing. You enter a deviation % and number of days,eg, you can set it so that an order can be changed by up to 10% within 30 days of original order entry date without it going back on credit block. 
 
• Next Review Date

If a customer has a credit limit of 1000 USD, and you would like to restrict this credit limit only to be available in current month (say March). If the document day is in April then the credit limit is zero.

You can use the "NextReview date" and "Number of days" fields and combined it with the "Last int.review" field in customer credit master "Status"view (FD32).

VOKR - Display of work list for credit management (configure the display variant)

Dunning Process In Credit Management

Explain about dunning process in credit management?

Let me explain in simple terms:

1) You have a Customer which you had felt, he is doing good business and supplied material on Credit of 45 days.

2) Since this customer is good as you felt, you have not managed Credit Checks as well. So, he had comfortably reached to the fullest credit (or even more) which you can afford for any customer.

3) One fine day you got realised that, there is very bad debt with this customer and need to recover from him and till then, there will be no further supply to the customer.

4) Your company's legal department has laid a policy that, inorder to recover any bad debts, like: 
a) We will send a normal payment reminder. 
b) In case customer doesnt respond, we will send at least further reminder (dunning notice) may be 9 times  
    (9 reminders) (Dunning level) and what intervels of time (dunning frequency)  
c) Still if the customer doesnt resopond for the reminders, you will file a law suit against the customer for recovering 
    the Payments. 
d) Finally, after getting veridict, you may proceed for auction of his property or as per the order for Law.

Now in SAP, the definition of Dunning procedure is a pre-defined procedure specifying how customers or vendors are dunned.

For each procedure, the user defines 
- Number of dunning levels  
- Dunning frequency  
- Amount limits  
- Texts for the dunning notices 

In SAP, you will maintain the Dunning Procedure at customer master.  Referring to this your SD Team / FI Team (user team) will effect Dunning

PS: You might remembered the dunning procedure laid by Relaince Mobile, sometime back, sending street rowdies for recovering the bad debts from users. That is dunning. Remember Reliance, you will not forget dunning forever.

Set Up for Credit Card Payment Processing

Given below is the set up for credit card payment processing:

Set Up Credit Control Areas:

Define Credit Control Area 
Transaction: OB45  
Tables: T014 
Action: Define a credit control area and its associated currency.  The Update Group should be ‘00012’.  This entry is required so the sales order will calculate the value to authorize

Assign Company Code to Credit Control Area 
Transaction: OB38 
Tables: T001 
Action: Assign a default credit control area for each company code

Define Permitted Credit Control Area for a Company 
Code 
Transaction:  
Tables: T001CM 
Action: For each company code enter every credit control area that can be used

Identify Credit Price 
Transaction: V/08 
Tables: T683S 
Action: Towards the end of the pricing procedure, after all pricing and tax determination, create a subtotal line to store the value of the price plus any sales tax.  Make the following entries: 
Sub to:  “A” 
Reqt:  “2” 
AltCTy:  “4”

Automatic Credit Checking 
Transaction: OVA8 
Tables: T691F 
Action: Select each combination of credit control areas, risk categories and document types for which credit checking should be bypassed.  You need to mark the field “no Credit Check” with the valid number for sales documents.

Set Up Payment Guarantees

Define Forms of Payment Guarantee 
Transaction: OVFD 
Tables: T691K 
Action: R/3 is delivered with form “02” defined for payment cards.  Other than the descriptor, the only other entry should be “3” in the column labeled “PymtGuaCat”

Define Payment Guarantee Procedure 
Transaction:  
Tables: T691M/T691O 
Action: Define a procedure and a description.  
Forms of Payment Guarantee and make the following entries Sequential Number  “1”  
Payment Guarantee Form “02” 
Routine Number   “0”    Routine Number can be used to validate payment card presence.

Define Customer Payment Guarantee Flag 
Transaction:  
Tables: T691P 
Action: Define a flag to be stored in table.  
Create Customer Payment Guarantee = “Payment Card Payment Cards (All Customers can use Payment Cards)”.

Define Sales Document Payment Guarantee Flag 
Transaction:  
Tables: T691R 
Action: Define the flag that will be associated with sales document types that are relevant for payment cards

Assign Sales Document Payment Guarantee Flag 
Transaction:  
Tables: TVAK 
Action: Assign the document flag type the sales documents types that are relevant for payment cards.

Determine Payment Guarantee Procedure 
Transaction: OVFJ 
Tables: T691U 
Action: Combine the Customer flag and the sales document flag to derive the payment guarantee procedure

Payment Card Configuration

Define Card Types 
Transaction:  
Tables: TVCIN 
Action: Create the different card types plus the routine that validates the card for length and prefix (etc…)  
Visa , Mastercard, American Express, and Discover  
Create the following entries for each payment card  
AMEX  American Express ZCCARD_CHECK_AMEX Month 
DC  Discover Card  ZCCARD_CHECK_DC  Month***** 
MC  Mastercard  ZCCARD_CHECK_MC  Month 
VISA  Visa   ZCCARD_CHECK_VISA  Month

The Routines can be created based on the original routines delivered by SAP. 

*****SAP does not deliver a card check for Discover Card. We created our own routine.

Define Card Categories 
Transaction:  
Tables: TVCTY 
Action: Define the card category to determine if a 
payment card is a credit card or a procurement card. 
Create the following two entries 
Cat Description  One Card  Additional Data 
CC Credit Cards  No-check  No-check 
PC Procurement Cards No-check  Check

Determine Card Categories 
Transaction:  
Tables: TVCTD 
Action: For each card category map the account number range to a card category.  Multiple ranges are possible for each card category or a masking technique can be used.  Get the card number ranges from user community.  Below is just a sample of what I am aware are the different types of cards. 

Visa Credit  Expires in 7 days.  
    400000   405500 
    405505   405549 
    405555   415927 
    415929   424603 
    424606   427532 
    427534   428799 
    428900   471699 
    471700   499999 
 Visa Procurement  Expires in 7 days. 
    405501   405504 
    405550   405554 
    415928   415928 
    424604   424605 
    427533   427533 
    428800   428899 
 Mastercard Credit Expires in 30 days 
    500000   540499 
    540600   554999 
    557000   599999 
 Mastercard Procurement Expires in 30 days 
    540500   540599 
    555000   556999

 American Express Credit Expires in 30 days 
    340000   349999 
    370000   379999

 Discover Card Credit Expires in 30 days 
    601100   601199

Set Sales Documents to accept Payment Card Information Transaction:  
Tables: TVAK 
Action: Review the listing of Sales Document types and enter “03” in the column labeled “PT” for each type which can accept a payment card

Configuration for Authorization Request

Maintain Authorization Requirements 
Transaction: OV9A 
Tables: TFRM 
Action: Define and activate the abap requirement that determines when an authorization is sent.  Note that the following tables are available to be used in the abap requirement (VBAK, VBAP, VBKD, VBUK, and VBUP).

Define Checking Group 
Transaction:  
Tables: CCPGA 
Action: Define a checking group and enter the 
description.  Then follow the below guidelines for the remaining fields to be filled. 
AuthReq Routine 901 is set here. 
PreAu  If checked R/3 will request an authorization for a .01 and the authorization will be flagged as such. (Insight does not use pre-authorization check). 
A horizon This is the days in the future SAP will use to determine the value to authorize 
(Insight does not use auth horizon period). 
Valid  You will get warning message if the payment card is expiring within 30 days of order entry date. 

Assign Checking Group to Sales Document 
Transaction:  
Tables: TVAK 
Action: Assign the checking group to the sales order types relevant for payment cards

Define Authorization Validity Periods 
Transaction:  
Tables: TVCIN 
Action: For each card type enter the authorization validity period in days.

AMEX American Express 30 
DC Discover card  30 
MC Master card  30 
VISA Visa   7

Configuration for clearing houses

Create new General Ledger Accounts 
Transaction: FS01 
Tables:  
Action: Two General Ledger accounts need to be created for each payment card type.  One for A/R reconciliation purposes and one for credit card clearing.

Maintain Condition Types 
Transaction: OV85 
Tables: T685 
Action: Define a condition type for account determination and assign it to access sequence “A001”

Define account determination procedure 
Transaction: OV86 
Tables: T683 / T683S 
Action: Define procedure name and select the procedure for control.  Enter the condition type defined in the previous step.

Assign account determination procedure 
Transaction:  
Tables: 
Action: Determine which billing type we are using for payment card process.

Authorization and Settlement Control

Transaction:  
Tables: TCCAA 
Action: Define the general ledger accounts for reconciliation and clearing and assign the function modules for authorization and settlement along with the proper RFC destinations for each.

Enter Merchant ID’s 
Transaction:  
Tables: TCCM 
Action: Create the merchant id’s that the company uses to process payment cards

Assign merchant id’s 
Transaction:  
Tables: TCCAA 
Action: Enter the merchant id’s with each clearinghouse account.

Difference Between Simple and Automatic Credit Check Types

Explain in detail difference between simple and automatic credit check types.  In automatic check, difference between static and dynamic checks.

SIMPLE CREDIT CHECK : Tr.Code - FD32

It Considers the Doc.Value + Open Items.

Doc.Value : Sales Order Has been saved but not delivered 

Open Item : Sales Order has been saved , Delivered, Billed & Transfered to FI, but not received the payment from the customer. 

Eg: Customer Credit Limit is  Rs.1,00,000/- 
      Suppose Doc.Value + Open Item Value is Rs.1,10,000/-

Here credit limit exceeds then system reacts.

Options : A) Warning Message 
          B) Error Message (Sales Order won't be saved) 
          C) Error Message with Delivery Block  
   
AUTOMATIC CREDIT CHECK : Give extra credit facilities to the particular customer.

STATIC CREDIT LIMIT DETERMINATION :Checking Group + Risk Catageory + Credit Control Area. 
  
A) Credit Checking Groups : Types of Checking Groups.

  01) Sales 
  02) Deliveries 
  03) Goods Issue 
At all the above 3 levels orders can be blocked.

B) Risk Catageory : Based on the risk catageories company decide how much credit has to give to the customer.

HIGH RISK (0001) : LOW CREDIT 
LOW RISK  (0002) : MORE CREDIT 
MEDIUM RISK(0003) : Average Credit  

Static Credit Check it checks all these doc value & check with the credit limit

1) Open Doc.Value / Sales Order Value : Which is save but not delievered

2) Open Delivery Doc.Value : Which is delivered but not billed

3) Open Billing Doc.Value : Which is billed but not posted to FI

4) Open Item : Which is transfered to FI but not received from the customer.

DYNAMIC CREDIT CHECK : 1) Open Doc 
                                                   2) Open Delivery 
                                                   3) Open Billing 
                                                   4) Open Items 
                                                   5) Horizon Period = Eg.3Months

Here the System will not consider the above 1,2,3& 4 values for the lost 3 months

Then assign the Sales Doc & Del Documents.

Sales Doc.Type(OR) + credit Check(0) + Credit Group (01)

Credit Limit Check for Delivery Type : Del.Type (LF) + Del Credit  
Group  (02) + Goods Issue Credit Group (03)

Sales value field in not getting updated after creating the billing

Subject: Sales value field in not getting updated after creating the billing

we are on 4.6b. we are going for credit management but facing one problem. in fd32- 
customer credit management change - the sales value feild in not getting updated after 
creating the billing.  
eg. when i create the order - the order value get updated in the sales value in fd32. after 
creating the delivery - that value remains same in the feild of sales value. but when i am 
going for billing (delivery related), the bill value is appearing in 'receivables' but the amount 
in 'sales value' is not getting reduced. because of this the credit exposure is increasing 
continuously.  
update group for corrosponding credit ctrl area is 12. also the item is mark for credit 
update.  
can anyone tell the missing link?  
thanking in advance 

A*You need to check couple of settings like: 

1. Your customer should be assigned the credit control area. 

2. In your Item Category Credit should be active. 

Q*customer is assign to concorn CCA and item category is mark for credit active

A*Check the credit update group in the transaction OB45. The credit update group controls 

when the values of open sales orders, deliveries and billing documents are updated. It 
should be '000012'. 

Further also refer to the OSS note 18613. 

Credit Mgmt Dynamic checking

Does anyone know how I can automatically re-execute a dynamic credit check a few days prior to shipment for future dated sales orders. Any ideas would be appreciated. 

Program RVKRED08? Or manually execute function module SD_ORDER_CREDIT_RECHECK.

We check credit at the time of the delivery (at delivery creation and before picking) and use the blocked sales doc process/list to release them. This can be set up in customizing under risk management-> credit management. 

MRP block for Credit limit attained Customers

How to block the requirement (MD04) generated by the item category in a sales order when the customer has attained the credit limit?  The MRP requirements still appear even though the schedule is zero.

You should try and use one of the standard requirements. 

See in transaction "VOFM". 

Under Requirements / Subsequent Functions / Reqs.Availablity. 

Try using routine 103, you may have to tweak if it doesn't work exactly as you'd like. 

For example, you can write a routine 903 because you only wanted this reaction for certain business units. Irregardless, using a routine similar to this will prevent the requirement from appearing in MD04 for orders blocked on credit. 

Code:  
DATA: W_ZSDCRD TYPE ZSD_CREDITBLCK.  
DATA: W_CMGST LIKE VBUK-CMGST. 

SELECT SINGLE * INTO W_ZSDCRD  
FROM ZSD_CREDITBLCK  
WHERE KKBER = VBAK-KKBER  
AND CTLPC = VBAK-CTLPC. 

IF SY-SUBRC = 0 AND VBUK-CMGST CA 'B'. 

IMPORT VBUK-CMGST TO W_CMGST FROM MEMORY ID 'CREDIT'. 

IF W_CMGST = SPACE.  
MESSAGE I706(Z1).  
EXPORT VBUK-CMGST TO MEMORY ID 'CREDIT'.  
ENDIF.  
 

*} REPLACE  
*{ INSERT DEVK966908 1 

*} INSERT  
* Read the subsequent function information for the message  
PERFORM FOFUN_TEXT_READ USING GL_FOFUN  
CHANGING FOFUN_TEXT.  
MESSAGE ID 'V1' TYPE 'E' NUMBER '849'  
WITH FOFUN_TEXT  
RAISING ERROR.  
*{ INSERT DEVK966908 2 

*} INSERT  
ENDIF.  
ENDFORM. 

How To Do Configuration For 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.

Tips by : Kapilaa

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.