cancel
Showing results for 
Search instead for 
Did you mean: 

Availability Check

Former Member
0 Kudos

Hi,

Is there a way for the system to confirm the availability in Sales Order based on open Purchase Order first (even for the delivery date on PO is beyond RLT) before checking RLT.

Currently "Availability Check Control" setting is:

     - Incl. Purchase Order = X

     - Check without RLT = BLANK

Example:

     Material RLT = 10 days

     Inventory = none

     Open PO Delivery Date = 5/27/2015

Currently when creating Sales Order today (5/8/2015)  with Customer Requested Delivery Date of 5/15/2015, the system will propose ATP on 5/21/2015 based on RLT. 

My user wants the system to check against open POs first (even though the delivery date on PO is bigger than RLT) and use the delivery date on PO to confirm the availability on Sales Order.  So in this case, they want the confirm date on SO to be 5/27/2015, instead of 5/21/2015.

I know the system can do this if "Check without RLT" is flagged but we still want to keep this unflagged so when there is no available inward movements, then it will propose the availability date based on RLT.

I will appreciate, if anyone has any tips or suggestions.

Regards,

Michelle

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member223981
Active Contributor
0 Kudos

Hi Michelle,

I do not think this is possible. You have to remember what the RLT does. It confirms requirements according to the end lead time. As per the F1 Help of the end lead time, "The end of replenishment lead time is the date on which the material could be available again if production or procurement is started today". This means that the latest this material will be available by is the end lead date.

The availability date always strives towards providing the earliest possible confirmation date. Therefore, it would not make sense that the system uses a confirmation date from the PO as your end lead date states that there is material available before this.

You should also remember that really, confirmations against the end lead date should only happen in exceptional circumstances. If you are regularly encountering negative ATP quantities due to confirmations against the end lead date, it hints at an unrealistic end lead time.

Hope this helps.

Noel

Former Member
0 Kudos

Hi Noel,

Thank you very much for your input and I do agree with your explanation.  But to address my users' request, is there an user-exit to add our own custom logic to this process?

Thanks,

Michelle

former_member223981
Active Contributor
0 Kudos

Hi Michelle,

Generally, it is not wise to implement a user exit for a process that is not logical. I do not think the desired behaviour is logical and I think it's worth re-iterating that the best solution would be to put the end lead time further into the future. If this is done, then ATP will confirm against the POs first (assuming they are earlier than the end lead date).

If you were to use a user exit, then EXIT_SAPLATPC_002 might be appropriate. This exit can be used to change the ATP result. However, this would not be an easy solution and would require complex coding. You could do something like this:

- check w/o RLT in OVZ9. This means that when ATP is called, the system will have to confirm against the POs.

- After ATP, EXIT_SAPLATPC_002 is called. In here, you could maintain code similar to SAPLATPC (Form END_OF_RLT_CALCULATE) where you calculate the end lead date in the exit.

- You can subtract the confirmed quantity from the required quantity to get the unconfirmed quantity.

- Then, you can assign the unconfirmed quantity to the end lead date (i.e. the remaining quantity is confirmed according to the end lead date)

I am not sure if the above would actually work. Certainly, it would require extensive testing before being used on a production system. And I wouldn't advocate this approach - in my experience, complex coding in ATP user exits inevitably lead to further issues.

I would recommend that the end lead date is extended to ensure that POs are rarely later than the end lead date. In cases where the PO falls later than the end lead date, regular rescheduling jobs should mean that the requirement eventually gets assigned to the PO rather than the end lead date anyway.

Hope this helps,

Noel

Former Member
0 Kudos

Hi Noel,

Thank you very much for your suggestions and what user-exit to use if my users still want to pursue with it.

Regards,

Michelle