c2c-oerpscenario team mailing list archive

[Raphaël Valyi - http://www.akretion.com <676169@xxxxxxxxxxxxxxxxxx>]

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 <
borjalopezsoilan@xxxxxxxxx> 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 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.
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-addons/+bug/676169/+subscribe
>

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