We are considering setting up the products and stock levels (steps 1 and 2) through your dashboard. Then, we plan to integrate OpenBoxes with our storefront to fetch available products and process purchases. This integration will act as a proxy for our store’s backend, recording the transaction details and writing them to our database.
I wanted to make another point here: what I think you’re building will probably work for a little while, at least as a proof of concept with minimal volume. But eventually, you’re going to encounter limitations as there are many more details and states that you’ll probably want to keep track of during the order and fulfillment process and you’ll likely encounter higher error rates as volume increases.
If you’re building an online storefront, there will be additional use cases related to fulfilling orders (allocate, pick, pack, ship) that you will want to track. Not to mention the exceptional use cases like backorders, canceled orders, and returns. In addition, you’ll probably want to handle sales orders in a more robust way, which will likely require a solution that is scalable and fault-tolerant i.e., message queue.
Let me know if you’d like to discuss that in more detail. We’ve worked on similar projects in the past.
Hey all,
I am just doing a “test” run with a stock movement and there is a red note that shows when you “adjust stock” - I just wondered when this is likely to be updated as this would be a great feature to have as the warehouse could adjust stock without the need to go to the stock card and manually adjust.
If I have missed something though please let me know thanks
The idea for this feature was introduced back in 2018 when we first designed the Outbound Stock Movement workflow. It looks like we even implemented it in the initial version of the Stock Movement workflow.
I agree that this feature would be really useful. However, looking back through the Jira tickets for this one, it seems we encountered some gnarly edge cases we hadn’t considered that might cause substantial headaches for higher-volume warehouses.
In general, the main problem with including a Stock Adjustment feature within the Stock Movement workflow is that it makes it very easy for a user to muck up their data without much effort because you’re singularly focused on the inventory item you’re picking and not considering implications of that adjustment across the entire inventory. For example, if you’re adjusting one inventory item to make it available for pick, are you also taking into account that the stock you’re picking may have recently been moved from another bin location (without a corresponding transaction in the system)? In that case, there are actually two adjustments that need to be made and one would likely be ignored in this case.
Another problem is that there are financial implications to adjustments that are being ignored because the user is solely focused on making inventory available for fulfillment.
Therefore, before we can reintroduce a feature like this within the Stock Movement feature, we need to make sure of a few things:
only certain users are allowed to make adjustments
usability around the Stock Adjustment feature must be holistic not myopic
there are safeguards around creating adjustments to prevent data errors
we provide a detailed audit trail of the adjustment with reason code, user, and timestamp
A better approach to handling Stock Adjustments within a workflow like this would be to record the discrepancy event (e.g. within the Picking step) and have that event trigger the need for a Cycle Count to investigate and potentially adjust multiple inventory items associated with that product.
We’re actually working on a mobile application feature that will allow this type of discrepancy event to be triggered. I also want to consider adding a way to record the same discrepancy within the Picking step of the Stock Movement workflow. Both of these features would allow users to signal to the system that a Cycle Count is needed for a particular product.
For now, you can use the Adjust Stock feature from the Stock Card or manually trigger a Cycle Count for the product. This will ensure you provide the necessary focus to address what might be a larger systemic problem.
Hey there, thanks for the update on this one much appreciated. Will have a look at this and see if it might solve the issue. Got another couple of points to this…which might not be possible at this time but wanted to ask.
The way we want to use the system is that when stock is used by our final location, is there a way or process that can link to deduct it from the end users stock system. Like a form that can be linked to Openboxes to say the stock has been used? The theory behind this is that our vans are installers so each one is a like a mini “depot” and the use stock on a daily/weekly bases, so I am trying to work out is there an automated way that they can do this, that doesn’t require them making manual adjustments each time
I have way more questions than answers at this point.
Are the vans (mini depots) already locations in OB? If so, the stock should already have been moved from the main depot to the van so you just need to create a consumption transaction within the van location. If that’s not correct, can you explain how this currently works? What I’m imagining is that technicians take stock from the depot but it’s still considered in the depot within OB?
How are you thinking this would be automated? What triggers the automation?
What data should the technicians be responsible entering? Is the list of products used on each job pretty consistent? Or does it vary widely? In other words if you could define a template for products consumed on a job would that help with the automation?
Do installers have smartphones/tablets they could use, or are you thinking web form they access periodically?
What data needs to be captured for these transactions?
How do you currently know what they used? Do they report it back somehow or is it purely manual adjustments now?
Are vans restocked from your main depot periodically, and if so, is that part already working in OpenBoxes?