Refer Wiki.
Setup => Company Setup - Screenshot
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
Refer Wiki.
Setup => Company Setup - Screenshot
On 2014-01-17 there was a fix for it.
Run and Rerun. voiding an allocated currency invoice doesn't clear FX account
http://devel.frontaccounting.com/git/?p=fa-stable.git;a=commit;h=5ea4d80a91017eadba9db43a0f26242c57bc4c9e
http://devel.frontaccounting.com/git/?p=fa-stable.git;a=commit;h=8d564a2cbca92c71738d933813ac4985e15488e4
Try your issue with the latest codebase - v2.3.25+ and see if your error persists.
Which version / build of FA are you using?
The rep107 is for the invoice. Just before output of the invoice make a copy of the $pdf object. In the copy of the invoice, make changes to the invoice header where the "INVOICE" is replaced with "COPY INVOICE" and append it to the original in a new page and then output it. Alternatively create an "Add Page" at the end of the $pdf rendering and copy the code that created it into the new page and edit as needed before outputting.
@itronics: Actually I was puzzled by how a length of a string returned by strspn() could be used though the logic was clear. Thanks for the fix.
@joe: Thanks. No backport needed as too many reports change.
Can refer this commit in the wiki for those with such edge cases in FA 2.3.
You must make the version of your package 2.4.something....
includes/packages.inc has at it's last function check_src_ext_version($ext_v) which has lines 725-741:
/*
Check basic extension source compatibility.
*/
function check_src_ext_version($ext_v)
{
global $src_version;
$compat_levels = 2; // current policy is keeping compatibility on major version level.
$app = explode('.', strspn($src_version, "0123456789."));
$pkg = explode('.', strspn($ext_v, "0123456789."));
for ($i=0; $i < min($compat_levels, count($app)); $i++)
if ($pkg[$i] < $app[$i])
return false;
return true;
}
This function returns true only if the package version (at major level 2) is greater than or equal to that of the FA version.
The $SysPrefs->version (or if absent, the $src_version) in version.php is used as the FA version.
The admin/inst_module.php at line 215 checks the above before the said warning / error arises:
if (check_value('Active'.$i) && !check_src_ext_version($ext['version']))
This must be borne in mind when developing / updating modules in FA v2.4.
In FA v2.3, only a check for previous version < current version of the module was done.
For a test just replace your code with that from sales/inquiry/sales_orders_view.php and see if it displays correctly from your position in the code tree.
typo:
funtionp1val => functionp1val
We need to know what is in the functionp1val() as well. Are there any variable missing scope?
Try calling the function ordinarily and see if the values are available.
Please state which report - "Balance report" is ambiguous. Also use the latest version of the report after ascertaining the changes there in and it's dependencies and see if the error persists. Using old version is not recommended. PM me for upgrades if you cannot get it done. Your version was released on 2013-02-14.
The list of changed files are attached. There may be database changes needed. Extensions and code modifications in your base install may need to be upgraded / ported.
The Banking -> Bank Statement report file is reporting/rep601.php. Change it's line 75 (in current version - check for your version):
$cols = array(0, 90, 110, 170, 225, 350, 400, 460, 520);
to:
$cols = array(0, 90, 120, 170, 225, 350, 400, 460, 520);
Each element in the above array represents the starting character column for the font used in sequence for the various headings in the array $headers assigned thereafter.
@joe: Actually, this can be made the standard (as appropriate for other reports as well) since a 4 digit transaction number will be quite common.
FA 2.4 RC1 was released on 2016-02-23. Since then there have been several fixes attached here.
Potential issues with language changes from disparate charsets is discussed here. In most instances it will need a removal of Byte Order Mark (BOM) from the core files. This generally affects windows users on distributions like WAMP.
Using FA v2.3.25+ with PHP version < 5.6 is recommended for production.
Check the value of the variable always_populate_raw_post_data in your php.ini in PHP 5.6 when your errors come.
Increase the timeout value for script execution and input time in php.ini for bigger results.
Try to make the addition of p1+p2 in the sql statement itself.
List the function get_prodlist() here to see if anything is amiss.
See if $result displays a validly executable sql statement when it is assigned.
Make sure that the $result is just an sql statement and not the executed resultset.
Check out the last part of sales/inquiry/sales_orders_view.php as an example.
All standard Report form controls are listed in function get_ctrl() in reporting/includes/reports_classes.inc and there is no PreFormattedInvoicePDF selection control listed there and hence it needs to be hardcoded into a header file that needs to be included in the actual repXXX (rep107.php for invoice) file. Using TCPDF's background PDF feature will be one possibility.
@itronics: an example of pre-formatted PDF included invoice will be useful.
In PHP v5.6 onwards this behavior is so. Restart the webserver after including the following line in the php.ini file:
always_populate_raw_post_data = -1
The caveat for the above would be an inability to upload files as discussed here. The newer recommended construct for Ajax is to use php://input stream that does not have the above issue.
If you are using the latest code from GitHub / SF Git, (for FA v2.3.25+) you will find HTTP_RAW_POST_DATA is so in line 264:
$rawPost = strcasecmp($_SERVER['REQUEST_METHOD'], 'POST') == 0? (isset($GLOBALS['HTTP_RAW_POST_DATA'])? $GLOBALS['HTTP_RAW_POST_DATA'] : @file_get_contents("php://input")) : null;
Try the MySQLtuner to adjust the server parameters and rebuild the indices.
You might want to optimise your FA db using my FAMods with upgradation caveats.
Closing and deleting previous years after suitable backups will improve usage latencies.
The includes/db_pager.inc already has the efficient LIMIT clause in line 326:
$sql .= " LIMIT $offset, $page_len";
@cambell: I just wanted to minimise the differences between the core file and the modified one (sans white space diffs as well) so as to focus on the main code changes. Porting it to FA 2.3 requires removal of FA_Assets based code and replacing functions and variables with their older counterparts.
How is FA 2.4 in terms of stability - is it ready for production use yet?
Was the move to InnoDB for all tables justified?
Check the list of Debtor balances in the trial balance and see if there are any discrepancies with actuals. It is possible that some opening balance entry before start of operations is the cause of this unless some inadvertent direct db intervention deleted / inserted some entry.
Make a "dummy" payout to (Dr) / deposit from (Cr) the relevant debtor in FA to annul the opening balance. make it at the end of the previous fiscal year if it remains open or at the beginning of the current fiscal year otherwise. Your Cash/bank balance would take the contra ( adjust reality with it - pocket the difference or pay it in ). Alternatively, a Journal Voucher may do it.
The .txt files are the relevant tax tables subset of the sql backup - before and after fixing. They may be viewed in a diff program like WinMerge in Windows to see what changes occurred in the db to get it fixed.
The .sql file is to directly execute in a mysql client like SQLyog, phpMyAdmin, etc if you wanted to set it right without entering in the FA's web UI.
If you followed the screenshots, then you can ignore the .txt and .sql files. They are there for studying the issue and alternative means of fixing for the "gifted and lazy" sysadmins....
@cambell: Refer lines 41,42 of your patch. Any reason for replacing the original $_GET['ModifyOrderNumber'] with $_POST['trans_no']? Also does the order of the root path statement affect the file? The patch to your modded file in my previous post will provide for minimal diffs from the core file.
Attached is the series of screenshots and those needed to correct it from the FA Web UI. Tax exemption are not taxes leviable. Item tax exemptions are for item based exceptions only.
References:
https://frontaccounting.com/fawiki/index.php?n=Help.TaxTypes
https://frontaccounting.com/fawiki/index.php?n=Help.TaxGroups
https://frontaccounting.com/fawiki/index.php?n=Help.ItemTaxTypes
Sample diffs to sgw_sales/sales_order_entry.php to isolate real changes from sales/sales_order_entry.php in FA v2.4.RC1+ to make porting to FA v2.3.25+ easy.
This module installs correctly in FA 2.3.25+ but the 3 menu links in it lead to blank pages.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.