Merge lp:~camptocamp/banking-addons/7.0-bank-statement-reconcile-account_invoice_reference into lp:banking-addons/bank-statement-reconcile-70
Status: | Merged |
---|---|
Approved by: | Yannick Vaucher @ Camptocamp |
Approved revision: | 122 |
Merged at revision: | 153 |
Proposed branch: | lp:~camptocamp/banking-addons/7.0-bank-statement-reconcile-account_invoice_reference |
Merge into: | lp:banking-addons/bank-statement-reconcile-70 |
Diff against target: |
743 lines (+671/-0) 14 files modified
account_invoice_reference/__init__.py (+22/-0) account_invoice_reference/__openerp__.py (+146/-0) account_invoice_reference/account_invoice_view.xml (+49/-0) account_invoice_reference/account_move.py (+100/-0) account_invoice_reference/i18n/account_invoice_reference.pot (+42/-0) account_invoice_reference/i18n/fr.po (+42/-0) account_invoice_reference/test/in_invoice_with_supplier_number.yml (+40/-0) account_invoice_reference/test/in_invoice_without_supplier_number.yml (+39/-0) account_invoice_reference/test/in_refund_with_supplier_number.yml (+40/-0) account_invoice_reference/test/in_refund_without_supplier_number.yml (+39/-0) account_invoice_reference/test/out_invoice_with_origin.yml (+23/-0) account_invoice_reference/test/out_invoice_without_origin.yml (+22/-0) account_invoice_reference/test/out_refund_with_origin.yml (+34/-0) account_invoice_reference/test/out_refund_without_origin.yml (+33/-0) |
To merge this branch: | bzr merge lp:~camptocamp/banking-addons/7.0-bank-statement-reconcile-account_invoice_reference |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Sébastien BEAU - http://www.akretion.com | Approve | ||
Joël Grand-Guillaume @ camptocamp | code review, no tests | Approve | |
Yannick Vaucher @ Camptocamp | code review, no test | Approve | |
Frederic Clementi - Camptocamp | functional | Approve | |
Review via email: mp+212099@code.launchpad.net |
This proposal supersedes a proposal from 2014-01-22.
Description of the change
We observed difficulties for the users to file the references (name, origin, free reference) and above all, to understand which field will be copied in the reference field of the move and move lines. It ends up with move lines with incoherent, inconsistent descriptions and references, giving head-hashes to the accountant trying to figure out which move line refers to which document.
The approach here is to state simple rules with one concern: consistency.
The reference of the move lines must be the number of the document at their very
origin (number of a sales order, of an external document like a supplier
invoice, ...). The goal is for the accountant to be able to trace to the
source document from a ledger).
The description of a line should always be... well, a description. Not a number
or a cryptic reference.
The transaction ids from external systems like payment gateways could have been used in other modules as a reference to reconcile the entries. We strongly advocate for using a new (technical) field for that and not storing it in the existing reference to keep a clear distinctions between human references and technical reference. See also my recent proposal on transaction ids [0].
The rules:
----------
For customers invoices
~~~~~~~
The reference is the origin of the invoice (so it could be a sales order's number or another document having generated the invoice).
When it has no origin, the reference is the invoice's number. In that case, the move's reference will be the same than the move's number, but that's consistent and at the end that's what we want: the ref allowing to find the origin document, here an invoice.
For supplier invoices
~~~~~~~
The reference is the "supplier invoice number".
When this field is empty, the ref is the invoice's number (same remark than for customers invoices).
In the supplier invoices view, when the reference type is "free reference, we hides the reference field and display the name instead, thus it will be copied in the name of the move. We also copy the supplier invoice number in the ref for usability (we think the supplier invoice number should not have existed - same as ref - but now it is there and searches and views are designed around this field so we prefer to deal with it)
Details in the __openerp__.py file.
I first thought that this module would have his place in this project as it is mostly related to how moves are created with reconciliation in heads, but it could be in an invoicing project. Let me know what you think.
Hi,
Thanks for the work and the COMMENTS ! That is very much welcome :)
LGTM