Dear Raphael, we need account_payment_extension in a customer project for the reasons i will describe below. We are currently developing a module to extend account_payment_extension to be able to fulfill common german accounting practise with cash discounts. Maybe check if your situation in Brasil is comparable ...
For your information our extension depends on *account_payment_extension*. We needed to certify all modules for this customers project because they wished to have 100% coverage with the conditions of maintenance. Sadly we was forced to initiate the certification for this module, because there was not so much initiative from original editors of great accounting extensions to use free certification of accounting modules until 01st of may as offered on community and partners day. You know about the certification discussion of 3rd party developed modules and (partly) i can understand original developers. You can find our development branch for this module here >>><http://bazaar.launchpad.net/~openbig/bigconsulting/addons/files/head:/account_payment_discount_extension/> *Why do we have to modify account_payment_extension for our customer in germany?* * account _payment doesn't allow to create a payment proposal for customer invoices with payment via bank collection (thats what you described). The menu point "Receivable Payment Orders" in account_payment_extension was exactly what we needed for this. * main reason for modification of account_payment_extension was to be able to have reconcilation wizard available on the proposed payment lines. The plan is to handle the reconcilation of supplier invoices at the time we create a list with all payable invoices. * Wizard for population of invoices to pay list should be able to propose invoices checking due date and cash discount time frame (for example invoice with possibility to deduct payment amount with x percent in x days). The logic of "prefered date" needs a change to benefit from early payment discounts (cash discount). * We create account moves on confirmation -> "creditor against intermediate bank account" * We reconcile invoices on confirmation of payment. * One or two days later we only create one account move line on bank statement (amount of all invoices we send to our bank). * Summarized we handle account move posting and reconcilation not anymore in bank statement. Instead we do this one step before. *Remark:* * Account moves for cash discounts seems to be different from country to country. For germany we need to correct taxes for cash discounts at the end of the process (payment). Other countries create account moves for cash discounts on invoice (which is not legal in germany). Some countries need to correct taxes for cash discounts (at the moment i only know germany), in other countries it is strictly forbidden to correct taxes for cash discounts... As i know we have the possibilty to propose merges in this branch * lp:~openerp/openobject-**addons**/5.0-**certified**-**addons**/* The same situation is for all magentoerpconnect modules, which are also in this branch beneath others. May you check this with Stephane if it is right that these branch is the one which is valid to be 100% compatible with maintenance contracts? To prevent a frozen situation like you described it seems to be really important to propose merges (modifications, bug fixes) to this branch. I hope there will be a benefit in the future for all original developers if they will merge their bug fixes and modifications to this branch. I see a strong demand to subcontract original developers efforts for those 3rd party extensions in "5.0-certified-addons" branch. There should be a *economical motivation* to propose merges and modifications to this branch. I hope Fabien will find a solution for instance to pay x% of earnings from maintenance contracts to benefit "maintenance" efforts of 3rd party developers. It should be possible to find a indicator, for example bug fixes or launchpad points to calculate interest rates for 3rd party developers who help to maintain these certified addons. Another option is to order a extended maintenance for certified addons (for instance 500 EUR for up to 10 users, 1000 EUR for up to 25 users ...) and to share this funds to the developers with contributions to these certified-addons... Maybe there are other ideas to motivate - to certify modules - participation of 3rd party module editors I trust in Fabien and Open ERP to find a solution to motivate 3rd party developers like Raphael, Jordi or others to contribute also for maintenance of "their" modules and to benefit from their efforts. At the end this decision is at Open ERPs side. Best regards Thorsten (openbig.org) 2010/9/1 Raphaël Valyi <[email protected]> > Hello accounting expert, > > For the Brazilian localization of OpenERP, we need to make it easier for > companies to register the B2B bank payment they should emit and receive. > It seems we better reuse the account_payment module (official addons) for > that. > > But we can't exactly reuse it directly because account_payment is only > meant for payables (at least when filtering invoice entries to make payment > order lines). > However, in Brazil at least, when a company expects B2B payments, a popular > method is to register them at the bank, this makes reconciliation easier and > banks > will reclaim your money in time for you, so it's used in both ways. See > http://pt.wikipedia.org/wiki/Bloqueto_de_cobran%C3%A7a > > So we would need a change in account_payment to use it also for > receivables. > > Actually this is what is done in the account_payment_extension from stable > extra addons 5.0 (by Zikzakmedia). A payment order has now a type > payable/receivable + dedicated menu. > > However, we are a bit cautious about making the Brazilian localization > depend upon that account_payment_extension module. > Indeed: > - account_payment_extension seems to do a lot more than we need immediately > at least, it also does it in a sub-optimal way wherever account_payment > lacks extension points. > - how reliable is it? Who uses it here for which countries? > - it has been done for v5, we are assuming a Brazilian localization for > OpenERP v6+ essentially, we can't really afford to port the module to v6 > alone for features we won't use. > - has it has been done for v6, are there features that would be better > refactored for v6 given the changes in v6? > - may be it has been done for v5 because v5 was frozen as it was and > unusable, but the situation with v6 might be different, may be we have a > chance to contrib a minimal refactoring in v6 account_payment before a > freeze? > > > At the end, I'm proposing we move the receivable/payable two ways feature > of account_payment_extension to account_payment in v6, what do you think > about that? > Would like to hear OpenERP S.A. view on that as they are the one > making/blocking merges at the end. > > > Regards, > > > Raphaël Valyi > Founder and ERP Consultant > +55 21 3010 9965 > http://www.akretion.com > > <http://www.akretion.com.br/> > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
