Dear FI/CO Expert,

Once a credit block on a sales order is active, what will cause the block to be automatically removed?

Nigel Clarke
Business Analyst

Hi Nigel,

The most common way to release credit-hold sales orders is manually via end-user transaction code VKM1. With this transaction, you do not have to correct the error condition that led to the automatic credit hold. For example, if a customer’s credit limit is $500 and the customer currently owes your company $475, then saving a new sales order for $30 will trigger a credit hold on that order. (This assumes that your company is using R/3’s automatic credit-management functionality.¹) Your credit manager can then use the VKM1 transaction to manually release the block, whether or not any of the outstanding $475 of accounts receivable is recorded as paid prior to this.

I believe that your question, however, deals with the situation in which the sales order goes on hold Tuesday at 9 a.m. and a $100 payment is recorded at 4:30 p.m. later that same day. In this case, the "error condition" is now gone.

Will this prompt R/3 to automatically remove the credit hold from the $30 sales order?

What about the opposite scenario? The customer’s current A/R balance is $450, and a $30 sales order is saved at 9 a.m. Later, at 4:30 p.m., a $100 debit memo to the customer’s account is posted. Will this prompt R/3 to automatically place the $30 sales order from 9 a.m. on hold? Good questions.

My answer is, "Semiautomatically, yes. Automatically, no."

To launch the credit-checking routine a second time, you have to access the credit-held sales document (the sales order or the delivery) in change mode. Then at a minimum you must perform some form of action (such as changing a field value or clicking on the availability check button) before saving it.

This change will prompt the credit-checking routine to run again when you use the save command.² If the customer’s credit conditions are now below the error threshold, the credit block will be removed. See Figure 1 for a visual representation of this process.

Figure 1

Online credit management vs. the sales order change event

How to Semiautomate Via a Simple Workaround

As mentioned, the way to make this work is to access the credit-held sales documents in change mode. This does not necessarily mean that to do this you must manually access the end-user transaction called Sales Order – Change, processing one document at a time. Other kinds of standard transactions have the ability to apply changes to existing sales documents and, therefore, prompt the credit- checking routine to execute a status review. Two examples are transaction codes VKM1 and V-V2.

With transaction VKM1, you use the Reassign function to launch the revalidation of the credit hold status for one or more sales documents (Figure 2).

Figure 2

Refresh of credit status using transaction VKM1

The limitation is that VKM1 only selects sales documents that have existing credit holds. This works when the customer’s credit situation improves for the better shortly after a sales document goes on hold. However, it has no chance to catch documents when the customer’s credit situation worsens shortly after a sales document has been saved without a credit hold.

Using a transaction such as V_V2 (Reschedule Sales and Stock Transfer Documents) covers both scenarios (Figure 3).

Figure 3

Refresh of credit status caused by transaction V_V2

If you set up either of these two transactions to run once per night,³ you achieve what I’ve been referring to— a "semiautomatic" update to credit management.

² This depends somewhat on your site’s credit management settings for when the credit-checking routines should and should not be allowed to execute against existing credit-held sales documents. For more details about these "If …, then …" rules in online credit management, refer to "Why Do Previously Approved Sales Orders End Up on the Credit Hold List a Second Time … And What Can I Do About It?" in the February 2002 issue of FI/CO Expert.

³ Refresh of credit status caused by transaction V_V2 3 You or your Basis person does this through something SAP refers to as a "job," using transaction code SM36.