In this post we’re going to talk about locations… not just storage locations, but usage locations and quite literally all the places in between. This post is all about:

• Cribs & Bins
  
• Locations and Sub-locations
  
• and the great mystery of just what Current and Transit fields are used for in IndySoft
  

Storage vs. Usage

The first thing to understand about asset location information in IndySoft is the concept of storage vs. usage locations. Storage locations are basically considered out-of-use locations for assets until they are needed in production. This is the primary purpose of the Crib and Bin fields. Now keep in mind the Crib and Bin fields are basically just parent/child fields and can be relabeled to any structure such as Room and Shelf or Storage Unit and Box Number, etc. This leaves us with usage locations. Usage locations are considered areas where the assets are actually used in production. Just like Crib and Bin these are parent/child fields and can be relabeled as desired. Some examples might be Assembly Zone and Workbench or Production Line and Work Area. When you are working with asset level information you are generally working with storage locations. When you are executing events against assets you are most often working with usage locations.

Current vs. Transit Designators

Now that we have storage and usage locations under control, let’s look at an extension of the usage locations called the Current and Transit fields. This is a concept that doesn’t apply to everyone and often it’s just not understood without a solid example. Consider any given asset… let’s say Widget123. We keep Widget123 in a storage location of Room A and Shelf 9. Once we take that asset out for use, we are taking it to a Location. So using our previous example we are taking it to Assembly Zone 4 and Workbench 3. Let’s imagine that this is a high-dollar asset that is going across a campus to a different department so we really need to keep track of where it was last seen and where it is going.

When issuing an asset (or performing any event) you can map any of the primary fields in the event information panel to Current and Transit fields. As an example when checking out Widget123 from Room A, Shelf 9 for use at Assembly Zone 4, Workbench 3 we can push the Crib/Bin fields to Current_Location and Current_Sublocation while mapping the event Location/Sublocation to Transit_Location and Transit_Sublocation. So this provides us with start and endpoints for a location move.

You can actually get alot fancier with these fields. An event for “Transfer to Lab” could store the Current_Location/SubLocation as the issuing lab and the Transit_Location/SubLocation as the receiving lab. On the other side of the event chain we would simply create a receive event to then utilizing the Info Transfer step to push the Transit_location/Sublocation to the Crib/Bin fields.. thus closing the complete transfer and chain of custody of the asset.

Keep in mind that you can map any of the Event Information fields so you can have Current_Department and Transit_Departments, Employees, Machines, etc. These “endpoints” allow you to get very specific about the who/what and when of equipment assignment and location reconciliation. With enough pre-planning you can even designate locations like transfer vehicles as your Current_Location and the Driver as the Current_Employee so you would know which truck the asset was placed in and who was driving it on the way to the Transit endpoint.

Used in conjunction with properly constructed events and targeted searches, location fields in IndySoft offer a solid foundation for loss prevention, chain of custody visualization, and effortless communication related to pinpointing an asset in your environment. More information about locations can be found in IndySoft Help within the “Important Concepts”, “Add/Edit”, and “Configuration” topics.