openerp-expert-production team mailing list archive

[Albert Cervera i Areny <albert@xxxxxxxxxxx>]

Hi,
the last few days we've been fighting against procurements and stock booking 
(reservation) in v5 and v6. 

There are several problems. For example, if the user removes one purchase 
order line, it doesn't cancel its procurement (that's easily fixable). Also 
there are other usability issues such as when the user modifies the amount in a 
purchase order line she looses the reference of the quantity that is being 
held by the procurement.

From the programmer's point of view, the thing is not better. Procurements use 
a compex workflow which is created in module procurement (v6), but purchase and 
mrp modules extend it. Those workflows listen to purchase.order and 
stock.picking models, meaning that if for some reason one processes only one 
picking line, the change will not be triggered to the procurement, for 
example. Not to say, that those workflows are complex and complicate hacking 
procurements a lot.

From the booking point of view, OpenERP isn't very featureful. In the first 
place, purchase orders lines only have a reference to procurement's move line 
that required the purchase, which means that it will not be possible to group 
those lines when executing the purchase order merge. This means a single 
purchase order line (and also a single stock move) can only be used as booking 
for a single sale. For example, say you buy 1000 units of a product (you may 
purchase it manually or make-to-stock). Say you have 3 customer pickings of 
500 units each but you want to be sure that two of them will get all the 
stock. Currently, the only way to do that would be to validate the purchase 
order first, then split stock moves, and finally fill in the move_dest_id field 
(which is not exposed to the user!).

So wha'ts our proposal? 

We have an initial implementation of what we think should be the solution to 
these issues providing more features for users as well as simplified 
architecture for developers.

The idea is to concentrate in stock booking which will provide, at stock.move 
level, the possibility of pre-assigning virtual stock (extending what 
move_dest_id does). So each stock move can reserve/book stock from a number of 
incomming moves and it's stock can be reserved by a number of outgoing moves. 
In both cases, a quantity and UoM is also attached to the move. Please, take a 
look at the screenshot (stock-move.png) and see Back Bookings and Forward 
Bookings sections, because it's easier to understand.

At the same time, as you can see in the screenshot (stock-move.png) we also 
moved Procurement Information to stock moves. In the screenshot (stock-
move.png), you can see a Procurement -> Stock move. In this case, the 
procurement checkbox is equivalent to procurement.order 'make_to_order' state. 
Once the stock procurement is created, we create the purchase order (or 
production order) but also assign the move to the purchase order lines. Once 
the order has been confirmed, the procurement move is cancelled and the new one 
is created with the same Forward Booking information (so customer stock move 
will be marked as Available when purchased products arrive). Please, take a 
look at purchase-order-line.png screenshot to get an idea of what users can 
see in purchase order lines once the purchase order has been confirmed.

I said, that the solution would simplify things for developers but, how? The 
answer is simple: we can drop procurement.order and it's related workflow. Even 
more, as we provide a new function called 'create_procurement()' in stock.move 
model, we can remove the procurement creation part of sale/sale.py and simply 
add a function call. We can also remove reference to procurements from 
purchase.order.line (and other places) because everything is handled at 
stock.move level.

Note that we know that procurements are also used for services and those do 
not currently create stock moves but this in itself is a very weak argument 
IMHO:

- In the first place because nothing prevents us from creating stock moves for 
services. Those could even have a boolean field so they're not shown in 
stock.move list view, if one wishes.
- Currently handling both service and stockable products is a mess (sorry, 
haven't tested in v6, but at least it was in v5) because if users invoice from 
pickings and there are only service products, a purchase order would not 
create a picking and wouldn't let the user create the invoice from the order 
either. What we currently do, is use Consumible instead of Services so users 
know they can always create an invoice and they always have to go to the same 
place to create them. So we're already creating stock moves for Service 
products anyway.

What do you think? I know procurements are pretty complex and probably many 
will not be familiar with its internals. Even after the first implementation we 
may have missed something in the analysis ourselves, although it's pretty 
clear to me that the proposed approach is much better than what we have now.

But please, share your view, even if it's from a user point of view. I think 
it'll be easier to make users understand the new architecture than the old one 
is, but your vision may be different. Also let me know if my explanations were 
not clear enough.

We're particularly interested in OpenERP sa point of view. Do you think this 
could be integrated in future versions (we're willing to work on this).

-- 
Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners
Tel: +34 93 553 18 03
skype: nan-oficina

http://twitter.com/albertnan 
http://www.nan-tic.com/blog