Conversion of products without production orders
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
- Started by
- Completed by
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===========
