[RRowley]

It looks fine to me using the settings you gave. There is a problem in the rendering of the amount fields in the first section not interpreting, £, as the British Pound sign. But otherwise, the rendering looks pretty much the same in the Export to PDF, and the Print options. I also checked the PDF attachment on the email. All looked fine. Here are the settings I used.

In config/custom.config.ini:

[exportWordProcessor] => doc
[exportPdfDefaultFontSize] => 7
[exportPdfPaperSize] => A4
[exportPdfLeftMargin] => 15
[exportPdfRightMargin] => 15
[exportPdfTopMargin] => 15
[exportPdfBottomMargin] => 15
[versionName] => 2020.3.11
[versionUpdateDate] => 20211016
[localLocale] => en_GB
[localCurrencyCode] => GBP
[localPrecision] => 2

In Inv Prefs:

Currency sign: £
Currency code: GBP
Invoice heading: Invoice
Invoice wording: Invoice
Invoice detail heading: Details
Language: en_GB
Locale: en_GB

I’ll work on the amount rendering issue but otherwise, looks fine to me. Make sure you are running the latest version and attach the PDF if it is still a problem. I’ve attached the PDF that I generated. The first with my standard settings and the second with your settings.

Attachments:

1. Invoice_555.pdf
2. Invoice_555-3.pdf

[RRowley]

Fixed issue. Uploaded in version 2020.3.09 – 20211011.

[RRowley]

First, you say that you imported MySQL tables from a 2009 version. Did you “import” them or “upgrade” your tables?

You should go through the upgrade processes. What version of SI where you running on?

There are two libraries for SI. On github you have simpleinvoices/simpleinvoices and fearless359/simpleinvoices. The first is the historic version that runs on php 5.6 and lower. For longtime users of SI, they are running the 2013.1.beta.8 (aka master) version on the simpleinvoices/simpleinvoices path.

This is great. If you are on this version, then you can install the fearless359/simpleinvoices master.2019.2 version and the database will be automatically updated for you when you run SI. One big change in this version is that it implements foreign key support at the database level. You might have some “orphan” records in your database which will be reported as part of the upgrade process and need to be fixed before you continue. Once you have these corrected (typically deleting the orphan records, or if you use multiple domains, creating the master records for the domains other than 1) the upgrade will fully complete.

After you have successfully upgraded to master_2019.2, you can then upgrade to master_2020.

If you didn’t follow this process, you probably need to backup and follow this upgrade path. There are some changes that occur in the upgrades that are meant to enhance performance.

My set up has 550 invoices and 60 customers. The time to load the invoices table is about 3 seconds and the customers is 1.5 seconds. This is true for my windows development environment and the linux based hosting service for my production environment.

I’m looking forward to your update on this.

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

[RRowley]

What is slow and how slow is it? Typically, this is the invoices manage table screen. So how many records in the database table?

SI is using the DataTables. It uses ajax to supply the data. In my testing, it is not the server that is the issue. It is the client rendering the data. Also, the feature is set to present the table when the first page is formatted. That is, it doesn’t have to wait for all the data to be transferred and rendered before displaying the first page.

Let me know what you have and we’ll go from there.

[RRowley]

I think you need to make an extension where you modify the signature field from the biller to add tokens for the variable data you want to insert and then insert it yourself.

Signature Example: %custname% | %date% invoice from %billername% is attached.

You then parse this and replace the tokens with the needed values. You could do this in the modules/invoices/email.php file for the $biller['signature'] field.

Or you can do what I do. Use the signature field to say “Attached is your invoice for the current month.” The subject line already contains the invoice number and the biller name. And all the pertinent information is in the attached PDF.

[RRowley]

Enter your default message in the Signature field in the biller record.

[RRowley]

Let’s start with the locale. Currently there is no en_IN locale defined. But you can remedy that quite simply. In the lang directory, make an “en_IN” directory. Then copy into it the info.xml and lang.php file from whichever language directory most closely matches what you want. If that is the en_US directory, then in the copied lang.php file, delete the lines at the end following the $LANG[‘zip’]… line (the ones in the if statement for setting the user password help format).

Modify the information in the copied, info.xml file.

At this point you now have an “en_IN” locale set up. Of course the words in the lang.php file have not been translated. You can do that as necessary. Once you have your lang.php file set up, you can send me copies of both the xml and php file via an attached zip file containing them, via this forum. I’ll add them to the standard application for future users, etc.

With these files set up, there are two places where you set en_IN to use it in field formatting and language selection. First is in the config/custom.config.ini file “localLocale” setting. The next is in the Settings/Inv Prefs tabs records, set both the Language and Locale fields to en_IN.

As for the date. In the screens that display the date, the format is as it comes from the database. “yyyy-mm-dd” I believe. This is standard and yields a natural sorting order for the field if you order the management tables by it.

For the invoice templates, you get whatever they display. You can modify them and make your own invoice formatting for dates and other information however you please; but it isn’t necessarily controlled by the locale settings.

Hope this helps.

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

[RRowley]

I just uploaded a version 2020.3.03 that contains changes to address this issue. The change supports multiple, semi-colon separated email addresses in any of the email address fields. Let me know if this works for you.

[RRowley]

There is no restriction on having multiple preferences with different language and currency codes. The one thing that can cause a problem is if the currency sign is input as a character rather than an html code for the character. The US dollar sign is an exception. If you view the help on the Invoice Preferences Currency sign field, it explains this. I’ve include screen shots of test the I performed testing this.

Attachments:

1. 

   invMultiPrefTypes.png
   

2. 

   invMultiPrefTypes2.png
   

[RRowley]

If the authentication option in the config file is set to false, the user is not relevant. Since there is no log in, there is no logout. When authentication is enabled, the user is pertinent. Typically, if a user already exists, the same password should work. The rules for what a new password must conform to does not apply to existing passwords. What I believe the issue would be, is that there has been a change in the algorithm used to hash the password has changed. The authentication logic however takes this into account. If the password fails authentication using the new algorithm, it attempts authentication using the old algorithm. If that succeeds, it updates the password on file using the new hash for all future login attempts. In practice, I found that I would have to login a second time to have the newly encrypted password work. If this process didn’t work for you, I’m at a loss as to why. I’m glad however that you were able to get it working.

[RRowley]

These are the first three lines of the function. The code would go in after them.

 $printIfEmpty = !empty($params['printIfEmpty']) && $params['printIfEmpty'] == true;
    $class1 = empty($params['class1']) ? '' : Util::htmlSafe($params['class1']);
    $class2 = empty($params['class2']) ? '' : Util::htmlSafe($params['class2']);

[RRowley]

I believe you need to start adding debug statements to the function. Try this. In the include/smarty_plugins/function.print_if_not_empty.php file add the following code after the setting of the $class2 variable:

if ($params['label'] == "Ph.") {
    $str = "smarty_function_print_if_not_empty(): Ph is ";
    $str .= empty($params['field']) ? "empty. " : "not empty. ";
    $str .= "printIfEmpty is ";
    $str .= $printIfEmpty ? "true." : "false.";
    var_dump($str);
}

When you print the template, you will get a message at the top of the print info screen that will tell you if it sees the phone field as empty and if it is setting the print if empty option for some reason. A not empty phone field or a true setting on the print if empty variable are the only ways that the logic will print something.

Hope this helps.

[RRowley]

It works in all my testing. Make sure you don’t have a local copy of the function in your invoice plugins directory. I removed them all from the standard version and have worked with this in testing the logic in the various templates and it works fine. I’m in the middle of making some significant changes to SI which includes enhancements to these functions to using multiple labels values and such. So it will be a little while before I get those delivered.

[RRowley]

I’ve gone through and removed all duplicate occurrences of the various smarty function so that the standard version in the library is used. There is no need to include a function in a invoice templates plugin directory unless you want to modify it for some reason.

I’ve updated internal comments in the not null and not empty functions to explain the difference. Basically and item can be not null but empty (blank, 0, etc. are empty values). It appears there is no use of the not empty function but I’ll keep it around for now anyway.

[RRowley]

The isset() test for a field is to see if there is valid content to print. You can use the empty() test on a field to determine if both the label and the field should be printed. For instance here is a test to determine if custom field 1 should be printed:

<!-- Show the Invoice Custom Fields if valid -->
 {if !empty($customFieldLabels.invoice_cf1) && isset($invoice.custom_field1)}
 <tr>
   <td nowrap class="">{$customFieldLabels.invoice_cf1|htmlSafe}:</td>
   <td class="si_right" colspan="3">{$invoice.custom_field1|htmlSafe}</td>
 </tr>
 {/if}

[Author]

Posts