• From: Nicaragua, Leon
  • Registered: 05/12/2012
  • Posts: 74

Topic: Invoice not printing in 2.4.14

We have been using FA for more than 10 years now, and are happy with the programme. Currently on 2.4.4 with php 7.3. As we want to update our server (Linux Mint 19) to Mint 21, we have the challenge of how to handle php8. Trying with a fresh install with American 4 digit COA), we get problems when trying to restore the backup. So I thought it might a good idea to start updating to 2.4.14 before updating the OS, as I understand 2.4.14 should be compatible with php 8.
The install of FA 2.4.14 with php 7.3 apparently works well, and restoring the backup from 2.4.4 gives no error. All data seem to have been restored. We can print accounting reports in both pdf and excel, but it is for some reason not possible to print an invoice. We get the error: "You have missing or invalid sales document in database (type:30, number:20131)". Not clear to me where that document should have gone, or why ti should suddenly be invalid. Any hint on where to look for a solution?

thorbjornw's Website

  • rafat
  • Senior Member
  • Offline
  • From: UAE, Dubai
  • Registered: 11/28/2017
  • Posts: 550

Re: Invoice not printing in 2.4.14

In database
trans_type 30 is a Sales Order
order_no is the Sales order number.

You will find the above in database tables xx_sales_order.
so look for trans_type =30 and order_no=20131 combination.

OR

From within FA

Sales->Sales Order Enquiry -> #=20131 and see what you can do.

rafat's Website

  • From: Nicaragua, Leon
  • Registered: 05/12/2012
  • Posts: 74

Re: Invoice not printing in 2.4.14

Thanks for your reply. Searching in the database, this transaction is simply the last invoice. Deleting it doesn't help. Strange.

thorbjornw's Website

  • From: Nicaragua, Leon
  • Registered: 05/12/2012
  • Posts: 74

Re: Invoice not printing in 2.4.14

So I guess it simply tells me that it didn't succeed in generating a valid invoice. So it doesn't bring me further to understand why I can't generate an invoice.

thorbjornw's Website

  • rafat
  • Senior Member
  • Offline
  • From: UAE, Dubai
  • Registered: 11/28/2017
  • Posts: 550

Re: Invoice not printing in 2.4.14

Try with debug on. See if anything in the logs.

rafat's Website

  • From: Nicaragua, Leon
  • Registered: 05/12/2012
  • Posts: 74

Re: Invoice not printing in 2.4.14

Thanks for the proposal. Now I get the following message in the FA error-log:
25-Dec-2022 11:31:30 America/Managua] 0:admin:connect_db_mysqli.inc:68: Unhandled exception [1364]: Field 'fiscal_year' doesn't have a default value.
[25-Dec-2022 11:31:35 America/Managua] 0:admin:sales_order_db.inc:103: Trying to access array offset on value of type null
[25-Dec-2022 11:31:35 America/Managua] 0:admin:connect_db_mysqli.inc:68: Unhandled exception [1292]: Incorrect date value: '' for column 'gl_date' at row 1.
I have checked the fiscal year in the configuration file, and it is correctly defined as 2022. The date format is configured as DDMMYYYY, and that is also what appears in the invoice (that won't print).
Any suggestion?

thorbjornw's Website

  • rafat
  • Senior Member
  • Offline
  • From: UAE, Dubai
  • Registered: 11/28/2017
  • Posts: 550

Re: Invoice not printing in 2.4.14

For me its a difficult problem to crack as I dont have enough programming background.
See
https://frontaccounting.com/punbb/viewtopic.php?id=8242
It might help.

rafat's Website

  • From: Nicaragua, Leon
  • Registered: 05/12/2012
  • Posts: 74

Re: Invoice not printing in 2.4.14

Thanks for the link. It apparently solved the issue:

+++ b/core/includes/db/connect_db_mysqli.inc
@@ -10,7 +10,7 @@
     See the License here <http://www.gnu.org/licenses/gpl-3.0.html>.
 ***********************************************************************/
 define('DB_DUPLICATE_ERROR', 1062);
-define('SQL_MODE', 'STRICT_ALL_TABLES'); // prevents SQL injection with silent field content truncation
+define('SQL_MODE', ''); // well tested

So I deleted STRICT_ALL_TABLES and kept the
define('SQL_MODE', '');
Thanks for the hint. I would never have found that. However, not sure whether the STRICT check means that there is something wrong in our DB. I hope not.
smile and smile

thorbjornw's Website