Topic: Allocation of Work Order
|By: Stephen||Posted on: Nov 18 2019 at 07:34:36 AM|
|If you Allocate parts fora Work Order, then change a part (i.e. replace) in a sub-assembly within, the 'show shortages' do not update (i.e. to the original part remains in the shortages). I reversed the allocation, then re-allocated to get the update.|
Is this the correct procedure? Always undo the allocation?
|By: Support||Posted on: Nov 18 2019 at 08:12:06 AM|
|Some people would argue that once an assembly has been created/edited and used to build product then no further changes can be made to it. It should be locked. Any changes to the assembly should be a NEW assembly revision. The reason for this is if sometime in future you have a customer concern you can go right back to the original Work Order and reproduce the BOM exactly as it was when you built the customer's product.|
But, currently, MiniMRP allows you to change an assembly even if there's active work orders allocated or actually building that assembly. Nobody has complained about this capability but if you make changes to an assembly while work orders for that assembly are in the Allocated state then you'd need to undo/un-allocate those work orders and reallocate using the new BOM.
I would add that when you move the work order from the Allocated to WIP stage then MiniMRP does pick the components based on the current PartsList (not the old one)
We are aware that this might not be ideal and we're deciding what to do about it. If we do make a change to the software then the preferred option would be that, once an assembly has been used or processed (ie allocated, issued or sold) then we double lock the assembly's parts list. Any changes would then be a new revision. We would include a less obvious option to unlock the parts list if you really, really want to on the understanding that it's up to you to undo any current/active work orders that may be affected by any change to the assembly..
|By: Stephen||Posted on: Nov 19 2019 at 09:26:04 AM|
|Your explanation makes sense to me. miniMRP picks the components based on the latest version of the BOM. |
What I was doing was getting snapshots of shortages with only allocated assemblies.
Is there a way to identify when an WO is 'out of date'or needs to be reversed because the BOM has been changed after it was allocated ?
Now that I understand the logic, I will follow the current process your outlined above. Thanks.
|By: Support||Posted on: Nov 20 2019 at 09:45:37 AM|
|You are doing it correctly. The whole idea of "Allocation" is to tell MiniMRP what you're planning to do in future and you can see shortages before they actually occur.|
You are also correct in that if you change an assembly while work orders are in the allocated state then we could at least warn you about them. This is where we can't decide what to do. (1) should we warn you or (2) should we automatically unallocate/reallocate or (3) block changes or (4) pop up a dialog asking you which of those options you want to do.
This is one of those things where we've been waiting for user feedback but, strangely, it's not mentioned often if ever.
|By: AndyT||Posted on: Nov 27 2019 at 02:12:09 AM|
|As far as I am concerned the ability to un-allocate, do changes and then re-allocate is very useful. Perhaps a warning would be nice but an option would probably be even better.|
|By: Ken at DTS||Posted on: Nov 27 2019 at 05:41:51 AM|
|I agree with AndyT.|
|By: Stephen||Posted on: Nov 27 2019 at 06:59:10 AM|
|I also agree. If you make a change to an already allocated item (part or assembly) provide a User warning, List the offending allocations and Offer or Not , to unallocate any offending allocations.|
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.