Merge lp://staging/~scigghia/ocb-addons/7.0_prop_supplier_invoice_number into lp://staging/ocb-addons

Proposed by Andrea Cometa
Status: Merged
Approved by: Holger Brunn (Therp)
Approved revision: no longer in the source branch.
Merged at revision: 10163
Proposed branch: lp://staging/~scigghia/ocb-addons/7.0_prop_supplier_invoice_number
Merge into: lp://staging/ocb-addons
Diff against target: 12 lines (+1/-1)
1 file modified
account/account_invoice.py (+1/-1)
To merge this branch: bzr merge lp://staging/~scigghia/ocb-addons/7.0_prop_supplier_invoice_number
Reviewer Review Type Date Requested Status
Holger Brunn (Therp) code review Approve
Stefan Rijnhart (Opener) Approve
giudalo (community) Approve
Carlo - Didotech.com (community) Approve
Andrea Cometa (community) Abstain
Review via email: mp+208934@code.staging.launchpad.net

Description of the change

when paying a supplier invoice, with voucher, may be useful to show supplier invoice number instead of ref for supplier invoice, and invoice_number instead of ref or name for out invoice

I think this could be done in action_move_create in account.py done by this mp

To post a comment you must log in.
Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

It is true that there is a certain redundancy on the invoice form, having both the supplier_invoice_number and reference fields. Then again, they are not necessarily the same. When creating payment orders from the resulting move lines, we definately want the reference to be passed. Payments read the reference from the move line's 'ref' field, so I don't think the supplier_invoice_number is a good choice here and I favour the reference from the invoice.

Apart from the functional aspect, I wonder if this code actually works. The move line's 'ref' field is a related field on the same field on account.move and while the move's 'ref' value is specified explicitely here, I believe it to be overwritten when the move lines are created (the move lines are passed in (0, 0, {}) o2m notation). The move lines' value for 'ref' is determined around l.945 in account.py, depending on the invoice type. If I am not mistaken, this assignment is void anyway for that reason.

review: Disapprove
Revision history for this message
Andrea Cometa (scigghia) wrote :

sorry, but line 945 in account.py show me name_search

however I've tested this code with every type of account.invoice with no problem

I would be happy to improve this functional aspect, as it is useful for the end user that work with many payments with multiple maturities. so showing supplier_invoice_number is useful

Revision history for this message
Carlo - Didotech.com (iw3hxn) wrote :

hello to all, i think in different mode.

On supplier invoice (account.invoice type=out) there are 2 field

supplier_invoice_number
ref

is this redundancy?

on Supplier Invoice i think is correct to use 'supplier_invoice_number' for set the "invoice number that i received".
I look into the code and i not find sense for 'ref' field, i belive that is revival of v5 and v6.x

i propose to set 'ref' as reference of 'supplier_invoice_number' and also on "supplier invoice form view" hide 'ref'

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

@carlos, you can have separate invoice number and payment reference. See for instance the structured payment reference as defined in the SEPA specifications: http://en.wikipedia.org/wiki/Creditor_Reference.

@andrea sorry, that should be around l.945 of account/account_invoice.py. But you are right, it was the other way around. The place where you inject the supplier invoice number overwrites the logic above.

To keep complete compatibility with the way that the payment module uses the references as *payment* references, how about using the supplier invoice number as a fallback in case no reference has been given? Something like:

    'ref': inv.reference or inv.supplier_invoice_number or inv.name,

?

Leaving inv.number out here, because it is a related field on the name of the move that we are creating here in the first place.

Revision history for this message
Andrea Cometa (scigghia) wrote :

+1 for Stefan :)

Revision history for this message
Andrea Cometa (scigghia) wrote :

done

review: Approve
Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

Hi Andrea, great to find a common ground! Note that you cannot approve your own contribution (even if co-developed with the reviewers) so please change that to 'abstain'.

In line with OCB policy, I need to ask you to propose the same code to lp:openobject-addons (preferably trunk branch, I think). Setting to 'needs fixing' for that reason.

review: Needs Fixing
Revision history for this message
Andrea Cometa (scigghia) wrote :

sorry

review: Abstain
Revision history for this message
Carlo - Didotech.com (iw3hxn) wrote :

perfect scigghia++

review: Approve
Revision history for this message
giudalo (g-dalo) wrote :

it's good solution for my never satisfied customers

review: Approve
Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

Hi there,
Thanks for your proposal. As Stefan stated, you need to propose the same code on lp:openobject-addons to be in line with the OCB policy. I set this merge proposal to "Work in progress", please put it back to "Needs Review" and write the link the other propolal once done.

Revision history for this message
Andrea Cometa (scigghia) wrote :

Hi, here i propose a patch for that

https://bugs.launchpad.net/openobject-addons/+bug/1286483

maybe necessary a merge proposal?

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

Thanks for creating the proposal on upstream OpenERP!

review: Approve
Revision history for this message
giudalo (g-dalo) wrote :

disapprovo. nn si lavora a Pasqua.
:-)

Inviato da Samsung Mobile

<div>-------- Messaggio originale --------</div><div>Da: Andrea Cometa <email address hidden> </div><div>Data:20/04/2014 12:17 (GMT+01:00) </div><div>A: <email address hidden> </div><div>Oggetto: [Merge] lp:~scigghia/ocb-addons/7.0_prop_supplier_invoice_number into lp:ocb-addons </div><div>
</div>Andrea Cometa has proposed merging lp:~scigghia/ocb-addons/7.0_prop_supplier_invoice_number into lp:ocb-addons.

Requested reviews:
  Stefan Rijnhart (Therp) (stefan-therp)
  giudalo (g-dalo)
  Carlo - Didotech.com (iw3hxn)
  Andrea Cometa (scigghia)
Related bugs:
  Bug #1286483 in OpenERP Community Backports (Addons): "reference instead supplier invoice number in voucher line"
  https://bugs.launchpad.net/ocb-addons/+bug/1286483

For more details, see:
https://code.launchpad.net/~scigghia/ocb-addons/7.0_prop_supplier_invoice_number/+merge/208934

when paying a supplier invoice, with voucher, may be useful to show supplier invoice number instead of ref for supplier invoice, and invoice_number instead of ref or name for out invoice

I think this could be done in action_move_create in account.py done by this mp
--
https://code.launchpad.net/~scigghia/ocb-addons/7.0_prop_supplier_invoice_number/+merge/208934
You are reviewing the proposed merge of lp:~scigghia/ocb-addons/7.0_prop_supplier_invoice_number into lp:ocb-addons.

Revision history for this message
Holger Brunn (Therp) (hbrunn) :
review: Approve (code review)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.