Search options (Page 132 of 246)

Check your upgraded db schema with that of the sql/en_US-new.sql and see what is different.

Look at the heading "View/set global locale for all users on a “CentOS/RHEL/Scientific Linux v5.x/6.x” and older" in the CyberCiti.biz link.

http://www.oag.go.th/en/home
http://www.thailawforum.com/database1/acconting-act.html
http://www.dbd.go.th/dbdweb_en/ewt_news.php?nid=3937
http://msnagroup.com/thai-accounting-law/
http://msnagroup.com/thai-accounting-standards/
http://www.thailand-business-law-center.com/thailand-tax-and-accounting-regulations-2/
http://www.ifrs.org/Use-around-the-world/Documents/Jurisdiction-profiles/Thailand-IFRS-Profile.pdf
http://www.fap.or.th/
http://www.iasplus.com/en/jurisdictions/asia/thailand

Looks like Thailand appears to follow International Accounting Principles.

Any Thai Accounting professionals would like to check out FA's features and comment on differences?
Any concessions / exemptions for the royalty or special privileged groups?

The reporting standards / requirements can be different everywhere - just build / tweak what reports you need. FA is an open system and can be extended at will.

Make sure that the access roles assigned to your other users have the requisite privileges for your activated application.
The password field stores the MD5 of the plain text password unless you have modified it.

Wiki-ed it.

The function user_use_date_picker () is not part of core FA 2.3 but in includes/current_user.inc in FA 2.4. Assume it is part of your module.

function user_use_date_picker()
{
    return $_SESSION["wa_current_user"]->prefs->use_date_picker();
}

The function get_js_date_picker is in FA 2.3 and FA 2.4 in includes/ui/ui_view.inc.

The version of the above function in FA 2.3 uses:

$fpath = company_path().'/js_cache/'.'date_picker.js';

whilst that in FA 2.4 uses:

$fpath = user_js_cache().'/'.'date_picker.js';

This is available in the Wiki too.

The line 74 in includes/errors.inc is:

    $bt = $SysPrefs->go_debug>1 ? get_backtrace(true, 1) : array();

Try to replace it with and see:

    $bt = (($SysPrefs->go_debug > 1) ? get_backtrace(true, 1) : array());

$go_debug is defined in config.php and gets into the $SysPrefs object is all is well.
The backtrace comes in correctly.

The line 85 in the same file is:

        error_log(user_company() . ":$user:". basename($file) .":$line:$context $errstr");

Try to replace it with:

        $msg_tmp = user_company() . ":$user:". basename($file) .":$line:$context $errstr";
        error_log($msg_tmp);

The function user_company() is defined in lines 425 - 430 in includes/current_user.inc:

function user_company()
{
    global $def_coy;
    
    return isset($_SESSION["wa_current_user"]) ? $_SESSION["wa_current_user"]->company : $def_coy;
}

Make sure that the user you logged in as exists in the company's database's users table.

Convert the least count as a unit and provide price per unit. Then translate that into tax % for that item.

FA v2.3.25 was released on 2016-02-21. Since then there have been many fixes. Please use FA 2.3.25+ which was last updated on 2016-07-26.

The errors you are getting possibly arise with incompatible php settings for your later version of PHP. What is your PHP/MySQL version and what platform and version is your server on (CentOS 6, Debian 8, etc)?

The offending line 295 in gl/gl_journal.php is:

    $_SESSION['journal_items']->add_gl_item($_POST['code_id'], $_POST['dimension_id'],
        $_POST['dimension2_id'], $amount, $_POST['LineMemo']);

The class member function add_gl_item is defined in includes/ui/items_cart.inc and it was last changed on 2014-09-22, much before the release of the version you are using. The file gl/gl_journal.php was last changed on 2015-03-15 and that too hasn't changed in your version. Hence it must be a generic issue of handling $_POST array's elements and that points to the newer PHP's idiosyncracies.

If the custom cron php file is in the FA web folder then anyone from outside too can execute it. Why would you want a security vulnerability?

If you wish to directly interact with the FA's DB tables, then write your own php file and keep it outside your webroot and include the relevant files like config_db.php, includes/db/connect_db.inc and operate on them directly.

If you wish to simulate a login and perform the FA's form based operations then use php cURL to achieve it. Teaching PHP is outside the scope of this forum.

Provide an example of what you wish to achieve and in which version of FA?

I shall assume you are working on FA 2.4RC1 with all fixes till date.

As for the 4 GL Accounts issue, check their entries in the db tables for any record / field differences other than account code and name. Also check their entries in the sys_prefs table if the mischief is in it's being set as some default.

As you are using PHP7, there seems to be a sticky post in announcements that could be useful.

Counterparty is just the contra account in a transfer transaction. It can be between 2 bank accounts or even between some balance sheet entries and P&L entries like in depreciation entry transactions apart from the ones you already mentioned.