[6.0][purchase] wrong relational model: purchase m2O invoice; wrong invoiced status and % check

[Raphaël Valyi - http://www.akretion.com]

Hello,

affects v5 and v6:

consider this very common business case: you order several items to your supplier. And just like you could do in OpenERP for sales (eg it's a matter of consistency also), your supplier delivers you the items with partial deliveries and you are invoiced upon those partial deliveries. Meaning that your purchase order is only paid when you paid all those n related invoices.

However, currently in OpenERP, purchase.order has a many2one field to account.invoice!!!
here is the code snippet from purchase/purchase.py:
'invoice_id': fields.many2one('account.invoice', 'Invoice', readonly=True, help="An invoice generated for a purchase order"),

This doesn't cover that case where several invoices are related to the purchase order!

Furthermore, the
_invoiced_rate and _invoiced functions are not implemented properly as they only consider the unique invoice_id (whichone?)
see the following code:

    def _invoiced(self, cursor, user, ids, name, arg, context=None):
        res = {}
        for purchase in self.browse(cursor, user, ids, context=context):
            if purchase.invoice_id.reconciled:
                res[purchase.id] = purchase.invoice_id.reconciled
            else:
                res[purchase.id] = False
        return res

    def _invoiced_rate(self, cursor, user, ids, name, arg, context=None):
        res = {}
        for purchase in self.browse(cursor, user, ids, context=context):
            tot = 0.0
            if purchase.invoice_id and purchase.invoice_id.state not in ('draft','cancel'):
                tot += purchase.invoice_id.amount_untaxed
            if purchase.amount_untaxed:
                res[purchase.id] = tot * 100.0 / purchase.amount_untaxed
            else:
                res[purchase.id] = 0.0
        return res

Note that fortunately, it seems that the purchase order lines and the account invoice lines are properly linked through a many2many relation.

I think we should have also a purchase.order many2many account.invoice relation instead and that we should iterate over the related invoice lines (from the potentially several invoices then) to compute the "invoiced" and "invoice_rate" status instead.

Notice that on Twitter, Joel Grand Guillaume (C2C), Carlos Liebana (Ting.es), ovnicraft (Gnuthink) and NeoPolus (Borja L.S.) just confirmed the bug and proposed solution. I think we need to refactor this urgently instead of dragging it all the v6 cycle once the schema is frozen wrongly...

Hope this helps.

[Ana Juaristi Olalde (ajuaristio)]

Well... I don't understand very well the problem.

This is... here in spain we usually invoice from packing. So we don't create supplier invoice from order but from packing.

If your supplier send you an invoice for each packing, I don't know how ids are linked internally but functionally it works really fine.

This is you confirm order, you obtain the pack.

You receive the first pack, make partial picking.. you could even receive goods corresponding to different purchase orders into a single pack...

At the end of the month, receiving invoice from supplier you filter by date and supplier name and easily you create a correct invoice.

I think relating purchase order itself with one single invoice or several invoices, has no relevance if line itself is good linked. It could be extremly complicated linking to order invoices including other purchase order line invoices and so on... I can't see the real utility for this functionality.

Out of question...
There is only one thing missing here and it is supplier packing reference number. It would be much more easier to make invoice from several packs identifying with supplier number and not OpenERP internal number. I made a little module published on community to solve this little problem.

[Carlos Liebana (carlos-liebana)]

So,Ana, the reason is that a single invoice can have lines from many different purchase orders?

[Ana Juaristi Olalde (ajuaristio)]

Carlos I don't understand the question.

Yes.. it's true, an invoice could contain lines from different purchase orders and purchase order lines could be included in several invoices, so relation truly is m2m but I mean that if line itself is right asigned, I can't see it's so critical linking invoice-order m2m.
Maybe it is, but I don't see the reason.

I don't know if I'm explaining.

[Borja López Soilán (NeoPolus) (borjals)]

Ana, the problem is that the user interface of the purchase order only shows the relationship with one of the invoices.

Of course the user may open an invoice line to navigate to the invoice line, and then to the invoice; or he may just search for invoices with the given purchase order reference.
But either way, it is not exactly intuitive or comfortable when compared to how sale orders are implemented: you can just open the "history" tab and there you have the list of all the related invoices.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Ana, Borja,

an other important issue is that the way the invoiced and % invoiced are
currently computed, as soon as you have several invoices for the same
purchase order, those indicators are wrong and you'll possibly have lot's of
PO totally invoiced and done that will be shown as say 50% invoiced only
because of that bug, so you can't filter them properly...

On Wed, Nov 17, 2010 at 5:42 AM, Borja López Soilán <
<email address hidden>> wrote:

> Ana, the problem is that the user interface of the purchase order only
> shows the relationship with one of the invoices.
>
> Of course the user may open an invoice line to navigate to the invoice
> line, and then to the invoice; or he may just search for invoices with the
> given purchase order reference.
> But either way, it is not exactly intuitive or comfortable when compared to
> how sale orders are implemented: you can just open the "history" tab and
> there you have the list of all the related invoices.
>
> --
> [6.0][purchase] wrong relational model: purchase m2O invoice; wrong
> invoiced status and % check
> https://bugs.launchpad.net/bugs/676169
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> Hello,
>
> affects v5 and v6:
>
> consider this very common business case: you order several items to your
> supplier. And just like you could do in OpenERP for sales (eg it's a matter
> of consistency also), your supplier delivers you the items with partial
> deliveries and you are invoiced upon those partial deliveries. Meaning that
> your purchase order is only paid when you paid all those n related invoices.
>
> However, currently in OpenERP, purchase.order has a many2one field to
> account.invoice!!!
> here is the code snippet from purchase/purchase.py:
> 'invoice_id': fields.many2one('account.invoice', 'Invoice', readonly=True,
> help="An invoice generated for a purchase order"),
>
> This doesn't cover that case where several invoices are related to the
> purchase order!
>
> Furthermore, the
> _invoiced_rate and _invoiced functions are not implemented properly as they
> only consider the unique invoice_id (whichone?)
> see the following code:
>
> def _invoiced(self, cursor, user, ids, name, arg, context=None):
> res = {}
> for purchase in self.browse(cursor, user, ids, context=context):
> if purchase.invoice_id.reconciled:
> res[purchase.id] = purchase.invoice_id.reconciled
> else:
> res[purchase.id] = False
> return res
>
> def _invoiced_rate(self, cursor, user, ids, name, arg, context=None):
> res = {}
> for purchase in self.browse(cursor, user, ids, context=context):
> tot = 0.0
> if purchase.invoice_id and purchase.invoice_id.state not in
> ('draft','cancel'):
> tot += purchase.invoice_id.amount_untaxed
> if purchase.amount_untaxed:
> res[purchase.id] = tot * 100.0 / purchase.amount_untaxed
> else:
> res[purchase.id] = 0.0
> return res
>
> Note that fortunately, it seems that t...

[Olivier Dony (Odoo) (odo-openerp)]

(to be checked by Purchase R&D team)

[Olivier Dony (Odoo) (odo-openerp)]

Seems we could change this for consistency with the model at the sale.order.line level, and for correcting the computation of the function fields. See with QDP for exact specifications.

[Carlos Liebana (carlos-liebana)]

+1 Borja, that's what I meant, Ana.

+1 Olivier. Thanks.

[qdp (OpenERP) (qdp)]

In summary, there are 2 things to do

1) replace the many2one(account.invoice) on the purhcase.order with a fields.function of type m2m(account.invoice). The function has to loop on each purchase order lines to gather all the invoices.

2) correct the invoiced status and % of invoicing done on the purchase order to compute it on the new m2m field instead of just checking the previous one invoice linked.

I confirm also the milestone.

Thanks everyone,

[Rifakat Husen (OpenERP) (rha-openerp)]

Hello,

It has been fixed in lp:~openerp-commiter/openobject-addons/rha-dev-addons2

Revision ID: <email address hidden>
Revision no: 4698

Thanks,
rha

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Thank you guys, this is very welcome!