24
Credit Check This document explains the system solution for credit check concept IOF2122 Credit Check). The purpose of concept is to improve customer credit control in order handling in order to minimize unnecessary credit and delivery blocks and thus improve the otd-figures and customer service. System solution gives answers to global credit check concept and it describes how the requirement are met in system. The main areas of system solution are Sales & distribution's automated credit check, running of SAP standard credit check batch job and the list of credit blocked documents (VKM1). The first credit check will be made at the order entry. If the order does not pass the credit limit check, it will be marked as credit blocked and the user gets a warning message, which shows the exceeding value. The credit-blocked order goes through the frame check normally, but the delivery cannot be created before the block has been released. The blocked orders will show up in the credit block list VKM1 (within credit check horizon, including goods issue date and the value) and they are monitored and released by the credit control management. If the credit control does not release the credit block it will inform logistics, where the frames will be manually released for the other customers. Credit check is implemented with R/3's automatic credit control at sales order cycle. Credit checking is activated in customizing for each credit control area and customer credit group (risk category). Credit control area Credit control area is same as company code (Nokia specific) Risk category Risk categories are Nokia specific and they are defined for each customer. Document credit group 01 for orders and 02 for deliveries.

Credit Check

  • Upload
    joseph

  • View
    270

  • Download
    9

Embed Size (px)

DESCRIPTION

SAP Credit Check

Citation preview

Page 1: Credit Check

Credit Check

This document explains the system solution for credit check concept IOF2122 Credit Check). The purpose of concept is to improve customer credit control in order handling in order to minimize unnecessary credit and delivery blocks and thus improve the otd-figures and customer service.

System solution gives answers to global credit check concept and it describes how the requirement are met in system. The main areas of system solution are Sales & distribution's automated credit check, running of SAP standard credit check batch job and the list of credit blocked documents (VKM1).

The first credit check will be made at the order entry. If the order does not pass the credit limit check, it will be marked as credit blocked and the user gets a warning message, which shows the exceeding value. The credit-blocked order goes through the frame check normally, but the delivery cannot be created before the block has been released. The blocked orders will show up in the credit block list VKM1 (within credit check horizon, including goods issue date and the value) and they are monitored and released by the credit control management. If the credit control does not release the credit block it will inform logistics, where the frames will be manually released for the other customers.

Credit check is implemented with R/3's automatic credit control at sales order cycle. Credit checking is activated in customizing for each credit control area and customer credit group (risk category).

Credit control area Credit control area is same as company code (Nokia specific)

Risk category Risk categories are Nokia specific and they are defined for each customer.

Document credit group 01 for orders and 02 for deliveries.

Credit Controls (OVA8)

Every credit control area/customer credit group/document credit group (01) uses following credit controls:

i. dynamic credit check is activated and time horizon is 5 days, document is blocked, warning message is shown with the exceeded value.ii. oldest open overdue is activated, document is blocked, warning message is shown with the exceeded value.

Page 2: Credit Check

NMP Sales FramesStandard SAP Credit blocking does not have any affections to NMP sales frames. Sales frame functionality is same whether the credit check is on or off. In Sulo 2.1 Eur/Afr carefully evaluated if the frame reservation should be prevented when the order goes to credit block at the order entry. It was found out that blocking the frames makes the process at the logistics side too complicated especially as in most cases the goods will be sent to the customers anyway.

Material RequirementsMaterial requirements are passed to PP (SAP standard). However for future SuLo

project the material reservation should be prevented in PP in production order release phase.

Delivery CreationDeliveries cannot be created if order is in credit block (SAP standard).

Credit Blocked order listAll orders with status credit blocked are shown in credit block list (VKM1). Documents

can be selected by credit control are, risk category, customer number and next shipping date (+ some other fields). List contains following columns: next shipping date, customer name, document number, documents open order value, currency, credit limit usage (in per cents), terms on payment code, risk category, status (usually B=Blocked) and the reason of blocking (usually "dynamic check").

User can set a specific user parameter (KKL) to be able to see the schedule line level information in credit block list. When KKL is used the list contains additional rows for each schedule lines. Show fields are delivery date and schedule line's credit value.

Controller can release or reject orders in credit block list.

The second credit check will be made with a batch run five days prior to the date the goods should leave the DC. This is to cover possible changes, which may have occurred since the first check at the order entry phase. The re-check is not done if the order was released from the credit block or did pass the check 3 days before the re-check should take place, i.e. maximum risk of 8 days is accepted.

If the order does not pass the second check it will be marked credit blocked. The new credit blocked orders will show up in the credit block list. If credit control releases the credit block, delivery can be created. If credit control decides not to release the credit block it will inform logistics, who will manually release the frames for other customers.

Batch job RVKRED09

SAP standard credit check program can be used. Program name is RVKRED09. Different selections in selection screen can be defined. Following selection fields can be used: Credit

Page 3: Credit Check

control area, Credit account, Risk category, SD document number, Overall document status, Overall credit status, Next shipping date, Date of next credit check.

Batch job is run daily. Selection criterias are: Next shipping date -> current date + five days, Overall credit status -> from A to C. Other additional selection criterias can be defined.

Batch job can block orders or approve orders, depending on customer's credit situation.

Batch job names:

-Europe & Africa regionSD4: Daily credit check EUR/AFRused for Europe & Africa region. Batch job is executed every time 4 am. Finnish time (3 am

Central European time).- Americas

- APAC

Variant values for EUR/AFR:Credit control area: AT10 (+all other European credit control areas)Overall document status: from A to B (select all documents which are not (or partially) deliveredOverall credit status: from A to D (select document which are not approved/approved/released)Next shipping date: date variable (current date + 5 days)Orders: XLog? X

Variant values for Americas:Credit control area: not defined yetOverall document status:Overall credit status:Next shipping date:Orders:Log?

Variant values for APAC:Credit control area: not defined yetOverall document status:Overall credit status:Next shipping date:Orders:Log?

Page 4: Credit Check

4. Master Data Requirements

Master data is mainly maintained by finance department. Finance is responsible for credit account (customer) settings, e.g. customer credit limit, risk categories and so forth.

Customer Open Order ValueCustomer's open order values are updated to infostructucture S066. Currently the update period of infostructure is one month (used by Americas US10 and CA10). In new concept the update period is changed to one day. The change of update period deletes all data from infostructure and old data must be re-loaded to the infostructure. This can be done with report RVKRED77. There is some notes in OSS concerning report RVKRED77.

5. Global / Local Settings

(ref. also OSS-Note 18613)

1. Transaction OB38 Check which credit control area is assigned to the company code. Credit control area: Credit control area and company code uses same codes (FSP) 2. Transaction OVAK Which settings do exist for the sales document type used? Sales document: BV, SO, TA, ZAP1, ZSAM, ZOR, ZRAM, ZTA, ZTA1, ZUDA, ZUDR Check credit: D Credit group: 01 3. Transaction OVA7 Is credit management active for the item category used? Item category: all normal item categories are active (42 pieces) 4. Transaction OB01 Which risk category does your credit control area have? Risk category: all CCA's have Nokia standard risk categories 5. Transaction OVA8 Does an entry exist for your combination of - credit control area - risk category - credit group? Are the displayed details correct? 6. Transaction FD32 Maintain the data for the sold-to party and the credit control area. Make sure, that - risk category: - all limits: - currency: are correct.

Page 5: Credit Check

7. Pricing (transaction V/08) In the pricing procedure which you use during pricing in credit processing, you must enter the subtotal "A" in order to determine the credit value (detail screen in pricing procedure, view). Thus, the system will create subtotals for the credit price during pricing and store them in a specific (KOMP-CMPRE = credit price in the item). The credit functions will be based on the subtotals.

This is ok. 8. Now credit management can be tested with the combinations set as described above.

Following setting must be applied for each credit control area, risk category and action code 01:

Update: 00012 Check that credit control area is using update group 000012, which updates infostructure S066 Open orders: credit mgmt. If value is different, then change it in FI settings (see additional settings).

Item check: X Item check in switched on. Preliminary credit check is done after pressing firs time enter on item line.

Deviation in %: 1-10%. Credit check is done if order value is changed more than here defined.

Number of days: 3 days. Credti check is not done if order is released later than three days ago.

ReactionDynamic check: X C, order is blocked, time horizon is 5 daysCritical fields: X C, order is blockedOldest open item: X A, order is blocked, Day oldest item is set from 1 - 60, depends on

different controls and risk categories.

Credit control area settings:in FI customizing (Enterprise structure/Financial/Credit Control area) the SD settings should changed in update group field. The value of update group field should be 000012, which updates open order values in infostructure S066.Requirement 101This requirement removes the confirmed quantities if the order goes to credit block. Requirement 101 is disabled (transaction code OVB8 => 101, program name for requirement is LVO7A101) to have the confirmed quantities in credit blocked orders.

6. Reports, User-exits, Modifications and Interfaces

Reports:(Reports section updated as part of Cord 3.0; 2005/02/08 - Egil Holten)

6.1 RVKRED06

RVKRED06 checks all blocked documents from credit view. SAP recommends running the program after incoming payments. The program should be run in the background.

Selection options:

Page 6: Credit Check

Log result:

6.1.1 FunctionalityThe program will automatically release orders (to status B) in cases where the credit situation has improved. If the risk category or credit limit has changed, but no re-organization yet performed, the program will still take the new values into consideration for documents that are already blocked. For orders that are not blocked, the new risk category or credit limit will not be considered, even though the documents would be blocked according to the new values.

6.1.2 Nokia UsageThis program is not being utilised currently in the Nokia solution. Based on input from Lea Saastamoinen January 11th, 2005, there are no immediate plans to start using the program.

6.2 RVKRED08Source OSS Note 42145. RVKRED08 will retrigger the credit checks on all documents that reach the dynamic credit check horizon, as new. This is only applicable if you are using the dynamic credit check with a horizon. SAP recommends running the program at the start of each period.

Selection options:

Page 7: Credit Check

Log result:

6.2.1 FunctionalityThis report rechecks sales documents with schedule lines that have a material availability date that reach the credit horizon (or lies outside the current credit horizon but will fall within the credit horizon based on the Date of next credit check inputted when running the program).

The documents that have already been released are only checked if the release date plus the validity period (frozen period) is smaller than the next check date. Source OSS Note 156827.

Example: An order is created today, December 20th, with a scheduled delivery date of January 11th. The credit horizon is 5 days. In this case the, the Date of the next credit check, will be January 6th-

If you run RVKRED08 and select “Date of next credit check” as January 5th, our order will not be credit checked. However, if you select January 6th, our order will be selected.

By inputting a value in the “Take release data into account”, it’s is possible to exclude orders that has been manually released, from the credit check.

The logic behind this selection option works as follows: When a value has been inputted into the “Take release data into account”, and the order has been manually released, i.e. “Overall credit check status” (VBUK-CMGST) equals ‘D’, then:

Page 8: Credit Check

· If the Release date (VBAK-CMFRE) of the order+ the Number of days without check (T691F-TAGEF), aka Frozen period, is greater than or equal to the Date of next credit check of document (VBAK-CMNUP), then the release is still valid and no new check is carried out.

· Else, if the Release date (VBAK-CMFRE) of the order+ the Number of days without check (T691F-TAGEF) is less than the Date of next credit check of document (VBAK-CMNUP), then a new check is carried out.

Example:Order initially credit blocked, and subsequently released by a credit controller on December 20th (Release date = 20.12.2004). In this example, let’s assume the frozen period is 5 days. Some items on the orders are scheduled for delivery in 8 days, thus the date of next credit check is therefore 23.12.2004.

20.12.2004 + 5 days > 23.12.2004

In this example, the program will not perform a new credit check.

Example:Order initially credit blocked, and subsequently released by a credit controller on December 20th (Release date = 20.12.2004). In this example, let’s assume the frozen period is 5 days. Some items on the orders are scheduled for delivery in 12 days, thus the date of next credit check is therefore 26.12.2004.

20.12.2004 + 5 days < 26.12.2004

In this example, the program will perform a new credit check.

6.2.2 Nokia UsageThis program is not being utilised currently in the Nokia solution. Based on input from Lea Saastamoinen January 11th, 2005, there are no immediate plans to start using the program.

6.3 RVKRED09

RVKRED09 will recheck credit on all SD documents, both blocked and/or released, according to your parameters. Obviously, it is sufficient to run the program for open orders (with Overall document status ‘A’ or ‘B’).

You might want to run this program if your customers have long lead times and you need to recheck credit before shipping goods.

Selection options:

Page 9: Credit Check
Page 10: Credit Check

Log results:

6.3.1 Functionality OSS Note 42145; 510034.The report checks all sales documents as transactions VKM1 – VKM5 would do online. Should be started in the background and take report RVKRED06 and RVKRED08 into account, which means for example that the blocked documents do not have to be selected since these have already been processed by RVKRED06.

The report updates all sales (and delivery) documents in the same way as report RFDKLI20 concerning the Risk Category and Customer Credit Group with much better performance. In addition, RVKRED09 provides a large number of selection options, and it carries out a new credit checks for the sales documents selected.

The documents that have already been released are only checked if the validity period (frozen period) of the release has expired. 6.3.2 Nokia UsageRVKRED09 is currently scheduled in a nightly batch run, with the following selection options set in one variant:

· Credit control area: AT10, CZ10, GB11, TR11, BE10, NL11, IT11, HU10, DE11, ES10, PT11, FR10, PL10, SE14, DK11, FI11, IE10, NO10· Overall document status: A, B· Overall credit status: A, B, C, D· Next shipping date: Selection range with Previous 5 days – Next 5 days· Range of documents: Only Sales documents selected

6.4 RVKRED77OSS Note 400311. RVKRED77 is a correction report for the open sales values in SD.

Screen shot of FD33:

Page 11: Credit Check

This report is used to correct 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).

Selection options:

Page 12: Credit Check

Log results:

6.4.1 Functionality

Source OSS Note 400311.

The report should be used when:

· Errors occurred in the updating the sales values, and 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.

· 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.

Program RVKRED88 can be run in simulation mode. This program will show the corrections that will be done after running RVKRED77.

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.

One drawback by running report RVKRED77 is that VBAK, LIKP and VBRK needs to be completely locked during the run-time. As the run-time for RVKRED77 is quite long, it has to be scheduled outside normal business hours.

OSS Note 755395 contains reference to a report which blocks the above tables allowing parallel running of this program – allowing shorter run-times. This OSS Note dictates us to use RVKRED07 instead of RVKRED77 when running multiple simultaneous processes.

Page 13: Credit Check

Program Z_RVKRED77_PARALLEL blocks VBAK, LIKP and VBRK until the last process og RVKRED07 has completed.

Selection options for Z_RVKRED77_PARALLEL:

Selection options for RVKRED07:

Page 14: Credit Check

· PROTB: If ticked, log is outputted after completion of run.· TRACS: If ticked, simulation mode.· NOBLOCK: If ticked, no blocking of VBAK, LIKP and VBRK.· TUNING: Always True.

6.4.2 Nokia UsageDue to the long run-time, and the required tablelocking this program is seldom being run.

6.5 RFDKLI20

Report RFDKLI20 carries out a reorganization of the SD and FI credit data after organizational changes. You can also start it directly via Transaction F.28. This document will only cover the SD related aspect of this report.

Screen shot:

Page 15: Credit Check

Log results:

6.5.1 Functionality OSS Note 408596 You must execute this report after the following changes (General changes concerning SD and FI):

Page 16: Credit Check

· 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. · Currency of the credit control area. · Assignment of customers to credit management accounts. Caution: With such a change, the system automatically starts the reorganization of the credit data in Transaction FD32. However, if a runtime error occurs due to high data quantities, you must start report RFDKLI20 manually afterwards - in this context, refer to Note 99937. · Risk category in the master data of the credit management account (Transaction FD32). Caution: If you have not changed anything except the risk category, report RFDKLI20 is actually possible, but too large for this purpose. If you only change the risk category, report RVKRED09 is sufficient.

· Credit Representative Groups.

The report updates all sales and distribution documents for open transactions (transactions containing non-processed documents) with regard to their credit data (credit control area, credit management account, credit currency, credit value, risk category) within an 'internal VA02'. That is, the system imports the document, changes the credit data, and then saves it again. This can lead to further changes in the document - exactly those changes that would also occur if VA02 and the saving were carried out manually. The affected information structures S066 and S067 are not deleted (as in RVKRED77), but the SD credit values are cleared from the information structures by the 'internal VA02' with regard to the old settings, and then posted again with regard to the new settings.

Report RFDKLI20 updates only SD documents that are still open or that contain open documents in their document flow OSS Note 370022..

Report RFDKLI20 does not go through the release logic in the credit check. The logic 'Released documents are still unchecked' does not apply. It is therefore required the release the orders again in transaction VKM1.

6.5.2 Nokia UsageThis program is being used after changes to the Credit management master data or Organisational structures.

· Risk Category --> Use RVKRED09 (can also use RFDKLI20, but better performance w/ RVKRED09)· Credit Representative Group --> Use RFDKLI20. Subsequently VKM1 to release again.· Credit Control Area --> Use RFDKLI20. Subsequently VKM1 to release again.· Credit Account --> Use RFDKLI20. Subsequently VKM1 to release again.· Reset Credit Control Area --> Use RFDKLI20. Subsequently VKM1 to release again.

· Changes to Organizational structures --> Use RFDKLI20. Subsequently VKM1 to release again.

It is important to be aware of the following:

· Situation 1: When running the program with the “Recreate FI and SD Data”, neither the order nor the delivery values are updated for subsequent customer in cases where the Credit Account is changed.

Page 17: Credit Check

· Situation 2: However, when running the program with “Only Recreate SD Data”, the program seems to be working correctly, updating both Credit Accounts, Credit Representatives and Risk Category correctly.

6.6 Ways of working - RVKRED09 vs RFDKLI20The RFDKLI20 program is the only option in situations where we have changed:- Credit Account (field KNKLI; stored in VBAK, LIKP and VBRK)- Credit Control Area assignment (field KKBER; stored in VBAK, LIKP and VBRK)- Currency of a CCA (field CMWAE; stored in VBAK, LIKP and VBRK)

As a consequence of running the RFDKLI20 program for the above changes:

(1) Main tables VBAK (i.e. sales orders), LIKP (i.e. deliveries) and VBRK (i.e. billing documents) will be updated with the new Credit Account, Credit Control Area, Credit Control Area currency values.

(2) The credit value for any released orders that are blocked after running the RFDKLI20 program will decrease the value in the credit management information structures (S066 and S067) in the Logistics Information System (LIS). HOWEVER, the decrease in value is not directly due to the new values for Credit Account, Credit Control Area or Currency of CCA, but rather that the order now is blocked (as the RFDKLI20 program re-blocks orders which has been manually released the last 5 days - i.e. the release logic is ignored).

(3) The info structures (S066 and S067) in LIS will be updated with the new Credit Account, Credit Control Areas, and Currency of CCA; as these fields are used in the info structures in LIS. From a technical point, the SD credit values are deleted from the info structures with regard to the old settings, and then posted again with regard to the new settings.

The RFDKLI20 program will also update changes to: - Risk Category (field CTLPC; stored in VBAK and LIKP - not VBRK)- Credit Rep group (field SBGRP; stored in VBAK and LIKP - not VRBK)

As a consequence of running the RFDKLI20 program for these changes:

(1) Main tables VBAK and LIKP will be updated, as Risk Category/ Credit Rep Grp are not used in VBRK.

(2) The credit value for any released orders that are blocked after running the RFDKLI20 program will decrease the value in the info structures (S066 and S067) in LIS. HOWEVER, as in the case above, the decrease in value is not directly due to the new values for Risk Category/ Credit Rep Grp, but rather that the order now is blocked (again, as the RFDKLI20 program re-blocks orders which has been manually released the last 5 days - i.e. the release logic is ignored).

(3) The info structures (S066 and S067) in LIS will in ths case not be updated, as these fields are not used in the relevant info structures (S066 and S067) anyway.

Page 18: Credit Check

However, if only the Risk Category or Credit Representative group has been updated, then it is sufficient to run the RVKRED09 program. In standard SAP the RVKRED09 program will not be updating the Credit Representative Group, while we as part of Cord 3.0, have changed the standard program, to allow such updates when running the program.

Based on this, when it comes to RVKRED09, this program will update:- Risk Category (field CTLPC; stored in VBAK and LIKP - not VBRK)- Credit Rep group (field SVGRP; stored in VBAK and LIKP - not VRBK)

As a consequence of running the RVKRED09 program for these changes:

(1) Main tables VBAK and LIKP will be updated, as Risk Category and Credit Representative Group are not used in VBRK. This is the same way as for the RFDKLI20 program above.

BUT - as we are running the RVKRED09 program for sales orders only, LIKP will not be updated with the new values for Risk Category/ Credit Rep Grp, when running the RVKRED09 program with the current selections.

(2) The credit value for any released orders that are blocked after running the RVKRED09 program will decrease the value in the info structures (S066 and S067) in LIS. HOWEVER, as in the case above, the decrease in value is not directly due to the new values for Risk Category/ Credit Rep Grp, but rather that the order now is blocked. This is the same way as for the RFDKLI20 program above.

(3) Info structures (S066 and S067) in LIS will not be updated, as Risk Category and Credit Representative Groups fields are not used in these info structures. This is the same way as for the RFDKLI20 program above.

When it comes to currency updates, the open orders, open deliveries and open billing documents (tables VBAK, LIKP and VBRK respectively) will be updated in those cases as the currency of the credit control area has been changed.

Example:

Let’s say we have a credit control area which has been defined with currency DEM in field WAERS. Based on this, all orders in VBAK are stored with Currency key of CCA (CMWAE) equal to: DEM.

Then, after we change the currency of the credit control area (WAERS) to EUR, and execute program RFDKL20, the result will be that the Currency key of CCA in VBAK (CMWAE) updated for open orders will be changed from DEM to EUR.

Page 19: Credit Check

1.1 Execution of RVKRED09 and RFDKLI20 during intial cut-over

Initial Cutover

Field Field techn.

NET Cust: (AccGrp: Z002 /200 000-299 999)

NMP Cust (AccGrp: Z001 & Z003 & Z004 & Z006)

Credit account KNKLI *20 to be started for dedicated cust. Use report RFDKLIAB.

*20 to be started for dedicated cust. Use report RFDKLIAB.

CrCtrlA-Assignment NET (11 ??): GB20, IE20 + ?? NMP (18): AT10, BE10, NL11, CZ10, FI11, FR10, DE11, HU10, IT11, PL10, PT11, SE14, DK11, ES10, TR11, GB11, IE10, NO10

KKBER *20 to be started for dedicated cust. Use report RFDKLIAB.

*20 to be started for dedicated cust. Use report RFDKLIAB.

Currency of CrCtrlA CMWAE *20 to be started for dedicated cust.

*20 to be started for dedicated cust.

Risk Category CTLPC * 09 to be started for all open orders

* 09 to be started for all open orders

Credit Rep. Group SBGRP * 09 to be started for all open orders

* 09 to be started for all open orders

Page 20: Credit Check

1.1 Execution of RVKRED09 and RFDKLI20 as periodical activities

Periodical Activities

Field Field techn.

NET Cust: (AccGrp: Z002 /200 000-299 999)

NMP Cust (AccGrp: Z001 & Z003 & Z004 & Z006)

Credit account KNKLI * Once per period (month or quarter)

* Once per period (month or quarter)

CrCtrlA-Assignment NET (11 ??): GB20, IE20 + ?? NMP (18): AT10, BE10, NL11, CZ10, FI11, FR10, DE11, HU10, IT11, PL10, PT11, SE14, DK11, ES10, TR11, GB11, IE10, NO10

KKBER * Once per period (month or quarter)

* Once per period (month or quarter)

Currency of CrCtrlA CMWAE * Once per period (month or quarter)

* Once per period (month or quarter)

Risk Category CTLPC RVKRED09 once per month to do new credit check date range can not be used Customers have to be chosen manually approx. 10 hours -> weekend runs

RVKRED09 each night to do new credit check +/-5days

Credit Rep. Group SBGRP RVKRED09 once per month to do new credit check date range can not be used Customers have to be chosen manually approx. 10 hours -> weekend runs

RVKRED09 each night to do new credit check +/-5days (this one is not updated today, as prg change was part of Cord30

***************************************************************************************

User-exit:Requirement 101 removed (tr. code OVB8)

Modifications:

Page 21: Credit Check

Order confirmation printing changed (program ZVADOR01). If the order is in credit block, printall schedule lines.

Interfaces:No Interface changes

7. Alternative Solutions

No possible alternative solution considered in this document.

7. Additional info

More info can be found in R/3 Help. Here's a shortcut to Credit Management

http://sawww01nmp.nmp.nokia.com/R3OnlineDoc/html/Helpdata/EN/7f/1d85347860ea35e10000009b38f83b/frameset.htm