Showing results for 
Search instead for 
Did you mean: 

Identify part quantities using assembly statistics

Valued Contributor
Valued Contributor

Hello Developers ..
As the title suggests, I want to know the quantity of the same parts used in assembly statistics.
Customize the number of quantities from the assembly statistics to the Property Manager
I want to automatically enter the "quantity" item.

First, I want to know how to subtract an identified quantity from the assembly statistics list.
If you know the code above, thank you.


Without entering the quantity into the Property Manager ...
It can also be input to a variable table or the like.

I see an sdk document (occurrence)
I do not know how to count quantity ...


Re: Identify part quantities using assembly statistics

Gears Esteemed Contributor Gears Esteemed Contributor
Gears Esteemed Contributor

What specifically is it that you are trying to do?  Since you have the ability to run reports and get occurence counts that way for specific components, what do you need code to do that is different?

Production: ST10 MP7, Testing: SE 2019

Re: Identify part quantities using assembly statistics

Valued Contributor
Valued Contributor

Yes, you have to get a reference to the occurrences collection. Then for occurrences with the same part number (or file name) you would add their quantities together and just have one line in your "part quantities" list with the total quantity for that item. The property of the occurrence you are looking for is simply .Quantity.

Terry Tyson
Software Automation Designer

Re: Identify part quantities using assembly statistics


From my knowledge, identyfing component quantities in an assembly is far from being a trivial task. Not sure if there's some kind of direct approach I missed, but in my experience, I had to develop a recursive methodology.


I will try to explain:


Studying Occurrences, you can easily get the quantities of the components in one level, but any of those Occurrences can also be an assembly with further Suboccurrences and so on. Maybe the same component can be located in different branches of the hierarchy, so you need to study all branches and carry along all the components found, in order to updtate their quantities or add new, if not previously found.


When estuding recursively, you must multiply each branch content by the quantity of each branch, and also have in mind other importants aspects, depending of what you are looking for in your design:


-Flags such as HideInSubassembly or ExcludeFromReports from SubOccurences and their counterpart in Occurrences

-User defined Quantities, wich should be multiplied over branches content

-Visibility: dealing with visibility is complex, since different occurrences of the same assembly can have different visibility states, and so each one needs to be studied as a separate case. (From my point of view, most in-house apps should include an option for just limit to visible components, for more flexible workflows...). Without visibility filter, the workflow becomes far more simple, fortunately...


Also, depending on the level of the recursive analysis, you must differenciate between SubOccurrences or Occurrences, which adds another interesting point.


So, if you want to have any assembly structure suitable of your analysis, be ready for a funny recursive party.


Hope this helps