[RRowley]

What the error is saying, is that you orphaned records in your si_inovice_item_tax file. That is, you have records in the si_invoice_item_tax file that reference records in the si_invoice_items file that no longer exist.

Verify this is the case by checking a few of the values. For instance, the first record says that there is no si_invoice_items record with an id of 63. Verify this is true. If it is, you can delete the record in the si_invoice_item_tax table with a invoice_item_id value of 63.

You’ll need to repeat this for each of the values specified. I know the list is long, but once this is cleaned up and the foreign key can be created, the foreign key will prevent this from happening in the future.

Let me know how this works out.

[RRowley]

Your database structure contains obsolete settings that need to be cleaned up. The best way I can think of to do this is to:

1) Restore your 2019.2 database. Hopefully you have a backup of this.
2) Export data only, no structure.
3) Delete all the tables in the 2019.2 database. Turn off foreign key checks to simplify this.
4) From you 2019.2 SI software backup, import the “databases/mysql/structure.sql” file. This creates all the tables without any data.
5) Import the SQL file with data only, made in step 2.

Hopefully this all works without an issue. If it does, export this database both structure and data, so you have a copy incase of issues still there. If there is an issue and you can’t resolve it, let me know what it is and we’ll move forward from there.

If all works well to this point and assuming the database name is the same as that defined in your 2023 custom.config.ini file, access your 2023 SI and see if the update errors are resolved.

[RRowley]

Please export the database structure (no data), zip it and attach to reply message for this topic.

[RRowley]

The sinqle quotes surrounding the strings in the values were converted to a different character. I’ll try again and see if it stores correctly.

INSERT INTO si_sql_patchmanager (sql_patch_ref, sql_patch, sql_release, sql_statement, source) VALUES
(330, 'Add invoice_item_id as a key for the invoice_item_tax table.', '20220926', 'ALTER TABLE si_invoice_item_tax MODIFY invoice_item_id INT(11) UNSIGNED NOT NULL, MODIFY tax_id INT(11) UNSIGNED NOT NULL; ALTER TABLE si_invoice_item_tax ADD KEY invoice_item_id (invoice_item_id);', 'fearless359');

This appears to work. Give it a try.

• This reply was modified 1 year, 8 months ago by RRowley.

[RRowley]

Just wanted to verify that the changes that the update terminated on were indeed already present in your database. They are. So with the database at the point where the error occurred, execute the following SQL command to add the entry for the patch to the si_sql_patchmanager table:

INSERT INTO si_sql_patchmanager (sql_patch_ref, sql_patch, sql_release, sql_statement, source) VALUES
(330, ‘Add invoice_item_id as a key for the invoice_item_tax table.’, ‘20220926’, ‘ALTER TABLE si_invoice_item_tax MODIFY invoice_item_id INT(11) UNSIGNED NOT NULL, MODIFY tax_id INT(11) UNSIGNED NOT NULL; ALTER TABLE si_invoice_item_tax ADD KEY invoice_item_id (invoice_item_id);’, ‘fearless359’);

This entry will to SI that that patch 330 has been applied and you can access SI and it will pick up applying the patches following this. Let me know how this works.

• This reply was modified 1 year, 8 months ago by RRowley.

[RRowley]

Via phpMyAdmin, select the si_invoice_item_tax table and export it. Then zip the exported sql file and attach the zipped file to a response to this message. Chances are that the changes in patch 330 have already been applied. I want to verify this before I advise you what to do next.

[RRowley]

The master_2023 version has been updated to better support customer and biller user roles. Along with a couple of non-report fixes, the reports have been modified to only present report links for ones that can be used based on the user’s role name.

Note that master_2023 requires PHP 8.1 or later and is now the default version of SI offered for users to use.

[RRowley]

The new master_2023 version has been delivered. This version requires that a system is using 8.1 or later version of PHP. I am running it on both my development and production sites. I develop on Windows 11 and deploy on a LINUX webserver. Please try it out and let me know how it works for you.

[RRowley]

Sorry for the delayed response. I’ve been invested timewise with two updates delivered for use to. One is for the master_2020 version to formally support globalization of numeric fields. The other is support for systems running 8.1 or later versions of PHP. This is the new master_2023 version.

Work on reports is something I will address in a yet to be determined, future update.

[RRowley]

Look in the Inc/Claz/Util.php file. Find the date method. Notice in the comments the supported date formats. Say you want the long format (ex: May 8, 2024). In the field you mentioned you would have:

field=$invoice.date|utilDate:long

If you need a format other than those in the Util::date method, you would need to implement extension code to do it. View the Extensions topic.

[RRowley]

This is an issue that will take some time to resolve. In the mean time, if you modify the templates/default/payment/process.tpl at line #48 to remove the validate-number class, your payment should work. This bypasses the interactive, at entry time, field validation which is what isn’t honoring your globalization settings.

[RRowley]

Download latest version and see if that addresses your issue. I found and fixed the error where deletion of an existing line item that has associated tax records was failing.

[RRowley]

Refer to the Invoice Templates & Styles topic on the left menu. It explains how you can create your own, personalized printed/pdf invoice template. This allows you to personalize the output as you need to. Also, you can try out other templates included with SI by selection in SI Defaults setting.

[RRowley]

I should have looked up the 3.6.2 section first. I assumed this was the “to” address that you were trying to put multiple addresses in. However the error deals with the email origination fields; from, sender and reply to. Of these only the “from” field is set. If you read the help on the from field, it says specifically that it does not support multiple email addresses. Basically and by default, the from field is intended to be the biller’s email and gets loaded with the biller’s name for the friendly part of the address. Does this address your issue?

[RRowley]

Are you on the latest version of SI? That would be 2020.4.7. I’ve run several tests on it and seems to work OK for me. I will look more into the swiftmailer package that is used for email to see if the error you are porting is a known issue.

[Author]

Posts