NEW shipment kits with dispatcher v2

[lvessiller-opendsi]

NEW shipment kits with dispatcher v2

• see NEW shipment kits with dispatcher v2 (SQL) #26519 for SQL structure

Example

1. Create a virtual product
Virtual product '"PANIER1" contains sub-products :

• 1 x PANIERVIDE
• 3 x POMME1
• 2 x ANANAS1
• MINIPANIERGARNI (virtual product)
  

and MINIPANIERGARNI it's a sub virtual product and contains sub-products :

• 1 x POMME1
• 1 x ANANAS1
  

2. Create an order

3. Create a shipment

Then choose your quantities on each product line to prepare the shipment (see 5. to dispatch all shipment lines and children products of a virtual product)

4. Shipment
Here you can see all lines of the shipment

and the details for each warehouse and quantities of each sub-product as tooltip :
POMME1 P1 : ENTREPOT2 (Qty: 4)
POMME1 P1 : STOCKP2 (Qty: 4)
ANANAS1 Ananas : ENTREPOT2 (Qty: 3)
ANANAS1 Ananas : STOCKP2 (Qty : 3)

and we can edit a virtual product

• link to "Dispatch shipment" tab (see 5. above)

and we can delete a virtual-product

• all children are deleted (by reccurence)

5.Dispatch shipment
Here you can select each warehouse and the quantities for each line of products and sub-products

And then you can save all dispatched lines and validate your shipment.

5.Stock
For virtual product

• check on all children if the checkbox "Increase or dscrease stock" (incdec) is checked (see 1.) and then dicrease the stock with the quantity dispatched for each warehouse

The stock for virtual product is not managed : movements are only for sub-products (if "incdec" is checked)

• for "POMME1"
  
• for "ANANAS"
  

The movements are only when we validate or close a shipment (see parameters of stock module)

And when we cancel or delete a shipments, all inverse movements are done in for stock of each sub-product (not virtual product)

• example for sub-product "POMME1"
  

• example for sub-product "ANANAS1"
  

Kit with batches as sub-components
In shipment details you can choose serial numbers for sub-components

[lvessiller-opendsi]

@eldy
The field "incdec" was used for virtual products to determine if the stock of a sub-product was managed.
Since Dolibarr v19, a new field "stockable_product" has been introduced in "product" table.
Now, I wonder If "indec" must be replaced with "stockable_product" to manage stock of a sub-product ?

[eldy]

@eldy
The field "incdec" was used for virtual products to determine if the stock of a sub-product was managed.
Since Dolibarr v19, a new field "stockable_product" has been introduced in "product" table.
Now, I wonder If "indec" must be replaced with "stockable_product" to manage stock of a sub-product ?

Incdec is used to know if we must change stock inside the virtual product.
Stockable_product has the same meaning but for all application. So stockable product has priority on incdec if value is 0. If value is 1, we use incdec (that is a local choice for 1 virtual product).
There is still use case where we can have stockable_product to 1 but for only a particular virtual product, we want no stock change.

[lvessiller-opendsi]

@eldy
The "stockable_product" is only in database structure and is not used in the interface.
The product class has no fetch method with "stockable_product" in develop branch.

[lvessiller-opendsi]

@fappels
In shipment setup, now you have an option to pre-select the batch number with the earliest sell-by or eat-by date :

1. If this const "SHIPPING_SELL_EAT_BY_DATE_PRE_SELECT_EARLIEST" is disabled
   A batch number is pre-selected only if there is one batch linked to the selected warehouse

2. If this const "SHIPPING_SELL_EAT_BY_DATE_PRE_SELECT_EARLIEST" is enabled
   The batch, whose sell-by (DLC) and eat-by (DLC) date is the earliest, is pre-selected by default when creating the shipment

[josett225]

Hi @lvessiller-opendsi
Many thanks for this PR. This is a MUST HAVE when we use product Kit as the actual behavior has no warehouses selection and also has some bugs when deleting shipments.
Some remarks after testing:

• It works very well when validating and deleting an expedition.

• After selecting the warehouse for each product the button SAVE is still displayed. Difficult to know if we did it or not even if you display a message box. Could it be possible to block the selected values and get a modify button instead?

• Is it possible keep the tab available so we can get it for historical data for all the shipment (of course the Modify/Save button has to be greyed if Shipment has been validated?
  

• not sure I understand why you are not decreasing/increasing the KIT stock value? In my configuration if the Kit stock value is not enough then I cannot move forward to do the shipment as there is no enough stock. (In the meantime, I am testing in another platform ProductMixer from @BadPixxel that calculates automatically the available kits based on real time product stock data):
  

Let me know if you need more information and again Many Thanks for the huge effort.

[josett225]

Hi @lvessiller-opendsi and @eldy
What is missing to move forward?
This feature is great one to get in the core.
Best Regards
Jose

[lvessiller-opendsi]

Hi @lvessiller-opendsi and @eldy What is missing to move forward? This feature is great one to get in the core. Best Regards Jose

Thanks for your remarks, maybe there still exist a lack as you commented :

not sure I understand why you are not decreasing/increasing the KIT stock value? In my configuration if the Kit stock value is not enough then I cannot move forward to do the shipment as there is no enough stock. (In the meantime, I am testing in another platform ProductMixer from @BadPixxel that calculates automatically the available kits based on real time product stock data)

[lvessiller-opendsi]

@josett225
I have fixed it :

• not sure I understand why you are not decreasing/increasing the KIT stock value? In my configuration if the Kit stock value is not enough then I cannot move forward to do the shipment as there is no enough stock. (In the meantime, I am testing in another platform ProductMixer from @BadPixxel that calculates automatically the available kits based on real time product stock data):

There is no stock movement for virtual products (kits).
You can choose to increment or decrement only on components of virtual products.
And in shipment, only warehouses where there are components are suggested at first.
Could you have a check ?

[lvessiller-opendsi]

@eldy
I realized a lot of tests.
There are still some CI errors, but it seems to concern unchanged files by this PR.
I wish you would integrate it for the new year : "2025".

[lvessiller-opendsi]

@eldy I realized a lot of tests. There are still some CI errors, but it seems to concern unchanged files by this PR. I wish you would integrate it for the new year : "2025".

It still exists a problem with virtual products in TakePos module. I will check it before

[eldy]

@eldy
I realized a lot of tests.
There are still some CI errors, but it seems to concern unchanged files by this PR.
I wish you would integrate it for the new year : "2025".

3 points:
First i see addition of such option in the pr
print ''.$langs->trans('SHIPPING_SELL_EAT_BY_DATE_PRE_SELECT_EARLIEST');
This seems not related to the pr and make indzrstanding ofncode change more difficult. Si pr must be split in 2.

Second point is that this change will have a very high number of trouble, whatever is the quantity of test, it will have a lot of side effect that will need a very long time ti be stable again (compatibility with lot, variant module, bom and mo, xternal modules...). I am even not sure it can be stable one day as there is some situation that i am not sure we will be able to define a clear business rule that can works for everybody. For this reason any code related to this must be isolated into a if of a hidden feature and old code must remain unchanged.

Before trying to introduce such a change, i think we must also first make the existing feature related to kits more stable.
For example, what happen if we introduce a kit inside a kit. Not sure this was implemented.

Also can you describe the goal of the feature (the use case). Which trouble or feature do you want to address ? The screenshot show how it will work but not what we want to solve. Is it to allow sub kits ?

[lvessiller-opendsi]

@eldy
I realized a lot of tests.
There are still some CI errors, but it seems to concern unchanged files by this PR.
I wish you would integrate it for the new year : "2025".

3 points: First i see addition of such option in the pr print ''.$langs->trans('SHIPPING_SELL_EAT_BY_DATE_PRE_SELECT_EARLIEST'); This seems not related to the pr and make indzrstanding ofncode change more difficult. Si pr must be split in 2.

This is linked with this PR.
You have the choice when you dispatch you shipment :

• to preselect serial numbers of virtual products with nothing (or the only one) or the last sell-by / eat-by date

1. If this const "SHIPPING_SELL_EAT_BY_DATE_PRE_SELECT_EARLIEST" is disabled
   A batch number is pre-selected only if there is one batch linked to the selected warehouse
2. If this const "SHIPPING_SELL_EAT_BY_DATE_PRE_SELECT_EARLIEST" is enabled
   The batch, whose sell-by (DLC) and eat-by (DLC) date is the earliest, is pre-selected by default when creating the shipment
   It was a good remark of @fappels

Second point is that this change will have a very high number of trouble, whatever is the quantity of test, it will have a lot of side effect that will need a very long time ti be stable again (compatibility with lot, variant module, bom and mo, xternal modules...). I am even not sure it can be stable one day as there is some situation that i am not sure we will be able to define a clear business rule that can works for everybody. For this reason any code related to this must be isolated into a if of a hidden feature and old code must remain unchanged.

In develop, you can't choose a warehouse to decrement components of virtual product.
It's a lack if you enable virtual products.
This PR is compatible with serial and lots.
I don't know how can I introduce a const to keep it as a feature (too much changes in several files).
The most of code is unchanged when you don't enable virtual products.

Before trying to introduce such a change, i think we must also first make the existing feature related to kits more stable. For example, what happen if we introduce a kit inside a kit. Not sure this was implemented.

This PR is compatible with kit inside a kit. I tried with 3 levels of depth.

Also can you describe the goal of the feature (the use case). Which trouble or feature do you want to address ? The screenshot show how it will work but not what we want to solve. Is it to allow sub kits ?

Yes it allows sub kits. I will see how to describe the use case.

[josett225]

@josett225 I have fixed it :

• not sure I understand why you are not decreasing/increasing the KIT stock value? In my configuration if the Kit stock value is not enough then I cannot move forward to do the shipment as there is no enough stock. (In the meantime, I am testing in another platform ProductMixer from @BadPixxel that calculates automatically the available kits based on real time product stock data):

There is no stock movement for virtual products (kits). You can choose to increment or decrement only on components of virtual products. And in shipment, only warehouses where there are components are suggested at first. Could you have a check ?

Hi @lvessiller-opendsi
Sorry for being long on answering. It does not work better as I still have the same error message. It is even worst as now I cannot increase or decrease the stock of the Kit.

[lvessiller-opendsi]

@josett225 I have fixed it :

• not sure I understand why you are not decreasing/increasing the KIT stock value? In my configuration if the Kit stock value is not enough then I cannot move forward to do the shipment as there is no enough stock. (In the meantime, I am testing in another platform ProductMixer from @BadPixxel that calculates automatically the available kits based on real time product stock data):

There is no stock movement for virtual products (kits). You can choose to increment or decrement only on components of virtual products. And in shipment, only warehouses where there are components are suggested at first. Could you have a check ?

Hi @lvessiller-opendsi Sorry for being long on answering. It does not work better as I still have the same error message. It is even worst as now I cannot increase or decrease the stock of the Kit.

The error message is for components of the virtual product.
The virtual product has no stock movement and you should define increment/decrement quantities only on components of virtual product. In your last picture, we can see there is not enough quantities for components of virtual product : -2 for component "Cadre LAB" and -5 for component "Roue libre". Could you check the stock for components of this virtual product "TEST_KIT" ?

[josett225]

Hi @lvessiller-opendsi

Same issue after adding 10 pieces per component:

Also the real stock value of the parent is still mentioned as low even if I cannot changed it:

And when I look inside the kit component products setup, there is still a mention that the stock components values can be updated based on parent stock changed:

Regards

[lvessiller-opendsi]

@eldy
There is a use case here : #32753

[lvessiller-opendsi]

Hi @lvessiller-opendsi

Same issue after adding 10 pieces per component:

Also the real stock value of the parent is still mentioned as low even if I cannot changed it:

And when I look inside the kit component products setup, there is still a mention that the stock components values can be updated based on parent stock changed:

Regards

You got some details I don't have in your screenshot : so I wonder if you got the last changes of this PR or have you got some external modules ? Could you check with a new database and no external modules ?
If you want we can organize a video-conference (it will be easier to communicate) ?

[josett225]

Hi @lvessiller-opendsi
Let me look into my configuration in case.
And yes let's do a web conf.
Please contact me on [email protected] with some slots.