Paul

We recommend setting up ntpd to keep sync'd up with a time server. On RHEL/CentOS this should work.. yum install system-config-date ntpdate pool.ntp.org chkconfig ntpd on service ntpd start

Do you have mod_security rules that may be interfering? You definitely want to have CSRF enabled, it provides a major security advantage.

I would wait for the final release to upgrade to 3.1. It's actually in QA now, so it may be released tomorrow.

That's interesting.. try logging out, and logging back in.

You're right, if a staff member has permissions to manage staff and staff groups, they can create staff groups for other companies -- but only from the company where they have these permissions. If they are logged into a company where they don't have these permissions, they won't be able to do so, even if they have permission to do so in a different company. The result is that an admin with this level of access to one company, can grant themselves access to other companies. But, that's how you give yourself access to new companies you create too. What you're asking is worth considering though, we'll take a look.

Is this out already? It looks like it may just require different embed code for the PayPal button, if so, this would be pretty easy to implement. First I've seen of it.

Maybe Tyson can take a look at this. Anyone else getting this error?

Email sales FTP details, and I can FTP a copy of beta 2 to your server for you.

Ok, that makes sense.. that's what I was looking for.

That sounds fun. I'm guessing many EU companies simply issue proforma all of the time, to avoid this, even if there is a contract in place. Just speculation on my part, trying to understand how it works in practice, and how important/practical a package level proforma option might be.

Yes, the feature is available in the current 3.1.0-b1 beta release.

That makes sense. In that case, what happens if the customer drops off the earth and breaks contract? I'm assuming you'd then be liable for the tax on on this non-collectable amount. Or is there a way around it? My assumption has been in part that creating a proforma invoice first not only ensures that the customer agrees to renew, but that they pay before you're liable for any tax. I'm not sure how chargebacks are accounted for, but maybe broken contracts are handled similarly? I'm curious whether proforma invoices are a big problem, or a minor inconvenience for contracted services, and whether its common practice for companies to issue proforma invoices in these cases.

Only one way to find out, my guess is, probably. They haven't changed much with their database schema I don't believe. However, it's probably better to copy your install, upgrade the copied version, and then import from that database.

Mike is right, you can upgrade.. however, couple things to note.. 1. If you upgrade from 3.0.x to 3.1.0-b1, you MUST run the upgrader via CLI, ie php ./index.php admin/upgrade 2. If you do a fresh install of 3.1.0-b1, you should be able to upgrade to 3.1.0-b2, and 3.1.0 final via GUI or CLI methods. This is due to a bug in 3.1.0-b1 that breaks the CLI upgrader.

What would be the benefit of a per-product override? You are either under EU rules, or you aren't, right?

Do you happen to have 4 client groups? If so, have you upgraded to 3.0.7?

Yes, the simplest thing would be to develop a plugin that calculates the price each month based on the # of days, and updates the package price prior to renewals. It can do so via an automation task it registers. Soon it will be possible to have packages defer their pricing to a plugin, in which case your plugin would be able to control the price directly vs updating the package.

I'm not sure there's a way to do exactly what you're asking as the monthly amount would be variable. You could adjust the package price ahead of each month to accommodate this, or you could set the package price to "30 days". The renew date would not be the same each month depending on the # of days in the month, but then you'll be billing on a 30 day cycle rather than a monthly cycle. (Or 28 days, or whatever you want to do). If you bill on a 1 day basis, it will invoice daily.

The plan is to add a company and perhaps client group setting to enable proforma invoicing. Then, Blesta would create proforma invoices by default, and once paid, these proforma invoices would become normal invoices. Proforma invoices have their own numbering scheme, and are not simply converted to an invoice. Someone named Bjorn emailed us what I believe to be a clear description of proforma invoices. I'm including what he wrote here, so that we can solicit your feedback and provide some dialogue as we lead up to development on this.

Did you run the migrator twice? You'll need to re-install Blesta before attempting another import. What we recommend is after installing 3.0, do a backup of your 3.0 database. Then, do the import. If for any reason you need to run the importer again, first restore your 3.0 database. Importing to a clean database is the only supported import method.

If you are considering developing your own system, consider this.. Blesta is 99.9% open, you can modify it to include proforma invoices. You might even be able to re-purpose draft invoices for this without too much trouble.

Proforma invoices are coming, part of CORE-497. I don't have an ETA for you yet, tentatively scheduled for 3.2 but not guaranteed to be in this release.

b2 has not been released yet

It may not show up for you because you have reseller licenses only. Open a ticket (medium priority), with FTP details and I will FTP the zip file to your server where you can retrieve it. Please note that a beta is not intended for production use, and you should do a fresh installation. Also, support is only provided on the forum for betas.

Both are in 3.1