@joe: Does this make it to the core?

1,602

(3 replies, posted in Banking and General Ledger)

Caveat: Provided you have not closed any of the succeeding fiscal years.

"Unknown" is okay for third party extensions.

Will these SKRs for 2018 do?

1,605

(9 replies, posted in Modules Add-on's)

Wiki updated.

1,606

(3 replies, posted in Banking and General Ledger)

Making entries out of order is generally not advisable. However, the ability to enter / edit transactions in prior fiscal years is available if enabled under role permissions - this feature is for those who perform batch-wise historic book keeping.

All transactions pertaining to one fiscal year must be entered in order (date-wise) when that fiscal year is made the active one for the company, the earliest fiscal first.

Then make sure that the original path to root variable also gets passed on as well but as it's original value.

1,608

(9 replies, posted in Modules Add-on's)

@aleifuuwork: The dashboard.inc is integrated in FA 2.4.x. Your links are for FA v2.3.x. Read from this post onwards. Use the canvas theme in a default install of FA 2.4 and enable it's deployment in the access role for the Administrator user, logout and then login.

1,609

(4 replies, posted in Accounts Receivable)

Make it part of the Logo image wink

Actually, this is the way it is by default.

Looks like you downloaded the FAMods into a separate folder and did not integrate it with your FA core.

1,611

(20 replies, posted in Banking and General Ledger)

The en_US-demo.sql has the following error on navigating to Banking and General Ledger => Trial Balance:

The Opening Balance is not in balance, probably due to a non closed Previous Fiscalyear.

This appears to be a false positive as the balances (without zeroes for clarity) do actually tally.

Cannot duplicate your date picker error - is it specific to your choice of date format? The en_US date format seems to work okay.

Use a different variable for your extension's path to root and it will lapse after it's scope vanishes.

1,613

(20 replies, posted in Banking and General Ledger)

date_picker.js is created for the specific date choices in the config.php and placed in the company/#/js_cache/#/ folder where "#" is company index number.

The function get_js_date_picker() in includes/ui/ui_view.inc includes the said file and generates the js include code based on user select options.

Hence purge the said file in the js_cache and it should get generated anew and all should be well.

Prefix logo with some variable that denotes these branches.

1,615

(6 replies, posted in Setup)

Yes. Looks like it got orphaned:
https://frontaccounting.com/fawiki/index.php?n=Main.OpeningBalances
https://frontaccounting.com/punbb/viewtopic.php?pid=30427#p30427
https://frontaccounting.com/punbb/viewtopic.php?pid=31547#p31547
https://frontaccounting.com/punbb/viewtopic.php?id=1587
https://frontaccounting.com/punbb/viewtopic.php?id=7387
https://frontaccounting.com/punbb/viewtopic.php?pid=31548#p31548

Remove == Void ?

There are some audit trail entries and average costs of stocks that may need to be re-computed as well and the actual comment entries in the removed invoice numbers that may still exist in some tables.

1,617

(6 replies, posted in Setup)

If all receivables and payables are moved into the new FA using Journal entries, then allocation towards invoices cannot be done. Where such allocations are desired, the invoices that remain unpaid need to be manually entered in the previous fiscal year and the remaining should be entered using the Journal entry method.

This is generally provided through widgets in a dashboard or custom reports.

What about the paginated entries that overflow to next page?

1,620

(5 replies, posted in Installation)

Just fix your config_db.php file to point to your upgraded database correctly and that the access credentials are okay.

Banking and General Ledger => Maintenance => Bank Accounts +> Select Bank Account and make it Default (Dflt).

A screenshot using the standard default theme (and not the dashboard/canvas) theme would be better for design purposes.

@joe: a nice functionality but may affect a lot more tables fields / scripts.

1,624

(5 replies, posted in Setup)

Study some of the extensions that create new permissions that can be allocated to any role (new or old) and make yours.

1,625

(5 replies, posted in Setup)

That will just prevent editing an existing Purchase Order's price.
Probably clone the said role as a new role, switching of the edit permission and create one for switching off the add/view purchase price permission as well which needs to be instantiated in the role instanciation script as well. Then use that role in your new purchase order form to replace the existing one possibly as an extension.