To track warranty or other info for a return, clients can create custom fields tailored for their individual needs. However, these apply to the entire return rather than individual products. This is a problem for returns with multiple products.
We are pursuing the feature to allow tracking properties such as warranty at the product level. Client requests are actually rare for this feature, which is a major reason it has gone unresolved for so long, but we do see it as a basic requirement and not at all unreasonable.
One issue we face is the current structure tracks Line Items rather than individual products.
Each line item has properties such as:
- Product ID
- Action: Repair, Replace or Return As Is
- QTY
- On Hold Yes/No
- Shipped Yes/No
However, each individual product in the line item can't be edited. This means that for a line item with QTY 3, all 3 products have the same value for Action, Shipped, etc. However, you could separate the products into 3 line items to track differences such as repair or replace.
If we wanted to track things like warranty at the line item level it may not work so well as you would be required to sort the products returned into line items that correspond to their warranty status. It also wouldn't apply beyond the return. If a product is returned again the warranty info wouldn't be carried with it as the line item holds the property. The system wouldn't know the product returned is the same one as before.
This leads us to 2 choices:
1. A big redesign where products are all stored as individual objects.
This has the advantage that the properties follow the products across multiple returns. Product would be stored under the customer object independent of any particular returns. This would be a massive effort, however, and resources are limited. Also the interface would need to facilitate easy editing of perhaps thousands of products on a return. Consider scanning in SNs in this scenario. Instead of scanning them all as a batch in one field which the current design allows, the user would be required to lookup each product, open it and then scan the SN.
2. Tracking warranty at the serial number level.
The Serial Number Tracking feature represents each product as a combination of Serial Number and Product Name. Each serial number is stored in its own record with properties such as location, passed/fail status, applicable returns, testing history etc.
Serial numbers also provide a unique identifier for each product. If a return contains two products with one in warranty and one not, there needs to be a way to tell them apart. So it would make sense both theoretically and practically to track warranty information at the serial number level, and it doesn't involve the resources of option 1.
One issue with this strategy is that it isn't a solution for clients who do not wish to track serial numbers.
The next problem is that serial numbers are rarely entered until the product is actually received and scanned. So we would require the ability to mark an SN as in or out of warranty before it has been received and therefore before we know the actual TEXT of the serial number. *Always having the SN when a return is created would solve this but is probably unrealistic.
So we're thinking now of an interface that would allow entering "temp" serial numbers and setting properties like warranty before the actual serial numbers are scanned in.
The interface would be different than it is now however. Since the warranty would be set for each SN, it wouldn't be possible to scan in serial numbers as a batch. Each SN would need to be opened before scanning as each has properties BEFORE being scanned. This could be cumbersome on returns with many products. The current design does have an advantage in that it's easy to scan in many serial numbers for a line item.
In conclusion, for returns with multiple products we want to provide a way to track warranty for each product. Tracking warranty at the serial number level seems logical as SNs provide a unique way to tell each unit apart from others.
The alternative would be a very large system change where each product would exist as its own record with properties and even custom fields independent of returns.
We always strive to put resources into projects that serve the greater good. We know this particular issue is frustrating for clients who no doubt see the feature as a basic requirement and we don't disagree. We continue to plan for this feature but there is no ETA as of yet.
Comments