Search options (Page 32 of 97)

The payment should be done via Payments to Suppliers. If you do not see the change on bank account just  check your setup (does the bank account use GL account you check for changes? is the payment date ivalid i.e. in any fiscal year?)
Janusz

You should first  set GRN clearing account in 'System and GL General Setup'
Janusz

Ok, guys. Version 2.3.9 including all last fixes has been released today.
Thank you all for cooperation.

liahsheep, special thanks for pointing out the exact source of the problem .

Janusz

Thanks for isolating the problem. The $min_level conditional value was introduced in 2.3.8 due to another bug causing infinite loop during remote repository interaction. Seems php behaviour changes in this aspect with minor version number change, so we have to make another countermeasures. Please test following new version of end_flush() function located in erros.inc:

function end_flush() {
    global $Ajax, $transaction_level;

    if (isset($Ajax))
        $Ajax->run();

     while(ob_get_level() > 1) ob_end_flush();
    @ob_end_flush();

    // if any transaction was aborted unexpectedly rollback changes
    cancel_transaction();
}

If this code works well, we will release new bugfix FA version ASAP.
Janusz

No.
Janusz

Probably you have misconfigured php/www server installation, so the session files are not properly written to the disk. I have no experience with windows family systems, so there is small chance I could help. Anyway check why the file mentioned in the message cannot be deleted by www server process. I guess this is some permitions related problem.
Janusz

I guess you want to you use Slovenian locales rather than Polish, so better choice for you is sl_SL.ISO-8859-2 .
Location of locale can vary depending on Linuz distribution, so RTFM:

man locale-gen

Janusz

I personally prefer git to manage multiply FA versions. As other developers work on windows we have decided to keep the code in Mercurial repository which seems to have better windows support. This decision requires me to use also git-hg extension. This is in fact one way integration (not very handy to push changes back to the repo), so I would advice just to use hg for new developers if you are not addicted to git as I am .
Janusz

Maybe. This is not the case on my Linux box using php 5.3.3 where memory usage floats about 1-1.5MB. I guess this can be some version related php issue?
Janusz

FrontAccounting presume that order is binding agreement with your customer, so if you want to enlarge delivery ad then invoice you have to first change sales order or entry an additional one.
Janusz

I have explained all the reasons in our mail discussion. If you still say there is no reason to not apply your weak patch to FA core sources, this is probably because you do  not want to understand the reasons. Probably  you should just read our correspondence again.

To help you and other peoples to understand rationale behind the decision, I will repeat them in short here:
. the patch has ignored current FA users which use ISO encoded data by years completely. The only advice from author of the patch was: DIYusing iconv. This definitely is not the way we provide backward compatibility in FrontAccounting;
. using UTF8 instead of any single byte encoding like ISO-8859-* enlarges generated pdf reports enormously, in order of MB. This is not acceptable for many FA users using the application on weak and/or expensive (GSM) connections;
. the only problem with current UTF-8 support appears in arabic environment (ar_EG locales). We have received no claims about using UTF8 in other languages like georgian or chinese. So, I'm still not sure the problem is really in encoding used (however it is probable).

I have tried to solve the problem reported by Excellence some time ago, unfortunatelly without success. After studying provided patch,  I doubt it is the real fix for the problem reported, but have found the changes adopted as they are would be great pain in the *** for current FA users.

Again, we are ready to adopt any improvements in utf8 support unless they will hurt peoples using other encoding. In near future we will improve FA repository system to support more than one encoding for any locale. Hope it will be inviting for further development toward better utf8 support.

Janusz