Disassembly percentages
Hi Team,
This relates to Post: Feature Request - Auto Disassembly should reference the Assembly Job it was created from.
I'm creating a new post as the above post was created some time ago.
We are experiencing similar issues with disassembly costs.
Currently, splitting the costs at the point of disassembly results in incorrect on-hand values for individual components. This means we cannot reliably use these values for purposes such as pricing and cost analysis.
We attempted to address this by adding disassembly percentages to our BOMs. However, this has introduced a number of additional issues and is extremely time-consuming to maintain. We regularly update our BOMs for various reasons, and each update requires the disassembly percentages to be reviewed and adjusted accordingly. This is not a viable long-term solution.
A more effective approach would be to create links between assemblies, sales orders and disassemblies, allowing an assembly to be disassembled using the exact component costs recorded when that assembly was originally created. This would ensure that component values remain accurate and provide a much more reliable basis for pricing and inventory management.
We would appreciate it if this could be considered for development.
Thanks so much.
Related to
Comments
3 comments
As far as I know, auto-disassembly was intended for a slightly different task than we are discussing here. We are discussing reverting assemblies that we have built and maintaining the input costs, whereas the auto-assembly & disassembly processes are designed to be complementary actions that are part of the sale and purchase flows.
Auto-assembly is triggered by a sale. It is what other systems call “kitting” and assembles the components into a single salable SKU when the sale is processed.
Auto-disassembly is intended to be part of the purchasing process. When you buy e.g. a case of detergent under the case SKU, auto-disassembly will immediately break that down into the singles SKU.
I believe the issue here would maybe be to provide an override that uses the underlying cost or ave cost to split the cost as opposed to have to use the percentage splits. I can see the value in this and we have has clients request this
Hi,
I looked at both issues. The root cause is the same: Cin7 Core's disassembly doesn't reference the assembly job it came from. So it splits the cost using the BOM (evenly, unless Disassembly cost % is set) and uses the job number as the batch.
Auto-disassembly is also designed for one specific case: breaking down a purchased case when the purchase order is completed, for products you don't sell as the parent. It isn't meant for returns or for undoing bundles.
Here's what I recommend:
CostPercentage_ForStockComponentOnlyfrom current average costs, and re-import it.Until Cin7 adds a reverse-assembly function, keeping costs and traceability correct needs one manual step per return or unwind. We've also put together a feature request for you to submit.
If you'd like help setting this up, such as reviewing your BOMs, building the cost-percentage spreadsheet, or walking your team through manual disassembly, feel free to reach out to me directly at omar@scitex.ltd. I'm happy to help.
Best regards, Omar SciTex – Cin7 Core Partner
Please sign in to leave a comment.