Forum Replies Created
-
Posts
-
Are you running master_2020 version? If so, my last update was to add code to set up the index file and numbering from the INV PREF maintenance screens. I will be updating the documentation in the knowledge base to reflect these changes soon.
If you are on master_2020, download the lasted version and see if it helps.
Sorry it took so long. I had to complete work I was doing on master_2020 to get back to master_2019.2. Anyway, I’ve attached a zip file with three files that go in your Inc/Claz directory. I took a different approach than you did but I believe it implements the changes needed. If you could test this and let me know how it works.
These are the records at issue (from the attached zip file):
FOREIGN KEY TABLE COLUMN REFERENCE TABLE COLUMN INVALID VALUE ------------------------ ------------------ ----------------------- --------- ------------- invoice_items invoice_id invoices id 1 invoice_items invoice_id invoices id 2 invoice_items invoice_id invoices id 3 invoice_items invoice_id invoices id 4 invoice_items invoice_id invoices id 12 payment ac_inv_id invoices id 2 payment ac_inv_id invoices id 3These records are orphaned, they have no associated parent records. For the si_invoice_items records, you can check them in the database and verify the the index_id in each of these records does not exist in the si_invoices table. Similarly for the si_payments records you can verify that the ac_inv_id does not have a corresponding record in the si_invoices table.
Once verified, your choice is to delete the orphaned records or to manually create an si_invoice record with an id matching the orphaned records.
Once this is done, the patch process will complete.
I suggest you try updating to the master_2019.2 version. Follow the instruction under the Version Update Process topic on the left. If you could load your current version on your local PC first and run this update there, it will help you work out any issues you run into.
The primary issue you might encounter is the patch that implements foreign key support in the database. This patch checks your database for orphaned records (such as a si_cron_log record with no associated si_cron record). The patch process will stop if it finds any orphaned records. It does list the issues found and typically the solution is to delete those records and then run SI again so the patch process can complete.
Since you are running with a version of PHP 7.3, you will stay on this SI version. However, if your cpanel allows you to maintain your PHP version (as mine does), you might consider updating to PHP 7.4+. If your SI application is the only thing running on your host, this should be straight forward. If you have other sites running on your host, you need to make sure they will support the change. Once on PHP 7.4+ you can install master_2020 which will get you on the most current version of SI. Also, you should notice a significant performance improvement.
Let me know how this goes.
Are you using the default pdf or your own? Also, what is the product description that you are printing? Maybe provide a screen shot of the product record and of the messed up pdf.
The “to” field is set to the customer and/or the biller email depending on the option to send to either one or both in the recurrence record.
The error for the tax_id field is a bug in the code. I’ve attached new Email.zip file that contains updated Email.php and Invoice.php files. The first removes the debug statements I added in the previous change, but the Invoice.php contains a fix for the tax_id issue. Extract both of these to the Inc/Claz directory.
At this point, I’m not able to test that changes, so I ask that you do and let me know the result so I can hopefully at them to the next version of 2019.2
The email body is automatically set by the code. I don’t think that is the problem. However, I don’t know which field is empty. I’ve made a modified version of the Email.php file that will put info in the tmp/log/php.log (aka error log) file indicating which email field is empty.
Extract the Email.php file from the zip file and save it in your Inc/Claz folder over the version that is there. If you run cron, you can see what it puts in the error log and let me know.
See instructions in image file.
Attachments:
You need to make a custom template. The instructions I mentioned tell you how to initially set this up. You can copy the default directory to a new directory named for example, “mypdf”, and then modify line 35 of the template.tpl file and change
{$invoice.date|utilDate}to{$invoice.date|htmlSafe}.PDF’s are an exception to the rule. They contain their own code to display values and any changes you want to make require you to implement a customized version. Check out the directions for the Invoice Templates & Styles menu link to the left.
Check the tmp/log/php.log file for error detail. You likely have orphaned records that prevent foreign keys from being added. The error information will tell you what they are as well as provide an example of how to correct them. If zip the error log file and attach it here, I can look at it an advise what to do. Make sure there is not secret info in the error log before attaching it.
I’ve standardized the date format displayed on screens to the database format, yyyy-mm-dd. The value on the invoice, expense and payment view screens had been missed. The most recent update, Version: 2020.0.11, corrects this.
If you want a difference format for the printed invoice, you’ll need to develop a custom template.
Thanks. Fixes for this issue have been uploaded on github. Update to that version to get them plus other changes for datatables library security issue fix.
Please try the following:
In the templates/default/customers/create.tpl file, find the “SELECT” statement for the “parent_customer_id” field. Approximately line 125. Modify the line following the “SELECT” statement remove the value setting of blank, so it looks like this:
<option value></option>If that works for you, I’ll make it a permanent fix.
Recent Comments