openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Guys,

my analysis so far is that account_voucher doesn't close the gap for
account_payment: we can't use account_voucher instead of account_payment for
electronic batch payment processing unless account_voucher is heavily
refactored.
Do you share that analysis? For us it's important to know on which module we
should base the Brazilian "boleto" payment system, so unless the OpenERP
says they want account_voucher to fix the following issues/accept community
merges:
http://openerp-expert-accounting.71625.n3.nabble.com/account-payment-account-payment-extension-are-you-using-it-refactoring-tt1397685.html#a1452810
<http://openerp-expert-accounting.71625.n3.nabble.com/account-payment-account-payment-extension-are-you-using-it-refactoring-tt1397685.html#a1452810>Then
we go for account_payment.

Then, as I said, for us it's risky/costly to rely on account_payment
extension or even sale_payment because we don't need all of their feature
and have some fear to assum porting them to v6 alone.
So instead, what we will do is:

- take everything that is good for us from account_payment_extension and
sale_payment and copy/paste it/migrate it to v6 in the l10n_br_boleto module
(to be built).
That way, eventually if account_payment_extension* is properly ported to
V6/refactored, then we could easily rely on them.
- propose everything that make sense to merge into the official
account_payment module (like ability to works both for sale and purchase,
extension points).
If OpenERP S.A. doesn't merge it, then we will let it in l10n_br_boleto.
Then I think it's the interest of all account_payment users here to weight
behind our merge proposals to have a cleaner and more generic
account_payment module for everyone.

As I said, for us the deadline is around the end of September max.
Finally, it's still unclear, but we think we will do the final export of the
XML payments using TerminatOOOR and our new Kettle OpenERP module (advantage
is that it's straightforward, even for a trainee to change the export format
to adapt it to a new bank API):
https://code.launchpad.net/~akretion-team/+junk/kettle_connector

Thoughts?


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>




On Tue, Sep 14, 2010 at 6:25 AM, Ferdinand Gassauer <office@xxxxxxxxxx>wrote:

> On Monday 13 September 2010 19:26:45 Davide Corio wrote:
> > Il giorno lun, 13/09/2010 alle 19.07 +0200, "Borja López Soilán
> >
> > (Pexego)" ha scritto:
> > > On Spain we usually send batch collections to the bank (yeah,
> > > collections, not payments; so account_payment_extension is needed):
> > > you just tell your bank "collect this invoices (vat number, reference
> > > and amount) from these bank accounts into my bank account", everything
> > > else is managed by the bank (they even might give you the money in
> > > advance (kind of a credit).
> > > It's easy, it's lazy, so it is one of the most used payment methods
> > > here.
> >
> > Same situation here in italy
>
> I just want to announce that  our EDIFACT / PAYMUL  is finished and will be
> release soon.
> i'ts propably the place to add the processing of collections.
>
>
> Best Regards
>
> ChriCar Beteiligungs- und Beratungs- GmbH
> http://www.chricar.at/ChriCar/index.html
> Dr. Ferdinand Gassauer
> Official Tiny Partner
>
> _______________________________________________
> 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
>