Forum Replies Created
-
Posts
-
I forgot to a a
COMMIT;line at the end of the sql file. So I’ve attached an update version with this message.Sorry to tell you this, but you probably have a data base that does not have the proper foreign keys enabled. It will work, but you won’t be protected from orphaned records.
The 318 error you had is telling you that you have orphaned records in your database. This is what was in your log:
FOREIGN KEY TABLE COLUMN REFERENCE TABLE COLUMN INVALID VALUE ------------------------ ------------------ ----------------------- --------- ------------- user domain_id user_domain id 4 user domain_id user_domain id 3 user domain_id user_domain id 2Basically this is telling you that there are three records in the si_user table with the domain_id set to 2, 3 and 4 which do not have parent records for those domains in the si_user_domain table. The best solution is to create these records in the si_user_domain table and run the master_2019.2 installation again; assuming you can back up that far.
If you can load back to where you were prior to loading master_2020, this is what you should do. This way, the foreign key constraints implemented in patch 318 will succeed and every thing will be hunky dory.
Otherwise, you can make the fix above and import the sql file in the attach zip file which hopefully, will apply all the foreign key constraints to you master_2020 database.
Let me know how it turns out.
Typically you would have Set Aging enabled for your invoices. Otherwise, you won’t get any aging information in the Aging column. You might want to disable it on Quotes, Estimates, etc. because you aren’t looking for past due information on those invoices.
Were any errors reported to the tmp/log/php.log file? If so, I’d be interested in looking at that file. You would need to zip it in order to attach it.
I’d also be interested in knowing what happens if you set the Invoice INV PREFS record Set Aging field to Enabled.
The file you included was named incorrectly. It should be
custom.config.phprather thanconfig.custom.php.Once I corrected this, it converted correctly. I’ve attached the converted ini file in case you just want to use it.
In the primary SI directory, there is a phpinfo.php file. Change the
$secure = true;setting to false. Then run this by entering the same thing you do to run SI but add/phpinfo.phpto the end of the line. For example:
https://localhost/simpleinvoices/phpinfo.php
This will list the settings in your php.ini file. At least then you will know what settings you have.Be sure the change
$secure = falsesetting back to true. This will prevent someone else from running this file on your site.Please make a copy of your custom.config.php file with any personal info (passwords, etc) changed to innocuous values. Then zip this file and attach it to this thread. I’m not sure why you got the error you did but want to test it myself.
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:
Recent Comments