banking-addons-drivers team mailing list archive

[Virgil Dupras <virgil.dupras@xxxxxxxxxxxxxxxxxxxx>]

Hi Stéphane,

Yes, precisely, the situation is more complex for payments and the 
parser mechanism in bank-statement-reconcile-70 is not adequate for this 
complexity. That is why I was proposing a registry mechanism to handle 
this complexity while, at the same time, having loose coupling between 
bank communication logic and banking workflow logic.

I have just uploaded an experimental branch with a concrete example of 
what I mean at 
https://code.launchpad.net/~savoirfairelinux-openerp/banking-addons/loose-coupling

The workflow is in "customer_payment_request" and it handles the logic 
of charging every partner who owe us money, as well as cycling over 
available payment methods for each partner when a payment request fails.

It uses a registry method to loosely couple with my two implemented 
payment methods, direct debit (payment_method_dd_desjardins) and credit 
cards (payment_method_visa_desjardins).

This is all, of course, experimental code that is still under heavy 
development. I've uploaded it for demonstration purposes.

So I was wondering what you guys think about this code, if you think 
it's a correct approach, if it has its place in Banking Addons and if 
yes, how do we integrate it.

Regards,
----
Virgil Dupras
Le 13-08-21 09:58 AM, Bidoul, Stéphane a écrit :
> Hi Virgil,
>
> On Tue, Aug 20, 2013 at 5:45 PM, Virgil Dupras <
> virgil.dupras@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > Hi Stefan,
> >
> > Thanks for your answer. The refactoring looks interesting, but it's still
> > a bit far from my use case, especially since it seems based on wizards (the
> > workflow I have to implement is a cron job that batch-charges all customers
> > who owe money, and a cron job that receives the response file from the
> > bank).
> The goal of this module is to have a hook to plug payment order export
> mechanisms. In principle there is no obligation to have an interactive
> wizard.
>
>
> > [...]
> >
> > Workflows differ, but communication protocols with banks should normally
> > stay pretty similar, so we shouldn't have to re-implement them for each
> > workflow. If we're going to have banking workflows that aren't compatible
> > with each other, I thought we should loose the coupling and implement a
> > registry-based system (instead of direct dependency) so that bank
> > parsing/export code can be re-used by all workflows.
> It is for this reason that we want to refactor banking addons.
>
> - for importing and processing bank statements, the
> bank-statement-reconcile-70 series has a very modular approach which
> cleanly separates the parsing and import of statements from the
> reconciliation phase
>
> - for payments (and direct debit), the situation is more complex, hence the
> effort started to refactor that part to cleanly separate the generation of
> payment files from the rest, then the other gems in banking addons will
> have to be factored out
>
> Cheers,
>
> -sbi
>
> Stéphane Bidoul | @SBidoul <https://twitter.com/SBidoul>
>   Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120