[purchase_discount] Wrong implementation in calc or generate packing and invoice

Hello!

Please revert this change in extra-addons and create a separate module for the modified code.

We use the original functionality as it is. The reason: Most of our suppliers give their prices and invoices in a base price + discount% form and we need to have the same numbers in the ERP to be able to match the ERP records with the supplier invoices in an acceptable amount of time.

Thank you.

Hello Dukai.

I can improve my change for both your functionality and what we think. Only
I need that you give us your opinion.

2010/6/18 Dukai Gábor <email address hidden>

> Hello!
>
> Please revert this change in extra-addons and create a separate module
> for the modified code.
>
> We use the original functionality as it is. The reason: Most of our
> suppliers give their prices and invoices in a base price + discount%
> form and we need to have the same numbers in the ERP to be able to match
> the ERP records with the supplier invoices in an acceptable amount of
> time.
>
>
The problem is: for the reason that the original is leaving the unit
 original price without discount if you have the poduct with "average price"
configurated, this amount is wrong calculated due this reason, and all the
accounting things in the middle.

For cause and efect we must to recalculate 6 month of average prices by hand
to correct average cost in time.

Is a good solution for you that we add a new field called
"original_price_wodiscount" ?.
With this, your customers can decide what "show" on invoices, quotation and
comunications you are tottally right this information is needed on lines. I

Will make this always because is necesary.

But the calc AFIK should be done with the efective amount on transaction
(including discounts), and not with the informative amount.

The question:

Why don't add a new field for me even for you?

The problem is that if i add _only_ a field for me and not override the
original equation to calculate the accounting behaviour, (that they are a
lot), the module is wrong implemented,
if you are not agree we can with all pleasure reverte the change but the
module must have a quotation on terp file IOHO "This module Override the
amount calc process and not include discount in the accounting process" ,
the problem will hidden until it is too late...... ;-)

Sorry for make directly the change, today i will make the revert if is
necesary depend your opinion or the opinion of other members.

Thanks.

> Thank you.
>
> --
> [purchase_discount] Wrong implementation in calc or generate packing and
> invoice
> https://bugs.launchpad.net/bugs/595780
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Addons.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> This module is necesary to give the power to ability to push discount in
> purchase process.
> Without this module all accounting process work great, but we think it
> shouldn't make anything else than calculate or force to change the "base
> cost" to be lower in an percent especificaly, I mean, it only change the
> price nothing else, with this instalation, the purchase only use the totals
> in a right way, we think this is wrong.
>
> We implement the changes and validate this with our accountant experts and
> they are agree with us, if somebody else is using this module we really
> aprecciate a feedback about that.
>
>
>

--
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
+58-212-6615932
+58-212-9536734 ext 124
+58-212-9512643
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://...

The discount handling in the original purchase_discount is consistent with the discount handling in sale.order, account.invoice and pos.order. The only difference is that the others have discount fields in the base module, purchase.order needs this separate module.

In my opinion we should not create a totally different behavior in purchase_discount just because some purchase-related code has bugs handling discounts but fix the bugs instead. For example invoices have discounts the same way implemented but in the accounting entries they create, the correct amounts are written.

Please look at my patch, that fixes the partial picking wizard that caused problems with the average cost handling you mentioned. I haven't noticed this problem before because we have a different cost handling.

Hello Dukai...

Sorry for the delay in answer.

IMHO the behavior in cost calculation for both cases Anglo and Normandy is
correct right now, i think we need to make consistent modules without
overwrite the original ones that are working very very good....

Solution:

I post on revno 4433 of extra-addons the solution to both situations (your
and mine) in the purchase_order_line with a consistent behaviour between
discount-price_unit - and[[New Field]] price_base if you change whatever you
 want the other two fields will take a consistent value....

If you are agree with this behaviour, i can extend this solution to
purchase_invoices, in this case you can show in all your documents the full
price (without discounts) and the original behaviour in the cost calculation
will stay "immaculate"...... Thanks a lot.....

Proccess:

Select Purchase Order.
Select a product.
----- All Fine auto loaded exactly like the original behaviour....

Change the discount Value.... the price_unit will change.
Change the _new price Unit.... the price_base change
Change the price_base the price_unit will change to a consistent value......

I hope it can help you..................

I improve a little thing....

If you put in your product your supplier and the prices related to quantities these will be used to calculate the first amount when you select the discount............ try it....!!!!!

Regards.

Hello Nhomar,

To sum it up:
-Your original problem could be solved with a 2-line patch as I proposed earlier.
-But you need a new feature on the PO to show a price that is lowered with the discount.
-You redesigned the purchase_discount module without asking anyone if they use the original version or not. No problem, I have it on my hdd.

My opinion is that it could be useful to show that price lowered with the discount. But if you do that, it should be done in all the modules I listed earlier to have a consistent way of handling discount through all the application and not to confuse users. IMHO in v5 this is not possible.

Regards,
Gábor

Hello Dukai...

You are right in one thing, i must ask firs before make the push, but IMHO
this is a problema looks like affect only you and me, anybody else has
commented anything :-( . I wait a lot of time before commit my first waiting
arround this problem but nobody improve this.

Like it is a extra-addon module i thought the change can be reviewed for a
lot of people but it wasn't.

BTW, My original problem wasn't only show the price lower, in depth for an
accounting point of view the simply fact of not use the real unit price in
all the process (price with discount included) affect all the behaviour in
at least 4 parts, we have this in our production enviroment and is working
very very well. I try it Your patch! It only resolve the consecuense not
the cause... IMHO the option of use discount _must_ be a standard feature in
the accounting proccess and in the purchase-sale proccess, but like this is
not, we decided make the changes in extra and share it as soon as possible
;-) to take feedback.

For this reason we want give you the solution too! because this is not my
module is our module, and we dedicate a little of time in improve it for you
point of view too!! we think with all opinions involved (in this case your
and my opinion) we can build consistent extra- modules.

I think. Any module in extra-5.0 shouldn't overwritte the standard behaviour
in account (), and the discount management is not the exception, for this
reason i leave the price_unit field for the procces _exactly_ as in the
original is i only overwrite to put some help and change the "label" but, if
at least one more person is disagree with me i can revert all the
change..... without problem.... we can check this with the accounting-expert
list.... are you agree???

Yes, I agree.

Hello Dukai....

I was preparing my email to post my point of view about this bug.... and I
realize that you are right in amost all your points, change the unit price
behaiviour on invoice was wrog affect at least 2 more modules.....

I revert my change... and added a new function field to invoice related to
the discount "to can use it directly on print reports and other
things......"

about the unit price in PO i left a price_base to push in invoice..... I
think for a functional point of view.... if you change one of three the
other two must change....

can you check it?.... I will prepare an exposition around all the
improvement to expose to accounting-expert mailing, but first i want you
point of view around it!!!

Thanks a lot for take the time in check it ....

Look Nhomar,

With your latest commit you didn't solve the problem just changed the behaviour of the invoice creating code in the stock module. There are a lot of other places in OpenERP that doesn't work with your module.

I agree that you should write to the expert lists to ask the opinions of others, too.

Hello. I'm Paco Torrado

It is the first time I participate in Launchpad.

I installed OpenERP 5.15 with purchase_discount module but It gave me bugs working with price unit, discount and price base.
Then I installed products_pricelist_discount_and_tax. It resolved the problems with getting data and discount from pricelist but has bugs calculating price_unit from price_base and later in the purchase order the subtotal and total calculation are not correct.

I have modified the code way to get the same behaviour than sales order so the rest process (delivery and invoices) work well.

Could you tell me if you continue working in those modules and how can I share my code with you?

Regards,

Just share some screenshots.

Line and total calculation correctly but unitary line price not implemented.
Price_base is never used.

Hello Paco,

The purchase_discount module in 5.0-extra-addons doesn't work with products_pricelist_discount_and_tax because as you can see from this bug report, Nhomar has modified it.

I've uploaded the original version of purchase_discount to https://code.launchpad.net/~gdukai/+junk/purchase_discount_v5_original

I'll soon update the module description of products_pricelist_discount_and_tax to include this information.
Sorry for not informing you earlier.