Michael

We have to make a lot of assumptions if we start voiding invoices and cancelling services. To start, cancelling a service would be immediate and permanent. If you accidentally mark the client as inactive, you've done something potentially disastrous. If we void an invoice that had a partial payment, that difference is then returned as a credit.
 
If we do none of this, but simply stop billing people with active services whos accounts are marked inactive or fraud, and the account becomes active again later -- those services will be back billed from the time the account was made inactive.
 
So, the simplest, most straight forward way to handle it is to manually void and cancel. Marking the client inactive or fraud prevents them from logging in, and designates the account as such in the system. We want to leave you with control over how to handle any open invoices and active services.

I have assigned this to CORE-852 Add support for vault to quantum gateway.

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.

Doesn't APF/BFD have issues with virtual servers? We use to use it and switched to CSF/LFD because of it if I recall. Maybe we can nudge Interworx towards CSF/LFD. 

Very nice!  We're moving off cPanel and into InterWorx, so unfortunately this doesn't help us much.  But if you make something to facilitate BFD, we're definitely interested.
 
Keep up the good work, and thanks for contributing!  Blesta is an open gold mine right now.  It would be very easy for the right coder to come along and establish their company as "the" Blesta modules company.  If only I knew PHP.

I'm pretty sure the card readers could just input the card number into the appropriate field in Blesta on swipe, through the browser on your device (iPad or whatever). There's a lot that can be done to support this more fully, like a mobile interface, and some tweaks with card present in mind.. but yeah, not high priority at the moment.

Really appreciate the progress on this.  I know some people think an importer is their entitlement; however, having used competing billing systems importers or got into dialogue with the devs regarding one Blesta has been the best experience so far.

Ticket status is fixed for the next rev. We're working on adding diagnostics, and looking at ways to improve runtime.

I checked around and didn't see another feature request about this so I wanted to bump it.
 
I've been a strong proponent of Blesta since the v3 Beta, love lots of things about it...however, I can't say that I love the coupon system.  It needs to be WAY more robust...and hopefully soon.
 
I know for me personally, coupons are a major factor in the hosting industry (as well as other industry's/services that could use Blesta)...and only being able to give permanent discounts, or single term discounts is a huge killer for me.
 
At the moment, during my relauch, I'd love to be able to give 75% off the first 3 months, or 20% off for life...something like that...but as the system stands...I can't do that.
 
CubicWebs idea is pretty much spot on as a start, but having even more than that...an awesome, robust coupon system would be nice.
 
----------
 
Coupons should be able to have one, some, or all of the below options, the admin can choose...and of course put settings for each one
 
Percentage/Amount/term discount (buy 3 months get one month free...etc)
Single Time Period or recurring
Uses
Coupons restricted to term length, not just specific package (have 2 coupons for the same package, one works for 1-3 months terms, other works for 6-12 month terms as an example)
 
While I don't think this should be #1 priority (though I do think the basic system Cubic mentioned should be very high on the priority list for the hosting industry), I think having such a robust coupon system would be "another" huge selling point for blesta.

I would like a coupon tier please in the future, where we can make a coupon just for a month or a year. Or even valid for a month or a year. Maybe a tick box feature with the day, month, year, one time. Or even a auto generator so it pulls what values they are.
 
So maybe one package has this:
 
[  ] 2 day
[  ] 4 month
[  ] 12 month
[  ] 1 year
[  ] one time
 
Because at the moment if a user say wants to buy hosting from you. They find a coupon for 60% off your package. But accidentally clicks on the yearly price. They enter the coupon and BAM they now get 60% off your yearly price. Even though it's not valid for it.
 
Just a little inside of my feature request

You need to make sure you have coupons enabled for each order form as well:
 
Packages > Order Forms
 

 
 
It shows as a link on the order form 1st and 2nd page, once you get to the 3rd step it won't show anymore and you'll need to go back to enter it.  It's under the total/subtotal on the right hand side, when you click the link it will open up the field for entering the code.
 

The "From:" email is set on a per email basis, so you will need to open each individual email template to update the address.
 
Settings > Company > Email Templates
(or just throw this on the end of your blesta domain: /admin/settings/company/emails/templates/)

We submitted a responsible disclosure document to them today, all issues we found were confirmed to still be issues in their latest release. We'll see how they handle it.

Love it mate, thanks for sharing will help alot of people.

Love it mate  maybe a nice place in the Contribute mate.

/app/views/client/foldername/blueviolet.css
 
You can edit that carefully, and if you bought the layout you can get everything needed for it, however I can give you the following:
 
- Black
- Blue
- Red
- Green
- Brown
 
But I can only give you the CSS and Images, you will need to edit it according to your liking.

Haha mate, on WHT he's slated every single one. So not much for him to choose from.

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.

There's no link in WHMCS between the refunded transactions and the original. Refunds appear to be handled simply as negative credits, unless I'm mistaken and WHMCS only uses them for display purposes, not for accounting?
 
 
I'm seeing something different. Considering the following scenario:
 
An invoice is due for $100. The client pays $50, then $25 is refunded. The new due amount for the invoice is $75. The invoice is still considered unpaid.
 
 
It would appear to me that if an invoice is "refunded" that means it's considered paid in full. The problem with that there may not be any transactions that make that a true statement.
 
Moreover, taking my example above. If I refund the additional $25, the invoice is now considered "Refunded" even though it still has $100 due. That makes no sense to me.

FYI, mine is line 78.  I know this wasn't directed to me but I'll see if it makes mine work better with showing errors.

The issue you have is related to custom client fields. Somehow you have a custom field assigned to a client multiple times in WHMCS (or your client_values table in Blesta is not empty).
 
Try changing line 334 from:
 
                $this->local->insert("client_values", $vars);  
to:
                $this->local->duplicate("value", "=", $vars['value'])->insert("client_values", $vars);

I would say they should make two importers LOL na maybe a option.
 
Fresh Import [ ]
Merge Import [ ]
First system I know to do that.

Take a look at tblaccounts.  The refundid is the id of the original transaction id that was refunded.  The amountout is the amount of the refund.
This means that an invoice can be paid in full by one transaction which is what you would expect, but another transaction could be a partial refund.
 
This happens all the time, an invoice for $100 could be paid by one transaction but then a refund of $25.00 was issued on that original payment and refunded back to their credit card or paypal account.
This could be for any reason, but the issue here is that the invoice is considered paid in full but shows a status of refunded.
 
WHMCS uses refunded for a status whether the invoice is 100% refunded or just partially refunded.
 
You're going to have to look at transactions that have a refundid and process them differently.  Same with the invoices they are tied to.
 
Here's a potential and rough work flow.
Is transaction a refund? What is the invoice amount due Is this a full refund? If yes, void the invoice If no, the invoice is paid

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.