Docstoc

Eggheads Sample Code for Feb 02

Document Sample
Eggheads Sample Code for Feb 02 Powered By Docstoc
					Credit Management “Doublecheck: Yes/No?” Sample Code for FI/CO Expert, February 02

Sample Code
The goal of creating a custom FORM routine for the R/3 Credit Management module is to establish our own rules regarding when a sales order that had been previously on Credit Hold, and then released by a Credit Manager for further processing, should be subjected to the online Credit Management policies a second time if a Sales Order enduser is now trying to save some changes to that sales order. If the sales order is, in fact, subjected to the same online policies a second time, most likely that sales order will end up on Credit Hold a second time. The below Sample Code does not try to determine whether or not a sales order should be placed on a Credit Hold. Instead, it merely seeks to enforce our own (i.e., custom) rules on whether or not the sales order‟s data values should be allowed to bypass (skip) the online credit-checking routines. Without establishing our own rules, the R/3 default rules will be enforced. Those default rules typically allow 100% of all sales orders being changed by an end-user (or by a batch process, or etc.) to be subjected to the creditchecking routines active in your R/3 system, even if the only value being changed is not related to Credit Management (e.g., a sales order‟s text field‟s value). For the purposes of this Sample Code, we will assume that we would like the sales order that is being changed to only be subjected to the online credit-checking routines in the following four circumstances: 1. 2. 3. 4. When the new Net Value of the sales order is more than the old Net Value. When the new Currency Code in the sales order is different than the old Currency Code. When the new Net Weight of the sales order is more than the old Net Weight. When the new Payment Terms code is different than the old Payment Terms code. *-------------------------------------------------------------* * DISCLAIMER * *-------------------------------------------------------------* * * The following is meant as Sample Code, and is not meant to represent a ready-to-implement program for your “Live” R/3 system. As with any ABAP that was developed outside of your own system, code should always be modified to meet your own users’ requirements, preferences, and assumptions, and then tested thoroughly prior to implementation into a productive R/3 system. Neither the developer nor the FI/CO Expert newsletter publishers assume responsibility for your results. *-------------------------------------------------------------* *-------------------------------------------------------------*

Your custom FORM routine is called by Program LVKMPU01 with the following Statements (as of R/3 release 4.0b): 275 276 277 278 279 280 281 282 283 *-------------------------------------------* checking procedures *-------------------------------------------* Prüfungen über Bedingungen deaktivieren if no_check is initial. clear: bypass, status_reset. if not t691f-grpno is initial. move t691f-grpno to formname-grpno. perform (formname) in program saplvkmp.

There are two important context items to know about concerning that calling syntax: (1) The „no_check‟ variable referred to in Line 279 is potentially populated with an „X‟ a few lines earlier in the same program. This logic by SAP merely guarantees that two standard settings in Credit Management customization table T691F always take priority over your custom FORM routine, in regards to whether or not to subject the sales order being changed to the online credit-checking routines (if „X‟, then the sales order will not be subjected). To view these standard settings, access transaction code “ova8”. The two settings involved are in the “Released Documents Are Still Unchecked” section, and are called “(Allowed) Deviation in Percentage” and “(Allowed) Number of Days”. 260 261 262 263 264 265 266 * 267 credit_value_allowed = xvbak-amtbl - delivered_value. credit_value_allowed = credit_value_allowed + ( credit_value_allowed * t691f-crprc / 100 ). if credit_value_allowed ge credit_value. valid_to = xvbak-cmfre + t691f-tagef. if valid_to ge sy-datum. keine Prüfung, da Änderung im erlaubten Rahmen no_check = true.

(2) The „t691f-grpno‟ variable referred to in Line 281 and 282 has a very strange text when you see it in the transaction (t/c “ova8”) you‟ll use to populate the variable. The text reads “No credit check”. This is very similar-sounding to the variable in Line 279. But, the two are really quite different. In this case, the “No” of “No credit check” is an abbreviation for the word “Number”, as in “Number of the (custom) credit check (FORM)”.

*------------------------------------------------------------------------------- * * SALES O R D E R data entry tables * *------------------------------------------------------------------------------- * * TABLES * The following work areas or tables are available during the * * “VA02” transaction, and therefore their data values can be * * read and checked by our custom ABAP routine. * * * * XVBAK - Header of order, after the end-user‟s changes * * YVBAK - Header of order, before the end-user‟s changes * * * * XVBAP – Line Items of order, after the end-user‟s changes * * YVBAP - Line Items of order, before the end-user‟s changes * * * * XVBEP – Delivery Schedule Lines of order, after … * * YVBEP – Delivery Schedule Lines of order, before … * * * * XVBKD - Business Data of order, after … * * YVBKD – Business Data of order, before … * * * * XVBPA – Partners (e.g., “Sold To” or “Ship To”), after … * * XVBPA – Partners (e.g., “Sold To” or “Ship To”), before… * * * ---------------------------------------------------------------------------------

*----------------------------------------------------------------------------------* * Importing Flags * * The following information is passed into your custom FORM * * program by the calling program. * * * * RECHECK * * an „X‟ means that the sales order is being accessed by a * * Credit Manager via t/c “VKM1”, and not an end-user via * * t/c “VA02”. Therefore, if we want to, we can exit our * * custom FORM routine immediately. * * SECURITY_CHANGE * * an „X‟ means that some change in risk management (such * * as letter of credit, or payment cards) exists. Therefore, we * * probably will want to make sure that the sales order has to * * pass through the online credit-checking routines, and will * * exit our custom FORM routine immediately. * *-----------------------------------------------------------------------------------*

*----------------------------------------------------------------------------------* * Exporting Flags * * The following information is passed out of your custom FORM * * routine back to the calling program. * * * * bypass-SECURITY 'X' check will not be carried out * * i.e. letter of credit, payment cards (insurances) * * bypass-STATIC_LIMIT 'X' check will not be carried out * * bypass-DYNAMIC_LIMIT 'X' check will not be carried out * * bypass-DOCUMENTVALUE 'X' check will not be carried out * * bypass-CRITICAL_FIELDS 'X' check will not be carried out * * bypass-REVIEWDATE 'X' check will not be carried out * * bypass-OPEN_ITEMS 'X' check will not be carried out * * bypass-OLDEST_OP 'X' check will not be carried out * * bypass-DUNNING_LEVEL 'X' check will not be carried out * * bypass-USER1 'X' check will not be carried out * * bypass-USER2 'X' check will not be carried out * * bypass-USER3 'X' check will not be carried out * * * * status_reset-SECURITY 'X' special status will be reset* * status_reset-STATIC_LIMIT 'X' special status will be reset* * status_reset-DYNAMIC_LIMIT 'X' special status will be reset* * status_reset-DOCUMENTVALUE 'X' special status will be reset* * status_reset-CRITICAL_FIELDS 'X' special status will be reset* * status_reset-REVIEWDATE 'X' special status will be reset* * status_reset-OPEN_ITEMS 'X' special status will be reset * * status_reset-OLDEST_OP 'X' special status will be reset * * status_reset-DUNNING_LEVEL 'X' special status will be reset* * status_reset-USER1 'X' special status will be reset * * status_reset-USER2 'X' special status will be reset * * status_reset-USER3 'X' special status will be reset * *------------------------------------------------------------------------------------*

FORM BEDINGUNG_PRUEFEN_901.

* Credit Check occurs only if changes to the following A/R risk-relevant * factors have occurred: * * 1.The new net value is more than the old net value. * 2.The document‟s currency symbol has changed. * 3.The new net weight is more than the old net weight. * 4.The terms of payment has been changed. * *These factors are checked and if the rules have not been violated, then relevant export *flags are set to „X‟, which eventually leads to Credit Management‟s checking routines *getting skipped. *---------------------------------------------------------------------* *Begin of Code * First, check for an „X‟ value in the two Import Flags. If an „X‟ is there, then exit * our custom FORM routine so that the sales order will be subject to the online * credit-checking routines. IF NOT SECURITY_CHANGE IS INITIAL. EXIT. ENDIF. IF NOT RECHECK IS INITIAL. EXIT. ENDIF.

*If neither of these fields were imported with an „X‟ value, then we can now look to *see if any of the field values we want to be sensitive to have been changed. If they *have not been changed, then we will populate all of our Export Flags with an „X‟ so *that when control is returned to the calling program LVKMPU01, the “If … then …” *logic that exists in front of each “perform credit check” statement will fail. The credit *routines will not be called. And, therefore, the changes being made to the sales order *will not lead to the sales order being automatically put on a Credit Hold. * 1.Check that the new net value is not greater than the old net value * 2.Check that there is no change in the document currency IF XVBAK-NETWR LE YVBAK-NETWR AND XVBAK-WAERK EQ YVBAKWAERK. * 3.Check that the new net weight is not greater than the old net weight, IF XVBAP-NTGEW LE YVBAP-NTGEW. * 4.Check that the Terms of Payment have not been changed IF XVBKD-ZTERM EQ YVBKD-ZTERM. *If all of that is true, then set all of the Export Flags equal to „X‟ MOVE CHARX TO BYPASS-SECURITY. MOVE CHARX TO BYPASS-STATIC_LIMIT. MOVE CHARX TO BYPASS-DYNAMIC_LIMIT. MOVE CHARX TO BYPASS-DOCUMENTVALUE. MOVE CHARX TO BYPASS-CRITICAL_FIELDS. MOVE CHARX TO BYPASS-REVIEWDATE. MOVE CHARX TO BYPASS-OPEN_ITEMS. MOVE CHARX TO BYPASS-OLDEST_OP. MOVE CHARX TO BYPASS-DUNNING_LEVEL. MOVE CHARX TO BYPASS-USER1. MOVE CHARX TO BYPASS-USER2. MOVE CHARX TO BYPASS-USER3. ENDIF. ENDIF. ENDIF. ENDFORM. "Bedingung prüfen 901


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:137
posted:11/5/2009
language:English
pages:6