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

[RRowley]

Make sure you have the intl extension defined in the php.ini file. Restart your web server after changing.

[RRowley]

Not sure what is going on. There are a few things I’d like you to update to the latest SI version and check again. Likely won’t change anything but then we are working from common code. Let me know either way. If the problem still occurs, I’ll put together some changes to display data to try and drill into what is going on.

[RRowley]

The most likely case is that the si_invoices owing field has been zeroed out. You can set this field to 1 in records to force SI to recalculate the owing field for display purposes. It will also allow you to do payments from the invoice manage screen.

This slows down processing as the owing value is recalculated for all invoices; paid off or not. If you enter the edit screen for invoices with payments due and save them without making changes, the owing field will be properly set. If you does this for all invoices that are outstanding, you can then change all those with an owing value of 1 back to 0 so they no longer force the recalculation.

You can use phpMyAdmin to set the owing field to 1:

UPDATE si_invoices SET owing= 1 WHERE 1

Later you can use phpMyAdmin to set the owing fields with a value of 1 back to 0:

UPDATE si_invoices SET owing= 0 WHERE owing = 1

• This reply was modified 2 years ago by RRowley.
• This reply was modified 2 years ago by RRowley.
• This reply was modified 2 years ago by RRowley.

[RRowley]

You need to restore your database to what it was before you loaded the master_2020 update. Hopefully you exported the 2019.2 database and have the sql file to do the restore. You can drop all the tables in the database, then import the sql file of your 2019.2 database.

Next in the file, include/init.php, find the line (about line #61):

$databasePopulated = $patchCount > SqlPatchManager::BEGINNING_PATCH_NUMBER;

and change it to:

$databasePopulated = $patchCount >= SqlPatchManager::BEGINNING_PATCH_NUMBER;

Now access your database again and it should let you apply the patches for 2020 and go forward from there.

[RRowley]

Need to check if you have a database table named si_products_values. The error says you don’t. Now check if you have a table named si_products_attributes_values.

If you don’t have either table, create the si_products_values table and try SI again.

If you have the si_products_attributes_values table then insert the following to the si_sql_patchmanager table:

FIELD NAME           VALUE
sql_patch_ref        324
sql_patch            Rename si_products_values table to si_products_attributes_values
sql_release          20210527
sql_statement        ALTER TABLE si_products_values RENAME TO si_products_attributes_values;
source               fearless359

Adding this to the patch table will tell SI that this patch has been applied.

Let me know what you find and how this works out.

• This reply was modified 2 years, 2 months ago by RRowley.

[Author]

Posts