openerp-expert-accounting team mailing list archive

[David Mitchell <david@xxxxxxxxxxxxxxxxxx>]

Hi Fabien,

Thank you for responding and explaining the situation. I agree it can be
difficult to manage/maintain multiple methods of similar functionality.

One thing I will ask for your consideration and thought - for architectural
changes such as what has occurred here, I believe it is important to
establish a design stage/and review concept in the community _ Request for
Comments RSS feed -  period on the design. 1) to communicate what your
intentions are and 2) to gain feedback. From a Product Management software
perspective it is important to keep the community in sync/informed even if
they are fast moving changes/decisions for coordination. Perhaps you're
already doing this . . . but if not I encourage you to consider this as a
positive step to reduce wasted effort/cycles in the community - and also
improve the quality of the product. That would be a proactive step versus
forcing the community to be reactive. Perhaps this occurred and I missed it
in the accounting expert forum/discussions - so apologies if I did. NPG knew
when we began implementing our clients on alpha - v6 that we would face some
rework issues, and bug fixes along the way, but I feel this was more of a
coordination/communication breakdown. Even a *******Targeted for
refactoring/elimination ********** notice on the _openerp_.py file would be
good.

Our steps from here . . .
What we will do based on your information and projected stability of
accounting is review the best location to place the cash_discount
functionality for reusability and rework the code. If Quickbooks is your
benchmark then we would look to include placement on the Sales_Payment view
in account_voucher with an ability to apply Cash_discounts (like in
Quickbooks) - they also apply credit memos using the same dialog box by the
way. We had built the logic to test and automatically propose the discounts
and automatically create the corresponding G/L entries upon payment. I think
this effort will be positive that others may want to leverage/extend.

The other thing that is important is that we built the cash_discount module
to apply to the Product Line level - so individual products could be
accounted for in different G/L accounts. Some companies track all sales
discounts in a single GL account, and other track discounts by individual
product line sales accounts. The coding we have supports both. In our
version we will rework some of the default logic on how the payments are
applied/and journal selection on the payment because we feel some of the
logic today is incorrect - as outlined in my earlier email. This will be
available in the US Localization Code stream when we're done.

Thanks again for your time and we look forward to v6RC.

David Mitchell
President
NovaPoint Group LLC
david@xxxxxxxxxxxxxxxxxx

On Wed, Sep 22, 2010 at 12:39 PM, Fabien Pinckaers <fp@xxxxxxxxxxx> wrote:

> Hi David,
>
> In the past we had several ways of paying an invoice in OpenERP: invoice
> and pay wizard button, bank statement and bank reconciliation, manual
> reconciliation on journal items. These code were very complex and lead
> to several bugs in OpenERP v5 due to the complexity of multi-company,
> multi-currency & adjustments.
>
> The pay invoice wizard was not good because:
>  - it did not handled payment of multiple invoices
>  - it did not manage write-off/multi-currencies, taxes
> Most of the customers did not used this wizard but the bank statement
> instead which was more powerfull.
>
> So we decided to clean up these code and go for a unique code to manage
> the payment on an invoice, whatever the tool you are using (statement,
> pay wizard, sales payment, vendor payment).
>
>
> In the meantime, we developed the account_voucher module. It implements
> a very smart way of payment / reconcilition for customer or vendor
> payments. This useability has been inspired by Quickbooks (Intuit).
>
> This new feature allowed us to remove the old Pay Wizard on an invoice
> and the Bank Reconciliation form which was quite ugly too. The pay
> wizard button on an invoice is now just a Act Window on the
> account.voucher object. (500 lines of code replaced by 10). This is the
> same for the bank statement reconciliation form, it's just a many2one on
> the voucher object (instead of a specific bank reconciliation object).
> The useability is also much better.
>
>
> The result of this:
> * 1000 lines of code removed for more features
> * a unique way of handling reconciliation for all objects
> * better useability (which was the main trouble of V5)
>
>
> Unfortunately, we did this quite quickly in trunk, because our deadline
> for RC1 is approaching and we just finished the voucher features a few
> days ago. As usual, we changed all quality certified addons accordingly,
> but we don't have visibility on all the community modules.
>
> We don't have others modifications in the trunk planned for the
> accounting. All the modifications we are doing now is useability
> improvements of some views and bugfixes. So, you can rely on the current
> trunk for your development.
>
> For the prompt cash payment discount:
>
> I did not think a lot about your problem. But here are my quick thoughts:
>
> The pay wizard button is just a tool to ease the creation of payment
> entries and reconciliation. I think it's better to implement business
> logic at the business layer rather than at the user interface layer.
> Because by working on this wizard, it means that your module will not
> work for: payment recorded by bank statements, payment recorded through
> reconciliation, etc.
>
> You should investigate doing this feature at the reconciliation process
> so that it becomes generic. (if you partially reconcile, according to
> the amount paid, it may generate the entries of the discount automatically)
>
> Thanks,
>
>
> 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>
> > <
> 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 <mailto:david@xxxxxxxxxxxxxxxxxx>
> >
>
>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>