Manufacturing Values Off By Small Amounts

Whilst a onetime cleanup using a journal adjustment entry is in order, the real solution going forward will be to increase the precision in php.ini from default 14 to 17.

An interesting discussion on this topic is here:
https://stackoverflow.com/questions/145 … oint-issue.

I also tried precision set at 8, 20 and 40. All returned same, inaccurate, results in my test.

Assuming you are referring to a literal term, I do not find a "delta" value in my FrontAccounting's config.php

I saw this option, but thought it was for discrepancies while receiving a purchase order if pricing was too far off of the entered amount. But, I did change the value (not knowing it's potential) with no change to my manufacturing issue. The values I tested with other than the 0.005 were 0.505 and 5.505 - Manufacturing amount inaccuracies are still produced.

With the test php file, I get:

1.7 is NOT greater than or equal to 1.7000000000000002
0.30000000000000004

  I don't need super fine precision. I would like consistency. If I'm taking $33.01 out of inventory for manufacturing, I need $33.01 taken from manufacturing back into inventory. Maybe part of my problem is the difference from my vendors unit of 1 equals 1152 units in my inventory. Standard costs are shown at 4 decimal places.

This is an FA bug, sort of, and it affects my site as well, but I haven't gotten around to fixing it yet.  And yes, a journal entry is probably the only way to address it without fixing the code.

When FA closes a work order, it calls work_order_produce() which first creates the Finished Product Requirements.   The g/l created by each requirement eventually calls add_gl_trans().  Note the rounding in this function:

function add_gl_trans($type, $trans_id, $date_, $account, $dimension, $dimension2, $memo_,
    $amount, $currency=null, $person_type_id=null, $person_id=null, $err_msg="", $rate=0)
{
    global $SysPrefs;

    $date = date2sql($date_);
    if ($currency != null)
    {
        if ($rate == 0)
            $amount_in_home_currency = to_home_currency($amount, $currency, $date_);
        else
            $amount_in_home_currency = round2($amount * $rate,  user_price_dec());
    }
    else
        $amount_in_home_currency = round2($amount, user_price_dec());

OK, so each requirement is rounded, and then added up.

But wait, there is more to do.  work_order_produce() then sums up the Finished Product Recieval:

        // 1. calculate sums of material/labour/overhead costs

        // sum collected BOM material & labour costs (no way for separate overhead here for now - needs flag in bom or stock_master)
        $bom = get_wo_requirements($woid);
        $m_cost = $l_cost = 0;
        while ($component = db_fetch($bom))
        {
            if (!is_service($component["mb_flag"]))
                $m_cost += $component['unit_cost']*$component['units_issued'];
            else
                $l_cost += $component['unit_cost']*$component['units_issued'];
        }

        // add additional material issues
        $issues = get_additional_issues($woid);
        while ($issue = db_fetch($issues))
        {
            if (!is_service($issue["mb_flag"]))
                $m_cost += $issue['unit_cost']*$issue['qty_issued'];
            else
                $l_cost += $issue['unit_cost']*$issue['qty_issued'];
        }

        // and additional costs
        $o_cost = get_gl_wo_cost($woid, WO_OVERHEAD);
        $l_cost += get_gl_wo_cost($woid, WO_LABOUR);

        $total_cost = $o_cost + $m_cost + $l_cost;

        add_gl_trans_std_cost(ST_WORKORDER, $woid, $date_, $product['wip_account'],
            0, 0, $memo, -$total_cost);

        add_gl_trans_std_cost(ST_WORKORDER, $woid, $date_, $product['inventory_account'],
            0, 0, $memo, $total_cost);

So if all units were able to be manufactured, the calculation should be the same.

Except for the lack of rounding in this code.

So if it disturbs you to see these rounding errors, what can you do?  Well, you could try rounding m_cost and l_cost like in add_gl_trans.  Maybe try:

          if (!is_service($issue["mb_flag"]))
                $m_cost += round2($issue['unit_cost']*$issue['qty_issued'], user_price_dec());
            else
                $l_cost += round2($issue['unit_cost']*$issue['qty_issued'], user_price_dec());

I haven't tried this, so it might not work.  But this is first thing I would try.

I don't know. We have tried to do our best by using the DELTA factor.
We can await @Braath Waate's approach by @paul testing it.

/Joe

Just for the record, round2() is mainly needed starting at line 55 to sum up the the boms.  Line 65 is just the additional materials.

I have made many changes to FrontAccounting the past 6 months. I have rough notes of these changes. Probably 99% of those changes have been offered from many of you via this forum.

  What is the best way to backup and restore these changes when a new version becomes available? I imagine some of the changes I made to 2.4.7 may already be incorporated in the next version.