Currently, when creating a build order, components can be allocated against a particular Stock Item. Then, no transfer of stock takes place until the build is completed. This creates two issues:
Another step between build order item allocation, and build order completion. After allocating stock, the user should be able to transfer stock to another location. In the simplest use case, the user can designate a single Production stock location, which can hold parts in production until their respective build orders are completed. Another, more advanced way to handle this would be to add a flag to stock locations to allow them to be used to hold production items. In this manner these locations would not be available to hold inventory unless transferred there against a build order.
Other options to accomplish the same thing would be for the user to manually transfer production items to another area, but this is clunky and there isn't currently a way to automatically transfer build order items. This could work without the concept of "production" stock locations, but would still need a way to transfer all allocated build items to a stock location. I do think that closing off the list of allowable locations to a subset of all locations makes sense in most every use case I can think of.
Axelor, Odoo, and ERPNext all have similar features, allowing for production component stock to be transferred against a production order or work order to accommodate longer build times and more accurately track inventory.
Hi there @kmudlemmon
I know of that extra step in other software and the confusion it often caused in the shops I saw it at. If there is a good UI implemented this can certainly work.
Will be interesting to see if this gains traction with other users or devs.
Another solution that just came to mind which makes this extra step optional:
Add an action on a build item which creates stock transactions that remove allocated stock from StockItems. This doesn't require a stock location for the inventory to be put, only removes necessary stock from the db ahead of build order completion.
I see the user flow like this:
As for implementation, another field added to Build Items indicating the picked quantity is the only db change needed.
This action could be reversed easily as well to accommodate cancelling a build order. If this feature complicates some use cases, it could easily be disabled via a configuration flag as well.
Another benefit is that the build item effectively becomes the location of the stock, and queries can be performed to calculate where stock is. The "Available Stock" component of the part view could specify an "In Use" quantity, which can be investigated by an additional column in the part's build order allocations table displaying the picked quantity.
There are undoubtedly some edge cases I haven't thought through, but I think this is a much simpler solution in terms of implementation and ease of use.
That sounds like a better solution, lets's see what the core team thinks.
@inventree/maintainer @inventree/triage
@kmudlemmon the later solution seems pretty nice to me, and looks to be mostly a "front end" / "user interface" approach. Would you be willing to implement this?
Please note also that are going to be migrating to react for the front-end so any "major" UI changes should hold off until that transition has been made.
| Owner Name | inventree |
| Repo Name | InvenTree |
| Full Name | inventree/InvenTree |
| Language | Python |
| Created Date | 2017-03-23 |
| Updated Date | 2023-03-31 |
| Star Count | 2586 |
| Watcher Count | 61 |
| Fork Count | 411 |
| Issue Count | 141 |
| Issue Title | Created Date | Updated Date |
|---|