# Line vs Item Discounts

I have a problem that I’m wondering if anyone has written a solution for: We came from Fourth Shift ERP which did item discounts. Navision is doing line discounts. We have an item with a list price of \$14.81. The customer gets a 57.5% discount. Price each is \$6.29. They ordered 175 of this part. From the customer’s perspective, the invoice line should be \$1100.75 (175* \$6.29). Instead they were invoiced \$1101.49. Navision takes the list price * line quantity then applies the discount. Outside of having to define each of my 12K active items and their discounted price for each customer, does anyone else have a potential solution? Thanks in advance!!! It’s Friday!

Yeah, I had the same problem while implementing customers that gives line discounts. I still have not met a client in the USA that calculates discount by (List Price * Quantity) * discount. I guess this is a Europe thing? Anywho, this has to be modified. Both on the sales line table and on the codeunits.

Mathematically ABC = (AB)C = A(BC) in the both the US the UK and generally around the globe. Your \$6.29 is really \$6.29425. Exactly where you do the rounding is always an issue. On the line, on the item, on the sku, on the order. Navision as you say works on the list price and calculates discount on the line. A bit radical but why don’t you show the \$ price to more than two decimal places ? I’m assuming you have different discounts for each product per customer. If you always give a customer 57.5 % discount then you can do it through customer sales invoice discounts.

Business standard here in the US is 2 decimal places. We round the discounted unit price, thus \$6.29 x sales qty. This is the way that most, if not all, ERP packages in the US do it as well. If most if not all US companies have to have this piece of the code changed to fit the US model, why doesn’t Navision offer this as a configurable option in the Sales and Receivables - Setup option, or in the US version? I know some things are changed for the US when new version come out. Why can’t this be one of them?

I would say that most companies in the UK use two decimal prices like yourselves. However I have seen major UK companies raise purchase orders / invoices to 5 decimal places. But I agree with your comment. If it’s standard in the US then presumably the US localisation should cater for it.

quote:

Originally posted by Navicons
Mathematically ABC = (AB)C = A(BC) in the both the US the UK and generally around the globe. Your \$6.29 is really \$6.29425. Exactly where you do the rounding is always an issue. On the line, on the item, on the sku, on the order. Navision as you say works on the list price and calculates discount on the line.

Oi… Yes, indeed mathematically, it’s the same. But unfortunately, Navision includes the ROUND function. Therefore: Round(Round(AB)C) <> Round(ARound(BC)). This is why you have wierd decimals when invoices gets printed out. Yes, I agree that the US version should include something in the S&R setup for this. This is hugely annoying, for the US anyway[:D]

What is the problem, really? Doesn’t \$1101.49 result in a better profit than \$1100.75? [8D] And “Business standard here in the US is 2 decimal places” - is that the reason why Intel had problem with their Pentium processor? [:D] (sorry, just having a good day here!)

And I seem to recall that AB # BA for Matrices too. When Mr Wmart orders 2,000,000 pencils for one of his distribution centres. Suppose he pays 10 cents for them ? But then he applies some pressure to his suppliers. Do you think he 9 cents or 8 cents per pencil. Or perhaps he pays 9.75 cents per pencil. I worked for a lace company in NY and we sold lace per yard at fractions of a cent. Clearly Mr Mart doesn’t have Navision !

I’d like to add to this discussion that whenever you switch from one system to another, you will always find differences in calculations, rounding, applications, etc. Rather than spending the time and monay to make Navision do the same thing as 4th Shift, maybe you could just accept the way Navision works and move on from there? This time the total amount is \$.74 higher, another time it might be a little lower that 4th Shift calculates. Overall (offsetting a year of transactions) I think it would be pretty close.

We can’t just accept it today, as we have published our parts pricing, showing them, by item number what their discounted pricing is. Thus they take the discounted and rounded pricing * qty. I’m trying to see if sales will accept the fix of changing the discount % to 57.535, which would put most orders of qty > 100 a few cents under what the customer would expect to pay. Hopefully this will eliminate anymore phone calls. The loss in revenue is so small, it wouldn’t be noticed.

quote:

Originally posted by Rich Rhodes
We can’t just accept it today, as we have published our parts pricing, showing them, by item number what their discounted pricing is. Thus they take the discounted and rounded pricing * qty. I’m trying to see if sales will accept the fix of changing the discount % to 57.535, which would put most orders of qty > 100 a few cents under what the customer would expect to pay. Hopefully this will eliminate anymore phone calls. The loss in revenue is so small, it wouldn’t be noticed.

Word my friend