Mouvement des stocks

[d0bz]

Lorsque je déplace N stock ABC d'une location X à une location Y et qu'ensuite j'affiche le stock restant dans le secteur X, openerp me dit que X contient TOUJOURS ces N unités.

exemple:

VOIR ATTACHMENT

ver = 5.0.0

[Husen Daudi (husendaudi)]

Hello,

Stock will decrease if your destination location type will be customer.
If location Bin 1-A-1 is internal location then movement will not affect on real stock it will just move that stock from Zone_tampon to Bin 1-A-1 location, you can check that movement from lots by location report.

[d0bz (bourque-david+oerp)]

Ok, let me re-ask my question in a much simpler way:

Let's start from scratch...

1- I make three locations:

Main\
Main\Bin-1
Main\Bin-2

2- I make one product: screws

3- I receive 1000 screws and put them into Main\Bin-1 (Stock management / Incoming products / New)

4- I move 1000 screws from Main\Bin-1 to Main\Bin-2 (Stock management / Traceability / Low levels / Stock moves / New). After each steps, the status of the move is "done".

Now, i *Assume* that there should be 1000 screws in Main\Bin-2 and, of course, 1000 in Main\ (which is the parent).

5- Then i go to (Stock management / Stock location structure), select "Main\" and click "Print / Location Content (with children) and the report shows:

Main\: 1000 screws
Main\Bin-1: 1000 screws
Main\Bin-2: 1000 screws

how is that possible? what am i missing here?

thanks

[d0bz (bourque-david+oerp)]

After a quick talk with the user "cedk" on IRC i should point out that he thinks the bug is in the database in the "stock_location" table,

see http://www.sitepoint.com/article/hierarchical-data-database/2/

in my postgreSQLadmin i can see that:

main\bin1 has left=6 and right=9
main\bin2 has left=7 and right=8

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hi, I hope this is not what they suspect. I have no time to check now, but I should say had no problem so far with stock levels. So it seems too important to be true, but one never knows. I first tought that d0bz was looking at the global stock level while making internal moves on child location (so that wouldn't change the stock levels), I really had no time to check that was the scenario, but it seems they investigated themselves and found it wasn't the reason. Hope somebody can investigate.

So for the record, here is the IRC conversation they had (from the log):
d0bz on a un bug extremement bizarre, jai post sur le forum, fait un bug report, ecrit un email a "matrixise" et demander au mec de smile.fr, les 4 trucs essaye n'ont pas regle le probleme 19:46
d0bz https://bugs.launchpad.net/openobject-addons/+bug/331245/comments/3 19:48
cedk d0bz: did you check the left-right value of the location? 19:51
d0bz je ne sais pas cest quoi ? 19:52
cedk d0bz: http://en.wikipedia.org/wiki/Tree_traversal 19:53
cedk d0bz: I wrote it for Tryton some times ago and 1 month ago I added unit_test for this and I find a lot of issue 19:54
cedk d0bz: so I guess that it can have also those kind of issues on OpenERP as there is no unit_test to check it 19:55
cedk d0bz: so if you can copy/paste the field id, parent_left, parent_right, parent of the table stock_location 19:56
d0bz you mean like in the postgre database? 19:56
cedk d0bz: yes from the database 19:56
d0bz you think the problem is in the way the tree is stored in the database!??! 19:57
cedk d0bz: perhaps, because it looks like the system think the Bin-2 is in Bin-1 19:57
d0bz hmmm 19:58
d0bz lemme take a look 19:58
d0bz visually, in the gtk client, the bin-2 is *not* in the bin-1 tho 19:59
d0bz now lemme look @ the db 19:59
cedk d0bz: yes but the client use the parent field but to compute the server uses left-right 20:00
d0bz ok, what table? 20:00
cedk d0bz: stock_location 20:01
d0bz ok i found it 20:04
d0bz bin_1-a-1: {id=13; left=6; right=9} bin_1-a-2: {id=14; left=7; right=8} et leur parent id=11 20:07
cedk d0bz: it looks like 14 is under 13 according to the left-right 20:09
cedk so there is a bug in the left-right 20:09
d0bz hu? 20:10
cedk d0bz: ??? 20:11
d0bz 1- how do you know that (i dont know the algo.) and 2nd- is there a patch for this ? and 3- if not, is that a known bug so far? 20:12
cedk d0bz: to know the children of a node, you must search for left > node_left and right < node_right 20:13
cedk d0bz: so here left > 6 and right < 9 20:14
cedk d0bz: so bin_1-a-2 is selected 20:14
cedk d0bz: I don't know if there is a patch 20:14
cedk d0bz: and I don't know if it is a know bug 20:15
d0bz well.. should i fill a bug report!? 20:15
cedk d0bz: I don't know I'm not a dev of OpenERP 20:16
d0bz haha how did you know that then 20:18
d0bz i think this is exactly my problem 20:18
cedk d0bz: as I said I implement 6 months ago this algorithm in Tryton 20:19
cedk d0bz: and I find later with unit_test that it was more complicate then my first write 20:19
cedk d0bz: and as far as I know the algo in OpenERP looks like my first write 20:19
d0bz en passant je comprends le francais si t'es plus a l'aise 20:19
ce...

[Husen Daudi (husendaudi)]

I just test with demo data.
stock information is like this
location product uantity
stock Medium PC 4
--stock level 1 Medium PC 4
--workshop Medium PC 0

I move 2 Medium PC from Stock\stock level 1 to stock\workshop (Stock management / Traceability / Low levels / Stock moves / New).
I also test with Stock Management/Internal Moves/New Internal Packing
Now my new stock information is like this

location product uantity
stock Medium PC 4
--stock level 1 Medium PC 2
--workshop Medium PC 2

[d0bz (bourque-david+oerp)]

The bug only occurs when you add childs to the data already inserted
in the database when you install the erp, i.e. when i add a child to
my company \ stock. I have tested it on three different installations
following the exact same steps and i can reproduce the bug anytime. I
could make a little video or something to prove my point if you guys
want to.

[Fabien (Open ERP) (fp-tinyerp)]

Can you do a screenshot of this menu:
  Stock > Configuration > Locations

[Fabien (Open ERP) (fp-tinyerp)]

fixed in trunk.

[d0bz (bourque-david+oerp)]

08:54 <Red15> its revision 1742 on server trunk
08:55 <Red15> can you add it to your bug report ?
08:55 <Red15> something like ; for developers, the fix is in r1742 in server
              trunk