openerp-expert-accounting team mailing list archive

[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
>       * files removed:
>       * account/wizard/account_pay_invoice.py
>       * account/wizard/account_pay_invoice_view.xml
>       * 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

Attachment: mga-card2.jpg
Description: JPEG image