Search options (Page 197 of 200)

Thanks Jan, this is really appreciative.

Kind regards
Joe

Janusz, lets take these discussions in the Mailing List. I've created a list and it will be available within 24 hours.
There is always a reason why things are implemented in a specific way. All the reports are taken care of in a 2 click away report centre, where your last document is default for printing.
The form_items table is a left over from the former project, where they used a non published java based report generator. We are not using it at present, and could possible eliminate it in the future.

/Joe

Thanks for your contribution. It warms our hearts. Did you see the oppurtunity to select jalali or islamic calenders as well. See in config.php. I don't know if you are using it, but they are there for your pleasure.

We also need some better fonts for the PDF presentations. There are some links around the website about it (Download Language page and some Feeds pages). The Farsi font we have tried is not the best one. There are some problems with it. If you have the time and interest you could probably dig into this a bit to get optimal solutions.

/Joe

Hello again,
Now it popped into my mind what the Retained Earning Clearing Account is about. It is the account for accumulating the profits during the fiscal years.

To your last question you should create an account, probably the last one in your cost group and call this account for something like 'Year Profit Clearing'.

The last transaction of the fiscal year will then be a debit to this account for your profit and credit to the Retained Earning Clearing Account.

If there is no profit, but loss, you should use credit and debit instead.

You don't have to this before creating a new fiscal year and start entering on the new year. You can do this later on when your transactions of the previous year has finished. As soon as you have done it, you should close the previous year, to avoid entrance on this year by mistake.

This is the normal way of doing it. There might be slightly different methods in various countries. In that case you should ask an accountant.

/Joe

The dot was mistakenly included. Here is the link again
https://frontaccounting.com/grid/sample16.php .

Fixed in the CVS repository at Sourceforge. Thanks janusz.

/Joe

Hello again janusz,
I'm not sure if I understand your answer.
When you choose the backup/restore in the setup tab, only the current company is backed up. If this company has a table prefix of 0_, the backup file will show up as: dbname_0_Ymd_Hi.sql, where dbname is the name of the database, _0 is the table prefix. It is important that you select the correct sql file with the correct table prefix when you later restore this file on the company.
If there is no table prefix the backup file will show: dbname_Ymd_Hi.sql. In this case you would chose the correct dbname when restoring.
String replacing a 0_ with 0_ will result in 0_
String replacing a 0_ with an empty string will result in an empty string (no table prefix).
The only cases that the str_replace line will be executed are when you replace a 0_ with 0_. (backup/restore), and when creating a new company. It will either replace the 0_ with the selected table prefix or an empty string if no prefixes.

So I really see no problem here if you take these precautions when restoring the databases.

/Joe

But janusz, we have used it with the farsi (persian) language as well as russian.
You can see the PDF output for the farsi language on the Screenshot page here on this site. If you follow the instructions on the Download Language page about creating a local.inc file and making a new font file for PDF, there should be no problems using this class for presenting non latin-1 encodings.

And we can put more fonts and local.inc files on the Download Language page as soon as they are created.

/Joe

Thank you Janusz for your help.
#1 is ok. Will be fixed asap.
#2. A temporarily fix to the Report Generator is to limit the access to Admins only. Page_security 15. I think the second str_replace line was mistakenly implemented during development of the Report Generator. It is not neccessary. But the first line with str_replace with replacement of 0_ to currentry table-pref is neccessary due to importing new chart of accounts when creating new companies. These charts have a prefix of 0_. It shouldn't create any troubles at least as I see it. If it does, we have to find another way of adding the table-prefixes into the tables. The problem here is that all the various chart of accounts have been implemented with this 0_ prefix. What do you say to this? When we have solved this we can update the CVS repository.
Again, did you see my answer to your PDF presentation? If we are sure about that we can include this also.

Kind regards
Joe

Hello,
We are aware of this. Can you point out a solution for this? It should probably be done in the include file /reporting/includes/pdf_report.inc.

Joe

Hello,
Thanks for your contribution. I will answer your questions by referring to your list numbers.
1. The phone numbers etc, are not belonging to the customer, but to a branch (branches). The reason to have this separated is that it might be a one to many relationship. In database technology it is called normalization. A company can have one or many branch addresses for deliveries.
2. The same thing regarding the Items. We can have prices for retail, wholesale, and for various currencies. Again this is a one to many relationship.
3. The check writing has not been implemented yet. You can use the ACH transferring in the US.

If you want to build another application based on FA, you are welcome to do so.
We will not change the kind of infrastructure we have built, because it is our experience that this is the right way of doing it.

Kind regards

Joe