openerp-expert-accounting team mailing list archive

[Ferdinand Gassauer <office@xxxxxxxxxx>]

On Wednesday 15 September 2010 10:48:31 Thorsten Vocks wrote:
> Dear Raphael and accounting experts,
we also need account_payment_extension

for those who want to investigate I attach our module
( may be some issues left)
> 
> 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-accoun
> t-payment-extension-are-you-using-it-refactoring-tt1397685.html#a1452810
> <http://openerp-expert-accounting.71625.n3.nabble.com/account-payment-acco
> unt-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

Best Regards

ChriCar Beteiligungs- und Beratungs- GmbH
http://www.chricar.at/ChriCar/index.html
Dr. Ferdinand Gassauer
Official Tiny Partner

Attachment: account_payment_edifact.zip
Description: Zip archive