openerp-expert-accounting team mailing list archive

[David Mitchell <david@xxxxxxxxxxxxxxxxxx>]

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