bank statement - some more misssing features comparing to V5
Locked
 
|
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 [hidden email] +1-704-321-4700 skype: mitchell.dm
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".
- 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 <[hidden email]> Hi Thorsten, 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.)
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.
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..
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)
I assume you have an intermediate account to bridge the gap between bank acc. (cheque) and main bank account.
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [hidden email] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp |
|
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 <[hidden email]> wrote: Dear ferdinand and other experts. _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [hidden email] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp |
SegregationofdutiesTable.doc (30K) Loading...
| Powered by Nabble | See how NAML generates this page |
