V_V2 Rescheduling puts the credit block

[Former Member]

When I do a rescheduling job V_V2 in the overnight every day orders are going into credit block even

IF nothing changes into the order. Every day it re block again the same orders.

How can I avoid it???

tihs is OVA8:

REGARDS

[VeselinaPeykova]

It is likely that the setting would not help in all cases. Number of days setting in OVA8 works only if the following two prerequisites are met:

•     the new value of the sales order is not greater than the approved value;
•     the current date is before the order release date plus the number of added dates.

The second condition will be most probably fulfilled, but the first one - maybe not. Assuming that V_V2 is used for not fully confirmed orders, in case the increase of confirmed quantity happens for items that are relevant for credit exposure update, this would trigger order blocking again for credit limit reasons. It would help if the not confirmed item is TANN or similar.

The setting for number of days is mostly useful in case of oldest open items/dunning level problems.

It would not be very wise to skip the credit block in case the credit value becomes higher than the approved value.

If I remember correctly, we have already discussed in a previous thread that your customer does not wish to approve orders based on ordered quantity, but based on confirmed quantity, so the other obvious solution (activating the user exit) is not applicable.

What I fail to understand is: why V_V2 is run so often? In the companies I have worked before (regular business):

Day 1:

•     Order taking: CIC, mobile;

Day 2:

• Credit department releases/rejects the blocked orders, that should be planned on this date until the end of the agreed cut-off time.
• After credit department finishes with credit release, sales/logistics department run VL10A and create deliveries. We had additional coding in the OVA8 routine to bypass ALL credit checks except critical fields in case a delivery is created. Additional coding was implemented to restrict adding of items/increase of order quantity in case a delivery is already created for an order.
• Transportation planning, warehouse processing, delivery execution.
• Route settlement, billing.
• After finishing billing: A/R summary to have the most recent data for the mobile devices.

V_V2 was needed only in very rare cases (effective production planning plus good organization).

I would suggest as a start to try to resolve the problems with production planning/production order confirmation/GR from external vendors or whatever it is that causes partial confirmations and establish clear rules for cut-off times.

Since you run V_V2 during the night, you are supposed to get in the list orders that are not yet processed by the credit department - so you are actually helping them to get the accurate credit value for release and reduce the credit risk for the company.

[former_member183879]

Hi Veselina,

I think there is still valid reason to run V_V2 on a daily basis. The rescheduling does two things.

1. First it blocks the orders for credit reasons (even it had been released earlier). This in rescheduling point of view releases those quantities which are confirmed for for delivery, but should be blocked for credit block, even it had been released from the credit block. This part of the functionality is a process bug.

2. At the end of first activity, we will know the stock and requirement situations more clearly and now rescheduling happens.

The logic that credit released orders should not be blocked again is acceptible, but as of now this functionality is unavailable ( or we dont know how to enable that functionality)

We have the same issue and solved by a coding, not a good way of solving standard functionality bug.

[VeselinaPeykova]

I agree that there could be valid reasons to run V_V2. However, it implies partial quantity confirmations - there must be a reason for that to happen in the first place which should be investigated.

For example we had a process with sales of ice, were the production happens during the night based on a report of the quantities ordered on the previous day (due to limited storage capabilities of the special storage space), so we chose to switch off ATP in the sales order. The actual quantity to be delivered to customers was based on the picked quantity in the deliveries (we still needed production order confirmations to happen before the goods issue for the deliveries). There were no problems with credit blocks, because in this case we release the order against the confirmed quantity that is in fact the ordered ice quantity.

What you describe is not a bug, but a very reasonable feature - I would try to explain it the best I can.

When you release an order from credit block, you take the decision for credit risk based on the credit value. In this case the check is executed on the confirmed quantity and not on ordered quantity (there is such option via a user exit, but I understood that the client decided not to use it probably because of the negative impact on his business).

When we have a partial confirmation for an order and a subsequent block, the credit clerk based his decision on value X and released the order (the risk for the company was acceptable). After running V_V2 we get full confirmation and the value becomes X+Y. It can be that the risk for the company becomes too high, so the credit clerk should review again the credit situation and decide whether to release or not the same order. From audit point of view not blocking the order for credit again in case the value is increased would be an issue.

What I tried to point out in my previous comment (clearly I failed to express it very well) is that V_V2 is supposed to be run before the order is processed by credit department. Credit clerks run VKM4 with selection based on next shipping date - why would they release from credit an order several days in advance, when the credit situation could change several times before they have to deliver it? In some companies they even run order recheck as a daily background job, so that orders blocked for overdue items could become automatically approved in case these items were cleared in the meantime.

It really depends what logic you have implemented (it could be really well thought out and it could eliminate any possibility to abuse this functionality) - this is why SAP provides the option of defining a routine in OVA8 and the user exit on released value. There is no such thing as 'one size fits all' in credit management processing (SAP even wrote something of that sort as a comment in the sample routine 001).

Bypassing additional  credit blocks in case of value increase could not only cause audit problems, but also potential losses for the company - especially considering that most of these credit blocks can be minimized by better organization and establishing internal rules.

[Former Member]

Hi navaneetha, could you send  me the code you have developed? Because i am not able to avoid also using code.

i Am also agree with what Veselins explained but in my scenario we are not speaking of partial confirmation, but V_V2 changes the overall status if the order has been released in a prevoius day.

i Cannot accept this, my custom er doesn't accept this 😞

regards

[VeselinaPeykova]

If your sales order was initially confirmed up to the full quantity and afterwards released from credit block, with the code in the OVA8 routine which I shared with you in our previous discussion, it does not get blocked after running V_V2, because the value is not changed.

Have you investigated in the meantime why your orders get blocked as a result of running V_V2 (assuming you have followed my idea of a VOFM routine to bypass checks except for critical fields in case the order value is not increased)?

[Former Member]

Hi Veselina,

the routine is not enaugh as written in note 0000588226.

I think is necessary to use % and day in OVA8

This because I have tested that even if nothing changes (same stock, no material movememts because is a tst client), the day after the V_V2 block again the order.

oVERALL STATUS CHANGED is the only effect in the order log.

regards

[VeselinaPeykova]

Depends what you have done in the routine .

You need % if you wish to allow additional tolerances in value for order recheck (which is not recommended in some business practices) in the case the released order can be rechecked.

In the case of using a routine instead of number of days is that ATP is rerun and the order is rechecked for credit, but because of the logic that I use - to bypass credit checks in case the released value is not increased, the order is not getting blocked. If the value is not increased, I need to block it only in case critical fields are changed.

My order gets full quantity confirmation before I have released it from credit block.

You can add 1-2 days if you insist to release the orders earlier, but not 999.

If you have no additional days or % defined, the program would run through the routine anyway.

[michael_kozlowski]

In OVA8 "Number of Day" set to 999 and "Deviation in %" e.g. to 5