ARGOMENTO: Produzioni su ordine

Ciao a tutti,
tempo fa avevo avuto dei problemi con il pianificatore di OE7, nello specifico un problema con le unità di misura che bloccava lo scheduler. Adesso la cosa che succede, e sono gia' tre volte che verifico questo evento, e' che i prodotti da produrre su ordine, che quindi dovrebbero essere messi in produzione dal pianificatore, generando automaticamente l'ordine di produzione vengano trattati in modo anomalo. Infatti gli ordini di produzione non vengono generati automaticamente al successivo avvio del pianificatore dopo la conferma dell'ordine di vendita. A questo punto genero un ordine manuale, produco e successivamente evado l'ordine di consegna, solo a questo punto il pianificatore genera automaticamente l'ordine di produzione per quel determinato prodotto. Vi e' mai capitato qualcosa del genere?

trovi delle eccezioni nell'approvvigionamento?
hai provato a lanciare più volte il task mrp? non sempre il primo ciclo arriva fino alla produzione.

fortunatamente sulla v8 hanno rivisto un po' questa parte.

Anche questa mattina mi e' successa la stessa cosa, ho verificato e come qualche tempo fa, ritrovo nel log due errori che gia' mi erano capitati.

2014-07-28 11:21:30,232 1410 WARNING emervolsrl openerp.osv.orm: No such field(s) in model procurement.order: sale_line_id.
2014-07-28 11:21:30,393 1410 WARNING emervolsrl openerp.osv.orm: No such field(s) in model procurement.order: sale_line_id.
2014-07-28 11:21:30,727 1410 ERROR emervolsrl openerp.tools.safe_eval: Cannot eval u'action_po_assign()'
Traceback (most recent call last):
File "/opt/openerp/lp/openerp/openerp/tools/safe_eval.py", line 285, in safe_eval
return eval(test_expr(expr, _SAFE_OPCODES, mode=mode), globals_dict, locals_dict)
File "", line 1, in <module>
File "/opt/openerp/lp/openerp/openerp/osv/orm.py", line 377, in function_proxy
return attr(self._cr, self._uid, [self._id], *args, **kwargs)
File "/opt/openerp/lp/openerp/openerp/addons/purchase/purchase.py", line 1090, in action_po_assign
res = self.make_po(cr, uid, ids, context=context)
File "/opt/openerp/lp/openerp/openerp/addons/purchase_requisition/purchase_requisition.py", line 295, in make_po
res.update(super(procurement_order, self).make_po(cr, uid, non_requisition, context=context))
File "/opt/openerp/lp/openerp/openerp/addons/purchase/purchase.py", line 1189, in make_po
qty = uom_obj._compute_qty(cr, uid, procurement.product_uom.id, procurement.product_qty, uom_id)
File "/opt/openerp/lp/openerp/openerp/addons/product/product.py", line 168, in _compute_qty
return self._compute_qty_obj(cr, uid, from_unit, qty, to_unit)
File "/opt/openerp/lp/openerp/openerp/addons/product/product.py", line 175, in _compute_qty_obj
raise osv.except_osv(_('Error!'), _('Conversion from Product UoM %s to Default UoM %s is not possible as they both belong to different Category!.') % (from_unit.name,to_unit.name,))
except_osv: (u'Error!', u'Conversione da UoM Prodotto Unit(s) a UoM Default m non possibile siccome appartengono a categorie differenti!')
2014-07-28 11:21:30,729 1410 ERROR emervolsrl openerp.addons.base.ir.ir_cron: Call of self.pool.get('procurement.order').run_scheduler(cr, uid, *(False, True)) failed in Job 6
Traceback (most recent call last):
File "/opt/openerp/lp/openerp/openerp/addons/base/ir/ir_cron.py", line 136, in _callback
method(cr, uid, *args)
File "/opt/openerp/lp/openerp/openerp/addons/procurement/schedulers.py", line 41, in run_scheduler
self._procure_confirm(cr, uid, use_new_cursor=use_new_cursor, context=context)
File "/opt/openerp/lp/openerp/openerp/addons/procurement/schedulers.py", line 83, in _procure_confirm
wf_service.trg_validate(uid, 'procurement.order', proc.id, 'button_check', cr)
File "/opt/openerp/lp/openerp/openerp/workflow/wkf_service.py", line 119, in trg_validate
res2 = instance.validate(cr, id, ident, signal)
File "/opt/openerp/lp/openerp/openerp/workflow/instance.py", line 43, in validate
workitem.process(cr, witem, ident, signal, force_running, stack=stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 60, in process
ok = _split_test(cr, workitem, activity, ident, signal, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 175, in _split_test
_join_test(cr, t[0], t[1], ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 183, in _join_test
create(cr,[activity], inst_id, ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 40, in create
process(cr, res, ident, stack=stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 60, in process
ok = _split_test(cr, workitem, activity, ident, signal, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 175, in _split_test
_join_test(cr, t[0], t[1], ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 183, in _join_test
create(cr,[activity], inst_id, ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 40, in create
process(cr, res, ident, stack=stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 60, in process
ok = _split_test(cr, workitem, activity, ident, signal, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 175, in _split_test
_join_test(cr, t[0], t[1], ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 183, in _join_test
create(cr,[activity], inst_id, ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 40, in create
process(cr, res, ident, stack=stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 52, in process
result = _execute(cr, workitem, activity, ident, stack)
File "/opt/openerp/lp/openerp/openerp/workflow/workitem.py", line 127, in _execute
id_new = wkf_expr.execute(cr, ident, workitem, activity)
File "/opt/openerp/lp/openerp/openerp/workflow/wkf_expr.py", line 67, in execute
return _eval_expr(cr, ident, workitem, activity)
File "/opt/openerp/lp/openerp/openerp/workflow/wkf_expr.py", line 57, in _eval_expr
ret = eval(line, env, nocopy=True)
File "/opt/openerp/lp/openerp/openerp/tools/safe_eval.py", line 285, in safe_eval
return eval(test_expr(expr, _SAFE_OPCODES, mode=mode), globals_dict, locals_dict)
File "", line 1, in <module>
File "/opt/openerp/lp/openerp/openerp/osv/orm.py", line 377, in function_proxy
return attr(self._cr, self._uid, [self._id], *args, **kwargs)
File "/opt/openerp/lp/openerp/openerp/addons/purchase/purchase.py", line 1090, in action_po_assign
res = self.make_po(cr, uid, ids, context=context)
File "/opt/openerp/lp/openerp/openerp/addons/purchase_requisition/purchase_requisition.py", line 295, in make_po
res.update(super(procurement_order, self).make_po(cr, uid, non_requisition, context=context))
File "/opt/openerp/lp/openerp/openerp/addons/purchase/purchase.py", line 1189, in make_po
qty = uom_obj._compute_qty(cr, uid, procurement.product_uom.id, procurement.product_qty, uom_id)
File "/opt/openerp/lp/openerp/openerp/addons/product/product.py", line 168, in _compute_qty
return self._compute_qty_obj(cr, uid, from_unit, qty, to_unit)
File "/opt/openerp/lp/openerp/openerp/addons/product/product.py", line 175, in _compute_qty_obj
raise osv.except_osv(_('Error!'), _('Conversion from Product UoM %s to Default UoM %s is not possible as they both belong to different Category!.') % (from_unit.name,to_unit.name,))
except_osv: (u'Error!', u'Conversione da UoM Prodotto Unit(s) a UoM Default m non possibile siccome appartengono a categorie differenti!')

Poterbbe essere questo il problema che blocca il pianificatore? Ho controllato nel DB, pero' non ho trovato nessun prodotto con categoria di unità di misura differente.

Esiste qualche procedura gia' testata per fare un riallineamento del database e cancellare record orfani e campi chiave non coerenti?

Ho notato che il pianificatore funziona invece regolarmente nella generazione dei preventivi di acquisto. A questo punto non so piu' cosa fare...anche vedendo in debug i prodotti che lo mandano in errore, non ci sono discordanze nelle unita' di misura e categorie unita' di misura.

Nelle impostazioni dell'azienda c'e' l'opzione 'giorni pianificatore', qual e' la logica dei giorni settati? Adesso il parametro e' a 700, il pianificatore gira ogni 15 minuti, si parla di 700 giorni indietro a partire da oggi o il contrario? Cioe' il pianificatore utilizza il parametro giorni per pianificare le richieste fino ad un numero n di giorni impostato indietro rispetto all'esecuzione e processa le richieste?