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
The dashboard theme must be installed
and then the dashboard extension as well
and then activated too.
Backup before installing them.
If you are upgrading,
take a backup,
then de-activate the dashboard extension,
choose a normal standard theme and
uninstall the dashboard theme and extension.
Now upgrade the FA, install the dashboard theme and extension and activate and choose them. Import your reminders selectively from your backup.
No
Check the same type of transactions in the demo Chart of Accounts and see what difference it makes. State FA version / build.
Which version of FA are you using? Which supplier did it generate a credit for? The utilities account should not be a supplier if you do not wish to track inventory and payments. It should be a general expense account. Check your Chart of Accounts.
The detailed search on specific columns of database need to be designed. Most common ones are already there.
@trecords: Use the latest version 2.3.25+. State your Browser/Server/Platform/PHP versions. Clear cache of browser.
@ericgroen: Clear cache of browser. Test with latest version and provide feedback.
Refer Wiki and Forum Post.
Please check if the error still persists in the latest FA code so that it can warrant inspection. The URLs listed (amongst others) may have changed the functionality that may have cleared the error.
@joe: is this by design?
The debtor_trans_details table has the rate info.
The field debtor_trans_type's value of 10 needs to be taken as it is the ST_SALESINVOICE, whilst the value of 13 represents the actual ST_CUSTDELIVERY. By filtering the field as needed for either price history based on invoice (10) or delivery (13) you can make a report based on other report templates / report extension modules. Take care to remove entries matching transaction numbers' items for voided entries.
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.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.