banking-addons-drivers team mailing list archive

[Stefan <stefan@xxxxxxxx>]

On 01/23/2014 11:34 AM, Alexis de Lattre wrote:
> If you try to install modules from both branches, you will get 
> conflicting views :
> - In account_banking/account_banking_view.xml line 181, the field 
> "period_id" is removed from the tree view of account.bank.statement.
> - In 
> bank-statement-reconcile-70/account_statement_ext/statement_view.xml 
> line 87, the field "period_id" is also removed from the tree view of 
> account.bank.statement.
>
> There may be other conflicts, I don't know. Maybe it's just this one 
> and it can be solved very easily.

Hi Alexis,

as you know, the two series in the project are independent projects 
which have been grouped by subject in the same Launchpad project. We on 
the account_banking side are very interested in making the 
account_banking series more lean and compatible with other modules such 
as the bank_statement modules. However, we are suffering from the 
handicap of a head start, because the account_banking series (with all 
its flaws) basically seems to fulfil the current requirements of our 
customers. So we are without funding and customer incentive, but with a 
very large debt to the community (cq. you and Stéphane Bidoul, as both 
of you contributed heavily in the last year).

Now, every year, the need for the modules to be migrated to the next 
version of OpenERP provides part of the funding for the heavy 
refactorings and cleaning that I try to do alongside the migration. In 
the migration to version 7.0 for instance, I split up the payment 
functionality in a separate module, which allowed Stéphane to create a 
base payment module independent of the account_banking base module with 
its crude matching mechanism and elaborate manual reconciliation 
interface. So I should hope to achieve the compatibility by the time of 
OpenERP 8.0 (with the option of backporting to 7.0).

One annoyance is account_banking's custom IBAN formatting and validation 
logic. I'm already extracting the deprecated lookup for Dutch account 
numbers into a separate module and will have a look at this IBAN 
mangling in the process. Next step in this bottom up approach would be 
to split off the import part, and the matching and reconciliation part. 
But if just providing basic compatibility in terms of side-by-side 
installation could provide a short-track to at least being able to use 
other reconciliation methods while have account_banking's additional 
functionality sit around unused but harmless, that might be a better 
approach. It would also ease the transition for existing account_banking 
installations. Only I don't have a clear enough view of the 
bank_statement modules to be sure about how easy it can be achieved.

So I have a couple of questions about requirements and the 
bank_statement_reconcile framework.

First question: Stéphane and me already discussed on this list that the 
custom reconciliation logic for payment orders in 
account_banking_payment could probably be replaced by triggers in the 
move line workflow. This would allow the workflow integration between 
payables, payment orders and bank transactions to function transparently 
when other reconciliation methods are used. Is anything like this 
already in place or planned in the bank_statement_reconcile framework, 
or is this provided by another module as far as you know?

As your latest work concerns direct debits, we need to think about the 
following: how can we process direct debit rejections and refunds 
properly? In account_banking_payment, when a debit order has been fully 
processed, the receivable move line has been reconciled, and processing 
a post-hoc rejection or a refund is established by unreconciling this 
move line (and reconciling the refund with the original debit transfer) 
and in case of a related invoice, triggering the invoice workflow by 
either reopening the invoice in case of a temporary failure, or putting 
the invoice in a custom state 'debit denied'.

About this, I would first like to know if this is a good practice as far 
as you are concerned, or if you had other ideas about this.

Then, if you think that unreconciling a move line upon debit 
rejection/refund is acceptable, the next question would be if the 
bank_statement_reconcile framework allows to retrieve a reconciled move 
line in order to unreconcile it.

It would be great if you and the contributors to the 
bank_statement_reconcile framework could comment on this. As for the 
code sprint, I think it is a good idea but unfortunately I'm won't be at 
FOSDEM so we'll have to look out for another opportunity.

Cheers,
Stefan

--
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

mail: stefan@xxxxxxxx
tel: +31 (0) 614478606
web: http://therp.nl