YES IT WORKS. Prorated addons

[nibb]

Remember the post where I said addons where not prorated?

http://www.hostbillforums.com/index.php/topic,140.0.html

It seems we are doing this wrong.

For current services, you don´t create an addon. You create the addon in the product itself using the form fields.

This is not perfect, in particular because cPanel addons are supposed to be created as addons, and not here. But I think this can work for most that are having this problems.


If you create a package, and then want a related addon for it, do not create as addon, which is the logic step you would do and I assume must do, because even Hostbill suggest that approach.

Well, Hostbill owns docs does not clear this. Hostbill itself threats addons as completely separated products, so its makes sense that it bills them on its own complete separate billing date.

So if you are creating extra space, or something related to a product that can only work for that product, do not create it as an addon. Create it right in the product using the order forms.

People, this prorates addons. I just tested it today a couple of time.

It will only allow the customer to order it on the same period of this plan, so if its monthly, it will default to it, and will prorate the amount based on the days left for this next billing period.

You can also select on forms, which ones you want to be showed in the cart, or only as upgrades, etc.

Now, I used this forms for servers, before but I did not realized this prorates amounts correctly.

Hostbill itself suggests adding extras, like cpanel space as an addon, so this is not perfect, as the forms will not allow you to automate anything, this means create the addons, etc. But its at least one solution.

So instead of using addons, which are threated as complete separated products with its own billing, just use the build in form to create your prorated addons to a particular service.

Of course it would be perfect, if ADDONS itself could do this, but if you think about it makes sense, if addons are separated, this means they can be configured for any product, hosting, server, support, etc, what ever, it makes sense for them to be in its own billing period and date, as if they where separated products. Of course why Hostbill suggest creating cPanel addons and others like this I don´t know. And the of course addons itself are more powerful as they can work on its own.

But hey, I create most addons manually anyway, it was the billing which was not prorated that was bugging me. So at least for me this is a solution. If you could use hooks, call actions based on select order forms, then we could even automated this.

Now you just need to think like this:

1. If an addons works only with that specific product. Create is as an extra field using the forms.

2. If the addon can work without the product, this means if the product is suspended or cancelled, or it needs to work with several different products, use the addons options.

[tallship]

1. If an addons works only with that specific product. Create is as an extra field using the forms.

Okay, I'm going to try this out. And thanks for that info

So, I have an existing service a client has been paying on a service for a VM and then they want, say, an extra NIC or Hard Drive, so I go back to the order page and add that in?

2. If the addon can work without the product, this means if the product is suspended or cancelled, or it needs to work with several different products, use the addons options.

Our 24/7 NOC Support is included, and that's how I've been adding that in, so that it appears as a line item on their invoices - although it is zero dollars. I just didn't want to generate an invoice in the middle of the month for the zero amount, so I changed the registration date to match their billing anniversary date.

We would do the same for a priority support contract, but now you're saying do it on the order page. That's not a problem if we have just one order page for each of these customers, but for on-demand, self-managed services there's a common order page that everyone who visits is going to see so that might not work I think.

Your thoughts?

[nibb]

Yes this is the correct. This where I got the idea actually.

Instead of creating an extra hard drive, nic, etc as addons on servers, I actually used the build in forms in the product itself.

Then I thought, wait a minute. This are prorated, so why not use this for the rest as well....

So basically yes, don´t create an extra hard drive, nic, or any server addon as an ADDON. This sound stupids I know, but its not the correct way.

You would create this as an extra field using the forms in the product itself, this mean in your server or plan product. This is actually more flexible that addons, because I had the need to only show some addons AFTER a client purchased a service, but not in the order page as new client. And this can´t be done with addons either and I was scratching my head about that as well, besides the prorated billed.

Now, the forms are way more flexible, first they will only work with that specific product, so if you have tons of different plans or servers, you need to create the same fields on each of one, it would take you a few minutes to hours, but yes, you will need to create them for each product. Now you can choose this to be showed in the order page, or only after ordering, or only as upgrade, etc. They are more flexible. And if your client now wants an extra hard drive, this will bill them directly with this billing period, a prorated amount.

This also lets you use logics, which you can´t on addons. For example, if customers selects "this extra hard drive" maybe this does not work with this config, so you need to hide or show another option.

So where would you actually use addons? On things that can work without your product, in this case your server.

Lets say a firewall. A firewall could work with one or more servers. You can choose to use this as the build in forms, if you want to charge per server, but lets assume you actually just charge for the firewall, a Cisco unit, and the customers can use this for what ever servers he has in his account. So in this case, an addon would work, because the Cisco device would not be related to any specific servers. If can work with Server A, or Server B, or both.

So in this case, you don´t need prorated billing either. If the customers orders the firewall, maybe he wants to have a different billing period for this. Now if he cancels Server B, if you used build in forms, it would also cancel this firewall and leave Server A without service, but since we are using an addon in this example, this will work. Client cancels server B, but firewall is still billed since he will use it for Server A.

Now, lets say his server is paid annually. If you use the build in forms, the firewall would prorate to yearly, and maybe the customers does not want this, he wants a firewall for 3 months. So now since we use addons, he orders the firewall for what ever server he wants, since you can choose which products can use this addon. He orders it monthly, this firewall will not be prorated, and has its own billing date. If does not pay next month, the firewall is suspended, with an action or manually, depending on how you have your system setup.

Does this make sense?

The only drawback for this, is that the customers would be billed separately for the firewall, or each addon. Now this can be positive or negative, depending on how you want your business model, in either case, you can change the addon date to match the renewal date manually in case you want consolidated billing.

So its really your choice, if you want to user addons, or create the addons directly in the product itself. First will be completely separated from all products, it will have its own independent billing date, and can be added to multiple products. The second option will only work with what ever product you are configuring it. It will bill according to the product billing date, and its build in right into the product.

So Tallship, I think this will work for you and me and the rest and maybe we need to apologize for some of our comments, because we are just not really taking a few minutes to test the software and different settings.

Now, I understand some may want addons prorated, but I thought about it, and it really does not make sense, the way hostbill is threatening them is correct. An addon is a separate product, and so it should be on its own period and payment. Some things do not make sense as addons, and in that case you should not use that option. I just used that option because from the software I came, addons where working as the build in forms in hostbill. In this case, hostbill has a different approach and I actually like it, because some customers may prefer this.

We should relax a bit more and actually test and research what we purchased, I saw many other people complaining about this same issue in the old hostbill forums and to be honestly I must feel Kris maybe even read those and said to himself, "Wow, this are hosting companies and are to stupid to figure out how to configure the software"

And indeed we are. We are just not configuring products and addons correctly. I know must probably made this mistake for the following reasons:
1. cPanel addons are actually created as addons. So this confuses you and since this are addons, its logic to create the rest of extra stuff as addons. And you can, but if you want prorated billing you should not.
2. Must of us, come from software where addons, are just addons, there are not build in forms in the products like Hostbill has, so you create extra fields as addons, so coming from there, most create addons in hostbill as well and then are surprised that this do not work like they expected.

Just keep it simple like this:

1. Is this service or product going to work only with XX product?
Use the build in form.
2. This service does not make sense to be billed separately, it should be billed with the service product together.
Use the build in form.
3. This service can work with multiple different products, suspending it will not affect any other service
Use addons.
4. Service addon is independent from other products, can be activated, suspended on it own, and needs to be billed separately.
Use addons

[nibb]

Tallship, to reply to your question, about support you should really answer this:

Is this billed per customer, per account, or per product or services?

I mean, do you bill this support for each server (using server example) of have a support package regardless of servers units.

This will let you answer the question. I understand most customers, in particular in the US, will want 1 single invoice with all items billed. You can still do this with addons, but you need to adjust the date manually like you are doing.

If you bill a management service per server, I would not use addons, because you want this to be billed together with each server.

So if the customers looks Server A, he pays and can see the charges for the + extra management services

Then the same customers can look Server B, which does not have this support included.

In that case, I would not use addons, I would create the support package using the forms directly in your product.

[tallship]

Thanks nibb

I'm going to run with that method.

I'm going out drinkin' lincoln'ing tonight so I won't be around to participate (Not good for me to do so once I've had more than a few in me). I'll see you all in the next day or so, coz I've got a pretty busy schedule tomorrow and have to rack up some more boxes at my datacenter.

Kindest regards,