Cody

Beta version 4 of the migrator has been added. Get it here. Changes in this version: Imports custom service/domain pricing as individual package pricings and assigns that pricing to the service Tweaks the way invoice numbers are imported so as to maintain the exact same number as in WHMCS.

Ah, I think I know what's happened there. Should be fixed in the next update. Could you send me the invoice record as well as the transactions that apply to the invoice? Use the following queries (replace INVOICEID with the proper invoice ID): SELECT * FROM `tblinvoices` WHERE `id`='INVOICEID' SELECT * FROM `tblaccounts` WHERE `invoiceid`='INVOICEID' Feel free to do the same for these as well. Does Blesta show a partial payment applied to the invoice? If so it should be reflected in Blesta. This is the funny thing about WHMCS, it plain sucks at keeping track of money. An invoice can be marked as paid without any transactions being applied. Credits can be added to a client's account from thin air (no transaction). And to pay multiple invoices with a single payment requires creating new a invoice(????). It's weird, but we want to try to work around the anomalies as best we can so we really appreciate any insight into your invoices and transactions.

I think your idea is a good one. I think WHMCS might store the price for each service on the service record itself. If so we could import every unique pricing used by a service as a package price, that way all service pricings remains accurate.

For those of you not seeing tickets imported. Check the support_tickets table in Blesta to see if it's empty. Most likely the reason you don't see any tickets is because the migrator will import your WHMCS admin users and assign them to necessary departments (it does nothing with the user you are currently logged in as). Log out and log back in with your WHMCS admin user (that was imported). Also, double check the Support Manager settings for Support Departments and ensure all of the correct staff users belong to the appropriate staff departments.

An updated version of the migrator is now available for download here. This latest update should minimize the number of packages needed for registrars, as well as corrects issues with importing package pricing and 'autorelease' packages. For users with a lot of data to import, you may benefit from changing (in /plugins/import_manager/components/migrators/whmcs/whmcs_migrator.php): Configure::set("Whmcs.import_fetchall", false); to: Configure::set("Whmcs.import_fetchall", true); Also, it would be great to get feedback on execution time vs the two methods (Whmcs.import_fetchall set to true vs false). From my testing there was a 1% increase in speed when set to true, of course this method requires a lot more memory.

So you think it should only import packages for TLDs that are assigned to a specific registrar? I wasn't sure if it was a requirement to assign a registrar to a specific TLD in order for the TLD to be orderable, but I guess it is.

Version 3.0.5 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.0.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes - Blesta Core - Version 3.0.5 ## Version 3.0.5 2013-10-24 ### Bug * [CORE-806] - Order: Incorrect CSS URI on Windows servers * [CORE-807] - Stripe: Invalid conversion of decimal values into interger representation * [CORE-808] - Support Manager: Does not use system temp directory when downloading attachments * [CORE-809] - Order: Nonmerchant gateways do not receive description * [CORE-811] - SolusVM: OpenVZ nodes fail to provision due to error "Invalid node or group" when more than 1 node can be chosen from * [CORE-812] - SolusVM: IP address and password do not get set when provisioning a service with a password with special characters * [CORE-813] - Order: Return URL not properly set for nonmerchant gateways * [CORE-815] - Support Manager: Parsing charset fails for some email headers * [CORE-817] - Client creation through the admin interface always sends welcome email * [CORE-823] - Modal confirm on edit currency displays escaped HTML content * [CORE-824] - Unable to change service renew date if service meta fields are required * [CORE-827] - Plesk: Reseller accounts are unable to suspend services * [CORE-829] - Security: System overview widget fails to sanitize some data * [CORE-830] - Security: Feed Reader widget does not properly sanitize description * [CORE-831] - Order: Domain and other order type process has incorrect flow * [CORE-833] - Universal Module: POST header not being properly sent * [CORE-836] - Logicboxes: Multi-level TLDs may not be selected * [CORE-837] - Namecheap: Multi-level TLDs may not be selected * [CORE-838] - Logicboxes: transfer domain results in "required Parameter Missing: Customer-Id" * [CORE-839] - Import Manager: Does not display errors that may be returned from the migrator * [CORE-842] - Order: Some addon services remain in cart after primary service removed ---

You have multiple registrars. Each Blesta package can only be assigned to 1 registrar, therefore you need at minimum 1 package per registrar. However, because WHMCS allows setting different prices per TLD you need a different package for each TLD to ensure that the package assigned to the service for that TLD has the correct pricing. If you had the same price for each TLD then it would be theoretically possible to assign them all to the same package, but the importer doesn't go through all the trouble trying to determine that. It's certainly possible to tweak the importer to produce one package per registrar with all TLDs, though I suspect the majority of people won't be able to do that. That said, we're looking to introduce a plugin in Blesta that will simplify pricing for TLDs, since they are so different than most other packages. This will essentially be an option to allow the package to defer to the module for pricing as opposed to the pricing being defined at the package level.

Can you send me a dump of your tbldomainpricing, tblpricing, and tblcurrencies tables?

This is expected. WHMCS stores pricing based on TLD, whereas Blesta only stores pricing based on package. With Blesta you can select multiple TLDs for a single package and define a specific pricing. Packages for domain registrars are non-existent in WHMCS so Blesta has to create them as one TLD per registrar to ensure that your pricing per TLD per registrar remains the same.

The logicboxes module simplifies this by forcing all contacts to be natural persons/individuals only. That is, "es_form_juridica" is always "1".

Interesting. We'll take a look. Normally, yes, but this particular error throws an exception, which halts all further process for that particular batch. If you do as I suggested (edit line 818), it should continue processing services and skip those it can't find module row records for.

The only fields available for ES contacts (according to the logicboxes API docs) are: es_form_juridica es_tipo_identificacion es_identificacion If you can provide documentation outside of that we'll take a look, but from what I can tell the module fully implements the capabilities of the logicboxes API with respects to .es domains.

The importer processes items in batches. That is, all clients are imported, then it moves on to importing all contacts, etc. So it's something like Clients > Modules > Packages > Services. It can't import a service until it has imported both the client and the package; and it can't import a package until it has the module. So I guess to clarify what I wrote earlier, what is the highest number service ID that is imported? By the time services are imported you should already have all of your clients, contacts, modules, and packages. Yup, that will happen because the SolusVM module created by SolusVM is a bit odd and would take quite a bit of time to reverse engineer (it's 100% ioncube encoded... why, I don't know). How are dedicated services stored in WHMCS? That is, what module do you use? My guess is this is where you're running into trouble.

My guess is you've got a lot of data. Seems like there's some correlation between a lot of data and this particular error given that you generally get about the same number of clients imported before the connection is reset. Try this. Update line 157 of whmcs_migrator.php: from: foreach ($this->WhmcsClients->get() as $client) { to: $clients = $this->WhmcsClients->get()->fetchAll(); foreach ($clients as $client) { This will, undoubtedly, require you to set your memory_limit in PHP to something very high (all dependent on how much data you have). But it's worth a shot.

Moved to support forum as doesn't appear to be a bug.

CORE-842 is fixed for 3.0.5.

I was able to duplicate. Created CORE-842.

Moved to support as not a bug.

This error hints at the importer not being able to determine the module row used for the service. Check to see that all of the modules were imported and all contain at least some data. If you can figure out the exact service that's attempted and triggers this error we might be able to investigate a little. Aside from that the only thing to do is to skip the service: Add the following to line 818 of /plugins/import_manager/components/migrators/whmcs/whmcs_migrator.php if (!$module_row_id) continue; These are just reflections of the original error above.

Another things that might help in terms of debugging:

Make sure you update the migrator file as well before your next attempt.

Have you read the comments on the manual page I linked, above? Have you tried the following: Also, have you looked into increasing mysql's "max_allowed_packet" size? P.S. Since the issue is occurring when importing clients, update the migrator (/plugins/import_manager/components/migrators/whmcs/whmcs_migrator.php line 23-36): from: $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 ); to: $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 ); That way you don't waste time waiting for the rest of the import processes to finish.

See the MySQL manual for reason why the MySQL may "go away".

The hardware already exists for my raspberry pi sprinkler system, so I think I'll probably just pick up that kit and write the application to run it.