unit factor is limited to 5 zeros

[Ana Juaristi Olalde]

I have got a category measure unit size.

The master unit is meter, but I need having m2, m3 and related measure units like mm, mm2, mm3, micrometer

so 1m = 1000mm
but 1m = 1000000micrometer

If I try including a conversion factor where I need more than 5 zeros, system crashes showing this error:

Environment Information :
System : Windows-XP-5.1.2600-SP3
OS Name : nt
Operating System Release : XP
Operating System Version : 5.1.2600
Operating System Architecture : 32bit
Operating System Locale : es_ES.cp1252
Python Version : 2.5.2
OpenERP-Client Version : 5.0.6
Last revision No. & ID :Bazaar Package not Found !Traceback (most recent call last):
  File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in dispatch
    result = LocalService(service_name)(method, *params)
  File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in __call__
    return getattr(self, method)(*params)
  File "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py", line 38, in execute
    res = super(recording_objects_proxy, self).execute(*args, **argv)
  File "/home/xabier/openerp-server/server/bin/service/web_services.py", line 583, in execute
    res = service.execute(db, uid, object, method, *args)
  File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in execute
    res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/home/xabier/openerp-server/server/bin/osv/orm.py", line 2458, in write
    'where id in ('+ids_str+')', upd1)
  File "/home/xabier/openerp-server/server/bin/sql_db.py", line 76, in wrapper
    return f(self, *args, **kwargs)
  File "/home/xabier/openerp-server/server/bin/sql_db.py", line 120, in execute
    res = self._obj.execute(query, params)
ProgrammingError: numeric field overflow
DETAIL: A field with precision 12, scale 6 must round to an absolute value less than 10^6.

This is limiting the possibility of having all posible and needed conversion factors on measure units, so I think it could be considered a bug or maybe wishlist

Thank you!!

Ana

[Nhomar - Vauxoo (nhomar)]

Hello Ana.

The bug is happend to me too!!!!, only I want to add some comentary:

mm2, mm3 CAN NOT be ralated with mm or micrometer (symbol is called Miú)
because the first one is Area Units and the second one are Volume Units, for
this reason you must not relate this units, at least you want to make
calculation between them...... Area*Length is Volume etc....

Thanks

2010/1/22 Ana Juaristi Olalde <email address hidden>

> Public bug reported:
>
> I have got a category measure unit size.
>
> The master unit is meter, but I need having m2, m3 and related measure
> units like mm, mm2, mm3, micrometer
>
> so 1m = 1000mm
> but 1m = 1000000micrometer
>
> If I try including a conversion factor where I need more than 5 zeros,
> system crashes showing this error:
>
> Environment Information :
> System : Windows-XP-5.1.2600-SP3
> OS Name : nt
> Operating System Release : XP
> Operating System Version : 5.1.2600
> Operating System Architecture : 32bit
> Operating System Locale : es_ES.cp1252
> Python Version : 2.5.2
> OpenERP-Client Version : 5.0.6
> Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> call last):
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> dispatch
> result = LocalService(service_name)(method, *params)
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> __call__
> return getattr(self, method)(*params)
> File
> "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> line 583, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> wrapper
> return f(self, dbname, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in
> execute_cr
> return getattr(object, method)(cr, uid, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/orm.py", line 2458, in
> write
> 'where id in ('+ids_str+')', upd1)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 76, in
> wrapper
> return f(self, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 120, in
> execute
> res = self._obj.execute(query, params)
> ProgrammingError: numeric field overflow
> DETAIL: A field with precision 12, scale 6 must round to an absolute value
> less than 10^6.
>
> This is limiting the possibility of having all posible and needed
> conversion factors on measure units, so I think it could be considered a bug
> or maybe wishlist
>
> Thank you!!
>
> Ana
>
> ** Affects: openobject-addons
> Importance: Undecided
> Status: New
>
> --
> unit factor is limited to 5 zeros
> https://bugs.launchpad.net/bugs/511193
> You received this bug notification because you are subscribed to
> OpenObject.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> I...

[gpa(OpenERP) (gpa-openerp)]

Hello Ana,

Can you apply a little change for this error?
Increase the size of the factor field from (12,6) to (16,6).

Thank you

[Ana Juaristi Olalde (ajuaristio)]

I have to do that directly on database? Or on class definition file?
Sorry I don't understand. I think it should be changed on official distribution if needed. Otherwise I will loose change if I upgrade code.
Is there any way to change without be affected on upgrading code?

Thank you very much!!!

Ana

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Ana,

If you sense risk on upgrading the module after this change in class definition.

Follow this on postgresql:
You need to run these queries:
First check \d product_uom and observe the size of factor column.

1. alter table product_uom rename column factor to temp_column; (renaming factor to temp_column)
2. alter table product_uom add column factor numeric(16,6);(Adding our own column)
3. update product_uom set factor=temp_column;(Coying data back to factor column from temp_column)
4. alter table product_uom drop column temp_column cascade;(Remove temp_column)
5. \d product_uom; Observe the difference.

Hope this helps.

I am invalidating this bug as this is not a bug,this is a limitation of factor set in generic.

Thanks.

[Ana Juaristi Olalde (ajuaristio)]

Jay... sorry. I don't think this is the correct way to make thinks. This bug
is causing that I can't define 1kg like the unit master and a mg like
refactored unit. I think it should be changed on affected module not to be
happen again just like another bug it it's not related to python code.

Thank you for sending me the querys.

2010/2/4 Jay (Open ERP) <email address hidden>

> Hello Ana,
>
> If you sense risk on upgrading the module after this change in class
> definition.
>
> Follow this on postgresql:
> You need to run these queries:
> First check \d product_uom and observe the size of factor column.
>
> 1. alter table product_uom rename column factor to temp_column; (renaming
> factor to temp_column)
> 2. alter table product_uom add column factor numeric(16,6);(Adding our own
> column)
> 3. update product_uom set factor=temp_column;(Coying data back to factor
> column from temp_column)
> 4. alter table product_uom drop column temp_column cascade;(Remove
> temp_column)
> 5. \d product_uom; Observe the difference.
>
> Hope this helps.
>
> I am invalidating this bug as this is not a bug,this is a limitation of
> factor set in generic.
>
> Thanks.
>
>
> ** Changed in: openobject-addons
> Status: New => Invalid
>
> --
> unit factor is limited to 5 zeros
> https://bugs.launchpad.net/bugs/511193
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenObject Addons Modules: Invalid
>
> Bug description:
> I have got a category measure unit size.
>
> The master unit is meter, but I need having m2, m3 and related measure
> units like mm, mm2, mm3, micrometer
>
> so 1m = 1000mm
> but 1m = 1000000micrometer
>
> If I try including a conversion factor where I need more than 5 zeros,
> system crashes showing this error:
>
> Environment Information :
> System : Windows-XP-5.1.2600-SP3
> OS Name : nt
> Operating System Release : XP
> Operating System Version : 5.1.2600
> Operating System Architecture : 32bit
> Operating System Locale : es_ES.cp1252
> Python Version : 2.5.2
> OpenERP-Client Version : 5.0.6
> Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> call last):
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> dispatch
> result = LocalService(service_name)(method, *params)
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> __call__
> return getattr(self, method)(*params)
> File
> "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> line 583, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> wrapper
> return f(self, dbname, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in
> execute_cr
> return getattr(object, method)(cr, uid, *args, **...

[Numérigraphe (numerigraphe)]

Jay, just out of curiosity, why are you considering this bug report incomplete ? Launchpad will drop it in a few month if it's marked incomplete.
Lionel

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hi Lionel,
This bug is related to accuracy for UOM.

Should we treat this as a general request?

Thanks.

[Numérigraphe (numerigraphe)]

Well I don't know. Maybe you should ask the manufacturing experts - but Ana's one of them with a reputation already.
I was just pointing that this bug is marked to expire in 2 month, so shouldn't we mark it "new" if it needs discussion?

BTW, my own 2c about this issue: if you change factor to numeric(16,6), don't you need to change the inverse factor to numeric(16,10)?
And, will it degrade performances to use bigger decimal accuracy in the standard?

Lionel

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello,

We want manufacturing experts to put their opinions here to sort out this issue.
Thanks.

[Ferdinand (office-chricar)]

http://www.onlineconversion.com/

I would expect that OpenERP should support (and ship?) "common" conversions mentioned here
loadable as extra addons module ?
http://www.onlineconversion.com/weight_common.htm
http://www.onlineconversion.com/length_common.htm
http://www.onlineconversion.com/volume.htm

[Ana Juaristi Olalde (ajuaristio)]

As shown on Ferdinand links,
1 centigram = 1.0e-8 tonne

So we would need at less 8-9 accuracy for all kind UOM conversion. But maybe
only going up to 6, would be enough? Yes, I think it needs discussion from
other manufacturing experts to define it.

Lionel, thank you for your comment about my reputation :)

2010/3/26 Ferdinand @ ChriCar <email address hidden>

> http://www.onlineconversion.com/
>
> I would expect that OpenERP should support (and ship?) "common" conversions
> mentioned here
> loadable as extra addons module ?
> http://www.onlineconversion.com/weight_common.htm
> http://www.onlineconversion.com/length_common.htm
> http://www.onlineconversion.com/volume.htm
>
> --
> unit factor is limited to 5 zeros
> https://bugs.launchpad.net/bugs/511193
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> I have got a category measure unit size.
>
> The master unit is meter, but I need having m2, m3 and related measure
> units like mm, mm2, mm3, micrometer
>
> so 1m = 1000mm
> but 1m = 1000000micrometer
>
> If I try including a conversion factor where I need more than 5 zeros,
> system crashes showing this error:
>
> Environment Information :
> System : Windows-XP-5.1.2600-SP3
> OS Name : nt
> Operating System Release : XP
> Operating System Version : 5.1.2600
> Operating System Architecture : 32bit
> Operating System Locale : es_ES.cp1252
> Python Version : 2.5.2
> OpenERP-Client Version : 5.0.6
> Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> call last):
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> dispatch
> result = LocalService(service_name)(method, *params)
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> __call__
> return getattr(self, method)(*params)
> File
> "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> line 583, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> wrapper
> return f(self, dbname, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in
> execute_cr
> return getattr(object, method)(cr, uid, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/orm.py", line 2458, in
> write
> 'where id in ('+ids_str+')', upd1)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 76, in
> wrapper
> return f(self, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 120, in
> execute
> res = self._obj.execute(query, params)
> ProgrammingError: numeric field overflow
> DETAIL: A field with precision 12, scale 6 must round to an absolute value
> less than 10^6.
>
> This is limiting the possibility of ...

[filsys (office-filsystem)]

Yes, in such cases would be required theoretical accuracy of 8-9 digits.
There are no many companies that have the raw material stock in tonnes
and consume in milligrams. Maybe some medicine factory. But I think
there is a processing, sorting and allotments of raw material, which is
a preproduction phase, which may include conversion to an intermediate
unit of measurement (eg tonnes in kg)..
I think the effort should focus primarily on improvenet of functionality
and usabilitaty of mrp to cover more industries.
Best wishes,
Dumitru Gilcescu
Fil System

On Sat, 2010-03-27 at 11:20 +0000, Ana Juaristi Olalde wrote:

> As shown on Ferdinand links,
> 1 centigram = 1.0e-8 tonne
>
> So we would need at less 8-9 accuracy for all kind UOM conversion. But maybe
> only going up to 6, would be enough? Yes, I think it needs discussion from
> other manufacturing experts to define it.
>
> Lionel, thank you for your comment about my reputation :)
>
> 2010/3/26 Ferdinand @ ChriCar <email address hidden>
>
> > http://www.onlineconversion.com/
> >
> > I would expect that OpenERP should support (and ship?) "common" conversions
> > mentioned here
> > loadable as extra addons module ?
> > http://www.onlineconversion.com/weight_common.htm
> > http://www.onlineconversion.com/length_common.htm
> > http://www.onlineconversion.com/volume.htm
> >
> > --
> > unit factor is limited to 5 zeros
> > https://bugs.launchpad.net/bugs/511193
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
> > Status in OpenObject Addons Modules: Confirmed
> >
> > Bug description:
> > I have got a category measure unit size.
> >
> > The master unit is meter, but I need having m2, m3 and related measure
> > units like mm, mm2, mm3, micrometer
> >
> > so 1m = 1000mm
> > but 1m = 1000000micrometer
> >
> > If I try including a conversion factor where I need more than 5 zeros,
> > system crashes showing this error:
> >
> > Environment Information :
> > System : Windows-XP-5.1.2600-SP3
> > OS Name : nt
> > Operating System Release : XP
> > Operating System Version : 5.1.2600
> > Operating System Architecture : 32bit
> > Operating System Locale : es_ES.cp1252
> > Python Version : 2.5.2
> > OpenERP-Client Version : 5.0.6
> > Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> > call last):
> > File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> > dispatch
> > result = LocalService(service_name)(method, *params)
> > File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> > __call__
> > return getattr(self, method)(*params)
> > File
> > "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> > line 38, in execute
> > res = super(recording_objects_proxy, self).execute(*args, **argv)
> > File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> > line 583, in execute
> > res = service.execute(db, uid, object, method, *args)
> > File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> > wrapper
> > return f(self, dbname, *args, **kwargs)
> > File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> > exe...

[Mecatis (engineering)]

Hello !

For us in the engineering industry, I'm understand with "Ana Juaristi Olalde" !
We need minimum 6 digits but 9 digits would be better !

- for volume that we use, from m3 to mm3, it's 10^9 digits
- for length that we use, from meter to 0,01mm it's 10^6 digits

Also 10^5 is not enough

Best regards

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

Hi,

I mark this bug as High Importance, I agree with Mecatis and Ana Juristi.

We do need more precision on the UOM level, this is a must have. We don't need to spare anything here, so let's increase the precision.

Regards,

[Nhomar - Vauxoo (nhomar)]

Hello.

I think this bug must be taken in account for the next release seriously.

There are a lot of industries that sell or convert in little unit an buy in big units we have 3 customers and the three have the problem.

thanks.

[Ana Juaristi Olalde (ajuaristio)]

I totally agree with Nhomar.

This bug is causing serious issues on some implementations.

Thanks!!!

2010/4/26 Nhomar Hernández - http://openerp.netquatro.com <email address hidden>

> Hello.
>
> I think this bug must be taken in account for the next release
> seriously.
>
> There are a lot of industries that sell or convert in little unit an buy
> in big units we have 3 customers and the three have the problem.
>
> thanks.
>
> --
> unit factor is limited to 5 zeros
> https://bugs.launchpad.net/bugs/511193
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> I have got a category measure unit size.
>
> The master unit is meter, but I need having m2, m3 and related measure
> units like mm, mm2, mm3, micrometer
>
> so 1m = 1000mm
> but 1m = 1000000micrometer
>
> If I try including a conversion factor where I need more than 5 zeros,
> system crashes showing this error:
>
> Environment Information :
> System : Windows-XP-5.1.2600-SP3
> OS Name : nt
> Operating System Release : XP
> Operating System Version : 5.1.2600
> Operating System Architecture : 32bit
> Operating System Locale : es_ES.cp1252
> Python Version : 2.5.2
> OpenERP-Client Version : 5.0.6
> Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> call last):
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> dispatch
> result = LocalService(service_name)(method, *params)
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> __call__
> return getattr(self, method)(*params)
> File
> "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> line 583, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> wrapper
> return f(self, dbname, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in
> execute_cr
> return getattr(object, method)(cr, uid, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/orm.py", line 2458, in
> write
> 'where id in ('+ids_str+')', upd1)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 76, in
> wrapper
> return f(self, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 120, in
> execute
> res = self._obj.execute(query, params)
> ProgrammingError: numeric field overflow
> DETAIL: A field with precision 12, scale 6 must round to an absolute value
> less than 10^6.
>
> This is limiting the possibility of having all posible and needed
> conversion factors on measure units, so I think it could be considered a bug
> or maybe wishlist
>
> Thank you!!
>
> Ana
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-addons/+bug/511193/+...

[Jay Vora (Serpent Consulting Services) (jayvora)]

We shift this to be done on trunk.

[Nhomar - Vauxoo (nhomar)]

Hi Jay,

In other words, we need to develop other module to use a good convert unit
on Stable????

If is yes, I'm not agree but no problem, I develop this and override the
original fields definition, but I think is not a "Clean!"Solution!!!

Nhomar
PD: I can make the change on addons and propose for merge if you will pay
attention, because I think is a BUG not a WISHLIST. Thanks.

2010/4/26 Jay (Open ERP) <email address hidden>

> We shift this to be done on trunk.
>
> ** Also affects: openobject-addons/trunk
> Importance: High
> Status: Confirmed
>
> ** Also affects: openobject-addons/5.0
> Importance: Undecided
> Status: New
>
> ** Changed in: openobject-addons/5.0
> Status: New => Won't Fix
>
> ** Changed in: openobject-addons/5.0
> Milestone: None => 5.0.10
>
> ** Changed in: openobject-addons/trunk
> Milestone: 5.0.10 => 6.0
>
> --
> unit factor is limited to 5 zeros
> https://bugs.launchpad.net/bugs/511193
> You received this bug notification because you are subscribed to
> OpenObject.
>
> Status in OpenObject Addons Modules: Confirmed
> Status in OpenObject Addons 5.0 series: Won't Fix
> Status in OpenObject Addons trunk series: Confirmed
>
> Bug description:
> I have got a category measure unit size.
>
> The master unit is meter, but I need having m2, m3 and related measure
> units like mm, mm2, mm3, micrometer
>
> so 1m = 1000mm
> but 1m = 1000000micrometer
>
> If I try including a conversion factor where I need more than 5 zeros,
> system crashes showing this error:
>
> Environment Information :
> System : Windows-XP-5.1.2600-SP3
> OS Name : nt
> Operating System Release : XP
> Operating System Version : 5.1.2600
> Operating System Architecture : 32bit
> Operating System Locale : es_ES.cp1252
> Python Version : 2.5.2
> OpenERP-Client Version : 5.0.6
> Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> call last):
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> dispatch
> result = LocalService(service_name)(method, *params)
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> __call__
> return getattr(self, method)(*params)
> File
> "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> line 583, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> wrapper
> return f(self, dbname, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in
> execute_cr
> return getattr(object, method)(cr, uid, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/orm.py", line 2458, in
> write
> 'where id in ('+ids_str+')', upd1)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 76, in
> wrapper
> return f(self, *args, **kwargs)
> File "/home/xabi...

[Stephane Wirtel (OpenERP) (stephane-openerp)]

Hi all,

I asked to Jay to shift the bug to Trunk (6.0).

Why ?

1. Currently, there is a limit with the accuracy in stable, but we can't fix in the current version. Because we risk to introduce new bugs and I want to avoid that.
2. There is a featured module in trunk (decimal_precision), someone can propose a backport to stable, but don't forget to change every modules of stable.

Regards,

Stephane

[Nhomar - Vauxoo (nhomar)]

Hello Stephane.

This is a good reason, let me try to backport it to Stable, and try on our
Productions enviroments, after this, we will push this new module on
stable-extra-5.0.

If you have some aditional information that you think is relevant, before
begin the work, This will be welcome!!!

Nhomar

2010/4/26 Stephane (Open ERP) <email address hidden>

> Hi all,
>
> I asked to Jay to shift the bug to Trunk (6.0).
>
> Why ?
>
> 1. Currently, there is a limit with the accuracy in stable, but we can't
> fix in the current version. Because we risk to introduce new bugs and I want
> to avoid that.
> 2. There is a featured module in trunk (decimal_precision), someone can
> propose a backport to stable, but don't forget to change every modules of
> stable.
>
>
> Regards,
>
> Stephane
>
> --
> unit factor is limited to 5 zeros
> https://bugs.launchpad.net/bugs/511193
> You received this bug notification because you are subscribed to
> OpenObject.
>
> Status in OpenObject Addons Modules: Confirmed
> Status in OpenObject Addons 5.0 series: Won't Fix
> Status in OpenObject Addons trunk series: Confirmed
>
> Bug description:
> I have got a category measure unit size.
>
> The master unit is meter, but I need having m2, m3 and related measure
> units like mm, mm2, mm3, micrometer
>
> so 1m = 1000mm
> but 1m = 1000000micrometer
>
> If I try including a conversion factor where I need more than 5 zeros,
> system crashes showing this error:
>
> Environment Information :
> System : Windows-XP-5.1.2600-SP3
> OS Name : nt
> Operating System Release : XP
> Operating System Version : 5.1.2600
> Operating System Architecture : 32bit
> Operating System Locale : es_ES.cp1252
> Python Version : 2.5.2
> OpenERP-Client Version : 5.0.6
> Last revision No. & ID :Bazaar Package not Found !Traceback (most recent
> call last):
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 244, in
> dispatch
> result = LocalService(service_name)(method, *params)
> File "/home/xabier/openerp-server/server/bin/netsvc.py", line 73, in
> __call__
> return getattr(self, method)(*params)
> File
> "/home/xabier/openerp-server/server/bin/addons/base_module_record/base_module_record.py",
> line 38, in execute
> res = super(recording_objects_proxy, self).execute(*args, **argv)
> File "/home/xabier/openerp-server/server/bin/service/web_services.py",
> line 583, in execute
> res = service.execute(db, uid, object, method, *args)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 59, in
> wrapper
> return f(self, dbname, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 118, in
> execute
> res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/osv.py", line 110, in
> execute_cr
> return getattr(object, method)(cr, uid, *args, **kw)
> File "/home/xabier/openerp-server/server/bin/osv/orm.py", line 2458, in
> write
> 'where id in ('+ids_str+')', upd1)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 76, in
> wrapper
> return f(self, *args, **kwargs)
> File "/home/xabier/openerp-server/server/bin/sql_db.py", line 120, in
> execute
> res = self._...

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hi Nhomar,
Thank you for taking care of this issue. We appreciate this step from you.
Make sure, the factors calculation at other places(I mean other modules if they use) also needs to be clean.
Let us know when you push the module or propose a merge.
Thanks.

[Syd Viscious (sydspoetry-gmail)]

I do manufacture, and regularly order by the ton and produce by the mg and track by the microgram.

anyone that is doing composition of raw materials i.e. chemicals, food stuffs etc needs a large range (even than 10^9);

The reasons for this are simple:

I procure materials by the metric tonne
I schedule material use by the kg
I pack material by the gm
Said material has characteristics measured in mgs
Said material has quality assurance checks that test trace materials measured in mcg's

If you're going to fix this problem (and lord, I certainly consider it critical!) then you should do so in such a manner as to remove the problems with precisions period. Picking another range (other than 10^5) doesn't correct the problem, it is simply a palliative that will inevitably need corrections yet again. Email me at <email address hidden> if you want to discuss this further.

Additionally (since I'm just getting started with OpenERP and haven't located a mailing list yet), another point:
I'm not sure what rounding algorithm you are using but you should check out Bankers Rounding. Eliminates an inherent bias in rounding.

[Nhomar - Vauxoo (nhomar)]

Hello Syd.

We are working with food and you are totally right.

We are not trying our concepts in production yet. Because we have some
priorities first.

If you have an special algorithm for this you can share it by this way, for
us should be very useful.

Thanks.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hi Nhomar,

I am setting the suitable status to this bug for 5.0 .
Meanwhile, do post a solution when you find( as you were working on it).

Thanks,

[Fabien (Open ERP) (fp-tinyerp)]

It's better to not use a float field and continue using a decimal field.
I propose to simply increase the digits from 6 to 12. The goal is not to satisfy all cases, but the most common ones.

[Rucha (Open ERP) (rpa-openerp)]

Hello,
It has been fixed in lp:~openerp-dev/openobject-addons/rpa-dev-addons2
revision-id: <email address hidden>
revision-no: 4498
It will be available in trunk soon,
Thanks

[Zack Powers (zpowers)]

I agree that with Fabien that float data-type is inadequate for the arithmetic requirements for unit conversion. In both Python[1] and PostgreSQL[2], the precision of float types are dependent on CPU architecture and Operating System. An Ideal fix would be a data type that is exact to any arbitrary number of digits precision. In Python, the decimal type defaults to 28 digits of precision[3] however has no defined maximum in implementation. In the PostgreSQL manual, the numeric data type is recommended for fields of arbitrary precision. As stated in the documentation[4] "Specifying NUMERIC without any precision or scale creates a column in which numeric values of any precision and scale can be stored, up to the implementation limit on precision.". This datatype, allows for arbitrary precision and and is arithmetically exact, and should be the proper solution for this bug.

[1]http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
[2]http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-FLOAT
[3]http://docs.python.org/library/decimal.html#module-decimal
[4]http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-NUMERIC-DECIMAL