FrontAccounting forum — SQL Files Fiscal Year should be updated

Re: SQL Files Fiscal Year should be updated

null@example.com (apmuthu) — Thu, 24 Jan 2019 10:54:00 +0000

The following sys_prefs parameters:

default_loss_on_asset_disposal_act
depreciation_period

have their length field value in quotes.
Automated systems looking for these gotchas beware.

Re: SQL Files Fiscal Year should be updated

null@example.com (joe) — Tue, 22 Jan 2019 11:33:17 +0000

Hello,
The 2 core COAs have now been redesigned a bit and are now syncronized. Only that the demo variant has the demo data..

I have tested both of them, and it seems to work fine.

Committed to repo.

/Joe

Re: SQL Files Fiscal Year should be updated

null@example.com (apmuthu) — Tue, 22 Jan 2019 03:17:59 +0000

The text and tinytext fields have " COLLATE utf8_unicode_ci" now.
The table and field ordering should be the same in both en_US-sql and en_US-demo.sql to make for ease of comparison and error detection. Changes between commits should be easily spottable especially in such core files.
It is okay to keep the comment as "--" for now.

Re: SQL Files Fiscal Year should be updated

null@example.com (joe) — Mon, 21 Jan 2019 18:33:03 +0000

No, the dashboard tables should not be there.

Well if users make a backup they will see the '#' as a comment specifier.

Will make a rerun later.

Joe

Re: SQL Files Fiscal Year should be updated

null@example.com (apmuthu) — Mon, 21 Jan 2019 17:12:00 +0000

It appears that the dashboard_reminders and dashboard_widgets tables are now present in the new en_US-demo.sql file. The comment character is a condensed "#" instead of the multi line "--". This makes it difficult to compare with the en_US-new.sql which has the "--" as it's comments character. Some sys_prefs items are also missing.

Re: SQL Files Fiscal Year should be updated

null@example.com (joe) — Mon, 21 Jan 2019 13:43:51 +0000

Hello again.

Only en_US-demo.sql needed update of the 2 core. It was done by moving 2017 to 2018 (search and replace). Then creating a new year 2019-01-01 to 2019-12-31. And setting the Company to this year. Then a couple of transactions were made.
This is all we can do. Remember things are very close mingled in the database. But this is good enough.

The en_US-new.sql was ok as is. The fiscal year was set to 2018-01-01 to 2018-12-31. I think this is ok, for when you start a new company you will often make an opening balance on the end of 2018. And then create whatever new fiscal year you need.

All the other COAs from the repo only needs a new fiscal year, I guess.

But Janusz will do some adjustments to the 2 core COA's due to SQL security injections. And of course also to the repo COAs.

The new en_US-demo.sql has been committed to repo. Can be downloaded here if needed.

/Joe

Re: SQL Files Fiscal Year should be updated

null@example.com (apmuthu) — Sat, 19 Jan 2019 10:10:47 +0000

Fork the FA24Extensions repo and change what you want.

Re: SQL Files Fiscal Year should be updated

null@example.com (kvvaradha) — Sat, 19 Jan 2019 01:30:04 +0000

The other chart of accounts are from your repository. So it can be override the year change for me is not easy.

May be we can write a override program to update the years in all chart of accounts.

Re: SQL Files Fiscal Year should be updated

null@example.com (joe) — Fri, 18 Jan 2019 20:53:25 +0000

I will fix it manually this time for the two charts we have in core, but if you are keen fixing it your way, you are welcome to try.
We do have a lot of charts that need update.

Joe

Re: SQL Files Fiscal Year should be updated

null@example.com (apmuthu) — Fri, 18 Jan 2019 17:54:09 +0000

Better to make it dynamic where SQL user variables are suitably populated and used.

Re: SQL Files Fiscal Year should be updated

null@example.com (joe) — Thu, 17 Jan 2019 17:39:35 +0000

Yes, it is a matter of search and replace.

Joe

SQL Files Fiscal Year should be updated

null@example.com (kvvaradha) — Thu, 17 Jan 2019 16:50:14 +0000

@joe, the demo and fresh sql files has 2017 data's. We need to refresh the dates with 2019 and also fiscal year also 2018. we need to allow them to see 2019 on both default SQL files with current year. So the new users wont get confusions.