Unlimited Credit for Test Customer

[Former Member]

I do many SO in DEV enviroment, and I have to release the credit in VKM1 for every single one.

How can I give credit or set up a customer so it does not get blocked?

I tried changing its limit in FD32 but its alredy on the maximum allowed.

Thank you,

Carlos

[former_member131745 · Accepted solution]

You could deactivate the credit check for the document type in OVAK or alternatively in trx OVA8 remove the field: Credit check: > Set credit status (block) - T691F-STSET.

I hope this helps

Gerard

[Former Member]

Thanks to both.

[Former Member]

Hi Carlos,

The reason for the wrong credit updates could be due to ,

there are a few things that can cause imbalances if you

have code in MV45AFZZ, especially in the SAVE_DOCUMENT . . . and

SAVE_DOCUMENT_PREPARE forms. This userexit has been the reason of

negative open orders for many customers. There can be several updates

to internal table XVBAP without a corresponding update on table YVBAP.

Table XVBAP is responsible for the 'positive' statistics update and

YVBAP is responsible for the 'negative' statistics update. If these two

tables do not correspond, you can get wrong or negative updates to the

credit statistical tables S066 or S067.

You should check your userexits to make sure that the update flag for

the Y tables is set. Sometimes, customers only set the update flag for

the X tables. Both must be set in order to update correctly.

There is a note 50551 which offers an example of this. You don´t

have to copy the code directly from this note: it is only an example.

This note explains how userexits can affect your structures. There are

a few things that can cause imbalances if you have code in MV45AFZZ,

especially in the SAVE_DOCUMENT...and SAVE_DOCUMENT_PREPARE forms.

You need to make updates to Yxxxx structures as well as Xxxxx

structures.

The problem that can happen here is that there are two changes being

made to Xxxxx/Yxxxx for the order. So the amount would be subtracted

twice from S066 and only added once for S067, causing your negative

balance. This balance would then be cleared by the re-org program

RVKRED77.

Note 216448 is about this issue.

These user exits are the reason of negative values in 99% of the cases.

Moreover, in order to have the open credit values of FD32 properly

updated, please take into account the following settings:

- in transaction OB45, an update group must be maintained for the

relevant credit control area. In the standard, update group 000012 is

used. I recommend you to read the F1 help of this field in order to

choose the update group that best fits your business needs.

- in transaction OVA7 or in VOV7, the flag "credit active" must be set

for the relevant item categories. The system does not update the open

credit values (Open sales orders, Open delivery and Open billing

documents) if this flag is not set.

- in transaction VOV7, the relevant item category must be relevant for

billing and it must be delivery-related in order to update S066.

Sales order items which are not relevant for delivery and do not have

schedule lines relevant for delivery are not updated to S066 but to

S067.

- in transaction OMO1, S066 must have "synchronous updating (1)".

All other settings will lead to errors in updating (note 426202).

- Please also check OVA8. There we can set different criteria to block a

sales order or delivery.

- if an item has no confirmed quantity, nothing will be updated in S066 or S067

- in transaction V/08, for the relevant pricing procedure, a subtotal

"A" must be entered. If no subtotal "A" is entered, the system cannot

determine the credit price and nothing will be updated.

- if there´s a delivery block at schedule line level, the sales order

item will not update the credit values (note 60672).

- if in VOV7, the flag "item relevant for delivery" is set for item

type= blank (Standard Item), the open credit values will not be updated

(note 67748)

- if you enter a payment guarantee procedure in the order and if the

depreciation level is 100 %, the system does not update the sales value

(note 435252).

- in the scenario described by note 626880, credit values are not

updated.

If you want to analyze if a specific sales order has updated S066,

you can use transaction MCVR. Moreover, you can check note 381789 which

shows you how to analyze the update of S066 and S067 using transaction

MC30 as well as note 389377 for analyzing the relevant documents for

the update.

Moreover, there are some typical problematic transactions which can

cause a wrong update of the open credit values (list is not complete):

o Processing of credit and debit memo requests

o Rejection of sales orders

o Delivery of material structures

o Partial deliveries

o Change of billed deliveries

o Deletion of delivery items

o Cancellation of billing documents

Finally run the report-RVKRED77 to reorganize the credit data.

Completely block tables VBAK, LIKP and VBRK when you run the report.

Finally, I understand that the removal of user exits will possibly

have an impact on other user testing. Please note that it is possible

to deactivate userexits for a particular user using the following

code - (? system with username SAPOSS)

IF SY-UNAME = SAPOSS

EXIT

I hope this will help to resolve the problem.

Ruy Castro