banking-addons-drivers team mailing list archive

[Stefan <stefan@xxxxxxxx>]

On 08/20/2013 03:07 PM, Virgil Dupras wrote:
> Hi everyone,
>
> I'm working on integrating the OpenERP system of a customer with his 
> bank for credit card processing. Each customer has a "credit card" 
> bank account type and payment requests are regularly sent (in batch) 
> to the bank for processing.
>
> There's a whole system (which I still have to implement), where failed 
> payments are retried regularly (possibly with an alternate payment 
> mode) until they pass.

Hi Virgil,

Closest I can think of is the direct debit module. It creates debit 
orders (a specially marked regular payment order) which are uploaded to 
the bank. Feedback comes in through the bank statement. Individual 
debits are allowed to fail both temporarily or fatally. Invoice workflow 
integration is implemented according to the Dutch practice, which I 
understand can be uncommon in other regions: the debit order is 
guaranteed to be disbursed when accepted by the bank, so the invoices 
are then considered to be paid. The company account is credited for 
individual failures afterwards (and invoices are reopened).

> At first, I thought I could reuse code from Banking Addons, but the 
> more I'm looking at it, the more these modules seem to be exclusively 
> for the payment of suppliers and reconciliation of bank statements, 
> not the collection of customer payments.

Thinks you could use: direct debit order tweaks on the standard payment 
order model, payment mode of type 'debit' with a filter on your specific 
payment term, wizard selection based on payment mode (but define your 
own wizard. Wizards for payment/debit order export do not actually share 
code in the Banking Addons). Depending on what the bank statement looks 
like, you might even be able to do a full roundtrip. If on the other 
hand, you do not want the bank statement part of banking addons, look at 
the first attempt to disentangle the payment order part here: 
https://code.launchpad.net/~acsone-openerp/banking-addons/ba-70-payment-export-refactoring. 


If you are looking to push a new payment term upon failure, we did it as 
an experimental customization in 6.1 
(http://bazaar.launchpad.net/~therp-nl/banking-addons/6.1-direct_debit_storno_payment_term/revision/141). 
Combine that with an alternative payment mode that filters on the next 
payment term.

Your biggest gripe will probably be the invoice workflow integration. 
What would it look like in the ideal situation?

Cheers,
Stefan.

--
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

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