Additional note: account_voucher_extension has been essentially developed by the Spanish localization leaders and I believe this is what they are mostly using in Spain. May be some could comment. However, it's good to know that due to mismatch with some OpenERP SA policies, a large part of those historical leaders, that is NaNTic and Zikzakmedia already told they are going Tryton for the future... But I believe account_voucher_extension is however pretty mature already and here in Brazil we are likely to keep using it until better appears (may be your module, we will see).
Regards. -- Raphaël Valyi Founder and consultant http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> +55 21 2516 2954 www.akretion.com On Wed, Nov 23, 2011 at 12:16 PM, Colin MacMillan < [email protected]> wrote: > Hi Raphael, thanks for the feedback I was not aware of this module > account_payment_extension but will have a look. > > > > Agreed re the extra addons branch, I wonder how we can better managed > community contributions however apps.openerp.com looks to be the > solution. > > > > Making our module an extension of the existing account_voucher will > probably involve a lot of rewriting so I haven’t decided if we can go down > this route yet. > > > > Look forward to your comments once you get some time for testing. > > > > Regards > > Colin > > > > > > *From:* Raphael Valyi [mailto:[email protected]] > *Sent:* 23 November 2011 13:14 > *To:* Colin MacMillan; [email protected] > > *Subject:* Re: [Openerp-community] new account_voucher available now > > > > Hello guys, > > > > We didn't had a chance to test it yet. > > However, I would like to mention that here in Brazil we manage the > payments of all our implementations with the "account_payment_extension" > extra addons module instead of the account_voucher module. > > If I'm correct, account_payment_extension inherits some parts of > account_voucher or at least calls some of its methods. > > We would also like to mention that we > ported account_payment_extension from 6.0 extra addons branch to trunk (eg > 6.1) extra addons branch. > > > > Yes the extra addons branch is un-manageable and unscalable, but IMHO we > still need such a central place for common modules and instead we would > need people (including the important ones) to be more responsible > before pushing any non generic module here, this way we could have that > branch limited to a decent set of very common modules. > > > > It would be interesting to see using your module would as a base would be > better than account_voucher. I have no idea at his stage. > > > > Also, I very much prefer a module tested by specialists where other > experts can have a chance to commit some changes and not only once a year a > best. Be free from any single vendor licensing catch is also appreciable > IMHO. > > If you still have a chance to propose changes in account_voucher for 6.1 > and make your module an extension of it, that would probably be better > though. > > > > Regards and thanks for the work! > > > > 2011/11/23 Frédéric Clementi <[email protected]> > > We already had the opportunity to tell you but this is an excellent job > guys. > > I really like the usability (check boxes, paid amount at the bottom) and > the speed ! At the moment, performance is lacking on today standard voucher. > > I would add that the few test I have done shows correct figures. > > One thing though (I cannot only say that you are great !)... the exchange > rate difference between the real bank rate and the OpenERP rate goes to > write-off... in my view it should go to the currency difference amount. > What do you think? > > > Frédéric CLEMENTI > Business Solutions > Camptocamp SA > Tel : + 41 (0)21 619 1041 > > http://www.camptocamp.com > > > > > <[email protected]> > > > > 2011/11/22 Colin MacMillan <[email protected]> > > Hi Olivier, glad to hear you have tested the module. The inheritance > approach was looked at but we decided against it ... perhaps we will > review it now as this is a good idea. > > Regarding the testing, we tested it with our own scenarios and also got > help from other openerp partners. The module is in 8 different live > implementations all using multi-currency so we are happy with the > accuracy. To be honest I've not yet work out how to do YAML tests and it > is very technical and can I say 'geeky'. Personally I'd rather use a > spreadsheet with figures I know are correct, then test this out on a > system manually. > > We are keeping an eye on the 6.1 version which is much better for > multi-currency but still varies significantly from a usability standpoint. > > Your viewpoints are appreciated. > > Regards > Colin > > > > > > -----Original Message----- > From: Olivier Dony [mailto:[email protected]] > Sent: 22 November 2011 10:10 > To: Colin MacMillan > Cc: [email protected] > Subject: Re: [Openerp-community] new account_voucher available now > > On 11/18/2011 01:15 PM, Colin MacMillan wrote: > > This module has a number of additional features: > > > > - speed - on_change has been replaced with a button for retrieving > > open lines > > > > - ergonomics - the layout and ability to select lines with a tick box > > makes the screen very easy to use > > > > - the new approach is not top-down, but bottom-up in design which is > > more intuitive for the operator. Total appears at the bottom. > > > > - credit and invoice lines appear in different colours on the same > > list which is more logical > > > > - fully functional multi-currency - has already undergone heavy > > testing > > > > - 4 configurable accounts for write-off gain/losses and exchange rate > > gains/losses > > > > - enhanced cancellation process - fixes error in logic that meant > > partial payments would be retrospectively unreconciled automatically > > Great job, your module seems to work nicely and introduces interesting > ideas. > > One question pops immediately: why not building it as an extension of the > original account_voucher module, instead of duplicating the functionality? > > I did not check thoroughly, but it seems you copied enough of the original > account_voucher module to stay compatible with the rest of the system. So > presumably this could also be achieved with an inheriting module, possibly > after refactoring some parts of the core that are currently hard to > inherit, and fixing any remaining bugs. > Your module would then be compatible with the official ones, simply > providing a variation on the workflow and screens of the original > account_voucher. > > I suppose you have tried both approaches, so I would be interested to know > how hard you think it would be to go the inheriting route, imagining your > module as "account_voucher_alternative_layout", if you see what I mean. > > BTW, did you compare your module with the trunk/6.1 version of > account_voucher, or only with 6.0? > > And one last question, if I may: there do not seem to be any YAML > scenarios/test in the source of your module, so what strategy did you use > when you say it "has already undergone heavy testing"? > > Thanks! > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
