Search options (Page 4 of 11)

Do tags or dimensions help?

simpleAPI pagination

Your approach is promising.  This should work in theory for lists which are the most frequent occurrence of ajax sync, so perhaps this approach could fix the lions share of the problem.  However, ajax sync can be called for other data types, such as dates, so it is not a complete solution.

I don't have the ability to test this, but it seems like it does close one avenue of data corruption in FA in a more user friendly way than just simply reloading the page as I proposed.

I suggest making a fork of the FA project on github, and adding your changes in, perhaps with help from a 3-way diff tool.  Then as new changes are made in FA, you can sync your fork with the upstream code.  Often the new changes are incorporated without any additional effort but sometimes there are conflicts, but then you run git mergetool to help determine how to proceed.

I'm thinking this was fixed.  Make a copy of your database and upgrade it 2.4 and let us know what you find out.

I agree that the loss of data is frustrating, but this might be the only easy way to assure data integrity.  The code assumes that the ajax operation will complete successfully.  For a list, the list is already updated on the browser page and then the code requests the ajax update. If the ajax operation does not occur successfully, the page will have inconsistent data.

In the example of the customer payments screen, if the customer is updated and ajax fails, the branch will be wrong as well as the allocations and who knows what else?  Perhaps the customer has multiple branches, and the branch is updated and ajax fails.  Then the allocations would be assigned to the correct customer, but what effect will having the wrong branch have on the code? What if the bank account is changed, but ajax fails, and now the currency calculations are wrong?

There might be some easy way to cache the page before ajax is called and then restore the page if it fails, but that is beyond my knowledge.

Branches are a good suggestion, but FA support for reporting/inquiry by branch is limited.  I have been working to improve this in my fork and you might be able to rework this commit to FA (ignore the first two ui_lists.inc changes).

See also, https://frontaccounting.com/punbb/viewtopic.php?id=8379.

Make sure that Tax Bank Payments and Deposits is checked in Company preferences.   The default is not checked.  With this checked, the pull request should result in the same output as 2.3.

As you discovered in your first two trials, 2.4 does not have this code.  I believe it may be planned for 2.5.

Its an FA bug unmasked by an advanced version of php, requiring a code change to fix.  You might make it quiet down by adding:

$line .= chr(32);

after $len = strlen($line);

on line 181.

You could look at the extension that I wrote https://github.com/braathwaate/FA24extensions/tree/master/Extensions/bank_auto_reconcile.  The main focus is to reconcile a bank statement with existing manually entered g/l entries in FA; however, missing g/l entries can be automatically imported using the same g/l accounts as used previously.  That is, once there has been one match, future entries are imported using the comment field, assuming that some of the comment on the bank statement is consistent.  (E.g. WATER UTILITY X75GGGGFX will match each time based on WATER UTILITY in the comment even if other numbers in the bank statement comment change).   Therefore, auto deductions with varying amounts each month auto-import using the same g/l accounts as the prior month.  Bank statement formats are hard coded, but easily modified in the code in a table.

You can find out what session the browser was using before the logout event and then see if it still exists or is corrupted in some way after the logout event.  For Firefox, open the storage inspector with shift F9.  The session name is stored as a cookie.  After the unexpected logout, look for the session file on the server.  If it is gone, then you know that something on the server removed it.

If it is still there, then the problem becomes more interesting, as then you will need to examine the file for clues why FA could not use it.  I would also guess that if it were still there, FA would display "authorization timeout" or some other error message.

Note that when a session file is removed unexpectedly, FA will initiate a logout and create a new session.  So looking for the session cookie name after logout tells you nothing.  FA apparently does not issue an error message if its cookie is gone.  The screen display is the same as when a brand new session is initiated with FA.

My word of advice: don't.  Customers will see the discount schedule and always take the largest discount no matter when the payment is made.  Then you are stuck with sending them a statement asking for more money which they may dispute and believe me can lead to legal action.   If you go this route, you just need to add the calculation on the invoice like you would for invoice signature.   Like the built-in FA prompt payment discount, this would be informative only and you manually split the invoice amount and discount on the customer payment screen.

My recommendation is to work out the varying customer discounts in advance.  Send them notice that their customer discount will be changing due to slow payment, low volume, etc.  Then change their discount to a lower or no discount in their customer record.