odoomrp / odoomrp-wip Goto Github PK

Dijimos de quitar el segundo one2many y que la relación se hiciera automáticamente por dentro para simular un many2many.

El one2many sigue ahí y además al intentar meter manualmente un dato da este traceback

  return self.endpoint(*a, **kw)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 688, in __call__
    return self.method(*args, **kw)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 363, in response_wrap
    response = f(*args, **kw)
  File "/opt/odoo/odoomrp/odoo/addons/web/controllers/main.py", line 941, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "/opt/odoo/odoomrp/odoo/addons/web/controllers/main.py", line 933, in _call_kw
    return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 357, in old_api
    result = method(recs, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 5679, in onchange
    record._onchange_eval(name, field_onchange[name], result)
  File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 5613, in _onchange_eval
    method_res = getattr(self._model, method)(*args)
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/odoomrp/temp_addons/partner_rel_ext/models/partner_rel_ext.py", line 36, in onchange_customer1_id
    if client1_id == part.id:
NameError: global name 'client1_id' is not defined

Al confirmar un pedido de compra, me da un warning:
There is no income account defined for this product: "Ordenador" (id:18)

El ordenador tiene definidas las cuentas en su categoría, pero no lo está pillando.

Debe ser una solicitud específica de IACS. QUITAR, esta validación y dejar la standar de coger la cuenta de la categoría.

Off topic: Me ha salido un aviso Amount Error. The amount of this line, is greater than the available budget line (ESTUPENDAMENTE) Está controlando que no se permita hacer compras por encima del presupuesto asignado, en la confirmación de la compra. Pensé que esto no se había llegado a desarrollar. 👍

Analytic Line NOT FOUND!

Analytic Line with expense_type MOVE_LINE not found

Hola según la tarea que tengo asignada nuestro módulo de 6.1:

El módulo que linka reclamaciones con albaranes y reparaciones,
de tal forma que visualizas en una reclamación los albaranes implicados.

El primero de envío de albarán, el segundo de devolución del cliente y
entrada a sat y el tercero si es necesario de devolución de sat a cliente

Pedro me comento que le echara un vistazo a los módulos de RMA de la comunidad.
https://github.com/OCA/rma
Los he estado mirando y la verdad es que son bastante más extendidos de lo que hace actualmente nuestro módulo, entonces no se hasta que punto puede merecer la pena migrar uno de esos módulos para añadir 4 mejoras en las vistas, como lo veis?

OpenERP Server Error
Traceback (most recent call last):
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 479, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 498, in dispatch
result = self._call_function(*_self.params)
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 314, in _call_function
return checked_call(self.db, *args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 113, in wrapper
return f(dbname, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 311, in checked_call
return self.endpoint(_a, *_kw)
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 688, in call
return self.method(_args, *_kw)
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 363, in response_wrap
response = f(_args, *_kw)
File "/opt/odoo/odoomrp/odoo/addons/web/controllers/main.py", line 1251, in run
[action_id], request.context)
File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 790, in proxy
result = meth(cr, request.uid, _args, *_kw)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/addons/base/ir/ir_actions.py", line 1011, in run
res = func(cr, uid, action, eval_context=eval_context, context=run_context)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/addons/base/ir/ir_actions.py", line 848, in run_action_code_multi
eval(action.code.strip(), eval_context, mode="exec", nocopy=True) # nocopy allows to return 'action'
File "/opt/odoo/odoomrp/odoo/openerp/tools/safe_eval.py", line 312, in safe_eval
return eval(c, globals_dict, locals_dict)
File "", line 1, in
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/addons/base/module/module.py", line 450, in button_immediate_install
return self._button_immediate_function(cr, uid, ids, self.button_install, context=context)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/addons/base/module/module.py", line 497, in _button_immediate_function
registry = openerp.modules.registry.RegistryManager.new(cr.dbname, update_module=True)
File "/opt/odoo/odoomrp/odoo/openerp/modules/registry.py", line 324, in new
openerp.modules.load_modules(registry._db, force_demo, status, update_module)
File "/opt/odoo/odoomrp/odoo/openerp/modules/loading.py", line 357, in load_modules
loaded_modules, update_module)
File "/opt/odoo/odoomrp/odoo/openerp/modules/loading.py", line 263, in load_marked_modules
loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks)
File "/opt/odoo/odoomrp/odoo/openerp/modules/loading.py", line 182, in load_module_graph
_load_data(cr, module_name, idref, mode, kind='data')
File "/opt/odoo/odoomrp/odoo/openerp/modules/loading.py", line 118, in _load_data
tools.convert_file(cr, module_name, filename, idref, mode, noupdate, kind, report)
File "/opt/odoo/odoomrp/odoo/openerp/tools/convert.py", line 892, in convert_file
if ext == '.csv':
File "/opt/odoo/odoomrp/odoo/openerp/tools/convert.py", line 978, in convert_xml_import
_logger.error('The XML file does not fit the required schema !')
File "/opt/odoo/odoomrp/odoo/openerp/tools/convert.py", line 845, in parse
raise Exception("Mismatch xml format: root tag must be openerp.")
File "/opt/odoo/odoomrp/odoo/openerp/tools/convert.py", line 763, in _tag_record
res[f_name] = f_val
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/addons/base/ir/ir_model.py", line 1031, in _update
res_id = model_obj.create(cr, uid, values, context=context)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/addons/base/ir/ir_ui_view.py", line 270, in create
context = {}
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 329, in old_api
result = method(recs, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 3935, in create
record = self.browse(self._create(old_vals))
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 232, in wrapper
return new_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 461, in new_api
result = method(self._model, cr, uid, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 4116, in _create
recs._validate_fields(vals)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 232, in wrapper
return new_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 1286, in _validate_fields
raise ValidationError('\n'.join(errors))
ValueError: "" while evaluating
u"self.button_immediate_install(cr, uid, context.get('active_ids', []), context=context)"

Buenas...
Remito esta tarea que aún estando en mi cabeza parece que no estuviese escrita en las tareas de fabricación.

Continuando con el tema de maestro de operaciones y rutas requerimos:

En el listado de materiales a consumir: un many2one a línea de ruta

Adicionalmente como extensión del módulo by products lo mismo, en el listado de productos adicionales a producir: un many2one a línea de ruta.

En la OF, requerimos el mismo many2one en los siguientes puntos:

• Listado de productos planificados
• Listado de productos a consumir / consumidos
• Listado de productos a producir/producidos

Al crear la orden, se inicializarían las ops desde lista de materiales en la solapa lista de productos planificados.
Al confirmar la orden, cuando se crea el listado de productos a consumir y los de a producir, se inicializa la operación con la que marcase el listado de productos planificados.

Esta tarea la tengo como pendiente también, la añado aquí para que no se nos pase.

Necesitamos una gestión completa de la trazabilidad, es decir:

• Para la trazabilidad hacia adelante, debemos conocer en que productos (acabados, intermedios, reprocesados, ...) ha intervenido una determinada materia prima y llegar hasta el detalle de los movimientos (documentos de venta, devoluciones, ...) de cada uno.
• Para la trazabilidad hacia atrás, debemos conocer que materias primas han intervenido en la fabricación de un determinado producto (materia prima, producto intermedio, reprocesados, ...) y llegar hasta el detalle de los movimientos (documentos de entrada de dichas materias primas).
  Enfoque técnico:
  En el punto de "procesar" una orden de fabricación, al aceptar la pantalla donde se indican lotes de producto y de componentes, crear las líneas correspondientes en una nueva tabla con los siguientes campos:
  Componente
  Nºlote componente
  Producto final
  Nºlote prod final
  Id orden de fabricación
  Necesitamos esta tabla relación (que se creó también para Fagor, creo, algo similar) De momento, el módulo que incluya sólo hacer la tabla e insertar el registro al pulsar el botón "aceptar" del wizard de "fabricar" en una orden de fabricación.

El sistema solo tiene que crear línea en el caso de que el producto final sea trazable y solo para los componentes que sean trazables
El informe de trazabilidad, lo haremos a posteriori, en otro módulo una vez funcione este.

Las vistas que se han montado están correctas.

Modificaciones solicitadas:

En el objeto product.attribute.value se requiere enlace a template_id. Hay un error conceptual en Odoo. Un atributo podría tener un precio extra diferente, dependiendo del template al que aplique.

Añadir campo template_id e incluir en vista tree del menú + one2many en template. El botón llevaría a precios de atributos genéricos que aplican a todos los productos, pero en un producto concreto podría coger otro precio.
De hecho dudo de si deberiamos poner un many2many ya que la misma variante puede tener el mismo precio extra variante para varios templates diferentes. De momento pongamos el many2one que es más sencillo. Ya le daremos una vuelta.

En el objeto product.attribute.line se requiere modificar la vista form, para que muestre todos los datos, incluidas sus opciones. De momento he añadido a mano el campo
<field name="value_ids" en el form que se ve desde menú y tiene mucha mejor pinta.

Hay un bug en el campo <field name="attr_type" de esta vista, ya que no se ve ningún valor en la vista form. Este campo debería ser un related al campo tree del objeto Attribute, no tiene sentido cambiarle el valor en attribute line.

En el form de template, en el one2many product.attribute.line debería existir un botón que permita abrir desde ahí mismo el form, definido en el punto anterior, ya que será necesario establecer los valores "por defecto", "requerido"... etc. De hecho, estos valores deberían aparecer en este mismo tree, en el one2many.

El valor "por defecto" tiene que venir filtrado por los valores definidos en la lista. O sea, no puedo poner un valor por defecto a un atributo, si ese valor no está en la lista de atributos.

Eliminar tipo atributo "dimensión" que ya no aplica

Relacionado con #62

OpenERP Server Error
Traceback (most recent call last):
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/http.py", line 496, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/http.py", line 513, in dispatch
    result = self._call_function(**self.params)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/http.py", line 279, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/service/model.py", line 113, in wrapper
    return f(dbname, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/http.py", line 276, in checked_call
    return self.endpoint(*a, **kw)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/http.py", line 729, in __call__
    return self.method(*args, **kw)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/http.py", line 372, in response_wrap
    response = f(*args, **kw)
  File "/home/avanzosc2/Odoo/odoo-v8/addons/web/controllers/main.py", line 945, in call_button
    action = self._call_kw(model, method, args, {})
  File "/home/avanzosc2/Odoo/odoo-v8/addons/web/controllers/main.py", line 933, in _call_kw
    return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/api.py", line 235, in wrapper
    return old_api(self, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/addons/base/module/module.py", line 450, in button_immediate_install
    return self._button_immediate_function(cr, uid, ids, self.button_install, context=context)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/api.py", line 235, in wrapper
    return old_api(self, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/addons/base/module/module.py", line 497, in _button_immediate_function
    registry = openerp.modules.registry.RegistryManager.new(cr.dbname, update_module=True)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/modules/registry.py", line 324, in new
    openerp.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/modules/loading.py", line 357, in load_modules
    loaded_modules, update_module)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/modules/loading.py", line 263, in load_marked_modules
    loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/modules/loading.py", line 163, in load_module_graph
    init_module_models(cr, package.name, models)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/modules/module.py", line 275, in init_module_models
    result = obj._auto_init(cr, {'module': module_name})
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/api.py", line 235, in wrapper
    return old_api(self, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/models.py", line 2486, in _auto_init
    cr.execute('SELECT min(id) FROM "%s"' % (self._table,))
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/sql_db.py", line 158, in wrapper
    return f(self, *args, **kwargs)
  File "/home/avanzosc2/Odoo/odoo-v8/openerp/sql_db.py", line 234, in execute
    res = self._obj.execute(query, params)
ProgrammingError: column "id" does not exist
LÍNEA 1: SELECT min(id) FROM "sale_order_tax"
                    ^

El codigo es:

class SaleOrderTax(models.Model):
    _name = 'sale.order.tax'

    sale_id = fields.Many2one('sale.order', string='Sale Order',
                              ondelete='cascade')
    tax_id = fields.Many2one('account.tax', string='Tax')
    untaxed_amount = fields.Float(string='Untaxed Amount',
                                  digits_compute=
                                  dp.get_precision('Sale Price'))
    taxation_amount = fields.Float(string='Taxation',
                                   digits_compute=
                                   dp.get_precision('Sale Price'))
    total_amount = fields.Float(string='Total',
                                digits_compute=
                                dp.get_precision('Sale Price'))

@pedrobaeza puedes indicarme si me he colado en algo al pasarlo a la nueva API

Si se da el caso de que no se encuentra ninguna plantilla para un producto/categoría y por tanto no puede generar un test -->NO DAR ESTE AVISO

Error Creación Test!
No test template found for product: Procesador core i5 2.70 GHz, category: Componentes

Simplemente no se crea el test y listo. O si se da el warning que permita continuar el proceso. No puede pararlo. Actualmente al procesar un albarán, si da el warning entras en un bucle y no puedes continuar.

Corrective Actions no es corrective actions, sino que es un número de no conformidad. La secuencia es un número de no conformidad.
Esta no conformidad, incluye varias acciones de solución, con un estado, responsable y demás.
Al abrir la no conformidad (para la que la secuencia se crea bien y todo), el one2many de las acciones correctivas no se visualiza en el form de la no conformidad.

El tree y menú de corrective actions, sí que está, pero en el form, no muestra ni el claim, ni la no conformidad, por lo que no se pueden asignar correctamente. No tiene sentido tener acciones correctivas "sueltas" que no pertenecen a una no conformidad, y por ende a una reclamación.

Premisas funcionales:
Pueden exisitr reclamaciones, para las que no se genere una no conformidad, pero nunca al revés. una no conformidad, siempre se crea desde una reclamación.
Las no conformidades deben estar numeradas en orden, sin huecos y deben constar las acciones correctivas que se llevaron a cabo para solucionar el problema, indicando responsable y fecha en la que se realizó la acción.
No está migrado completo, aunque casi.

1. En proyectos, al añadir un padre de proyecto da este error (aunque el proyecto padre sí que lo crea). El error está relacionado con cuentas analíticas, ya que no permite abrir ninguna en modo formulario.
   File "/opt/odoo/v8/core/openerp/models.py", line 1656, in search
   return self._search(cr, user, args, offset=offset, limit=limit, order=order, context=context, count=count)
   File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
   return old_api(self, _args, *_kwargs)
   File "/opt/odoo/v8/core/openerp/models.py", line 4490, in _search
   offset_str = offset and ' offset %d' % offset or ''
   TypeError: %d format: a number is required, not dict

You should save before the simulation, en todos los casos. Creo que es tema de la secuencia.

Y el mismo warning sale cuando metes una línea de coste manualmente. Esto provoca efecto colateral, ya que no ejecuta onchange del producto y por tanto no se trae ni la descripción, ni los importes de coste y venta a la línea.
En principio, no es para nada urgente ya que en la demo puedo evitar meter datos a mano, pero hay que tenerlo en cuenta si vamos adelante con el proyecto

Al instalar el módulo da este error:
Intenta instalar el módulo 'purchase_pricelist_rules' que depende del módulo 'purchase_discount'.
Este último módulo no está disponible en su sistema.

y en la descripción del módulo pone:
This module allows to apply product_pricelist_rules extended features to purchase order lines and gets the best pricelist rule automatically.

Warning: This module requires product_pricelist_rules that is incompatible with product_visible_discount

Warning: The required module purchase_discount is available at: https://github.com/OCA/purchase-workflow

Los 2 botones de crear presupuesto de compra desde el requisition, tanto el estándar como el que añadimos nosotros dan los 2 siguientes tracebacks

Una cosa que no entiendo es porqué el botón del módulo estándar llama a nuestra función, ya que son ambos totalmente independientes.
Revisar esto.

  File "/opt/odoo/v8/other-addons/purchase_requisition_ext/models/purchase_requisition_ext.py", line 51, in make_purchase_order_avanzosc
    cr, uid, condition, context=context)
  File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/models.py", line 1656, in search
    return self._search(cr, user, args, offset=offset, limit=limit, order=order, context=context, count=count)
  File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/models.py", line 4474, in _search
    query = self._where_calc(cr, user, args, context=context)
  File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/models.py", line 4297, in _where_calc
    e = expression.expression(cr, user, domain, self, context)
  File "/opt/odoo/v8/core/openerp/osv/expression.py", line 646, in __init__
    self.parse(cr, uid, context=context)
  File "/opt/odoo/v8/core/openerp/osv/expression.py", line 812, in parse
    raise ValueError("Invalid field %r in leaf %r" % (left, str(leaf)))
ValueError: Invalid field 'product_id' in leaf "<osv.ExtendedLeaf: ('product_id', '=', 12) on product_supplierinfo (ctx: )>"


-----------------------

    return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/core/addons/purchase_requisition/wizard/purchase_requisition_partner.py", line 45, in create_order
    self.pool.get('purchase.requisition').make_purchase_order(cr, uid, active_ids, data.partner_id.id, context=context)
  File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/other-addons/purchase_requisition_ext/models/purchase_requisition_ext.py", line 163, in make_purchase_order
    location_id = requisition.warehouse_id.lot_input_id.id
AttributeError: 'stock.warehouse' object has no attribute 'lot_input_id'

PR #74

En plantilla de test, en opciones de valores cualitativos, añadir un checkbox
Los valores "buenos" serán marcados y los "malos" se quedarán sin marcar.

Por defecto, al crear el test, en valores cualitativos el check Ok, nok será inicializado a false (actualmente le pone true, cuando aún no se ha evaluado)
Posteriormente, en el propio test, al seleccionar un valor cualitativo, se trae el valor que tenga en el check en la configuración.
El check, basta con ponerlo en la tabla opciones, no es necesario modificar el many2many de prof/opciones. Si una misma opción es válida en un test y no válida en otro test, que creen 2 opciones diferentes, seleccionen el que corresponda en la plantilla y listo. No hace falta cambiar estructura de modelo

Botón fabricar en la workorder --> Casi no se ve. Está como escondido en cabecera, hay que fijarse. Subir arriba a la barra al lado de los de workflow
Aunque en el listado de material haya materiales, el one2many del botón aparece vacío.
Las pantallas siguen sin estar como comentamos de voz, aunque sí se ha unificado la apariencia
Deben ser de la siguiente forma dividido en solapas
Cabecera: Como está ahora.
Solapas:
.- Materiales: One2many a materiales a consumir
.- Productos adicionales: One2many a byproducts( esto SOLO dependiente de byproducts y en módulo aparte)
.- Info extra: Campos fecha (info extra) Todos los datos de portada de la workorder, menos los de cabecera
.- Solapa 4: Uptime
En cabecera, unificar formato de botones y workflow a imagen y apariencia de V8, siguen estando los botones grises "feos".

DUDA: No sé si la actualización de datos en la ficha debería hacerse al confirmar el pedido y no al guardar. Por otro lado, veo peligroso independizar la asignación de cliente de venta del importe de venta ya que podrías facturar antes algo que el pedido has enviado después.
Por mi parte voto porque el precio se ponga al confirmar la venta y ya está. Es un dato informativo temporal y lo veo más consistente de esa forma.

Al confirmar factura de venta o la de compra da este Traceback:

    return self.wkf_expr_eval_expr(activity['action'])
  File "/opt/odoo/server-v8/openerp/workflow/workitem.py", line 291, in wkf_expr_eval_expr
    result = eval(line, env, nocopy=True)
  File "/opt/odoo/server-v8/openerp/tools/safe_eval.py", line 315, in safe_eval
    return eval(c, globals_dict, locals_dict)
  File "", line 1, in <module>
  File "/opt/odoo/addons_OdooMRP/odoomrp-wip/product_last_purchase_sale_info/models/account_invoice.py", line 40, in action_date_assign
    product_obj.write(self.cr, self.uid, [line.product_id.id],
ValueError: "'account.invoice' object has no attribute 'cr'" while evaluating
u'action_date_assign()'

Para @anajuaristi y @pedrobaeza

Existe un modulo llamado sale_order_type que hizo @CsanchezC en el que se crean "tipos de pedidos de venta" y se le añaden los datos:

• Nombre de tipología
• Almacen (requerido)
• Secuencia de entrada
• Diario de facturación
• Diario de facturación rectificativa
• Descripción
  además hace que en el pedido de venta haya que seleccionar un tipo de manera obligatoria.

En el caso del purchase_type hecho en un principio por @alfredoavanzosc lo que se hace es crear "tipos de pedidos de compra" con los campos:

• Nombre de tipo
• Secuencia de pedido de compra (código)
  de manera que al tener que seleccionar un tipo en el pedido de compra lo que hace es aplicarle la secuencia que definimos, y así poder usar una secuencia por cada tipo

Con esto lo que quiero saber es si ambos tienen que ser equivalentes, como ya se ha hecho con otros módulos, o no. Ya que @mikelarre tiene que cambiar el modulo sale_order_type para que tenga un tipo por defecto (con la idea de evitar el olvido de seleccionarlo) y el purchase_type lo tengo como PR #73 sin aprobar.

Desde hace tiempo, en el entorno de odoomrp, no puedo editar la descripción de las tareas, ya que se queda "loading pad" y no vuelve. No pasa en el entorno de gestión de almetac.

Se pierde la operación del proceso en la que se consumen materiales.
Revisar herencia de vistas con el módulo operations extension

Al seleccionar una acción en la solapa follow up
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, _args, *_kwargs)
File "/opt/odoo/odoomrp/avanzosc/crm_claim_corrective/models/crm_claim.py", line 144, in onchange_cause
initial_cause = description['cause'][1]
NameError: global name 'description' is not defined

Buenas...

En el wizard que salta en el botón transfer, me habeis incluido un one2many nuevo que permite mover paquetes de sitio, que está genial... pero... debería ponerse en un sitio aparte, no en este punto.
Es correcto que cuando estoy transfiriendo material, si lo quiero meter en un paquete lo meto. Pero luego, si quiero volver a empaquetar ese paquete, lo haría en principio en otro sitio (A validar)
Entonces, metería una entrada de menú adicional o bien un action en quants que me permita seleccionar varios de ellos y pulsar la acción "mover" a otra ubicación.
El origen, no me hace falta ya que lo marca el quant. El destino puede ser el mismo paquete en otra ubicación u otro paquete en la misma ubicación.
Habría que darle una vuelta de usabilidad. De momento... ¿Podemos sacar este wizard al menú, independizándolo del wizard de consumo? Incluso podría estar el botón en la línea de albarán pero aparte ya que si quiero mover el package recién creado, igualmente tengo que cerrar el wizard y volverlo a lanzar.

Packages To Move
The source package will be moved entirely. If you specify a destination package, the source package will be put in the destination package.
4 results are available, use up and down arrow keys to navigate.

Source package
Source Location
Destination Location
Destination package

Añadir un elemento

Faltaría de hacer lo siguiente:

1. La descripción de la línea de pedido, si no se ha asociado producto, debería asignarse el nombre del templateId + la concatenación de todos los valores de atributos que ha seleccionado el usuario.
   Así, si cojo templateId = Auricular y de valores de atributos cojo color rojo, micro "con micro", la descripción de la línea tendría que ser Auricular rojo con micro
2. Falta botón de duplicar la línea de pedido.De hecho, igual podría ser buena, lanzar desde la línea "el tree" de línea un asistente que muestre la cantidad y la tabla atributo valor copia de la línea desde la que se lanza, ahí mismo el usuario puede cambiar el valor de un atributo y no tendría que pulsar el botón duplicar, luego abrir la línea duplicada y cambiar el atributo en ella. Creo que se gana usabilidad y sería sencillo de montar. Aparte de que cuando haya muchas líneas, el duplicar nos lo llevará al inicio o al final del pedido y habrá que hacer scroll.

Estos se pidieron ya anteriormente pero faltan.

Nuevas solicitudes:

1. El campo type Template/product de la línea sobra. Por usabilidad, un usuario no sabe si está buscando un template o un producto, la operativa debe ser siempre la misma.
   Por defecto, se muestra sólo el campo template. El usuario busca ahí.
   Si el template buscado no tiene listado de atributos, es que es un producto por lo que se asigna product_id y se hace visible el campo.
   Si los tiene, tal cual funciona ahora es correcto.
2. En el onchange del template, aplicar el mismo tratamiento, ya que si se borra el campo template_id debería también borrarse product_id y empezaría de nuevo la búsqueda del template.
3. Estos mismos cambios deberían aplicarse en product_variant_purchase
   De momento, grabo estas...

La tarea no está terminada del todo.
En los tipos de pedido faltan los siguientes campos, que no sé si se habrán incluido en otro módulo. Igual sería lo suyo separarlo.

diario facturacion: many2one a diarios factura
diario rectificativa: many2one a diarios facturas rectificativas.

Por lo tanto, no puedo probar la siguiente funcionalidad:
Albaran incluir campo relacionado tipo de pedido por pedido.
Al generar factura desde albarán, asignar por defecto el diario marcado en tipo de pedido desde el que proviene el albarán.

La funcionalidad que SI se ha hecho en el módulo funciona correctamente por lo que lo doy por validado funcionalmente.

Pedro: Valorar si merece la pena o no hacer esto

Actualmente, se evalúan todos los valores metidos al grabar el test. Propongo que se evalúe cada opción, asignando ok, nok en el onchange del valor de la línea.

Además, sería muy visual si el OK fuese verde por ejemplo y el NOK rojo. Las que aún no se han evaluado (no tienen valor en los campos Qt o Ql, pueden quedarse en negro.

El error de cantidad duplicada sigue ahí.
4. Hay un error en el cálculo del actualizado y este provoca el mismo error en el disponible. Está duplicando el importe. No atino a ver en pantalla qué está sumando de más. ¿qué fórmula está aplicando para calcular el actualizado?

En las plantillas de test, sólo se puede seleccionar un producto y/o una categoría.

Primero, habría que aclarar bien en pantalla (directamente con un texto de párrafo en la vista), diciendo que si selecciona un producto y una categoría, se hará el test para ambas cosas (y si éste no es el comportamiento, debería serlo).

Además, deberían cambiarse los campos a un many2many, para poder decir que un test se puede hacer a más de un producto/categoría. Un escenario típico es realizar un test a una categoría y unos pocos productos de otra categoría.

A fin del control posterior de costes de fabricación, se requiere:

.- Crear una nueva tabla con los campos
Fecha/hora inicio
Fecha/hora fin
Operación
Tiempo

Cuando en una operación se pulsa el botón "iniciar" o "reanudar", se genera una nueva línea donde fecha/hora inicio, es la que se ha pulsado el botón.
Cuando se pulsan los botones parar/finalizar, se actualiza la fecha hora fin y se calcula/actualiza
tiempo = fechahorafin-fechahorainicio

Esto nos va a permitir conocer el tiempo que una operación/máquina ha estado en marcha y por tanto, calcular fácilmente sus costes, realizando las imputaciones en analítica que se vean necesarias.

Prueba:
incluir un rango de muestra genérico
Crear presupuesto compra
Recepcionar todo
Ir a solapa test calidad: No se visualiza ningún test

Si se hace mediante la pantalla de código de barras, se crea test. Pero todos los campos relación quedan vacíos:
Producto, movimiento, categoría.. etc. lo cual luego impide buscar

En la vista form, no se han incluido los 2 campos en grupo por lo que no se ven las etiquetas.
Se lo he añadido yo a pelo desde pantalla

<group>
    <field name="name"/>
    <field name="sequence"/>
</group>

PR #73

Caso:
Utilizando la pantalla de inventario "vacía" para leer con código de barras, la pantalla desaparece al pulsar start.
Los códigos que no se han podido mapear en el sistema no se ven, no se da feedback al usuario. Deberían mostrarse los que sí se pueden mapear en verde y los que no en rojo, por ejemplo y que la solapa no quede invisible ya que da información superválida al cliente, sobre productos mal etiquetados, por ejemplo.
Esto es una mejora no es un bug

Actualmente tenemos un módulo desarrollado para la 6.1 en el que definiendole un archivo csv te crea un inventario según los códigos de producto y cantidad.
Ahora teníamos pensado ampliarlo a archivos xls ademas de añadir un control en las lineas que se habían importado marcando las que se han importando correctamente y las que no.
Tenía pensado añadir un asistente para elegir el archivo y ampliar la vista de inventarios para que salga una nueva solapa al lado del "inventory Details" con el log de las lineas del archivo importadas.
Adicionalmente se puede añadir una 3 columna en el archivo que defina la ubicación del producto si es diferente a la que se define por defecto en el asistente.

En algunos está puesto OdooMRP
En otros OdooMRP Team y en otros OdooMRP team por lo que al agrupar por autor, aparecen 3 autores. Esto es un problema de visibilidad en apps cuando publiquemos.

Igual con los de Avanzosc. Dijimos que la convención de nombre para todos los módulos Avanzosc, sería Avanzosc, S.L. Exactamente así, con puntos y todo. Revisad todos los que tenemos subidos para Odoo y ponerlo bien.

Necesitamos un procedimiento automático que realice la duplicación de un calendario de proyecto, en otro proyecto. Es decir, que duplique todos sus meetings

Propuesta:
Montar una acción en meetings, que me permita seleccionar uno o varios, que al pulsar muestre un wizard con los siguientes campos:
.- Combo de selección proyectos (requerido)
.- Fecha inicio sesiones del proyecto (no requerido)

Al pulsar aceptar realiza las siguientes acciones:
.- De cada meeting guardar: Fecha del primer meeting del proyecto al que pertenecen. (Fecha inicio Proy Origen), Fecha meeting origen
.- Duplicar meeting
.- Asignar al meeting creado el ID de proyecto seleccionado en el combo
.- Asignar como fecha meeting = fecha meeting origen - (Fecha inicio proyecto/el del wizard) - Fecha inicio proy origen) Es decir, si digo que el proyecto se inicia el 10 de septiembre de 2014 en el wizard y tengo que el primer meeting del proyecto al que pertenece fue el 10 de Julio de 2014, entonces sería (10 de septiembre - 10 de Julio) = 2 meses = 60 días, por ejemplo. Pues a cada fecha de meeting nuevo que cree, le sumo esos 60 días. Esto me permite luego, ajustar los días de forma visual en el mes que corresponda, por si cae en sábado y cosas así, pero más o menos me ubica los meetigns nuevos de forma tratable.
Y creo que es todo.

Generate lines del test, que debería crear más líneas de test, no funciona. No inserta líneas.

En el onchange de producto en línea de pedido de compra, traceback de warning o warning log

result = method(recs, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/models.py", line 5723, in onchange
    record._onchange_eval(name, field_onchange[name], result)
  File "/opt/odoo/v8/core/openerp/models.py", line 5657, in _onchange_eval
    method_res = getattr(self._model, method)(*args)
  File "/opt/odoo/v8/core/openerp/api.py", line 237, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/odoomrp-wip/warning_log/models/warning.py", line 161, in onchange_product_id
    state='draft', notes=notes, context=context)
  File "/opt/odoo/v8/core/openerp/api.py", line 237, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/core/addons/warning/warning.py", line 252, in onchange_product_id
    warning['title'] = title and title +' & '+result['warning']['title'] or result['warning']['title']
KeyError: 'title'

Hay un modulo llamado product_expiry_ext que según @anajuaristi no hace lo que debe, pero los requerimientos exactos no se encuentran en la tarea. Por lo que he visto si que hace algunos cálculos, pero como desconozco que color y estado debe de aplicarse según las fechas, no puedo decir si es correcto.

Supongo que @mikelarre tendrá la misma duda. Ya que es el quien tiene ahora asignada la tarea.

Está aprobado por @pedrobaeza 😉

Servidor de la ofi.

OpenERP Server Error

Traceback (most recent call last):
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 496, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 513, in dispatch
    result = self._call_function(**self.params)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 279, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 113, in wrapper
    return f(dbname, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 276, in checked_call
    return self.endpoint(*a, **kw)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 723, in __call__
    return self.method(*args, **kw)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 372, in response_wrap
    response = f(*args, **kw)
  File "/opt/odoo/odoomrp/odoo/addons/web/controllers/main.py", line 952, in exec_workflow
    return request.session.exec_workflow(model, id, signal)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 1026, in exec_workflow
    r = self.proxy('object').exec_workflow(self.db, self.uid, self.password, model, signal, id)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 797, in proxy_method
    result = dispatch_rpc(self.service_name, method, args)
  File "/opt/odoo/odoomrp/odoo/openerp/http.py", line 96, in dispatch_rpc
    result = dispatch(method, params)
  File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 37, in dispatch
    res = fn(db, uid, *params)
  File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 113, in wrapper
    return f(dbname, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 183, in exec_workflow
    return exec_workflow_cr(cr, uid, obj, signal, *args)
  File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 177, in exec_workflow_cr
    return execute_cr(cr, uid, obj, 'signal_workflow', [res_id], signal)[res_id]
  File "/opt/odoo/odoomrp/odoo/openerp/service/model.py", line 159, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 235, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 3483, in signal_workflow
    result[res_id] = workflow.trg_validate(uid, self._name, res_id, signal, cr)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/__init__.py", line 85, in trg_validate
    return WorkflowService.new(cr, uid, res_type, res_id).validate(signal)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/service.py", line 91, in validate
    res2 = wi.validate(signal)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/instance.py", line 75, in validate
    wi.process(signal=signal, force_running=force_running, stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 120, in process
    ok = self._split_test(activity['split_mode'], signal, stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 248, in _split_test
    self._join_test(t[0], t[1], stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 257, in _join_test
    WorkflowItem.create(self.session, self.record, activity, inst_id, stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 95, in create
    workflow_item.process(stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 120, in process
    ok = self._split_test(activity['split_mode'], signal, stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 248, in _split_test
    self._join_test(t[0], t[1], stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 272, in _join_test
    WorkflowItem.create(self.session, self.record, activity, inst_id, stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 95, in create
    workflow_item.process(stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 120, in process
    ok = self._split_test(activity['split_mode'], signal, stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 248, in _split_test
    self._join_test(t[0], t[1], stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 257, in _join_test
    WorkflowItem.create(self.session, self.record, activity, inst_id, stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 95, in create
    workflow_item.process(stack=stack)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 116, in process
    if not self._execute(activity, stack):
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 162, in _execute
    returned_action = self.wkf_expr_execute(activity)
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 313, in wkf_expr_execute
    return self.wkf_expr_eval_expr(activity['action'])
  File "/opt/odoo/odoomrp/odoo/openerp/workflow/workitem.py", line 291, in wkf_expr_eval_expr
    result = eval(line, env, nocopy=True)
  File "/opt/odoo/odoomrp/odoo/openerp/tools/safe_eval.py", line 312, in safe_eval
    return eval(c, globals_dict, locals_dict)
  File "", line 1, in <module>
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 233, in wrapper
    return new_api(self, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 550, in new_api
    result = method(self._model, cr, uid, self.ids, *args, **kwargs)
  File "/opt/odoo/odoomrp/odoo/addons/purchase/purchase.py", line 826, in action_picking_create
    picking_id = self.pool.get('stock.picking').create(cr, uid, picking_vals, context=context)
  File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 235, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/odoomrp/temp_addons/sale_documents_comments/models/stock.py", line 61, in create
    values['sale_comment'] = (partner.picking_comment + '\n' +
ValueError: "unsupported operand type(s) for +: 'bool' and 'str'" while evaluating
u'action_picking_create()'

En demo.odoomrp.com en pedidos de venta hay un botón "recalcular" que se supone recalcula los precios del pedido si a mitad de estarlo haciendo, se cambia la tarifa, actualizando todos los precios en función de dicha tarifa.
Al pulsar el botón da el traceback que copypasteo.

Aparte... no tengo nombre del módulo y no sé si hay PR porque el claim es muy antiguo, de los primeros que se abrió. Apuntar aquí qué módulo es.

Traceback (most recent call last):
  File "/opt/odoo/v8/core/openerp/http.py", line 476, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/opt/odoo/v8/core/openerp/http.py", line 495, in dispatch
    result = self._call_function(**self.params)
  File "/opt/odoo/v8/core/openerp/http.py", line 311, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/service/model.py", line 113, in wrapper
    return f(dbname, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/http.py", line 308, in checked_call
    return self.endpoint(*a, **kw)
  File "/opt/odoo/v8/core/openerp/http.py", line 685, in __call__
    return self.method(*args, **kw)
  File "/opt/odoo/v8/core/openerp/http.py", line 360, in response_wrap
    response = f(*args, **kw)
  File "/opt/odoo/v8/core/addons/web/controllers/main.py", line 945, in call_button
    action = self._call_kw(model, method, args, {})
  File "/opt/odoo/v8/core/addons/web/controllers/main.py", line 933, in _call_kw
    return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)
  File "/opt/odoo/v8/core/openerp/api.py", line 234, in wrapper
    return old_api(self, *args, **kwargs)
  File "/opt/odoo/v8/odoomrp-wip/sale_order_recalculate_prices/models/sale_order.py", line 40, in recalculate_prices
    line.write(res['value'], context=context)
  File "/opt/odoo/v8/core/openerp/api.py", line 232, in wrapper
    return new_api(self, *args, **kwargs)
TypeError: write() got an unexpected keyword argument 'context'

Controla incorrecto la existencia de test
Mirar MO34 en demo.
Hay test en las operaciones 3 y 4 de la ruta
Pero no me permite cerrar la primera operación
En las workorders no se visualizan los test, por lo que parece que tienen enlace a OF pero no a Workorder y la comprobación del cierre la está haciendo por OF en vez de por workorder.

Asignar correcto ID y modificar comprobación.
Gracias!!

Creo este nuevo módulo para no recargar mas el de operaciones extendidas y dejarlo como finalizado.
Añado en este dependencia al operaciones extendida y algunas de las cosas que comento Ana y dejo la Issue por si se le ocurre alguna otra.
De momento:
Operaciones : Asociación many2many con "etapas"
Project.task: many2one a Workorder.

PR #89

Inicialmente en el simulador había una pantalla de "datos" que se hizo para CTA con estos campos que paso a continuación.
Se dijo de "ocultar" la solapa para Iacs pero la volvería a hacer visible para UVP ya que por ejemplo tipo de actividad, línea /sublínea, administración/convocatoria... están exactamente así en sus documentos de requerimientos. Pongo un * al lado de los que NO hay que hacer visibles (básicamente los de aeronaútica que no aplican para nada). De hecho, los 3 de aeronaútica los ocultaría también en proyectos.
Departamento
Project Type
Campaña
Ubicación proyecto

Tipo de actividad
Actividad
Subactividad

Programa de ayudas/Administración
Administración
Convocatoria

*Aeronave y tipo de componente
*Programa aeronaútico
*En modificación presupuestaria

Línea de investigación
Línea proyecto
Sublínea proyecto

Sector de actividad
Sector
Subsector

Resumen

Los botones de estados y demás, se ven en el formato antiguo y abajo. Habría que modificar las vistas para que tengan imagen unificada.
Esto sí lo metería para la demo.

Al seleccionar una decisión
File "/opt/odoo/odoomrp/odoo/openerp/models.py", line 5613, in _onchange_eval
method_res = getattr(self._model, method)(_args)
File "/opt/odoo/odoomrp/odoo/openerp/api.py", line 234, in wrapper
return old_api(self, *args, *_kwargs)
File "/opt/odoo/odoomrp/avanzosc/crm_claim_corrective/models/crm_claim.py", line 88, in onchange_decision
decision_inicial = decision['desc_decis'][1]
TypeError: 'bool' object has no attribute 'getitem'

Buenas...
Hace un tiempo en el entorno de gestión de OdooMRP, se podían asignar los claims a un proyecto y una tarea y nos permitía así categorizarlos. Ahora mismo no veo los 2 campos en claims y se necesitan

Existe requerimiento para añadir producto/cliente en OdooMRP por lo que este módulo creo que debería ser genérico tanto en nombre técnico como en descripción y ser incluido en OdooMRP en vez de en el proyecto de Almetac.