@joe: It is better to remove the Reference field from all such forms and save as next available Reference automatically and informing the user of the actual reference it was saved as by reporting it in the "success" message.

2,602

(24 replies, posted in Installation)

@PaulShipley's Post #10's commit link has all the necessary files to be copied into the modules/<module name> subfolder. The patch file is used in linux CLI to apply on existing files without having to copy the other replacement files.

2,603

(5 replies, posted in Report Bugs here)

Probably that should be sufficient. Is all well now?

2,604

(5 replies, posted in Report Bugs here)

Upgrade to FA 2.4.2+ and clear the company cache and it's js_cache as well.

Disable the autofill of form fields in the browser settings.

Make sure that the auto form filling in the browser setting is not enabled. A browser refresh may also mitigate it.

The new tax that is also non taxable is just a temporary creation. As you can see all the tax transactions, your method may be okay. If you had voided each such invoice and recreated them, all may be okay as well.

2,607

(4 replies, posted in Translations)

Hope you logged out and logged back in after the language change. Browser cache and sometimes js cache in the company/#/#/js_cache may need to be cleared too.

Linux will also need the locale installed for Arabic and a weberver restart.

Making it an absolute config constant value would avoid having to set and overwrite is everywhere in erroneous relative path method that prevails now. I do not want autoload composerisation as it come with other issues.

2,609

(27 replies, posted in Banking and General Ledger)

For a start, you can make decimals 0 length for Amounts.

@joe: separating the amounts and prices into 2 separate config variables for decimal length may be needed to accommodate such cases.

You should have made a new tax and then moved the erroneous one there and then moved it from there to the target one. Take a backup before and after so that if any unwanted transactions are not needed, they can be deleted and / or removed from the backup and then restored.

2,611

(5 replies, posted in Wish List)

There should be in context notes of what is pertinent to FA 2.4.x alone and not for FA 2.3.x and vice-versa. Info on enabling Fixed Assets config editing permissions too should be available.

Only @joe can edit the Sidebar.

https://frontaccounting.com/fawiki/index.php?n=Devel.TrobleshootingFrontAccounting

2,613

(4 replies, posted in Report Bugs here)

Which version of FA are you using?
Have you patched it with fixes after it's latest release?

2,614

(5 replies, posted in Wish List)

Even the wiki will need a separate menu link....
@joe: listening?

2,615

(27 replies, posted in Banking and General Ledger)

https://frontaccounting.com/fawiki/index.php?n=Devel.TrobleshootingFrontAccounting

2,616

(9 replies, posted in Installation)

The latest PHP 7.1 will not ordinarily accept FA code. They will insist on changing the constructor and destructor names. May be you are using some php.ini settings for backward compatibility in your specific version.

The idea is to make it usable in a uniform way without different hardcoded values.

2,618

(3 replies, posted in Report Bugs here)

Check this thread.

2,619

(24 replies, posted in FA Modifications)

You need to create a new item for each combination of attributes. Otherwise, there is no place other than in the description to place your attribute specifics.

@joe: is this the acceptable way to code the $path_to_root in all repXXX.php files?

2,621

(24 replies, posted in FA Modifications)

These are product attributes. You can make one item for each combination of colour and width. That way you will be able to manage it's stock individually too.

2,622

(3 replies, posted in Report Bugs here)

Upgrade to FA 2.3.26+ and see if the problem persists. There may be some random entropy issues / forced check or if your IP changes.

Just try to enter the form again and submit with the fresh reference. It is possible that more than one person attempted to use the same entry screen simultaneously and one got the next reference number whilst the other failed since there would now be a record already in the db with that reference number. The post referenced above explains the scenario and a possible solution using an auto check for a new reference number just before adding the record for a more reliable means but not notifying the user of the reference number change if any.

Check the settings of the config_db.php file to see if the correct company and db name and db prefix match. It is possible you imported one company's backup into another company and the prefix may or may not have been the same.

No standard fix. Hack the Credit Note script and alter the way the new reference is generated to take it as the next one from the invoices series and then use that in the Credit Note set.