← Back to team overview

openerp-wms-expert team mailing list archive

[Blueprint new-partial-picking-wizard] Alternative partial picking procedure

 

Blueprint changed by Numérigraphe:

Whiteboard changed:
  == Implementation status==
  The main branch is lp:~numerigraphe/openobject-addons/trunk-stock-backorder-rewrite:
- [1b], [1c], [2b] and [3a] are implemented. [2a] is being implemented, so average prices are still wrong in some cases.
+ [1b], [1c], [2a], [2b] and [3a] are implemented. is being implemented, so average prices are still wrong in some cases.
  [2a] and [2b] will need to be re-implemented later if the average price calculation is rewritten in the trunk, as was announced by the Core Team.
  The following branches are also merged into this main branch:
  - lp:~numerigraphe/openobject-addons/trunk-stock-split-move-refactoring partially implement [1a] : we've added a new wizard to split moves in a clean way. We'd like to refactor the other wizards too later on.
  - lp:~numerigraphe/openobject-addons/trunk-stock-qty-help provides additional GUI helps useful for [3a]
+ - lp:~numerigraphe/openobject-addons/trunk-stock-editable-compatible-picking-line fixes issues that prevent the picking lines from being editable as suggested by Don Kirkby.
  
  == Notes ==
  Additions and corrections are most welcome here.
  ...
  
  Side notes and additional thoughts:
  ----
  Note : are partial moves a stock concern in the first place?
  It would be tempting to declare that the partial shipping management should not be handeled by the stock module at all. After all, isn't it more intuitive to let users change the quantity on the stock move? Then the ERP could compare that shipped quantity with that of the origin order (sale, purchase, production, procurement) and create the needed backorder.
  Unfortunately that would require very deep changes to several workflows that expect events to come from the stock to progress.
  There is also a problem with procurements, which only have a link to a single stock move. Finishing that move means the procurement is complete, which may mean the sale order line is honoured: no backorder can be made then.
  
  ---
  A simpler but still elaborate approach would be to integrate the features of the wizard directly into the picking. This would have the advantage to let users process part of the picking, save it, and recall it later on.
  This boils down to adding a new object "Stock Move Order" representing the ordered stock move vs the actual stock.move. Back orders would be created by comparing the two.
  Or it could just as well be considered the other way round: we could add a distinct "Picking Line" object between stock.picking and stock.move: it would contain the required products and quantities, with a o2m relation to stock.move representing the actual stock moves.
  
  ---
  Another possible approach : make the main views read-only and move all the features to the "process" wizard
  Moving everything to the wizard has several problems. First it's not consistent with the rest of OpenERP. Moreover, it makes data volatile, which can be a real problem for complex cases and data that take long to key in.
  
  ---
  If the user will be making several changes to the move lines in a picking, then you might consider letting him edit the lines in the tree view like some of the accounting screens do. Even without that, this still sounds like an improvement over the wizards, but the wizards did let the user edit all the prices at once, for example.
  ~ Don Kirkby
  => We do make the list editable for our own deployments in a custom module (not public, but all it takes is to add editable=bottom to the tree views), so maybe it's needed indeed.

-- 
Alternative partial picking procedure
https://blueprints.launchpad.net/openobject-addons/+spec/new-partial-picking-wizard