Paul

Interesting, does this only occur for non-clients opening tickets? Can anyone else reproduce? I'm not seeing this is our environment, but only clients can open tickets.

What were you searching for an alternative to? I think the reviews show up, but the ratings seem to be stuck at 13 for some reason. Thanks to everyone who posted a review or rating though, it means a lot to us.

Or you can sponsor development for one

A direct cPanel reseller module would be good, but I could see a module that uses buycpanel.com work out a little better. Not only would there be no volume commitment, but we could include other software products that they offer.

If generating an invoice manually, or via the API you aren't even restricted to a particular term as supported in Blesta. You can bill for any term or any quantity you want. Only if it has a service, must the service follow a supported term & period.

That looks pretty good! And, a beer does sound pretty good. Cheers. There may have been another thread for this, but this issue (must have a field for a universal module) is corrected in 3.0.4 and should be released in the next week or two.

Then you'll have to fetch the information for the invoice template by doing a query yourself, the data will not be available automatically and there is no method that you can invoke to fetch the information. We suggest only making changes to the database structure or core files if necessary as it may eliminate an upgrade path. All of the areas you may need to modify to allow the field you added to be updated via the interface, and during check out, etc may be quite significant. Cody or Tyson may be able to point you in the right direction, but we can't provide any official support for this.

Awesome, fully migrated to that other VPS?

I guess I'm confused about how you're storing the data. Did you actually modify a table structure in the database, or are you using the built in custom client field feature? In any case, you will likely have to fetch the information in the invoice template. See components/invoice_templates/TEMPLATENAME/

If you enter the key, and it complains, then you know it's time to re-issue it. Generally if you're doing a new install and it's not a fresh key, when it asks you for the key, that's the time to do the re-issue. I suggest doing the new install and selecting the 30 day free trial, because then you'll have both a trial, and your official keys allowing you to run 2 copies of v3 side by side. Once your new install is done and migrated and ready to go live, re-issue your official key and plug it in under Settings > System > General > License Key

If you need a 2.5 license for a couple weeks let me know (email support@.), I can issue one for you on a temporary basis. I'll need to know the full hostname you'll be using it at.

If you have an owned license with us directly, we can provide a dev license at no charge.

Thanks for the suggestion, anyone else have any thoughts on this?

To be safe, you will need to import your data into a fresh 3.0.3 install. Install with a trial key, and keep your other v3 install up and running. Then run down and compare the two after you import your data, and update the themes, email templates, and other settings with the changes you have made. Having them side by side should help.

Just a note, the maxmind details should still be available via maxmind's login area under logs, even if the threshold was so high that Blesta rejected the order outright.

Yes. What I meant about late notices and auto-debit is that regardless of how an invoice was created (Automatically by Blesta, manually through the interface, or via the API) the invoice is treated the same way moving forward. There is a feature that can send up to 3 late notices / payment reminders, and a feature that can automatically charge a credit card x days before an invoice is due. These features can still be utilized, if you want, even when creating an invoice via the API. I mentioned this because in your original post you asked about a reminder.. so, those reminders, if you have them set up, will still be sent when creating an invoice via the API.

It's against Mastercard/Visa merchant rules to store CVV data in any way, shape, or form. The CVV data is passed along by Blesta when processed live via customer input, but never saved. This makes it impossible to send CVV data if using auto-debit. Cody or Tyson may be able to comment on sale vs preauth, however I'm not sure I see the correlation with CVV data. I wouldn't think a capture should take place if there is an issue with CVV or AVS. Don't most merchants automatically do a preauth, then capture? I guess the side affect here is that the immediate void BluePay is doing results in the funds being held up in the customers account for several days, and you are charged a processing fee?

You may wish to use the API to create the invoices on the 1st of the month, each month, based on your other systems evaluation of whether they owe $5 or more. I think this is where you're headed? In this case, the client would have no services in the system, and Blesta would not invoice on its own. Any invoices you create via the API will still work similarly however, with late notices being sent how they are configured, and auto-debit running if configured as well.

Invoices are sent out X days before a service renews. This value is configurable, so you can invoice someone 5 days before, 10 days, 30 days, etc etc. The due date of the invoice is always the date the service renews. Yes, virtually everything you can do in the interface, you can do via the API. Essentially all public method models are available through the API, including those for plugins. See http://docs.blesta.com/display/dev/API for information on the API. If you scroll to the bottom you'll see source code documentation which you'll need.

No, Blesta will only pull from the database referenced in the config file in config/blesta.php You will need a v2.5 license. If you purchased before Aug 14th and bought an owned license you should have a v2.5 license also. Open a ticket with us with the new domain so we can re-issue it to that. If it will be installed at the same domain/subdomain as before, regardless of sub-directory it will work. If you have a backup and might need to restore it, I would copy it down just in case. Did you verify your data was imported properly initially? Were there invoices prior to Aug 1st?

Is this still an issue, or was it related to http://www.blesta.com/forums/index.php?/topic/1102-serious-cache-issue/#entry8970 ?

You can create a recurring coupon, and customers that apply the coupon would get that amount, or percentage off every time it renews per the coupon.

It's likely we will make the delivery methods modular in the future, as there is at least 1 other method we are planning to implement. So, if you don't need interfax now, I suggest simply replacing it with your metrofax implementation. You can refactor your code later once it's modular and then have support for both.

Thanks for the contribution!

You could remove non-required fields on the order form by editing the template and setting them to style="display:none;", but modifying them, depending on what you are trying to do may be an issue. Of course, if you disable the field from displaying, and then create a custom client field to replace it with your changes, that may work out.