Jump to content

Cody

Blesta Developers
  • Posts

    1,574
  • Joined

  • Last visited

  • Days Won

    74

Posts posted by Cody

  1. After migration, I logged in as a client who has quite a few services with us.  It shows the client has having a $311.93 outstanding balance, when in reality they should only have $114.97.  Here's what it shows:

     

    Invoice # -- Amount -- Paid -- Due -- Date Billed -- Date Due

    3133 -- $114.97 USD -- $0.00 USD -- $114.97 USD -- Oct 16, 2013 -- Oct 26, 2013

    0 - $179.99 USD -- $19.02 USD -- $160.97 USD -- Aug 05, 2012 -- Aug 15, 2012

    0 -- $97.98 USD -- $72.99 USD -- $24.99 USD -- Jul 13, 2012 -- Jul 18, 2012

    0 -- $59.97 USD -- $48.97 USD -- $11.00 USD -- May 21, 2012 -- May 26, 2012

     

    Ah, I think I know what's happened there. Should be fixed in the next update.

     

    In WHMCS, the client only has the following invoices unpaid:

     

    3190 10/25/2013 11/04/2013 - $189.99 USD PayPal Unpaid

    3133 10/16/2013 10/26/2013 - $114.97 USD PayPal Unpaid    

     

    I'm not concerned about the invoice from 10/25, as that was generated after I pulled the database over.  Several issues:

    • The old invoice #s.  I'd like to have the old WHMCS invoice # copied over for old paid invoices.  If that's not possible, it's acceptable to use "0".  But there should be a sanity check that any time an invoice has a due balance, the invoice number should not be "0".
    • The $179.99 invoice from 8/5 was paid in full and on time.  The client had a $160.97 account credit, and paid $19.02 via PayPal.

     

    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'

     

    • The $97.98 invoice from 7/13 was paid in full and on time.  $24.99 credit, $72.99 via PayPal.
    • The $59.97 invoice from 5/12 was paid in full and on time.  $11.00 credit, $48.97 via PayPal.

    Feel free to do the same for these as well.

     

    • Viewing the invoice for any of the payments does not show the "partial payments" (incorrect as they are) reflected above.  It shows the entire amount is due.  If the client legitimately made a partial payment, it should show the total balance, a line item for each partial payment, and the remaining balance.

     

    Does Blesta show a partial payment applied to the invoice? If so it should be reflected in Blesta.

     

    Can someone else with a similar situation check your clients for phantom invoices?  I only checked one customer, but I'm sure there are more.

     

    I'm posting this here since I know you're working hard on the importer, figured it would be easiest to keep everything in one spot for now.  Feel free to relocate to the bug forum if you want.

     

    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.

  2. Restored my blank database and ran the import.  Huge improvement.  The packages have prices now, but many of them are incorrect.  This may be because the modules aren't importing the configurable options from WHMCS.

     

    Quantity still shows as zero for the autorelease modules.  Actually, I'm fine with this.  These are legacy packages that nobody should ever be ordering, as they'll be replaced with modern ones.  Good show.

     

    So a customer with a $50 VPS and a $20 control panel and a $30 management option is only being charged $50.  Coupons didn't copy over, either.

     

    WHMCS must have a database field for storing the price, since admins can override the price simply by typing the number in the profile screen (see the "first payment amount" and "recurring amount" fields in the WHMCS products / services tab for a client).  Can you grab the value for the recurring amount and kludge it in as the product price?  That would take care of all the discounting / price override options we've been discussing, since the recurring amount is always the final amount after discounts, coupons, add-ons, etc.  It wouldn't be "proper", but it would work.  I could see how the client would lose that discount if they ever changed packages, but that's how out price grandfathering is going to work anyway.  Keep it till you change it.

     

    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.

  3. 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.

  4. 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.

  5. 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
    
    ---
    
  6. I guess I don't follow.  Each TLD product shows pricing for 1-10 years.  They are all identical...

     

    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.

  7. I'll do more digging to see what I can find wrong with the import but I did notice that all domain tlds were imported multiple times with different modules.

    I don't see any difference between the different tld entries except the module they are linked to.

    lhHxe1I1t0.png

     

    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.

  8. The highest service number is #1 in Blesta, which corresponds to #1 in WHMCS.  There is only one service showing in Blesta.  It appears all the clients are there, as well as all of the packages.

     

     

    I use Autorelease, which is their version of your Universal module.

     

    Interesting. We'll take a look.

     

    It's possible it's failing on the dedicated servers.  That would explain it.  But user #1 in WHMCS doesn't have any dedicated servers; only shared, IPs, SSLs, and some other things.  If it's crashing on dedicated servers, wouldn't the rest of those services come over?

     

    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.

  9. Almost, but not there yet. We need to ask for 5 additional domain fields:

     

    1. Registrant type

    2. Registrant document type

    3. Registrant document number

    4. Domain contact document type

    5. Domain contact document number

     

    This is needed for domain transfers too, something WHMCS hasn't been able to fix. We have a third party module because of this.

     

    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.

  10. WHMCS package #1: cPanel user account, user #1 - made it to Blesta, assigned to correct user

    WHMCS package #9: cPanel user account, user #4 - package created in Blesta, but not assigned to any user

    WHMCS package #11: cPanel user account, user #6 - package created in Blesta, but not assigned to any user

    ... the rest of the packages have similar results.

     

    If I sort my WHMCS packages by username, starting with user #1:

     

    WHMCS package #1:  cPanel user account, user #1 - made it to Blesta, assigned to correct user

    WHMCS package #121:  TheSSLStore module, RapidSSL, user #1 - package created in Blesta, but not assigned to any user, no module assigned

    WHMCS package #118:  TheSSLStore module, Comodo Essential, user #1 - package created in Blesta, but not assigned to any user, no module assigned

    ... the rest of the packages have similar results.

     

    Does the importer process entries by username, or by the actual sequence in the database?  If by username, then I'm guessing it's failing on the RapidSSL product / TheSSLStore module.  I can try again using the modification you posted above, unless you want me to try troubleshooting this.

     

    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.

     

    All the cPanel packages were correctly assigned to the cPanel module.  I haven't verified, but it looks like the hash came over correctly.

     

    All of my domains were correctly assigned to the Logicboxes module.  My NetEarthOne information appears correct in this module.

     

    All of my SolusVM packages and colocation packages were assigned to the Universal module.  Blesta created one product label in the Universal Module for each VPS node, which appears to also store the access keys.

     

    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).

     

    All of my dedicated servers were not assigned to any module.

     

    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.

  11. Ugh, I kind of wish someone else was having the troubles I am.  Any chance you can shoot me a copy of your my.cnf and php.ini?

    Are you importing a copy of your full whmcs database, or are you using a smaller test database?

    email: my username @lithiumhosting.com

     

    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.

  12. Similar results, but without MySQL crashing:

     

    The import completed but the following errors ocurred:

    importServices: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module_row_id' cannot be null on line 124

     

    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;

     

    importSupportDepartments: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens on line 124

    importSupportTickets: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens on line 124

    importMisc: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens on line 124

     

    These are just reflections of the original error above.

  13. Have you read the comments on the manual page I linked, above?

     

    Have you tried the following:

     

     

    The way I managed to rectify the problem was not with the mysql settings, it was actually in php.ini


    setting connect_timeout = 300
    and default_socket_timeout = 300


    they are set to default at 60 seconds and this caused my problem.

     

     

    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.

×
×
  • Create New...