Search options (Page 7 of 97)

Please use the author/maintainer email found in the package info to address such issues in publishes packages in the future, there is no warranty the extension author read this forum.

BTW While it may seem a little redundant to your eyes, both forms are proper and one could judge the current one is even more canonical. This ise disputable, but anyway outside interest of most forum users. Therefore I think this is another good reason to address such notices directly to the author.

Janusz

No, this is not supported in current FA version, but you can try implement it yourself, or hire any software developer. This should not be hard to achieve.
Janusz

This is latin2 encoding related fix which is used  not only for polish language. Probably the same problem could arise for other encodings not supported by htmlspecialchars(). For now nobody was interested in contributing any translation which use encoding other than  latin1, latin2 or utf8 (see list of avilable languages), so frankly I don't care about that. The patch fixes the problem for all currently supported languages, and this is safe minimum.

Janusz

This fix is related to your specific situation, when you have changed  database server to other one with different encodings, so cannot be included in FA. Nevertheless planned FA 2.4 version will change default  database  encoding to utf-8, and will migrate database properly.
Janusz

Check if your language is visible o Install/Update Languages screen with the checkbox checked. If not, your system does not support your langauge.
Janusz

1. Exchange rate is get from selected web source when first transaction on the day made in given currency is entered. So, if you do not make transactions on every day, you will not have complete exchange rate tables.
2. Every FA user have some POS setup selected. The setup defines which sales options are allowed for the user. POS options seems to be selfexplanatory.
Janusz

No, such setup is not available in FA, and would be hart to implement as module. You will need customize core source code.
Janusz

Just entry it on Items page as a Service if don't want to register it as regular inventory item. Then you can issue invoice as usally.

If you are looking for help here you need to describe the issue a little more precisely than just as  'strange behaviour'.
AFAIK there is no clairvoyant here on the forum.
Janusz

No, this is just  formatted string marker added by original gettext suit command msgfmt. As this is just a comment it should not hurt anyway.
Janusz

Please look closer on the check_bank_account_history() algorithm. This function scans all the bank history to find whether atomic change in balance made on some date is safe or not.

If you try implement transfer edition as void/entry sequence in general you have take into consideration two dates:
1. original date for which old transaction is voided (check against -ve balance in target account);
2. new date for which new transaction is entered (check against -ve balance in source account).

In addition you should consider special situation, when only amount changes (but from/to account and date don't): in this case only change in amount on the old transaction date should be tested, otherwise you can have 'false positive' results in case of small change made on big transfer amount.

Janusz

Consider following simple scenario:
1. Create new Bank Account of cash type;
2. Transfer $100 to this account from any other account;
3. Entry $60 payment to supplier from the cash account;
4. Edit transfer created in step 2 changing amount from $100 to $50

and you will end with -$10 balance on the cash account without any warning nor error.
The same negative balance issue you can trigger by simply changing target account to any other one during edition.

Regarding the zero entries displayed in bank account inquire they just should be omitted in Bank Inquiry listing. This can be achieved by sql modification in get_bank_trans_for_bank_account() function.

Janusz