Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 90 of 97)
Topics by itronics User defined search
Posts found: 2,226 to 2,250 of 2,419
Once entered transactions in GL Journal cannot be edited, although you can void selected transaction under Setup/Void Transaction. You can also search all entered journal transactions in Setup/View or Print Transactions. Keep in mind that most GL postings are made automatically from other screens than Journal Entry.
All reports are defined in rep*.php files in reporting folder. Common layouts are included from files in reporting/includes/header2.php etc.
Janusz
p2409 is mostly right.
2. Journal entry is for posting changes in your GL accounts, therefore zero value cannot be posted simply because it reflects no change in your assets.
3. New grn's should be entered against previous purchase order selected via Outstanding Purchase Order Maintenance menu option. The adjustments should be used only for entering initial inventory.
Janusz
Hello,
There is no special description about local taxes in Australia nor any other country on FA site (beside local charts of accounts section), but the tax system is flexible enough to accommodate most local fiscal systems. If you want to use prices with tax included you should check respective boxes in tax definitions. The tax is posted to GL during invoice issue (see GL links for different transactions in sales/purchase inquiry).
Janusz
I think you can find more about how to resolve your problem here:
http://infotechaccountants.com/forums/
and here you can prove that it really work:
http://www.infotechaccountants.com/accountingb/
(login demouser, password:password)
Janusz)
No, the comments in .po file are informational only. The transaltion is made automatically if you have properly configured web server and related software.
The exact solution depends on your system. I guess you have some www server installed locally on some sort of Windows. Sorry, my hardware entirely work under Linux so I cannot help you in your case. Please read forum threads related to FA installation under Win, maybe you will find them usefull.
Janusz
If you have gettext installed you also need to have respective locales installed on server site. Without it you have messages not translated.
Janusz
No idea. You will have more info about actual source of errors when you set temporarily $go_debug=1 in config.php.
Janusz
Yes, you are right, private subdirectories should be created for all existing companies. Thanks for pointing this out.
Janusz
Yes, of course you can make new, completely different implementation of reporting module. But you must be prepared for spending a lot of time to do this and keep in mind that you can only send reports to printer via network interface. There is no way to print directly to printer port from browser.
Janusz
I'm afraid currently we have no serial number control implemented.
Janusz
Look inot source code. There is plenty of examples.
For sales orders you have sales_order_entry_page.php when you can add extra input fields and sales_order_db.inc for mysql storage, where respective read/write functions should be extended.
Janusz
Yes, you should look int the source e.g. sales/sales_order_entry.php for Sales Order Entry page.
Janusz
Yes, we have implemented sending reports directly to network printer, or local networked printer on user computer if there is installed print server with lpd support . It is available form CVS in unstable branch and will be included in FA 2.1. But as far as I understand your problem has nothing to do with direct printing. All reports in FA are produced in pdf format, so using matrix printer involve graphical printing. Matrix printers are slow in graphic mode, so I do not see any way to have fast printing in your configuration.
Janusz
Hello, please set $go_debug=1 and $pdf_debug=1 in config.php and try genearte the report again. This should give some error messages explaining the reason of the strange behaviour.
Janusz
Hi nyasar,
The installation process is stright forward. At first time you should call install/index.php file to create first company. If you want to have more than one company you should select numeric prefix for table names during install. Then you should login into just created company with admin/password, and now you can add more companies under Setup/ Create/Update Companies. Thats all.
This process does not need using phpMyAdmin. As I understand you have tried to add new company by adding new record in 0_company table. This not make sense because every company has its own x_company table, and only first row is used to store this one company parameters.
Janusz
Well, you said that gettext does not work on Linux box. This is not the case. To use say russian translation under linux you must have both FA ru_RU translation file and system locales in the same encoding. So if you want to have russian user interface on linux box where you have only ru_RU.utf-8 locales you must recode messages file, or translate it from scratch. The ru_RU.po file in download section of frontaccounting.com is encoded in ISO-8859-5, not UTF-8.
Your method to replace all the gettext _() calls makes your system not upgradable. But if you wish, you can of course do it this way. I wanted to say this all is not needed to make FA work in Russian , Latvian, Farsi or any other language if you have messages translated.
Janusz
Hello straga,
I've just checked russian translation under Debian Linux and the translation works, although declarared 20% of translated messages is optimistic approximation.
To have any localization with gettext working you have to install respective locales. As I see your test was done with utf-8 sample, but the translation file for FA use iso-8859-5 encoding, so it will not work until you make something like:
dpkg-reconfigure locales
and select right locale to install i.e. ru_RU iso-8859-5.
After apache restart you have some messages translated, but as I said not too much. If you wish to translate the rest you can send the results to us to share with other users.
Janusz
Above applies to Debian but also should work on its derivative Ubuntu.
Good luck.
Yes, in some situations there was false edition conflict detected, which was not displayed because of another error display bug. Both bugs are fixed and files ui_input.inc and po_receive_items.php in CVS updated.
Janusz
There always can be problem after partially not successful upgrade. When some of tables are updated and the rest defined in upgrade script are not, new errors appear because the properly updated tables cannot be updated again. So the best method is to have backup file prepared in Backup and Restore page before upgrading. Then if something goes wrong you can restore database before next try.
I've just found that on Backup and Restore page we had false success message even if something goes wrong during upgrade. This was confusing and today I uploaded to unstable cvs better version of backup utility. Now after upgrade failure you will have info at which line of source file the problem begun. This is useful of course if you use backup/restore utility to upgrade FA database. If you are using phpmyadmin to do it you have mysql error displayed anyway.
You had badly updated db structure (there was no POS definitions). Beside this you have not updated all needed source files (fatal error on Direct Invoice page). Please clean up the site before next tests.
Janusz
You must have respective locales installed i.e. pl_PL.ISO-8859-2 on your Linux box.
All installed locales (and some info how deal with it) you will find in /etc/locale.gen file.
Maybe some problem caused by password autofill during installation. Check your password hash according to:
https://frontaccounting.com/punbb/viewtopic.php?id=318
Janusz
Yes, you are right. Price for [base pricelist/home currency] has bigger priority than price for [user pricelist/home currency]. Just fixed in main CVS trunk (file sales_db.inc), to be merged with unstable branch in near future.
Thanx.
Janusz
Well, I've just tried to reproduce both the problems, but with no effect.
More info is needed to track it down. Have you pricelist problems also on stable FA version? At what moment the database error appears?
To use new functionality in unstable you need to upgrade database structure with changes in alter2.1.sql file. Keep in mind that this file can be used directly only for db table set with prefix 0_. If you want to use it to upgrade tables for company 1_ you have to change the prefixes manually.
Janusz
Currently search function is not properly implemented for combo type 0 (see ui_lists.php/combo_input()), so cannot be used here. Normally there is not so much accounts used so we have no need for this. Of course you can try to fix this issue .
Posts found: 2,226 to 2,250 of 2,419