banking-addons-drivers team mailing list archive

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

MP submitted. Looking forward to your feedback.

-sbi


On Fri, Aug 9, 2013 at 7:49 PM, Bidoul, Stéphane
<stephane.bidoul@xxxxxxxxx>wrote:

> 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
>>
>>
>