lp:~therp-nl/banking-addons/6.0-interactive-matching-and-debit-orders

In collaboration with Smile Benelux, Therp BV presents two major features to the banking-addons:

- A new interactive wizard is added to bank statement lines. The wizard allows handling of possible duplicate imports, selection between multiple candidates, indicates residual amount and allows configuring of write-off, manual matching of any open invoice or move line in the system. See here for a demonstration video: http://www.youtube.com/watch?v=qJ5YYBJOeHM

- Full support of direct debit orders. This includes creating payment orders of type 'Direct debit' through a new dedicated menu item and selecting customer invoices through the wizard. The module follows Dutch style direct debit reconciliation: the full amount of the order is reconciled with a payment on a transfer account, which pays the invoices. Canceled debits (storno's) can be processed manually through the invoice workflow or through the import of bank statements. A canceled debit re-reconciles the move on the transfer account with the bank account's credit transaction, leaving the invoice unpaid and changing the invoice's state through the workflow. A distinction between a fatal error and a temporary one is possible. You may need to allow for canceling entries on certain journals to successfully perform all steps in the debit order and storno invoices workflows.

Additionally, this branch adds support for the Dutch ING bank statements (csv format) and includes an optional module that preselects the candidates on a payment order in the 'Select invoices' wizard, to avoid an extra step in the process.

Architectural changes
==================
- State is added to bank statement lines. Move lines are only created when the bank statement line is confirmed. Bank statement lines support canceling for most reconciliation types. When a statement is confirmed, all lines in draft state will be confirmed as a result. Lines on a confirmed statement can not be canceled, but you can cancel the statement itself in order to cancel any of the statement lines. Additional control over which statement lines may be canceled can be enforced by enabling the canceling of entries only on certain journals. Refer to the module 'account_cancel' for that. A new menu item is added for a list view of statement lines.

- For underspecified bank statement file formats without a unique transaction identifier, the interactive wizard allows for a more subtle dealing duplicate imports than just checking for existing statements with the same (again underspecified) statement identifier. Parsers *can* therefore opt to create a unique statement identifier for every imported statement using models.parser.get_unique_statement_id().

- Splitting up transactions in the matching process is disabled. Aggregate payments can be matched with a single move line only. The residual amount can be reconciled manually.

- Caching of matched move lines is disabled. The interactive wizard allows the user to select from multiple candidates instead.

- Invoices to be selected for either payment or debit orders can be prefiltered on payment term, to be configured on the payment mode. A new payment term for direct debit payments is added to the system.

Upgrade and installation prerequisites
==============================
Please confirm all existing bank account statements in the system before installing this version of the modules. Existing bank statement lines cannot be canceled.

The support for direct debit orders is optional, and can be installed through the module 'account_direct_debit'.

API changes
==========
models.parser.parse() now has an additional cursor argument to check for existing statement identifiers.
payment mode types now have a payment order type 'payment' or 'debit', to allow filtering on selectable payment modes.

Further improvements
==================
- Allow for splitting transactions through the interactive wizard
- When a statement line is confirmed, deal with other statement lines in which the reconciled move line is a candidate as well.
- The current implementation, an orm'ified copy of the original transaction python object tagging along with the statement line is awkward, but meant to be refractored into the statement line itself using the new serialized fields functionality of OpenERP 6.1.