Feature Request - Auto Disassembly should reference the Assembly Job it was created from

Chris

Hi Team,

Currently, when “auto-disassembly” is on for a BOM product;

  • IF the percentages are not set in the “Disassembly Cost %" in the Bill of Materials tab, then it will split the total cost, equally across all of the items.
  • This gives a problem because its changing the unit costs per item when it is restocked, which is not good when trying to set pricing, margins etc.

Problem 1 - Unit Cost Change When The Auto-Disassembly is completed

Auto-Assembly #FG-0001 of Back to School Bundle

  • 1x - SKU001: Notepad - $12 - Batch F5
  • 1x - SKU002: Pen - $2  - Batch F1
  • 1x - SKU003: Pencil Case - $7 -  Batch AA
  • 1x - SKU004: Glue Stick - $3 - Batch GG
  • Total = $24

Customer returns the BOM product and if the percentages are not set then the system is going to restock items as follows;

Auto-Disassembly #FG-0002 of of Back to School Bundle

  • 1x - SKU001: Notepad - $6
  • 1x - SKU002: Pen - $6
  • 1x - SKU003: Pencil Case - $6
  • 1x - SKU004: Glue Stick - $6
  • Total = $24

Now, support said we could set the percentages manually, but that isn't a viable / sustainable solution, because the unit prices of the individual items that make up a BOM item, do change on each Purchase Order along with the currency. This would require us having to manually recalculate the percentages each time a new PO is made (if those individual items are on the PO) using a calculator, which will lead to errors or simply be missed, depending on how many BOM products we have (could be hundreds).

Problem 2 - The batch number being inputted is the Auto-Disassembly FG-Number, and is not being based on the Original Batch number it was produced from

When auto-disassembly is on, it is putting in the batch number as the assembly job number.

Auto-Disassembly #FG-0002 of of Back to School Bundle

  • 1x - SKU001: Notepad - $6 - Batch FG-0001
  • 1x - SKU002: Pen - $6 - Batch FG-0001
  • 1x - SKU003: Pencil Case - $6 - Batch FG-0001
  • 1x - SKU004: Glue Stick - $6 - Batch FG-0001
  • Total = $24

Clearly, this is wrong, because if that item is later individually sold, there is no such batch sticker attached to the product with batch FG-0001. If you look at the notepad, that had batch F5, not FG-0001. This will mean every time an auto-disassembly is completed, we would need to do a stocktake adjustment, remove anything with these FG-0001 batch numbers, and then add it back into the inventory with the correct batch number, otherwise if the notepad was later sold individually, the system is going to watch its batch to be FG-0001 which is a problem. The other thing would be to undo the auto-disassembly job and then change all the numbers - but we might as well be doing a manual disassembly from the start.

Suggested Solution

  • If a Sale Order comes in for a BOM product, then it auto-creates the assembly job number that is linked/related to the SO number
  • If a customer returns that SO-nunber, then Cin7 knows there was a linked assembly job number associated to it.
  • Cin7 should then reference the original assembly number, so that it inputs the correct values for the Batch Number, Bin Location, and Unit Prices, so that everything matches up correctly in a 1 to 1 manner for the individual components. 
  • This is the only logical sense here in my opinion and will resolve both issues.
  • Currently, we cannot use Auto-Disassembly in its current form due to the way it splits the pricing equally, along with inputting the batch number off the assembly job, instead of the item itself. We are currently having to create manual diassemblies, and then open/reference the original assembly job to know the unit prices, bin location, batch number.

Hope that makes sense, I feel these two issues can be resolved with auto-disassembly, if it simply referenced the original assembly job.

 

Related to

1

Comments

2 comments

Date Votes
  • Comment author
    melanie

    Totally agree with Chris.
    This is a significant issue and is causing lots of unit cost issues for us.

    We assembly bundles in Cin7 to protect stock for our website listings. Sometimes we need to disassemble if we receive more stock on a delivery or if we don't sell the forecasted bundles. 

    The disassembly percentage split can't be set in the BOM as it changes from batch to batch.

    It's crazy that Cin7 doesn't have a FIFO method for this - it should be recording the cost of the components at assembly, and then using those units costs on disassembly.
    Hopefully the create a fix for this soon as this is having a big impact on our business.

    0
  • Comment author
    Chris
    • Edited

    Hi Melanie,

    I gave up waiting. I avoid using auto-disassembly all together, until they listen / implement the change.

    What I end up doing is;

    • Minus the BOM sku manually in the availabilty tab
    • Add the individiual skus quantity (if that batch/product is in stock) through the availability tab
    • If that batch/product is not available (sold out), then you need to do a stock adjustment, and add it on the zero tab, type the unit cost, batch, bin location etc.
    • It is better doing it this way, than the currently implementation of auto-disassembly, where it is just dividing the total dollar value by the quantity of units and then just inputting the batch number as the disassembly job number (which in real life means nothing for the product / not scannable)

    I don't understand why they do not simply process a reversal of the assembly job, as it has the unit pricing, the bin locations, the batch data etc. That makes logical sense. But I understand that whilst it may make logical sense, there may be some technical challenges that I'm unaware of, that I don't know. 

    Fingers cross more people vote for this I guess / or someone as Cin7 reads this and just gets onto it / gets it done.

    0

Please sign in to leave a comment.