It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by apmuthu
All fixes since the release of FA v2.3.22 are attached herein. No DB schema changes.
Only critical backports will be done for v2.3.x henceforth.
For backports and mods visit FAMods in my unofficial GitHub folder.
FA v2.4 is now installable for new instances and development is rapidly progressing.
@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.
Refer Tips and Tricks in the Languages page in the FA Wiki and search the forums as well.
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.
Spot on! That's the right way for human readability. But... linux has a patch command to auto-magically traverse thru the folder tree and apply such "diffs" (can be generated from WinMerge - Unified Diff and adjusting for CRLF=>LF UnixDos differences in line endings).
Since there was one other key in the table that mimicked the first part of the proposed new re-arranged Primary Key, we call it a redundant index and have it removed.
Making a new CoA from the en_US-new.sql will be the right way to proceed. The one in my updated FAMods folder has all the changes necessary. You need to change the order of currencies and their default id and rate value to 1 for the home currency making it the first one and the default currency in the users table and in the sys_prefs tables' data. If you add new account heads then space them numerically in steps of 10 or 5 and huddle them together logically for ease of sifting thru later. You may also want to adjust the fiscal_years table to suit your current and future installs.
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.
Please refer Forum Post and let us know if it fixed it for you.
The "id" field instead of the "component" field was being compared till now for "update_bom()" function!
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.
This has now been wiki-ed.
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.
@cambell: I understand your development convenience.
CSS files that need tweaking in one version will need to be "re-tweaked" in subsequent versions for end users and the locations in the concatenated css file will then have to be traced back to it's source fragment file each time. The alternative would be to include a file that includes all these files in turn. I have used such in-situ testing of CSS in FireFox's FireBug feature and found it cumbersome - YMMV.
Also if there are too many files that need tweaking in the core, see if they fit a pattern to be included from a single file. They could be functions and / or template code. See what is the easiest way to merge the two together so that we can work from a common core.
A sort of a $Is_Mobile_Theme variable ....
on the lines of RTL ...
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".
@cambell: Whilst the development of the theme will benefit from such splitups of more/less code, the releases for end user usage and feedback / troubleshooting / fixing code may prove to be cumbersome if it is needs to be back referenced to the original files that made up the file being investigated.
Have you made any fixes to the code to achieve this that you would like to submit here in?
FA v2.4 is now installable for new instances. Follow it on this post.
Anyone can verify this claim?
You're right. Maybe we need a last document customer change option as most such errors are realised the moment we hit the enter button!
There are many ways an invoice can be entered. The most common place such an error would arise is in a Direct Invoice entry or in a Sales Order Entry since that is where a Customer is chosen and everywhere else it gets carried over from the parent document, we need to have:
1. Change Last Invoice Customer
2. Change Last Sales Order Customer
It should address the wrong defaults for address and other contacts and references that may have been entered.
... provided no payments / credit/debit notes have been made in the meanwhile!
If the said invoice/sales order got emailed to the wrong customer entered ......
There is an Invoice edit option ......
Install from the snapshot and then apply the mods and see what breaks - tmp/errors.log and apache error logs.
Check out Dimensions, Tagging and sub ledgers for addressing your needs. The FA Wiki is your friend and these forum posts are your treasure trove.
Void the invoice and create a new one - invoices change a whole lot of entries in various tables.
If you had taken a backup before and after the transaction then the diffs of the sqls can be used to change them.
Alternatively, take an sql backup before and after a new transaction and then study the differences and extrapolate it for the target invoice.
I have wiki-ed the discussions here starting from your first post here to help others taking their first steps in FA(iry) Land.
This appears specific to Canada - GIFI.
FA v2.4 changes:
most $_POST['xxx'] => get+post('xxx')
some $_POST['xxx'] => check_value('xxx')
blank strings => ALL_TEXT
All MyISAM tables now InnoDB
All closing php tags removedQuite a few blank strings will need the ALL_TEXT replacements for easy readability. Some are single quoted and others are double quoted. Some are preceeded by == and others by !=.
Like most of the constants, ALL_TEXT is defined as a blank string in includes/types.inc file.
function check_value() is in includes/ui/ui_input.inc and checks if the $_POST element has been set (isset()).
function get_post() is in includes/ui/ui_controls.inc and retrieves the $_POST element's value if it exists or returns the second argument if it exists or a blank string.
Some good constructs like:
if (isset($order_number) && $order_number != "") have got changed to
if ($order_number != "") This snapshot has been tested to install correctly both for the en_US-new.sql and the en_US-demo.sql CoAs. A few of the reports have been tested and appear to be working (sample attached).
The version of FA 2.4 as on date is now installable (only fresh installs) without any errors.
1. Delete company/2 folder and reset your credentials in config_db.php so that the counter - $tb_pref_counter - is set back and the array element for the second company is removed.
2. Empty (not truncate or drop) the database used for the company 2.
3. It is best to use a separate database for each company
4. The database should already have been created, a user privileged for it and privileges flushed.
5. Now test your CoA sql that it has no create database and use database statements and conforms to the standard en_US-new.sql format. Manually executing it on the target database and then emptying it out on successful execution is one way to fish for errors.
6. Login to default company as admin
7. Create your second company all over again, logout and login to the second company and go ahead.
All companies by default have the same administrator username of "admin" on creation. The username can only be changed in the database - phpMyAdmin / SQLyog. Within the FA Web UI, another administrator roled user can be created and then logged in using that and then the original one deleted but I do not know what will happen if some stupid script was to assume that user id 1 should always be admin!
The company name given during company creation is the one in the dropdown list during login that determines which db and FA company will be used. This info is stored in the company's entry in config_db.php. For security reasons, there is a variable in config.php - $text_company_selection - that can be set to make the dropdown box to a text box for manual entry.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.