banking-addons-drivers team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Hi Luc,


Thanks for the feedback, In-line:


On Mon, Oct 13, 2014 at 11:24 AM, Luc De Meyer <luc.demeyer@xxxxxxxxx>
wrote:

> My 2 cents:
>
> >>> 1. when requesting the payment of the invoice to the electronic
> payment company, create a move to a transfer account and reconcile the
> invoice (N)
>
> Agree. The ‘transaction identifier’ of the payment should be stored in the
> account.move.line of the transfer account to allow reconciliation later on
> with the details in the statement from your bank or the payment card
> company.
>

=> We do it this way as well in v7. The field name is transaction_ref (or
ID I don't remember). It's already done in banking-addons.


>
>
> >>> 2. when receiving the bank statement for eg a batch of VISA payments,
> create a move from the bank account to the transfer account (1); we
> typically have one per day per card type
>

>
> Not always true. Several banks give all details in their electronic bank
> statements, hence no need for step 3 and 4.
>
> Because of this, it is in my opinion easier to use the bank statement as
> an object to load not only bank statements but also for importing
> statements from e.g. VISA, Atos Worldline since the same logic is required.
>

=> This is what we've done, but it creates lots of move in the accouting.
Moreover, even if several banks give details in their electronic bank
statement, you have more frequently the info from the financial institute
first. For example, Atos will confirm you the payment before you receive it
in your bank. This info is useful to starts deliver the orders. If we
import the payment confirmation in a new object, we'll have the info at the
proper time, not waiting on banks confirmation.


>
>
> >>> 3 & 4
>
>
>
> Can be skipped if sufficient details are available in the electronic bank
> statement, if not an import of the Card Company statements Is indeed needed.
>

=> See my point above


> Concerning the matching/reconciliation of the statement lines with the
> transfer account move lines created in step 1, there are several techniques
> that we have used in the past.
>
> Technique 1 reconcile during import via standard ORM methods (slow hence
> can’t be used for high volume).
>

=> Too slow indeed


> Technique 2 is to bypass standard ORM methods so that reconciliation
> during statement import becomes acceptable.
>

=> Yes, but then you break the system as you skip the ORM. If another
module used one of the method called by the ORM, and you use SQL... You'll
have trouble. I can't leave with this on my side.


> Technique 3 is an ir_cron job running ‘standard’ (and hence unperformant)
> ORM method to created reconciled accounting entries on the transfer account.
>

=> We used to do that in extreme cases. It works, but I think we can do
better.

So in the end, I keep trusting the "new" idea I suggested using a new
object Batch Line to link the payment confirmation, the invoice, and the
amount received in the bank. This way, you'll have no more perf trouble, no
more thousands of entries in the accounting.

Bet regards,

Joël



>
>
> Regards,
>
> Luc
>
>
>
>
>
> www.noviat.com
>
> Rusatiralaan 1, 1083 Brussel
>
> +32 2 808 86 38
>
>
>
> [image: cid:image002.jpg@01CE271A.FF53FB90]
>
>
>
> *From:* Banking-addons-drivers [mailto:
> banking-addons-drivers-bounces+luc.demeyer=noviat.be@xxxxxxxxxxxxxxxxxxx] *On
> Behalf Of *Bidoul, Stéphane
> *Sent:* maandag 13 oktober 2014 10:48
> *To:* banking-addons-drivers@xxxxxxxxxxxxxxxxxxx; Joël Grand-Guillaume
> *Subject:* [Banking-addons-drivers] eCommerce reconciliation [Was:
> Banking addons guidelines for 8.0 - a proposal]
>
>
>
> Hi Joël,
>
>
>
> In our experience, the characteristic of eCommerce (or electronic)
> payments is that we typically have one line on the bank statement for many
> customer payments.
>
>
>
> In this case, the number of lines on the bank statement itself remains
> reasonable, but there is high volume many2one reconciliation to be done
> with the help of an additional file relating bank statement lines and card
> payments.
>
>
>
> We have done it this way (I think it's similar to what you suggest):
>
>    1. when requesting the payment of the invoice to the electronic
>    payment company, create a move to a transfer account and reconcile the
>    invoice (N)
>    2. when receiving the bank statement for eg a batch of VISA payments,
>    create a move from the bank account to the transfer account (1); we
>    typically have one per day per card type
>    3. when receiving the payment details from the electronic payment
>    company, load these references in a separate table; this table typically
>    contains references between the communication in (1) and the order
>    references in (N), plus the fees
>    4. run a reconciliation job that matches moves lines on the transfer
>    account with the help of the table from 3.; this job also creates the moves
>    for the fees
>
> 1. is reminiscent of account_banking_payment_transfer (not sure how it is
> done with the electronic payment interface of 8.0, I'll need to look it up).
>
>
> 2. is a bank statement operation button in 8.0 and/or a statement
> completion rule.
>
>
>
> 3. and 4. could be a useful generic module in bank-statement-reconcile.
>
>
>
> -sbi
>



-- 


*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Joël Grand-Guillaume*
Division Manager
Business Solutions

+41 21 619 10 28
www.camptocamp.com