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.

Before:

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

After:

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

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.

No comments:

Post a Comment