Search options (Page 81 of 97)

This is not solution to the problem reported. When in FA only one currency is used, no exchange rate check should be done. If the error mentioned is raised it means that database is not consistent regarding currency references, or there is some very ugly bug in FA not squeezed so far.

The proposed sql change can result in retrieval of outdated exchange rate without any warning e.g. when ECB page is not available.

Janusz

If ISO-8859-1 contains all needed chars you can prefer using it, as UTF-8 report generation is much more memory hungry.
Janusz

Thank you very much in advance jackel

Janusz

No, Tom. We have decided to use encoded strings everywhere to prevent injection problems, so it will not be changed. Please follow this convention - this is thoroughly tested concept. The strings have to be decoded only when they are got from database and are to be written again by any db layer function (I mean the functions in */includes/db/* files).

You will find an example of rewriting documents stored in database in function write in items_cart.php (html_entity_decode calls).

Janusz

Hello,
You can send invoice by email manually from the report module.
Also when you set $loc_notification  to 1 in config.php emails are sent to respective inventory location about low level of ordered items during new sales order entry.
That's all.
Janusz

As far as I understand the mechanism user can set individual price for any batch of received items. Currently there is no support in FA for inventory stock control on batch level, so this feature cannot be implemented as for now, I'm affraid.

Janusz

Please check under phpmyadmin if your debtors_master records have the same currency code as set in company record. If it is the case I have no other idea what can lead to this message. The only thing I can propose is to send me backup file to install and track the problem locally on my site.
I guess the problem is result of some manual interference into database content, which can have a lot of side effects. Is this the case?

Janusz

In sales_kits.php line 87 should be kit_code instead of item_code. Fixed in main CVS.
Janusz

Yes, it is. To be fixed in CVS ASAP.
Thanks Tom.
Janusz

I'm not sure. Anyway you can check what you have installed via phpinfo(); call.
Gettext on debian works like a charm, but I'm not sure about the emulation. I not use it.

BTW. Please ask your boss to consider Joost's request. Maybe he/she using FA would like to support back this way our community?

Janusz

Hello,

I personally don't like java, and therefore I do not know it well so I cannot help on POSper side. The lack of web API in FrontAccounting is big issue, but I do not want to waste time for implementing API which later have to be completely rewritten. If there is someone who can do the work on POS side, I am open for any discussion and cooperation.

There is a couple protocols which can be used to data exchange here. I have done some startup work to implement Hessian API services for FA. The protocol developed by Caucho (resin server authors) has many advantages, and there is at least two free implementations of java libraries which can be integrated on java POS side. I think it would be good choice for the case. But if POSper has some web API already implemented, we can also try to make some connector for using it.

Anyway there is no chance to integrate FA with any third party POS without help of some coder knowing details of this POS implementation. It's not me.

Janusz

Hello,

I use FrontAccounting on Debian linux server with polish translation using system gettext libraries, and have no problems with translation. What is your distro? Have you got gettext installed, or php emulation is used?

Janusz