Search options (Page 1 of 246)

I do not know of what changes PHP 8.x will have on these extensions. Also, if there is no Banking Transactions in the said list and the Journal Transactions did not suffice, the error logs with debug on should provide some pointers. If you consider my suggestions as a tangent then please seek professional assistance in the Job Offers board. Using the audit trail is another method of viewing the various SQL queries that get traversed through during it's execution.

I maintain the unofficial extensions repo as it has some third party extensions also, not officially vetted as yet to serve as a self help resource. Also I make sure that the white space in the changed code is synched with those in the core and official code base to make for ease of troubleshooting and development.

My requests on the board and its archives have not elicited any response from the original developers of the extensions till date. Nor have any users listed the way they have solved the issues at hand in the forum and in the wiki as far as I know.

Just checked. This has been the default since the very beginning over 15 years ago.

Tested with Debian 6 and MySQL 5.1 and PHP 5.3.3 and all worked well.
If adding a user was a real problem practically all major users of FA would have complained by now.
Single stepping and watch points and debug_status are the way forward.

Which version of PHP/MySQL are you using?

Looks like the de-activation of the linked bank account is not being updated in the database presumably if there are transactions dependent on it.

This error is effected in line 87 (in current FA version) of gl/manage/gl_accounts.php.
Lines 89-94:

            elseif (update_gl_account($_POST['account_code'], $_POST['account_name'], 
                $_POST['account_type'], $_POST['account_code2'])) {
                update_record_status($_POST['account_code'], $_POST['inactive'],
                    'chart_master', 'account_code');
                update_tag_associations(TAG_ACCOUNT, $_POST['account_code'], 
                    $_POST['account_tags']);

need to succeed.

Furthermore, the table 0_bank_accounts too needs to have the inactive field set as needed and refreshed for the session variables to be updated. From line 282, the function is_bank_account($account_code) has been defined in gl/includes/db/gl_db_accounts.inc.

Hence the specific version of MySQL when queried may be returning a NULL instead of 0 for the inactive field or the get_post() part of the html response may not be of the type expected in the browser / PHP version used.

@joe: Any checks in the code that is preventing it?

You will have to make the 2024 year as the active year and then close the 2023 year.

Closing the dummy year will forward the closing balances to the new years' opening balances.

Please note that all partial transactions will be abridged into the opening balances unless the dummy year had details of individual transactions that were to be finished in the new year.

Check if negative values are allowed in the settings.

Increase the number of max_input_vars in the php.ini apart from max memory size.

Check your PM where I answered your queries.

Search for the code where the amount comes in as red and prevent it from making an invoice there.

The Credit Limit is set in the table #_debtors_master.credit_limit and the credit_status field therein shows the ID of the record where #_credit_status.disallow_invoices field has the binary switch.
There is a similar field as #_suppliers.credit_limit too.

Check if you find something in red in such an invoice when the amount is reached.

Check out the tutorials from IIT Mumbai - Spoken-Tutorial

Use the Indian CoA and place the file in the FA Webroot/sql folder and create your company with it from the derfault company.