Search options (Page 72 of 97)

Yes, there is problem with incorrect amounts in journal inquires, when bank account is used. This will be fixed as Joe stated.

But I can't reproduce problem reported in p 1-2. Moreover p.3 is not acceptable fix - this would lead to inconsistent audit_trail table.

Janusz

You should set 'Search Item List' box in Company preferences. Then after spacebar press you can entry item code fragment to search, and only related items will be displayed in the list.
Janusz

And of course not all of your items have Item Type  set to 'Service'?

If you have phpmyadmin installed you can make play with the sql query which returns empty result:
Place temporarily line:

display_notification($sql);

in function get_loc_details just before return db_query();. This function is placed at the bottom of  get_loc_details.inc file.
When sql query s display copy-paste it to phpmyadmin sql query window and try too find what is wrong in your database.

Janusz

Do you have any location defined? Does your location code contain some special char like: ', ", &, < or > ?
Janusz

But what exactly happens? Blank page, or all zero values in status table, or no item in selector?

Janusz

Seems there is some problem here, although I cannot find whether it is upgrade procedure bug, or some not clear upgrade instructions. This is how the upgrade from 2.1 should be done step by step, providing  FA version 2.1.x is used without any partial upgrades from unstable CVS, or 2.2RC version was installed:
0. Make backup copy of database content for all companies,  and eventually copy of working FA sources.
1. Copy all the 2.2 tarball sources to related places where you have 2.1.x files.
2. Make changes in config.php described in update.html. Do not touch security_groups, security_headings for now.
3. Login as admin of first company (superadmin)
4. Perform upgrade form Setup/Software Upgrade page.
5. If there were no errors during upgrade, the process is nearly finished. You can log out, comment out $security_groups and $security_headings arrays in config.php.

Now you should be able to login with old admin user/password. In Access Setup all previous roles defined in config.php should be visible with 'FA 2.1' name prefix. The roles normally need some smaler fixes, as previous security setup was not especially consistent.

This is how all should work. When you expect problems you can enable error logging before FA upgrade by uncommenting $error_logfile in config.php, and making sure tmp directory is world-writable. Then in case of any problems error messages should appear in log file even if not displayed on screen during upgrade. This should help recognize what went wrong.

Janusz

The conversion code is not a problem, as it is implemented in FA for long time. The problem is which institutions are acceptable as source of daily rate for FA users, and it depends somewhat on user's location. Currency rates in Malaysia are not especially valuable for FA users in Europe. Currently only ECB page is supported.
Janusz

You have to be logged in as administrator to _the_first_ company in config_db.php. If you log in to second on any other  company you will have no access to those options.
Janusz

Those options influence  overall site security, so they should be available only for site admin. In FrontAccounting such special role can be created only for first installed company, admins of which are considered site admins. Login as admin to company which were created during FA installation on your site and you will have those options available.

Janusz

POS  is simply wildcard term, just like ERP. To implement any new feature we have to at least know what wishers mean. Current functionality named POS (direct invoicing and point of sales definitions, also foreign codes feature) is just what is enough for me. I know it is far too little for most other people over there.

There were a couple of prepositions regarding POS beginning from full implementation inside FA, via integration of third party applications up to loose data synchronization. In fact to begin such a big task we at least have to know what FA community consider satisfactory set of features to name it POS.

Some time ago on growing demand from FA community we have established FrontAccounting wiki. Unfortunately so far the main authors are still Joe and me. Seems that  all the energy of other forum members has been exhausted on discussions how the wiki should be organized. Nevermind.

Anyway if you are really interested in POS functionality, the first step toward implementation is to write down some functional POS specification, and describe which features are necessary, which are optional or just a candy. The wiki system is ideal for such cooperation effort, and you can be the pioneer which decides about future shape of POS.
I have just switched your status to senior member, so you have write access also to Devel group of pages, so you can start to turn your wishes into reality .

Janusz

Release 2.2.1 is already available on SF.net. All reported bugs are fixed beside the CtrlAlt problem.
Janusz