c2c-oerpscenario team mailing list archive

["Eric Caudal - www.elico-corp.com" <elicoidal@xxxxxxxxxxx>]

Hi Olivier,
I agree on the unique constraint you propose but I still feel that
having a mandatory reference per Category is necessary.

Maybe I understand it wrong but currently if you have one UoM in a
category it can be of 2 main types:
- reference ('Absolute' reference)
- bigger/smaller than the reference ('relative' meaning compared with
something)

Currently the system has no field for the 'reference' UoM in the
relative UoM definition so you cannot specify several 'reference' UoM
for one category . If you have 2 references which one should we compared
with?  In other systems I saw, there was  complete and separate
conversion factor tables which allow you several references (actually
whatever UoM could be a reference)

Now let's take the process logically in case we keep your philosophy
(uniqueness but no constraint on having a mandatory reference UoM and no
'reference' field in UoM definition)
- If you have 1 UoM in a category, it should be 'reference' type by
default (since there is nothing to compare). It doesnot matter actually
to much as it is unique in the category but there is no point of a
semantic lie (bigger than something that does not exist) .
- If you have 2 UoM, one should be reference and the other relative. 2
absolute reference are not possible (as you cannot then refer to them in
the relative UoM) and 2 relative UoM are not possible neither (even if
you calculation is right, the meaning is incorrect and leads to
misunderstanding in the user's head). Still could be acceptable even if
borderline.
- Problem is imagine that you have 3 or more UoM with no  'reference'
type, how do you tell the UoM that the conversion factor for the UoM1 is
relative to UoM2 or UoM3?

That's why I am in favor of having 1 reference mandatory per category
and only one. If you have different UoM in meaning (metric tons or metre
linear), you should create different categories (length, length lineal,
etc...) or create the correct relative connection (eg: 1 ROLL=100 m). 

Where it becomes tricky is that you cannot force a mandatory reference
UoM for a category by SQL since the category is needed in the UoM and
the UoM would be needed in the category. I think we need to find a way
to check that at deletion/creation/modification, there is always at
least one UoM of 'reference' type in the category.    

Another option of course can be to have several references per category,
create a field and specify the reference UoM in the relative UoM
definition (for relative UoM) and of course fix the bug on the reports.
I am not sure I like this option mainly because of the issue of circular
references and more complex design.
 
-- 
Eric

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/731035

Title:
  Reference UoM for category should be checked for uniqueness

Status in OpenERP Modules (addons):
  Confirmed

Bug description:
  Currently any UoM can be set as a reference for a given category which
  seems to be wrong (meaning one category can have several UoM
  references). By conception it is dubious and actually it makes some
  reports crashes like account_invoice_report with the following error
  message:

  Traceback (most recent call last):
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/netsvc.py", line 489, in dispatch
      result = ExportService.getService(service_name).dispatch(method, auth, params)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/service/web_services.py", line 599, in dispatch
      res = fn(db, uid, *params)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/osv.py", line 122, in wrapper
      return f(self, dbname, *args, **kwargs)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/osv.py", line 176, in execute
      res = self.execute_cr(cr, uid, obj, method, *args, **kw)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/osv.py", line 167, in execute_cr
      return getattr(object, method)(cr, uid, *args, **kw)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/orm.py", line 1735, in search
      return self._search(cr, user, args, offset=offset, limit=limit, order=order, context=context, count=count)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/orm.py", line 3981, in _search
      cr.execute('SELECT "%s".id FROM ' % self._table + from_clause + where_str + order_by + limit_str + offset_str, where_clause_params)Traceback (most recent call last):
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/netsvc.py", line 489, in dispatch
      result = ExportService.getService(service_name).dispatch(method, auth, params)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/service/web_services.py", line 599, in dispatch
      res = fn(db, uid, *params)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/osv.py", line 122, in wrapper
      return f(self, dbname, *args, **kwargs)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/osv.py", line 176, in execute
      res = self.execute_cr(cr, uid, obj, method, *args, **kw)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/osv.py", line 167, in execute_cr
      return getattr(object, method)(cr, uid, *args, **kw)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/orm.py", line 1735, in search
      return self._search(cr, user, args, offset=offset, limit=limit, order=order, context=context, count=count)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/osv/orm.py", line 3981, in _search
      cr.execute('SELECT "%s".id FROM ' % self._table + from_clause + where_str + order_by + limit_str + offset_str, where_clause_params)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/sql_db.py", line 78, in wrapper
      return f(self, *args, **kwargs)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/sql_db.py", line 131, in execute
      res = self._obj.execute(query, params)
  ProgrammingError: more than one row returned by a subquery used as an expression

  
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/sql_db.py", line 78, in wrapper
      return f(self, *args, **kwargs)
    File "/usr/local/lib/python2.6/dist-packages/openerp-server_9000/sql_db.py", line 131, in execute
      res = self._obj.execute(query, params)
  ProgrammingError: more than one row returned by a subquery used as an expression

  
  Uniqueness should be checked when the UoM is created/modified. Even more, you should not be able to delete the reference of a category if other UoM depend on it.