c2c-oerpscenario team mailing list archive

[Ana Juaristi Olalde <ajuaristio@xxxxxxxxx>]

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.

-- 
[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 member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.

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 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.