openerp-expert-accounting team mailing list archive

[Thorsten Vocks <thorsten.vocks@xxxxxxxxxxxxxxxxxx>]

Dear ferdinand and other experts.

For analytical account moves the field 'analytic distribution' is available
on a bank statement line by installing the modules account_analytic_default
and account_analytic_plans. Either it is more complicated than to add simply
analytic account in a one and only field on a bank statement line this could
make sense to use analytic distribution for the payment line. Then we will
be able to use same or similar structured allocation model for payment as
for the invoice the payment belongs to. If this suggestion would be right,
wouldn't it be a good idea to fill analytic_distribution field automatically
(same logic as on invoice), which is not the case at the moment?

Belonging the tax field. You are right. This functionality is really
important! Not enough, it should create automatically the corresponding tax
moves, as you would do by entering a line (for example general expense line
with a default tax on this account) directly in a bank journal. It is
important to clearify generally if it should be possible to enter expense
(like telephone bill, or gas...) directly via bank statement or not.

*This was a critical functionality we developed in this customer branch*
http://bazaar.launchpad.net/~openbig/bigconsulting/addons/files (especially
the 2 modules: account_invoice_cash_discount &
account_payment_discount_extension).

Furthermore two points:

1. Maybe i jumped from the wrong side on the horse, but i recognized a huge
problems with missing 'reconcile' field wizard in a bank statement line. I
hope instantly that i was not able to reach the full scope of
account_voucher simplifications(?), but at the moment i discovered this:

Trying to follow the classical way i practised bymyself for over 2 years as
a debitor accountant (10 years ago but anyway) to reconcile a customer
invoice directly in a bank statement line (V5: field 'reconcile'), to be
able to decide about allocation of a payment, full or partly reconcilation,
write-off or not and so on .... This is not possible anymore.

2. There are some other generic problems, nothing todo with localisations,
more about basic functions in an accounting system.
@ Raphael and others. Before discussing about localisation, with all the lot
of differences, shouldn't we try to find and discuss and maybe vote about
the most important generic functions we miss? Maybe as a starting point. To
point to some maybe more generic problems we recognized to be the same in US
and germany. Sorry i have to say this is not a 140 sign sms style text ...

This was a conversation i had together with David form novapoint USA about
some missing generic functions for payment deductions (cash disocunts) which
are not rebates on a invoice line base (which are more simple).

Hi Thorsten,

I wanted to follow-up on some of our prior emails about cash-discounts,
write-offs and now how credits are applied against customer payments.

Next week will be modify some of the existing work we did to extend our
solution to work better with the new v6 Sale Payment flow associated with
the modified account_voucher. It should be done in a week or two.

We're doing this work for a specific client - but are trying to develop it
in such a way to be applicable to the entire US (for US localization - which
is where the module will reside), and also try to ensure it has
applicability in the international market.

If you're open to it, could we arrange a time to talk early next week about
your requirements/use case and we can walk through ours?
If we can address our requirements with a little communication that would be
great.

As an introduction - below is what we're working on:

1. Modifying the new Sales Payment screen and account_voucher logic to
control and display: Payments with cash discounts, write-offs and credit
used, and to make the appropriate Journal Entries.
2. When an accountant/bookkeeper enters a customer payment amount, OpenERP
will go through an automated matching routine against the outstanding
invoices a customer has (I actually believe a user defined rule engine would
be great here in the future. At the very least we will make the code well
commented so others can modify the matching rules for their specific
situation). The new matching routine will take into consideration the timing
of the payments with cash discounts to try to accurately match and reduce
false positives. We're thinking it may be good to have a boolean flag on the
Sales Payment screen that enables an accountant to control whether they want
a payment to go through the "automatic matching" routine or assign it
manually.
3. OpenERP will then present the proposed match. An accountant can accept
the match or modify any of the payment field values (which invoices a
payment will be applied against, the amount to apply against a specific
invoice, if cash discounts are taken and how much, and if write-off entries
should be applied as well as if credits will be applied and how much to
allocate to a specific invoice) in addition we will also provide for future
development in the enhancement to designate whether finance charges have to
be paid and interest assessed (in the US companies can charge a finance
charge on outstanding/past due invoices and amounts (e.g. if a $1000 invoice
is past due 30 days - the customer may be assessed a 1.5% finance charge on
the outstanding balance or a minimum value amount(e.g. $15)). An accountant
will be able to manually override any of the automatic matching logic - so a
customer's specific instructions on how a payment would be applied can be
executed.
4. Today, in the new v6 account_voucher module, OpenERP automatically
applies the available credits against the "oldest outstanding invoice". This
really doesn't work for our market. We will be overriding this functionality
as our clients/accountants have indicated their customers specifically
instruct then on which invoices and in what amounts credits would be
applied. (What I am describing is actually very similar to logic found in a
popular application here in the US called Quickbooks (see Discounts and
Credits; Quickbooks in a google search). To accommodate this requirement
which we will make separate we will enable user/accountants to select a
specific outstanding invoice which will bring up a wizard that displays all
the outstanding credits and allows users to select which credit(s) and how
much of the available credit to apply against a single invoice.

A little background . . .
What I described above is really tailored towards an approach where
individual customer payments are entered into OpenERP. We consider this a
backwards step - as our banking payments system isn't as advanced as you
have in Europe for instance.

Many customers in the US still receive physical checks for payment, and when
they receive the physical check in the post they enter the payment in the
system and then deposit the funds to the bank (by either physically
delivering the checks to a bank branch, or by scanning them and sending an
image file to the bank - which is called remote check capture). So the usual
process today is:

1) Receive check payment
2) Record/Reconcile payment with invoices in their ERP system
3) Deposit the check to the bank
4) Receive Bank Transactions (may be an end of the month statement - or a
download of transactions during a month)
5) Reconcile that the check cleared with the bank account

For most Small to Medium companies in the US, they still approach the
process this way (and actually physically deposit the check), which is
certainly not as advanced/nor efficient as importing bank transactions and
then having OpenERP automagically match the payments and having accountants
review the matches and manage the exceptions.

I view the OpenERP process with Bank Statements as:

1) Receive Bank Transactions (may be an end of the month statement - or a
download of transactions during a month)
2) Record/Reconcile payment with invoices in the system (automatic matching
or manual assignment)
3) Reconcile that all payments/transactions are accounted for in OpenERP


Of course - when companies in the US do receive electronic payments (which
are called ACH here in the US) they would have to go through a bank
statement matching process. So in essence there are two ways in which the US
handles payments (physical checks, and electronic transactions the other
another).


To streamline work for companies - what we may recommend is that clients
deposit physical checks first - and don't record the payment initially - but
rather wait for the transaction to appear in the bank statement. Then when
they pull the bank transactions (aka bank statements) - they use that method
to manage payments since it would encompass both the electronic and physical
check approach.

This process would be:

1) Receive check payment
2) Deposit the check to the bank
3) Record/Reconcile payment with invoices in the system (automatic matching
or manual assignment)
4) Reconcile that all payments/transactions are accounted for in OpenERP
5) Reconcile that their individual bank account with their "debit/credit"
bank transactions


Hopefully this provides a little additional background into our use case
today.

I'm interested to hear your thoughts . . . and compare use cases because I
believe the US is trying to move to a more similar model of what is found in
Europe.

PS. I'd also like to hear your thoughts about your MSI Wind Appliance. We
are an MSI Partner and are looking to launch a similar appliance for SMB
shops here - that want to run on-premise versus, as SAAS.

Thanks,

David Mitchell
President
NovaPoint Group
david@xxxxxxxxxxxxxxxxxx
+1-704-321-4700
skype: mitchell.dm


 Antworten
 Allen antworten
 Weiterleiten
Antworten
Thorsten Vocks an David
Details anzeigen 1. Nov. (Vor 10 Tagen)
Englisch
>
Deutsch
   Nachricht übersetzenDeaktivieren für: Englisch
Dear David,

for sure we can exchange ideas and experiences. I would  propose a kind of
web meeting, conference. I am sorry that i can offer this week only today
(our time 7 p.m. - i would assume 2 p.m. your time).

We had a  similar demand from customer requirement for a project we
realized with v5. Indeed it was a fact that OpenERP was not able to deal
with cash discounts. In the first project phase
i pointed our customer to a workaround with the existing accounting modules
and their account move flow logic.

As a consequence we recognized huge time demand to follow this workaround
solution, especially the customer
would have to create a lot of account moves and calculations manually with
high risk to create not proper account
moves and more time demand in compartion to their prior software for
reconcilation management.

I will try to comment your email statement regarding your plan later. I am
sure there are some similar thoughts and
strategy in it and also improvements, because i should have to say that my
feeling about our solution (account_invoice_cash_discount,
account_payment_discount_extension) is that there is
still a lot of room for improvements - hopefully simplifactions or better
useability. Currently we have to
explain the modules, which could point to the fact that these modules are
not generic enough.

Also we have to care about differentation between
- customer payments with cash discounts
- supplier payments with cash discounts
- customer payments with cash discounts (in a different currency)
- supplier payments with cash discounts (in a different currency)
- different anchors in OpenERP payment procedere which also differs
depending of concrete situation especially differing between customer /
supplier payments but also payment with pay invoice wizard, import invoice
wizard in bank statement or account_payment_extension depending additionaly
of pre-invoice payments or not, payment of domestic partner invoice or
foreign partner invoice and so on.

I will also try to summarize the main problems we discovered with OpenERP
for payments:

- payment terms doesn't cover cash discounts, in the sense to be able to
create the right account moves on invoice payments
automatically

- we missed account types as a kind of anchor to create automatically
counterpart account moves on a realized cash discount: for instance"cash
discounts to customers account", "cash discounts from suppliers account".

These counterpart moves should be against the (100%) income (customer),
expense (supplier) account moves on a invoice . We have to create as much
counterparts as we have different income/expense move lines from an invoice
(to cover full, half, no tax depending of the product for the logically
follwing tax correction- in germany we have for instance for food and
books). In an additional step to the cash discount we need the counterpart
posting of invoices tax account moves with proper entries in the base tax
and tax fields to ensure accurate counterpart entries also for the legal tax
reports comming from these tax fields .... For every account move  we have
to adopt and to check finally fiscal positions (especially for the new "cash
discount account" moves and the tax corrections) for every situation to
ensure proper validation of taxes (tax amount) to tax base (amounts) and tax
accounts balance. For this purpose fiscal positions mapping needs to be
applied not only to invoices and payments but also to stock account moves).


- payment in another currency needs an additional account move to another
new "curreny difference account" (assume the common situation of different
exchange rates between invoice and payment date).

- We should be able to cover a sequence in cash discount terms which needs
to be reflected to propose the right payment amount for the amount to pay in
dependency of payment terms cash discount conditions (2% in 10 days, 1% in
30 days, net cash 90 days).

- There could be also in some cases payment term in the sense of OpenERP
interpretes a payment term which is imho not a cash discount condition (half
payment after 0 days, another half after 180 days). Both sequences could
have a cash discount condition. Sometimes the whold cash discount for the
100% amounts needs to be applied only to the first sequence payment to
complicate the sceanrio a little bit more;-).

- We need to deal with pre payments we create from time to time for large
supplier contracts. If we reconcile a pre-payment against an invoice
(sometimes after we pre paid a certain amount), there should be also
application of cash discounts (modified action wizard in reconcilation
dialogue).

- Another idea was to be able to choose for the account moves of cash
discount to take either "cash discount accounts" from the
payment term conditions (with our modification to extend payment terms with
cash discount conditions) or simply "against the original income/expense
account from the invoice. This was refused from the customer, because they
doesn't recognized a demand for this. For proper account moves regarding
fixed asset accounts (for instance invoice for fixed assets) i still see
this as a demand.

- Also i see some influence in cases you work with a complete configured
stock accounting (to re- calculate average prices). This was also a
requirement from our customer. I am nearly 100% sure we modified also the
appliance logic of fiscal positions mapping for this purpose.


Summarized: We covered everything in our modules, except the refused parts
of the customer. *Indeed a kind of rule engine to configure different
payment scenarios with account move template (engine) could be a huge
improvement of our solution*.

I will further try to comment directly inline your email...


2010/10/29 David Mitchell <david@xxxxxxxxxxxxxxxxxx>

Hi Thorsten,
>
> I wanted to follow-up on some of our prior emails about cash-discounts,
> write-offs and now how credits are applied against customer payments.
>
> Next week will be modify some of the existing work we did to extend our
> solution to work better with the new v6 Sale Payment flow associated with
> the modified account_voucher. It should be done in a week or two.
>

Account voucher module as i can appraise at the moment ( i  also evaluated
the main idea in the phase of developement a few weeks ago) does not really
fit to demand of payment management in bigger companies. Especially it does
not fit imho in combination with a cash discount scenario. Also imho it does
not fit to the account flow for debitor and creditor accounting departments
in medium and large companies. For small companies without complex payment
and cash discount conditions  this might be a smooth solution anyway (for
instance the scenario if you have a few regular customers with some, more or
a lot of invoices) to reconcile in voucher dialogue.

In this case it could be indeed smooth to assign and to detect automatically
invoices and payments for reconcilation of these creditors/debitors. On the
other hand i am sure there are not so much alternatives to do it the way we
do it now (dealing with customer payments in bank statements , supplier
payments in a two steps flow with at first account_payment_extension to
create a payment proposal with the right amounts comming form payments and
(!!) cash discount terms and  in a scond step a  one line move in bank
statement against intermediate account we use in extended
account_payment_extension as counterpart account against creditor accounts.)



>
> We're doing this work for a specific client - but are trying to develop it
> in such a way to be applicable to the entire US (for US localization - which
> is where the module will reside), and also try to ensure it has
> applicability in the international market.
>
> If you're open to it, could we arrange a time to talk early next week about
> your requirements/use case and we can walk through ours?
> If we can address our requirements with a little communication that would
> be great.
>

The best would be imho to present (teamviewer) what we realized in our
customer project to give you a light on this development result  or to point
to  further improvements or a rework with or without adaptions from our
modules.



>
> As an introduction - below is what we're working on:
>
> 1. Modifying the new Sales Payment screen and account_voucher logic to
> control and display: Payments with cash discounts, write-offs and credit
> used, and to make the appropriate Journal Entries.
>

Imho the problem i see with account_voucher is a little bit the workflow
(dealing with payments in practise) which is not the (main) way an
accountant would work to realize best efficiancy. In fact the real scenarios
i know about is entering line by line from a printed bank statement, where
you have to switch line by line between customer payments, supplier bulk
payment counterpart positions (x $ for y invoices posted a day befor to the
bank), direct debits for telephone, gas, water (not an invoice every
month!), manual payment of supplier invoices, cash box balances ...
The automated assignations of differences as Fabien showed in the webinar is
imho dangerous. This will lead imho to more confusion, because for instance
your customer does not know that you assigned a difference to a certain
invoice. But he should, otherwise it is possible to receive at the end a
difference you cannot explain and solve, because you have reconciled
invoices, which are still unpaid, or partly paid in the sense of the payee.
>From my own experience i know that doing it this way might be horrible.


> 2. When an accountant/bookkeeper enters a customer payment amount, OpenERP
> will go through an automated matching routine against the outstanding
> invoices a customer has (I actually believe a user defined rule engine
> would be great here in the future. At the very least we will make the code
> well commented so others can modify the matching rules for their specific
> situation). The new matching routine will take into consideration the
> timing of the payments with cash discounts to try to accurately match and
> reduce false positives. We're thinking it may be good to have a boolean flag
> on the Sales Payment screen that enables an accountant to control whether
> they want a payment to go through the "automatic matching" routine or assign
> it manually.
>

At the moment we have these routines implemented in bank statements, pay
invoice wizard and payment_account_extension (i marked these routines in
yellow, more you can adopt from the beginning). *The idea of user defined
rule engine is good*, maybe you can give a little bit more light on this.
Otherwise i would say that this is simply definition of cash dicount terms
with cash discount account properties. Then we need either in in addition
(per invoice) to the field "total amount", the (dynamic calculated) fields
"cash discount" and "amount to pay" (total amount - cash discount amount)
either in new sales payment lines or better in classical move line of bank
statement. Furthermore a possibility to change these two pre-calculated
fields and to decide how to deal with a potential difference (no
reconcilation, additional write-off line, additional assignation of
difference to cash discount) and last not least calculation and automated
journal postings of tax reductions would be great.

*Automatical matching of a single payment for a lot of invoices taking into
account cash discounts as you proposed could bring further **benefit*.  *Anyway
this issue need a deeper research, some **testing with the v6 changes*.
Saturday i made first tests with the new reconcilation and payment flow and
sorry i have to say that either i am to stupid to discover the scope of
"improvements" or that it seems we have a reinvention of the wheel but in
fact simply a big step in a wrong direction from  accounting point of view.
For the moment i mainly miss the reconcilation dialogue in bank statement.
Further more i receive wrong account journal posting, wrong balances and it
was not possible to reconcile a really simple use case with cash discounts.
But fairly i should give it a next try in the next days, maybe the path i
followed was wrong.

Regarding your last sentence above. *Yes it should be a possibility to
decide between attempt to automatically match invoices and to automatcally
assign payment amount to invoices or to keep possibility for a  manual
intervention. *


> 3. OpenERP will then present the proposed match. An accountant can accept
> the match or modify any of the payment field values (which invoices a
> payment will be applied against, the amount to apply against a specific
> invoice, if cash discounts are taken and how much, and if write-off entries
> should be applied as well as if credits will be applied and how much to
> allocate to a specific invoice) in addition we will also provide for future
> development in the enhancement to designate whether finance charges have to
> be paid and interest assessed (in the US companies can charge a finance
> charge on outstanding/past due invoices and amounts (e.g. if a $1000 invoice
> is past due 30 days - the customer may be assessed a 1.5% finance charge on
> the outstanding balance or a minimum value amount(e.g. $15)). An accountant
> will be able to manually override any of the automatic matching logic - so a
> customer's specific instructions on how a payment would be applied can be
> executed.
>

I totally agree. This seems to be a huge OpenERP lack at the moment. The
automated application seems to me far away to cover
real business cases. At the moment it might cover some special situations
more than common use cases.


> 4. Today, in the new v6 account_voucher module, OpenERP automatically
> applies the available credits against the "oldest outstanding invoice". This
> really doesn't work for our market.


 *100% right.* I do not believe this works anywhere in the world. This is
far from reality in germany to. Sorry that i have to say this, but it does
not suite the requirements of bigger companies. It only fits for some seldom
scenarios. I just tried to think about an example where this scenario could
bring a benefit. A business example could be a fixed payment once a month
from customers own calculated "payments for consumption" with a time delay
(prior or  afterwards) to real invoices, very often with different total
amounts between payment and invoice. A kind of running account, which is a
mess to reconcile because it is nearly impossible to do a proper follow
up management. This makes it also difficult to control key indicators
like average
collection periods and more worse to control improve liquidity situation
trying to reach more time near payments.

I compared to Navisions payment flow. They have two different methods. The
way  in OpenERP V6 is the second (not default) method besides the main one
which is
- open item management (methododoly you described per invoice based, with
possibility to activate some invoices via check box and change amounts
manually). The other one is
- balance method , which is in navision defined as a customer property
field. Payments are automatically assigned to the oldest outstanding
positions (the same as we have in v6 -> voucher module).


> We will be overriding this functionality as our clients/accountants have
> indicated their customers specifically instruct then on which invoices and
> in what amounts credits would be applied. (What I am describing is actually
> very similar to logic found in a popular application here in the US called
> Quickbooks (see Discounts and Credits; Quickbooks in a google search). To
> accommodate this requirement which we will make separate we will enable
> user/accountants to select a specific outstanding invoice which will bring
> up a wizard that displays all the outstanding credits and allows users to
> select which credit(s) and how much of the available credit to apply against
> a single invoice.
>

100%. This is not only in quickbooks the usual solution..

>
> A little background . . .
> What I described above is really tailored towards an approach where
> individual customer payments are entered into OpenERP. We consider this a
> backwards step - as our banking payments system isn't as advanced as you
> have in Europe for instance.
>

Yes i also see this as a backward step, in best case it is an improvement
for  a special scenario.
*Except it wouldn't be so difficult to...*
*... embed voucher method in bank statements (reconcile filed v5)*
*... proper usage of credit application*
*... new activate / deactive field of Invoices and credits choice in voucher
dialogue (bypassing automatic way)*
*.... possibility to change "payment", "cash discount" fields in the lines
of invoices.*
*.... automatical posting of tax corrections and counterpart moves for all
counterpart deductions (cash discount)*



>
> Many customers in the US still receive physical checks for payment, and
> when they receive the physical check in the post they enter the payment in
> the system and then deposit the funds to the bank (by either physically
> delivering the checks to a bank branch, or by scanning them and sending an
> image file to the bank - which is called remote check capture). So the usual
> process today is:
>
> 1) Receive check payment
> 2) Record/Reconcile payment with invoices in their ERP system
> 3) Deposit the check to the bank
> 4) Receive Bank Transactions (may be an end of the month statement - or a
> download of transactions during a month)
> 5) Reconcile that the check cleared with the bank account
>

I assume you have an intermediate account to bridge the gap between  bank
acc. (cheque) and  main bank account.



>
> For most Small to Medium companies in the US, they still approach the
> process this way (and actually physically deposit the check), which is
> certainly not as advanced/nor efficient as importing bank transactions and
> then having OpenERP automagically match the payments and having accountants
> review the matches and manage the exceptions.
>
> I view the OpenERP process with Bank Statements as:
>
> 1) Receive Bank Transactions (may be an end of the month statement - or a
> download of transactions during a month)
> 2) Record/Reconcile payment with invoices in the system (automatic matching
> or manual assignment)
> 3) Reconcile that all payments/transactions are accounted for in OpenERP
>
>
> Of course - when companies in the US do receive electronic payments (which
> are called ACH here in the US) they would have to go through a bank
> statement matching process. So in essence there are two ways in which the US
> handles payments (physical checks, and electronic transactions the other
> another).
>
>
> To streamline work for companies - what we may recommend is that clients
> deposit physical checks first - and don't record the payment initially - but
> rather wait for the transaction to appear in the bank statement. Then when
> they pull the bank transactions (aka bank statements) - they use that method
> to manage payments since it would encompass both the electronic and physical
> check approach.
>
> This process would be:
>
> 1) Receive check payment
> 2) Deposit the check to the bank
> 3) Record/Reconcile payment with invoices in the system (automatic matching
> or manual assignment)
> 4) Reconcile that all payments/transactions are accounted for in OpenERP
> 5) Reconcile that their individual bank account with their "debit/credit"
> bank transactions
>
>
> Hopefully this provides a little additional background into our use case
> today.
>
> I'm interested to hear your thoughts . . . and compare use cases because I
> believe the US is trying to move to a more similar model of what is found in
> Europe.