Forcibly Generate Service's Next Invoice

[lukasP]

Currently this would be done in 2 steps as an admin

 

1. Manually create the invoice

2. Manually bump the renew date

 

In this case, the invoice is not physically linked to the service though, so the service would not be suspended if unpaid. The advantage of this method is that it allows the customer to pay however far in advance they want. It's not limited to a single additional term. The downside is that there's more work, and that it's not self-service for a client.

 

How would you see such a feature being implemented, both as an admin, and as a client? What would this look like?

 

Yes, this is absolutely fine if you have 10 clients, but if you have thousands of clients then it is not convenient.

 

Implementation

 

Admin area

Clients > client > Service > Manage > add button to the Actions block: "Generate renewal invoice".

 

Client area

Dashboard > service > Manage > add button to the Actions block: "Generate renewal invoice".

[Paul]

Please see CORE-2058. This thread will serve as a point of discussion on this task.

[Jonathan]

This sounds like a great start.  I agree with the due date reflecting what the actual due date would normally be for that invoice cycle.

[Paul]

This sounds like a great start.  I agree with the due date reflecting what the actual due date would normally be for that invoice cycle.

 

Yes, it creates a problem though if as an admin you invoice for multiple cycles and a single invoice is created per-service as I suggested in the task. I wonder if we should create an individual invoice for each cycle or handle it differently.

[evolvewh]

I wonder if this needs to be done on a per service basis (hosting, domain, ssl, etc)?

 

This is kind of what I would invision:

 

Admin side:

 

Click the manage button next to a service and under the 'Actions' section, there is an option to 'Extend Renewal Period'. I don't know if this could or should be tied into the 'Change Renewal Date' option. From there, we would see the pre defined terms available (similar to upgrade/downgrade) and we could choose the correct one. From there, an invoice would be generated and sent at the scheduled cron time. I agree with Jonathan's comment here: I agree with the due date reflecting what the actual due date would normally be for that invoice cycle.

I don't know if there is a clean way to 'mass update' with this feature.

 

Client Side:

 

I think the button should be placed under 'Manage' again. I wonder if a notification of some sort should be added on the client home page to alert them about this feature?

Once they click manage, they're presented with a new button under 'Actions' and given the pre defined option to pay ahead.

 

As I look at all of this, I wonder if it overlaps features such as 'Change Term'. It might make sense to us in the industry but not to the customer. A simple change to the wording on the action button could take care of this.

 

We have had customers who wanted to pre pay one service but not the others which is why I present it this way.

[Paul]

I wonder if this needs to be done on a per service basis (hosting, domain, ssl, etc)?

 

This is kind of what I would invision:

 

Admin side:

 

Click the manage button next to a service and under the 'Actions' section, there is an option to 'Extend Renewal Period'. I don't know if this could or should be tied into the 'Change Renewal Date' option. From there, we would see the pre defined terms available (similar to upgrade/downgrade) and we could choose the correct one. From there, an invoice would be generated and sent at the scheduled cron time. I agree with Jonathan's comment here: I agree with the due date reflecting what the actual due date would normally be for that invoice cycle.

I don't know if there is a clean way to 'mass update' with this feature.

 

Client Side:

 

I think the button should be placed under 'Manage' again. I wonder if a notification of some sort should be added on the client home page to alert them about this feature?

Once they click manage, they're presented with a new button under 'Actions' and given the pre defined option to pay ahead.

 

As I look at all of this, I wonder if it overlaps features such as 'Change Term'. It might make sense to us in the industry but not to the customer. A simple change to the wording on the action button could take care of this.

 

We have had customers who wanted to pre pay one service but not the others which is why I present it this way.

 

In terms of what you recommend for the client side, this is almost identical to what the task describes in CORE-2058. From the admin side, an option under Actions would be fine unless we allow bulk-renewal as specified in the task.

[evolvewh]

Maybe my post was a bit worthless. I don't know the technical programming side of this and what it takes to make it all work.

 

How would bulk renewal work? It would allow multiple services to be checked for renewal and then step them through the options available prior to an invoice being generated?

[Paul]

Maybe my post was a bit worthless. I don't know the technical programming side of this and what it takes to make it all work.

 

How would bulk renewal work? It would allow multiple services to be checked for renewal and then step them through the options available prior to an invoice being generated?

 

See the screenshot in the task, it contains all of the options necessary for Staff, which is just, the # of cycles. For the client, I think advancing it a single cycle is sufficient.

 

What other options are you thinking of?

[evolvewh]

See the screenshot in the task, it contains all of the options necessary for Staff, which is just, the # of cycles. For the client, I think advancing it a single cycle is sufficient.

 

What other options are you thinking of?

Let me give this some thought and get back to you. Hopefully others will chime in as well.

[evolvewh]

I'm waiting for JIRA to load again but I think some of the wording needs to be changed in the UI and I think there needs to be a limit on the number of cycles they can renew for but I wouldn't be opposed to letting them renew for more than 1 cycle. Especially on domains. If someone wants to lock in a price for 5 or 10 years, I'd be ok with that.

[Paul]

I'm waiting for JIRA to load again but I think some of the wording needs to be changed in the UI and I think there needs to be a limit on the number of cycles they can renew for but I wouldn't be opposed to letting them renew for more than 1 cycle. Especially on domains. If someone wants to lock in a price for 5 or 10 years, I'd be ok with that.

 

We had a brief power outage and MySQL failed to start on Jira, fun.

 

Domains are a good example of renewing for more than 1 cycle, however domains are also very unique in that they have many other restrictions. For example, you can't register a domain for more than 10 years. I wonder if this type of functionality should be delegated within domain management and kept separate from standard services. (When we add better support for domains)

 

If a case can be made for renewing other services for more than a single cycle, perhaps the setting that allows clients to renew early can also allow a maximum number of cycles to be specified. There is nothing preventing someone from renewing in advance again (Unless that were also included as part of this) so there is no upper limit.

[evolvewh]

We had a brief power outage and MySQL failed to start on Jira, fun.

 

Domains are a good example of renewing for more than 1 cycle, however domains are also very unique in that they have many other restrictions. For example, you can't register a domain for more than 10 years. I wonder if this type of functionality should be delegated within domain management and kept separate from standard services. (When we add better support for domains)

 

If a case can be made for renewing other services for more than a single cycle, perhaps the setting that allows clients to renew early can also allow a maximum number of cycles to be specified. There is nothing preventing someone from renewing in advance again (Unless that were also included as part of this) so there is no upper limit.

I can see that this could get very cluttered in terms of what can and can't be renewed and for how long. I wonder if it would suit most users to have 2 or 3 years as a default and then allow up to 10 years for domains once that area of the software has been updated? This would allow customers to renew for 2-3 years on hosting, dedicated IP's, SSL and software licenses.

 

If you try to keep it simple, maybe two years is the way to go since EV SSL can only be renewed for 2 years at a time.

 

I'd like to see opinions from other users as well.

[Blesta Addons]

The term renewal . What i preffer is a option in package .

Something like maximum term or renew .

As every service has it own renewal terms and conditions

[evolvewh]

The term renewal . What i preffer is a option in package .

Something like maximum term or renew .

As every service has it own renewal termsand conditions

I'm wondering if this new feature can pull from the terms defined in the packages.

[activa]

interesting discuss ...

 

anyone can make this as plugin ? i pay .... send me qoute via PM .