NEW shipment kits with dispatcher v2

[lvessiller-opendsi]

NEW shipment kits with dispatcher v2

• see https://github.com/Dolibarr/dolibarr/pull/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"

[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]

@eldy I don't find any CI erros on changed files. Some errors still persist on unchanged files. Could you have a look ?

[eldy]

@eldy I don't find any CI erros on changed files. Some errors still persist on unchanged files. Could you have a look ?

Did you meege/ repush your PR recently ?

[lvessiller-opendsi]

@eldy I pulled today but I still have CI errors and this PR seems no to be concerned.

[lvessiller-opendsi]

Now you have also the reload of lot/serial numbers when you change the warehouse (ajax) And the "eatby" and "seelby" dates are automatically filled.

[fappels]

Now you have also the reload of lot/serial numbers when you change the warehouse (ajax) And the "eatby" and "seelby" dates are automatically filled.

@lvessiller-opendsi The text input value of the lot-number should be only pre-set when there is only one lot available, else possible other lot number are filtered out of datalist Data list filtered to one lot: Remove some filtering, shows complete list available:

[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 : https://github.com/Dolibarr/dolibarr/issues/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.

[lvessiller-opendsi]

Fix of Issue #33144

[lvessiller-opendsi]

@eldy I integrated the new way to manage product with "stockable_product" field. I replace "STOCK_ALLOW_NEGATIVE_TRANSFER" by "STOCK_DISALLOW_NEGATIVE_TRANSFER". I don't know how to split more this pull request.

[eldy]

@eldy I integrated the new way to manage product with "stockable_product" field. I replace "STOCK_ALLOW_NEGATIVE_TRANSFER" by "STOCK_DISALLOW_NEGATIVE_TRANSFER". I don't know how to split more this pull request.

Yes STOCK_DISALLOW_NEGATIVE_TRANSFER is now merged and option stockable_product too. V21 has been released so we can take new risk in merging. I should have a look at this pr soon...

[lvessiller-opendsi]

@eldy I updated this pull request from develop. I have solved every CI errors I could. The last ones seem not concern this pull request. Could you have a check ?

[eldy]

I am still no able to fix the PR. To avoid to keep it open (i would like to merge it for v22 beta very soon), are you able to switch easily the PR on a personal branch and repush it so it would fix the permission problem i have (at least for this PR, until we find a better way) ?

[lvessiller-opendsi]

I am still no able to fix the PR. To avoid to keep it open (i would like to merge it for v22 beta very soon), are you able to switch easily the PR on a personal branch and repush it so it would fix the permission problem i have (at least for this PR, until we find a better way) ?

@eldy I have just updated from develop. It will be an other big effort for me to repush it on a personal branch. Could you explain to me what is the problem ?

[lvessiller-opendsi]

This PR was replaced by new one #33750