Search options (Page 185 of 246)

That is nice feedback indeed and has been wiki-ed as another way to troubleshoot it and possibly incorporate these fixes in future versions of the extension/theme.

Please elaborate it on the Wiki where this has been listed.

@joe: In fact a few posts earlier, we found that the thread evolved into a FA Setup Tips topic and I wikied it as such for want of some forum feature to fork a part of it as a separate topic... This new topic can begin with the 13th post in this thread onwards.

For those who partook of my fix in the 35th post in this thread can now update it with the superceeded commit.

Put all your custom reports in the company/#/reporting folder if you want it for a specific company alone. There will also be a need to put in form parameters for the report in the reports_main.inc file. Have a look at how the reports are made in the existing extensions expanded out in my GitHub repo.

You will nevertheless need the fixes in my previous post as the error in update_bom() will show up when used.

Study the backup file sql and compare it with the original and see where Navicat (that specific version/build) falters. It is possible that your Navicat install expects the keyword "FOREIGN KEY" instead of the plain and possibly ambiguous "KEY" or it is expecting the equivalent "INDEX", in which case it is likely to affect quite a few tables!

The entire fix is now in the FAMods in my GltHub repo.

Try making it:

  PRIMARY KEY  (`parent`,`loc_code`,`component`,`workcentre_added`),
  KEY `component` (`component`),
  KEY `id` (`id`),
  KEY `loc_code` (`loc_code`),
  KEY `workcentre_added` (`workcentre_added`)

to remove redundant indices but that is not the fix.

The fields parent and component refer to stock_id which is varchar(20) in the other tables and hence these two should be varchar(20) too but that should not generally be the cause of any problems except for type matching and index based joins.

The following sql will achieve the above changes:

ALTER TABLE `0_bom` 
    CHANGE `parent` `parent` VARCHAR(20) DEFAULT '' NOT NULL, 
    CHANGE `component` `component` VARCHAR(20) DEFAULT '' NOT NULL, 
    DROP INDEX `parent`, 
    DROP PRIMARY KEY, ADD PRIMARY KEY (`parent`, `loc_code`, `component`, `workcentre_added`); 

The file / function that is in error is:

includes/db/manufacturing_db.inc => update_bom()

function update_bom($selected_parent, $selected_component, $workcentre_added, $loc_code, $quantity)
{
    $sql = "UPDATE ".TB_PREF."bom SET workcentre_added=".db_escape($workcentre_added)
     . ",loc_code=".db_escape($loc_code) . ",
        quantity= " . $quantity . "
        WHERE parent=".db_escape($selected_parent) . "
        AND id=".db_escape($selected_component);
    check_db_error("Could not update this bom component", $sql);

    db_query($sql,"could not update bom");
}

should be

function update_bom($selected_parent, $selected_component, $workcentre_added, $loc_code, $quantity)
{
    $sql = "UPDATE ".TB_PREF."bom SET workcentre_added=".db_escape($workcentre_added)
     . ",loc_code=".db_escape($loc_code) . ",
        quantity= " . $quantity . "
        WHERE parent=".db_escape($selected_parent) . "
        AND component=".db_escape($selected_component);
    check_db_error("Could not update this bom component", $sql);

    db_query($sql,"could not update bom");
}

The only two functions there that use the id field in the 0_bom table are:

• delete_bom()

• get_component_from_bom()

*** The fix listed above for the file manufacturing_db.inc is not correct ***
It has been superceeded by a later commit in my GitHub Repo. - Thanks @itronics for pointing me in the right direction.

When you do some testing see if you want to try this patch which is a backport from FA v2.4 where some legacy bugs are aslo fixed.

--- old/sales/customer_payments.php    Mon Sep 29 21:21:28 2014
+++ new/sales/customer_payments.php    Wed Jan 07 00:24:14 2015
@@ -54,6 +54,7 @@
         if($inv) {
             $_SESSION['alloc']->person_id = $_POST['customer_id'] = $inv['debtor_no'];
             $_SESSION['alloc']->read();
+            $_POST['BranchID'] = $inv['branch_code'];
             $_POST['DateBanked'] = sql2date($inv['tran_date']);
             foreach($_SESSION['alloc']->allocs as $line => $trans) {
                 if ($trans->type == ST_SALESINVOICE && $trans->type_no == $_GET['SInvoice']) {
@@ -247,9 +248,6 @@
 //    unset($_POST['branch_id']);
     $Ajax->activate('BranchID');
 }
-//if (isset($_POST['_DateBanked_changed'])) {
-//  $Ajax->activate('_ex_rate');
-//}
 
 //----------------------------------------------------------------------------------------------
 

The progress of this thread exposes how much I took for granted that anyone would be able to adopt the full disclosures on my GitHub Repo inspite of the regular cross referencing of the wiki to the forum posts.

Please be aware that some files should be uploaded together.

The ones in the company folder are not required if you do not want to use the extra info option (CID, BinLoc) which enables the printing of the Branch ID (either external lookup Branch ID in the notes field or in it's absence, the branch_code field)  and the Bin Location in the long_description field in the Packing List report. It is explained in the Wiki Page for Bin Location in FA.

The admin backups file is used to provide extended functionality for backup file renaming and for execution of various linux commands and outputting the results in the browser. It is discussed in this post.

There is also some code (header2.inc) to display a pretty PayPal link in the Invoice - discussed in this post and later updated in my repo.

Congrats. You are making exemplary progress indeed inspite of our "half way across the world timezone human latency".

Have you made any fixes to the code to achieve this that you would like to submit here in?

Anyone can verify this claim?