Problem:
The login was dropped every few screens, and in particular each time a main-menu tab was opened (index.php?application=...). Logging in again worked, until the next tab.

SessionManager stores the client address on the session and, in preventHijacking(), treats a different address as a hijack and wipes the session. Behind Cloudflare, REMOTE_ADDR is a Cloudflare edge address, and that address changes from one request to the next. The visitor has not changed. The next menu click looks like a hijack, and the login is cleared.

Solution:
I enabled a solution that works for all users as it currently does, but also for servers who use Cloudflare Orange.

What I changed:
1. The address stored and compared is the visitor address Cloudflare sends (CF-Connecting-IP), and only when the request also has Cloudflare's CF-RAY header. Both headers are required so a client who simply sends CF-Connecting-IP is not trusted.
Users who are not coming through Cloudflare orange-cloud, or through another proxy that sets those two headers, are not affected. A LAN client, or a WAN client hitting the server directly, has no CF-RAY header, so clientAddress() returns REMOTE_ADDR and the check is the same as before.

2. I removed the 5% random call to regenerateSession() on every request. That path is not specific to Cloudflare. On PHP 8, regenerateSession() (session_regenerate_id, session_write_close, then session_start again) drops the logged-in session on the requests where it runs. A real address mismatch still calls regenerateSession().

Code:
------
Replaced, in sessionStart():
$_SESSION['IPaddress'] = $_SERVER['REMOTE_ADDR'];

with:
$_SESSION['IPaddress'] = $this->clientAddress();

------

Removed, immediately after regenerateSession() in that same block:
// Give a 5% chance of the session id changing on any request
}
elseif (rand(1, 100) <= 5)
{
    $this->regenerateSession();
}

------

Replaced, in preventHijacking():
if ($_SESSION['IPaddress'] != $_SERVER['REMOTE_ADDR'])
    return false;

with:

if ($_SESSION['IPaddress'] != $this->clientAddress())
    return false;

------

Added, immediately above preventHijacking():
// Visitor address. Cloudflare's own address changes between requests, so the
// session is kept against CF-Connecting-IP when that request came through Cloudflare.
function clientAddress()
{
    if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']) && !empty($_SERVER['HTTP_CF_RAY']))
        return $_SERVER['HTTP_CF_CONNECTING_IP'];
    return isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : '';
}

------
After this, one fresh login stays put across the menu tabs. I'm happy for this to be adjusted if there is a preferred way to handle it in the next release.

The call shown in the error output is, for example:
date2sql('2025-01-01')

date2sql() obtains the current separator using:
$sep = $SysPrefs->dateseps[user_date_sep()];

and for the YYYYMMDD date format eventually executes:
list($year, $month, $day) = explode($sep, $date_);

user_date_sep() in includes/current_user.inc gets the separator from the current session:
return isset($_SESSION["wa_current_user"]->prefs->date_sep)
    ? $_SESSION["wa_current_user"]->prefs->date_sep()
    : $SysPrefs->dflt_date_sep;

Therefore the stale company A page submits 2025-01-01, while the current session expects /. This effectively results in:
explode('/', '2025-01-01')

which explains the warnings.
Expected result
A page generated in the context of company A should not silently be processed in the context of company B after the active session company has changed.
Ideally, each submitted form/request should contain enough information to verify that the company context in which the page was generated still matches the current session company. If it does not match, FrontAccounting should reject the request and ask the user to reload the page.
Why I think this is more important than the date parsing warning
The different date separators made the problem visible. If both companies had identical date settings, this particular request might apparently succeed and there would be no obvious indication that a page generated under company A was being processed using company B's current session context.
I have reproduced the context mismatch with Journal Inquiry. I have not tested submitting an accounting transaction from such a stale tab because I do not want to risk modifying the wrong company's data. Therefore I cannot say that cross-company writes are possible, but I think this should be checked because it could represent a data-integrity issue.
Version: FrontAccounting 2.4.20
I can provide a screenshot showing the complete PHP warnings and the stale Journal Inquiry page if useful.

They seem to focus on practical support and transparent pricing, which can be helpful for small businesses trying to stay organised with their accounts and tax obligations.

If anyone is interested, you can contact AffordBooksTax on (03) 7071 1180, 0416 339 239, or 0402 124 067.

They seem to focus on practical support and transparent pricing, which can be helpful for small businesses trying to stay organised with their accounts and tax obligations.

If anyone is interested, you can contact AffordBooksTax on (03) 7071 1180, 0416 339 239, or 0402 124 067.

I have 2 Supplier Transaction References set up.  1 with no prefix (generic payments) and 1 with a prefix (checking account and check number as a reference)

When entering a Supplier Payment, only the reference number is check for uniqueness, preventing references with the same number but different prefixes from being accepted.

It seems that the Supplier Payment form will return the Reference List (ref_list) index but not the prefix value.

Is there an easy way to allow duplicate reference numbers with different prefixes?
Thanks

Edit Invoice using posted Wiki
Results posted below.

0_audit_trail
('32595', '30', '6472', '1', '2026-05-06 07:17:23', NULL, '8', '2026-04-26', '0'),                    (Original)
('32596', '13', '6473', '1', '2026-05-06 07:17:23', NULL, '8', '2026-04-26', '0'),                    (Original)
('32597', '10', '6473', '1', '2026-05-06 07:17:23', NULL, '8', '2026-04-26', '0'),                    (Original)
*********************************************************************************************
('32595', '30', '6472', '1', '2026-08-15 19:30:10', NULL, '8', '2026-04-26', NULL),                    (Changed)
('32596', '13', '6473', '1', '2026-08-15 19:28:04', NULL, '8', '2026-04-26', NULL),                    (Changed)
('32597', '10', '6473', '1', '2026-08-15 19:28:04', NULL, '8', '2026-04-26', NULL),                    (Changed)
*********************************************************************************************
('34130', '13', '6473', '1', '2026-08-15 19:28:04', 'Voided.', '8', '2026-04-26', '0'),                (New Addition)
('34131', '10', '6473', '1', '2026-08-15 19:28:04', 'Voided.\nedit', '8', '2026-08-15', '0'),        (New Addition)
('34132', '30', '6472', '1', '2026-08-15 19:30:10', 'Updated.', '8', '2026-04-26', '0'),            (New Addition)
('34133', '13', '6772', '1', '2026-08-15 19:31:27', NULL, '8', '2026-04-26', '0'),                    (New Addition)
('34134', '10', '6771', '1', '2026-08-15 19:32:22', NULL, '8', '2026-04-26', '0'),                    (New Addition)
('34135', '12', '6769', '1', '2026-08-15 19:32:22', NULL, '8', '2026-04-26', '0');                    (New Addition)

0_bank_trans
('12920', '12', '6473', '4', 'CP260325', '2026-04-26', '165', '0', '0', '2', '217', NULL),        (Original)
**************************************************************************************
('13543', '12', '6769', '4', 'CP260621', '2026-04-26', '165', '0', '0', '2', '217', NULL);        (New Addition)

0_comments
('13', '6473', '2026-04-26', '260426 PayPal $4.93'),                    (Original)
('10', '6473', '2026-04-26', '260426 PayPal $4.93'),                    (Original)
('12', '6473', '2026-04-26', 'POS_VBC #6473'),                            (Original)
**************************************************************************************
('13', '6772', '2026-04-26', '260426 PayPal $4.93'),                    (New Addition)
('10', '6771', '2026-04-26', '260426 PayPal $4.93'),                    (New Addition)
('12', '6769', '2026-04-26', 'POS_VBC #6771');                            (New Addition)

0_cust_allocations
('6485', '217', '165', '2026-04-26', '6473', '12', '6473', '10'),        (Deleted)
**************************************************************************************
('6781', '217', '165', '2026-04-26', '6769', '12', '6771', '10');        (New Addition)

0_debtor_trans
('6473', '10', '0', '217', '214', '2026-04-26', '2026-04-26', 'Dn260325', '3', '6472', '165', '0', '0', '0', '0', '165', '0', '1', '1', '7', '0', '4', '0'), (Original)
***************************************************************************************
('6473', '10', '2', '217', '214', '2026-04-26', '2026-04-26', 'Dn260325', '3', '6472', '0', '0', '0', '0', '0', '0', '0', '1', '1', '7', '0', '4', '0'),     (Changed)
***************************************************************************************
('6771', '10', '0', '217', '214', '2026-04-26', '2026-04-26', 'Dn260623', '3', '6472', '165', '0', '0', '0', '0', '165', '0', '1', '1', '7', '0', '4', '0'), (New Addition)
***************************************************************************************
('6769', '12', '0', '217', '214', '2026-04-26', '0000-00-00', 'CP260621', '0', '0', '165', '0', '0', '0', '0', '165', '0', '1', '0', '0', '0', NULL, '0'),     (New Addition)
***************************************************************************************
('6772', '13', '1', '217', '214', '2026-04-26', '2026-04-26', 'DN260001', '3', '6472', '165', '0', '0', '0', '0', '0', '0', '1', '1', '7', '0', '4', '0');     (New Addition)

0_debtor_trans_details
('16227', '6473', '13', '101', 'Donation - Tithe', '165', '0', '1', '0', '0', '1', '8112'),        (Original)
('16228', '6473', '10', '101', 'Donation - Tithe', '165', '0', '1', '0', '0', '0', '16227'),
***************************************************************************************
('16227', '6473', '13', '101', 'Donation - Tithe', '0', '0', '0', '0', '0', '1', '0'),            (Changed)
('16228', '6473', '10', '101', 'Donation - Tithe', '0', '0', '0', '0', '0', '0', '0'),
***************************************************************************************
('17075', '6772', '13', '101', 'Donation - Tithe', '140', '0', '1', '0', '0', '1', '8112'),        (New Addition)
('17076', '6772', '13', '104', 'Donation - Building', '25', '0', '1', '0', '0', '1', '8536'),
('17077', '6771', '10', '101', 'Donation - Tithe', '140', '0', '1', '0', '0', '0', '17075'),
('17078', '6771', '10', '104', 'Donation - Building', '25', '0', '1', '0', '0', '0', '17076');

0_gl_trans
('40813', '10', '6473', '2026-04-26', '4011', '', '-165', '7', '1', NULL, NULL),        (Original)
('40814', '10', '6473', '2026-04-26', '1200', '', '165', '7', '0', '2', '217'),
***************************************************************************************
('40813', '10', '6473', '2026-04-26', '4011', '', '0', '7', '1', NULL, NULL),            (Changed)
('40814', '10', '6473', '2026-04-26', '1200', '', '0', '7', '0', '2', '217'),
***************************************************************************************
('42822', '10', '6771', '2026-04-26', '4011', '', '-140', '7', '1', NULL, NULL),        (New Addition)
('42823', '10', '6771', '2026-04-26', '4011', '', '-25', '7', '4', NULL, NULL),
('42824', '10', '6771', '2026-04-26', '1200', '', '165', '7', '0', '2', '217'),
('42825', '12', '6769', '2026-04-26', '1003', '', '165', '7', '0', NULL, NULL),
('42826', '12', '6769', '2026-04-26', '1200', '', '-165', '7', '0', '2', '217');

0_refs
('6771', '10', 'Dn260623'),
**************************************************************************************
('6768', '12', 'CP260620'),            (Original)
('6769', '12', 'CP260621'),            (New Addition)
('6772', '13', 'DN260001'),            (New Addition)
('1', '20', 'SI19001'),                (Original)
**************************************************************************************
('6402', '30', 'SO260002'),            (Original)
('6472', '30', 'SO260003'),            (New Addition)
('6530', '30', 'SO260003'),            (Original)
('18', '40', '101'),                (Original)

0_sales_order_details
('8112', '6472', '30', '101', 'Donation - Tithe', '1', '165', '1', '0', '0'),    (Original)
**************************************************************************************
('8112', '6472', '30', '101', 'Donation - Tithe', '1', '140', '1', '0', '0'),    (Changed)
**************************************************************************************
('8536', '6472', '30', '104', 'Donation - Building', '1', '25', '1', '0', '0');        (New Addition)

0_sales_orders
('6472', '30', '1', '0', '217', '214', 'auto', '', '260426 PayPal $4.93', '2026-04-26', '3', '1', '1313 Garbage Can Lane\r\nBoredom, XZ 12345', '', NULL, 'John Doe', '0', 'DEF', '2026-04-26', '4', '165', '0', '0'),    (Original)
***************************************************************************************
('6472', '30', '3', '0', '217', '214', 'SO260003', '', '260426 PayPal $4.93', '2026-04-26', '3', '1', '3520 Leith Street\r\nBoredom, XZ 12345', '', NULL, 'John Doe', '0', 'DEF', '2026-04-26', '4', '165', '0', '0'),    (Changed)

0_stock_moves
('8112', '6473', '101', '13', 'DEF', '2026-04-26', '165', 'auto', '-1', '0'),        (Deleted)
***************************************************************************************
('8536', '6772', '101', '13', 'DEF', '2026-04-26', '140', 'DN260001', '-1', '0'),    (New Addition)
('8537', '6772', '104', '13', 'DEF', '2026-04-26', '25', 'DN260001', '-1', '0');    (New Addition)

0_trans_tax_details
('12950', '13', '6473', '2026-04-26', '0', '0', '1', '0', '165', '0', 'auto', NULL),        (Original)
('12951', '10', '6473', '2026-04-26', '0', '0', '1', '0', '165', '0', 'Dn260325', '0'),        (Original)
***************************************************************************************
('12950', '13', '6473', '2026-04-26', '0', '0', '1', '0', '0', '0', 'auto', NULL),            (Changed)
('12951', '10', '6473', '2026-04-26', '0', '0', '1', '0', '0', '0', 'Dn260325', '0'),        (Changed)
***************************************************************************************
('13542', '13', '6772', '2026-04-26', '0', '0', '1', '0', '165', '0', 'DN260001', NULL),    (New Addition)
('13543', '10', '6771', '2026-04-26', '0', '0', '1', '0', '165', '0', 'Dn260623', '0');        (New Addition)

0_voided
('10', '6473', '2026-08-15', 'edit'),    (New Addition)
**************************************************************************************
('13', '6473', '2026-04-26', ''),        (New Addition)

From what I have found, the start of the upgrade path should be:
FA 2.3.19 -> FA 2.3.26 (old server)
FA 2.3.26 -> 2.4.1 (old server, includes database conversions)
But what then?

I assume at some point FA 2.4.X does not run on PHP 5.4 anymore and the next version 2.4.Y does not run on PHP 8.4 yet. I have not been able to find the PHP requirements for each FA version.

I think I need to find 2 versions of FA which
- use the same database format
- the older version runs on PHP 5.4
- the newer version runs on PHP 8.4
So I would export the database on the older version, followed by an import on the newer version.

Does that even exist? Or is there a better way?

Note: I use the Direct Goods Receipt Entry (D) method, not the Purchase Order Entry (B) method.

Any assistance would be appreciated.

Any thoughts?

I need help with the above issue. The VAT was mistakenly enabled which is not supposed to be. Just discovered it and we are trying to revert it cos the invoices already issued with the VAT are very very many about 7month duration. Some of the invoices have GRN on them.
Please how do I revert these VAT to Sales without having to modify them individually cos this will take several months to do. Invoice number is over One thousand.

Please help.

Thanks.

Popsicles12

Is that module is not update or something other reason.?

I am also downgrading the PHP version same issue.

I wanted to start a discussion around Xyli, a keyword that is gaining attention in different online communities and digital platforms. As industries continue to evolve rapidly, new terms like Xyli often represent tools, services, or concepts that improve user experience, efficiency, or accessibility in various fields.

Many users are curious about how Xyli (ไซไล) can be applied in real-world scenarios, especially in areas like online networking, digital services, and modern web-based platforms. With the rise of advanced technologies, such keywords often become part of larger ecosystems that focus on user convenience and better interaction.

One interesting aspect of Xyli is how it can potentially be integrated into platforms that focus on user discovery, communication, or service-based environments. Whether it is used for branding, system functionality, or digital identity, the adaptability of Xyli makes it a topic worth exploring.
Read more: fiwfan.app

I was installing the new 2.4.20 version and it could't finish installation

I'm using

MariaDB 10.4.32
PHP Version 8.1.25

The problem I notice is when the system tries to execute the script

CREATE TABLE `0_bank_accounts` (
  `account_code` varchar(15) NOT NULL DEFAULT '',
  `account_type` smallint(6) NOT NULL DEFAULT '0',
  `bank_account_name` varchar(60) NOT NULL DEFAULT '',
  `bank_account_number` varchar(100) NOT NULL DEFAULT '',
  `bank_name` varchar(60) NOT NULL DEFAULT '',
  `bank_address` tinytext,
  `bank_curr_code` char(3) NOT NULL DEFAULT '',
  `dflt_curr_act` tinyint(1) NOT NULL DEFAULT '0',
  `id` smallint(6) NOT NULL AUTO_INCREMENT,
  `bank_charge_act` varchar(15) NOT NULL DEFAULT '',
  `last_reconciled_date` timestamp NOT NULL DEFAULT '1900-01-01 00:00:00',
  `ending_reconcile_balance` double NOT NULL DEFAULT '0',
  `inactive` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `bank_account_name` (`bank_account_name`),
  KEY `bank_account_number` (`bank_account_number`),
  KEY `account_code` (`account_code`)
) ENGINE=InnoDB AUTO_INCREMENT=3 ;

the failure is because in the newer MariaDB does not allow this line   
`last_reconciled_date` timestamp NOT NULL DEFAULT '1900-01-01 00:00:00',

so in order to make it work change it to 
`last_reconciled_date` DATETIME NOT NULL DEFAULT '1900-01-01 00:00:00',

After I did it it works, hope I can help someone.