Search options (Page 153 of 247)

There is a constant defined as FLOAT_COMP_DELTA - see if it affects your values. Check it's appearance in purchasing/includes/db/suppliers_db.inc under function get_supplier_details() for the sql statement's WHERE clause:

"AND ABS(trans.ov_amount + trans.ov_gst + trans.ov_discount) - trans.alloc > ".FLOAT_COMP_DELTA

A similar code fragment is in purchasing/includes/db/supp_trans_db.inc in function get_sql_for_supplier_inquiry() apart from other files.

My repo has been committed with this fix.

Yes, that is the solution!

When $qoh is 0, only the new qty should dictate the material cost and not add to it.

@joe: please correct it in the stable version:

manufacturing/includes/db/work_orders_db.inc line 48.

The patch which includes proper initial sorting of Work Orders as well is:

--- old/manufacturing/includes/db/work_orders_db.inc    Sun May 10 02:37:36 2015
+++ new/manufacturing/includes/db/work_orders_db.inc    Sat Oct 10 00:40:29 2015
@@ -45,7 +45,7 @@
     if ($qoh + $qty != 0)
     {
         if ($qoh == 0) // 27.10.2014 apmuthu and dz.
-            $material_cost += $m_cost;
+            $material_cost = $m_cost;
         else    
             $material_cost = ($qoh * $material_cost + $qty * $m_cost) /    ($qoh + $qty);
     }
@@ -555,6 +555,7 @@
 
         $sql .= " AND workorder.required_by < '$Today' ";
     }
+    $sql .= " ORDER BY workorder.id DESC";
     return $sql;
 }

Did a sql_trail for the Direct purchase Invoice (turned on in the config.php file just before the "Process Invoice" button was clicked) and there were 144 SQL queries!
SELECT = 100
INSERT = 21
REPLACE = 3
UPDATE =  18
One BEGIN and One COMMIT.

It appears that each line item (stock_id) rate in the purchase Direct Invoice form populates the stock_master.material_cost and purch_data.price (for the specific supplier_id) fields even if it already exists and has not changed. It must certainly be here that something is going wrong.

The following SQL run on the FA db would yield the necessary sequence of SQLs that were executed:

SELECT id , `result`, msg, REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(`sql`, '&#039;', "'"),'&lt;','<'),'&gt;','>'),"\n",""),"\t",""),"\r","") AS SQL_used FROM `0_sql_trail`

The file purchasing/includes/db/grn_db.inc has the function update_average_material_cost() that provides the material cost for computations in other files. Must see if there is any anomaly here - missing scope/vars, etc.

The value of the $_POST variable just before Work Order Add just before executing line 264 in manufacturing/work_order_entry.php is:

Array
(
    [wo_ref] => WO11
    [type] => 0
    [_stock_id_edit] => I3
    [stock_id] => I3
    [StockLocation] => DEF
    [quantity] => 1
    [date_] => 09/10/2015
    [Labour] => 3.00
    [cr_lab_acc] => 1060
    [Costs] => 2.00
    [cr_acc] => 1060
    [memo_] => 
    [RequDate] => 
    [ADD_ITEM] => Add Workorder
    [_focus] => wo_ref
    [_modified] => 0
    [_token] => a8c1a6693552df346a1fd03d90b1287e8c32cd276dfc60712b91f2154ef04926
    [_random] => 700059.4337549664
)

Only the last 2 elements change on WO Addition.

Check if it is a browser issue and / or date ranges / cache issue.

Server and client platform and versions,
php and mysql versions,
fa version ans Chart used.

... will be needed to assist you.

Which FA v2.3.24 are you using? Take the Post Release, the v2.3.24+ which is on the GitHub Repo Master.

Please let us know if the problem persists.

Please state what version of PHP/MySQL and what Chart of Accounts you are using and on what platform/version.

Attached herewith is a PDF of your article. A couple of mail-> lines above the code snippet referred to will also need to be changed suitably.

Using the Autoload may not be recommendable as it might cause multiple classes out of context to overload one another. Including just the files used like lass.phpmailer.php  (and others if used) may be better off. Better still would be to include it in another replacement file class.mail.inc where the latter's methods and properties can be aliased.

Yes, that was fast - even on a Sunday - wonder why it happened on a Sunday in the first place.

GitHub has restored the public viewing of my repo.

Notification of the restore:

Hi there,

I'm sorry about our naughty robots - they mistakenly flagged your account as spammy. They do a good job but can be a bit overzealous at times.

I've just unflagged your account and you are all set!

Don't hesitate to ask if you have any questions.

Thank you!

First off, the current callback method of deactivating the extensions is simply not working as far as the dropping of the extension's tables are concerned - wonder when was the last time it worked, if ever.

Lines 213 to 225 of the current admin/inst_module.php file are:

    foreach($exts as $i => $ext) {
        if ($ext['package'] && ($ext['active'] ^ check_value('Active'.$i))) {
            if (!$ext['active'])
                $activated = activate_hooks($ext['package'], $comp);
            else
                $activated = hook_invoke($ext['package'], check_value('Active'.$i) ?
                 'activate_extension':'deactivate_extension', $comp, false);
            if ($activated !== null)
                $result &= $activated;
            if ($activated || ($activated === null))
                $exts[$i]['active'] = check_value('Active'.$i);
        }
    }

The second line (first if) above has an XOR (^) which means that the code fragment is executed only if either

1. the extension was already active or

2. the activate extension checkbox has just been ticked and submitted

but not both.

The second "if" activates the extension using the direct function activate _hooks() if it was inactive which because of the XOR condition above would mean that the activate extension checkbox had just been ticked. This works correctly and the module gets installed. However, this does not happen through the callback portion of the hook_invoke() function through which it is never called. The use of the direct function activate _hooks() was necessary since the value of the $Hooks global array variable is empty when it enters the activate_extension() method by callback if the hook_invoke() was used.

The "else" of the second "if" triggers the callback only for the deactivate_extension() method when the activate extension checkbox has just been unticked whilst the extension was active. Here, the value of the $Hooks global array variable is empty when it enters the said deactivate_extension() method which exits without executing the deactivation sql if any. It is for this reason that the new direct function deactivate_hooks() was used to do the job.

The esoteric callback method in hook_invoke() seems to make the code quite a bit of a challenge for the average user to comprehend and I was initially blinded to conclude that the said deactivate_extension() method was never called. We should try to use simple and easy to understand constructs for ease of debugging / troubleshooting by the average user for mass trusted adoption.

Steps to reproduce:
1.  Install and activate for one company any extension (currently, only dashboard extension has a drop sql separately) that creates tables and has a means to drop them as well. Alternatively create an extension that only creates one table and then on deactivation drops that table and then install and activate it for one company.
2. Now choose to deactivate it for the company for which it is currently active.
3. Check and find that the newly created table(s) have not been dropped despite deactivation.
4. Use my new function method and then repeat the steps above and you will find successful deactivation with the newly created table(s) dropped.

If verification is the reason, then an Ajaxable local label display on dropdown selection change should suffice.