Phantom Assembly Functionality

A Phantom Assembly is an grouping of child parts and or sub-assemblies for some convenience, and usually only within the context of a large, complicated product. Generally phantom assemblies are not made or sold (that is done using a higher-level, or parent, part number).


Phantom assembly items, also known as make-on-assembly, are parts that have a bill of materials, but are not usually produced with a work order. Rather, they are produced as part of a parent assembly. The material requirements for a work order would not include the phantom item, but would include all of its components. This allows a more structured organization of the bill of materials, without adding more work orders or stocked assemblies.

Someone recommended the following link for an additional conceptual overview of the phantom assembly item.

Functional Details

It seems natural to use the stock type "Assembly" (mbflag='A') to represent phantom items. They appear to be essentially the same concept. This would require changing Stocks.php to allow Assembly items to have a bill of materials.

<Phil Daintree>Yes assembly items may fit the "bill" here. Currently assembly items can have their own bill of materials. But they cannot be children of a parent BOM. What I was trying to avoid here was to have an assembly item within another assembly item in particular. The problem would be at the stage of confirming the quantities sold for invoicing where there were potentially serial or lot controlled components - and to enter the serial numbers/lots and quantities of each lot for components of components would blow away users (and me trying to program it). There is a description of assembly items in the manual as:

"An assembly of other stock items. An assembly item does not have a physical stock holding itself, nor has it a cost. An invoice for an assembly item creates the stock movements for all the components of the item and the stock of each of the components in proportion to the requirements specified in the bill of material are decremented. The cost of sales entries in the general ledger journals created by an invoice (if the link is active) is created at the sum of the costs of all the items in the bill of material for the assembly as at the time of invoicing."

It is a selling tool to sell a set of items as a single item.

However, the manual describes a Kit-Set as:

"A kit set of other stock items that should be exploded into its components when ordered. A kit set is not a physical item itself it is just a short cut to entering a number of parts onto an order. Unlike an assembly, the kit set part does not appear on invoices or orders, but explodes into its component parts for modification. It follows that kit sets do not have any cost or physical stock quantities associated with them. "

me thinks that the kit-set is the closest to a phantom on the sales side... and perhaps we should use a kit-set to build this functionality to expand the manufacturing capabilities of the system.

The to-do list then:
  • modify the BOM.php script to allow kitsets to be components of manufactured items.
  • modify WorkOrderReceive.php to autoissue/backflush the components of kit-sets on the BOM of the parent item being received
  • modify the WorkOrderIssue.php to issue the components of a selected kit-set issued to the work order. This could be tricky in that all ~the components of the kit-set (phantom) would be shown against the work order and the number of phantoms (kit-sets) would not be shown - the system would still be calling for the balance of the kit-set items to be issued and on demand. Not sure how to overcome this... might need to hide kit-set (phantom) components on a work order reports - perhaps using a new field to flag them as such (as we do for stockmovements for assembly item components on invoices)

What else???

</Phil Daintree>

<Matt Taylor>
more to-dos:
</Matt Taylor>

<Phil Daintree>
Yes that overcomes that one nicely - so long as it is acceptable to show the real components as exploded from the kit-set BOM are added to the WO Requirements.
Not sure why we need to modify stocks.php at all? I think it is possible to change from manufactured to kit-set currently. We do need to think about the error trapping here - kit-set items are now allowed to be components of a BOM of a manufactured item. But can we have a kit-set that has a kit-set as a component? How does this work for sales orders - do we wish to modify SelectOrderItems.php to allow multi-level kit-sets?? Hmmm.... maybe not perhaps we should create a new type called "phantom" after all - perhaps "ghost" type G may avoid confusion for type P - could be purchased (although I used "B" for Buy for purchased items). Better I think to distinguish this as different functionality from kit-sets. We should not be able to order a phantom so some changes required to sales order entry too.

The components of kit-sets may not necessarily be auto-issue components though ... should they? If they are simply exploded from the kit-set at the time of WorkOrderEntry.php then it doesn't matter if they are or not me thnks... the phantom then works the same as a kit-set does on a sales order - simply explodes into its components on creation of a work order. OK, the recursion is necessary to cope with phantoms inside a phantom! There is a function inside the BOMs.php script that deals with this scenario I think to check for a recursive BOM - where the item is a component of itself.

<Matt Taylor>
Here's another issue: we occasionally build and sell phantom assemblies. For example, one of our assemblies includes various pieces of hose in differing lengths. The pieces of hose are phantom assemblies, but customers sometimes require replacement hoses. In this case, we need a sales order and work order for cutting the hoses. I guess this is an argument for creating a new "phantom" type. The following describes similar functionality.

I expect it is best to explode the phantom item into worequiprements when the work order is created.
</Matt Taylor

Work order requirements would have to be selected recursively.

<Phil Daintree>
When we show an item in StockStatus.php we show the demand against the item and we would need to modify this script to show demand from all work orders - pretty sure there is some recursive function - I think maybe 10 levels deep without looking back at the code...
</Phil Daintree>

This is probably the hardest part (and the most fun to program) The cleanest solution would be a stored function in the database (MySQL>5.0).
<Phil Daintree>
Not so clean if we ever need to move to another DB... I am keen to keep all SQL as nice generic ANSI SQL all in the code of the scripts to give us maximum portability and flexibility. Hence stored procedures aren't really an option.
</Phil Daintree>

The most portable/flexible method would be a recursive PHP function.

Update: Feb 12th 2009 Matt has coded this function in so that one WorkOrderEntry.php the components of type "G" - Ghosts/Phantoms are "blown through" into the parent bill requirements - so allocations of work order component demand is properly recorded and expectations of component requirements properly reflected.

List discussion thread:

Phil Said:

If we have phantoms in the traditional/SAP definition then a
manufactured item with a BOM that contains a single phantom item will
behave as your hybrid manufactured/phantom - ie the stocked work order
manufacturable item - wouldn't this be ok for you Matt?

The research below shows that most perceive a phantom is not a stocked
item - just a place holder for a group of components used only in other
bills of materials.I do feel that we should keep webERP as consistent
with other systems as we can.

Phantom bills

A phantom bill is a list of parts commonly used together when assembling
a finished good—for example, all the screws, brackets, nails and other
hardware needed to assemble a desk. The phantom bill item isn’t stocked
in inventory, though it must have an item number before you can create
it using the Bill of Materials Maintenance window. The components of a
phantom bill aren’t typically sold separately. Because quantities aren’t
tracked for phantoms, you can’t use them as a finished good.

Phantom Bills - Components grouped together for manufacturing purposes
but never built for stock can be defined as a phantom bill. You can
print reports with phantom bills, or you can blow through phantom bills
by printing only their components.

Phantom - A sub-assembly not planned to be held in stock. A Phantom
will appear on a Bill of Material but the Kit Picking List will show the
Parts needed to make the Phantom, less any Phantom Parts that may be in
Stock, rather than the Phantom itself. The software will not expect or
need Works Orders to be raised for Phantom Parts. Phantoms are also
called non-returnable assemblies and blow-throughs.

Oracle -


A phantom assembly is a non-stocked assembly that lets you group
together material needed to produce a subassembly. When you create a
bill of material for a parent item, you can specify whether a component
is a phantom. One bill of material can represent a phantom subassembly
for one parent item, and a stocked subassembly for another parent item.

SAP R/3 -

A phantom assembly is used when you want to be able to structure a BOM
so it is easy to understand, but don't want to create too many
production orders.

Assume an auto Engine. There are hundreds of components. You might
structure them as: Engine block and parts, camshaft and parts, and 6
piston assemblies. But you don't want to create 3 production orders, too
much hassle. So you want to issue the components for the piston assembly
in the same production order as the Engine block. So you create a new
material number for the Piston assembly, but you mark it as a phantom
assembly. That means that when you create the bom for the Engine
assembly, you only have two assemblies, the Engine block and the
Camshaft. You add the phantom assembly for the Piston Assembly to the
Engine block BOM, saying it requires 8 of the phantom assembly. When the
production order is created for the Engine block, the picklist will also
include all of the components of the 8 piston assemblies.


Matt Taylor wrote:

Hi Phil,

Phantoms are also different from manufactured items, in that they
shouldn't be controlled/serialized.

How about having a system setting that defaults to disallowing phantoms
on orders? That way we can have it both ways. It doesn't seem like the
coding would be very difficult. My allow-phantom-stock flag would work
in a way similar to the allow-negative-stock flag.

I like your off topic quip.


On Fri, 2009-02-13 at 18:10 +0800, Phil Daintree wrote:

If we make it so ghost items can hold stock and have work orders against
them and be sold - then this is so close to a manufactured item -
perhaps we simply have a flag in the BOM to say whether or not to
"dissolve into components" when the item is included in other BOMs - and
perhaps stick with the traditional functionality of real ghosts not
existing at all as real items only as BOM short cuts.

Do ghosts/phantoms really exist?? Maybe slightly off topic.


Matt Taylor wrote:

Hi Phil,

I am taking a closer look at sales/invoicing of phantom assemblies, but
I would really like to make this work. This definitely needs more
testing, and I am trying to put a more complete test plan together.

I'm not sure you saw my other email, in which I wrote the following.

From a part sales standpoint, phantom items are no different from
manufactured items. The key here is that phantom items are not
exploded on a sales order.

I think what I have done here is easier to understand when you think of
phantom items (mbflag=G) as being identical to Manufactured items
(mbflag=M), with one noted exception: Phantom items are dissolved when
allocated to work order requirements. Otherwise, they can be sold,
built, transferred, etc. just like manufactured items.

Being able to sell phantom assembly items is important for 2 of the
companies I work with. One of them is using IntuitiveERP (that other
proprietary system I mentioned), which definitely allows phantom items
to be manufactured and sold. The other is starting to use webERP, but
really would like to have this extra functionality.

I think if you experiment with what I have done, you will find that the
manufacturing part works well.


On Fri, 2009-02-13 at 14:10 +1300, wrote:

Hi Matt,

As I read the SAP article the piston assemblies are just a phantom BOM - not a
real item at all but part of the engine BOM - the piston phantom is never going
to hold any stock of its own - you can't make a work order up for a phantom, its
just a short cut for including the piston assembly components x 8 times for a
V8.(The document explicitly says that if you wish to know how much labour in
each piston assembly then it is no longer a phantom) since you can't create a
work order for a phantom and the phantom cannot hold stock it is just a way to
make BOMs for sub-assemblies without cluttering the main BOM and perhaps
simplifying it. Since a phantom does not hold stock of its own and you cannot
make work orders up for a phantom then you cannot invoice it. If you invoice it
this would be functionality the same as a kit-set or assembly- that we currently

If a phantom could hold stock of its own and be invoiced then it would be
identical to any other manufactured item. Of course manufactured items can be
components of other manufactured items and have their own BOMs etc.

It is easy to get confused here, but I think I have it clear in my head. Now is
the time to write some documentation !!

As an aside (and to propogate more confusion :-)the problem with having phantoms
(and assembly items with serialised/lot controlled components) on an invoice is
that we want phantoms to be able to contain a bill of material containing
components that may be serialised or lot controlled. When the dispatch of the
phantom (which is clearly nonsense from the above in any event) is confirmed to
create the invoice, the components of the phantom would need to be reduced in
proportion to the quantity required on the BOM multiplied by the number of
phantoms sold - now which serial numbers of the components of the phantom were
used and which lot numbers of the components of the phantom were used - these
would need to be recorded and entered at the time of invoicing which would blow
the minds of the folks invoicing if we had the functionality to allow it - we

I have specifically disallowed assembly items from containing serialised/lot
controlled components to avoid this problem. This is the very same reason why we
cannot use an assembly for a phantom because we want the phantom to be able to
accomodate serialised/lot controlled components.

There is a little bit of error trapping we need to build in to make sure we
don't end up with a stuffed system for our ghost items. Work Order Entry not to
allow selection of ghost items for work orders, SalesOrders not to allow ghosts
to be selected for a sales order. Also the logic for allowing ghosts to be
changed to other item types...


Affected Modules

Stocks.php, WorkOrderEntry.php
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki