If this seems too long, skip to the last paragraph.
Philosophy wise, it is ideal if the model directly drives the entire process. However, this presumes the model is exactly accurate and can exactly represent every condition. When the model is incorrect or there are situations that are not exactly represented, the directly-driven output needs a method to discover the errors and a means to represent that which cannot be exactly represented. In addition, not all processes benefit from being gated by model creation.
My preference is to extract the BOM from the models and dump it into an independent document. The independent document has places to record the location of each balloon and related flag note, bounces the manual list against the extracted BOM, allows for mis-named/custom name part conversion, and generally tracks and explains why everything is where it is, both in paper space (sheet and zone) and function space (bracket with attaching hardware.)
I export the information from the model tree, in which I generally keep items in groups. Want to know what a certain screw is used for? Look and see what it's grouped with. This just gets dumped as-is as input to the workbook. If someone thinks there is a need, just dump out another copy of the model tree and import again. Include in the dump any parameter fields desired - part names, material, color, description, et al.
The next level up is the names correction page. Because PTC (and all other CAD companies I think) have a problem making arbitrary alterations to parts on installation, it's pretty common to have to make custom models of things like cables, one for each of the various installations.
The names corrections page is where the base part names are, by equation, stripped of suffixes, where underscores in filenames get replaced with slash characters, and so on. Anything more than that the user can type in. When it's manually entered, the cell format indicates it's a manual entry overriding the model.
The next step collects all the balloon and flag locations per item number. This is a manual process as PTC doesn't have an easy means to report this information, but since the coordinates of the first balloon sets the sheet and zone, there's a lot of copy/paste. These are used to accumulate the total that is identified on the drawing, compared to the qty in the model, and to the qty that is shown on the PL. In addition, it reflects back the item number and item name from the PL, so that groups of balloons can be seen to contain expected items - nut, bolt, washer rather than nut, nut, washer.
The PL itself is a standalone sheet. One can type in anything, but I prefer to just copy and paste from the model tree dump. As items are added to the PL, comparisons with the corrected model information and conditional formating indicates process status.
It seems like a lot of effort, but it includes verification that the on-drawing BOM doesn't/can't have. In addition, I never experience lost balloons, balloons that wouldn't show in a view, BOMs where fixed items that were removed from the assembly left unexpected gaps in the BOM listing. It never required complex relations or filters. It makes obvious that the balloons are correctly grouped, so this provides a check for that as well as a way to check that note flags are correctly applied. It provides independent traceability for not only what items are used, but also how they are used together. Nothing on the drawing BOM will indicate the .250-UNC nuts are used with the .375-UNF screws, but that info comes along for the ride from the model tree.
Because the PL front part can be completely generated and released before any assembly is done, but remains useable to validate against the model, exceptions and discrepancies can be discovered and managed, Purchasing can be off purchasing things that Engineering hasn't had the need or time to build models of. Example, a pneumatic/electronic anti-lock braking system needs all the items the supplier suggests for the PL, but engineering doesn't need to build the 30-40 models of little piece parts and assemble them in order to get that done, but will in the future need to verify that all the parts are in the model so that Tech-pubs can create the documentation.
Being Excel, it's readily accessible for other groups to use, review, copy and reformat. It always gets printed full size, at least more often than trying to get a J-Size BOM onto A-size paper. It doesn't require an expert to manage; it doesn't need a Pro/E trained user to make use of most of it.
If you are creating PLs with hundreds plus unique items and thousands of components spread across perhaps dozens of J-size sheets and someone wants to validate it, the method above has been more reliable due to self-check and accessibility than any on-drawing auto-BOM. If you are dealing with D-size drawings with five or ten parts, the above method may be break-even, unless you have to create custom complicated relations to get what you want to appear where you want it. There must be organizations that can cradle-to-grave it from Engineer to Shipped product without leaving the fully electronic farm, for which this would not be useful, but for those not experiencing error-free, hands-off, no hassle BOM management, I can say it works well.
