Quote Subtotal 100x Larger - Line Items Calculations Wrong

[burndata]

As the story continues I have the quote system now working and have now pushed onto the line items part of my adventure.

I have just added a couple of items to a quote and have just noticed the subtotal is way off. see picture.

You will see the math is 100x greater.

I double-checked my quantities… hmm. I will dig deeper… I think I have to dig into the

modules/AOS_Products_Quotes/line_items.js

I will find it and hopefully report back… maybe it is on my end. hmm.

I was able to adjust the values and have them work…
And then Not work all by just changing the quantities back and forth… I am poking into the javascript and seeing what could be the issue.

afte time…

I do see that the javascript that loads the detail view up is pulling a decimal value from the dom that is a float ie: 1.000000 value vs a quanity that should be a integer ie: “1”

Lines 776 /modules/AOS_Products_Quotes/line_items.js
if (input[j].id.indexOf(‘product_qty’) != -1) {
qty = unformat2Number(input[j].value);

I am going to dig deeper and see what I can find.

[pgr]

Make sure you’re using the latest version, I remember seeing this bug before and I think it’s fixed, but I might be wrong.

I think it’s related to number formats - dots versus commas to specify fractional parts.

Maybe you can try some variations in formats, both from the user profile and from locale settings in php.ini (I’m not sure that is even a thing, just hinting)

[burndata]

Installed Version:

Version 7.11.15
Sugar Version 6.5.25 (Build 344)

still checking this quantity issue… going to see if I can force it to an integer on the web page generation side of things. So when the quantity value is then pulled from the dom it is an integer, not a fractional value that has to get converted to a string and then an integer… ouch. I think this is the issue… hmm. I think I am in the right local.

I do wonder why the “Quotes” has a British pound icon… like wow.

I have seen posts about this Pound issue… I will fix that when I have time…

Time passes…

I was able to track down where this issue / bug was pinpointed by other developers…

//Bug #598   --- Line 222 - modules/AOS_Products_Quotes/Line_Items.php
//The original approach to trimming the characters was rtrim(rtrim(format_number($line_item->product_qty), '0'),$sep[1])
//This however had the unwanted side-effect of turning 1000 (or 10 or 100) into 1 when the Currency Significant Digits
//field was 0.
//The approach below will strip off the fractional part if it is only zeroes (and in this case the decimal separator
//will also be stripped off) The custom decimal separator is passed in to the function from the locale settings

I am still going to try to force this product_qty into a integer value right from the start. I could be walking up a mountain though.

Time passes…
.
.
.
.
I think I just finished climbing the mountain…

Seems the product_qty is now an integer. whoo hoo!! quotes will not be laughed at by customers seeing crazy prices.

Took some editing… but I think things are working satisfactorily at this time. see pics…

This could be fixed. At least so far… still testing…

Some icing on the cake. Seems updating the defaults is a mysterious act to get the defaults saved. forcing them via the custom files…

//Manually Added Defaults to this file /custom/modules/AOS_Products_Quotes/Ext/Vardefs/vardefs.ext.php
$dictionary['AOS_Products_Quotes']['fields']['product_qty']['default']='1';
$dictionary['AOS_Products_Quotes']['fields']['product_qty']['min']=1;
$dictionary['AOS_Products_Quotes']['fields']['product_qty']['max']=9999;

btw the file that I was able to modify for the datatype change in the above image for the Decimal to Integer is at:

modules/Contacts/metadata/listviewdefs.php

Whoo hoo!!

[pgr]

Nice detective work!

I think that your changes in
/custom/modules/AOS_Products_Quotes/Ext/Vardefs/vardefs.ext.php
will get overwritten in your next QR&R.

You need to make those changes in
custom/Extension/modules/AOS_Products_Quotes/Ext/Vardefs/anyFileName.php
and then the QR&R will move them into that file you edited. But if you do it this way it sticks.

Full docs about this here:

Vardefs

[burndata]

ohh that is very sweet. I think I would get further if I rtfm