SAP SD Availability Check

[Former Member]

I have got the SAP availability check "A" for create sales order set up exactly as I need it to work. When I create a new sales order it correctly identifies the availability based on other existing dependent requirements and reservations.
However immediately after creating the sales order if I go into change sales order, whilst the checking rule used is the same, the dependent requirements and reservations are ignored and the confirmed date is brought forward. I have looked in CO09 and I can see that the difference is that the "with requirements quantities" box is not checked at sales order change, only at sales order create. I have also looked at the configuration for the checking group, - OVZ2, and the accumulated quantities settings here make no difference.

Is this normal system behaviour, or am I missing something ?

Any help appreciated.

Gerry

[Former Member]

Hi Gerry,

Could you plase elaborate your issue with screen shots if possible or with exact details it will help us to understand and try to provide resolution.

Regards,

Shreenidhi math

[Former Member]

Hi Guys,

Thanks for quick response, I am having trouble attaching files, but my situation is that I have got 25 pieces of a material in stock. There are existing current network and production order reservations for 5 pieces, and a sales order for 3 pieces.

So VA01 for 25 pieces correctly offers me 17 pieces now and 8 pieces in January. I save this.

Immediately go into VA02 and this changes this to 22 pieces now and 3 pieces in January.

That is my problem, the "with requirements quants" flag in ATP is checked in VA01 buit not in VA02, hence different result

Any thoughts please

Gerry

[Lakshmipathi]

What settings are there in OVZ2 under the tab "Accumulation" against your availability check ?  If it is blank, try to maintain 2 or 3 and retry the process.  For information, if "With reqmts qtys" box is checked in sale order, then, you need to set 2 or 3 in OVZ2.

G. Lakshmipathi

[Former Member]

Hi,

OVZ2 is set to 3, I have tried it at all other settings also - but either 2 or 3 should be correct. When I create sales order if I branch to ATP at avail check stage - I can see the "with reqmts quants" is checked. But at sales order change it is blank. I can not see how I can influence this.

Gerry

[Former Member]

Gerry,

FYI My experience is that the checkbox 'With reqmnts quantities' checkbox is that it is never checked during order changes.  The system will ONLY check for confirmed qtys during order change, not requirements qtys.  This gives you a more realistic ATP check.

It sounds like you may have been 'playing' with the cumulation settings in OVZ2.  Please bear in mind that cumulation info is copied into the sales order upon SO item creation (stored in table VBAP).  Changing this setting in configuration will have only limited effect on an existing Sales order item.

When you do your experiments, you should reject the SO item; make the config change, and then create a new identical item.  Only then will you know what the effect will be.  As you have noted, it appears that cumulation in OVZ2 of  '3' will be most likely to meet your requirements.

Best Regards,

DB49

[Former Member]

Hi Dogboy,

Many thanks for your input. I do agree that that system does not look at requirements when changing sales order, just at confirmed quantities. To be fair, the help "behind" the accumulation settings in OVZ2 does say this.

As I tested with changing these settings I created new sales orders each time - to ensure I was seeing new data.

The scenario that my client pointed out to me was that when they create a sales order, the availability looks at all requirements, prod orders as well as sales orders and proposes the correct availability. Now, the customer might change the sales order, lets say item increase quantity by 1 piece. This triggers avail check based on confirmed qtys only, and tends to "pull" the promise date forward.

Then nightly we run the V_V2 - and this changes it back to where it was at SO create stage.

Because of this, we do not have a major problem - the following morning all is well.

I just didn't realise over the years that this was how it worked.

Once again thank you for your help

Gerry

[Former Member]

Gerry,

The scenario that my client pointed out to me was that when they create a sales order, the availability looks at all requirements, prod orders as well as sales orders and proposes the correct availability. Now, the customer might change the sales order, lets say item increase quantity by 1 piece. This triggers avail check based on confirmed qtys only, and tends to "pull" the promise date forward.

It is possible to automagically confirm the dependent reservations generated from production orders; either during production order creation or production order release (provided there is sufficient supply).  OMIH.  Then, you can configure your Sales order ATP check (OVZ9) to respect these dependent reservations (Incl.depen.reservat = X or A for checking rule A).  In this way, you can assume that your ATP requirements are more or less equal to your ATP confirmed quantities.  Sales orders will then not be unnecessarily pulled in and later pushed out.  Production orders can be made to compete on an equal footing with Sales docs.

Best Regards,

DB49

[Former Member]

re also using

[Former Member]

Hi Dogboy,

Sorry for delay, been away a few days.

I have checked our OMIH settings and the OVZ9 and all is well. The OPKJ settings are also fine. However we are also using PM - and we have a lot of network assy orders - it is these that do not get confirmed at order release. This is the standard SAP setting for this. OPKJ for order types PS02 and PS06. I need to discuss with client how and when these need confirming. Once I get this sorted, as you say all requirement types should be on an equal footing.

Thank-you for the help

[Lakshmipathi]

the dependent requirements and reservations are ignored and the confirmed date is brought forward.

May be if you can explain with an example what dependent requirements and reservations are ignored, it will be easy to understand what is happening at your end and accordingly, propose suitable suggestion

G. Lakshmipathi