Update group '18' will be always used by order items that are not relevant for delivery (for example, service items or value items) or for items that are billed as order-related (for example, for billing plans). In the following cases update group 18 is always set dynamically as opposed to the update group of the credit control area. This ensures that, in the case of these exceptions, the update occurs in the open delivery values (S067) and not in the open order values (S066). The update group is determined in the program LMCSBF10 in the form KREDIT_AKTIV:
1. Debit memo request: In the debit memo check, the items are not relevant for delivery and are billed as order-related. The customer has already received the goods to be billed - therefore, they have already been delivered. The order value is updated in the open delivery values.
2. Third-party order processing: You do not make a delivery to a third-party item yourself (item type TAS in the standard SAP system). The delivery is made by a third party. Therefore, you have no further influence on the delivery. The order value is also updated in the open delivery values.
3. Order items with billing plan: Billing according to the billing plan is order-related billing. The order values are also updated in the open delivery values.
4. Further examples are value items and service items for which there is no supply and which are also billed as order-related.
You can find further information about this in Note 361637.
Sales order is credit blocked, it has confirmed quantity and it updates the open credit values
Skip to end of metadata
Created by Former Member on Nov 24, 2014
Go to start of metadata
Symptom
Sales order is credit blocked, VBUK-CMGST = B;
Standard requirement 101 is used for the follow-on function 'Reqs/availability';
Even though the confirmed quantity is not deleted;
The system writes an open credit value for these items despite the credit block.
Analysis
The condition 101 for the follow-on function requirement/availability is not valid for items that are not relevant for requirements and therefore are not MRP-relevant. How you can determine this, you can read HERE.
In case of a non-MRP material where the availabilty check is deactivated, the system does not remove the confirmed quantity if there is a credit block (VBUK-CMGST = 'B').
If transfer of requirements is simultaneously active in item Customizing (read HERE how you can check), the system writes an open credit value for these items (S066-OEIKW) despite of the credit block.
Please read also SAP Note: 674112 - Updating of credit values in spite of credit block
Sales order item is rejected, however an open credit value is updated for this item
Skip to end of metadata
Created by Former Member on Dec 13, 2014
Go to start of metadata
Symptom
You set a reason for rejection.
You want to bill the item as order-related (for example, FKREL = B).
In Customizing for the reason for rejection, the indicator "Not relevant for billing" (TVAG-FK_ERL) is not set
Analysis
The indicator "Not relevant for billing" (TVAG-FK_ERL) in the reason for rejection decides whether or not the order item should still be billed despite the reason for rejection. If you still want to bill the order item despite the reason for rejection, an open credit value must be updated for this item. Technical background: If you still want to bill an order item despite the reason for rejection, the billing status of the item is set to "to be billed". This status is checked in credit management if a decision is made as to whether or not an open credit value should be updated for the order item. Exceptions: If the rejected item is already delivered, the open credit values can no longer be reset. This is the case, for example, in the returns process if the customer receives a replacement and the returns are not billed for this reason. Run the correction report RVKRED77 to reduce the credit values for these completed documents correctly.
Solution
Use a different reason for rejection for which the indicator "Not relevant for billing" (TVAG-FK_ERL) is set.
SAP Note 393830 - Updating open credit values with reason for rejection
Pages
…
Credit value update problem
Skip to end of banner
Go to start of banner
UPDKZ modification
Skip to end of metadata
Created by Former Member on Jul 23, 2015
Go to start of metadata
Problem
You determined that there are inconsistent credit values in the system. How this can be done you can read here: General GUIDE for inconsistencies
Analysis
In most of the cases the wrong updates are caused by customer modification of the field UPDKZ in userexits.
The aim is to explain the logic of the statistic updates for credit values. How the credit value is calculated you can read here: Credit value calculation of a document How the credit value is updated you can read here: How does the credit update work How the credit value calculation can be debugged you can read here: How to debug credit value calculation
Statistic tables for credit management (S066 and S067) are automatically updated when you create and change sales documents. The statistics are not updated until the end of the update.
During the update of statistics, the status before the data change is always compared with the status after the data change. If there is a change, an entry is generated in the change documents. To perform this comparison (old data - new data), two internal tables are used. The first internal table contains the entry before the change; the second internal table contains the entry after the data change. Both internal tables are managed for the following database tables, among others: KONV, VBAP, VBEP, VBKD, VBLB, VEDA, FPLA, FPLT. Here, the naming of the two internal tables is always the same: Table that contains the new entries: X + database name, for example, XVBAP. New means: Status after the change. Table that contains the old entries: Y + database name, for example YVBAP. Old means: Status before the change or data as it is on the database.
How are the internal tables filled? The internal X tables are filled as follows: 1. In the VAx1 when you enter data 2. In the VAx2 / VAx3 when the document is imported (that is, VAx2/3, entry of document number, Enter). The internal Y tables are not filled until changes are made in the document. The data record before the change (as it was saved on the database) is included in the Y table. That is, if an entry exists in the Y table, this entry was changed beforehand. You can find the 'unchanged' version of the data record in the Y table and the 'changed' version of the data record in the X table. A Y entry is also generated if a data record, for example an item or a schedule line, was deleted (however, the document must have been saved beforehand). The Y tables are not filled in the transactions VAx1. The update of the statistics only works without errors if the entries of the Y tables match the entries of the X tables and contain the correct entries. If the Y table contains too many entries (for example, items that were not changed), then errors also occur in the update.
How can I check if the entries in the X and Y tables are correct? To do this, you must determine whether an entry in an X table was changed or deleted (an entry is generated in a Y table only if this is the case). Since the X tables are also used for updating data, the database must be informed for each entry of what should happen with the entry: if it must be added, changed or deleted. Therefore, each entry in an X table has a particular indicator (field UPDKZ) that informs the database how the entry should be processed on the database.
The indicator UPDKZ can have the following values:
' ' - the entry should not be changed on the database. 'U' (update) - the existing database entry should be updated with the newly determined values. 'I' (INSERT) - the entry should be included again in the database. 'D' (DELETE) - the entry should be deleted from the database.
However, since entries in the Y table are generated only if something was changed or deleted, only the update indicators 'U' and 'D' are relevant for the Y table. That is, an entry in an X table with an update indicator U or an update indicator D must have a corresponding entry in the related Y table. The Y table must not contain an entry that does not have an update indicator 'U' or 'D' in the X table. For the correct update of statistics, the entry must be included in the Y table once; however, a correct update indicator must also be maintained in the Y table. However, the Y tables recognize only the update indicators ' ' and 'D'.
The update indicators of the X and Y tables correspond as follows: Update indicator of X table Update indicator of Y table 'U' ---> ' ' 'D' ---> 'D' This assignment must be correct to avoid errors in the statistics.
All this happens before the update task is called (with commit work). So only in very rare cases it is needed to swith update debugging on for credit value statistic update as already beforehand it is possible to check the X- and Y-tables.
The call of the update task is characterized by the COMMIT command. This happens in the program MV45AF0B_BELEG_SICHERN (for sales documents). The breakpoint for the analysis needs to be set before to the command COMMIT or COMMIT WORK.
The UPDKZ modification is done mostly in the PERFORM USEREXIT_SAVE_DOCUMENT_PREPARE or PERFORM USEREXIT_SAVE_DOCUMENT. Set the breakpoints on these rows. After the breakpoint is set, the transaction must be called again and executed. For that always an example is needed to recreate the same wrong behaviour. Please read more about this here: Example needed to recreate the wrong update and identify the root cause The system only stops at the breakpoint after the Save button has been pressed (but before the data is transferred to the database). When you reach the breakpoint, you can proceed as follows: - Choose the "Table" pushbutton. - Enter the table name of the X table or the Y table (in this case the relevant tables for credit value calculation are: X-YVBAP, X-YVBEP) - Enter UPDKZ as the first field name. - Compare the entries of the X and Y tables and find the incorrect or missing entry. - Using a watchpoint, check to see where the incorrect entry was generated.
In the most common case UPDKZ is modified in a userexit by changing the UPDKZ field for the X-table to 'U' without adding an entry to the Y-table.
You can also check if problem caused by the userexit by skippping them in debugging:
set a breakpoint in MV45AF0B_BELEG_SICHERN to perform USEREXIT_SAVE_DOCUMENT and perform USEREXIT_SAVE_DOCUMENT_PREPARE
recreate the problem by executing the same steps which leads to a wrong update and press the Save button
system stops at the breakpoints, set your cursor to the next executable line and
skip these exits during debugging (release dependent) without executing them: Menu: Debugging-> Control-> Goto statement or Menu: Debugging-> Goto statement
press F8 or 'Exit debugging' so document can be saved (make sure it is a testsystem or document is allowed to be saved in the production system!)
if the update problem does not occur without these exits, you can search further in the exits itself where UPDKZ is modified (goto SE38: MV45AFZZ -> search for the field UPDKZ)
also bear in mind that there are enhancement points in the system available which also can be used for modifications, in this case you might set a watchpoint to the UPDKZ fields of the X-tables to find where the incorrect entry was generated.
Please read SAP Notes 178328 and 208010 and review your userexits, especially MV45AFZZ and for LE please see note 415716 - User exits in delivery processing.
There is an analysis tool also available with regard to userexit modification effects on credit values, please see following notes and ensure all related notes are implemented too:
1606681 - Analysis tool reg. modification effects on credit values 1612842 - Error analysis with regard to modifications to credit values
VL_COMPLETE does not reduce the open delivery credit values
Skip to end of metadata
Created by Former Member on Dec 04, 2014
Go to start of metadata
Symptom
You are using transaction VL_COMPLETE to technically close old deliveries (set status to "complete")
After processing the delivery you expect the open delivery value to be reduced, but it isn't
Solution
When you complete a delivery with transaction VL_COMPLETE, it is standard behaviour that the open delivery credit values will not be reduced in this case. After completing a delivery with transaction VL_COMPLETE - which updated credit values previosly in the process - you have to run report RVKRED77 to ensure consistency of your credit data.
Normally, when an order is created, the credit values are updated to open sales order values (S066-OEIKW). When the delivery is created, they are moved to open delivery credit values (S067-OLIKW). When the delivery is billed, the open delivery credit values are reduced and moved to open billing document credit values (S067-OLIKW).
More about this you can read HERE.
When you complete a delivery with transaction VL_COMPLETE, no invoice will be created which can reduce the open delivery credit value. So the open delivery credit value remains. Therefore in this case it is necessary to run report RVKRED77.
Therefore use transaction VL_COMPLETE only in exceptional cases.
Check SAP Note 992587 - Manually closing completed deliveries which gives further information about VL_COMPLETE and its limitiations.
Also read KBA 1969447 - Wrong Update in S067 Structure - VL_COMPLETE
Different credit control area (KKBER) is determined than expected
Skip to end of metadata
Created by Former Member on Jan 12, 2015
Go to start of metadata
Symptom
The credit control area is wrongly determined in the sales document.
Analysis
With the following steps you can determine the root cause:
Use report CHECK_CM as starting point. This report displays all credit management relevant information for particular documents. Please read here about the usage of this report. The credit control area which was determined at the time of sales order creation can be seen in the 'Settings for Credit Check ' part (VBAK-KKBER). You can see the field either in green colour or in red:
When report CHECK_CM is executed, function module SD_DETERMINE_KKBER runs in the background and compares the credit control area from the sales document with the current customizing settings (active at the time of check_cm execution). Green means that the credit control area which was determined at the time of sales order creation (VBAK-KKBER) matches with the actual customizing setting of the credit control area determination. Red means: since the sales order creation the customizing setting for credit control area determination was changed as with current date a different credit control area would be determined.
You would like to know how the credit control area was determined in the sales order. The credit control area found during sales order processing is stored in the field VBAK-KKBER. The system determines the credit control area from these sources in the following order from the lowest possible assignment level to the highest level:
User exit -> TransactionSE37: EXIT_SAPFV45K_001 (CALL FUNCTION 'EXIT_SAPFV45K_001')
Payer's master record -> Transaction XD02 or VD02: Sales area data, Billing documents tab under Delivery and payment terms, check which credit control area is assigned to the payer (I_KKBER_KNVV)
*Remark: this field can be set as invisible in customer master customozing. If you can not see the field Credit ctrl area, go to transaction OB20 -> Display Customer (Sales) -> Sales -> Billing -> Hedging and credit contr. area
Sales area -> Transaction OVFL: check which credit control area is assigned to the sales area (PERFORM TVTA_SELECT)
Company code of the sales organization -> Transaction OB38: Check which credit control area is assigned to the company code (I_KKBER_T001) If system finds a credit control area in one of the assignments, it does not process further and sets the credit control area accordingly. For this the function module SD_DETERMINE_KKBER is called. If you would like to debug, you need to set a breakpoint here. Determination logic in the coding:
Solution
Credit control area determination is done only at the time of sales order creation, when you enter the header data information. This credit control area is copied to the subsequents documents (delivery, invoice) to ensure data consistency.
If you change the customizing setting for credit control area determination, this can be seen in report CHECK_CM also with red colours. This change you would like to reflect in existing sales documents. For that you need to run report RFDKLI20.
Also in case you change the payer in a sales order, you get mesage: V1677 "Credit data will not be redetermined". This might be the case when already subsequent document (i.e. delivery) exists for the sales order. The credit data are not redetermined, as already subsequent documents for this sales order do exist. Redeterming credit data for already delivered sales orders would result in inconsistency. If you nevertheless want to use the credit control area according to the new settings, report RFDKLI20 must be run.
Please read here in which cases RFDKLI20 might not update sales documents.
Further information you can find also in these SAP Notes: 355242 - Determination of Credit Control Area 18613 - Checklist for Credit Management 408596 - RFDKLI20: Recreating credit data - new documentation
Credit active flag (CMPNT) is deactivated in customizing, but sales documents still update the credit values
Skip to end of metadata
Created by Former Member on Jan 13, 2015
Go to start of metadata
Symptom
Credit active flag (CMPNT) was active in item category customizing
Sales documents were already created with this setting
Credit active flag (CMPNT) was deleted in the customizing
OR the opposite case
Credit active flag (CMPNT) was not active in item category customizing
Sales documents were already created without this setting
Credit active flag (CMPNT) was set in the customizing
Solution
The credit active flag (CMPNT) is filled only at the time of item creation of a sales order. After that it is not possible to change it anymore (except when item category is changed to a different one and changed it back). Also this is copied to the subsequent documents to ensure credit data consistency through the whole document flow.
You can check the existing documents - if CMPNT is present in the document or not - by using report Check_cm. More about this you can read HERE.
If you change the customizing setting for this field and you have existing open documents where you would like to reflect this change, you have following possibilities:
1. Write your own report in order to change VBAP-CMPNT in the old documents. In such a case you need to ensure data consistency in all of the subsequent documents also. But to set CMPNT for active won't update itself the credit values.
2. Set a reason for rejection in the old document items in order to delete its value from the info structures. Afterwards, you can create a new item in the old document and this new item will not update the open credit values since the item category is not credit active any longer.
3. Change the item category than change it back to the original one, in this case the customizing is read again.
All this can be done only after you deleted the subsequent documents.
Report RFDKLI20 is also not compatible with this change. More on this you can read HERE and in note 546734.
Credit release – ATP confirmed schedule line quantity
Skip to end of metadata
Created by Former Member on Jul 09, 2015
Go to start of metadata
Problem
You release a sales order from the credit block and then cannot explain the confirmed quantities in the sales order.
Solution
When a credit block occurs, the confirmed quantities are set to zero. After the sales order is released from credit block, another availability check takes place: the ATP check is performed in background. Here the availability screen cannot be performed, so you have to tell the system, whether to choose the delivery proposal, one-time delivery or full delivery. This is done in transaction OVZJ depending on the header organizational data. If your availability checking rule in OVZJ is blank, during the ATP check (when credit released), the system chooses the full delivery. If there is not enough stock to confirm the whole quantity, so the full delivery is not possible and therefore the system confirms zero. If you set the rule to 'E', then you will get the delivery proposal.
Credit release – ATP confirmed schedule line quantity
Skip to end of metadata
Created by Former Member on Jul 09, 2015
Go to start of metadata
Problem
You release a sales order from the credit block and then cannot explain the confirmed quantities in the sales order.
Solution
When a credit block occurs, the confirmed quantities are set to zero. After the sales order is released from credit block, another availability check takes place: the ATP check is performed in background. Here the availability screen cannot be performed, so you have to tell the system, whether to choose the delivery proposal, one-time delivery or full delivery. This is done in transaction OVZJ depending on the header organizational data. If your availability checking rule in OVZJ is blank, during the ATP check (when credit released), the system chooses the full delivery. If there is not enough stock to confirm the whole quantity, so the full delivery is not possible and therefore the system confirms zero. If you set the rule to 'E', then you will get the delivery proposal.
How is Sales value determined in FD33 (KNKK-SAUFT)
Skip to end of metadata
Created by Former Member on Nov 26, 2014
Go to start of metadata
Symptom
In transaction FD33 the sales value is displayed correctly, but on database level for table KNKK, the field SAUFT is blank.
When sales order is created, FD33 sales value is updated, but the table KNKK-SAUFT isn't.
Solution
When you call the transaction FD33, the displayed sales values are dynamically calculated from the info structures S066 and S067. That's why the field SAUFT in table KNKK is always zero.
Every time FD33 is entered, the sales value is determined newly, this happens here:
SAPMF02C -> MF02CFE0 - ERMITTELN_SAUFT:
Open orders = S066-OEIKW
Open delivery = S067-OLIKW
Open bill.docu = S067-OFAKW
I do not have any FD33 master data maintained for credit limit, but sales document is credit checked or blocked
Skip to end of metadata
Created by Former Member on Nov 26, 2014
Go to start of metadata
Symptom
Sales document is blocked by credit, but credit limit is not maintained / deleted.
No credit master data is maintained in FD33, but sales document is blocked.
Analysis
Please check if there is a 'Default data for automatically creating new customers' maintained:
This means following:
1. If you create a new customer, by saving a credit master data is also directly created with the default values from the credit control area (KNKK-record); 2. You create an order for a customer to whom there is no credit master data. If default values are in the determined credit control area defined, these are used instead of the not existing credit master data in order to execute the credit check.
Please read following SAP Notes related to this topic:
SAP Note 338486 - Credit check despite non-existing credit master SAP Note 425643 - Automatic creation of a credit master record f new SAP Note 674076 - Credit management master data for new customer
I need a different credit account than the payer
Skip to end of metadata
Created by Former Member on Nov 26, 2014
Go to start of metadata
Symptom
Different credit account is needed than the payer.
Different partner function is needed for the credit management than the payer.
Solution
In SD Credit Management it is not possible to have a different partner function, i.e. Ship-to than the payer as all the processes works with the payer function, all reports, credit value updates rely on this. Also there is no userexit available for this, as it is a complex process which can not be influenced only at one place.
In Credit management the credit account (KNKK-KNKLI) is used for all checks, reports, credit updates. This is derived from the payer. There is a possibility to use a different credit account, so called alternative credit account.
This is done in transaction FD32 -> Menu: Edit - Change credit account
The system always updates the open credit values for the credit account (KNKK-KNKLI). Example 1:
You create a sales order for the payer CUST_B.
For the payer CUST_B, the credit customer CUST_A is defined as the credit account (KNKK-KNKLI = CUST_A) in the credit master data.
For the credit customer CUST_A, credit master data must already exist.
The sales order with the payer CUST_B has an open credit value of EUR 10,000.00.
The system updates the open credit value of EUR 10,000.00 for the credit customer CUST_A (S066-KNKLI = 'CUST_A').
In the credit master data, the system displays the open sales value for the customer CUST_B as EUR 0.00.
In the credit master data for the customer CUST_A, the system now displays an open sales value of EUR 10,000.00.
Example 2:
You create a second sales order, this time, for the payer CUST_A.
In the credit master data of the payer, the payer is defined as the credit account (KNKK-KNKLI = CUST_A). This is the default value when you create the credit master data.
The sales order has an open credit value of EUR 2,000.00.
The system updates the open credit value of EUR 2,000.00 for the credit customer CUST_A (S066-KNKLI = 'CUST_A').
In the credit master data for the customer CUST_A, the system now displays an open sales value of EUR 12,000.00.
Referenced SAP Note: 886235 - Alternative credit account: Updating open credit values
Update Groups in Credit Management
Skip to end of metadata
Created by Gerard Magorrian on Oct 06, 2013
Go to start of metadata
Purpose
This document helps clarify the affects of update groups on the update infostructures in credit management.
Overview
When following the open credit values in credit mangement it is not always clear if the figures a consistent. A better understanding of what infostructures are involved and which update groups are used is necessary for breaking down the total credit exposure.
Infostructures in Credit Management
Structure S066 contains existing/previous update on open ‘sales order values’ for each customer credit account
Structure S067 contains existing/previous update on open delivery or billing doc values for each customer credit account.
Updating with structures S066 and S067 is hard-coded and is not controlled by normal Information Structures. The customizing is based on settings in transaction OB45:
It also relates to the Billing relevance of the item as specified in the Item category settings of transaction VOV7:
Note: The delivery document posts updates to S067 despite of being in credit block. This behavior is somewhat different to the sales, where in the case of a credit block refrains from updating info structures S066/S067.
Update Groups
12 - Open order value on time axis, delivery and bill.doct value (click for more info) Updates S066-OEIKW, S067-OLIKW and S067-OFAKW; i.e. standard order processing
15 - Open delivery and billing document value (click for more info) Updates S067-OLIKW and S067-OFAKW; i.e. orders without schedule lines
18 - Open delivery value for sales order, open billing doct value (click for more info) Updates S067-OLIKW and S067-OFAKW; third party order processing
Related Content
Related Documents
Related Notes
361637 - Update of open delivery values in the order 377165 - Update open credit values for credit management
Update Group 12 - Open order value on time axis, delivery and bill.doct value
Skip to end of metadata
Created by Gerard Magorrian on Oct 06, 2013
Go to start of metadata
Purpose
This document is to help explain the actions carried out by the system when using update group 12 in Credit Management.
Overview
When a Sales Order document is created an entry is generated in S066 for the credit value of the document. Once this sales order is delivered the S066 entry is cleared and a new value is generated for the ‘Open delivery value’ in S067. At the time of invoicing the delivery a new ‘Open billing value’ will be generated within S067 and the preceding ‘Open delivery value’ removed. Later, when the Billing document is completed and posted to Finance it too is cancelled out and the value forwarded on as an ‘Open item value’ in FI.
Updating credit related statistics
VA01 – Create Sales order
Increase S066-OEIKW for delivery-relevant schedule lines
VL01N – Create Delivery
Reduce Open order value (S066-OEIKW) for delivery-relevant schedule lines.
Increase S067-OLIKW ‘Open delivery value’.
VF01 – Create Billing document
Reduce S067-OLIKW ‘Open delivery value’
Increase S067-OFAKW ‘Open billing value’
Create Financial accounting document
Reduce S067-OFAKW ‘Open billing value’
Increases open items in FI
Related Content
Related Documents
IMG Help - Credit update for open order/delivery/billing document value
Related Notes
361637 - Update of open delivery values in the order 377165 - Update open credit values for credit management
Update Group 15 - Open delivery and billing document value
Skip to end of metadata
Created by Gerard Magorrian on Oct 06, 2013
Go to start of metadata
Purpose
This document has been created to help explain the actions carried out by the system when using update group 15 in Credit Management.
Overview
With this update type no postings are made to S066 ‘Open order value’ as the order is placed after the delivery is created. Update 15 used for orders without schedule lines – service items or orders with schedule lines that are not relevant for delivery.
Updating credit related statisics
VL01N – Create Delivery
Increases open delivery value - S067-OLIKW
VF01 – Create Billing document
Reduces open delivery value in S067
Increases open invoice value - S067-OFAKW
Create Financial accounting document
Reduce S067-OFAKW ‘Open billing value’
Increases open items in FI
Related Content
Related Documents
IMG Help - Credit update for open order/delivery/billing document value
Related Notes
361637 - Update of open delivery values in the order 377165 - Update open credit values for credit management
Update Group 15 - Open delivery and billing document value
Skip to end of metadata
Created by Gerard Magorrian on Oct 06, 2013
Go to start of metadata
Purpose
This document has been created to help explain the actions carried out by the system when using update group 15 in Credit Management.
Overview
With this update type no postings are made to S066 ‘Open order value’ as the order is placed after the delivery is created. Update 15 used for orders without schedule lines – service items or orders with schedule lines that are not relevant for delivery.
Updating credit related statisics
VL01N – Create Delivery
Increases open delivery value - S067-OLIKW
VF01 – Create Billing document
Reduces open delivery value in S067
Increases open invoice value - S067-OFAKW
Create Financial accounting document
Reduce S067-OFAKW ‘Open billing value’
Increases open items in FI
Related Content
Related Documents
IMG Help - Credit update for open order/delivery/billing document value
Related Notes
361637 - Update of open delivery values in the order 377165 - Update open credit values for credit management
Update group was changed in the customizing and the credit values are incorrect
Skip to end of metadata
Created by Former Member on Jan 20, 2015
Go to start of metadata
Symptom
Update group of the credit control area was changed in transaction OB45;
After this the open credit values are incorrect
Solution
The values should be adjusted after the change.
If only the update group of the credit control area was changed, you have two option to adjust the credit values:
1. Carry out report RFDKLI20 or the reorganization in transaction FD32 or
2. Carry out report RVKRED77 first to correct open credit values and then carry out reportRVKRED09 to trigger the credit checks in the documents again.
SAP Note: 562763 - Change of the update group in OB45
When changing payer in the sales order, got error message VP 237 - Credit limit customer differs from the credit customer in header
Skip to end of metadata
Created by Former Member on Nov 07, 2014
Go to start of metadata
Case 1: Changing payer at header level
In VA01, you create an order with payer 'A' at header and item level. Now in VA02, go to Header/ Partners. You can change the payer without any problem. This new payer will be automatically copied into the items.
Case 2: changing payer at item level
In VA01, you create an order with payer 'A' at header and item level. Now in VA02, go to Item/ Partners. If you try to change the payer at item level, you get error VP 237- "Credit limit customer differs from the credit customer in header". If you enter again payer 'A' manually, the flag "Partner valid at item level" is set. Now go to Header/ Partner. If you try to change the payer to a payer different from 'A', you also get error message VP 237. Error message VP 237 is displayed after pressing enter, not when saving the order. This is the standard system behaviour.
Conclusion:
Changing payer has to be done on the order header (provided that in transaction VOPA, payer has the flag "not changeable" off in "sales document header") but not on item level. If you do this on item level, error message VP 237 is given because it is not allowed to have different payers on header and item level if credit management is active. The only way to have different payers at header and item level in a sales order is by assigning a common "credit account" to both payers. To do this: for example you have payer 'A' and payer 'B'. In FD32, payer A has credit account (KNKK-KNKLI)= Test. Go to FD32 and enter payer 'B'. Go to "Edit/ Change credit acount" and enter the same credit account as payer 'A', that is, enter KNKK-KNKLI= Test. Save. Now, since both payers have the same credit account, you will be able to have different payers at header and item level in the sales orders. Without having the same credit account for both payers, you would get error message VP 237.
Also see this:
SAP Note: 370573 - No alternative payer possible at item level
When changing payer in the sales order, got the message V1677 - Credit data will not be redetermined
Skip to end of metadata
Created by Former Member on Nov 12, 2014
Go to start of metadata
In case you change the payer in a sales order, you get mesage: V1677 "Credit data will not be redetermined". This might be the case when already subsequent document (i.e. delivery) exists for the sales order. The credit data are not redetermined, as already subsequent documents for this sales order do exist. Redeterming credit data for already delivered sales orders would result in inconsistency. If you nevertheless want to use the credit control area according to the new settings, report RFDKLI20 must be run.
Please read here in which cases RFDKLI20 might not update sales documents.
Problem with credit management reports and programs
RFDKLI20
RVKRED06
RVKRED09
RVKRED77 and RVKRED88
VKM1-5 transactions
Pages
…
Problem with credit management reports and programs
Skip to end of banner
Go to start of banner
RFDKLI20
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
What kind of problem do you face?
RFDKLI20 does not update new credit master data in SD documents
I changed the payer in the sales order but the credit account did not change
FD32 or RFDKLI20 dumps with TIME_OUT
Sorting of RFDKLI20 is not correct - Logic of the report
Termination with message V1316 - Sales area is not defined
RFDKLI20 does not perform a new check for critical fields
FD32 or RFDKLI20 dumps with TIME_OUT
Skip to end of metadata
Created by Former Member on Nov 07, 2014
Go to start of metadata
When you maintain the credit limit an FD32 and save it, automatic reorganization takes place. Since the relevant partner function in the credit management is the payer, all open sales documents for a payer are selected for the reorganization. The selection is performed within function module SD_CREDIT_RECREATE, which is called from both Transaction FD32 and report RFDKLI20. The documents are selected according to one of the two following options:
1. Partner index VAKPA: The relevant documents are selected via partner index VAKPA. In index table VAKPA, the system updates all SD documents for a customer number in dependency on the partner function. All documents for a payer can be determined using index table VAKPA. CAUTION: Partner index VAKPA is only updated if the corresponding partner functions and transactions are activated in Customizing table TINPA. Table TINPA does not provide any update for the payer partner function in the standard system. 2. Document table VBPA: If the update for the payer is not active in table TINPA, the relevant documents are selected via application table VBPA. Table VBPA contains the used partners (customer numbers) for SD documents. The access to table VBPA with the customer number of the payer requires a long runtime because the customer number is not a key field in table VBPA. It might result in a TIME_OUT.
There are two possible solutions for runtime problems in Transaction FD32 or with report RFDKLI20: 1. Activate the update of index table VAKPA for the payer partner function: Activate the update of index table VAKPA for the payer partner function by creating an entry with transaction = 0, partner function = RG in table TINPA. You can use Transaction SM31 for that. Subsequently, a reorganization of index table VAKPA is absolutely required. You can execute the reorganization with report RVV05IVB. Note that all existing SD documents thus also those ones already closed are indexed again by this report. Depending on the number of your documents in the system, this can result in a runtime which is correspondingly long. Therefore test this beforehand in a copy of your production system.
2. Create a database secondary index for table VBPA: If a reorganization of index table VAKPA is not possible or not wanted, you can optimize the access via document table VBPA. For that, create a database secondary index for table VBPA. We cannot provide a general recommendation on how you have to define the secondary index in detail. This basically depends on your dataset. Use the SQL trace with Transaction ST05 in order to analyze the access onto table VBPA within function module SD_CREDIT_RECREATE. Then define a suitable database secondary index for table VBPA according to your analysis results. For example, you could create the secondary index for VBPA fields KUNNR and PARVW. Test the new secondary index by creating an SQL trace with Transaction ST05 again in order to check the effectiveness of the database access and the runtime.
Also with note 99937 you can avoid the automatic reorganization - and thus runtime problems - in Transaction FD32. BUT note that this does not solve the runtime problem during the reorganization in general, but shifts it to RFDKLI20 which you can schedule as a job. Thus, you are not disturbed by the runtime problem. For customers with many SD documents with which you already received a runtime error, you should no longer perform the changes to the SD documents online and instead schedule report RFDKLI20 as a job for the re-creation of SD data. Please start the program RFDKLI20 as background job and see the result. Other option would be if you want to execute this job oline, you can increase the system profile parameter "rdisp/max_wprun_time".
Also please read this notes: SAP Note: 705317 - Performance credit master data (FD32) and RFDKLI20 SAP Note: 99937 - Credit Management: Runtime error TIME_OUT
I changed the payer in the sales order but the credit account did not change
Skip to end of metadata
Created by Former Member on Nov 26, 2014
Go to start of metadata
Symptom
You changed the Payer in the document from 'A' to 'B'. When the partner data is changed in a sales document, the credit data is not redetermined automatically. So the credit account (field VBAK-KNKLI) has still the "old" value, also the credit values remain for this account.
Solution
In order to redetermine the "new" credit account for these affected documents, you will need to run report RFDKLI20, see note 408596. This report rebuilds the credit data after making organizational changes. Every document for the selected customers will be updated with regard to their credit data within an internal VA02. This means the document will be read, the credit data will be changed and then saved again. That means also the credit values of these documents will be updated to the "new" account, as if you would change the order within VA02.
Please read also: RFDKLI20 does not update new credit master data in SD documents
RFDKLI20 does not update new credit master data in SD documents
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Change of the credit account (KNKLI): You change the credit account in FD32. You want to reflect this change in the existing sales documents, but after executing RFDKLI20, nothing changes. Report RFDKLI20 updates only SD documents that are still open or that contain open documents in their document flow. If a document and all its subsequent documents are completed (overall processing status VBUK-GBSTK = 'C'), this document is no longer updated by report RFDKLI20. This applies generally for all change in the master data.
Change of the risk category (CTLPC): Sales orders that were not updated by report RFDKLI20 (because they are completed together with their subsequent documents) can be re-edited in Transaction VA02 so that they are open again. For example, this is the case if you add a new item or increase the quantity in an existing item. During the credit check for these documents, the system re-reads an alternative risk category (VBAK-CTLPC) from the credit master data (KNKK-CTLPC). This only applies to the risk category and not to a changed credit control area or to other changed credit master data! Caution: If you have not changed anything except the risk category, you can actually use the RFDKLI20 report, but it is too large for this purpose. If you only change the risk category, the RVKRED09 report is sufficient.
Settings that change the determination of the credit control area (KKBER): You change the customizing of the credit control area determination. More about the determination itself you can read here. Only open documents are updated or that contain open documents in their document flow. Caution: You have removed the assignment of the credit control area for a company code in the Customizing. You then run the RFDKLI20 report to write this change into the open documents. The RFDKLI20 report does not delete the credit control area from the open documents as expected. The RFDKLI20 report cannot "delete" the credit control area from documents. Also in case you change the payer in a sales order, you get mesage: V1677 "Credit data will not be redetermined". This might be the case when already subsequent document (i.e. deliveryI exists for the sales order. The credit data are not redetermined, as already subsequent documents for this sales order do exist. Redeterming credit data for, already delivered sales orders would result in inconsistency. If you nevertheless want to use the credit control area according to the new settings, report RFDKLI20 must be run.
Credit active flag change in the item category (CMPNT): Changes in field "Credit funct. active" (CMPNT) from the Customizing for the item category (Transaction VOV7) are ignored during the recreation of the credit data after organizational changes (report RFDKLI20). Therefore field CMPNT cannot be affected anymore in existing documents. A change of field CMPNT concerns all new documents. A consistent change of field "Credit funct. active" in the existing documents is not compatible with the existing logic of RFDKLI20 for technical reasons.
Documents that are excluded by RFDKLI20: For the reorganization of SD data, the report RFDKLI20 calls the function module SD_CREDIT_RECREATE. The function module selects the SD documents for the credit customers. Depending on the setting in your system, the documents are selected according to one of the following two options. A) Selection using the index table VAKPA: This selection is used if you have activated the order update (TRVOG = '0') for the payer function (c= 'RG') in the table TINPA B) In all other cases, the original table VBPA is selected.
When the index table VAKPA is used for the selection, scheduling agreements are excluded from the reorganization. Contracts that are relevant for billing are also excluded, for example, service contracts with billing plan. In this case, no solution is available in the standard SAP system. You can create your own report to select the scheduling agreements and execute the reorganization. In all other cases for contracts read note 439085.
Please read following notes related to this:
SAP Note: 408596 RFDKLI20: Recreating credit data - new documentation SAP Note: 370022 RFDKLI20: Not all documents are updated SAP Note: 915368 RFDKLI20: Credit control area not removed SAP Note: 439085 RFDKLI20 does not update contracts SAP Note: 1080446 RFDKLI20: Scheduling agreements excluded SAP Note: 546734 RFDKLI20: Changes in "Credit funct. active" ignored SAP Note: 510034 - Changing the risk category in Transaction FD32
Sorting of RFDKLI20 is not correct - Logic of the report
Skip to end of metadata
Created by Former Member on Nov 07, 2014
Go to start of metadata
You are not sure about in which sequence report RFDKLI20 process the documents, also would like to know more about the logic of the report.
The relevant Function module is SD_CREDIT_RECREATE.
First the documents are selected according to one of the two following options: