PhatPixel

As I had feared, the new invoice layout has confused several customers this month. Feedback so far: The line totals don't make sense because Quantity x Unit Price does not equal Cost (because Unit Price excludes tax and Cost includes it, but this is not indicated) The Subtotal doesn't make sense because it is the sum of the tax-exclusive line totals and not the tax-inclusive line totals that sit above it We then get asked if tax has been calculated twice because there is a Tax element shown below the Subtotal, which they think is the tax-inclusive subtotal because of the tax-inclusive line totals above it Can you please look into revising the invoice layout for the next update so that it can cater more appropriately for tax-inclusive countries? Thanks.

Agreed. If there is a layout that works for the EU and AU regions, then best to use that. Unfortunately the current invoice layout is confusing and doesn't calculate inclusive tax properly -- which was one of the main reasons I upgraded from v2.5 to v3.1.1 (v2.5 had rounding errors two, but this was because of only 2-digit precision in the calculations).

I've been working over the last few days to establish Australian English as the default language by taking the en_us language files, duplicating them to en_au and making various changes to spelling and localising terminology. I currently have both languages active and in various locations I now see two tabs -- one for English, US and one for English, AU. However when I go to edit a template under Settings > Emails > Email Templates, I only see the English, US tab. I also tried changing the language in the database from en_us to en_au for each of the templates but then the list of e-mails disappears completely. Perhaps the template list may be hard-coded to en_us rather than looking for the Default Language defined in Settings > General > Localization?

I've discovered a potential bug in 3.1.1 which probably only affects people who have migrated from v2. It seems that when there is no record in the database for a client in client_settings.key with "tax_id", it displays the company tax ID (my tax ID) on the client profile and also on the invoice. When I edit the client profile and wipe out my company tax ID, a blank value is stored in the client_settings table and the problem disappears. However, this means I need to edit every client that was migrated to remove the incorrect tax ID. A MySQL INSERT query could insert blank values to fix this for all clients that don't have an entry in the client_settings table for key "tax_id", or perhaps there is a bug in the code that is fetching the wrong tax ID to display in the client profile when one does not exist in the database.

Actually the suggestion to re-visit the logo and background images has led me to the solution. The PNGs were originally output with alpha transparency. Once I removed this and re-uploaded them to Blesta, the PDF appears almost instantly.

Yes, I am using both a background image as well as a logo. Both images are optimised PNGs from PhotoShop. I'll try placing the logo on the background image to see if that halves the processing time. In the meantime, is there a way to extend the PHP max execution time? I have tried with .htaccess and it is either being ignored or replaced by a directive in a config file.

I've found TCPDF to be running quite slowly... it takes around 15 seconds or more to generate a PDF. Are there any suggestions to speed up TCPDF or increase the PHP maximum execution time? When I try to process multiple PDFs I am receiving the error "Maximum execution time of 30 seconds exceeded on line 5404 in ~/httpdocs/vendors/tcpdf/tcpdf.php" In reading TCPDF's website, it makes the following recommendations to speed things up. Any tips on how to implement any of these that would be useful to Blesta? Install and configure a PHP opcode cacher like XCache; Edit the php.ini file and increase the maximum amount of memory a script may consume (memory_limit); Edit the php.ini file and increase the maximum execution time of each script (max_execution_time); Edit the config/tcpdf_config.php file: manually set the $_SERVER['DOCUMENT_ROOT'], K_PATH_MAIN and K_PATH_URL constants, and remove the automatic calculation part; If you are not using the Thai language, edit the config/tcpdf_config.php file and set the K_THAI_TOPCHARS constant to false; If you do not need extended chars, edit the config/tcpdf_config.php file and set the default fonts to core fonts; If you do not need UTF-8 Unicode, set the $unicode parameter on TCPDF constructor to false and the $encoding parameter to 'ISO-8859-1' or other character map. By default TCPDF enables font subsetting to reduce the size of embedded Unicode TTF fonts, this process, that is very slow and requires a lot of memory, can be turned off using setFontSubsetting(false) method; Use core fonts instead of embedded fonts whenever possible; Avoid using the HTML syntax (writeHTML and writeHTMLCell methods) if not strictly required; Split large HTML blocks in smaller pieces; Avoid using transactions if not strictly required;

Update: I have created some new invoices today and the dates are displaying correctly. Perhaps I had not set the system date correctly when I created the invoices yesterday. It appears that the dates are stored in the database -11hrs from local midnight (i.e. 2014-02-19 00:00:00 is stored as 2014-02-18 13:00:00). I had expected they would be stored as -11hrs from the time of creation, but as the billing/due dates don't use hours, minutes and seconds I can see why they are stored this way. I hope this doesn't become a problem when we return back to standard time, as we will then be UTC+10 so 2014-02-18 13:00:00 in the database could become 2014-02-18 23:00:00 and possibly display as the previous day?

There appears to be rounding errors in the calculation of the total of v3.1.1. I currently have tax set at 10% inclusive (Australian GST). Example as appears on PDF: Item 1: Quantity 0.25, Unit Cost 72.7273 = $20.00 (inc tax) Item 2: Quantity 0.25, Unit Cost 72.7273 = $20.00 (inc tax) Item 2: Quantity 0.25, Unit Cost 72.7273 = $20.00 (inc tax) Item 2: Quantity 0.5, Unit Cost 72.7273 = $40.00 (inc tax) Subtotal: $90.91 GST 10.0000%: $9.10 Total: $100.01 It seems the total may be calculated by adding the Subtotal with the Tax, when it should actually be the sum of each line item's calculation. Actually, the invoice is quite confusing where inclusive tax is used. The line item Cost includes tax, but the Unit Price does not. Then you have a subtotal at the bottom of the Cost row that excludes tax. Then we have a rounding error. Suggested solution: Where inclusive tax is used, show the Unit Price including tax, eliminate the Subtotal and the Tax row should be something like "GST 10.0000% (included in Total): $9.09"

When clicking a new column for sorting, it uses the same sort order as currently selected (Client ID is initially sorted descending). Typically a column should always first sort ascending. Clicking subsequent columns will retain the current sort order instead of always using ascending. Example: If I browse Clients I initially see them by descending Client ID If I click to sort by Company, I am presented with Z, Y, X... instead of A, B, C... I click Company again and I see them in ascending order Now that I am using ascending sorting, subsequent columns will also sort ascending If I click the same column again to go back descending sort, subsequent column clicks then retain descending sort instead of defaulting to ascending

The company timezone is correctly set, there seems to be a problem with the calculation. As mentioned, we are UTC+10 (currently +11 for summer). I suspect that Blesta is subtracting 11 hours from the server time as it is assuming the server is also in AEDT, but it is not -- the server is already in UTC.

I have noticed that line items on the invoice do not have number formatting in v3.1.1 -- only the total. I expect that only the total displays the currency symbol, however I would think that line items should still have thousand separators, etc. Is this normal operation?

I have just migrated from v2.5 to v3.1 and created an invoice today with the billing and due dates both 18 February -- however when I view a PDF copy of the invoice the dates show as 17 February. Presumably, this is a timezone conversion problem. I am located in Australia EDT (currently +11) and the server has UTC time. When I check the timestamp in the database, it shows as "2014-02-17 13:00:00" which would suggest that 11 hours are being taken off the server time, which is incorrect as the server is already in UTC.

When a client has a very long e-mail address, it overflows the Client box and spills over into the Services/Invoices boxes to the right. Actual customer details in attachment have been disguised for privacy. Suggested solution: E-mail address is truncated with an ellipsis, but the full address is shown in a tooltip when you hover over the address.

I'm now migrating from version 2.5 to 3.1 and have run into this issue again. I have been able to find the strings in the language file to rename references from VATIN to ABN, but need to relabel the word "Invoice" as it appears at the top of the printed/PDF invoice to "Tax Invoice" as it is a requirement of the Australian Taxation Office. Can anyone assist with the language definition that I need to update? Thanks!

ABN is "Australian Business Number" -- it's the number you receive after you register to collect/remit GST when operating a business.

In Blesta v2.5, I modified ~/inc/invoice-tcpdf.class.php to replace the text "[crn]" in the invoice footer with a client-specific code for the BPAY payment system used in Australia. In my instance, the CRN (or Customer Reference Number) is a zero-padded five-digit Client ID plus a MOD 10 check digit. Which file would I need to edit in v3 to allow me to achieve the same result? It would be great if there could be a new Type of Client Custom Field such as "Formula" which allowed the automatic calculation of this, but this field would also need to be accessible as a variable in the invoice. Any suggestions?

The language itself is almost identical to UK English, but there are indeed nuances such as the aforementioned "Tax Invoice" and "ABN" is more appropriate instead of "Tax ID/VATIN". These are just two I've initially observed, there are bound to be more.

I've located the file to change at ~/components/invoice_templates/default_invoice/language/[Language Code]/default_invoice.php The strings to change are: $lang['DefaultInvoice.type_active'] $lang['DefaultInvoice.type_draft'] $lang['DefaultInvoice.type_void'] Would it possible to have an English AU translation in the crowdsourced translator? This could be based on UK English (ideally, if complete) or US English with some minor modifications.

I need to make a change to the language strings for use in Australia as we must display the term "Tax Invoice" and not just "Invoice" on the invoice itself (in other locations, it can just be called an "invoice" though). Which language file do I edit in order to make this change?