Patch warehouse to use stock-locations

[fappels]

Patch warehouse to use stock-locations

Why don't we use a warehouse as a detailed stock location instead of a building or room where you put your products.

Things to-do:

• Patch product/class/html.formproduct.class.php selectWarehouses to select2 for stock corrections and transfers, update loadWarehouses with extra filtering and return info.
• Patch expedition/shipment.php to be able to take product from more then one stock location (with split button like used for batch products in dispatch supplier order). Remove source warehouse for shipment and use 'pre-filtered on (batch +) stock select2' for selecting source (batch and) stock-location.
• Patch fourn/commande/dispatch.php to use select2 and add split button for to split order line like on batch products to be able to dispatch to multiple locations.
• Patch product/stock/list.php to show quantities.
• Patch lang files.
• For generating stock-locations, the stocks warehouses import assistant can be used.
• With the patches you can still use the 'Warehouse' way of working. If you want both, simply create stock locations with ref name consisting of warehouse name and stock-location (for filtering product/stock/list.php).

Please comment if I'm missing something, so I can start patching.

[BebZ]

Is this screenshot useful ?

I'm not sure to understand your last point : we can still use the "Warehouse way of working". It means we can still choose one global warehouse like "mag1" and add it sub-warehouses like mag1-shelf1, mag1-shelf2, etc... ?

so the structure of the name of the location of the product (or product batch) should be "WAREHOUSE NAME"-"ROW/SHELF NAME" ?

[fappels]

Yes, good example.

With using "Warehouse way of working" I mean backwards compatibility, there a no changes in database structure. Only there some different usage of the shipments and dispatch forms.

When you added sub locations and transfered your stock to the sublocations you best remove 'mag1', it will contain no stock. But always put your warehouse name in the ref name to filter warehouse totals in list.php. There will indeed be some redundant data if you duplicate your warehouse address to each sublocation.

[rdoursenaud]

I understand the need for a fine grained location of stocked items. I even contemplated several implementations. But reusing the warehouse object for that sounds overkill to me. Maybe you could wrap it around a more generic 'location' object and use that instead.

[BebZ]

I don't get understanding of coding... Warehouse object is not right ? Did you see our demo ?

[fappels]

If we add a new 'location' object we have to rewrite all stock related classes to use the new 'location' object. All stock movements have to be done most detailed location. When reusing the warehouse object we don't need to touch the other business objects, we only need to improve the user-interface. We can now keep warehouse object naming and in a later phase we can add a new parent warehouse object with address and rename the the old warehouse object to 'location'.

[rdoursenaud]

Using a location named warehouse is misleading at best and potentially confusing for both developers and users. Refactoring the current warehouse object to extract its bones in a location class shouldn't be that hard. Doing it in the correct order may seem harder but will streamline the process. We are about to start a new release cycle, this is exactly the right time to undertake such work. I also know from experience that if you don't do it now, you'll never. But don't get me wrong, I don't want to undermine your idea, I'm really excited about bringing fine-grained stock support to Dolibarr! Let's just do it with a good design.

[fappels]

Refactoring the warehouse object was my first idea (see title change history) but I was worried about backwards compatibility with external modules. I think we should include a transition phase with deprecated properties. To keep migration simple we not need to touch the table and keys 'entrepot', In the French larousse is written for entrepot

Lieu, bâtiment, hangar, dock, etc., où sont déposées des marchandises pour un temps limité.

I wonder, is there still need to have a parent warehouse on top of the stock-location, we can add location categories to make reports on a group of stock-locations and not deprecate address fields. For example you can create a category 'SCRAP' where you can put your damaged materials or 'TRASH' or better 'RECYCLE' to put your spoiled food.

[BebZ]

My 2 cents is that @eldy 's thought ? a warehouse is a place/shelf/box/whatever where you store products, there can be 1 to 1000 warehouses on the same site.... A "Building (bâtiment)" linked to locations is useless in a first time and a waste of time... Moreover I've read about a Resource module, to manage rooms, ahaha. If the name warehouse doesn't fit, rename warehouse could be easy with a tool to search for expressions like "warehouse" or "entrepot" in the code...

other developpers of objects/modules linked to it should know it maybe with the dev newsletter and we should ask for their point of view ?

In my opinion there is not so many modules linked to warehouse... except maybe POS... ? And if some are linked to warehouse don't they need a finer grained location management ?

As @fappels said, he doesn't touch the tables, it's just touching the way it's dispalyed and selected when dispatching/shipping...

[BebZ]

it would be nice also because @fappels speaks about : Patch expedition/shipment.php to be able to : take product from more than one stock location (with split button like used for batch products in dispatch supplier order). Remove source warehouse for shipment and use 'pre-filtered on (batch +) stock select2' for selecting source (batch and) stock-location.

I would add pre filtered or "pre-sorted" on Dates of expiry (DLC/DLUO)

to quote ;) How much time for your solution Francis @fappels ? and how for much time for yours Raphael @rdoursenaud ?

[rdoursenaud]

@BebZ Time is irrelevant. Maintainability is.

[BebZ]

@rdoursenaud Time is now! Have a look in odoo or other softwares... shelf/row/bin is in their vocabulary... Maybe you could provide more info on howto do to make a second object if you disagree on changing warehouse object ? OK majority of dolibarr users are just using it as a simple invoice maker for their services or associations for managing adherents?

[rdoursenaud]

Yes Odoo has everything including the kitchen sink. But because they implemented it so quickly (i.e. bad design), they have all kinds of weird and wonderful issues because the kitchen sink is in the bathroom with a hose coming from the shower dangling on band aid tape and rope. This means more time to have a feature that's actually working. That's not the future I want for Dolibarr (Which already have its share of spaghetti code and weird loopholes). But I'm just expressing an opinion and you're right to say that, in the great tradition of Free Software, the one doing the implementation and providing the code wins the argument ;) This shouldn't prevent me from expressing my concerns to him. @fappels in this case. Anything he does now, he does with the knowledge of everyone's opinion.

[BebZ]

I think if you agree, I will finance the PR to be able to dispatch and ship to/from multi warehouses in the same time. Because even on demo, it is not possible to ship from more than 1 warehouse, and sometimes even in "normal" using of warehouses, you have a warehouse "shop" and another warehouse "stock", just next to the shop. Sometimes you have the products in both of them and you need to send it from both to fulfill a cutomer's order.

[BebZ]

No Pull Reqest has been created on develop before Freeze of 3.9 ? @fappels Meaning dispatching to multiple stocks in the same time, and shipping from multiple stocks at the same time will not be possible in 3.9 ? @eldy

[BebZ]

@Darkjeff

[BebZ]

https://github.com/fappels/dolibarr/tree/develop-stock-locations

[fappels]

Warehouse select2, multi ship and multi dispatch is available in latest dolibarr versions.