It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by joe
You can translate this by using the program poEdit.
The reason for that not having translated these is that they contain accelerator keys (&) in from of the key.
I will prepare a new file, sv_SE214.zip and place it on Sourceforge.net, languages. It will contain the latest strings up to 2.1.4.
If you translate the po file, please also do the fuzzy translations. They are almost wrongly translated. And please return it to us, when finished.
/Joe
You can either have double setup of items/customer or let the 1. address line contain the foreign name for the customer. For items you can include both names in the description.
/Joe
Per definition FA will print the invoice in English if it is in another currency than the company currency.
These texts are in /reporting/includes/doctext2.inc. The domestic invoice texts are in /reporting/includes/doctext.inc.
You can laborate with these two files to fix this. But you will probably have problems with space for both languages, right?
But certain texts could be fixed that way, I guess.
/Joe
It is quite simple to create a new fiscal year and you should do that before closing the existing one.
You just create the new fiscal year. After that you enter the Company Setup and choose this new year. When you don't need the old fiscal year you can close it.
/Joe
Let us wait for other comments on this.
In the mean-time you can use the memo field below to register the orig. inv.date. This memo field will follow the supp inv view as well as the GL trans.
/Joe
The date you enter for the supplier invoice must have the same date as the gl transactions, so if you want the gl transaction date to be 12/Aug then you must enter the supp invoice date as 12/Aug.
The supp invoice date follows all the transactions around the various tables.
/Joe
The CVS for 2.2 is tagged 'unstable'. It is not fully merged with the last changes from 2.1.4. The merge only happens when minor releases are shipped.
We expect a shipment for the 2.2 RC in about one month, Though we may move the Item Tax Types to the other tax setup and perhaps rewrite it a bit. Janusz has announced this and I agree. It would be easier to understand it this way. So please expect up to 2 months.
/Joe
In release 2.2 you can allocate the payments directly. I guess you can see this on the demo 2.2 CVS,
/Joe
Hello Jason,
The Quick Entries is based on the normal Journal Entry Lines from the table 0_gl_trans. So when you build these lines correctly the VAT part occupies a transaction line of its own.
Internally the tax details is updated automatically, so your vat report/inquiry should report correctly.
It is, however, important that the Sales/Purchase Tax Accounts are set up correctly in Tax Setup. And you should use a Sales Tax Account for each vat rate you use. Similar on the Purchase Tax side.
We have no need for saving the tax part on the transaction line.
/Joe
You can use the Advanced manufacturing. When the Work Order is created, the required items according to BOM is reserved so you should NOT issue the same items again. Only if more than the BOM is required. Then before running production, you can choose 'Issue' and select type 'Return Items to Location' and enter the qty that you are returning.
/Joe
Yes, we are aware of this problem. We might need some improvements to this in release 2.2. I will discuss this with my co-developer when he is back in office again.
At the meantime you can enter the tax-accounts and taxes yourself on separate lines.
I saw your reports on Mantis too. We will try to solve them asap.
/Joe
Thanks,
I am glad you resolved this issue.
I will fix this for the download version 2.1 on the Website.
/Joe
Thanks Khaled,
I am glad you resolved this for the community.
I will fix this for the download version 2.1 on the Website.
/Joe
Hello,
Janusz has built our ui_lists and he is out of office at present. This will be a change in db structure, so we have to wait until 2.2 release.
I guess he can fix that for us.
/Joe
I have heard of this before. Maybe this is a good idea to tag an account to not be normally shown. But couldn't it be dangerous to use? I mean if a GL posting only consist of one debit amount to an account with the tag and not the same amount in the credit? Well this was only quick thoughts. Let us see what other mean about that.
/Joe
Unfortunately this is not possible at present. I know of people who has put the id in front of the name to solve it.
/Joe
Hello,
It sounds interesting with the change of primay key types, but let us wait for any other comments to that.
Personly I am not glad for the long account code field. My experience is that 6 should be enough, at most 11 as is now.
Regarding the REPGEN 2.1 you are probably right. It was a long time since this repgen was created. It should use the 'ae_tholoth' font as default, but I guess the zarbold is better (gives less fingerprint and is available for download at the download section). This can be changed in /reporting/includes/class.pdf.inc about line 101.
I am sorry I don't have the resources to help you at present, but I hope you will figure it out yourself.
/Joe
Yes there is. Have a look in the report itself first to see which parameters are needed.
Then have a look in /reporting/includes/reporting.inc (function print_link) and f.i. /manufacturing/work_order_entry.php (line 62 and 63) to see how to build the parameters.
Finally use the file /reporting/prn_redirect.php for firing the report (the href part inside the link in function print_link).
/Joe
Hello Courtney,
Just let the credit amount/percentage be negative.
/Joe
Some of you have objected to the newly implemented class type definition (from 2.1.3). We promissed you a backward compability. This backward compatibility was not 100%. It worked as in the oldversion by setting a variable, $use_oldstyle_convert on line 78 in config.php, to a value of 1.
But when dealing with the account class types the new types were presented instead of the old one 'Balance sheet' checkbox.
This has been fixed in today's CVS update of the file /gl/manage/gl_account_classes.php, revision 1.6. You can download it from here
This fully backward compatibility will continue to be there in release 2.2 and as long as it is needed.
Just remember to set the variable in config.php, $use_oldstyle_convert, to a value of 1, every time you update the config.php file.
The sign converting before was done on Income and Expenses (not balance sheet), in the Reports Balance Sheet, PL statement and Monthly Break Down, and this is of course also working as before when setting this variable to 1.
/Joe
Some of you have objected to the newly implemented class type definition (from 2.1.3). We promissed you a backward compability. This backward compatibility was not 100%. It worked as in the oldversion by setting a variable, $use_oldstyle_convert on line 78 in config.php, to a value of 1.
But when dealing with the account class types the new types were presented instead of the old one 'Balance sheet' checkbox.
This has been fixed in today's CVS update of the file /gl/manage/gl_account_classes.php, revision 1.6. You can download it from here
This fully backward compatibility will continue to be there in release 2.2 and as long as it is needed.
Just remember to set the variable in config.php, $use_oldstyle_convert, to a value of 1, every time you update the config.php file.
The sign converting before was done on Income and Expenses (not balance sheet), in the Reports Balance Sheet, PL statement and Monthly Break Down, and this is of course also working as before when setting this variable to 1.
/Joe
By changing a few lines in /gl/manage/gl_account_classes.php and by setting the variable $use_oldstyle_convert in config.php, line 78 to 1, everything now run in fully backward compabitility mode. You will only see the 'Balance Sheet' checkbox if you run in this mode.
The CVS Main trunk is now updated. If you download this file manuelly, please also download a few other files, according to ChANGELOG.txt, to get fully updated with a couple of bugfixes.
This correction will also work in the upcoming release 2.2.
And remember to set this variable, $use_oldstyle_convert to 1 in config.php, in upcoming releases.
/Joe
Normally I am not reluctant. It is only because there really are no severe differences to how it worked before.
So what you suggest is:
If a variable is set (in config.php) then the old checkbox with balance sheet is re-established. And if this variable is set FA runs as it did before, right?
Would you also want the old sign convertion (in the PL sheet, the income and expense was converted. We better do so to get it really backwards compatible)?
/Joe
I will try to explain the difference once again.
In the new class type system you can select 'Assets', 'Liabilities', 'Equities', 'Income', 'COGS', 'Expense'. But you dont have to use all of them.
If you want to use it as before, you can for instance only use 'Assets', 'Liabilities','Income' and 'Expense' as is presented on the demo site.
Instead of marking the class with 'Balance Sheet' as before, you now select either 'Assets' or 'Liabilities'. It should be fairly easy to figure out which. And instead of unmarking the 'Balance Sheet' you select either 'Income' or 'Expense'. Again it should be fairly easy to set.
That's all there is to it.
By setting up the Account Types (Groups) you tell FA in which order inside a class you want to present the reports. This is similar as before.
This new implementation has nothing to do with any standards.
You can retrieve the same reports as before. If not, tell me which reports are not able to retrieve as before. And I will try to show you how.
/Joe
Thanks, I will publish it ASAP.
Yes, we need to populate the users table with one admin to get started. This user account can later be changed and more admins/users can be added.
/Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.