Increasing inventory turnover by setting up a holistic returns reuse workflow. [ItemLocation] Unassigned
Hi everyone ! It's me again.
The business case
At my workplace, we have a bit of a different system when it comes to ecommerce : we sell made-to-order products. Basically, you pick a tshirt fit, size, color and pocket design, and we assemble it for you. Having a product with many variants means we have 65k variants in Shopify. Managing raw materials (t-shirts, pockets) isn't too hard, but any number of preassembled products in the warehouse quickly becomes unmanageable.
For this reason, until recently, returns would end up in a big box, just waiting for the next studio sale so we could sell them in-person. Here's the big idea : What if we could easily pick a preassembled product (whenever possible) over assembling a new one from scratch. The solution seemed to involve leveraging Shipstation's inventory tracking feature, the Warehouse or Location product variables, and perhaps some clever HTML inside a custom Packing Slip template. The idea is that the packing slip will indicate whenever an item can be picked in the preassembled tshirts.
Counting tshirts and wrangling data
We started by sorting and countnig about 1600 t-shirts. I then tried my luck at importing all of it using the InventoryImport template, but it would error out. As it turns out, many of these preassembled products weren't even known to Shipstation. Shipstation just had no idea what these SKU's were. This happened because some products were so old that we stopped selling them before we even began using Shipstation. There were also returns from B2B exclusive products that never went through Shipstation. Keep in mind that unless you import your entire catalog to Shipstation manually, individual product records are only created when a sale is made.
Using a full catalog export from shipstation (24k product records) and our preassembled tshirts database, I used excel's COUNTIF function to compare every preassembled SKU against our Shipstation catalog. I then created product records for stuff that wasn't in there already, using the ProductImport template.
Then I imported preassembled tshirts inventory to Shipstation using the InventoryImport template. Not a single error !
Putting it all together
Now the next step would be to integrate the Location product variable to the packing slip. However, after testing, we noticed that the NULL or default value for this field is "Unallocated". This is problematic because it puts irrelevant information on our packing slip. As you know, the brain quickly learns to gloss over irrelevant information and I'm afraid that soon, our pickers would stop paying attention to this field.
This is where I ask for your help. I need some HTML wizardry or perhaps some sort of software tweak so I can change the default location text (personally I'd set it to " " so it's not detectable on the packing slip unless assigned.
-
Official comment
Hi Pierre,
Thanks for your post! It is always good to see you around the forums.
Just to set expectations since this is outside the scope of our support, this solution is something that we can't guarantee so you would need to test it first.
My Html/CSS experts say that you might be able to use psuedo-sectors to use CSS to hide empty elements. if that element has a class we can use as the selector, the pseudo-selector should work. It would be like:
.location:empty {display: none;}If you would like to read up on pseudo-sectors, you can check out the following resources. *Note that these are not affiliated with ShipStation, but I still think you would find them useful.*
https://css-tricks.com/almanac/selectors/e/empty/
https://dev.to/samanthaming/css-empty-selector-b6f
Let us know if this helped you out or if you still need additional advice.
-Erin: Your Friendly ShipStation Community Moderator.
Comment actions -
Thanks Erin I'm working on implementing this solution right now.
However I'm not able to hide the 'Unallocated' null placeholder using this code snippet.
I did some digging around and found this on the API documentation : under the "Example response" JSON code, there's these two snippets that caught my attention :
"warehouseLocation": "Aisle 1, Bin 7","warehouseLocation": null,Correct me if I'm mistaken, but I believe this means that the [Product Location] variable is mapped to 'warehouseLocation' instead of just 'location'
However, even by using the following code in my header, it's not really doing anything for my [Product Location] field
<style>
.quantity {
font-size:2.5em;
font-weight: bold;
}
.quantity1 {
font-size:1.2em;
font-weight: normal !important;
}
.warehouseLocation:empty {
display: none;
}
</style> -
I just got a bit of a sad answer from support :
I spoke to quite a few people here and had a few of our HTML experts take a look and they all came to the conclusion that you won't be able to hide that column/field from appearing based on a value using our editor.
I asked multiple people to try and get a different answer but they all came up with the same thing.Oh well.
-
Hello Pierre,
Thanks for following up to let us know about this. Support is correct about this since Warehouse Location value is not technically empty- the value would be 'null' or unassigned"- Psuedo-Sectors will not work.
To clarify, are you using the [Product Location] or the [Warehouse Location] field replacement? If you are using [Product Location] there is not really much that can be done in terms of an alternate workflow since this field replacement does not have any automation criteria attached to it. However, if you are using [Warehouse Location] you can create an automation rule where the criteria is Warehouse Location equals "null" and the action assigns a packing slip template- you would need to create- without that field replacement. I know this won't cover all scenarios but hopefully, it helps.
-Erin: Your Friendly ShipStation Community Moderator.
-
Hi Erin
I'm finding this whole Unassigned thing is cumbersone at best.
I'm using the [Product Location] field replacement. The only reason I mentionned warehouseLocation is because that's the name of the variable equivalent to [Product Location] in the JSON returned from API queries.
I'll look into using a separate virtual [Warehouse Location] instead of a specific [Product Location] for workflow automation. My default workflow would to automatically assign a packing slip with [Warehouse Location] to all orders. And another workflow to switch this packing slip to one without [Warehouse Location] if [Warehouse Location] = null/empty/unassigned.
Thanks for your help as always
Please sign in to leave a comment.
Comments
5 comments