Decimal number strangely rounded to integer in product_qty

Hi,

I get strange behaviour in the line items area of an invoice I try to create in SuiteCRM 7.8.1 (php 5.6.29): When I try to set the product quantity value to 5.5 it switches immediately to 6, and calculates line total based on 6 thus giving a faulty value. Is this a bug, or down to some mistake I make in my handling?

When I google around for an explanation, I realize that some earlier releases have had a similar problem caused by the product_qty field type being wrongly configured as integer (or so is my impression – I am not a clever guy with these things). (For reference, see e.g. https://github.com/salesagility/SuiteCRM/commit/a6a2b850d1a792ab2ceacdf061808d8e0b7310cf)

However, in my instance the field type seems to be set as ’decimal’, and precision is 4 (that’s the number of decimals which should be saved, right?). This shows in /modules/AOS_Products_Quotes/vardefs.php as the following code (right?) starting line 106:

    'product_qty' => array(
        'required' => false,
        'name' => 'product_qty',
        'vname' => 'LBL_PRODUCT_QTY',
        'type' => 'decimal',
        'massupdate' => 0,
        'comments' => '',
        'help' => '',
        'importable' => 'true',
        'duplicate_merge' => 'disabled',
        'duplicate_merge_dom_value' => '0',
        'audited' => false,
        'reportable' => true,
        'len' => '18',
        'size' => '20',
        'enable_range_search' => false,
        'precision' => '4',
     ),

Checking instead via Studio in the CRM backend, for the field product_qty in module Line Items, I get the same impression as looking at the code above: type is decimal and precision is 4 (decimals?):

[Pic attached as file]

In other words there is a contrast between apparent settings and behaviour.

5.5 is being rounded upwards to 6, different from some previously reported errors where decimals were said to be truncated. In my case 5.4 is rounded down to 5.

I feel very silly, what am I doing wrong? Please advise me on how this could be fixed in an upgrade-safe way. (If you think I will be sorted by just waiting for the next upgrade or so, that’s good enough for me. I am not super-cool with coding myself.)

Thanks a lot for any assistance!

Hi again,
the bug now seems to have disappeared. I can now charge my client for 5,5 hours – yes, with the decimal – and line total is calculated correctly.
Could the improvement possibly be related to the fact that I just ran a “Quick repair and rebuild”, under Repair on the Admin page?
/Alex