openerp-expert-accounting team mailing list archive

[Thorsten Vocks <thorsten.vocks@xxxxxxxxxxxxxxxxxx>]

Dear Raphael and accounting experts,

our result was the same a few month ago. We decided to settle upon
account_payment_extension to be
able to cover customer requirements with some adaptions. Account_voucher is
imho not the common way a
creditor accountant wants to pay a bulk of supplier invoices and also some
customer invoices (bank collection).
Anyway this module seems to be usefull in some other scenarios (cash
payments) and maybe in the future for
experienced payment tasks.

Normally there should be a upgrade to v6 of account_payment_extension
because our customer relies on that module
(certification of this module) and imho this is covered in their
maintenance contract.

Our customers requirement was to be able to assist creation of a bulk
payment list to pay supplier invoices.
This list should be prepared in OpenERP to be able to create a ascii file or
to post via xml export supplier invoices
a company wants to hand over to their bank to trigger the payments money
flow between companies bank and suppliers bank.
This process flow is a recurring process between every and 5-14 days. The
payment list contains mostly more than 30 invoices
to pay. Invoices should change their state to paid at the end of payment
proposal process. Counterpart move in bank statement
to reflect the  bulk payment should be done with only one move line (against
intermediate bank account).

We discovered some other requirements in addition:
* bulk payment also for customer invoices with payment type "bank
collection", which is allowness to pull payment from
customers bank account (this was covered in account_payment_extension).
* optimisation for the payment proposals to avoid paying invoices to late to
deduct cash discounts regarding
the payment term of invoices, for instance 2% in 10 days 30 days net
* avoid to early payment for invoices with or without cash discount (for
example do not pay today if you know you pay next time
in 7 days which is still early enough to deduct cash discount or to stay in
time for payment).
* possibility to add other not due invoices or to delete invoices from
proposed list.
* as easy as possible reconcilation (we decided to do this automatically as
part of the payment list preparation - one step before doing it invoice by
invoice in bank statement).
* automatic creation of proper account moves for cash discounts (with
corresponding tax correction account move).
* possibility to handle complex payment terms (50% pre payment directly, 50%
after 180 days , 3% cash discount in 10 days, 2% in 20 days).

To cover these requirements we needed a few changes in addition to
account_payment_extension:

* refactoring payment terms to split between payment condition (50% / 50%)
and cash discount conditions (2% in 10 days, 1% in 20 days)
* modification of population logic (account_payment_extension) for time
optimised payment proposals
* integrated reconcilation (on make payment)
* intermediate bank journal configuration (to be able to enter only one line
in bank statement one day after sending payment data
to bank). Reconcilation counterpart move is against the default account of
this intermediate journal.
* configuration of "supplier cash discount account" and "customer cash
discount account" (in refactored payment terms)
* scheduler to update (best) "next payment date" which allows financial
optimised payment proposals
* changed account move flow to be able to create account moves for cash
discount with tax correction.
* possibility to change payment and cash discount amounts in difference to
proposed values.

I hope you can check out this branch https://launchpad.net/bigconsulting with
especially the modules
account_invoice_cash_discount and account_payment_discount_extension. Maybe
there  are some
usefull adaptions also for other countries. Please report your ideas for
further improvements.

Best regards
Thorsten Vocks
openbig.org



---------- Forwarded message ----------
From: Raphaël Valyi <rvalyi@xxxxxxxxx>
Date: 2010/9/14
Subject: Re: [Openerp-expert-accounting] account_payment,
account_payment_extension: are you using it, refactoring?
To: Ferdinand Gassauer <office@xxxxxxxxxx>
Cc: Renato Lima <renato.lima@xxxxxxxxxxxxxxx>, Jordi Esteve <
jesteve@xxxxxxxxxxxxxxx>, openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx,
Fabien Pinckaers <fp@xxxxxxxxxxx>


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
>


_______________________________________________
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




-- 
Freundliche Grüsse

Thorsten Vocks

OpenERP Berater
Dipl. Kaufmann (FH)
big-consulting GmbH
Porscheweg 4-6
49661 Cloppenburg

Phone: +49 4471 8409000
Fax: +49 4471 84090009
Mail: thorsten.vocks@xxxxxxxxxxxxxxxxxx
Web: http://www.openbig.org