Journal of Materials Processing Technology 139 (2003) 535–538

Analysis and implementation of the BOM of a tree-type

structure in MRPII
Ji Guoli a,∗ , Gong Daxin a , Freddie Tsui b
a Department of Auto., Xiamen University, Xiamen 361005, PR China
b Tops Datacom Limited, Hong Kong, PR China

Abstract

According to the character of the tree structure of a bill of material (BOM) in MRPII, a tree-structure storage model has been proposed.
It uses two tables to record the parent components and the child components. Each table has a location point combined by three fields.
Other link fields in the child component table present the relationship between levels of a product tree. Compared with Gozintograph mode,
the BOM design on tree structure has many merits.
© 2003 Published by Elsevier Science B.V.

Keywords: BOM; Tree structure; Assembly; Component

1. The structure analysis of BOM
The bill of material (BOM), which is the technique
document on illuminating the product structure, is used
to demonstrate the structure and relationship between
the final product (never processed in current enterprises),
sub-assembly (composed of other parts, and used by other
sub-assembly or final product within current enterprise),
parts or materials (produced outside), as well as the corre-
sponding quantities of the subordinative parts and materials
of each assembly. The following figure (Fig. 1) shows the
tree structure of a lamp: each object presents itself as a
parent item or a child item. As a final product, the lamp
is limited as a parent item, and items such as wire, can-
nulation, plastic strap, and steel strap, which belong to the
lowest level, cannot be parent items, whilst other item will
be treated both as child items and as parent items.
A structure model is proposed to record the product tree.
To record parent components and child components, two
tables are used. Both of them have the same three address
fields, which helps to indicate, which product tree the object
belongs to, and on which level in the tree it lies, and of
which position on the level it has been fixed. In addition,
two special link fields are added to child component table:
one indicates which level the current item’s parent belongs
to, whilst the second indicates whether a child of the current
∗ Corresponding author.
E-mail address: glji@jingxian.xmu.edu.cn (J. Guoli).
item exists. The record structure model of a child component
table is shown in Table 1.
Now one comes to the disassembly of the product tree.
Suppose the start point is endowed to some known parent
item, thus all its child records which link to it can be found
in the child component table. Then by dint of the fifth field,
any child item which still has a child item can be identified,
and its corresponding record in the parent component table
can be reached by the link fields. Circularly, considered the
new known parent part as the start point, and repeating the
procedure above, the object will be fully disassembled.
A clear example based on Fig. 1 is shown in Fig. 2 to
demonstrate the storage structure of a BOM. Because only
one final product exists, the product number remains un-
changed. The location number is obtained according to the
spontaneous sequence, in practice, according to the input se-
quence. The parent loc. field in the child component table is
the pivotal field which keeps parallelism with the location
no. field in the parent component table.
2. Management of a BOM
2.1. Creating a new BOM
Usually a new BOM is created by creating a set of single
level BOMs, each of which contains a parent item and its
direct children. Taking the lamp for example, the top level
BOM is shown in Fig. 3. The structure information of the
product tree such as the product number, the level number,

0924-0136/03/$ – see front matter © 2003 Published by Elsevier Science B.V.

doi:10.1016/S0924-0136(03)00520-X
536 J. Guoli et al. / Journal of Materials Processing Technology 139 (2003) 535–538

Fig. 1. The tree structure of a lamp.

Table 1
A record structure model
Product no.a Level no.b Location no.c Parent loc.d Child marke Material namef
a The serial number of the final product.
b The serial number of the level, the item belongs to.
c The serial number of the location on the level.
d The parent item’s location number.
e Boolean to indicate the existence of a child item.
f User-defined fields.

Fig. 2. Records of the lamp.

the location number, and the parent item location number,
is created automatically. The child Boolean field is reset
when a new BOM is set up with the current child item
as a parent assembly. Something worth mentioning is the
automatic maintenance of the position number, a benefit
function to keep the position as continuous as possible. For
example, the next new child item will fill the vacancy if
the second position item has been deleted. This rule can be
applied to any other continuously varied fields.
To improve efficiency, duplication of a BOM must be al-
lowed. To an assembly, the scope of duplicating includes the
whole sub-tree. The implementation involves three changes
to the structure information: replacing the original product
number of all the objects in the sub-tree with the product
number of the target product tree; treating the summation of
the original level number and the target level number as the
new level number; and setting a vacancy or a new position
of the target level as the position number.

Fig. 3. A single-level bill of material.

 J. Guoli et al. / Journal of Materials Processing Technology 139 (2003) 535–538
2.2. Editing and delete a BOM
Unless it is at the lowest level, a single level BOM is not
allowed to be deleted separately. Deleting a BOM is equal to
deleting a sub-tree. Note that the related records both in the
parent part table and in the child part table must be cleaned.
Fortunately by those locating fields, it is not necessary to
rely on the complex algorithms to finish the deletion.
As to editing, just note that replacing an assembly can be
disassembled into two part: delete the current assembly and
create a new assembly.
2.3. Audit the BOM file
Many aspects are involved in the implementation of an
audit. An instant step is to check some necessary fields not
omitted and filled with correct data type by the user. A fur-
ther step is to check whether the information of one assem-
bly remains synchronized in different product trees, which
ensures the veracity of updating and statistics of the assem-
bly cost. A main aspect of audit lies in the rationality of the
BOM file. Here the rationality mainly means no recursive
problems hidden in a BOM, and no incompatibility lying
between any two items. To practice the former, a process
searches the whole sub-tree and traces back to the root of
the product tree along the links to ensure no reappearance
of current assembly. As to the latter, if there are only a few
simple rules for compatibility, an instant audit is enough,
otherwise a expert system is needed.
3. Graphic user interface
A graphic user interface (GUI) for a BOM cannot sim-
ply be explained by using some pop-up windows with grey
tables in them. For users, a graphic interface for a BOM
shall mean that what they operate are all 3D practicalities.
If this is still a little utopian for developers, as the alterna-
tive, a 2D expanded product tree is easy to realize by these
visual treeview controls. Unlike the pure text user interface,
GUI always make users very clear about the position of the
object they are operating, and moving between levels of a
BOM becomes very convenient.
4. Flexibility of the tree structure
The discuss of flexibility mainly focuses on this problem:
how to deal with the diversification of the products. Here
the diversification means those assemblies and final products
with few differences. In practice, the varieties derived from
a product can be counted in hundreds of thousands. Take,
for example, that a car of common type can be assembled
into millions of types through all the combinations of its
assemblies.
537
Fig. 4. A example of assembly relationship.
There are mainly two methods to manage the BOM of
diversiform products:
(1) treat each variety as a independent product tree;
(2) only create product trees for those subordinate objects
of polymorphous products. The BOM of a given poly-
morphous product is created only when needed.
The difference lies in that the latter is more suitable for the
varieties produced in a short period and with a huge quan-
tity, but they deal with the following state through the same
way. As Fig. 4 shows, assembly A1 and A2 have the same
sub-items B2 and B3 which is on the same level. To man-
age the BOMs conveniently, a phantom BOM is imported
to package up both B2 and B3. It will be treated as a whole
and inexistence in all kinds of statistics.
Suppose another B5 is an alternative for B2: it can be dis-
tinguished by a serial number added to the record structure.
Virtually, method two creates a temporary BOM, of which
the subordinate objects are derived from the basic BOM li-
brary and the life cycle of the records will last to the com-
pletion of the order for the product before those records are
separated and saved as a history back-up for future refer-
ence. Thus the audit becomes a comparatively complex job.
Although, it is not difficult, the implementation of either of
the two methods is of no help in cutting down the redun-
dancy, which is part of the reason for the usage of the Goz-
intograph storage model.
5. A comparation with the BOM of a Gozintograph
model
The storage structure of a Gozintograph model is known
as a network structure which can avoid redundancy effec-
tively. A typical Gozintograph is shown in (Fig. 5).
Its standing characteristic is that each object appears only
once. No doubt the record structure becomes more complex.
Fig. 5. A typical Gozintograph.
538 J. Guoli et al. / Journal of Materials Processing Technology 139 (2003) 535–538
Fig. 6. Records for Fig. 5.
As the following figure shows, the left presents an attribute
table (all attributes are omitted), and the right a structure
table, both of which are used to describe Fig. 6. The field
ADDR AS PARENT in the attribute table presents a set of
locations and it appears in the structure table as a parent item:
the field ADDR AS CHILD can be explained in the same
way. A record in the structure table presents a connection
between a parent item and a child item. The parent stores
its location of the attribute table in field PARENT ADDR,
and the child in CHILD ADDR. The child can find its next
parent and the parent can find its next child in the structure
table, respectively by the field NEXT PARENT and NEXT
CHILD. Put simply, this storage form describes a network
by several pointers which naturally increase the difficulty in
editing and maintenance.
The Gozintograph model deals with polymorphous prod-
ucts by adding attribute and Boolean fields, which increases
the difficult in establishing the requirement plan and this case
will be aggravated if the difference between products just
focuses on the quantity of their sub-items. When it comes
to hidden cycles in a product tree, this model has to depend
on some special maintenance routine to avoid a dead loop.
6. Conclusions
The material management module is one of the core mod-
ules of the MRPII system and the BOM is the foundation
stone of the material management system, so the stability
and flexibility of the storage model are the key to the in-
formation system of the entire enterprise. The tree structure
storage model is simple, smart, easy to implement, suits
products with both stable and complex structure and those
with fugitive and similar structure. This model does not pose
a limit on the depth of the product tree. With the develop-
ment of hardware technology, the effect of redundancy will
reduce to the minimum. It is certain that this model will be
applied widely in the future.
Acknowledgements
This work is supported by the Natural Science Foun-
dation (E0110007) and the Key Research Project no.
2001H020 of Fujian Province, and the Research Project no.
20001601 and the Construction Project no. 3003 of Xiamen
University.
Further reading
[1] A.-W. Scheer, Computerized Enterprise Management, Shanghai Tech-
nical Literature Press, Shanghai, 1994.
[2] H. Zou, M. Su, Theory and Practice of Modern Enterprise Manage-
ment, China Material Press, Beijing, 1994.
[3] Y.-q. Zhou, B.-y. Liu, B.-j. Liu, Theory and Implement of MRPII,
Tianjin University Press, Tianjin, 1994.