Thursday, March 29, 2012

QuickBooks Online Integration

We are happy to announce that support for QBOE (QuickBooks Online Edition) integration should be coming with the next release. We completed the coding for it yesterday so it needs to go through QA before it is a officially ready.

Integration with QBOE is very similar to the desktop edition with some exceptions. Probably the biggest difference is the transport paradigm. Pushing to QBOE is an active process where we POST data to the QBOE datacenter whereas the Desktop Edition requires a small go-between application called the QuickBooks Web Connector to contact Flex and pull down the requests. The other main difference is QBOE requires a connection ticket to be set in accounting integration settings and also in workflow Flex prompts for a session ticket if authentication is required.

Other differences worth mentioning are sales tax & discounts. In the Desktop Edition we send sales tax as the final line item because the sales tax area does not allow us to directly set the sales tax amount. In QBOE, sales tax is simply a field on the Invoice or Credit Memo that we directly set with our calculated tax from Flex. Discount line items are not supported in QBOE, so they are sent as standard Service item lines.

QBOE online features are a subset of the Desktop Edition features which QBOE online users are aware. We can push Invoices, Credit Memos, and Received Payments to QBOE. You may notice Purchase Orders are not on that list. At this point the QBOE API does not support Purchase Orders however Purchase Orders can be created from within QBOE. As API support becomes available for Purchase Orders, we will add support on our end for them.

We are excited to support another accounting integration. Please contact us after the next release to get access to the QBOE integration.

Monday, March 26, 2012

Release Post Mortum / Ireland / Labor

The Release

As most Flex users know, on Thursday night we released version 4.4.29 of Flex, skipping over four version numbers to get there.  In our last post we talked about how our release automation tools make it tricky to retag release candidates as GA releases, so we just burn minor revision numbers when release candidates get rejected.

In this case QA rejected the release candidate not once, but four times, initially for fairly serious reasons and later on for nit picky glitches that most users wouldn't notice.  We did the rework anyway and late Tuesday night QA cleared 4.4.29 for release.  We've instituted a policy that requires us to send pre-notifications for a release at least 24 hours in advance (except in the case of emergency releases), so the pre-notify went out on Wednesday morning and the release was pushed to everyone Thursday night.

The morning after a release always makes us a little nervous and our fear was that all these policy changes and extra time for UI regression testing wouldn't make any difference -- we'd end up with a mess to clean up the following morning all the same.  Luckily that's not what happened.  Friday morning was very quiet.  We had one customer notice that sorting for the container builder screen had been left out when the component was redesigned for storage containers, but other than that issue the only errors we saw come in were related to serialization changes -- typical stuff related to having a stale version of the Flash client.  Hopefully the recent validation logic we've added to warn the user when using a stale version of the client gave everyone the necessary heads up.

All in all, a very quiet morning after for us.  We all know the definition of insanity is doing the same thing and expecting different results.  But the dark underbelly of this maxim and our worry going into this last release was that doing something different would still yield the same results.  Score one for a more formal release process.  Hopefully the QA success on this last release is repeatable going forward.

Flex Europa

Most Flex systems, regardless of where the customers are located, are hosted in cloud data centers located in Northern California and along the Columbia River in Boardman, Oregon.

Recently we've built up a reasonably large number of customers in Europe and it seemed to us like there might be enough critical mass to justify a dedicated server for European customers.  The hope was such a move would increase response times for European customers, but there was no way to know this for sure.  Moving the server closer seemed like a logical way to speed things up, but since there are so many factors that contribute to response times, there was no way to know but to give it a try.

We added a new cloud instance located in Dublin, Ireland and moved all Flex customers located in Europe and Africa to this instance.  One of our customers, Gareth Jeanne from Stage Sound Services in Cardiff, was kind enough to send us this screen shot from his browser's performance monitoring plugin:

The interesting bit here is from the graph at the top, where it shows that the response times, at least for this user, are more than twice as fast as they were when the data had to cross the Atlantic.  Very encouraging data.  Our user base in Australia, New Zealand and the Pacific Rim is growing.  A little more growth there and we might consider adding a server in Singapore.

Labor Party

Chris, Devon and I had a great design session this morning where we sketched out the initial functional requirements for the much anticipated labor module.  I'm hesitant to discuss new features while they're still speculative, but suffice it to say that we'll be rolling out some labor management tools that will be the first of their kind in the industry.

I'll be taking our requirements doc and doing technical design today, with scheduling and implementation starting later this week.

Friday, March 16, 2012

A Word On Version Numbers

Right now at Flex we're gearing up for the release of 4.4.27, which is a critical maintenance release addressing bugs and some of Flex's more annoying quirks like package or kit substitution.

Most current users of Flex are either running 4.4.21 or 4.4.23.  You may have noticed we're skipping ahead to 4.4.27, so what happened to 4.4.24, 4.4.25, and 4.4.26?

First, we've made some modifications to our release automation tools and some of those release numbers were scratch releases done to test those tools.  In other cases, specifically 4.4.24, that release was not cleared by QA for deployment.  In the wake of 4.4.23, we'd made our release process a bit more formal.  Every release has to go through regression testing before deployment and that regression testing has to be exactly what will be deployed, not the latest from the source trunk - this means a tagged version of Flex, not a snapshot.  We used to build a release after QA gave the thumbs up.  Now we do it before.  This means that QA may reject a tagged version of Flex and that version never gets deployed.

The software developers among you may be asking yourself at this point "Why don't you just use release candidates?"  The answer is we'd love to, but we need some better tools first.

Because Flex has so many modules and our release process involves a dozen or so separate source packages, we don't have an easy way of retagging a release candidate as a release -- yet.  So, when we produce a release candidate for QA, it gets a real version number and if QA doesn't give the thumbs up, we burn that version number.  Ideally, we'd submit version 4.4.27 to QA as 4.4.27.RC1 (RC stands for release candidate).  If QA blesses the release, we'd then press a button and retag and rebuild RC1 as 4.4.27.

Right now we'd have to do this manually for a large number of source modules.  It would be time consuming and introduce the risk of human error.  We built a recursive release plugin for Maven some time ago and that's what we currently use to perform releases.  When we get around to modifying this tool to retag release candidates as GA releases, we'll stop burning version numbers.  In the meantime, if you notice that the version numbers skip a few slots, it's a sign that our QA team vetoed a release candidate.

Wednesday, March 14, 2012

Composite Availability

There's no kind of issue that gets our heart rate up more than availability.  And like most availability issues we encounter these days, this one was a bit of an edge case, but required a critical fix nonetheless.

Composite Availability

Prior to Flex 4.4, back when kits didn't have their contents included on the quote, the availability engine had to take into account kit and package components and come up with hard availability numbers.  Now that contents are on the quote -- and can be changed at will -- this approach no longer makes sense.

A virtual item is always available, because it does not exist.  If a virtual item is a package, it's only available if its component parts are available and since in the current version of Flex component parts can be manually altered, it no longer makes sense to calculate a hard availability number for the virtual item -- because if the standard contents are changed, that number no longer has a clear meaning.  What makes more sense is to merely warn if the kit is short or not.  So instead of seeing a quantity available for a kit, you'll now just see a red or green availability indicator without an associated number.  And this indicator will be based on the modified version of the kit contents, not the standard contents.

Inquiry Availability

One other quirk we noticed had to do with non-conflict creating statuses in situations where the same item appears on a quote or pull sheet more than once.  This was problematic because we treat quotes with non-conflict creating statuses a little bit differently.   The normal availability calculation only returns availability based on real conflicts with conflict creating statuses, like Confirmed or Tentative on most systems.   To calculate availability for non-conflict creating statuses like Inquiry, we take the normal calculation output and tweak it to show what the availability would be if the given quote or pull sheet were confirmed.  We do this by taking the availability number and subtracting the quantity for the line item.

The problem was that we were performing this adjustment on a per line item basis.  What we should have been doing was computing the sum of all lines for the same item and subtracting that number instead.  We added a simple method to our base project element to perform the sum for us.

public float getTotalQuantity(ManagedResource rc, ResourceType type) {
        float result = 0;
        if (getLineItems() != null) {
            for (ProjectElementLineItem lineItem : getLineItems()) {
                if ( (lineItem.getResource() != null) && (lineItem.getResourceType() != null) ) {
                    if ( rc.equals(lineItem.getResource()) && type.equals(lineItem.getResourceType())) {
                        result += lineItem.getQuantity();
        return result;

 We then modified the availability adjustment to use this new function instead of the line item quantity.


                    if ( result.getQuantityAvailable() != null ) {
                        result.setQuantityAvailable(result.getQuantityAvailable() - lineItem.getQuantity());
                        if (result.getQuantityAvailable() < 0) {


                   if ( result.getQuantityAvailable() != null ) {
                        result.setQuantityAvailable(result.getQuantityAvailable() - lineItem.getProjectElement().getTotalQuantity(lineItem.getResource(), lineItem.getResourceType()));
                        if (result.getQuantityAvailable() < 0) {

Coming Soon

This fix and a hefty pile of other fixes and enhancements will be in Version 4.4.27 of Flex, which goes into QA this week and should be deployed shortly afterward.