FRH Dave

Pretty sure it did not in my case, but I haven't had my afternoon coffee. It's possible that it was enabled and I just had to add myself to the ACL. I'll be doing another import run before going live, but in any event, no tickets made it over.

We have no tickets whatsoever importing. I'm not really concerned here, I can live with this. Thought I'd throw this out there because it apparently differs from everyone else's experience. The only thing I see is that since we did a fresh install, we did not enable the Support module before the migration. I think I submitted a feature request about this a while back (enable by default), but I'm betting that's the cause here.

To get our WHMCS migration moving, I might just go back and void all the overpaid invoices that are popping up as due. But I want to make sure I understand how this works in Blesta. A client has an invoice that was due back in mid 2012. In Blesta, for whatever reason, this shows that they owe $.01. I really don't care about the how or why, since their account is otherwise fully satisfied as of today, so I'm just going to void the invoice. If I void / cancel a past unpaid / partially paid invoice in WHMCS, WHMCS will consider that invoice unpaid forever and will repeatedly suspend the user's account for nonpayment. Does that happen in Blesta, or does Blesta simply consider the invoice totally dead? If I void the invoice in Blesta, will Blesta attempt to automatically refund the payment that was already applied?

Agreed, and it might be a good idea for one of the Blesta crew to update the OP to say that this is a work in progress. Otherwise someone might download the latest beta, have it not work, conclude that the system is broken, and not realize that work is ongoing.

The system isn't garbage. With a few hiccups, it works great. Far better than our experiences with WHMCS or PBA. Patches are being released rapid fire to nail down bugs and suggestions. You've got one of the lead devs personally helping you troubleshoot your issue, which may even ultimately turn out to be a problem on your end. And that's not good enough for you? Sorry that some brand new software had a few bugs, I guess. You may not be aware of this, but your posts are coming off as petulant and entitled. If you don't want to actually work through the issue, there are other billing systems to choose from.

Weighing in on refunds: Usually when we refund an invoice, it's a courtesy because a customer forgot to do something important. Maybe it's a customer with a dozen VPSes who forgot to cancel one -- we can make a one-time exception to the TOS and issue a refund. Sometimes we'll get double payments on invoices, especially with annual packages. A customer gets the renewal notice, forgets they created a PayPal subscription, and pays their $1500 for a year of service ... and then their subscription goes through and pays again. We'll refund the second transaction, but in this case, the invoice remains paid in full. I cringe saying this. It's just a bad practice and a sloppy hack fix. But it might be best to just take WHMCS's word on the state of the invoice. I think WHMCS considers a refunded invoice as "not due", but who knows. WHMCS is not good with numbers.

I agree - if the WHMCS importer was 100% finished, and the packages could be reordered, and the new order forms were in, and Blesta v3 wasn't basically an entirely new system, I'd be leaning on them a little harder for this. As it is, I can manage for now.

I just submitted this as a feature request, but this really does need to be addressed in the not-too-distant future. A blank database is fine for a one-time migration, but what happens when I buy a hosting company that uses WHMCS? I'll need to import that data and combine it with my existing Blesta data.

I definitely like the second option better.

Exactly! Otherwise, you can't buy another company without manually importing all the data. There should be a better data migration path.

Very interested here.

Bumping this request. I understand it's a low priority, but I thought of an idea. I hate seeing things like /?aff=102 on a URL, because it tells me I'm clicking an affiliate link. I just have an aversion to that. Maybe it's just me. But what if Blesta's URL read something like /mode=9fa83829105c2b9d -- maybe some 8-digit hex value that looks innocent, but is actually the affiliate link? Far from deceptive, it gets that "aff" out of the URL and -- get this -- doesn't indicate the total number of affiliates you have. Those of us who like to keep our company data private would appreciate that.

Currently the invoice PDFs do not show any applied credits or payments. For example, in the following circumstances: Service Total: $200.00 Existing Account Credit: $25.00 Partial Payment: $100.00 Blesta will print an invoice showing the customer owes $200.00, when in reality he only owes $75.00. This can cause some confusion among customers. We're also printing a padded invoice; the customer can then use that data to falsify their books, embezzle funds from their company, falsify taxes, etc. Or let's say one year after the invoice is paid, the customer's accountant is auditing their books. The accountant requests and gets a copy of invoice #12345, which shows the client "paid" a $200.00 balance. This creates a discrepancy with the client's books, which only show a payment of $175.00 (let's assume for the sake of simplicity that the accountant already saw the previous $100.00 partial payment and correctly attributed it to this invoice). Now the client has an unreconciled $25.00. A PDF should show the payment status in detail. Ideally, it should show each related transaction. In the case above, we might see three payment lines: Account Credit / $25.00, Visa Payment 10-21-2013 / $100.00, PayPal Payment 10-29-2013 / $75.00. Alternatively, all payments can be grouped so that we would see two lines: Account Credit / $25.00, Account Payment $175.00.

Currently when importing data from WHMCS, it's recommended that you start with a clean Blesta install, free of customer data. However, there will be circumstances where this is undesirable. If I purchase a web hosting company that uses WHMCS, for example, I want to be able to automatically import all their data. Obviously, I can't wipe my current Blesta database just to capture their client data.

So what happens in the following scenario: 1) Client has invoice for $250.00 2) Client has existing account credit for $20, which is automatically applied to the invoice 3) Client now owes $230.00 4) Client's PayPal subscription comes in for $250.00 If what you're saying is that the $20.00 will be applied towards the oldest open invoice, that's fine. That's how WHMCS works. But in the meantime, the client (in Blesta) is being advised he has an overdue balance. We can't test this without firing off cron, which is a bad idea -- all the client emails addresses are in there, and I don't want our entire userbase getting confusing emails from Blesta since it isn't live yet. What's more confusing is that the invoice was overpaid by $24.99, not by $183.98. To make this right, the client's account should have been credited for $24.99. In fact, since this is an ancient invoice that's already paid in full, and since the client currently has no account credit, and given the circumstances (rescuing data from WHMCS), it should just accept WHMCS's starting accounting data as golden.

I'm working through some other entries, but AT FIRST GLANCE, it looks like the pricing information is correct except as noted below. Balances appear to correctly reflect configurable options and promotional pricing. I'll need some time to do a more detailed audit, but on the surface, we're so close I can taste it. Two more hiccups that I see right now. Can't promise more won't come up during the audit: First: The invoice PDF still does not reflect account credits as partial payments. The invoice PDF for the transaction below shows no payments at all. No PDFs show payments at all other than the "PAID" watermark. If this is functioning as designed, I'll go submit this as a feature request. But it should at the very least reflect account credits applied, otherwise we get into invoice padding where we're submitting an invoice for an inflated amount. Second: We're still seeing an issue with some old invoices, with a twist. A client has an invoice from 7/7/12 in the amount of $208.97. An existing account credit of $24.99 was applied, leaving the client responsible for $183.98. The client paid $208.97 -- he paid the invoice in full, causing the $24.99 to carry over to his next invoice. When imported, Blesta says that he paid $24.99 and owes $183.98. This MIGHT be because the original invoice in WHMCS has a negative balance due, because of the credit that gets carried forward. When I view the transaction in Blesta, it shows Type = Other, Amount = $208.97, Credited = $208.97, Applied = $0.00, Number = (a valid PayPal transaction #, I assume), status = Approved, date = July 07 2012 9:08:15 AM. That's interesting, because usually the payment shows up in the "Applied" field.

Getting ready to try v5. Regarding the passwords, I think the best way is to require all users to reset their passwords after the migration. That's the most secure and simple method, IMHO.

About the tickets not coming over?

Here's the rundown of import-related issues we're still facing: Prices are incorrect in some modules, especially those with configurable options. A customer with a $100 VPS + $20 panel + $30 management is only being charged $100. Similar to #1, prices that have been discounted by coupon or overridden manually are incorrect. Cody remarked that it might be possible to pull this data out of the "recurring price" field in WHMCS. Customers who have been issued credit at any time in the past in WHMCS are being asked to pay the credit amounts in Blesta. Cody remarked that this one might be fixed. Invoices do not show partial payments / credits. Might be related to #2. "&" symbol in company name in WHMCS translates to "&" in Blesta. Five more to go and then all we have left is some auditing and tweaking, and we're in.

Look at any given user with those services. Is the price correct in their profile?

No. When the customer views the invoice PDF, it shows no payments at all. It shows a total due of $179.99. But when the customer is logged in, it shows amount = $179.99, paid = $19.02, due = $160.97, with a due date of over a year ago. By all means. WHMCS is horrible at accounting, so we've grown accustomed to never trust its numbers. 9 times out of 10, everything is straightforward with us. But once in a great while, we'll need to apply a courtesy credit or adjust someone's recurring price or do something weird. In WHMCS you simply give it the new value. For myself, I'd rather (NOT for imported data) see Blesta reflect the starting price, then any adjustments (ie, "Recurring FRH Courtesy Credit: -$9.00"), then show the final amount. Then there's never any question as to why a customer is paying a non-standard price. I think there's definitely a place for price adjustments, it's just that WHMCS has virtually no accountability. As you said, it plain sucks at keeping track of money. I'll start a suggestions thread with some accounting ideas that just jumped into my head. I don't think Blesta should be the primary source for bookkeeping, but it already has the information, and if we can take that information and make it usable, then that's just one more thing we can use to reconcile against. Also, just found another issue. A customer has an "&" in their company name, and it's coming across as "&" in Blesta. It's that way in the client area, the PDFs, and the admin side.

Normally I'd cringe at the thought of something so kudgy. Pricing should always be backed up by solid accounting. But given the circumstances, that we're doing a data liberation here, I think it's a reasonable solution in this case. This would also immediately resolve all the coupon / discount / bundling issues we talked about previously, as long as the imported price sticks on recurring invoices.

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

I'm using configurable options. When I look at Client > (select the client) > (locate a dedicated server on which the user has bought recurring upgrades through configurable options) > Manage, the price listed is just the base price of the service. Same thing on VPSes using the SolusVM module.

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.