openerp-expert-accounting team mailing list archive

[David Mitchell <david@xxxxxxxxxxxxxxxxxx>]

Hi Thorsten,

Good discussion I think. What I think becomes interesting about your point
about bank statement reconciliation and the set of capabilities is how the
process differs based on the size of the organization and segregation of
duties. At least across the pond here in the US.

Let me explain what we observe here . . .

In the US for a smaller operation - where possibly one person is managing
the full accounting and reconciliation process - an approach that allows a
user to do all steps efficiently in one "Super" do all wizard works well.
This issue is that this approach only works for the smallest of
organizations (one person managing the accounting) - and violates the
principle of segregation of duties in accounting common in the US - which is
designed to reduce fraud, embezzlement, internal in the organization. The
violation of segregation of duties/lack of financial control led to
significant legislation in the US over the last decade (aka SOX)

For larger organizations we see the approach to breakup the accounting
processes into various roles and duties - albeit at the cost of
efficiencies. So the old v5 bank statement wizard violates the segregation
of duties philosophy for all but the smallest of organizations - at least
here. And while segregation of duties helps on the "Fraud" perspective, it
of course is not the "most efficient way to operate the business", but still
seen as necessary. Call us skeptical/paranoid. This was driven by the lack
of "audit" capability found in most older accounting systems. If you do have
the Super wizard - then your ability to audit efficiently must be
"excellent".

I believe the lack of segregation of duties in the functionality is what
caused many individuals on some of the forums to state in the past "OpenERP
is completely unusable from a financial accounting perspective".

To demonstrate the segregation of duties and clarify my point - please see
the attached chart which I recently shared with OpenERP about the US market.
It shows the segregation principle as it applies to some activities in the
US in still relatively small companies - NOTE: it is not a comprehensive
list - I put it together to demonstrate the concept.

The other concept we have here is - matching/applying a list of banking
transactions (e.g. incoming payments) against invoices and the actual
review/monthly reconciliation of a bank account's transactions should be
done by a separate individual whenever possible in an organization.
Otherwise - someone can approve an outgoing payment and cover their tracks
with the bank too(Is this inefficient? Yes, of course. Does it provide a
better audit control? In theory, yes because it requires more than one
person to be involved in fraudulent activities.)

The impact I feel is - should OpenERP design the system for the one person
accounting shop - or does the design take on a segregation of duties
approach in the "base" system. It would be great if it easily could do both
surely - but there is a "cost to that all encompassing design" in the base
code I think.

At least that is my take currently. I hope this perspective at least shares
a little of what we are addressing in the US.

David Mitchell
President
NovaPoint Group LLC

On Thu, Nov 11, 2010 at 3:55 AM, Thorsten Vocks <
thorsten.vocks@xxxxxxxxxxxxxxxxxx> wrote:

> 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<http://bazaar.launchpad.net/%7Eopenbig/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 übersetzen Deaktivieren 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.
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting<https://launchpad.net/%7Eopenerp-expert-accounting>
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting<https://launchpad.net/%7Eopenerp-expert-accounting>
> More help   : https://help.launchpad.net/ListHelp
>
>

Attachment: SegregationofdutiesTable.doc
Description: MS-Word document