banking-addons-drivers team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

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 bemerged 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) 614478606
http://therp.nl
https://twitter.com/therp_stefan