Monday, September 17, 2012

The Wonderful World of Auto-Scans

All in all, the release of 4.5 last week went pretty smooth.  As much QA as we do -- which is not much for software in general, but quite a bit for the rental software industry -- we always worry that our testing will miss a serious show stopping issue and we'll have to slam in an emergency fix for something.

There were some issues, but nothing quite that serious.  Mostly dinky edge case null pointers that we were able to fix quickly.  The most serious problem that arose after the release of 4.5 pertained to what we call autoscans, or the automatic scanning of a container's contents when the container is scanned.

Inside Contents

At a basic level, autoscans are pretty simple.  For example, when you scan an amp rack, it stands to reason that the rack's component amps and any accessories or power cables usually stored inside the rack also get scanned.  Flex has supported that model of autoscans for a long time.

Where things fell short were situations where the contents of a container change during the prep process.  The most obvious example is free pick containers, though anything can be tweaked or changed during the prep process.

We added the ability to take this into account when autoscanning.  This would mean that if you had a free pick container out on a show, that when the show came back, scanning the container would effectively scan all of its contents back in.

The only problem here is that contents configured for an inventory item and contents specified as child line items are not really the same thing.  We wrote code to analyze the data and try to guess whether the user wants the configured contents or child line items to be scanned, or both.

Shortly after the release of Flex 4.5 we discovered that this code often guesses wrong and effectively scanned the same item twice - once for the contents and another time for the child line items.  When the parent item is a serialized item, you end up with a separate scan operation for each serialized unit, which could exacerbate the problem.

No More Guesswork

We looked at this issue of autoscan processing and decided that it just wasn't possible to make educated guesses about configured contents versus child line items that could fit every situation.

So, we chucked the old yes/no autoscan flag some of you may have seen in the equipment list element configuration screens and replaced it with a set of three Autoscan Modes: All Contents, Permanent Contents, and Child Line Items.

This means that you can configure how you want the autoscan process to work for each warehouse mode.  By default any situation where autoscans were enabled will be set to All Contents, which mirrors the system's behavior prior to 4.5.  It is recommended that anyone who wants line item autoscans change the autoscan mode for manifest returns to Child Line Items.  If you use a two stage check out process (with a prep and ship scan), you might also considering setting the autoscan mode for ship scans to Child Line Items as well.

One Last Guess

The only place in the system where some measure of autoscan guess work is still in play relates to when gear is flowed from one show to another.  When you flow gear, the system will default to Child Line Items mode if you have any autoscan mode configured.  If you have an autoscan mode of None, there will be no autoscans, even if you are flowing gear from show to show.

This fix, along with a number of fixes to clear some of the annoying error messages some of you may have been seeing, is in QA now and will deploy as part of Flex 4.5.3.  You won't have to wait months for this one.  This version will regression test today and should be deployed tomorrow or Wednesday night depending on how regression testing goes.

No comments:

Post a Comment