Max

Could very well be. But I have been told that tax inspectors exist outside the EU as well. Not all countries may have exact rules about what needs to be on an invoice, and what administration you must keep, but they generally do appreciate it if the information you do have is accurate, and do require that you have sufficient information for your turnover to be calculated and taxed properly. Things like back dated invoices, and dynamic address information -that suddenly may show a different state/country than originally, not matching the sales tax charged- are not going to earn you kudos anywhere.

Would argue that proper accounting is beneficial to every company, not just those in the EU.

It is, at least in the EU. If payment was made in advance, and the invoice was created on a later date, it is a requirement to mention the date payment was received on it.

Backdating any type of document is indeed fraud. Also keep in mind that in countries that use accrual accounting, VAT becomes due on the invoice date, and has to be paid at the end of the reporting period. So if you do were to write out an invoice backdated to December 2014 today, the VAT on the invoice should have been paid at the end of Q4 2014, and you are late.... Invoice date = date the (real) invoice is created. Which as naja already pointed out, can be later than the date the payment was received by your bank, in case of wire transfers and manual payment processing. Note that -when there is advance payment, which is the case here- you are required to mention the date the payment was received on the invoice as well, but separately, and not as invoice date. Invoices typically only have a due date and additional payment instructions ("if paying by bank transfer, use invoice number 1234 as description") if they have to be paid. If the invoice was paid in advance, it shouldn't have a due date, as nothing is due.

Same in most other countries outside of North America. That we have provinces has to do with politics and management, the mail man wouldn't care less. The ZIP codes of some countries include alphanumeric characters as well (1234 AB), and are used by the automated systems of the postal services to sort mail. Including strange unexpected and unrelated province codes in the address will get those systems confused, and is a good way for mail to get delayed... == A somewhat related feature request -that could potentially be added to the same "international address format configuration" admin interface- is the option to add regex validation rules by country, for zip, phone number and address line fields. http://www.blesta.com/forums/index.php?/topic/1624-internationalization-regex-checks-on-address-fields-depending-on-country/

Is the smoke coming out of the module black or white? Or could you be a tiny bit more specific, than "doesn't work"?

dedicatedip field in WHMCS is not module specific. Doesn't matter if it's a cpanel account or a dedicated server, you can put an IP there for informative purposes.

Duplicate of: http://www.blesta.com/forums/index.php?/topic/1623-internationalization-configurable-address-formats/

As long as all the modules you have are standard WHMCS modules, for which a standard Blesta counterpart exists, you should be fine. You may run into problems if you have third-party modules though. They get converted to "universal module" packages, and you cannot change them to a more proper module afterwards without messing in the database.

As I mentioned in the other thread, problematic settings can also be in Apache's configuration files. http://www.blesta.com/forums/index.php?/topic/3794-install-error/?p=28928

>"Enter your email address to get started" (+ a standard confirmation email) I do think having an e-mail address confirmation part is important, and currently lacking in Blesta. First of all making sure you have the correct e-mail adress is important so that renewal invoices reach the customer. But also because with some domain registries it is a contractual requirement that you verified at the very minimum the e-mail address, before you are allowed to register a domain on behalf of a customer.

Here in the Netherlands, you can even write out invoices by hand with pen on a piece of paper, and it would still be a legal invoice. As long as it has the required information, and you make copies of the issued invoices (and do not alter them afterwards). They do not have to come out of your accounting system. Can just enter the total amount of all invoices there, as a single batch journal entry at the end of the accounting period. We did had the requirement for a digital cryptographic signature on electronically sent PDF invoices in the past, but that requirement has been dropped, at least in my country (not sure about other EU countries). When we wrote our own billing system, it did was still required, and we had to duct tape our PHP software, to some Java code using the iText library to make that happen, as there weren't any PHP classes capable of that at the time.

1) start with an empty Blesta installation again. 2) unzip NOC-PS module to Blesta 3) create a file blesta/plugins/import_manager/components/migrators/whmcs/5.2/config/nocprovisioning.php with the contents: <?php Configure::set("nocprovisioning.map", array( 'module' => "nocprovisioning", 'module_row_key' => "ipaddress", 'module_row_meta' => array( (object)array('key' => "host_name", 'value' => (object)array('module' => "ipaddress"), 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "user_name", 'value' => (object)array('module' => "username"), 'serialized' => 0, 'encrypted' => 1), (object)array('key' => "password", 'value' => (object)array('module' => "password"), 'serialized' => 0, 'encrypted' => 1), (object)array('key' => "notes", 'value' => "Imported from WHMCS", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "server_name", 'value' => (object)array('module' => "name"), 'serialized' => 0, 'encrypted' => 0), ), 'package_meta' => array( (object)array('key' => "producttype", 'value' => "dedicated-manual", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "rebootmethod", 'value' => "auto", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "enable_provisioning", 'value' => (object)array('package' => "configoption1"), 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "enable_power", 'value' => (object)array('package' => "configoption2"), 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "enable_datatraffic", 'value' => (object)array('package' => "configoption3"), 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "enable_console", 'value' => "on", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "enable_sensors", 'value' => "on", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "powerdown_on_suspend", 'value' => "", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "powerdown_on_delete", 'value' => "", 'serialized' => 0, 'encrypted' => 0), (object)array('key' => "deletevps_on_delete", 'value' => "", 'serialized' => 0, 'encrypted' => 0), ), 'service_fields' => array( 'dedicatedip' => (object)array('key' => "ip", 'serialized' => 0, 'encrypted' => 0) ) )); 4) try WHMCS import again.

Even inside a chroot, executing untrusted binaries as root on the host system is NOT a good idea. Customer could have installed a trojan horse and named it /bin/passwd .... Better to start a rescue cd such as sysresccd inside the virtual machine, and run your mount -> chroot -> passwd commands there. Such actions are usually performed manually, and not automated. Not sure if they are using that method for resetting passwords though. Could also be that they added a custom start-up script to all their OS templates that can fetch and execute instructions from some central server. That is reasonable secure, but will not work if you install your own OS.

While our commercial server provisioning module does suppport creating Vmware VPSes, I wouldn't recommend it, unless you are targetting the enterprise market (with enterprise pricing ). The license terms of the free version of Vmware ESXi do not allow you to sell VPSes, and commercial Vmware VSPP licensing is kinda expensive.

As mentioned in the other thread, I'm not entirely convinced php.ini is the file that has the real problem, as it does not matter whether or not I have an include_path line in php.ini on my own systems. Normally the problem is that people have a setting in their webserver configuration file (not php.ini) instead that sets an include_path using a command that disallows overriding the value with set_include_path() later on. That is not a nginx specific problem. E.g. when using Apache mod_php, the bad configuration line could be in httpd.conf or in some related file that defines the <VirtualHost> and look like: php_admin_value include_path "/some/dir" Or when using a webserver that uses FastCGI/php-fpm, it would be in php-fpm.conf (or any of the files it includes in /etc/php-fpm.d), and look like: php_admin_value[include_path] = /some/dir Those should be replaced with respectively: php_value include_path "/some/dir" Or: php_value[include_path] = /some/dir Which is the flavour of the command that does allow overriding. That is if there is actually a need to have the include_path, e.g. if you are sharing an installed PHP library with multiple websites hosted on the server. If you are not, just remove the lines...

That's actually a bit strange. If you do not explicitly set the include_path setting in php.ini, the defaults do should work. I do not set that value there myself. Still wonder if the real problem isn't in any of your other (php-fpm related) configuration files. And that making the setting in php.ini perhaps prevents the other configuration file from imposing the restriction, as a side effect. But either way, glad it solved it for you.

You don't need to put in any directory, just double check the value can be overriden by code. If you're using nginx instead of Apache, check your php-fpm.conf. Same concept, php_admin_value cannot be overriden, php_value can.

Was already a problem before the new regulations. You need to advertise pricing inclusive all taxes when selling to consumers, but Blesta currently does not allow you to. Even if you only sell to one country with a single VAT percentage, you get rounding errors when selling more than one item. Existing thread: http://www.blesta.com/forums/index.php?/topic/1900-inclusive-tax-needs-to-display-full-price-in-order-form/

Blesta attempts to add the phpseclib folder to the include_path by calling set_include_path(), but looking at the include_path in your stack trace failed to do so. For testing purposes, try modifying in app/models/license_manager.php // Set the include path to include this vendor library set_include_path(get_include_path() . PATH_SEPARATOR . $this->path_to_phpseclib); to: // Set the include path to include this vendor library if ( ! set_include_path(get_include_path() . PATH_SEPARATOR . $this->path_to_phpseclib) ) { die("Error! My webserver configuration prevents me from changing the include_path!"); } If it prints out that error, it conforms my theory. In that case, go through your Apache configuration files looking for a line starting with "php_admin_value include_path" and change it to "php_value include_path" "php_admin_value" means: set this configuration option, and as a security restriction prevent code from overriding it at runtime. "php_value" does allow code to change the value set.

But at least the service fields could be updated manually in the service's setting then, while keeping the other information like the service's expiration/renewal date. Our module does allow changing the service's fields. But that currently doesn't work, because the module_row_id is wrong. If you disagree with updating the module_row_id, at least prevent the user from changing the module of a package that has active services tied to it. The current situation in which you do allow changing the module, and do show the tabs belonging to the new module in the admin and client area, makes it appear like the module can be changed.

Problem can also occur if you were using the universal module first, create services with that, and try to switch them to NOC-PS later. Instead of using NOC-PS as module from the start. Is that the case? Created a bug for that: http://www.blesta.com/forums/index.php?/topic/3906-changing-module-in-package-settings-does-not-update-module-row-id-of-existing-services/

1) you are using the "universal module" first. 2) later you install a proper module for the service you are selling, and update the "package settings" of the existing package so that it is using the new module. Expected behavior: If the module is changed to a totally different one, I would expect existing services to be updated, and module_row_id to be set to the new one selected in the package settings. Actual behavior: When the client views a service purchased before the change in the client area, it does is shown the tabs of the new module. However they will not work, as the module is unable to obtain its module row. Calling $this->getModuleRow() inside the module returns boolean false. Database table "services" shows the existing services still have a module_row_id belonging to the universal module. Related threads: http://www.blesta.com/forums/index.php?/topic/3891-remove-module/ http://www.blesta.com/forums/index.php?/topic/572-dedicated-servers-vps-module/?p=28549

Note that the <div> can contain subelements and can cover the total tab.

Would just create a big <div> of your own inside your tab. <div id="mycontent">initial content [...]</div> and change that using Ajax with something along the lines of: $.post(document.location.href, {'somepostparameter': 'value'}, function(reply) { document.getElementById("mycontent").innerHtml = reply; }, 'html'); (not tested) Having the <div> of your own, prevents you from having to make assumptions about the Blesta template that includes the tabs. It may change in the future, or it may have been modified by the user if you develop for others.