banking-addons-team team mailing list archive

[James Jesudason <james.jesudason@xxxxxxxxxxxxx>]

On 16 April 2012 09:39, Stefan Rijnhart <stefan@xxxxxxxx> wrote:

> On 03/08/2012 01:59 PM, Stefan Rijnhart wrote:
>
>> On 03/08/2012 01:22 PM, James Jesudason wrote:
>>
>>  The upgrade has focused on the functionality that I'm familiar with and
>>> can test. Since the module handles a lot more scenarios than we use, I
>>> cannot test all of them. So, I think it is better if I could ask others to
>>> start testing this branch and whether we could move to a new phase of the
>>> upgrade.
>>>
>>
>> Thank you for the clear summary. Can you give me a couple of days to do
>> some testing myself?
>>
>
>
> Well, that took me a whole time more than I anticipated. Apologies for
> that.
>
> I uploaded a branch with a number of modifications that I would like to
> include in 6.1-dev. Please have a look.
>
>    https://code.launchpad.net/~**therp-nl/banking-addons/6.1-**
> dev-fixes_from_testing_**iteration_1/+merge/102061<https://code.launchpad.net/~therp-nl/banking-addons/6.1-dev-fixes_from_testing_iteration_1/+merge/102061>
>
> I've taken a quick look at this and the changes look fine. I can't do a
full test right now, but will look at it in more detail as soon as I can.


> Apart from that, I looked at your work on delegating the reconcilation,
> rounding and currency conversion to account.voucher and I really like it.
> Thanks again for bringing this up and working on the implementation.
>
> Great. Hopefully this should allow us to remove a lot of code, making the
module easier to maintain.


> There is still some work needed in this part of the code, because it
> currently does not take match_type into account. The original code
> delegated the creation of the reconciliation to import_transaction_obj.**confirm(),
> which in turn applied various methods for this depending on the match_type.
> I think the new code should aim at a similar strategy, but to create a
> voucher instead of a reconciliation object. I hope to find a little time
> for this in the coming weeks.
>
> I didn't understand how the module was working in this respect. I was
thinking that the extra scenarios would not be needed, but I understand
that my use-case does not involve all the scenarios that you are using.


> One thing that I regret a little is that an voucher in OpenERP, when
> canceled deletes all of its move lines but it also explicitely deletes all
> of its reconciliations (see [1]). When an invoice is matched with multiple
> partial payments and one of the statement lines constituting these payments
> is canceled the other statement lines remain confirmed  and the other
> payments remain in the system but are now not reconciled with the invoice
> anymore. Previously, the banking addons took care to only remove certain
> move lines from reconciliations and then clean up reconciliations with less
> than two move lines on them. I do not consider amending this default
> behaviour in OpenERP to be within the scope of this upgrade effort, however.
>
> Understood


Our finance team has been very positive about the changes this module has
brought to bank statement reconciliation. At some stage, I'd like to
discuss the possibility of getting the module certified. The upgrade from
6.0 to 6.1 has been a lot of work (partly because of the extra
functionality that has been added), so I think it help to get the module
into the core OpenERP application.

I also have some thoughts about changing the matching process so that it is
defined by creating rules in the UI, instead of being hard-coded. Right now
the rules don't work for us, and if I make changes to the rules it may
break something for other users. So a more flexible and configurable
matching system will help more people.

Also, I am finding that the layout of the screen to add bank accounts is
quite poor. It is easy for users to enter bank accounts incorrectly, and
there are a lot of additional things that a user needs to know if the bank
account is to be used for payment generation e.g. UK-to-UK payments need
the bank account names to be a maximum of 18 characters, whereas other
systems allow 35 characters. Also, the validation of the bank account is
dependent on the country, and yet the country field is the last field on
the screen when it would be better if it was the first. It may be better to
have a wizard to ensure bank accounts are created correctly i.e. so that
they can be used for payments.

Thanks

James