Feature Request: Restructuring the stock movement module

[wdammak]

Feature Request

The stock movement module in its current state is incomplete and very limited in functionality. I think we need to restructure this module so that it complies with the standards and respects the processes of the movements of stock in most organizations.

In the first step we must add a new table to list the movements by: _operation / operation_type / date / inventorycode / warehouse out/ warehouse in / user / sender / receiver /... This table () ** to rebuild from the current stock_movement table.

The types of operations are generally like the following: (to be added in a new table of constants llx_c_stock_mouvement_type)

• Exit movement: currently it's done in the article sheet.
• Movement of entry: currently it's done in the article sheet.
• Transfer movement: The transfer movement normally has to be entered by the storekeeper of the source depot and received by the warehouse keeper of the destination depot + signature between the two warehouse workers + other additional information (Carrier, registration number of the truck ...) .
• And finally an inventory movement: the purpose of this movement is to perform outputs or inputs depending on the state of the system stock and the physical inventory.

The movements of stocks must be tracked and monitored by the internal control services and also by the accountants for this to have printed and signed documents is an obligation. So we must also add the generator of pdf in the management of the movements of stock.

A log of all movements is very important too (this is the current case of stock_movement) you just have to add a pdf generator to print them monthly or annually (add a periodic filter?).

There may be other details that have escaped me, but it's already a very important step to achieve this module for a good ERP.

Best regards & good work

(**) A proposal: CREATE TABLE llx_stock_mouvement_list ( rowid int(11) NOT NULL auto_increment, tms timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, datem datetime default NULL, eatby date default NULL, sellby date default NULL, fk_entrepot int(11) NOT NULL, total double(24,8) default '0.00000000', type_mouvement smallint(6) default NULL, fk_user_author int(11) default NULL, label varchar(255) default NULL, inventorycode varchar(128) default NULL, fk_origin int(11) default NULL, origintype varchar(32) default NULL, PRIMARY KEY (rowid), KEY idx_stock_mouvement_fk_product (fk_product), KEY idx_stock_mouvement_fk_entrepot (fk_entrepot) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

[eldy]

As a summary: We must add a filter on "type of movement" (field available in table llx_stock_movement) into the list of movement page.

[wdammak]

And: GROUP BY inventorycode

[wdammak]

-- -- Structure of the llx_c_type_movement table.

CREATE TABLE llx_c_type_movement ( rowid int(11) NOT NULL, code varchar(12) collate utf8_unicode_ci NOT NULL, libelle varchar(30) collate utf8_unicode_ci default NULL, picto varchar(128) collate utf8_unicode_ci default NULL, active tinyint(4) NOT NULL default '1', action int(4) NOT NULL default '1', PRIMARY KEY (rowid), ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

-- -- Contents of the llx_c_type_movement table.

INSERT INTO llx_c_type_movement (rowid, code, libelle, picto, action, active) VALUES (1, 'IN', 'IN', NULL, 1, 1), (2, 'OUT', 'OUT', NULL, -1, 1), (3, 'INV', 'Inventory', NULL, 1, 1), (4, 'TRAN', 'Transfer movement.', NULL, -1, 1), (5, 'PRET', 'Product return.', NULL, 1, 1), (6, 'PEXC', 'Product exchange.', NULL, -1, 1);

[wdammak]

Git Commit.... the report generator for the warehouses. Tested and it's ok.

[wdammak]

htdocs.zip

[wdammak]

Warehouse Stock move

[BebZ]

You forgot in your first "proposal" the foreign key of productlot or porductbatch table (you've implemented eatby and sellby) I don't remember which one is still active/useful. I understood : One is for history (productlot) the other one (batch) is for qty (in stock) qty=0, bath number entry is erased). Have you implemented it and is it working ? Anyway it's a very useful work as you remarked in first post 👍

[wdammak]

To go faster we can go beyond a new table and be content with the current llx_stock_mouvement. Just add a table for the types of movements (llx_c_type_mouvement?)

Good new: I implemented the types of movements in the filters ...

Here are the added features (tested and it works, just update the two tables; llx_entrepot and stock_mouvement by adding the column model_pdf):

• To be able to generate a pdf report for an entropot
• To be able to display and generate a state of all the movements of a warehouse
• To be able to display and generate a state of a type of movement of a warehouse
• To be able to filter by type of movement.

Still to be done (minor improvements):

• A new page that list the transactions group by operation (inventorycode/type_movement)
• Add a new method (selectTypeOfMovement?) to the formentrepot class that list the movement types in a select like // print $formproduct->selectWarehouses(

attached the updated module htdocs.zip

[eldy]

--

-- Structure of the llx_c_type_movement table. CREATE TABLE llx_c_type_movement ( rowid int(11) NOT NULL, code varchar(12) collate utf8_unicode_ci NOT NULL, libelle varchar(30) collate utf8_unicode_ci default NULL, picto varchar(128) collate utf8_unicode_ci default NULL, active tinyint(4) NOT NULL default '1', action int(4) NOT NULL default '1', PRIMARY KEY (rowid), ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

--

-- Contents of the llx_c_type_movement table. INSERT INTO llx_c_type_movement (rowid, code, libelle, picto, action, active) VALUES (1, 'IN', 'IN', NULL, 1, 1), (2, 'OUT', 'OUT', NULL, -1, 1), (3, 'INV', 'Inventory', NULL, 1, 1), (4, 'TRAN', 'Transfer movement.', NULL, -1, 1), (5, 'PRET', 'Product return.', NULL, 1, 1), (6, 'PEXC', 'Product exchange.', NULL, -1, 1);

We can't add an external table to manage this. Because the type of movement is something used to change how we store data and which business rules we applies. We already have 4 type (1,2,3,4). We must first just add a filter on this. For more precise context (product return, etc..) we will add a field later.

So the summary of this request is just

"As a summary: We must add a filter on "type of movement" (field already available in table llx_stock_movement) into the list of movement page."

Your zip contains a lot of code, only one page should be affected that is "product/stock/mouvement.php"

[wdammak]

--

-- Structure of the llx_c_type_movement table. CREATE TABLE llx_c_type_movement ( rowid int(11) NOT NULL, code varchar(12) collate utf8_unicode_ci NOT NULL, libelle varchar(30) collate utf8_unicode_ci default NULL, picto varchar(128) collate utf8_unicode_ci default NULL, active tinyint(4) NOT NULL default '1', action int(4) NOT NULL default '1', PRIMARY KEY (rowid), ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

--

-- Contents of the llx_c_type_movement table. INSERT INTO llx_c_type_movement (rowid, code, libelle, picto, action, active) VALUES (1, 'IN', 'IN', NULL, 1, 1), (2, 'OUT', 'OUT', NULL, -1, 1), (3, 'INV', 'Inventory', NULL, 1, 1), (4, 'TRAN', 'Transfer movement.', NULL, -1, 1), (5, 'PRET', 'Product return.', NULL, 1, 1), (6, 'PEXC', 'Product exchange.', NULL, -1, 1);

We can't add an external table to manage this. Because the type of movement is something used to change how we store data and which business rules we applies. We already have 4 type (1,2,3,4). We must first just add a filter on this. For more precise context (product return, etc..) we will add a field later.

So the summary of this request is just

"As a summary: We must add a filter on "type of movement" (field already available in table llx_stock_movement) into the list of movement page."

Your zip contains a lot of code, only one page should be affected that is "product/stock/mouvement.php"

https://github.com/Dolibarr/dolibarr/pull/10437 https://github.com/Dolibarr/dolibarr/pull/10436

[eldy]

Assigned to @Hystepik to first add a filter on list of type of movement. Remind of the 4 possible values/labels to show into combo:

• 0=input Manual stock increase (by a manual/direct stock transfer, correction or inventory)
• 1=output Manual stock decrease (by a manual/direct stock transfer, correction or inventory),
• 2=output Automatic stock decrease (after a business event like sale, shipment or manufacturing, ...),
• 3=input Automatic stock increase (after a business event like purchase, reception or manufacturing, ...)

[DATUC]

Hi @eldy this wil be present in V15?

[DATUC]

Hi @ll actualy having an issue wen generating the warehouse contain PDF if the contain equand fill just in one page v=everyting is ok but wen it com to 2 pages the contain on the secong page is ot well positioned.

[Hystepik]

Hi @ll actualy having an issue wen generating the warehouse contain PDF if the contain equand fill just in one page v=everyting is ok but wen it com to 2 pages the contain on the secong page is ot well positioned.

Hello @DATUC, Please create another Issue for this bug in with Bug tag

[Hystepik]

A filter has been added in stock movement list