banking-addons-drivers team mailing list archive

[Bidoul, Stéphane <stephane.bidoul@xxxxxxxxx>]

Hi Stephan,

The refactoring you propose looks quite reasonable to me. It's indeed a
moderately complex task, that we should try to split in manageable pieces
that can be merged progressively with minimal impact and a reasonable
review effort.

I propose to start by splitting account_banking_payment into
account_banking_payment_export that provides the basics for payment export
wizards as well as some improvement to the stock payment order wizards, but
leaving the workflow and reconciliation as is in account_banking_payment.

I attach the dependency graph that will result of this refactoring.

This first step should have a very minimal migration impact and create the
desired partition between payment export and bank statements.

I'll submit a MP for this soon.

-sbi




On Tue, Aug 6, 2013 at 12:18 PM, Stefan Rijnhart <stefan@xxxxxxxx> wrote:

>  On 08/03/2013 01:14 PM, Bidoul, Stéphane wrote:
>
> Thank you Stefan and Joël for the valuable feedback.
>
>  For bank statements, I lend towards bank-statement-reconcile-70, if only
> because it allows to kill the voucher (I've had my share of bad surprises
> with vouchers in the past).
>
>
> Hi Stéphane,
>
> I'd say that that should be a solid choice, as this functionality is
> supposed to be a bit more sophisticated than that included in
> account_banking.
>
>
>  On the other hand, banking-addons-70 has a killer feature: SEPA credit
> transfers (not mentioning several great features around bank accounts).
>
>  So to see if we can use both, I've created a proof-of-concept branch
> with the simple goal of cutting the dependency between
> account_banking_payment and the core account_banking module (which modifies
> bank statements behaviour). Pulling the thread I ended up with the
> following:
>
> - a new module account_banking_payment_statement that contains the
> interactions between payment orders and bank statement imports
> - renamed a few external ids in account_banking_payment that referred to
> account_banking
> - moved the Generated SEPA XML Files menu item to Payment Order menu to
> make it independent of the Banking menu item that is defined in
> account_banking
>
>
>  Before I continue, would you have a quick look at the branch to see if
> this path makes sense and could ultimately be merged in a reasonable time
> frame?
>
>  The branch:
> lp:~acsone-openerp/banking-addons/ba-70-payment-statement-split
>
>
> Great work! Some remarks:
>
> - Would it be OK to rename your account_banking_payment to
> account_payment_export, which would describe the changed functionality more
> precisely? The downside to this is that there used to be a module by that
> name for OpenERP 5, but it has not been maintained any further. We could
> then keep account_banking_payment (or
> account_banking_reconciliation_payment, if we go for the naming scheme
> suggested below) for the integration with the bank statements.
>
> - As you suggested on a proposal thread, the payment order and payment
> line workflow could probably be implemented using trigger transitions,
> triggered by the move line object. I'd like to keep the current ability to
> reopen payment orders.
>
> - Integration with the invoice workflow (paying off invoices with a
> clearing move) should probably be an explicit setting, upon which the
> appropriate settings (account & journal) could become visible and required.
> This setting could then be propagated to each created order, so that people
> can switch while having open orders to be reconciled. Based on the
> observation that consolidated amounts on the bank statement are very
> painful to reconcile manually with each included payment, this could
> initially correspond with the 'Batch booking' attribute that SEPA allows
> you to specify explicitely (even if the Dutch banks do not honour it). The
> SEPA module could then honour this setting instead of asking at export time.
>
> - We would need to come up with the migration scripts needed to rename
> existing data and workflow states and transitions.
>
>
>   Next, I'll need to split account_banking in order to extract the bank
> statement features from the rest. What's the best:
> - create a new module such as account_banking_core
> - or a set of more specific modules such as account_banking_banks
> - or leave the core in account_banking and create
> account_banking_statement?
>
>
> What kind of granularity did you have in mind? I think we can identify the
> following functionalities:
>
> - Having state and period per statement line. Future: to be made
> non-conflicting with account_bank_statement_extensions
>
>   Suggested module name: account_banking
>
> - Import wizard (including metadata structure) without (automatic)
> reconciliation. Future: mabye to be integrated with or dropped in favour of
> C2C's modules
>
>   Suggested module name: account_banking_import
>   Depends on: account_banking
>
> - Link partner wizard (to depend on import/metadata functionality)
>
>   Suggested module name: account_banking_partner
>   Depends on: account_banking_import
>
> - Reconciliation wizard and rough auto-matching logic (to depend on
> import/metadata functionality and partner wizard).
>
>   Suggested module name: account_banking_reconciliation
>   Depends on: account_banking_partner
>
> - IBAN lookup
>
>   Suggested module name: base_iban_lookup
>   Depends on: account_iban_preserve_domestic module
>
> There is also an alternative IBAN validation in account_banking but it is
> not actively maintained and reported to be erratic for some regions. Better
> to drop it in favour of standard validation in base_iban.
>
> Does this sound reasonable? Only thing is that I'm afraid that I cannot
> say how much time we would be able to devote to such a refactoring.
>
>
> Cheers,
> Stefan.
>
>
> --
> Therp - Maatwerk in open ontwikkeling
>
> Stefan Rijnhart - Ontwerp en implementatie
>
> mail: stefan@xxxxxxxx
> tel: +31 (0) 614478606http://therp.nlhttps://twitter.com/therp_stefan
>
>

Attachment: graph.dot.png
Description: PNG image