cancel
Showing results for 
Search instead for 
Did you mean: 

ATP and "stealing" how to prevent

Former Member
0 Kudos
675

Folks,

We have a situation where our lead product is a MTO but the components are not. They are generally purchased parts.

The usual scenario is a Sales Order with Configurable item of several components (X,Y &Z)

Those several components are not MTO or 'hard linked' to the Configurable item. So can be allocated and reallocated to Orders as they fly in.

The problem is that this leads to perceived "stealing" after nightly rescheduling jobs when new Orders may have come in.

Is there any way of structuring this so for example: when an Order (1) is confirmed the component 'X' is locked in with that Order and if another Order (2) comes in even if it is earlier it will honour the first commitment ?

In a full MTO route we would have that hard allocation but I am wondering if there is any way to do this in a MTO route using perhaps reservations?

be interested in feedback

Thanks

View Entire Topic
former_member196530
Active Contributor
0 Kudos

Hi ,

As per as Production process is concern , it basically depends on the availability check you perform on various order .The moment you perform availability check for any order and release the same , component  gets allocated through reservation based on the  availabity , RLT  (OPJK /OPJJ) .

In case of MTO , it become hard allocated with special stock indicator in component view  of the process or production order .

Now , if you want the available stock to be committed for your order, you can use CO06 to change the commitments manually or you can use COMAC with 'Reset Availability Data' check box ticked. System will then commit as per selection made.

Regards

JH


Former Member
0 Kudos

JH,

Thanks as always and I would like to expand a little here...

- The reservation allocation however is not 'hard-linked' and replanning will cause rearrangement and hence the stealing

- Yes could use CO06 but that is manual

- COMAC - will this hard allocate?

former_member196530
Active Contributor
0 Kudos

Hi

COMAC will not hard allocated rather it will go FIFO basis on various orders when you will perform availability check to reserve the qty based on the stock and requirement date situation

Refer -Collective Availability Check - Adjust sequence of orders checked - ERP Manufacturing (PP) - SCN Wik...

Regards

JH


Former Member
0 Kudos

Milton,

Any time you run COMAC for all orders, you run the risk that existing orders that have already been confirmed will either lose their confirmation, or they will receive new confirmation dates/quantities that are unsatisfactory.

As mentioned by expert Jiaul, there is no concept of fixed allocation in any ECC MTS ATP solution.  Also as mentioned by him, you can minimize this problem by fine tuning the sequence within COMAC.

Another method, somewhat simpler, would be to just exclude existing confirmed orders from COMAC processing.  Existing confirmations in this case are not touched by COMAC.

Best Regards,

DB49

Former Member
0 Kudos

Guys,

really good feedback thank you

we have the issue when we change purchase order or make confirmations and re run ATP we see this 'stealing'. I guess because of our actions we unconfirm the previous confirmations.

I dont think we can make these type of changes to POs, exclude existing confirmed orders from COMAC processing and still uphold the existing confirmations as your suggesting?

Former Member
0 Kudos

Just to add - can we exclude existing confirmed orders through V_V2 ??

Former Member
0 Kudos

Milton,

we have the issue when we change purchase order.....

Purchase orders to vendors do not trigger an availability check.  It is unclear what you are saying here.

...or make confirmations and re run ATP we see this 'stealing'. I guess because of our actions we unconfirm the previous confirmations.

It is unclear what you mean when you say 're-run ATP'.  When you perform ATP on a single object, you have the option of saving or not saving the original confirmation.  If your object does not provide a satisfactory confirmation, then don't save the object.

I dont think we can make these type of changes to POs, exclude existing confirmed orders from COMAC processing and still uphold the existing confirmations as your suggesting?

???  COMAC only performs availability checking on production orders or optionally planned orders.  Purchase orders do not use availability checking at all (unless you are talking about Stock Transport orders, which are also not ATP'd via COMAC).  If you want to exclude existing Production orders that already have a confirmation from COMAC processing, you can exclude status CNF.


Just to add - can we exclude existing confirmed orders through V_V2 ??

V_V2 has nothing to do with COMAC; this will not touch existing confirmations for production orders or planned orders.  It only handles sales ATPs and STO ATPs.  Yes, you can exclude existing confirmed sales docs from being processed by V_V2.

Best Regards,

DB49

Former Member
0 Kudos

Thanks and sorry for the confusion we are dealing with V_V2.

The issue we are having is that already confirmed orders are being picked up and moved when supply (Purchase Orders) dates are adjusted.

[By confirmation date I am talking about the confirmation date of the scheduling line of the sales order].

Our question is that by making adjustments to the Purchase Orders the system seems to be removin the previous confirmations and then rescheduling accordingly

Cheers

Former Member
0 Kudos

Milton,

Changing a Purchase order does not change Sales confirmations.  V_V2 can change sales confirmations.

You can exclude existing confirmed sales docs from V_V2 as mentioned above.  In general, such docs will thereafter not be touched by V_V2; so they would not be in danger of losing an existing confirmation.  Whatever confirmations they had previously would be preserved.

For some exciting reading on this subject, enter V_V2 and hit the blue information button.

For more exciting reading on this subject, try http://service.sap.com/sap/support/notes/1861066

Best Regard,

DB49