openerp-expert-accounting team mailing list archive

[Thorsten Vocks <thorsten.vocks@xxxxxxxxxxxxxxxxxx>]

Dear David,

interesting to see that you also jump into discussion about practise of
payments solution in OpenERP (discussion about following
account_voucher as best alternative?)

A few month ago we discovered the following about OpenERP payment
possibilities to cover demand of a customers project:

- At a first look OpenERP definitely was able to handle payments.

- At a second view the practise in OpenERP was not compatible with daily
workflow in accounting department of our customer.

- A lot of account moves for cash discounts, over-/underpayments, tax
(corrections) needs to be done by hand. There was no automated account move
creation.

- It was theoretically possible to book bank statement like they did before
in their ERP accounting system line by line from bank statement voucher but
the time demand to do this was huge in comparition to their former system.
We recognized definitely a lack of automated account moves and discovered
this as the main reason for the status quo at the beginning of this project.

- The simple possibility to "pay invoices" for every single invoice one by
one outside bank statements was definitely only a solution for some special
invoices, for instance for cheque or cash payments or for payments directly
at POS. We wasn't able to push this to the customer as the way they should
handle their payments.

- In bank statement it was only easy to pay simple invoices, invoices
without special payment terms like for instance cash discounts. Especially
cash discounts, over- or underpayment of invoices or also currency
differnces was the common use case in this project, the simple invoice was
the exceptional case. We wasn't successfull to push the customer to a
simplification of his processes (disclaiming all of their cash disocunt
conditions;-) ).

- The workaround to book payments with cash discounts and corresponding tax
correction was so time consuming that accounting department asked for
additional human resources to be able to handle their "new" work load
situation.

- There was a demand to be able to book also taxes in a bank statement
because there are a lot of account moves they enter directly from bank
statement (paper) as income or expense moves bypassing booking of complete
invoices. To do this we needed an easy way to create general account moves *
with* automated corresponding tax moves.

- Regarding supplier invoice payments was different from customer invoices:
Supplier invoices payments process first step is outside bank statement.
Common practise is to create a bulk payment proposal and to upload a payment
file to customers online banking solution to be able to process a bulk of
supplier payments in one step.
The demand for  this process is to have a good solution to propose payment
of supplier invoices in time (not to early and not to late), especially
proposing in time invoices to pay with a possibility to deduct cash
discounts when paying in a certain time frame.
We have to deal with a kind of "payment frequency", which filters out the
invoices a company should pay into a certain time frame to use especially
cash discounts on payment and to propose invoices getting due in this time
frame. For sure everything should be flexibel to enable the accountants to
decide to pay some invoices later or to change cash discounts by hand.
Everything i described has also consequences for accurate accounting moves
posting. Every manual change effects a change of account move. It has to be
taken into account different taxes in one invoice or different accounts we
need to post in dependency of partners country (for instance country leading
to a special fiscal position account mapping).

- Some customer invoice payments should also use the
account_payment_extension logic to pull payments from customer banks if we
are allowed to do this.

To cover all specialities i described above - *which are imho not only
specific to german requirements , *we started to develop
extension for

- bank statement reconcilation with automatic account moves for cash
discounts.
- bulk payment proposals (based upon account_payment_extension) taking into
account different payment terms and cash discount conditions.
- automatic creation of account moves we need to be able to book cash
discounts, over-/underpayments automatically with accurate tax correction
included.

You can find this under our branch in launchpad (openbig-openerp
branch<https://launchpad.net/bigconsulting>
)
Please look especially at the modules account_incoice_cash_discount,
account_payment_discount_extension (attention to dependencies).

I will also take a look at your developement for cash discounts because this
seems to be comparable to the solution we
developed. I hope there is a chance to benefit from each other (merge of
branches). For the future it seems to be a good example
to bundle resources for some (generic) development tasks.

I hope that i am right that OpenERP commits to maintain
account_payment_extension and our modules also for the future.
I am sure they have to, because there are maintenance contracts also for
these (certified) modules. If another solution really is better then i see
no problem to migrate customers to a better solution but i am also sure they
will be critical which is good customers right in this situation. Personally
i am really openminded for a better solution, but we need to think also
about the "special common" or like you want the "common special" use cases
because in a lot of projects these cases are more common than special;-)


Best regards

Thorsten Vocks
openbig.org



2010/9/22 Mantavya Gajjar <mga@xxxxxxxxxxx>

>  On Tue, 2010-09-21 at 19:21 -0400, David Mitchell wrote:
>
> Hi Fabien and the Accounting Experts Group,
>
> The account_pay_invoice.py wizard has gone missing?
>
> In reviewing some of the accounting code we see that the following files
> were removed with Rev 4818 on September 1st.
>
> http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/changes/4835?start_revid=4955<http://bazaar.launchpad.net/%7Eopenerp/openobject-addons/trunk/changes/4835?start_revid=4955>
>
>    - files removed:
>    - account/wizard/account_pay_invoice.py<http://bazaar.launchpad.net/%7Eopenerp/openobject-addons/trunk/revision/4818#account/wizard/account_pay_invoice.py>
>    - account/wizard/account_pay_invoice_view.xml<http://bazaar.launchpad.net/%7Eopenerp/openobject-addons/trunk/revision/4818#account/wizard/account_pay_invoice_view.xml>
>    - account_budget/account_budget_wizard.xml<http://bazaar.launchpad.net/%7Eopenerp/openobject-addons/trunk/revision/4818#account_budget/account_budget_wizard.xml>
>
> Is there a new design-"written down" that outlines the new flow of
> transactions versus using the Account_Pay_Invoice.py capabilities? It seems
> that with v6 we are abandoning this existing approach entirely in favor of
> the account_voucher approach to manage payments (using Sales_Payments) see
> Mantavya's blog. http://www.mantavyagajjar.in/
>
> The concern for us here in the US is that we've built modifications on top
> of the Account_Pay_Invoice.py capabilities to handle Prompt cash payment
> discounts (where companies receive discounts if they pay quickly - e.g. 2%
> 10 net 30; 2% discount on the price if they pay within 10 days and net due
> within 30 days of the invoice) as it looked like this code was being
> enhanced in prior recent revisions and would remain in the code. See
> cash_discounts to see this code in the USLocalizationTeam code stream. It
> modifies the partner code - to assign a cash discount to a partner, and then
> uses that cash discount in invoicing.
>
> Is there any guidance you Fabien, MGA, or the accounting experts can
> provide on what the overall intended design will be for this area and
> accounting in OpenERP - other than we're copying Quickbooks and to look at
> the videos. We're more concerned with what the vision is for the "end
> result" so we can build timely capabilities on top of the v6 trunk code.
> Fabien I know you've indicated the accounting code has been stabilized after
> the big push last week.
>
> Some companies do not utilize vouchers, and as such we'd like to see the
> account_pay_invoice.py wizard functionality restored if possible, or the
> cash_discount capabilities added to the new functionality + some refactoring
> of the sales_payment approach.
>
> Some issues in the logic with the sales_payment capabilities associated
> with the new account_voucher module (refactored) are below: they're not
> bugs, but rather design issues.
>
>
> #1- Today: Payments are applied to the oldest invoice first automatically.
> And then forward from there.
>
> MISSING: Why it does give you a list of outstanding invoices with open
> balances to select against – but doesn’t allow to positively select the
> invoice the payment will go against (e.g. checkbox). It only allows you to
> delete from the list of invoices you don’t want to pay. You should select
> from the list not – delete from the list. And if no invoices are selected it
> should apply to the longest outstanding invoice first and then forward –
> which it does today by default.
>
> Design Concept
>
>
> Typically in payment modules created in the past we've seen a split window
> mode: Have all the invoices listed with an outstanding balance on the
> left.Have an add and remove button in the center. A place to enter the
> amount of the payment up at the top.
>
> Typically have a checkbox to select which invoices to pay and then given a
> payment of a certain amount and the system automatically tried to figure
> which invoices to allocate to and moves them over to the column on the right
> (the invoices to pay column).
>
> e.g. Example 1 - Invoice list of 3 invoices with values 300, 200 and 500.
> If your payment is 500 which invoices do you allocate the payment to? If it
> can't figure it out the system will ask the user. The user then confirms the
> allocation of the payments against the invoice, but reallocate if needed.
>
>
> Example 2 - If you have invoices of 200, 300, and 600. If your payment is
> 500, the system will move both the 200, 300 to the right and apply the
> payment to that amount. The user then confirms the allocation of the
> payments against the invoice, but reallocate if needed.
>
> #2 - If an overpayment is applied it is applied directly to the accounts
> receivable – and doesn’t give the user a warning. It should give a warning –
> especially if there are outstanding invoices to ask how to apply the funds.
>
> #3 - default credit Journal account is used and the debit and credit
> entries are incorrectly applied in the system - they are reversed. The
> system forces you to select a Journal and then uses that Journal versus
> using the accounts associated with the sales_line in the voucher. This
> creates an issue when you have products that are booked to different Sales
> Accounts within the same Sales_receipt/Sales_payment. Default approach
> should be to properly book the debit and credit, using the accounts
> associated with the product first then the default credit journal account.
>
>
>
> #4 - Cash discounts need to be able to be available in Sales_Payments.
>
> I'd be interested in hearing the thoughts of the community on this one.
>
> David Mitchell
> NovaPoint Group LLC
> david@xxxxxxxxxxxxxxxxxx
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>
>
> Hello David,
>
> I would like to comment on the removal of the Account_Pay_Invoice
> capabilities, I think Bank statement is just going to change the internal
> objects only and not the way of working.
>
> If you look at the bank statement file under the account module now the
> model account.bank.statement.reconcile and
> account.bank.statement.reconcile.line are not exist, because internally now
> voucher is going to use instead of account.bank.statement.reconcile look at
> the code here
> http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/annotate/head:/account_voucher/voucher.py#L816
>
> So, i don't think it will affect the functional usage of the bank
> statements. and regarding the other points related to the voucher, this can
> be enhanced now or later upon the request.
>
> Regards,
>
>   *Mantavya Gajjar*
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Freundliche Grüsse

Thorsten Vocks

OpenERP Berater
Dipl. Kaufmann (FH)
big-consulting GmbH
Porscheweg 4-6
49661 Cloppenburg

Phone: +49 4471 8409000
Fax: +49 4471 84090009
Mail: thorsten.vocks@xxxxxxxxxxxxxxxxxx
Web: http://www.openbig.org