[RRowley]

While this inquiry is in process, copy the public/data.json file to zip and attach. Next, in phpMyAdmin, access the si_system_defauts table and export it to zip and attach. Then make a zip file with the data.json, exported si_system_detauls sql file and the templates/default/products/manage.tpl files. Attach the zip file to a response to this message.

[RRowley]

Give me an export of the si_preferences file and the localLocale, localCurrencyCode and localPrecision settings from the custom.config.ini file. I’ll see if I can replicate your set up.

[RRowley]

Sounds like you have a definition of “fun” similar to mine. Good luck.

[RRowley]

Find the invoice in the si_invoices table and set the owing field to 799. That should correct this.

[RRowley]

I forgot to a a COMMIT; line at the end of the sql file. So I’ve attached an update version with this message.

Attachments:

1. foreignKeyConstraints-1.zip

[RRowley]

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         2

Basically 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.

Attachments:

1. foreignKeyConstraints.zip

[RRowley]

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.

[RRowley]

The file you included was named incorrectly. It should be custom.config.php rather than config.custom.php.

Once I corrected this, it converted correctly. I’ve attached the converted ini file in case you just want to use it.

Attachments:

1. custom.config.ini_.zip

[RRowley]

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.php to 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 = false setting back to true. This will prevent someone else from running this file on your site.

[RRowley]

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.

[RRowley]

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.

[RRowley]

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.

Attachments:

1. Email_Fix.zip

[RRowley]

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         3

These 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.

[RRowley]

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.

[RRowley]

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.

[Author]

Posts