| Thread Previous • Date Previous • Date Next • Thread Next |
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).
As for account_direct_debit, the problem is that it depends on account_banking and this module is way too big.
Trying to fit my use case within the existing workflow is probably going to be more complicated than it needs to be, but I still want my code to be re-usable. After all, I have implemented a communication protocol with a local canadian bank, and this protocol might be useful, even for someone who doesn't have the exact same workflow as my customer has.
The root of the problem we have to solve, I think (and I hope that it doesn't just stem from my ignorance of Banking Addons), is that we have different banking worflows that are incompatible with each other. Some use vouchers, some prefer using direct move lines, some want to pay suppliers through wizards, some through cron jobs, some register payments at reconciliation time, some need faster feedback from their bank.
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.
For example, I could implement a system that, for every customer who owes money, takes the first 'res.partner.bank' available to it and then asks "who among my registered bank modules can handle a res.partner.bank of type 'bank' for the bank 'Triodos'?". account_banking_nl_triodos, having correctly registered itself, answers the call, verifies that it can handle it, and processes it.
Then, we could have another module, which works in another way (let's say a wizard within which we select a bunch of invoices from suppliers to pay up), and this one needs to attach a bunch of invoice-related metadata to it, we could have another registry that would ask "who among you can handle the payment of this invoice and attach invoice-related metadata to it?"
And so on, and so on.Then, we would have the individual bank modules, which would only need to implement adapters and register in this fashion:
try:
from banking_worflow1 import registry
registry.register(triodos_banking_worflow1_adapter_func)
except ImportError:
pass
try:
from banking_worflow2 import registry
registry.register(triodos_banking_worflow2_adapter_func)
except ImportError:
pass
This way, we can mix and match banking workflow and parsers/exporters as
we like.
The "parser" class in account_banking already does something similar through metaclass registering, we just need to take it out of account_banking and extend it to support more than parsing.
What I have to implement for my customer is relatively simple, so I think that instead of talking too much, I'll just implement it and show it to you. We'll have better discussion material then.
Regards, ---- Virgil Dupras Consultant en logiciel libre Savoir-faire Linux Inc. 418-525-7354 #151 Le 13-08-20 09:52 AM, Stefan a écrit :
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.
| Thread Previous • Date Previous • Date Next • Thread Next |
