Thank you for taking the time to consider this.

I am not clear on what I am checking for "zero date time settings"

Debug didn't show me anything related to being timed out.  Just SQL queries that seemed normal.

The timezone on the server is 3 hours behind my local time.  I have set the config.php to use my local timezone (not the server timezone).  Is this correct? Or should I do the reverse?

Unfortunately my server has deprecated anything less than php 7.x at this time.

I have seen this issue posted before. I didn't have it until my host (Dreamhost) updated PHP to 7.x. I am currently running on 7.2 (FastCGI)

I have tried the following:

-Commenting out anti-hijacking code in sessions.inc
-Removing .htaccess file
-increasing timeout to 999999 in company setup.

At this point I am at a loss as to why every few clicks the application forces me to relog.  Once I relog, it takes me to the screen i needed to be in.  This has really slowed down my workflow so hoping for some new things to try.

Thanks for your consideration of this problem.

I just wanted to add, I totally get the need to segregate duties and why FA does what it does.  I probably should have understood the FA workflow better.  It is good policy to have a different person handle the banking side while some else does the entry.  However, the fact that the customer payment option allows the orders clerk to mess with the bank could be the main issue.

I would think the a large user base (bookkeepers, accountants, entrepreneurs) of FA would benefit from tighter workflow control between modules and the general ledger.  For instance, the accounts payable module (or "Suppliers" in FA) should fully and exclusively control the accounts payable G/L account.  This means users would not easily be able to post normal journal entries, bank entries or otherwise into the accounts payable G/L account. The controlled way to post would be through the module itself.  This fully integrates the additional accounting data that the A/P module stores with the balance sheet.  This would be as simple as preventing "foreign" module entries (entries not from A/P in this example) from being permitted to post into the linked G/L account. This has many benefits to the user as there will be fewer mistakes, less time reconciling inter-module entries with reports, a fully support balance sheet account, and more time getting info and making money.

The implementation would have to incorporate logic to G/L accounts to lock them to certain modules. I can't help you there. sad

This request is a result of a recent experience I had where I made a mess of things in my A/P and A/R accounts by posting "Bank Deposits" and "Bank Payments" referencing customer/supplier accounts.  All of my A/R and A/P reports were a complete mess and didn't agree to the Balance Sheet! I ultimately ended up wiping the supplier transaction table in phpmyadmin. I then created a special item in the inventory module with a cost account of accounts receivable. Any invoices using this item would make a journal entry debiting and crediting the same amount in the accounts receivable account but would show as "outstanding" in the aging reports. Then I rebuilt the report after spending hours manually reconciling in excel these accounts.  In reflection, I probably could have avoided the damage I might have done in phpmyadmin by just posting an open item equal to all settled invoices and apply all the loose payments from the bank module.  Ah well.  I am now disciplined in FA to catch myself from posting to A/R or A/P in any place but their home modules.

I hope you consider this feature as I believe it will add something of value to every user and seems like it might be something you folks could definitely do considering the tremendous quality of this project.

Hello everyone.  I really like Front Accounting and have been using it for a not-for-profit that I work with.  I have noticed something about the bank reconciliation report that isn't obvious at first but it quite tiresome.

If I perform a bank rec,say in January, and two transactions were not cleared at that date, the report will indicate this by not having a "clearing date" next to it when the transactions are listed for that month. 

The problem becomes apparent on the NEXT reconciliation.  Say that there are two more transactions in this rec that have not cleared, and the ones from January have still not cleared.  The report will show the CURRENT transactions that haven't cleared but I have to go back to January to figure out why it still doesn't reconcile.  In month three, this becomes more tiresome and so on.

Basically a report should just have 3 sections. 

Section 1 - G/L Bank balance compared to Statement Bank balance (the current report does this)
Section 2 - Transactions reconciled this month (the current report does this)
Section 3 - All un-reconciled transactions up to this month (the current report forgets transactions from previous months! oh no!)

Example:

Bank Balance $  xxxxxx
G/L Balance    $ xxxxxx
Unreconciled : $ xxxxxx (This is just the difference of G/L and Bank)

Items Reconciled this month:
xxxxx    $ xxxxx
xxxxx    $ xxxxx
xxxxx    $ xxxxx
xxxxx    $ xxxxx
Total Reconciled this month $ xxxxx

Outstanding Items (From ALL previous periods where item does not have cleared date)
xxxxx    $ xxxxx
xxxxx    $ xxxxx
xxxxx    $ xxxxx
xxxxx    $ xxxxx
Unreconciled Total $ xxxxxxxxx (this should match from section 1)

I am going to take a stab at this report but I know basically nothing about PHP. smile  Hoping someone here can maybe modify the one that's ALMOST perfect.