Inventory: movement input with date prior to physical inventory are reflected in stocks

Currently not possible at all due to the way openerp manages the physical inventories: it's creating stock move from or to scrap location in order to adjust the current stock.

So it should be clear that when doing a physical inventory, all previous stock moves should be already entered into the system. Nevertheless, thanks for the contribution,

Quentin

Hopefully this should be there for the future release.

Hello,
Thank you for your suggestion! However this is unfortunately out of the scope of the current OpenERP release, so we cannot implement it. as said in comment#1 by qdp,
Let's close this bug for now, for the sake of clarity in Launchpad, it can always be reopened later when we consider new features for future roadmaps.
Thank you for your understanding!

What is the status of this bug please?
If this is not fixed yet, it should not remain "won't fix".
Lionel Sausin.

Please don't mark this bug "won't fix", because it's a required feature for most companies, but won't fix will make the bug invisible to the community.
If the core team can't or won't tackle this, it's still an opportunity for community contributions, so please mark this bug "confirmed", or "opinion".
Lionel.

I have create a series of (7 0 untestet) modules which allows to enter dates in stock moves and inventories (as well as the associated values)

http://bazaar.launchpad.net/~camptocamp/c2c-rd-addons/6.1/files (or 7.0)
c2c_stock_accounting and others

Two solutions can be implemented for this problem :
1/ we can refuse to change the state to "done" for all the stock moves dated before an inventory of the same product and location.
2/ we can make the function field "qty_available" (and others) use the latest inventory as a starting point to compute the current quantity, and only add the stock moves dated after the inventory.

Solution 2/ might be a performance booster, but it's pretty subtle because a product can be in many inventories at many dates in many locations.
So we're currently implementing solution 1/ and we hope to push a branch tomorrow.
Lionel Sausin

What we expect is that when users will get an error message, they will
change the source or location to something else - probably an inventory
location. But maybe this could be automated. We could even go so far as
to allow new moves, and make automatic chained moves to an inventory
location.
Lionel

Le 24/05/2013 01:38, Eric Caudal a écrit :
> Hi Lionel,
> Solution 1 seems to me unpractical and difficult to apply as is in
> reality: what if you have uncommited moves from the past (with pending
> invoicing)
> Solution 2 seems impossible as is: you have partial inventories etc.
> that makes it unrealistic.
>
> Solution 1 could be good but at some point we should come to a point
> where before doing an inventory for a given location you need to check
> that no pending moves are existing for the pair location/product/prod lot.
>
> A must would be something similar as the idea of not draft moves and
> periods management in accounting (but we are still far far far away
> from this...).

I've push a module for v6.0 called "stock_inventory_date_constraint" to refuse stock moves dated before an inventory in lp:~numerigraphe/openobject-addons/6.0-public .
I'll try to port it to v7.0 and propose it for adoption by the community warehouse management project.
Lionel.

Eric,
I humbly admit that I was naive with regards to this feature - It's OK, my being naive is not a bug, it's a feature of mine :)
I've pushed an improved implementation for solution 1, and it's now pretty complex indeed but it lets users take care of moves scheduled before the inventory, so it should work.

Anyway, the module has an extensive test file which should be reused by anyone trying to implement a better solution.

There may still be corner cases not covered by our module but unless we get stuck, that's all we're going to make for the moment.
But I'd really like to see work being done on a better solution, directly in the way qty_available is computed. Hackers wanted.

Lionel Sausin.

hum... i'm not sure it's a bug: it depends on the time you made the stock move. Was it before or after the invetory time? Otherwise, i suppose that when you want the virtual stock of a product at a given date, you always want the moves of that day included..

anyway, it would be great if you could spot the patch you think about in a merge proposal: finding it in the history, linked branches... may be a bit annoying :-)

qdp: sorry I didn't make it clear, but our solution was in a home-grown software outside OpenERP, so I don't have a patch at all.
I'm not confident with the new quant code to make a patch for trunk-wms, but if you make sure no moves are introduced in the past at all then this bug won't happen.
Just 2 things come to my mind:
- if I make a new inventory before an existing inventory, make sure it does not change the latest one's stock levels
- make sure no moves with past dates can be introduced through the API either (XML-RPC scripts for example)
Lionel.

Just to avoid confusion : you have to consider that inventory data is definitive, like a new starting point for all further calculations.
Whatever you record before/after an inventory, you must always make sure the quantity at the date of the inventory is unchanged.

So in a way, you do not "always want the moves of that day included": if ever you allow a past move to be inserted at a time before an inventory, then it must not change the quantity available at the time of the inventory because it was already accounted for in the inventory.

this doesn't affect trunk-wms anymore