File: sales/includes/db/customers_db.inc
Function: get_customer_details()
The mandatory parameter must be a valid $customer_id.
If invalid, it causes an error in line the sql construction portion on line 100:

             AND ".TB_PREF."debtors_master.debtor_no = ".db_escape($customer_id)." ";

You tried to create a quotation without having created atleast 1 customer.

@seend: Try to use the FA 2.3.24+ snapshot and see if the error persists. It might also be that you are using a newer version of PHP that uses the STRICT option which may be disabled in PHP 5.6 but is compiled hardcoded in PHP 5.7 onwards.

@joe: An error should be output when no customer exists if a Document Form depends on it. I thought it was so now.

Instead, just change the Decimal Places for Prices/Amounts to 3 in Setup => Display Setup.

@joe: Kudos. This commit of yours has been quite comprehensive!

If you edited the en_US-new.sql to suit your country, then rename it as your country sql file and upload it to your sql folder in the server and create a new company with it. Expect you will use the stable Euro instead of the STD.

There is a cert8.db file in your Firefox installation / data folder. Delete it. Close all browser invocations and then then open it afresh. The said file will get created with sane working defaults.

It is possible that negative entry flag is enabled in your install (config.php). After receiving stock from your supplier, you may have to check your stocks inventory position and make adjustments as needed. How did you make the delivery to the customer if you had no stock in the first place and how did the invoice get generated?

3,682

(1 replies, posted in Modules Add-on's)

You must logout of the default company and login to the target company (possibly even if both are the same) for which you have enabled it. Then you need to enable Access Roles and Permissions for yourself as Administrator first before the menu items become visible for use.

This could also be a max php variables issue. The default is set at 1000 (3000 in some installations). Increasing this value too should mitigate it. In some php.ini, the max_input_vars variable is missing. Just create it with something like:

max_input_vars = 10000

References:

Link1
Link2


The other way is to avoid variables bloating up in php by unsetting them after use.

Another solution solution is to implode() the array into one long string and explode() it on the server side.

json_encode() could probably work as well.

In Asia we use a "Suspense Account" as the contra entry pending decision of where to post it to. This is also used in entering opening balances as Journal Vouchers - all in one go. The said "Suspense Account" will hold un-reconciled amounts till proper allocation is made from the closing balance sheet.

Suppress Deliver To in reports:

The Deliver To address is obtained in reporting/includes/pdf_report.inc as part of an array. It is then passed on to the $Addr2 array in reporting/includes/doctext.inc file. This array is used in several reports through reporting/includes/header2.inc.

Try to comment out lines 151, 162 and 164 in reporting/includes/header2.inc and see what breaks. These are the places where the said array variable $Addr2 is used in the file.

Suppress Shipping line in reports:

Edit the rep107.php file and place in your company/#/reporting folder to override for the specific company (#).

The No Zero Shipping rep107.php attached herein can be used for all companies - the Shipping will get displayed only if it has a non zero value.

@joe: want to put it into the FA 2.3 core?

3,686

(12 replies, posted in Reporting)

I shall assume that you have your language strings translated correctly in your forms and reports now.

The order_no (I do not find any order_id field in FA, there is however, a workorder_id field in FA)  field gets a system generated value that should generally come from the auto_increment value in the table but here this field is not auto_increment type. The ERD in the Wiki is self-explanatory. It is possible that one more than the highest allotted number for the invoice type record is used as the next one as far as the order_no field is concerned. Attempting to change the value in the order_no field for the last order in both sales_orders and sales_order_details tables to say 99 will make sure that the next invoice gets generated with order_no as 100.

Also note that many different order_no records can get billed from a single invoice whilst some may not get billed at all. In reality, there is no direct invoice generation at all in FA and the order_no is an internal relational field only. Even in Direct Invoice, the steps of preparing the Order and then making the invoice are automated and not that the former is skipped.

3,687

(4 replies, posted in Wish List)

Yes, you probably will need to edit them before sending it too. Creating an configurable Alert feature is in order as it is an important functionality for FA - it can probably be done without any tables / fields being added. On login, if there are any recurring invoices, just provide an alert popup - if it is the first login for the user for the day - and optionally restrict it to the admin users alone!

3,688

(12 replies, posted in Reporting)

I assume you are using the Spanish (Panama) Language (es_PA) file. The latest .po and compiled .mo files are here and they can replace the ones in your lang folder. The IVA => ITBM changed version is attached in this post that you may unzip into the lang/es_PA/LC_MESSAGES folder.

Any changes to the standard .po file for translation variations needed can be uploaded somewhere and link pasted here for making the .mo file in case you are unable to follow the wiki instructions.

Setup => Forms Setup is where you put in the next Invoice Number and other FA document numbers.

Check the Tax Name for IVA (7%) and change it there as well in the tax_types table. There are a whole lot of Account Names like "Hacienda Publica IVA soportado" in the chart_master table and also chart_types table where you might want to replace IVA as well. Just take a backup of the database and then do a search and replace of IVA to ITBM in a case sensitive manner and hope nothing breaks or do it one by one.... and then upload and restore the changed version.

3,689

(4 replies, posted in Wish List)

Recurring invoices are sent automatically isn't it?

3,690

(6 replies, posted in Setup)

Please read the wiki:
1. https://frontaccounting.com/fawiki/index.php?n=Devel.EMailIssues - Multiple Contacts EMail
2. https://frontaccounting.com/fawiki/index.php?n=Main.Installation - Windows XAMPP Mailing

EMail is sent using the email class in reporting/includes/class.mail.inc and the "new email" object instance is called only in inventory/includes/inventory_db.inc and reporting/includes/pdf_report.inc. These are the files where you will find the message and/or message argument that can then be used to trace the message per se to make alterations.

3,691

(6 replies, posted in Accounts Payable)

Cash Supplier Account is the Payment Account should be Petty Cash. Whilst the expense account / asset account is the contra one as the case may be (if written off or capitalised respectively).

3,692

(8 replies, posted in Report Bugs here)

FA does not support Foreign Key Constraints like CASCADES as yet not even in FA 2.4 for now. Foreign Keys are however used in joining tables and extracting requisite data using BEGIN-ROLLBACK/COMMIT-END constructs.

Yes, MySQL is a Mickey Mouse DB and that is why it is popular - low / no learning curve and FREE - does not require a job in an MNC or any degree or qualification / certification to teach and use. MySQL still does not support function based indexing / constraints. It has no record number concept for end user usage and relies on primary keys alone instead. And yet it costed billion(s) to be purchased by the vendors of expensive databases! Governments in India, China and Russia (a lot of developers came in from there) were not consulted (only US / EU permitted them) before the purchase was authorised and certainly no major developer persons were asked their permission either.

Shouldn't there be a ban on sale of Open Source projects?

I do hope FA does not get sold any time soon - if it is going that way, I hope sufficient notice is given to the users / developers to fork and co-exist.

@bobloblian: Thanks for the example and solution. Wiki-ed it.

3,694

(10 replies, posted in Report Bugs here)

Thanks for the feedback. I was wondering where the ruc_no came from....

You may henceforth refer to the various extension modules - Charts, Extensions, Languages and Themes - by linking to files in my unofficial GitHub repo's extensions folder or your fork of it. In this case it would be:

Default American coa (5 digits)
US chart of accounts for service company.
Spanish COA - ISO

@joe: Whilst the selection of codes presented are actually accountant friendly, consider for a moment an inadvertant prefix of one or more zeroes to a regular account say: 790, as 0790, 00790, etc.

Hence use varying multi digit / character account codes with care to be accountant friendly.

3,696

(8 replies, posted in Report Bugs here)

You might want to upgrade to FA v2.3.24+ (snapshot).

The demo url has decimal point and differing no. of digits as well in Account code. I only hope that the "+" and "-" signs are not allowed as range choice would go haywire in reports. Also 1200 and 12001 are different as also 790 is different from 0790 - all sorted as strings..... Therefore say in rep 704 (GL Account Transactions) for a range of Account Codes from 700 to 800, 790 will be included but not 0790. Happy confusion with leading zeroes and decimal points!

Lines 129-130 from config.default.php in FA 2.3:

    /* allow alpha characters in accounts. 0 = numeric, 1 = alpha numeric, 2 = uppercase alpha numeric */
    $accounts_alpha = 0;

The account are per default set to be numeric.

chart_master.account_code2 can hold the alternate alphanumeric account code if necessary to interface with other applications. It is used in rep701.php other than when primary record is added/updated.

3,699

(10 replies, posted in Report Bugs here)

Since you are using cPanel, you might want to check if the username prefix is there - generally it will be your cPanel username with an underscore and then your actual username. The same may apply to your database as well. If you are able to login correctly, then your database is working okay.

Replace all instances of ruc_no with gst_no and R.U.C. No: with GSTNo: in your suppliers.php file. Looks like there is something wrong with your FA php files itself. The suppliers table is missing the supp_ref field and the gst_no field is wrongly named ruc_no.

DROP TABLE IF EXISTS `0_suppliers`;
CREATE TABLE IF NOT EXISTS `0_suppliers` (
  `supplier_id` int(11) NOT NULL auto_increment,
  `supp_name` varchar(60) NOT NULL default '',
  `supp_ref` varchar(30) NOT NULL default '',
  `address` tinytext NOT NULL,
  `supp_address` tinytext NOT NULL,
  `gst_no` varchar(25) NOT NULL default '',
  `contact` varchar(60) NOT NULL default '',
  `supp_account_no` varchar(40) NOT NULL default '',
  `website` varchar(100) NOT NULL default '',
  `bank_account` varchar(60) NOT NULL default '',
  `curr_code` char(3) default NULL,
  `payment_terms` int(11) default NULL,
  `tax_included` tinyint(1) NOT NULL default '0',
  `dimension_id` int(11) default '0',
  `dimension2_id` int(11) default '0',
  `tax_group_id` int(11) default NULL,
  `credit_limit` double NOT NULL default '0',
  `purchase_account` varchar(15) NOT NULL default '',
  `payable_account` varchar(15) NOT NULL default '',
  `payment_discount_account` varchar(15) NOT NULL default '',
  `notes` tinytext NOT NULL,
  `inactive` tinyint(1) NOT NULL default '0',
  PRIMARY KEY  (`supplier_id`),
  KEY `supp_ref` (`supp_ref`)
) ENGINE=MyISAM;

RUC [General/National Taxpayers Register by its acronym in Spanish] Nr.

Which CoA are you using and from where?

Google Translate. Worked on disease classifications for care2x project.....

There is one post where there was some comparison of account codes and some errors crept in. In fact the UK CoA had to be modified to start with 1 instead of 0. Better safe than sorry. Also please check the order of the fields if they match the en_US-new.sql - the UK CoA had to be corrected to comply - the official UK CoA pkg still has these errors but my repo has it corrected.

You might want to use my version of the en_US-new.sql - basically make for dynamic fiscal year, removal of redundant indices and inclusion of speed up indices besides currency symbols.

Probably @joe is right if alphanumeric account codes are enabled and used but most users will not bother to change the defaults in the config file! Also URL GET parameters are safer handled with numeric codes when interfacing with third party applications.