Sales orders ONLY in APO and not in R/3

[Former Member]

Dear Friends,

I have this peculiar but very critical problem wherein:

APO creates an extra schedule line to an ALREADY EXISTING sales order only in APO with a quantity in decimals like 130.320 PCs or whatever. Also, important to note is that this line has a required date very much in the future starting from 12-2009. Also, this sales order schedule line is non existent in R/3!

- I have checked the R/3 SD tables but nothing which relates to this qty.

- I have checked the sales order changes, but nothing in the history which suggests that someone might have changed it.

- I checked the UOM both in R/3 & APO but nothing.

Now, the problem is that:

How & what created this sales order?

If it is in APO, then y it isnt being sent to R/3 like all the other normal sales orders?

Most critical: APO sees this reqt & automatically creates a planned order (bckgrnd) which is then sent to R/3 as a recpt!!

Thanks in advance !

[Former Member]

Just one more point: we use SCM 5 and ECC 6.

R/3 is the master for Sales orders creation hence the movement is always unidirectional from R/3-APO - but these "problematic" sales orders are not in R/3 at all, they are only in APO, which is very puzzling!

[Former Member]

Hi,

Are you running backorder processing as it can create additional schedule lines in future. Also check whether the additional schedule line has any confirmed qty or not??

And the reason why salesorder is not flowing back could be because of no publication type defined for the salesorder for that location.

Hope it would help.

Thanks & Regards,

Jagadeesh

[Former Member]

Thanks but we dont run backorder processing at all and in the confirmed qty column it says "confirmed" with exactly the same quantity.

And yes, u r rite since publication for sales orders is uni-directional hence these sales orders are not sent to R/3.

We have also done the livecache consistency check in APO but no result.

[Former Member]

Team Eusap,

Sounds like you have an ATP integration model activated. If so, I can't understand why you wouldn't want to publish Sales orders back to your OLTP. What apps are you running in APO? Eg, PP/DS, DM, GATP, SNP, etc etc. What functionalities are you using in each app?

Rgds,

DB49

[Former Member]

Hello Dogboy,

We publish all transactional data back to R/3 aswell, sorry for my previous comment.

An important point to note is that - we are on APO sinec last 3 years but never faced this problem until last month.

We perform ATP check in R/3 and dont use APO for the ATP check.

We have DP (to generate forecasts), SNP (which acts on those forecasts and creates PRs for the network), PPDS (to create planned orders for in-house produced materials).

A sales order is always created in R/3 then confirmed after availability check in R/3 itself.

We do have an ATP integration model running before all the other int mods in R/3.

Hope this helps!

[Former Member]

Team Eusap,

If you have an ATP IM running, this is probably the functionality that created the order in APO.

There are a number of things that could have prevented the order from being re-cifd back to R/3. Many of them are 'momentary' and not worth the effort to track down.

First thing to do, check for queue errors. /SAPAPO/QM. Check inbound and outbound. resolve any errors.

Next, run reconciliation (/SAPAPO/CCR). The order will normally show up and you can delete in APO here. Other possibilities are Temporary Quantity Assignments, which you can delete in /SAPAPO/AC06. Blank out name, set generation date to 'from a long long time ago up until yesterday'', Select product availability, all 4 checkboxes, your products/locns, execute. Also check consistency of Pegging areas, /SAPAPO/DM_PEGCHECK, check all checkboxes, uncheck test, execute. Run /SAPAPO/QM again to ensure you have generated no additional errors. Let me know if the order still cannot be deleted in APO.

To prevent this in the future: You say you want to do your ATP in R/3. If so, de-activate all ATP models for all materials where you want to do the ATP in R/3. Probably should deactivate ALL ATP models.

Regards,

DB49

[Former Member]

Dogboy, first of all thanks for your kind help so far, very much appreciated!

I forgot to mention that I ran livecache consistency aswellas the QMgr in APO but it shows nothing in regards to these materials.

I also forgot to mention that we run "material independent" ATP intmod which transfers ATP settings from R/3 to APO.

As per your advice, I ran both pegging consistency and temporary qty assignments BUT nothing happens. Those entries stay as it is

[Former Member]

Team Eusap,

You say you ran LC consistency (which would be /SAPAPO/OM17). Did you also run CCR as I mentioned earlier?

Although there are no Queue errors, it is possible that someone has deleted the item from the queue. So, continue.

You can try to delete the order in APO using program /SAPAPO/SDORDER_DEL. Select Delete on database tab, deselect test, select the appropriate product/location(S). Select 'without check'. Select both boxes in Additional functions. Since you are not using GATP, you are not using allocations, but it is OK to select these items too. Execute. Stay away from the 'Delete all DB Sales order Data" tab!, or you may have to re-cif all your orders across. Now redo your LC consistency.

As far as your models are concerned, you need to assure yourself that there are no ATP (transactional, not material independent) models open. Use CFM5 to search.

As for the material independent CIF, it is a good idea to inactivate this model after the initial transfer. If you ever do any ATP config within APO, this model can overwrite some of the settings you created in APO. Usually this is undesirable.

Let me know if any of the above steps allow you to delete the APO order you don't want.

Rgds,

DB49

[Former Member]

Hello Dogboy,

I run the queue manager and reconcile CCR report on a daily basis, I ran the livecache last week aswellas yesterday but nothing happened. There are for sure no ATP models which are material dependant since we r the only ones who manage all INTMODs. As far as deleting those sales order entries are concerned, I had already deleted them last week using the report, but they came back again hence thats not an option. We need to get to the root of this problem, just deleting will not help.

Note: All the affected materials are pure MTO's.

[Former Member]

This problem was due to the fact that both sales orders & planned orders had a "number range overlap"; we changed the planned orders number range & its fine now! Thanks for all your replies!