dolibarr
dolibarr copied to clipboard
Dolibarr
NEW shipments kits with dispatcher
NEW shipments kits with dispatcher (need SQL from PR #21034)
- it's a feature for virtual products (kits)
With this feature, you can now dispatch all components and sub-components and choose warehouses when you create a shipment.
For example, on ou customer order, you have a line with a virtual product :
This "PANIER1" is a virtual product (kit) whose components are :
- 1x "PANIERVIDE
- 2x "ANANAS1"
- 3x "POMME1"
Then, when you create a shipment, you can choose quanitites and warehouses of each components :
- all quantities are pre-filled with the remain quantity to send (in the case of some quantities were already sent in another shipment)
- if you update the quantity of the parent (kit), it will automatically update all quanitties of its components
At the end of each line of each components, you can dispatch a new line in order to choose a different warehouse :
After when you validate, close, re-open, delete a shipment only movement are done on last level of componennts (sub-components). In this case, the virtual product "PANIER1" has no stock movement. Only components 'PANIERVIDE", "ANANAS1" and "POMME1" (last levels of the virtual product) are decremented from selected warehouses. And stock movements follow the stock setup to increment or decrement products / services linked to theses components (sub-components).
@eldy The new table "llx_expeditiondet_dispatch" is used to dispatch "shipment" lines. "Shipment" lines (expeditiondet) are inserted when you create a shipment from an order. In "expeditiondet_dispatch" you can have one shipment line linked to several warehouses. So one product of the shipment line can be decremeted from several warehouses when you click on "dispatch" button (you can choose an another warehouse with a quantity to decrement).
@eldy Could you merge it or tell me if something wrong with this PR ?
Need #21034 Need to test an order with:
- One kit
- One product without lot
- One product that need lot Test dispatching with setting a warehouse. Test dispatching without a warehouse.
TODO after:
- (Delete a line)
TODO before merge: What about the option to autoincrement/decrement stock for subproducts of kits ?
@eldy All prerequisites have been met and this PR is ready to merge. I also add a delete button on dispatched lines.
I did a comparison on how the reception and shipment works: Adding a new table llx_expeditiondet_dispatch will make things working too different than reception.
For reception, detail per batch/warehouse of reception is stored into the table llx_commande_fournisseur_dispatch.sql (that should have been named llx_receptiondet_batch).
So for shipment, we should also store detail into the existing llx_expeditiondet_batch.
This means we should instead add the field fk_warehouse into llx_expeditiondet_batch (to replace fk_origin_stock that is not enough accurate/appropriate for the need)
@eldy This features concerns virtual products and you don't have this need in reception. You receive only products and after you assemble theses products to get a virtual product. In the shipment, you must choose the warehouse for each child of virtual products. So you need this table "llx_expeditiondet_dispatch". Without it, how do you do to create the movement ? (you can take child products from different warehouses)
What is missing to get this PR validated as there is a strong need when using virtual kits?
A lot of pending PR related to shipment edition were submited with different philosophy and different feature. But all of them was doing a different implementation so were in conflict. So a PR that try to merge all the idea of all of them was pushed to add a new tab on shipment to add the expected feature of this PR. So i close this one.
@eldy I think you refer to this PR : https://github.com/Dolibarr/dolibarr/pull/24717, is it right ? I tried it and I see only a new "dispatch" tab on shipment card. You can access to this "dispatch" tab only when the shipment was created from an order. So it's to update the shipment and not to create.
The shipment lines has already been dispatched when you click the "Shipment" button from order card :
So you have to dispatch lines before with the old functionality. And then you can update dispatched lines with the new functionality given by the PR 24717. So I don't see the way to dispatch virtual products like I implemented in this PR.
As a little note: I just came across the problem of dispatching virtual products. Since in this case warehouse locations are managed by sub-warehouses for each item, the components of a virtual product are spread over many different warehouses.
Currently, virtual products are not usable in this specific scenario (we could work around this with BOMs and MOs).
My conclusion is that we need the mechanism described in this PR that during a shipment we can select the warehouses for the parts that form a set. I am not sure, whether the proposed implementation is the best one in the context of all ongoing activities, but I would like to encourage to not lose this PR.
As a little note: I just came across the problem of dispatching virtual products. Since in this case warehouse locations are managed by sub-warehouses for each item, the components of a virtual product are spread over many different warehouses.
Currently, virtual products are not usable in this specific scenario (we could work around this with BOMs and MOs).
My conclusion is that we need the mechanism described in this PR that during a shipment we can select the warehouses for the parts that form a set. I am not sure, whether the proposed implementation is the best one in the context of all ongoing activities, but I would like to encourage to not lose this PR.
Thanks for feedback. I agree that we must be able to select a werehouse for the set of sub products of a virtual product. But this should be done inside the shipment. Not from the order. Don't you think so ? Also, and this is a critical point, before discussing on how the screen must be and where, the database change structure must be first validated. As defined into the CONTRIBUTING file, no PR are allowed if it mixes database structure change and business code. Database structure addition must be pushed in a separate PR before any PR with php code submission. So this PR can't be validated.
@eldy
Is is in "expedition/dispatch.php" file (Dispatch tab of shipment card) I could put the dispatched quantities for each sub-product of a virtual product ?