On 16 April 2012 09:39, Stefan Rijnhart <[email protected]> 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
-- Mailing list: https://launchpad.net/~banking-addons-team Post to : [email protected] Unsubscribe : https://launchpad.net/~banking-addons-team More help : https://help.launchpad.net/ListHelp
