The new bank.payment.line sequence has the same prefix as the old payment.line,
so this makes that installations coming from the previous version where there were
no bank.payment.line, in an effective way this provokes to restart the numbering
of the references sent to the bank and thus the possibility of duplicating numbers.
The implicit noupdate="0" also does the same effect of restarting the numbering.
[ADD] account_payment_transfer_reconcile_batch
=================================================================
Batch reconciliation for transfer lines created in payment orders
=================================================================
This module allows to process with the connector technology the heavy task of
reconciliation of the receivable/payable journal entries of a payment order
against the created entries in transfer accounts.
This approach provides many advantages, similar to the ones we get
using that connector for e-commerce:
- Asynchronous: the operation is done in background, and users can
continue to work.
- Dedicated workers: the queued jobs are performed by specific workers
(processes). This is good for a long task, since the main workers are
busy handling HTTP requests and can be killed if operations take
too long, for example.
- Multiple transactions: this is an operation that doesn't need to be
atomic, and if a line out of 100,000 fails, it is possible to catch
it, see the error message, and fix the situation. Meanwhile, all
other jobs can proceed.
Inspired on *account_move_batch_validate* module from Camptocamp and ACSONE.
Installation
============
This module requires the connector module, hosted on
`OCA/connector <https://github.com/OCA/connector>`_
Configuration
=============
This will only work for payment modes that have a transfer account set.
Usage
=====
When exporting the payment order, click on *Validate* to generate the transfer
move. One connector job will be created for each payment line for a deferred
conciliation of this line.