Conversion of products without production orders

Registered by Davide Corio on 2010-03-16

At the moment, the only way to convert a roll of cable into meters of cable is to specify a BOM for the meter of cable which include a percentage of the roll.

eg: 1 MT of CABLE = 1/50 of CABLE ROLL

or

eg: 1 LT of PAINT = 1/200 of PAINT DRUM

Unit conversion could not be used, because we buy the roll and sell the meters which are different items.

The system has be able to automatically create production orders, without the need to specify the "inverse" BOM for the final products.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Sprints

Whiteboard

===GG 19.03.2010=====
I agree it is a problem. I am thinking a lot about new UoM concept for let say 6.0. But it is still foggy.

Generally I think that packing units should be better integrated into unit system. You should be able to define roll of cable as packing (which is possible now). And define packing unit as purchase unit (which is not possible).

Another example of usage of packing units is that warehouse worker should be able to enter to system that he receives from supplier 2 full palettes of rolls of cables and 5 rolls without palette. System should convert 2 palettes to rolls add 5 rolls and convert all this to default unit meters according to packing rates. Otherwise worker has to calculate picking by calculator. The same problem is in Periodical inventory. Worker should be able to count only palettes and packing and enter these values to system. System should convert entered values to default units (kg, m, PCE). Otherwise worker has a lot of spreadsheet calculation before he can use OpenERP.

Current concept of UoM is based on categories and is going to use two UoM fields on docs (UoM and UoS). Going further this way we should add third UoM field - UoP (unit of packing). Generally I think it evolute to be not smart. So I think we should change UoM concept to have one UoM field but it should be clever system to have on docs this UoM which is needed. And UoM can be defined individually for product as:
- purchase unit,
- sales unit,
- packing 1stlevel unit,
- packing 2ndlevel unit,
- palette unit,
- price unit (something to avoid rounding problem)
- OLAP unit (I know cases that company needed to use in OLAP different units than operation units - for comparison purpose)

It needs a lot of considerations and discussion to change it so totally.

On the other hand may be someone provide smart solution to expand current system. I think allowing to use UoP in various places (even as sales unit) would be also good enough.
====GG end===========

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.