PhatPixel

As per this discussion, I would like to request the ability to insert custom client fields into the Invoice Terms section using the same curly brace placeholders used when customising e-mails.
 
This would also solve the problem I raised in this other discussion.  Thanks!

For those that may be interested in doing this, here's the procedure I followed to insert a placeholder into the PDF invoice Terms field:
Duplicate the /components/invoice_templates/default_invoice folder and rename as appropriate (I'll refer to it as new_invoice in this example) Rename all files within this new_invoice folder from default_invoice to new_invoice Open /components/invoice_templates/new_invoice/new_invoice.php and replace all instances of default_invoice to new_invoice and also replace all instances of DefaultInvoice to NewInvoice (note that I had some problems with CamelCase here when I tired using more than Two Uppercase letters here such as BrandNewInvoice, etc.) Open /components/invoice_templates/new_invoice/new_invoice_pdf.php and replace all instances of DefaultInvoice to NewInvoice Open any language definition file file under /components/invoice_templates/new_invoice/language/ and replace all instances of DefaultInvoice to NewInvoice -- also be sure to give the invoice template a new name as assigned by variable $lang['NewInvoice.name'] Open /components/invoice_templates/new_invoice/new_invoice_pdf.php and add the following code to the top of the drawTerms() function: private function drawTerms(){ $cf_data = array(); if( property_exists( $this->invoice->client, "id" ) ){ Loader::loadModels( $this, array( "Clients" ) ); $field_id = 1; $values = $this->Clients->getCustomFieldValues( $this->invoice->client->id ); foreach( $values as $value ){ if( $value->id == $field_id ){ $cf_data = array( 'name' => $value->name . ":", 'space' => null, 'value' => $value->value ); break; } } unset( $values, $value ); } $data = array( array( Language::_("NewInvoice.terms_heading", true ) ), array( str_replace( "{crn}", $cf_data['value'], $this->meta['terms'] ) ) ); ... Some notes about the above code:
Replace the value assigned to $field_id with the appropriate ID number of the Custom Client Field Replace NewInvoice with the CamelCase name of the invoice as appropriate Replace {crn} at the end of the code with the placeholder of your choice (you could potentially use arrays to replace multiple placeholders, if required as well) Go to Settings > Company > Billing/Payment > Invoice Customization > Invoice Template and change as necessary This process can easily be adapted for placeholders in other parts of the invoice too.  Good luck, I hope this helps anyone else that wants to achieve something similar.

I'm interested to see that there are others that still find this Blesta functionality confusing.  I really think that what Blesta currently refers to as the Renewal Date (or Date Renews) would be best described as the Next Invoice Date.  The renewal date should relate to the service itself and not to the invoice scheduling, which can be a date managed by the system internally.

For those that may be interested in doing this, here's the procedure I followed to insert a placeholder into the PDF invoice Terms field:
Duplicate the /components/invoice_templates/default_invoice folder and rename as appropriate (I'll refer to it as new_invoice in this example) Rename all files within this new_invoice folder from default_invoice to new_invoice Open /components/invoice_templates/new_invoice/new_invoice.php and replace all instances of default_invoice to new_invoice and also replace all instances of DefaultInvoice to NewInvoice (note that I had some problems with CamelCase here when I tired using more than Two Uppercase letters here such as BrandNewInvoice, etc.) Open /components/invoice_templates/new_invoice/new_invoice_pdf.php and replace all instances of DefaultInvoice to NewInvoice Open any language definition file file under /components/invoice_templates/new_invoice/language/ and replace all instances of DefaultInvoice to NewInvoice -- also be sure to give the invoice template a new name as assigned by variable $lang['NewInvoice.name'] Open /components/invoice_templates/new_invoice/new_invoice_pdf.php and add the following code to the top of the drawTerms() function: private function drawTerms(){ $cf_data = array(); if( property_exists( $this->invoice->client, "id" ) ){ Loader::loadModels( $this, array( "Clients" ) ); $field_id = 1; $values = $this->Clients->getCustomFieldValues( $this->invoice->client->id ); foreach( $values as $value ){ if( $value->id == $field_id ){ $cf_data = array( 'name' => $value->name . ":", 'space' => null, 'value' => $value->value ); break; } } unset( $values, $value ); } $data = array( array( Language::_("NewInvoice.terms_heading", true ) ), array( str_replace( "{crn}", $cf_data['value'], $this->meta['terms'] ) ) ); ... Some notes about the above code:
Replace the value assigned to $field_id with the appropriate ID number of the Custom Client Field Replace NewInvoice with the CamelCase name of the invoice as appropriate Replace {crn} at the end of the code with the placeholder of your choice (you could potentially use arrays to replace multiple placeholders, if required as well) Go to Settings > Company > Billing/Payment > Invoice Customization > Invoice Template and change as necessary This process can easily be adapted for placeholders in other parts of the invoice too.  Good luck, I hope this helps anyone else that wants to achieve something similar.

I solved the problem. Somehow, in the database there were two of my staff_id -- the one I was logged in with was different to the one that tickets were assigned to.  This seems like an error that must have occurred during an upgrade of Blesta.  Anyway, after correcting the staff_id fields for the tickets, everything seems to be working now.

Here's an example of one of the calculation errors in invoice #3309:
 
0.5 x 72.7273 should equal 36.36365 (not displayed)
2 x 72.7273 should equal 145.4546 (not displayed)
 
Sub total 181.81825 (rounds to 181.82)
Tax 10% of the non-rounded sub total = 18.181825 (rounds to 18.18, but 18.19 is shown)
A 0.01 error is introduced.
 
If the system is using tax-exclusive pricing, you should only need to round the Sub Total and Tax.  The Total should be the sum of the rounded sub total and the rounded tax total.
 
The way the system works with tax-inclusive pricing is actually quite terrible because on the PDF, the Unit Price shown is tax-exclusive, the Cost is tax-inclusive then the Sub Total is tax-exclusive again!  Everything should be tax-inclusive, the Sub Total is therefore unnecessary and should just be called Total.  The Tax line should indicate that it is included in the Total above.

I highlighted Blesta's rounding issues some months ago and have since switched to using the exclusive tax method in the hope that these problems would diminish.  Sadly, I continue to battle this problem daily, with rounding errors on invoice lines, invoice totals and when reconciling payments to invoices.
 
Please refer to the attached image an an example, where you can see I am reconciling one payment against five invoices.  I have entered the payment amount at the top (which is the amount the client had deposited) and checked the invoices to which this payment is being applied.  If you add up the totals of each invoice, they do add up to the amount deposited -- but Blesta refuses to accept it.  After some trial and error, I was able to record the payment by changing the payment amount at the top to be $3,809.99
 
The problem, as far as I can tell, is that Blesta is constantly performing the calculation of taxes rather than accepting the rounded two-decimal total for each invoice.
 
Rounding should be performed once only (and I would suggest this happens at the line total).  Once that rounded figure is calculated, all future calculations should work with the rounded figure.
 
I really do like Blesta, but there are these niggling issues that deeply impact the software's integrity that need to be resolved.  I hope that one day I can return to inclusive tax calculations which is how we should rightly be operating for GST in Australia. 

I highlighted Blesta's rounding issues some months ago and have since switched to using the exclusive tax method in the hope that these problems would diminish.  Sadly, I continue to battle this problem daily, with rounding errors on invoice lines, invoice totals and when reconciling payments to invoices.
 
Please refer to the attached image an an example, where you can see I am reconciling one payment against five invoices.  I have entered the payment amount at the top (which is the amount the client had deposited) and checked the invoices to which this payment is being applied.  If you add up the totals of each invoice, they do add up to the amount deposited -- but Blesta refuses to accept it.  After some trial and error, I was able to record the payment by changing the payment amount at the top to be $3,809.99
 
The problem, as far as I can tell, is that Blesta is constantly performing the calculation of taxes rather than accepting the rounded two-decimal total for each invoice.
 
Rounding should be performed once only (and I would suggest this happens at the line total).  Once that rounded figure is calculated, all future calculations should work with the rounded figure.
 
I really do like Blesta, but there are these niggling issues that deeply impact the software's integrity that need to be resolved.  I hope that one day I can return to inclusive tax calculations which is how we should rightly be operating for GST in Australia. 

I guess the difference here is perspective.  From the customer and business operator's perspective, the Renew Date shown in the portal should represent when the current paid-for term expires/renews.  From Blesta's perspective it is when the next invoice needs to be generated.
 
PauloV has made a good suggestion, which seems to reaffirm my opinion that Blesta should represent the renew date from the customer's perspective whilst it tracks the next invoice date internally.  Can this thread be moved into the feature request forum?

I would tend to disagree with your statement.  I would expect someone with common sense would think, "Ok, it looks like someone else here must have renewed it".  Particularly when the renewal date may be up to 10 years in the future (for a .com domain, for example).
 
But I guess the point is that it shouldn't be ambiguous -- it should be quite clear that the service terminates on the date indicated unless payment is received... at which point it renews.  I don't see this as a feature request, I believe it is definitely a bug.

I have noticed that the service expiry date renews for another term when it is invoiced.  I expect this should actually occur when the invoice is paid.
 
We invoice 14 days before the renewal of the term and some customers will elect to notify us of their intention to cancel at the end of the term.  This then leads to a secondary bug -- if I try to reduce the term back to its original expiry date, I get an error message indicating I need to select a date greater then the last renew date.  If you look at the attached snapshot you will see I am trying to enter 27 March 2014 but it is giving me an error despite it wanting a value greater than 26 March. Perhaps there is a timezone calculation that is awry here as we are in UTC+11 (Sydney, AU).  In the end I just scheduled a cancellation date for 27 March 2014 instead.

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?