A) 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.
In the coding - SD_CREDIT_RECREATE:
... SELECT SINGLE * FROM tinpa * Lieferpläne bleiben im Moment unberücksichtigt -->> read here which documents are exluded by the VAKPA selection WHERE trvog EQ '0' AND parvw EQ 'RG'. IF sy-subrc EQ 0. SELECT * FROM vakpa WHERE kunde EQ kunnr AND parvw EQ 'RG'. IF NOT vbeln IS INITIAL. CHECK vakpa-vbeln EQ vbeln. ENDIF. SELECT SINGLE * FROM vbak WHERE vbeln EQ vakpa-vbeln.
B) 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. Further on this you can read here.
In the coding - SD_CREDIT_RECREATE: ...
ELSE. SELECT * FROM vbpa WHERE posnr EQ '000000' AND kunnr EQ kunnr AND parvw EQ 'RG'. SELECT SINGLE * FROM vbak WHERE vbeln EQ vbpa-vbeln. IF sy-subrc EQ 0. CLEAR da_kkber.
2. After that credit control area (KKBER) is determined:
Credit control area of the document will be cleared, as it is a re-organisation report, so after a possible customizing change it needs to be redetermined again. Note 408596 says also: "You must execute this report after the following changes: General changes concerning SD and FI: Settings that change the determination of the credit control area: assignment from company code, entry in the customer master data, entry in the sales area data, user exit."
Logic of the report is that first credit control area of the sales order is determined, just as it would be done at the time of sales order creation. SAP Note 355242: The system determines the credit control area from these sources in the following order: o User exit - > CALL FUNCTION 'EXIT_SAPFV45K_001' o Payer's master record > PERFORM knvv_read o Sales area > PERFORM tvta_select o Company code of the sales organization > t001-kkber
... CLEAR da_kkber. * read table TVKO PERFORM tvko_read USING vbak-vkorg CHANGING sav_bukrs. * read table T001 PERFORM t001_read USING sav_bukrs. CALL FUNCTION 'EXIT_SAPFV45K_001' EXPORTING ivbak = vbak ivbkd = vbkd CHANGING da_kkber = da_kkber. IF NOT da_kkber IS INITIAL. CALL FUNCTION 'FI_CM_CHECK_COMP_CONTROLAREA' EXPORTING i_bukrs = t001-bukrs i_kkber = da_kkber EXCEPTIONS not_allowed = 1. IF sy-subrc NE 0. CLEAR da_kkber. ENDIF. ENDIF. * credit-control area from knvv IF da_kkber IS INITIAL. MOVE 'X' TO vtcom-msgkz. "keine Meldungen PERFORM knvv_read USING kunnr vbak-vkorg vbak-vtweg vbak-spart CHANGING rc. IF rc IS INITIAL AND NOT knvv-kkber IS INITIAL. da_kkber = knvv-kkber. ENDIF. ENDIF. * credit-control area from TVTA IF da_kkber IS INITIAL. PERFORM tvta_select USING vbak-vkorg vbak-vtweg vbak-spart CHANGING rc. IF rc NE 0. MESSAGE e316(v1) WITH vbak-vkorg vbak-vtweg vbak-spart. ENDIF. IF NOT ( tvta-kkber IS INITIAL ). da_kkber = tvta-kkber. ENDIF. ENDIF. * read table TVAK IF vbak-auart NE tvak-auart. SELECT SINGLE * FROM tvak WHERE auart EQ vbak-auart. ENDIF. * credit-control area from t001 IF da_kkber IS INITIAL. da_kkber = t001-kkber. ENDIF.
3. Status of the documents is checked:
Once the credit control area could be determined for the sales order from the customizing, it is compared with the entered credit control area in the selection screen. If there are the same, than the status of the sales order is checked. If the sales order is completed, than the document flow is checked, if there are open sales documents in the flow. Please see note 370022: 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. More on this you can read here.
... IF da_kkber EQ kkber AND ( NOT t014-stafo IS INITIAL OR tvak-klimp EQ 'D' ). SELECT SINGLE * FROM vbuk WHERE vbeln EQ vbak-vbeln. IF sy-subrc EQ 0 AND NOT vbuk-gbstk CA 'C'. MOVE vbak-vbeln TO orders-vbeln. APPEND orders. ELSEIF sy-subrc EQ 0. SELECT * FROM vbfa WHERE vbelv EQ vbak-vbeln. CHECK vbfa-vbtyp_n CA vbtyp_lief OR ( vbfa-vbtyp_n CA vbtyp_fakt AND vbfa-vbtyp_n NA vbtyp_prof AND vbfa-vbtyp_n NA vbtyp_fkiv ). SELECT SINGLE * FROM vbuk WHERE vbeln EQ vbfa-vbeln. IF sy-subrc EQ 0 AND vbuk-gbstk CA 'AB'. MOVE vbak-vbeln TO orders-vbeln. APPEND orders. IF VBFA-VBTYP_N CA VBTYP_LIEF. MOVE vbfa-vbeln TO deliveries. APPEND deliveries. ELSE. MOVE vbfa-vbeln TO invoices. APPEND invoices.
4. The documents are sorted and only after this the document is "touched" and entered in internal mode:
Sorting is by document number. In this sequence the orders get rechecked, beginning with the smallest document number. Then i.e. during the static credit check for each order the following is happening: The system takes the credit exposure from the database. If the checked order was credit approved before, the credit value of this order is already included in the credit exposure. If the order was credit blocked before, this value is added to the credit exposure for the credit check. This credit exposure value is then compared to the credit limit. If it is higher, the order is credit blocked, if it is lower, it is credit released.
... SORT orders BY vbeln. DELETE ADJACENT DUPLICATES FROM orders. LOOP AT orders. ON CHANGE OF orders-vbeln. CALL FUNCTION 'SD_CREDIT_RECREATE_ORDER'
... SORT deliveries BY vbeln. DELETE ADJACENT DUPLICATES FROM deliveries. LOOP AT deliveries. ... CALL FUNCTION 'SD_CREDIT_RECREATE_DELIVERY'
... SORT invoices BY vbeln. DELETE ADJACENT DUPLICATES FROM invoices. LOOP AT invoices. ... CALL FUNCTION 'SD_CREDIT_RECREATE_INVOICE'
SAP Note: 408596 - RFDKLI20: Recreating credit data - new documentation
SAP Note: 355242 - Determination of Credit Control Area
SAP Note: 370022 - RFDKLI20: Not all documents are updated
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:
A) 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.
In the coding - SD_CREDIT_RECREATE:
... SELECT SINGLE * FROM tinpa * Lieferpläne bleiben im Moment unberücksichtigt -->> read here which documents are exluded by the VAKPA selection WHERE trvog EQ '0' AND parvw EQ 'RG'. IF sy-subrc EQ 0. SELECT * FROM vakpa WHERE kunde EQ kunnr AND parvw EQ 'RG'. IF NOT vbeln IS INITIAL. CHECK vakpa-vbeln EQ vbeln. ENDIF. SELECT SINGLE * FROM vbak WHERE vbeln EQ vakpa-vbeln.
B) 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. Further on this you can read here.
In the coding - SD_CREDIT_RECREATE: ...
ELSE. SELECT * FROM vbpa WHERE posnr EQ '000000' AND kunnr EQ kunnr AND parvw EQ 'RG'. SELECT SINGLE * FROM vbak WHERE vbeln EQ vbpa-vbeln. IF sy-subrc EQ 0. CLEAR da_kkber.
2. After that credit control area (KKBER) is determined:
Credit control area of the document will be cleared, as it is a re-organisation report, so after a possible customizing change it needs to be redetermined again. Note 408596 says also: "You must execute this report after the following changes: General changes concerning SD and FI: Settings that change the determination of the credit control area: assignment from company code, entry in the customer master data, entry in the sales area data, user exit."
Logic of the report is that first credit control area of the sales order is determined, just as it would be done at the time of sales order creation. SAP Note 355242: The system determines the credit control area from these sources in the following order: o User exit - > CALL FUNCTION 'EXIT_SAPFV45K_001' o Payer's master record > PERFORM knvv_read o Sales area > PERFORM tvta_select o Company code of the sales organization > t001-kkber
... CLEAR da_kkber. * read table TVKO PERFORM tvko_read USING vbak-vkorg CHANGING sav_bukrs. * read table T001 PERFORM t001_read USING sav_bukrs. CALL FUNCTION 'EXIT_SAPFV45K_001' EXPORTING ivbak = vbak ivbkd = vbkd CHANGING da_kkber = da_kkber. IF NOT da_kkber IS INITIAL. CALL FUNCTION 'FI_CM_CHECK_COMP_CONTROLAREA' EXPORTING i_bukrs = t001-bukrs i_kkber = da_kkber EXCEPTIONS not_allowed = 1. IF sy-subrc NE 0. CLEAR da_kkber. ENDIF. ENDIF. * credit-control area from knvv IF da_kkber IS INITIAL. MOVE 'X' TO vtcom-msgkz. "keine Meldungen PERFORM knvv_read USING kunnr vbak-vkorg vbak-vtweg vbak-spart CHANGING rc. IF rc IS INITIAL AND NOT knvv-kkber IS INITIAL. da_kkber = knvv-kkber. ENDIF. ENDIF. * credit-control area from TVTA IF da_kkber IS INITIAL. PERFORM tvta_select USING vbak-vkorg vbak-vtweg vbak-spart CHANGING rc. IF rc NE 0. MESSAGE e316(v1) WITH vbak-vkorg vbak-vtweg vbak-spart. ENDIF. IF NOT ( tvta-kkber IS INITIAL ). da_kkber = tvta-kkber. ENDIF. ENDIF. * read table TVAK IF vbak-auart NE tvak-auart. SELECT SINGLE * FROM tvak WHERE auart EQ vbak-auart. ENDIF. * credit-control area from t001 IF da_kkber IS INITIAL. da_kkber = t001-kkber. ENDIF.
3. Status of the documents is checked:
Once the credit control area could be determined for the sales order from the customizing, it is compared with the entered credit control area in the selection screen. If there are the same, than the status of the sales order is checked. If the sales order is completed, than the document flow is checked, if there are open sales documents in the flow. Please see note 370022: 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. More on this you can read here.
... IF da_kkber EQ kkber AND ( NOT t014-stafo IS INITIAL OR tvak-klimp EQ 'D' ). SELECT SINGLE * FROM vbuk WHERE vbeln EQ vbak-vbeln. IF sy-subrc EQ 0 AND NOT vbuk-gbstk CA 'C'. MOVE vbak-vbeln TO orders-vbeln. APPEND orders. ELSEIF sy-subrc EQ 0. SELECT * FROM vbfa WHERE vbelv EQ vbak-vbeln. CHECK vbfa-vbtyp_n CA vbtyp_lief OR ( vbfa-vbtyp_n CA vbtyp_fakt AND vbfa-vbtyp_n NA vbtyp_prof AND vbfa-vbtyp_n NA vbtyp_fkiv ). SELECT SINGLE * FROM vbuk WHERE vbeln EQ vbfa-vbeln. IF sy-subrc EQ 0 AND vbuk-gbstk CA 'AB'. MOVE vbak-vbeln TO orders-vbeln. APPEND orders. IF VBFA-VBTYP_N CA VBTYP_LIEF. MOVE vbfa-vbeln TO deliveries. APPEND deliveries. ELSE. MOVE vbfa-vbeln TO invoices. APPEND invoices.
4. The documents are sorted and only after this the document is "touched" and entered in internal mode:
Sorting is by document number. In this sequence the orders get rechecked, beginning with the smallest document number. Then i.e. during the static credit check for each order the following is happening: The system takes the credit exposure from the database. If the checked order was credit approved before, the credit value of this order is already included in the credit exposure. If the order was credit blocked before, this value is added to the credit exposure for the credit check. This credit exposure value is then compared to the credit limit. If it is higher, the order is credit blocked, if it is lower, it is credit released.
... SORT orders BY vbeln. DELETE ADJACENT DUPLICATES FROM orders. LOOP AT orders. ON CHANGE OF orders-vbeln. CALL FUNCTION 'SD_CREDIT_RECREATE_ORDER'
... SORT deliveries BY vbeln. DELETE ADJACENT DUPLICATES FROM deliveries. LOOP AT deliveries. ... CALL FUNCTION 'SD_CREDIT_RECREATE_DELIVERY'
... SORT invoices BY vbeln. DELETE ADJACENT DUPLICATES FROM invoices. LOOP AT invoices. ... CALL FUNCTION 'SD_CREDIT_RECREATE_INVOICE'
SAP Note: 408596 - RFDKLI20: Recreating credit data - new documentation
SAP Note: 355242 - Determination of Credit Control Area
SAP Note: 370022 - RFDKLI20: Not all documents are updated
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:
A) 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.
In the coding - SD_CREDIT_RECREATE:
... SELECT SINGLE * FROM tinpa * Lieferpläne bleiben im Moment unberücksichtigt -->> read here which documents are exluded by the VAKPA selection WHERE trvog EQ '0' AND parvw EQ 'RG'. IF sy-subrc EQ 0. SELECT * FROM vakpa WHERE kunde EQ kunnr AND parvw EQ 'RG'. IF NOT vbeln IS INITIAL. CHECK vakpa-vbeln EQ vbeln. ENDIF. SELECT SINGLE * FROM vbak WHERE vbeln EQ vakpa-vbeln.
B) 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. Further on this you can read here.
In the coding - SD_CREDIT_RECREATE: ...
ELSE. SELECT * FROM vbpa WHERE posnr EQ '000000' AND kunnr EQ kunnr AND parvw EQ 'RG'. SELECT SINGLE * FROM vbak WHERE vbeln EQ vbpa-vbeln. IF sy-subrc EQ 0. CLEAR da_kkber.
2. After that credit control area (KKBER) is determined:
Credit control area of the document will be cleared, as it is a re-organisation report, so after a possible customizing change it needs to be redetermined again. Note 408596 says also: "You must execute this report after the following changes: General changes concerning SD and FI: Settings that change the determination of the credit control area: assignment from company code, entry in the customer master data, entry in the sales area data, user exit."
Logic of the report is that first credit control area of the sales order is determined, just as it would be done at the time of sales order creation. SAP Note 355242: The system determines the credit control area from these sources in the following order: o User exit - > CALL FUNCTION 'EXIT_SAPFV45K_001' o Payer's master record > PERFORM knvv_read o Sales area > PERFORM tvta_select o Company code of the sales organization > t001-kkber
... CLEAR da_kkber. * read table TVKO PERFORM tvko_read USING vbak-vkorg CHANGING sav_bukrs. * read table T001 PERFORM t001_read USING sav_bukrs. CALL FUNCTION 'EXIT_SAPFV45K_001' EXPORTING ivbak = vbak ivbkd = vbkd CHANGING da_kkber = da_kkber. IF NOT da_kkber IS INITIAL. CALL FUNCTION 'FI_CM_CHECK_COMP_CONTROLAREA' EXPORTING i_bukrs = t001-bukrs i_kkber = da_kkber EXCEPTIONS not_allowed = 1. IF sy-subrc NE 0. CLEAR da_kkber. ENDIF. ENDIF. * credit-control area from knvv IF da_kkber IS INITIAL. MOVE 'X' TO vtcom-msgkz. "keine Meldungen PERFORM knvv_read USING kunnr vbak-vkorg vbak-vtweg vbak-spart CHANGING rc. IF rc IS INITIAL AND NOT knvv-kkber IS INITIAL. da_kkber = knvv-kkber. ENDIF. ENDIF. * credit-control area from TVTA IF da_kkber IS INITIAL. PERFORM tvta_select USING vbak-vkorg vbak-vtweg vbak-spart CHANGING rc. IF rc NE 0. MESSAGE e316(v1) WITH vbak-vkorg vbak-vtweg vbak-spart. ENDIF. IF NOT ( tvta-kkber IS INITIAL ). da_kkber = tvta-kkber. ENDIF. ENDIF. * read table TVAK IF vbak-auart NE tvak-auart. SELECT SINGLE * FROM tvak WHERE auart EQ vbak-auart. ENDIF. * credit-control area from t001 IF da_kkber IS INITIAL. da_kkber = t001-kkber. ENDIF.
3. Status of the documents is checked:
Once the credit control area could be determined for the sales order from the customizing, it is compared with the entered credit control area in the selection screen. If there are the same, than the status of the sales order is checked. If the sales order is completed, than the document flow is checked, if there are open sales documents in the flow. Please see note 370022: 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. More on this you can read here.
... IF da_kkber EQ kkber AND ( NOT t014-stafo IS INITIAL OR tvak-klimp EQ 'D' ). SELECT SINGLE * FROM vbuk WHERE vbeln EQ vbak-vbeln. IF sy-subrc EQ 0 AND NOT vbuk-gbstk CA 'C'. MOVE vbak-vbeln TO orders-vbeln. APPEND orders. ELSEIF sy-subrc EQ 0. SELECT * FROM vbfa WHERE vbelv EQ vbak-vbeln. CHECK vbfa-vbtyp_n CA vbtyp_lief OR ( vbfa-vbtyp_n CA vbtyp_fakt AND vbfa-vbtyp_n NA vbtyp_prof AND vbfa-vbtyp_n NA vbtyp_fkiv ). SELECT SINGLE * FROM vbuk WHERE vbeln EQ vbfa-vbeln. IF sy-subrc EQ 0 AND vbuk-gbstk CA 'AB'. MOVE vbak-vbeln TO orders-vbeln. APPEND orders. IF VBFA-VBTYP_N CA VBTYP_LIEF. MOVE vbfa-vbeln TO deliveries. APPEND deliveries. ELSE. MOVE vbfa-vbeln TO invoices. APPEND invoices.
4. The documents are sorted and only after this the document is "touched" and entered in internal mode:
Sorting is by document number. In this sequence the orders get rechecked, beginning with the smallest document number. Then i.e. during the static credit check for each order the following is happening: The system takes the credit exposure from the database. If the checked order was credit approved before, the credit value of this order is already included in the credit exposure. If the order was credit blocked before, this value is added to the credit exposure for the credit check. This credit exposure value is then compared to the credit limit. If it is higher, the order is credit blocked, if it is lower, it is credit released.
... SORT orders BY vbeln. DELETE ADJACENT DUPLICATES FROM orders. LOOP AT orders. ON CHANGE OF orders-vbeln. CALL FUNCTION 'SD_CREDIT_RECREATE_ORDER'
... SORT deliveries BY vbeln. DELETE ADJACENT DUPLICATES FROM deliveries. LOOP AT deliveries. ... CALL FUNCTION 'SD_CREDIT_RECREATE_DELIVERY'
... SORT invoices BY vbeln. DELETE ADJACENT DUPLICATES FROM invoices. LOOP AT invoices. ... CALL FUNCTION 'SD_CREDIT_RECREATE_INVOICE'
SAP Note: 408596 - RFDKLI20: Recreating credit data - new documentation
SAP Note: 355242 - Determination of Credit Control Area
SAP Note: 370022 - RFDKLI20: Not all documents are updated
Pages
…
RVKRED06
Skip to end of banner
Go to start of banner
No new check for critical fields
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
You have activated the "critical fields" credit check. This check blocks a sales order. You carry out a new credit check for this document:
In Transaction VKM1, VKM3 or VKM4, you call the "Check" or "Reassign" function.
You change the sales order in Transaction VA02 and save the document.
You use the RVKRED06, RVKRED08 or RVKRED09 programs to carry out a new check.
When the credit data is reorganized, either by the RFDKLI20 report or directly from the credit master data (Transaction FD32), this causes the system to carry out a new check on the selected documents.
In all cases, if the "critical field" check caused the credit block, this check is not carried out again. The document remains blocked, even if you have changed the customer master data or the document data in the meantime, and the critical fields in the document and the master data correspond once more.
Solution
This is the standard system behavior. The "critical field" credit check is excluded from the "Check" or "Reassign" function and the new credit check. A document that has been blocked by this check can only be released by the credit release.
Reason
When the system carries out the "critical field" check, it not only checks for critical field differences between the customer master data and the document, but also checks subsequent changes to the critical fields in the document. When you carry out a new check after the system has blocked a document because of the critical fields, it is therefore not sufficient to simply compare the document data with the master data.
Modification solution
If you still want the system to carry out a new "critical field" check when it is rechecking documents, you can implement the modification proposal from Note 805007. The modification is not valid for a new credit check in Transaction VA02. For more information about this, see Note 170183.
SAP Note: 805007 - New check: Critical fields
Report RVKRED06
Skip to end of metadata
Created by Former Member on Dec 19, 2014
Go to start of metadata
Purpose
This session will give you the basic steps to run the report-RVKRED06 (Background)
Overview
The Report-RVKRED06 is a Credit Management report which is run in the background .
It Checks Incoming payments And based on the availability of sufficient funds it releases the credit block .
RVKRED06
The behaviour of RVKRED06 is the following:
This report checks all blocked documents from a credit point of view.
It should be started in the background after incoming payments.
It redetermines the credit status in the background, for example from
B to A (VBUK-CMGST). But it doesn´t release the documents, that is, the status
changes to A (approved --if at all there is credit available) but not to D (released).
The report RVKRED06 picks up all credit blocked sales orders and puts them
into the internal table first. Then, within a loop, each order will be credit checked
and saved. The order is blocked for another check if it is not approved.
The RVKRED06 will not execute the credit check for the already
released sales orders. Another possibility might be a modification
Please follow the below steps to run the Report- RVKRED06 :
1. Go To the Transaction SE38
2. Enter RVKRED06
3. Execute F8
4. Enter the Credit Control Area(VBAK-KKBER)
5. Enter the Credit Account (VBAK-KNKLI)
6 .Execute 7. Report checks the blocked sales order in the background.
7.1 When the report- RVKRED06 is run after the incoming funds.
7.2 It clears the value of the Blocked sales order value if it has sufficient funds.
7.3 The credit status changes from VBUK-CMGST changes from “B" (Blocked)
To “A”(Approved) . If it still not approved the status remains “B” .
But it does not change to “D” Released when the funds are approved.
Related content
Related Documents
http://help.sap.com/saphelp_47x200/helpdata/en/7f/1d85347860ea35e10000009b38f83b/frameset.htm
http://wiki.sdn.sap.com/wiki/display/SD/ERP+SD - Report on credit Management
Related Notes
SAP Note 42145 Check credit SD documents in background
SAP Note 1039688 Long runtime of RVKRED06
Labels
FD33 VA01 VA02 RVKRED06 credit
RVKRED06 changes other, not credit management relevant data in the document
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
You run report RVKRED06 to check documents from credit management view. You realize that not only credit management relevant data is changed in the order but also i.e. dates, quantities.
Solution
RVKRED06 is meant for a new credit check for blocked SD documents. This means that sales orders will be processed as an "internal" VA02. Not only a new credit check is running, but all functions, just as you would open a sales order via VA02 and save. As a result i.e a new ATP check is also running and based on the actual situation and customizing it might end up with a changed situation in these data.
RVKRED06 does not change risk category
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
RVKRED06 or other transactions with another credit check (VKM1, VKM3, VKM4), do not change the risk category, although in the corresponding credit account (FD32) a new risk category was entered.
Solution
During each credit check, the system first checks whether in the sales document category the automatic credit control is set (TVAK-KLIMP EQ CHARD) or whether a payment guarantee procedure is used (NOT TVAK-BABSS IS INITIAL). If both does not apply, the system runs no check and also the risk category is not determined, since this is no longer necessary.
Here, no change is required. If NO automatic credit control is carried out and NO payment guarantee procedure is used, the system does not need the new risk category.
SAP Note: 370014 - RVKRED06 does not change risk category
RVKRED06 does not change risk category
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
RVKRED06 or other transactions with another credit check (VKM1, VKM3, VKM4), do not change the risk category, although in the corresponding credit account (FD32) a new risk category was entered.
Solution
During each credit check, the system first checks whether in the sales document category the automatic credit control is set (TVAK-KLIMP EQ CHARD) or whether a payment guarantee procedure is used (NOT TVAK-BABSS IS INITIAL). If both does not apply, the system runs no check and also the risk category is not determined, since this is no longer necessary.
Here, no change is required. If NO automatic credit control is carried out and NO payment guarantee procedure is used, the system does not need the new risk category.
SAP Note: 370014 - RVKRED06 does not change risk category
RVKRED77 and RVKRED88
Skip to end of metadata
Created by Former Member on Jul 23, 2015
Go to start of metadata
What kind of problem do you face?
Correction report for wrong credit values - RVKRED77
RVKRED77 is not correcting the credit values
RVKRED77 does not show any values, only the processed document numbers
RVKRED88 does not deliver any result
Is it possible to use report RVKRED07?
Difference in the protocol of RVKRED88 and RVKRED77
Runtime problems:
RVKRED77 is locking the tables, no SD activity is possible
Business runs 24*7, it is not possible to block the tables, how can we correct the values
Long runtime of RVKRED77
Business runs 24*7, it is not possible to block the tables, how can we correct the values
Skip to end of metadata
Created by Former Member on Jan 06, 2015
Go to start of metadata
Symptom
You have detected inconsistent credit values in the system. For the right method to do that please read HERE how this can be done. These wrong values should be corrected.
Solution
The standard recommended way is to use correction report RVKRED77. Further on this please read HERE.
This is blocking the SD tables (VBAK, LIKP, VBRK) to ensure data consistency and avoid inconsistent values again. SD postings are not possible during this time frame.
There are companies, which can not use this recommendation, as their system is operating 24*7*365 and there is no time frame available to lock the SD tables. In special cases to correct the wrong credit values it is possible to use report RVKRED07 with the 'no block' option. (RVKRED07 normally shouldn't be run alone, it is called by report RVKRED77). This report will then not lock tables VBAK, LIKP and VBRK. Thus it can be run during normal business hours.
Please keep in mind that it should be used only in very exceptional cases, for your own risk, if it's not possible for you to run report RVKRED77. As a selection criteria for this report you have to use the credit account of the customer (field KNKLI) and the credit control area (KKBER). The field NOBLOCK you have to set to X to make sure that tables VBAK, LIKP and VBRK will not be locked. Please do not use any other selection criteria, SAP Note 1297946 explains this, too.
There is one IMPORTANT thing you have to consider when running report RVKRED07, which is why generally can not be recommended to run it without locking the sales tables. When you create new sales orders for the customer you are just correcting with this report, while the report is running, new inconsistencies may occur. Please run the report always for customers, for which no sales transactions are performed in the time the report is running for this special customer.
Please read also:
Is it possible to use report RVKRED07?
Please ensure that note '1297946 - RVKRED07: incorrect credit values due to incorrect selection' is implemented in your system!
Correction report for wrong credit values - RVKRED77
Skip to end of metadata
Created by Former Member on Jan 06, 2015
Go to start of metadata
Symptom
There are inconsistent credit values in the system, you determined this by using the right method. You would like to know how to correct these wrong entries.
Solution
RVKRED77 is a correction report of the credit management for the updated open sales values (the open credit values in SD), that is, for the information structures S066 and S067 with the open order values (S066-OEIKW), the open delivery values (S067-OLIKW) and the open billing document values (S067-OFAKW).
You need to use the report if:
errors occurred in the updating of these sales values (ideally if the cause of the errors has been eliminated so that you can continue afterwards with correct values without errors);
if the update group (T014-STAFO, Transaction OB45) was changed in a credit control area (more on this you can read HERE);
in larger intervals to remove zero entries from table S066: The open order values (S066-OEIKW) are stored in time periods (monthly, weekly or daily, Transaction OMO1) in table S066. At some stage, the entries in the older periods become zero and are then also read each time you read the open order values (for example during the check of the credit limit used). To improve the performance, delete these entries in larger intervals by using RVKRED77;
in larger intervals to remove minimum elementary amounts (for example 1 cent) which, due to rounding problems, remained despite the completion of the respective processes. For more details refer to Note 406608.
For the following reasons the report is no suited for frequent use:
To ensure an error-free run of RVKRED77, it is necessary to completely block tables VBAK, LIKP and VBRK. As a result, the run of the report is not possible during the current operation.
Depending on the selection, a program run of RVKRED77 can last a few hours, in extreme cases you may even experience a runtime of a few days.
Help with runtime problems:
Note 363343 provides detailed instructions for the parallel processing of RVKRED77 and Note 755395 for background execution:. SAP Note: 363343 - Parallel processing of RVKRED77 if the runtime is too long SAP Note: 755395 - Parallel processing RVKRED77 for background processing
If you identified more credit accounts with incorrect credit values (i.e. with report Z_CREDIT_VALUE_COMPARE, read HERE how) you can build groups of credit accounts which you can run by parallel processing. With that you can reduce the time frame needed for reconstruction.
Additional information:
RVKRED88 simulates report RVKRED77. However, it does not block tables VBAK, LIKP or VBRK as does RVKRED77 as a result, differences may occur in the result if relevant documents are changed during the run or if new documents are created. It is very well suited to estimate the runtime of RVKRED77, and thus to determine suitable selections.
This is included in SAP Note: 400311 - RVKRED77: Reorganization credit data, new documentation
Further information
How is the credit value of a document calculated?
How does the credit update work?
RVKRED77 is locking the tables, no SD activity is possible
Business runs 24*7, it is not possible to block the tables, how can we correct the values
More information related to RVKRED77 and RVKRED88
Difference in the protocol of RVKRED88 and RVKRED77
Skip to end of metadata
Created by Former Member on Jan 08, 2015
Go to start of metadata
Symptom
You might be confused about the different protocol output between RVKRED77 and RVKRED88.
This is what RVKRED77 issues:
This is the output result for RVKRED88 with the same selection:
Case 1:
Case 2:
Solution
RVKRED88 lists the sales documents which would update the open credit values by simulating them (Case 1) .
In Case 2 there are no open sales documents which would have an open credit value, so it does not display anything. Further on this you can read HERE.
In case of RVKRED77 all documents are listed in the protocol which were investigated by RVKRED77, also such documents which wouldn't update the credit values.
Long runtime of RVKRED77
Skip to end of metadata
Created by Former Member on Jan 08, 2015
Go to start of metadata
Symptom
You execute RVKRED77 but it takes hours or a day to complete. As it is blocking the SD tables, it is seriously affecting the business operation
Solution
Depending on the selection, a program run of RVKRED77 can last a few hours, in extreme cases you may even experience a runtime of a few days. Performance will depend on how many open sales orders, deliveries and billing documents are in the system for the selection. If you want to be sure to complete the processing within a time period then you should reduce the selection criteria. You will have the shortest runtime if you run the report only for a single credit account (KNKLI) within a single credit control area KKBER). This is the smallest possible selection entity for this report.
Also you can use report RVKRED88: it simulates report RVKRED77. However, it does not block tables VBAK, LIKP or VBRK as does RVKRED77 as a result, differences may occur in the result if relevant documents are changed during the run or if new documents are created. It is very well suited to estimate the runtime of RVKRED77, and thus to determine suitable selections.
You can proceed as folows:
If this problem occurs for more credit accounts, you can use to determine the credit accounts with incorrect open credit values by the report Z_CREDIT_VALUE_COMPARE from SAP Note 666587. The report Z_CREDIT_VALUE_COMPARE first simulates the reorganization of open credit values (according to the RVKRED88 report) and then compares the results to the values that exist on the database in S066 and S067 - and which can be seen in Transaction FD32 (View: Status, Extras -> Sales values). Further on this you can read HERE also.
Based on this you can than build groups of credit accounts which you can run by parallel processing of RVKRED77. SAP Note 363343 has been created to reduce the runtime using parallel processing. Please review SAP Note 755395 for parallelism the report for background job.
Further information:
SAP Note: 400311 - RVKRED77: Reorganization credit data, new documentation SAP Note: 363343 - Parallel processing of RVKRED77 if the runtime is too long SAP Note: 755395 - Parallel processing RVKRED77 for background processing
RVKRED77 does not show any values, only the processed document numbers
Skip to end of metadata
Created by Former Member on Nov 06, 2014
Go to start of metadata
When you execute RVKRED77, you mark the selection field 'Log? (X)' with an 'X'. Although when report has finished, there are no credit values displayed, only the processed document numbers.
This is the standard behaviour. Report RVKRED88 shows the calculated credit values.
RVKRED77 does not show any values, only the processed document numbers
Skip to end of metadata
Created by Former Member on Nov 06, 2014
Go to start of metadata
When you execute RVKRED77, you mark the selection field 'Log? (X)' with an 'X'. Although when report has finished, there are no credit values displayed, only the processed document numbers.
This is the standard behaviour. Report RVKRED88 shows the calculated credit values.
RVKRED77 does not show any values, only the processed document numbers
Skip to end of metadata
Created by Former Member on Nov 06, 2014
Go to start of metadata
When you execute RVKRED77, you mark the selection field 'Log? (X)' with an 'X'. Although when report has finished, there are no credit values displayed, only the processed document numbers.
This is the standard behaviour. Report RVKRED88 shows the calculated credit values.
RVKRED77 is not correcting the credit values
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
You executed RVKRED77 but the values remain the same just as before or it calculates an incorrect open credit value.
Analysis
Check the support package level of your system and search for relevant program corrections under SD-BF-CM to avoid that RVKRED77 mailfunctions due to a program error.
The values might be correct. With report RVKRED88 you can simulate the correct values and this also lists the document numbers whith open credit values. With this information you can check the credit value calculation. Further on this please read HERE.
There are some special cases which are restrictions. For that please read following notes:
SAP Note: 1714643 - RVKRED77: Incorrect values for batch and FKREL = "H"
SAP Note: 1993089 - Open delivery credit values incorrect after price change in scheduling agreement
SAP Note: 1559136 - RVKRED77: Restrictions for POD with partial quantity billing
RVKRED88 does not deliver any result
Skip to end of metadata
Created by Former Member on Jan 08, 2015
Go to start of metadata
Symptom
You execute report RVKRED88 for a credit account in a specific credit control area. The result is an empty list, there is no output:
Solution
This might be normal and standard behaviour. If report RVKRED88 does not generate an output for a selected credit management account, no open sales value exists for this credit management account in the specified credit control area. The log of RVKRED88 does only show credit accounts, where there are still open credit values (like open orders, open deliveries or open billings).
SAP Note: 501240 - RVKRED88 does not generate output for some customers
Use of report RVKRED07
Skip to end of metadata
Created by Former Member on Jan 06, 2015
Go to start of metadata
Report RVKRED77 calls internally the program RVKRED07, but normally you should use report RVKRED77 to correct the inconsistent credit values as it blockes the SD tables automatically to ensure data consistency. Please read following information too:
Correction report for wrong credit values - RVKRED77
RVKRED77 is locking the tables, no SD activity is possible
If you want to use RVKRED07 for your own risk, please implement note 1297946 to ensure that only the correct selection criteria will be used. Also please read the text of it: SAP Note: 1297946 - RVKRED07: incorrect credit values due to incorrect selection
As a selection criteria for this report you have to use:
KNKLI = <relevant credit account>
KKBER = <relevant credit control area>
PROTB = "X" or space ("X" = list with documents)
TRACS = space -> mode with database changes (TRACS = ' ')
NOBLOCK = "X" -> if it is empty, it is blocking the tables, if it is 'X' it is not blocking the tables, but be careful about inconsistencies
Please do not use any other selection criteria.
VKM1-5 transactions
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Which documents are listed in the VKM* transactions
Blocked document is not listed in VKM1
Sales order is released but it is again displayed in the list of VKM3/VKM4
Credit values are displayed in thousand
Display variant shows two lines
Authorisation problems in VKM* transactions
"Check" or "Reassign" function does not perform a new check for critical fields
VKM*: Extend list with user-defined fields
Availability check during credit block release
No confirmed quantity after sales order credit release
Performance problem in VKM* transactions
Availability check during credit block release
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
1. You release a sales document from a credit block.
2. You carry out a recheck for a sales document (in the background using report RVKRED09 or in a credit list, for example using transaction VKM1).