We run Baan Vc and I'm looking for clues to find a cause for this situation: Yesterday, in our regenerative planning run, the EP system created a planned production order for an item for which there is no demand. According to the orders details pegging, cprrp110s000, there is no order calling for the new planned order (it is unpegged). There is also a signal on the item which tells us there is no demand - hinting, I think, that we should remove the order.

There is a similar item produced for a manufacturing project and it has a different (i.e., customized) bill of material. The planned order created yesterday is for a standard version of the item. There is also a customized version of this item in inventory and the version in inventory has a different bill structure than the one on order for the project.

Has anyone seen this situation where no demand exists for an item yet the system generates a planned order?

At the moment, I'm just looking for ideas from which I can continue troubleshooting.

Is safety stock causing this?

No, there is no safety stock on this item.

I've put together a query and it identifies 19 items without demand being planned. The investigation continues.

Out of more than 17,000 planned orders, this phenomen effects 8 items. Each item has an order type of "To Order". At a point in the past they were copied into manufacturing projects to be made as customized items.

In each instance, the estimated materials of the project parent-item has a customized version of the standard item. Example.

Project 30000034
Custom Item 300000342003650
Standard Item 2003650

The customized item has been produced and is already in inventory but has not yet been issued to the parent item's production order.

If I change the standard item's order type to "Anonymous" and run Simulate Orders, the unneeded planned orders go away. If I change the standard item's oder type back to "To Order" and run Simulate Orders, the unneeded planned orders return.

At the risk of stating the obvious. something is telling the system there is demand - for the standard version.

The hunt continues.

Sorry for any confusion. I should have said Order Policy is To Order, not Order Type.

Have you run the session Rebuild planned inventory transactions lately? Run when no users are on the system.
Then have a look at Planned Inventory Transactions by Item.

Yes, I checked planned movements both in warehousing and enteprise planning.

I'm concluding that there are bill of materials differences between the customized and standard versions of the items that are driving the demand. The system is ordering multiple quantities and so doesn't peg the planned order directly to another order, since the quantity is going to multiple orders.

The reason the users can't see this is on these items the bills of material are quite large, hundreds of items deep, and they say they can't take the time to review these situations line by line.

I found an unpegged item with a small bill of materials - and it took me two hours of query writing and snooping around to find it.

I've seen this before but they haven't complained of this for months. Now I'm seeing the same items in the bills and estimated materials but the estimated materials has the components in a sequence different than the bills of material.

There are eight such items in our system now, out of >17,000 planned orders, or 0.04%. In all eight cases the sub-assembly was manufactured and put into inventory. The sub-assembly's estimated materials list does not match, exactly, the current PBOM for the item - either standard or customized.

BOM
pono 1 item ABC
pono 2 item DEF
pono 3 item GHI

Estimated Materials
pono 10 item DEF
pono 20 item ABC
pono 30 item GHI

I'm concluding that even though the items match in the bill vs estimated materials and there are quantities now on hand, the fact that the position numbers are different is causing EP to see these as structurally different items. Thus, even though the same item exists in inventory, it's BOM/Est Matls structures are different and so it creates planned orders using the BOM in effect at run time.

At least that's the theory I'm going with now.

Apparently the difference in sequence numbers is not the cause of the problem but a natural effect of creating an estimated materials list. It will always have sequence numbers different than those of the BOM.

The mystery demand is still there. There are no planned inventory movements in whinp100 or cprrp010 to account for this demand, yet the system thinks it needs the items. Also, there's no safety stock, minimum order quantities, etc. that I can see driving this.

Can anyone think of other sources of demand that might be involved?

Hi, may be it's only an idea:
have you looked in the module planning from the PCS-Project?
Also, if in the module planning is no demand, generate the network planning onetimes. Maybe there were old demands, that are not deleeted...
greetings
Dirk

Did you check the 'derived from' items?
I bet one of those has your 'hidden' demand

I tried unlinking the 'derived from' on the customized version of a standard item and the demand for the standard item still seems to exist.

I've been slogging through what Baan code we have regarding planning and I'm coming up blank. At the moment my hypothesis is this: It's something to do with the timing of our weekly regenerative run and the initialize scenario run. Normally the regen run is on Saturday and the initialize scenario run is on Sunday. Last week we did the regen after the initialize on Sunday because we were conducting a physical on Saturday.

That's just a guess but it's the only thing that's changed in our little world. I'll watch it this weekend and if we still have the problem after the regenerative run on Saturday then I'll throw it at Baan as a problem.

That must be a hidden feature....(timing of the run resulting in the presence of demand)

There may be other derived items!
(just run a query on the 'dfit' field)

Check to make sure you don't have any negative on hand balances. We run with negatives not allowed, but several systems ago I worked with one that generated planned demand to offset negative balances (to bring them back to zero).