There are several ways to accomplish this in Limble, depending on your workflow and what you’re trying to achieve. This article walks through the available options and explains when each approach may be most useful.
Assets: best for serialized items that are worth tracking individually.
Parts: best for non-serialized items that can be repaired, refurbished, or recycled.
Asset Field: best for serialized items that belong to only one or a few assets and don’t need their own asset record.
Treating As Assets
The first option is to treat them as Assets in the system. This is commonly done for replaceable items that are serialized or can be otherwise tracked at an individual level. Even if the item may be disposed of at some point, if each one has a lifetime long enough to be worth tracking, then this is going to be the best option.
We have some customers who will set up the item as a child asset to the machine (parent asset) where the item is installed. This way, they can replace it with another version of that Asset as they send the original out for repairs. Then they can have an "Out for Repairs" parent Asset set up where they can temporarily move the asset there. Once the item comes back, they'll then move it to a "Ready for Use" parent Asset where it will 'live' until it needs to be used to replace another version of this item elsewhere.
As a part of this sort of setup, you can have the “Out for Repairs” and “Ready for Use” as a completely separate Parent Assets or they can “live” as child Assets to the Asset or Assets using these items. This would largely depend on how widespread such an item would be used on other Assets and/or how many other Assets have similar items associated with them. If it is a common item that can be used on any number of other parent Assets, then it would probably be best to have them ‘live’ at a higher level in the Asset Hierarchy than something that would be highly specific to one or two Parent Assets.
When it comes to building reports on these Assets, you can utilize a custom dropdown Asset Field for the Asset and provide an option indicating that these assets fall into a category of "Asset-Part". This will allow you to use this Asset Field when applying filters in the Custom Dashboard.
One of the great things about tracking items like this as Assets, is that you can use a separate Task to apply PO costs for repairs etc. against the individual items. This means you can then build a complete history of that one part/asset for future use.
There are multiple variations you can do such as not creating separate Tasks/POs against the Asset and instead apply that to the Parent machine etc. Another variation would be to set up a single Asset representing all of your "stock" of that one Part where you can then just apply the cost of repairs and new parts as POs assigned to Tasks associated with that ‘group’ Asset. The tracking of costs and inventory would be less precise but these are just additional examples of how it can be done.
The caveat of this option is that it does require additional work to get these Assets set up to begin with. Once it is all set up, it will just be a matter of moving the Assets back and forth in the Asset Hierarchy.
Treating as Parts
Rather than a variation on the above, the other 'common' method is to treat items that fall into this grey area as Parts even if they can be refurbished. This is more commonly done for items that can be repaired, refurbished or recycled but are non-serialized so there is no way to track them at an individual level.
The best way to handle this would be to set up 2 versions of this Part for proper cost tracking. For example, you’d create “Repairable Part - NEW” and “Repairable Part - REPAIRED”. By doing things this way, you can set up separate vendors and pricing for the two versions of that Part.
In this case when the part becomes damaged or worn out, you would apply a repaired version of the Part to a Task so the damaged part can then be set aside for repairs later. You would then set up a Minimum Part Qty Threshold so that when your repaired parts fall below a certain threshold, you can send them off to be repaired.
If however, the part becomes damaged beyond repair, you would then apply the “new” version of the Part to the Task for replacement. You can also then have a separate Minimum Part Qty Threshold in place for this. This way, if your “new” version of the part ever falls below a certain value, you’ll have a Task trigger to purchase new ones from its Vendor(s).
By following this New/Repaired Part setup, you would have a system in place to always use repaired parts until one breaks. This way you are only buying new Parts after you drop below that overall threshold. It would also be the simplest for users to understand and implement since you wouldn’t need to worry about building and maintaining additional Assets in the system.
You would need to ensure that employees are only using new parts when an old part is damaged beyond repair. Otherwise it will result in ordering additional stock when it isn’t necessary.
Please Note: If you use this method but also have “Require Unique Part Numbers” turned on, you’ll want to make sure that you either slightly alter the Part number to reflect the “repaired” version or use a vendor code associated with repairs that they perform.
Treating as Asset Field
This option would be for narrow instances where the item is serialized or trackable at an individual level, is unique to only one or very few Assets, and you do not want to track the Item as a separate Asset at all.
This would involve creating separate Asset Fields on the Parent Asset(s) where each Field is representing these separate repairable items. Each of these Asset Fields would be set up as Custom Dropdown selections so you can indicate that particular item’s status by updating the dropdown menu.
The history of this field on an Asset can be tracked by clicking on the clock-shaped icon on the right-side of the field. Also note that if the same repairable item is usable on multiple Assets, you’d want additional dropdown options to specify which Asset the item is currently being used on.
The drawback of this option is that as an Asset Field, there wouldn’t be any built-in processes for reminding you or users to keep these fields up to date. This would especially be important if the same repairable item is usable across multiple Assets and the respective field would need to be updated on each of those Assets any time the item’s status changes.
With the information above, we hope we’ve helped to create a starting point to track repairable items in the best way possible for you and your company! For additional support in setting this up, please don’t hesitate to reach out to a Customer Success Manager.
Related Articles