Search options (Page 153 of 247)

Please post your version of the modified file that works with standard settings in preferences so that it's effect may be studies in the sales and other portions it may possibly affect.

@joe / @itronics: your insights please.

The function user_def_print_orientation() is present only in FA v2.4.x beta and not in FA v2.3.x.

If you want the modded and backported version of the said file, then take it from my FAMods.

@Petros: In file taxes/tax_calc.inc the functions get_tax_free_price_for_item() and get_tax_for_items() use the formula for calculation you stated.

Please see if these are the places you would like to change.

Rounding is done for consistent storage value in the db to persist across version changes of the db server.

Other places where such code is available are listed below.

In file purchasing/includes/db/supp_payment_db.inc lines 114 to 116 when $rate <> 0:

        $supp_amount = round($amount / $rate, user_price_dec());
        $supp_discount = round($discount / $rate, user_price_dec());
        $supp_charge = round($charge / $rate, user_price_dec());

In file purchasing/includes/db/invoice_db.inc lines 129 to 133:

    foreach ($taxes as $n => $taxitem)
    {
        $taxes[$n]['Value'] =  round2($taxitem['Value'], user_price_dec());
        $tax_total += $taxes[$n]['Value'];
    }

and lines 137 to 143:

    $item_added_tax = 0;
    if (!$supp_trans->tax_included)
    {
        $taxes = $supp_trans->get_taxes($supp_trans->tax_group_id);
        foreach ($taxes as $n => $taxitem)
            $item_added_tax += isset($taxitem['Override']) ? $taxitem['Override'] : round2($taxitem['Value'], user_price_dec());
    }

In file purchasing/includes/supp_trans_class.inc lines 112 to 117:

        foreach ($this->grn_items as $ln_itm) 
        {
            $items[] = $ln_itm->item_code;
            $prices[] =round( ($ln_itm->this_quantity_inv * $ln_itm->chg_price),
                user_price_dec());
        }

lines 160 to 162:

        foreach ($this->grn_items as $ln_itm)
            $total += round(($ln_itm->this_quantity_inv * $ln_itm->taxfree_charge_price($tax_group_id, $tax_group)),
             user_price_dec());

lines 176 to 177:

        foreach ($this->grn_items as $ln_itm)
            $total += round($ln_itm->this_quantity_inv * $ln_itm->chg_price, user_price_dec());

In file purchasing/includes/po_class.inc lines 141 to 144:

        foreach ($this->line_items as $ln_itm) {
            $items[] = $ln_itm->stock_id;
            $prices[] = round($ln_itm->price * ($receival ? $ln_itm->receive_qty : $ln_itm->quantity),  user_price_dec());
        }

lines 164 to 184:

    function get_trans_total() {
        
        $total = 0;
        $dec = user_price_dec();

        foreach ($this->line_items as $ln_itm) {
            $items[] = $ln_itm->stock_id;
            $value = round($ln_itm->quantity * $ln_itm->price, $dec);
            $prices[] =$value;
            $total += $value;
        }

        if (!$this->tax_included ) {
            $taxes = get_tax_for_items($items, $prices, 0, $this->tax_group_id,
            $this->tax_included,  $this->tax_group_array);

            foreach($taxes as $tax)
                $total += round($tax['Value'], $dec);
        }
        return $total;
    }

In file purchasing/po_entry_items.php lines 465 to 470:

            foreach($cart->line_items as $key => $line) {
                $inv->add_grn_to_trans($line->grn_item_id, $line->po_detail_rec, $line->stock_id,
                    $line->item_description, $line->receive_qty, 0, $line->receive_qty,
                    $line->price, $line->price, true, get_standard_cost($line->stock_id), '');
                $inv->ov_amount += round2(($line->receive_qty * $line->price), user_price_dec());
            }

What platform are you on - Linux / Windows?
Have you enabled the various file functions in php.ini?
What does your Apache Error log say and are there any clues in your tmp/error.log file?

Please try to replace line 106 in purchasing/includes/purchasing_db.inc:

    $price = round($price * $data['conversion_factor'], user_price_dec());

with

    $price = $price * $data['conversion_factor'];

along with the default setting in preferences for the decimals and revert. Also state if there was any other place where the said function user_price_dec() should not be used.

The user_price_dec(), it appears, should be used only for display purposes and the highest precision should be used while storing data. This, of course, is limited to the number of decimal places available in the table's field where it is stored.

If this were to work, then all places where INSERT / UPDATE / REPLACE are used with this function, should be re-examined.

Void one of the invoices.

There could be several items in a delivery note coming in from different locations. (@joe: clarification)

If your business process confines items ion a delivery note to be from just one location, you might want to edit the header function of the report - See the Wiki.

You're right. Further investigation reveals something to do with NULL not being zero as the php code computes the material cost and adds to it the existing value.... just before inserting the Work Order cost entries.

Attached is the sql trail started for the Add Work Order button click alone - 82 queries!

In manufacturing/includes/db/work_orders_quick_db.inc, the function add_work_order_quick() is the one being executed in our case.

In manufacturing/includes/db/work_orders_db.inc, line 48 may be changed from:

            $material_cost += $m_cost;

to

            $material_cost = $m_cost;

and let us see if it makes a difference. Otherwise there could be some DELTA in subtraction causing the "==" to fail.

It looks like your PHP 5.4+ may be the problem. FA 2.3 was designed for PHP 5.3.

Now getting to the troubleshooting, place inspection points as in the wiki and enable the various debug flags in the config.php and see what fails where.

Provide a test backup (upload the sql somewhere and provide link here) of the fa install after all your above transactions and a list of menu navigations to replicate your error. It will save time to go thru the data entry screens.

Thanks Janusz.

Very elegantly done avoiding another function (should it now be toggle_hooks? ).

It certainly was worth the wait.

Synched and committed in my repo as well.

My tests have been on a plain vanilla FA 2.3.24+ install and the problem exists in it. It is imperative to fix it in the stable version as well based on the commit in my repo. The current activate_hooks is in itself a workaround on which the deactivate_hooks is based and the comment above the former would attest to this in includes/hooks.inc after the class definition:

/*
    Non active hooks are not included in $Hooks array, so we can use special function to 
    activate.
*/

Only, in this case, at this point of entry into the hooks_invoke even the active hooks are not in it! There are a host of functions that are outside the hooks class definition that create a new instance of the hooks class and then invoke the hooks methods!

Install the extension in the default company and activate it for a non default company alone and then try to de-activate it and see if the tables get dropped.

Only the official dashboard extension has the drop sql in it.

Try to only install the dashboard extension (and not the theme) and then activate it and then de-activate it and you will see that the tables remain. At first I thought that it was to save the tables for a re-installation so that user changes are persistent but then most extensions drop the table if it exists before re-creating them during the activation phase and hence it gives us an illusion of having been deleted during deactivation unless the tables are checked just after deactivation.

The usage of XOR is may be standard even if not very widely used, but the usage of the hook_invoke by callback isn't where a simple if...else could have sufficed.

The real solution however, would be to make sure that the global $Hooks array gets pupulated earlier than this invocation and does not get overwritten thereafter. In fact, we have @kvvaradha to thank as this was investigated during the vetting of his hrm extension based on the dashboard skeleton.

It is pertinent to note that solution may lie in the fact that the extension install and uninstall works perfectly in includes/packages.inc wherein the $Hooks array gets populated with the active extensions in:

            if (($ext['active'] == true) && file_exists($path_to_root.'/'.$ext['path'].'/hooks.php'))
            {
                // we need to include the new hooks file to activate extension
                include_once($path_to_root.'/'.$ext['path'].'/hooks.php');
                foreach($db_connections as $comp => $db)
                    activate_hooks($ext['package'], $comp);
            }

Perhaps something like this should precede the hooks_invoke in admin/inst_module.php.