Closed wdammak closed 2 years ago
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.
And: GROUP BY inventorycode
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;
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);
Git Commit.... the report generator for the warehouses. Tested and it's ok.
Warehouse Stock move
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 👍
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):
Still to be done (minor improvements):
attached the updated module htdocs.zip
--
-- Structure of the
llx_c_type_movement
table. CREATE TABLEllx_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 INTOllx_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"
--
-- Structure of the
llx_c_type_movement
table. CREATE TABLEllx_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 INTOllx_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
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:
Hi @eldy this wil be present in V15?
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.
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
A filter has been added in stock movement list
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)
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
), KEYidx_stock_mouvement_fk_product
(fk_product
), KEYidx_stock_mouvement_fk_entrepot
(fk_entrepot
) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;