APO planned orders moving around in R3, how?

[Former Member]

Hi all, i'm hoping for input on a strange issue

Background:

We are running a setup where we use PP/DS to plan our production, using capacity planning and heuristics.

Thus we generate planned orders in APO and these are transferred to R3. Conversion to production order is done in APO as well.  Planning is run by nightly heuristic as well as via automatic planning procedure on the finished goods, meaning that when a sales order comes in planning is executed and the order is confirmed against the newly created planned order (if one was needed to cover).

Since planned orders are tightly planned to cover incoming SD orders it matters a lot where these orders are placed in time since if It is off even slightly in time the SD order cannot confirm against them ( this matters a lot if you rerun ATP or run BOP).

Issue:

Over the last weeks we have seen planned orders move inexplicably. What I mean is that their date/time data change.  The only way we can check this is in R3 table PLAF where we can look at the timestamp and the last changed  by ID.

The timestamp is set to a point in time where no relevant batch jobs run, and the changed by ID is the R3 system user!.

My question is this, what on earth could make changes to planned orders if it’s not done from the APO system? If it were something from APO I would expect it to be done with the APO system user – this is not the case, it is clearly the R3 user that is stamped as the last user to make changes to these orders.

All the materials are set to a “no MRP” mrp type, so I doubt it’s some stray MRP job. People assure us that no one is making changes manually (it happens in the evening long after people have gone home). And if someone was doing it manually it'd be tagged with their own user yes?

Any ideas as to what can change dates/times on APO generated planned orders on the R3 side? Failing that, any idea for how we could keep a stricter eye on what happens on planned orders? There’s not a lot of change history on these.

[Former Member · Accepted solution]

Simon,

Any ideas as to what can change dates/times on APO generated planned orders on the R3 side?

Anything.  Forget that these orders originated in APO.  Once they are in R/3, they can be affected by any process that would affect any planned orders in R/3.

The timestamp is set to a point in time where no relevant batch jobs run, and the changed by ID is the R3 system user!.

I don't know what you mean when you say 'R3 System user'.  Regardless, go to your basis team and ask them to tell you what processes were running under this ID in R3 at the time you have noticed the changes taking place.

Best Regards,

DB49

[Former Member · Accepted solution]

By system user i mean that we have a user that is used for all batch jobs and system processes in R3, that is the user that is stamped on the orders in PLAF.

[Former Member · Accepted solution]

Simon,

The answer is the same.  Go to your Basis team and ask which processes were executed by this user.

Best Regards,

DB49

[Former Member]

Well it seems to work OK. The heuristic leaves the fixed orders a lone as expected.

However i would expect the orders to be moved around when we run heuristic manually or by editing SD orders - we've not seen them do this though despite testing several examples.

[Former Member]

We have seen in certain cases the if we are doing ATP check in ECC for these APO Planned orders, the Start & End Date/Times were getting shifted.

Rgds

Gk

[Former Member]

That was a theory for us at first too, but we only do ECC ATP checks at the lower component levels, not on the finished product. In our case it clearly is the heuristic that does the moving even if we simply can't seem to get it to do it when we look.

[Former Member]

Hi Simon - I am not too sure if you already have an answer for planned orders being moved by MRP. If not, there is a simple configuration you can use for MRP - lead time scheduling not touching APO planned orders.

Below are the config steps:

1)  Create a new Production scheduler say - XXX

          SPRO - Production --> Shop floor control --> Define production scheduler (configure for your plant)

2)  SPRO - Production --> MRP --> Planning --> Scheduling and Capacity parameters --> Define Scheduling parameters for Planned orders

     In this please configure

          Plant YYYY , Order type - LA, Production scheduler - XXX.

while configuring this, make sure you have in 'Adjust Scheduling' have the second option 'Adjust dates - 3 Do not adjust basic dates, dep requirements to order start, and

For capacity scheduling - 5 Do not adjust basic dates, dep requirements to order start.

3)  Next step is to do a mass upadte of your material master with the new production scheduler in Work scheduling view.

This should avoid order dates being moved for APO planned orders.

Thanks,

Murali

[Former Member]

Thanks, but it's clearly not the MRP that does the moving, MRP just updates the timestamp when it does BOM explosion in R3. We've solved it by doing the fixing workaround mentioned above even if it's sort of dodgy since we do not understand completely what's going on.

[former_member197994]

Hi Simon,

You can switch on detailed logging for the APO RFC user to make sure that it's not the RFC user

that's been doing it. On the other hand, even if all the materials are set to a “no MRP” mrp type,

they can still be planned by MRP (possibly as the result of a bug), you can check the MRP log for sure.

Best regards/Tiemin

[Former Member]

We have gotten further with this.

The R3 timestamp comes from the MRP doing bom explosion. We have also turned off the heuristic as a test, and this means that no orders move around.

So it is clearly our heuristic job that does the update, this seems very strange to me, i've always understood that orders that get moved get deleted and recreated.

Also i don't understand how a heuristic can move orders that are inside the planning time fence. We continue to investigate and will probably get SAP support involved.

[former_member197994]

Hi Simon,

Finally I've found out that system is also right in this aspect. Please have a look at note 501224 and the related notes which explain the MRP BOM explosion.

Best regards,

Tiemin

[Former Member]

Hi Simon,

You said that the materials in R3 are set to a "no MRP type".  Is this like X0?  If so then R3 MRP is not going to touch your planned orders in R3.  You say then that it is the heuristic run causing changes in the R3 order.  If so, then I think the user in the PLAF table should be your RFC user.  I don't have a system available so can't check the details. 

So, I assume you are running one of the production planning heuristics in APO.  Depending upon which heuristic you use, you can configure the Reuse Mode to either use existing orders or create new ones..  SAP_PP_002 is an example of one such heuristic. 

There are production planning heuristics and detailed scheduling heuristics.  Detailed scheduling heuristics ignore the time fence.  To prevent orders inside the time fence from moving, you either fix the operations or use the time profile with an offset in the Production Planning Run "wrapper".

Any changes to your requirements situation will result in a change in the plan after running production planning.  Detailed scheduling heuristics will move the orders.  This will be reflected in R3.

Best Regards,

Mike Kirkwood

[Former Member]

Hi Simon,

Expert Tiemen is right.  I stand corrected.  MRP can move orders for X0 materials if you use lead-time scheduling.  Thanks Tiemen.

Mike

[Former Member]

We're now running some testing where we try setting "date fixed" on the orders inside a defined time period. This should ensure that the heuristic leaves them alone.

We still don't completely understand why it would choose to move the orders around, but apparently thats' normal behavior for heuristics?

The algorithm we use is /SAPAPO/HEU_PLAN_DEFICITS with some capacity checking involved also.

If the test turns out well the solution may be to set date fixed for the orders we don't want moved->run planning->unfix again.

Thanks for the input so far, its useful.

[Former Member]

Hello,

we are facing something similar, R3 is sending an event that makes planned orders to be reexploded (as seen in /SAPAPO/RRPLOG1). According to planning procedure customizing (we are using 3), this is the case when material master or routing is modified or when sales order configuration is changed...

Our planned orders are fixed as far as PP/DS is concerned (fixed resource), but move in response to the event. We are looking into it right now.

regards,

J.

[Former Member]

We've arrived at a solution now.

We are going to run our planning like this:

step 1,set date fixed via heuristic for a number of days into future

Step 2, plan

step 3, remove date fixed again.

This can be run fairly quickly and should ensure that the heuristic will leave the dates alone.

It seems sort of a workaround, but if the planning time fence really cannot protect the orders from being changed then it will have to be like this.

[Former Member]

Hi,

not sure your solution will work. If your product is planned with planning procedure (RRPTYPE) = 3 (you said you were using heuristic based on /SAPAPO/HEU_PLAN_DEFICITS, right?), you may have BOM reexplosion when sales orders are changed (see customizing of planning procedure). This would happend at any time, independently of your step1-3 scheme.

regards

J.