Search options (Page 63 of 97)

E.g. for apache 2.0/php5 add to /etc/php5/apache2/php.ini:

extension=mysql.so

Janusz

Yes, this the only way for now, I thnik. It would be good to extend idea of allocation by enabling payment entry against purchase order/GRN as prepayment. So process would look like this:
. After PO/GRN entry we have link to payment against this PO/GRN
. Entered payment is preallocated against this PO/GRN
. When GRN/Invoice is entered the allocation is moved from PO/GRN to GRN/Invoice.
This way we could avoid additional allocation step in mos cases, i.e. when payment is done against some single PO.
Janusz

Maybe mysql interface is switched off in php setup? I see no other reason why php standard l  mysql_connect() function is not visible on your system.
Janusz

This is what we want to avoid by clear defaults: automatization of problems .

This is price list selected as base for price calculations, when there is no explicit price set for some items. If you have 'No base price list' here you have all automatic calculations for prices off. Maybe this is your problem? Set it to most complete/often used pricelist.

If you have some base price list set the price selection order described in my previous post is used.

Janusz

Well, timeout was enlarged to 6s in  2.2.5 and this should be enough in any circumstances, or anyway user interface became unusable. If this still genearte trouble I will think about finding some cure, although it can be difficult.

Janusz

No, Alvin. I have just explained why it cannot be done automatically: To ensure that  no random price is selected we have to base on clear defaults.  So only three prices are considered as apprioprate:
. Price in customer currency in current pricelist.
. Price in current pricelist in default currency (USD in your case)
. The price in default pricelist and default currency

Such selected price _is_ recalculated to customer currency, so you have not to do it manually.
We cannot use any available price just because we can have 10 different non-default prices for various currencies and there is no way to select the right one as base for final price calculation. We have to avoid any ambiguity here just to avoid mistakes in use.

Janusz

Hello Anthony,
thank you for pointing out this outdated information. FrontAccounting has release cycle established a couple of years ago, so point 3. on features page is misleading. I have fixed it. FA is suitable enough for most SME segment companies and non-profit organizations as well. There is lack of some more sophisticated features like batch/serials inventory control needed eg. in food industry, but it has most basic features needed by average business activity.

Janusz

You should set memory_limit to some bigger value in php.ini, or just in config.php, e.g.:

ini_set('memory_limit', '48M');

Janusz

Just set the price in the target currency for the target price list. Not all can be guessed, nothing can be calculated when there is no data to be calculated from.
Janusz

If you really need this you will have to made some customization in the script.
Janusz

Sales price is guessed from base price list as it is set in company setup, and from home currency, so if you have home currency USD in case of lack of price in GTQ it will NOT be guessed from HNL price. The price is guessed only using default currency and/or default price list. This is how the algorithm works - we can guess price only form defaults, not from any random price in database.

Janusz