[RRowley]

Make you sure you have directory, “public”, with access 755. You can also look in the tmp/log/php.log file to see if there is a better explanation of the error.

[RRowley]

First, check the settings in si_preferences. The logic assumes that the pref_id == 1 record has the pref_description of “Invoice”. That is, all “Invoice” type entries in the si_invoices table has a preference_id of 1. If this is the case, then in si_invoices, set the last_activity_date to “2020-01-02 00:00:00” and the aging_date to “2020-01-01 00:00:00” where preference_id == 1.

This should cause the aging and owing information to be recalculated when preference_id 1 invoices are accessed. This will be done in bulk for all invoices the first time you log into SI and it builds that invoices select table. If you have a lot of records, then you will notice a delay while the update if performed the first time. After that, only records that have activity or show amounts owing go through a calculation.

[RRowley]

Don’t think there is any way to do this via the new invoice url.

[RRowley]

Fix display to handle HTML codes. Update is available on github.com. Version 2019.2.14 20200114.

[RRowley]

Do you really have localhost email server setup and running? If so, what is it?

You can use a remote server like gmail if you have and gmail account. Here are the settings for that>

email.host = smtp.gmail.com
email.smtp_auth = true
email.username = your-gmail-username
email.password = your-gmail-password
email.smtpport = 465
email.secure = SSL
email.ack = false
email.use_local_sendmail = false

[RRowley]

Typically a set up issue. Without giving me your username and password, what are the other settings for email in the config/custom.config.php file?

[RRowley]

I tried your set up. Correct that amount is truncated to two decimal places but that truncated amount does print on the invoice correctly.

[RRowley]

Why include taxes in the unit price? What is the reason you can’t use the taxes feature of SI?

[RRowley]

Concern about the fax field. It is a field with a specific function. Believe it or not, fax capability still exists and is used. A better field would be to use a custom field. These are user defined, and if you use field 1 but another user already used field 1, then they could easily update their form to use field 2, etc.

[RRowley]

This is a beautiful template. It also worked first try after loading it. There are two ways I can think of to include it. One is to make it the new default template. The other is to modify the .gitignore file to allow specific template directories to be included in the package. I’m inclined to do the later. One, it doesn’t disrupt people using the default who are satisfied with it. Second and more important, it is a way to allow others who want to contribute professional templates to the package to have them included. So I plan on including it as a directory option that can be selected in place of the default. Thank you again for this contribution.

[RRowley]

Thank you for your contribution. I’ll review what you’ve provided and see how it might best be shared.

[RRowley]

I encourage you to use the master_2019.2 version to make sure you have the most current corrections as well as working with a version that more easily supported. That said, is there additional information about this error in the tmp/log/php.log file?

[RRowley]

Please be specific as to the items set and the values they were set to so I can replicate and test it.

[RRowley]

In the templates/default/cron/add.tpl file on line 114. Remove the “/” before the terminating “>” sign. So this:
<input type=”hidden” name=”domain_id” value={if isset($domain_id)}{$domain_id}{/if}/>
becomes this:
<input type=”hidden” name=”domain_id” value={if isset($domain_id)}{$domain_id}{/if}>

[RRowley]

There is some database setting the is not allowing an empty string to work as the same as the numeric 0 default value for a field. The si_customers table default_invoice field is int type and has a default value of 0. The update command was sending in an empty string (”) when this field was not set. This caused an error to be thrown. This default works on my database but not yours which is why I think it is some DB setting that differs on you set up vs mine.

I updated the customer update screen to send a 0 in for this field. This change has been uploaded to the SI version github. The new SI version is 2019.2.11. You can copy the templates/default/customers/details.tpl file from github and replace the one on your install. See if that helps. If so, you should pull the entire update and replace what you have so the the version and other info gets updated also.

While this might fix the customer update, you might encounter a similar issue on other screens. So determining the database setting that lets mine work and yours not, will be the best all around solution. I’ll keep checking to see if I can find this.

[Author]

Posts