openerp-expert-accounting team mailing list archive

[Thorsten Vocks <thorsten.vocks@xxxxxxxxxxxxxxxxxx>]

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 <rvalyi@xxxxxxxxx>

> 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     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>
>