Well, it somewhat depends on what you mean. 

There is no single format to a BoM that I am aware of.  When I created one (in Access, not Crystal), I just copied the existing format the company was already using.  It was fairly straightforward.

Generally, it's simply a matter of doing a join between an Orders table, an OrderParts table, and a Parts table (assuming your database is set up along those lines).  Since all the Orders information will be the same, you can put it up in the Report Header/Footer (or put it in a top-level Group Header/Footer, if you want to be able to print multiple orders at once).  Your Details section is just the list of parts and quantities.

Now, if the issue is with assemblies (i.e., parts that contain other parts, all of which need to be listed on the BoM, preferably in some kind of tree form), then you have a trickier situation.  It's a pretty classic one, though.  IIRC, Brian's book has a section addressing it.

If you could give us more specific questions, we might stand a better chance of helping you solve your issues.

It's under Hierarchical Reports, beginning on p.115 (and having more information beginning on p.152).  Brian actually uses the org chart example rather than the subassembly example, but it's the same principle.

I don't think this is going to work Lugh. In the example in the book the employee employer relationship is one to one no matter how many levels you go down. In my situation I have kits or assemblies that contain a part that may be in other assemblies so its a one to many type of relationship in that instance. If i used hierarchical grouping I would only get one assembly even if there was more than one. Someone suggested creating as many aliases of my PartMtl table for as many levels as I have. It involves daisy chaining tables. Do you know anything about that?

Sure.  That's relatively easy.  You just add the table to your report multiple times (in your case, once for each level of hierarchy).  Be sure to alias them intelligently, so that it is easy for you to tell which copy of the table belongs to which level.  The "daisy chaining" is just a matter of connecting the links in such a way that the foreign key of each table is linked to the primary key of the table above it (remember to use outer joins).