Page 1 of 1

XML Import Sales Order issue with overriding line price

PostPosted: Thu Jul 16, 2015 8:28 pm
by indikad
on 6.5.13 we used to be able to override the ExGST unit price for a line item when doing a XMLImport - sales order ( manually importing using the utilities area ).

However with version 7 the XML field does not have any effect ( <PriceExGst>)
Tried the field <DiscountedPrice> which seems to allow what we want to do. However the import behaves strangely.
on a 7.0.98 system the first line item seems to deduct 1% off the <DiscountedPrice>. from the first line. The rest of the lines get the price correctly
On a 122 system testing with 3 lines only one line got the price correct. Other 2 were less by about 5 cents.

a sample xml file that was tested is attached.

Re: XML Import Sales Order issue with overriding line price  Topic is solved

PostPosted: Tue Oct 20, 2015 3:59 pm
by Scott.Pearce
Hi Indika,

I must apologise for how long it has taken to respond to this post - it somehow slipped through the cracks.

With regards to your issue, I did some experimenting and found this to be a problem not limited to XML importing. The same issue can occur by manually creating a sales order with certain parts. I've logged bug 12165 to address the issue. Please read the bug for more information.

In simple terms, there are a number of ways to calculate "Price Ex." and associated fields, and because of rounding and precision, different results can be arrived at.

For example, imagine a part with a price of 2999. We add that part to a sales order, and we get Qty = 1, Price = 2999, Disc % = 0%. We then change the price to 10. Because the price has changed, we must recalculate the Disc %. The new Disc % value is 99.66655551850616872290763588. Of course, we round this to 99.67 AND HEREIN LIES THE PROBLEM. If we then change the Qty, even by over-typing it with the same value, fields get re-calculated. Price gets recalculated by applying the Disc % to the original price (list price). That's 99.67% off 2999, which gives us a price of 9.90 - because we rounded the Disc % the result is different. We could instead always calculate the Disc % FROM the Price, but this would become a problem if it were the Disc % that user last changed.