SSy

Okay I will test accordingly and let you know if this is how it is functioning.

This is what my settings page now looks like. Based on this, my understanding is as follows: 1) If a service started on January 4th, it will renew on February 4th and March 4th assuming it is monthly billing. 2) They will be sent an invoice on the 2nd of March, and that invoice in the blesta panel will say it is due on the 4th but invoiced on the 2nd. 3) If they fail to pay by the 11th, their service will be suspended. Yes?

Well I've updated it in the company settings and ensured that the client group uses the company settings. It still has not fixed. As I am paying for the software and cannot locate the issue, please advise.

So which option should control the space between the invoice date and due date?

Have confirmed this is server wide - all invoices are now being given only 2 days before suspension after the invoice instead of 5. How do I fix this setting?

Further investigation indicates this: 1) All previous invoices were created on the same date: 23rd of the month. 2) All previous invoices stated the due date was on the 28th of the month 3) This last one magically shifted to the 25th of the month for the due date. 4) The setting in the control panel says "Invoice Days Before Renewal" = 5 days Therefore for some reason the system is suddenly for some reason making the due date 2 days after the invoice for some reason. Any advice?

I have checked the logs and it appears an invoice was created on the 25th of Feb instead of the 28th which is when the payment is due. How do I fix this bug in the date? Our server experienced a crash recently so it is possible something got messed up in that.

One of my clients who is using PayPal payments was automatically suspended a day before his invoice was due, even though the system is set to only suspend services 2 days after the invoice is due. Any idea why this has happened?

A client of ours has notified us that their account was cancelled via Blesta. I can see in the logs that a request was sent to WHM to delete their account. Their billing is all fine and I can see no reason for the cancellation. The only possibility I can see is that they did it themselves, which seems unlikely. How do I reverse this? In actuality, it seems the client may have cancelled and is playing games. How can I determine if they initiated the cancellation? Is there a note of this in the log?

I'm not going to be upgrading yet due to custom code implementations, but is there a mass mailer for pre-4 that I can use?

Hey there - yes, I mean for clients. I can't see that plugin, or the mass mailer plugin, for example, in my plugins list. Is there somewhere I can download it?

Does Blesta have a mechanism for trial accounts?

Has anyone successfully implemented a mechanism for either the standard or universal module to cancel subscriptions? Any code snippets that I may use as a start to get this added to the module?

Determined the issue arises if you have 'subscription only' selected in the PayPal payment gateway settings. However, I'm confused - if someone upgrades their package, shouldn't Blesta cancel the old one and create a new one with a prorated difference? That's what a previous CP i was using did. The way it currently works it seems to just get a one time payment for the difference and leave the original subscription running.

Upon further investigation it appears to be a bug with the PayPal module: switch ($this->ifSet($this->meta['pay_type'])) { case "both": if ($recurring_btn) return array($regular_btn, $recurring_btn); return $regular_btn; case "subscribe": return $recurring_btn; case "onetime": return $regular_btn; In this case, it is set to 'subscribe' but the recurring_btn variable is not set because the $recurring_fields variable is never set. This is when trying to upgrade a yearly package. I have added this code above the snippet above as a temporary hack: if (!$recurring_btn) $recurring_btn = $regular_btn; Please advise on an actual fix for this issue.