Cody

I haven't been able to duplicate. This task is run by the "processRenewingServices" cron task. You can see when this task ran using the following query: SELECT `log_cron`.* FROM `cron_tasks` INNER JOIN `cron_task_runs` ON `cron_tasks`.`id`=`cron_task_runs`.`task_id` INNER JOIN `log_cron` ON `log_cron`.`run_id`=`cron_task_runs`.`id` WHERE `key`='process_renewing_services' AND `cron_task_runs`.`company_id`='1' ORDER BY `log_cron`.`start_date` DESC

I think we can make the importTransactions routine comparable to importInvoices if we allow whatever WHMCS says is applied to an invoice to be applied. That is, bypass Blesta's apply transaction routine which does all of the necessary checks. Obviously this may cause some issues if your WHMCS data is not properly accounted for.

Looks like a 20% improvement, which is significant. Looks like performance has an incredible amount to do with what's going on with the box since import contacts went from 2.19 seconds to 5.54 seconds even though nothing changed with respect to that routine.

By "cut" you mean those characters are not coming through?

Try the attached whmcs_migrator.php file. Place it in /plugins/import_manager/components/migrators/whmcs/. This will only run importStaff, importClients, importContacts, importTaxes, importCurrencies, and importInvoices. You should see speed improvements on importClients and importInvoices. I'm curious how they compare to your last run. whmcs_migrator.php

SELECT * FROM `tblpricing` LEFT JOIN `tblhosting` ON `tblhosting`.`id`=`tblpricing`.`relid` WHERE `monthly`='230.10' That should give you some info on where it's coming from. Absolutely, though I'll probably have you test on just clients to get a benchmark.

Where did 230.10 come from? Check your tblpricing table. That might shed some light on the 0.00 price as well. Do you have the gmp extension enabled on your machine? Just curious since importing clients took 3 times as long as importing invoices, and I'd expect you'd have more invoices than clients. FYI, I've got a theory on improving performance of the importer that I'm going to put to the test today. We'll see how it goes.

Moved to support as this is not a bug. The "renewService" module method is only invoked after the invoice for a service that renewed has been paid. It would probably not be a good idea to trigger the "renewService" module method that would then perform some action on the remote server unless the invoice for the service that renewed was actually paid.

B7 is now ready for download. Also, another tip for speed improvement is to comment out or remove line 66 from whmcs_migrator.php: #"importMisc" // works The "importMisc" method imports email log data, configurations, calendar events, and todo events. So there's a lot of inserts there that may not be necessary. We have a small data set, obviously, but 26% of the import time is spent importing that data. Your results may vary, obviously.

Judging by the time it takes to run, I'd say your WHMCS database contains about 900,000 records, or your server is slower than my 3 GHz Pentium D (circa 2005). You might consider importing into a database on a separate server than you are importing from. That is, if WHMCS database is on server1, have Blesta database on server2. This will help split the CPU/disk load. Though this really only makes sense if both server1 and server2 are on the same LAN, or are connected through a 100mbps+ connection. You might also consider performing the import on faster hardware (CPU/disk). Blesta does not create temporary tables at all, so sounds like you might also have something else running on the same machine slowing things down.

That's expected. That's correct. For what module(s)? Install the Support Manager plugin before you run the importer, or set permissions after the importer finishes. Examples of what you're seeing? For domains or products/services (in WHMCS terminology)? Package pricings come straight from the tblpricing table. You shouldn't have any prices defined in Blesta that aren't defined in your tblpricing table. Fixed in the next release. To patch change line 845 of whmcs_migrator.php to: 'qty' => $product->stockcontrol == "on" ? $product->qty : null, Tickets numbers in Blesta must be numeric. To extract only numeric values from ticket number change line 1167 of whmcs_migrator.php to: 'code' => is_numeric($ticket->tid) ? (int)$ticket->tid : preg_replace("/[^0-9]+/", "", $ticket->tid), Ticket status mappings were fixed in b6. b7 with the above changes coming soon.

The "please enter a last name" error is the result of having no last name set for a particular payment account. This is fixed in b5, I believe, where "unknown" will be set for the name if none given. If you're still having an issue with this update whmcs_migrator.php (line 54 - 67) like so and enable debugging: $actions = array( "importStaff", // works "importClients", // works #"importContacts", // works #"importTaxes", // works #"importCurrencies", // works #"importInvoices", // works #"importTransactions", // works #"importPackages", // works #"importServices", // works #"importSupportDepartments", // works #"importSupportTickets", // works #"importMisc" // works );

CORE-847 is fixed in 3.0.6.

What issues are you experiencing?

CORE-845 fixed in 3.0.6.

CORE-846 fixed in 3.0.6.

Taxes are applied to line items, however discounts are calculated as a single line item. Meaning if you have a discount that applies to 2 services, but only 1 of which is taxed, then the entire discount line item would have tax applied and you'd end up with an incorrect total. We need to discuss internally how we should be handling this. Whether there should be a discount line for each service, or whether the discount amount should simply include any tax amounts (CORE-861).

Install::tmpDir() method was updated in CORE-814 for version 3.1.0. For those that are curious, here's the new method: /** * Determine the location of the temp directory on this system */ private function tmpDir() { $dir = ini_get("upload_tmp_dir"); if (!$dir && function_exists("sys_get_temp_dir")) $dir = sys_get_temp_dir(); if (!$dir) { $dir = "/tmp/"; if ($this->getOs() == "WIN") $dir = "C:\\Windows\\TEMP\\"; } $dir = rtrim($dir, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR; return $dir; } The solution to the issue you are experiencing is to set your temp directory to the value you get from ini_get("upload_tmp_dir").

In other words, if the service is taxable then tax should be applied to the discount as well. For example: Service = $100 Tax 10% = $10 ($100 * 0.1) Discount 50% = $50 ($100 * 0.5) Discount tax = $5 ($50 * 0.1) Total = $55

Looks like ours is 20% faster. I was wrong about the original benchmarks, however. Their algorithm is not terribly inefficient (despite it being terribly insecure). I've updated the debugging in the next rev to accurately reflect the proper calculations. <?php include_once "./functions.php"; // Have to define variable with this name since WHMCS imports it via global $cc_encryption_hash = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; $x = "this is my secret string"; $y = encrypt($x); $total1 = 0; $total2 = 0; $iterations = 1000; for ($i=0; $i<$iterations; $i++) { $start1 = microtime(true); decryptData($y, $cc_encryption_hash); $total1 += (microtime(true) - $start1); $start2 = microtime(true); decrypt($y); $total2 += (microtime(true) - $start2); } echo "Total Time (ours): " . $total1 . " seconds<br />"; echo "Total Time (theirs): " . $total2 . " seconds<br />"; echo "Total iterations: " . $iterations . "<br />"; function decryptData($str, $key) { # # Get the source from the migrator # } ?>

Latest version of the migrator (b6) is up. Download.

That makes it look like you didn't start off with a fresh database. As of b5, the migrator decodes department names, so that department predates your latest import. I actually ran into a similar issue with my test environment because I made a back up of the database after I ran only select migration routines.

Hm. Are you sure it's the same ticket and doesn't happen to be a ticket with the a similar ticket number?

So... I've got some initial stats on the migrator. On my machine each DB write takes .03 seconds on average, so 1000 records = 30 seconds. Hopefully your machine is faster, but likely your dataset is much larger. Just something to keep in mind. The biggest slowdown is WHMCS' custom cipher algorithm. In case you weren't aware, WHMCS encrypts credit card numbers using AES (good for them), but they encrypt everything else using their stupid custom encryption algorithm which is nothing more than a glorified caesar cipher. Well, we cracked the algorithm a while ago and implemented it as part of the importer and it turns out it's slow as molasses. That's 0.383 seconds per string! In contrast, our AES encryption takes 0.0007 seconds per string. WHMCS' insecure custom algorithm takes 550 times longer to run than 256-bit AES. EDIT: Factoid, the full import took 39.2339 seconds. Over 25% of the time spent was attempting to decrypt WHMCS encrypted data.

What do you get for this query? SELECT supportdepts FROM tbladmins WHERE roleid=1