PhatPixel

I have also wrestled with this problem (using Chrome for Mac) for some time. I have used numerous plugins with varied success but this seems to be one of the better ones: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm

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.

Has this feature been scheduled into a future release at this stage? I would really like to add a CCF to the Terms section of the invoice. Can you advise which file I would need to edit in order to perform a str_replace($search,$replace,$subject) to achieve this? $search would be a curly brace placeholder such as {reference}. $replace would be the CCF. $subject would be the Terms field.

Thanks guys. Can we log this in as a feature request?

I remember asking this question a while back for v2 but can't seem to locate the topic. I expect the process is different in v3 so I've created this new topic. How can I define the default sort order for the various tables in the system? They seem to mostly use the ID number however this is not really helpful for the way we use the system. Ideally it would be great if Blesta could simply remember how each user likes to sort each type of table but in the meantime, how can I define a new default sort method?

The data from the previous system was never imported into Blesta, so the only updates were just to Blesta itself. I'm sure tickets were working a while back -- possibly with v2 but then we stopped using the ticket system for a year or so. We only recently upgraded from 3.1.2 (I think) to 3.3.2 but it was broken in the older version as well, I just never had time to investigate further until now.

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.

Thanks for your help. I have tried both options listed on the page but neither work unfortunately. 1. I am assigned to the department for each day of the week. 2. Changing the status doesn't make any difference -- I don't see any tickets in the Support tab, regardless of their status.

I have experienced this problem in both 3.1 and 3.3... when I am on the Client detail page then select Open Ticket under Additional Actions, I complete the details and click Open Ticket. I then receive a confirmation that the ticket was created but it is nowhere to be found. The Dashboard indicates there are 3 open tickets, but Support > Tickets > Open shows zero along with "There are currently no tickets with this status." How can I find these missing tickets?

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.

Disregard. I just found this thread. My original search for "lapse" didn't turn up any results so I created this thread. Please ignore/delete.

I have a number of domains that a customer chose to allow to lapse, so I configured Blesta to schedule cancellation at the end of the term. They are flagged this way in Blesta (time clock icon with yellow exclamation mark) but a new invoice was generated for their renewal. Why?

I think I have found the problem, and it looks to be a bug. When I create an invoice and save it as a draft, the Invoice Billed Date appears correctly in the interface but is the previous day when displayed on the PDF (we are in UTC+11 until this weekend, when we fall back to UTC+10).

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?

No, if you paid it on 1.4.2014 then it should renew the term based upon the actual renewal date. What I am saying is that it shouldn't show the new renewal date until after the invoice is paid.

That may be, but the problem is that the service shouldn't yet be showing Date Renews of 27.3.2016 until the invoice is paid. It should show 27.3.2014.

Thanks, I'll submit a feature request for the tax-inclusive invoice layout. The rounding error appears both in the interface and on the PDF. I have since switched to using tax-exclusive mode but this still produces rounding errors. Please see another example attached.

This is definitely how it is working on our installation. Please see the attached screenshot with an example outlined in red. You will note the service already has already got an expiry date of 27 March 2016 whilst invoice #3217 remains unpaid and is due on 27 March 2014 (the the renewal date of the domain). Some things that may [or may not] be relevant to this bug: We upgraded from 2.5 to 3.1.1 Autodebit is on, although it shouldn't actually have an effect because all payments are initiated by the client (the autodebit is set to 1 day before due date, in settings) Automatically Provision Paid Pending Services is active in settings

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.

When scheduling a service cancellation, it would be great if the Specific Date radio button is automatically selected if I enter a value in the date field (either through typing or using the date picker). I had the situation today where I had gone through a list of scheduled cancellations, and only realised towards the end that I had to enter a date as well as change the radio button. This would be a handy user interface enhancement.

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!

Would it be possible request a feature to allow custom fields to be displayed in the invoice terms (footer) using the curly braces in the same way you can substitute certain variables into e-mail notifications?