[IMP] account_statement_base_import: to have profile data stored on a variable across parsers methods, in order to be used to customize, for example, parsing with a parameter introduced on profiles. Dependent modules have been changed accordingly.
Add a test to expose the bug.
To reproduce: create a statement with two lines, confirm one, and then confirm
the whole statement. The first line has two associated moves.
2014-06-13 12:04:16 +02:00
Launchpad Translations on behalf of banking-addons-team
Without this this method will fail on trunk and am surprised if it worked on 7.0, however the change is backward compatible with 7.0 and more efficient and less code.
* The _insert_lines and _update_line method in *_base_completion/statement.py calls the symbol_f method to prorperly initiate the default value (e.g. integer default null value should be Null not False).
* The mechanism that allow to have a null account_id in bank statement line has been move in *_base_completion, instead of *_base_import.
Remove default value to False for account_id since it breaks existing code. It's the responsability of the parser to fill a blank/None account_id in the statement_line values if the default one provided by account_statement_ext does not apply to the expected behavior
==============================================
This proposal aims to improve the modules using transaction ids, I will start
by summarizing what are they used for, then what are the existing problems and
what changes I propose.
Transaction IDs?
----------------
The transaction IDs are a technical reference for a move line. They are to
differentiate from the usual reference that are a reference for humans firstly
(more about that here [0]). Usually, the transaction IDs are defined by
external systems such as payment gateways and are a way to streamline the
reconciliations between the invoices, bank statements...
Changes
-------
1) account_move_line.transaction_ref is defined in 'account_advanced_reconcile_transaction_ref' which adds a reconciliation method with transaction id.
It makes much sense to add the field in 'base_transaction_id' so we can use the field in other modules such as the bank statement completion modules. It is a pity that the field on the invoice and the sale order is 'transaction_id' and in move lines 'transaction_ref' but I prefer to keep the backward-compatibility.
So I moved these things from 'account_advanced_reconcile_transaction_ref' to 'base_transaction_id'
2) In account_advanced_reconcile_transaction_ref there is an inherit of the bank statement that copies the line's ref in the move line's transaction_id. I think this is a mismatch between the ref and the transaction_id that we have to avoid. In fact, only the transaction id of the statement lines should be copied if any, or left empty if the statement line has no transaction id.
3) A consequence of the change 2) is that the automatic reconcile from transaction ref will no longer work for those not using the transaction ids in the bank statement but only the ref. So I added a new reconciliation rule that matches 'ref' vs 'transaction id'. The only drawback is that they will need to change their configuration, but at least the rules will be clear on their intentions.
4) completion rules: 'base_transaction_id' adds a transaction_id on sales order and invoices. There is actually a completion rule that searches the bank statement information from a matching invoice with the same transaction_id. I added the same rule that searches for an invoice with the same transaction id. This is the logical continuation and a good complement when an invoice / refund was not generated by a sales order and we still need to autocomplete the bank statement.
[0] https://code.launchpad.net/~camptocamp/banking-addons/7.0-bank-statement-reconcile-account_invoice_reference/+merge/202689
[IMP] Add the number of lines in completion log to let the user know if some hasn't been auto-completed (e.g. 332/335 line compelted)
[IMP] Add a group by bank statement in journal items search view to ease the reconciliation
