banking-addons-drivers team mailing list archive

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

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

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

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?

Thanks again!

-sbi

On Tue, Jul 30, 2013 at 10:23 AM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> wrote:

> Hi Stefan,
>
>
> I try to give you what I know about here:
>
>
> On Sun, Jul 28, 2013 at 3:02 PM, Bidoul, Stéphane <
> stephane.bidoul@xxxxxxxxx> wrote:
>
>> Hi list,
>>
>> I'm getting more and more interested in the banking addons and, more
>> important, we will hopefully soon have customers with similar requirements
>> and therefore the possibility to contribute some features or enhancements.
>>
>
> => Good :)
>
>
>>  So my first question is: is there any particular reason that payment
>> and bank statements are tied together? Would it be a good idea to somehow
>> split  the account_banking module in two parts: one for payment and one for
>> bank statements?
>>
>
> => That was part of the reason we made a new version of banking addons,
> trying to split up as much as possible the features into various modules.
> We receive some helps last month from Savoir Faire Linux that contributes
> to make it even more modular.
>
>
>> My second question is related to bank statements. We are considering
>> implementing Belgium CODA bank statement support in banking-addons to
>> benefit from advanced reconciliation features for e-commerce (at this
>> stage, both banking-addons-70 and bank-statement-reconcile-70 are
>> apparently incompatible with the official l10n_be_coda).
>>
>> To implement such a CODA parser, I have difficulties to chose between the
>> banking-addons approach and the bank-statement-reconcile way. I understand
>> both approaches are incompatible? Is that correct? I also understand there
>> are also longer terms goals of merging them. Are there already any concrete
>> plan in this regard?
>>
>
> => I think a parser can be easily implemented in both project. We both
> have an abstract class that help deal with files and importations
> => Currently they are not compatible
> => No plan to merge them yet, but this is the goal we follow by putting
> them here both
>
>
>>
>> Finally, I saw in OpenDays slides that OpenERP SA has plans to improve
>> banking support in v8. Is there any relationship with the banking-addons
>> efforts, and does one influence the other?
>>
>
> => I discussed with Quentin (the guy that will implement that) and give
> him our branches to see if they may reuse something. Well, with OpenERP you
> never know.. But I tried to at least convince him to take our importation
> base module (we're in the process of breaking the dependencies) in the
> core. That way, OpenERP win time as it is done, and we may hopefully have a
> set of module to extend the base.
>
>
>>
>> Overall, I'm trying to better understand the landscape and go in the
>> right direction when we (hopefully soon) have the opportunity to contribute.
>>
>
> => Both project
>  * Use profile on importation of bank statement that configure in a way
> the entries generated at the bank statement confirmation.
>  * Handle commission by line and/or by importation (global line)
>
> => Well the biggest differences I see here are:
>  * The way we handle the reconciliation :
>        - banking-addons uses voucher per lines, and this process is
> strongly linked to invoices workflows. Can be a performance killer on big
> volume
>        - bank-statement-reconcile doesn't use voucher and work on moves
> only. Rules by profile are setup to reconcile most things automatically
> (99% once well configured). You can run a reconciliation job by profile and
> see what has been done by the system easily to eventually correct it.
> Handle thousands of lines at once.
>  * The reconciliation process:
>       - banking-addons will make the reconciliation while being in the
> bank statement
>       - bank-statement-reconcile will separate 3 phases: 1. the
> importation (only import value, without any completion or computation). 2.
> The completion (that uses rules by profile to complete all possible infos
> for each line like: figure out the partner from a number, try to get the
> proper counter-part account,...) 3. The reconciliation (also based on rules
> by profile to reconcile move) => note that this part handle properly the
> multi-payment terms problematics.
>  * The payment part:
>        - The banking-addons handle (and is linked to) the payment part
>        - The bank-statement-reconcile doesn't. Means you can rely on the
> standard one, use the other community one ore your own (may be one included
> in a localization, as it is for Switzerland).
>
> Correct me if I miss something.
>
> Hope this helps,
>
> Regards,
>
> Joël
>
> --
>
>
>  *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Joël Grand-Guillaume*
> Division Manager
> Business Solutions
>
> +41 21 619 10 28
> www.camptocamp.com
>
>
>