Search options (Page 228 of 240)

Use a different pricelist.

Thanks Joe,

The change set 3130 is reproduced here to help detect and fix similar errors:

--- old/purchasing/manage/suppliers.php    Thu Oct 04 13:09:47 2012
+++ new/purchasing/manage/suppliers.php    Sat Jan 05 10:17:23 2013
@@ -214,7 +214,7 @@
                 $_POST['website'], $_POST['supp_account_no'], $_POST['bank_account'], 
                 input_num('credit_limit', 0), $_POST['dimension_id'], $_POST['dimension2_id'], $_POST['curr_code'],
                 $_POST['payment_terms'], $_POST['payable_account'], $_POST['purchase_account'], $_POST['payment_discount_account'],
-                $_POST['notes'], $_POST['tax_group_id'], @$_POST['tax_included']);
+                $_POST['notes'], $_POST['tax_group_id'], get_post('tax_included', 0));
             update_record_status($_POST['supplier_id'], $_POST['inactive'],
                 'suppliers', 'supplier_id');

Thanks Janusz.

Looks like the said function is disabled in your php.ini - contact your system admin or see if your apache httpd.conf / .htaccess can be configured to allow it.

Please use the latest version of FA from the development repository if you are starting anew as many bugs have been fixed and not released as yet.

FrontAc_default_Mer_3127_2012-12-20.tar.gz.

Check out the release post.

If I understand your needs, you have an offline database table containing Journal Entries that need to be sucked into the FA system when it is used for the first time in a day (or in specific time period) or on demand.

This is easily achieved using a function that kicks in thru includes/main.inc.

You can also build a standalone script that reads what the remote journal entry last voucher number is and checks with the local FA system of last imported remote voucher number (reference number) to decide if an update is in order and does the import of the recent records only.

The standalone script can be scheduled to be exectuted at whatever frequency necessary thru a cron job.

If the remote journal entries exist in another FrontAccounting Server, then use any RESTful API like the SimpleAPI.

Please be specific about which version of FA you are using and on what platform (from the looks of your path, it appears to be some shared linux hosting).

I suggest you use the FA v2.3.13+ latest Mercurial Build available.

You can use the 5 digit COAs.
Or start from scratch.

You have a choice of Arabic Fonts installable at:
https://frontaccounting.com/wbt/pages/download/download-release-2.3.php

Check the wiki for encodings, PDF settings, etc., at
https://frontaccounting.com/fawiki/index.php?n=Help.InstallUpdateLanugages

Good Luck.

Will need a bit of work to get it fully working. Check the wiki link in my previous post for the current state.

Currently the following are observed:
1. Create new block works.
2. Create new function works and the code gets stored anew as the htmlentities version that is acceptable as long as no single quotes are used.
3. Test button in create new function does not work when any quote - single or double - are used. It works for any function with nothing after the function name - assuming that the function exists as part of some include(d) file.
4. Create new report results in only the report info, select and group entries being stored and the items and graphics are not stored nor are they editable - possible glitch due to db_query["BEGIN"] being used with no db_query["END"] but just a db_query["COMMIT"] assuming even that stored procedure / trigger rights are available for the MySQL user.
5. On the reports listing page, if we run any report, then subsequently all other buttons - Edit, Delete, Copy - also just run the reports.

Preliminary code reading / divining suggests that
1. some cache / globals parsing issue is involved in 5 above.
2. globals missing out on report id when passing to the strings and graphics page in 4 above. A mixture of POST and GET besides conflicting cleaning of GET and POST duplication efforts may be involved.
3. multiple escaping of quotes and / or php.ini settings different from the recommended ones being in use in some parts of the code in item 3 above for eval issues.

All Edit is done by deleting the existing record and inserting a new one in it's place - this can be more efficiently done using an update statement. "Update on insert fail" type of construct will fail as there is no primary key and the "where" can be ambiguous.

Wikied the above.

Attached here is the v2.3.13-1 version of the repgen Report Generator Extension incorporating corrections done so far.

Includes 2 fixes for the tab succeeding an "=" sign and preceeding a gettext translation "_("xxx").

Includes extra page sizes (but stays commented out) in the repgen.inc file

Fixed the manual.html for wrong link and removed the form tags in it.

reports.sql - cleaned up and organised by typ and id with standard delimiters with fields of double quote.

There are many statements like:

$query="INSERT INTO xx_reports VALUES ('".$id."','info','".$info."')";

in the repgen extension that need to be wary of single quotes getting into the strings like $info....