Credit Management

[Former Member]

Hi Gurus.,

In credit management there are different types like

static,

dynamic

doccument value

critical fields

next review date

open items

oldest open items

Dunning

User exist

Can any one explain all this by taking examples,why we use this different types and do we use one type of reit check or more than one for a project.,

Can u pls say with examples

POINTS ARE AWARDED TO ALL THE GURUS who explain with examples

Thanks in advance

Narayana

Message was edited by:

manam narayana

[Former Member]

Hi Manam,

We control the credit in two way, Simple and Automatic. whatever you are asking is fall in Automatic. I am here define you the Static and Dynamic.

In Static, the system check the all open item for the particular customer. The open item controlled by Update Group in Credit Control Area.

In Dynamic, we define the credit limit within a period defined by Horizon. Here the system check the all open item within the period defined in Horizon.

In short we can say, in static system will check all open items and in dynamic system will check all open items within a period.

Often we use the Static in almost all business process, as there is no risk.

If you need further clarification, pls. contact.

Have a nice day,

AKT

[Former Member]

Thanks tripathi for your answer

Can u pls explain why we use critical fields and how the credit limit is caliculated on critical fields with examples,and open items,oldest open items,next review date

Awaiting for your valueble reply

Pls explain with examples

Thanks in advance

Narayana

[Former Member]

Hi Narayana,

It is calculated through the updation rule assigned in Credit Control Area. Generally we use the 00012 rule. This rule caculate from credit from sales order.

As soon as you create an order, it will increse the open sales order value from sales document schedule line, again when you do the delivery, the system decrase the Sales doc value and incrase the delivery document value, same the system do for billing and acounting document.

We control the credit limit on three stages. Sales Order, Delivery and Goods issue. After goods issue we assume that the material is customrs property and the system updates all the accounting documents, like Inventory and COGS etc.

We define a customer with a credit limit in Automatic as, T-Code FD32

Total Amount : If customer is doing business with more than one Credit Control Area, then here we define the overall value of Credit in all Credit Control Area.

Individual Limit : Here we define the maximum credit value customer may receive within a credit control area.

Credit limit : Here you can define the actual credi value customer can benefited in a particular CCA.

I think it is enough to understand the process. If need more clarification, feel free to contact me also feel free to give some points to your friends.

Have a nice day, enjoy SAP.

AKT

[Former Member]

Hi, manam narayana.

I'll write down briefly.

<b>1) Static credit check</b>

Static credit check uses the value of confirmed quantities, regardless of delivery date. It also uses the open receivable balance and special general ledger accounts relevant for credit. You can also include open orders (regardless of delivery date) and open deliveries. Open deliveries include all quantities in deliveries as well as quantities in SD billing documents not yet passed to Accounts Receivable. The value is determined by multiplying the confirmed quantity by the credit price.

<b>2) Dynamic credit check</b>

Dynamic credit check in the order uses the value of confirmed quantities scheduled to ship within the credit window. The quantities are updated from schedule lines of existing orders and the order being entered. If the quantity confirmed is zero, the value of the current order (for credit limit check purposes) is zero. The value is determined by multiplying the confirmed quantity by the credit price.

Note that open order values are only updated from schedule lines that are relevant for delivery (TVEP-LFREL = ‘X’). Third party order items, for example, do not update open orders since they do not create deliveries (there is no mechanism to decrease the open order values other than by creating a delivery).

The length of the credit window in days is determined by multiplying the increment in Table T681F by 7 (weeks) or 30 (month or accounting period). The result is then added to today’s date.

<b>3) Maximum document value check</b>

Value is determined by multiplying the order quantity of each order line by the credit price. All quantities (confirmed or unconfirmed) are used in the calculation.

<b>4) Change of critical fields check</b>

Critical Fields are defined as the payment term, baseline date for aging and extra value days. The payment term is compared to the payment term from the Sales Area data of the Payer Account. Any entry in either baseline date or value days will trigger this check.

<b>5) Days since next review date check</b>

This check looks at the next scheduled review date from the customer master. If that date is more than the specified number of days in the past, the check fails. For example, a customer is reviewed on July 1, 1995 and the next scheduled review date is set to January 1, 1996. The maximum days specified is 15. On January 17, 1996, the check will fail if the next scheduled review date has not been updated.

<b>6) Oldest open item check</b>

This looks for any open item that is past due more than the specified number of days, regardless of value.

Note: If using this check with deliveries or goods issue and "Payer" indicator is on, then Payer must be defined as partner function for delivery.

<b>7) Highest dunning value check</b>

If the customer has at least one open item whose dunning level exceeds the specified value the check fails. The dunning level in the customer master is not used.

Note: If using this check with deliveries or goods issue and "Payer" indicator is on, then Payer must be defined as partner function for delivery

<b>8) User Exits</b>

Availability check on release of blocked document

FORM USEREXIT_AVAIL_CHECK_CREDIT is added to program MV45AFZF. The purpose is to enable the user to determine if an availability check should be carried out on an order that has been released or has been approved as a result of a recheck. The reason is that some customers use the backorder process or rescheduling to determine availability.

The user exit is delivered in release 3.0F. OSS Note 53201 describes how it can be installed into earlier releases

I refered the document 'Credit Management, Prepared by Jeff Hirsch, SAP America'. It's good reference document.

If you let me know your e-mail , I email to you.

Hope that helps,

Best regards

Kyung Woo, Nam

[Former Member]

Hi Kyung woo.,

Thanks for your immediate response,and can you pls sedn me the doccument on credit management prepared by jeff SAP America to my mail id

it is narayana.sapsd@yahoo.co.in

Thanks in advance

Narayana

[Former Member]

I mailed it to you.

I wish it helps you.

Best regards

Kyung Woo, Nam

[Former Member]

Hi Kyung Woo, Nam

Can you mail me those doc to my mail Id:nath1972@gmail.com

thanks in advance

Ranganath

[Former Member]

Hi friends,

Can u pls send me mail to my mail id

rams.sd@rediffmail.com

With regards

Rajesh

[Former Member]

Hi Ranganath,

Can you farward the mail to me

Mail : gantag@email.com

Thanks in advance

Regards

Gantag

[Former Member]

Hi Kyung Woo,

Please send me the document to nagaraj.sun@gmail.com

Thanks in advance

nagaraj

[Former Member]

Hi Kyung Woo, Nam

Please forward the same one to me also.

Mail: gantag@email.com

Sorry for gr8 trouble.

Thanks in advance

Regards

Gantag