Looking at the Breww mobile app, and seeing items that have been assigned to an order, and their hard-coded container indentities… would it be possible to have an option, at the point of picking, using the mobile app, to circumvent the chosen container with a different container of the same batch/product?
for instance:
If an order was “assigned” two kegs of IPA with contaier “codes” … keg1, and keg2, both being from the same batch 1234… could the person picking that order have the option to “replace” the containers with two different containers of the same product/batch
for instance:
When scanning items to order number #555 i see that the two kegs assigned to that order are same batch/product but differing containers… you have the option to replace or overwrite without having to have those kegs “removed” and readded with the chosen container ID?
Does that make sense to anyone please?
Second that. - sounds like a good idea. Our customers all have different bbe requirements and such, which makes the auto-assign stock almost impossible. And pre-determining container IDs to an order is nice if you only have 10 kegs in stock, but when you have 100’s of a particular batch finding those exact kegs is impossible. So to be able to essentially ‘kick’-off’ those assigned kegs at the touch of a button and then scan the keg IDs you do use for the order would be incredibly beneficial.
Thanks for the suggestion.
I might be missing something (sorry if I am), but if auto-assign can’t pick the right containers for you (i.e. “Our customers all have different bbe requirements and such, which makes the auto-assign stock almost impossible”), then you could just switch it off and manually assign with the app’s barcode scanner.
Is there a reason to have auto-assign on initially and assign some containers before you make manual adjustments after? Do you want some items auto-assigned and some manually assigned?
Cheers
i think the issue here - correct me if i am wrong - the sales team would love to assign a specific batch to an order but not necessarily a specific container - so the workaround would be to let us, at picking, overwrite the container data while retaining the batch request?
Ah, ok. In that case, can I close this request in favour of Ability to pre-assign batch number to a planned batch (before starting the batch)?
no, this is still open…
th e one you are talking about is in relation to packaging… i am comong from the deliveries aspect. Sorry i now see how that is misconstrued - this is in realtion to:
Sales placing an order
Delivery driver (at picking or dispatch stage) can overwwrite the trackable container requested as long as the batch matches the requested one
I’m sorry, Jason, that was my fault. I think I understand you correctly but somehow managed to link you to the wrong feature request entirely 
The one I meant to link you to is: Allocate a beer batch (not a specific keg/cask) to an order at the point of ordering (in advance of assigning stock to the delivery)
Can I close this one in favour of that one? Or have I still misunderstood? Cheers
that feature COULD in theory do the same job yes… BUT, in the cases where it would still be appropriate to overwrite a container through picking, i think it would make sense to have this as an option for the pickers and delivery bods please - otherwise the process is super complex - if it’s not too much hassle?
It’s possible I’m still misunderstanding something, but honestly, I think the proposal in the thread is a bad idea and, if brought up in a different context, would be described as a bug.
Let’s take a simple example of a delivery for one keg:
- Someone assigns (either manually or via auto-assign) a specific keg.
- Someone else scans another different keg to the same delivery.
I think the right thing, in this case, is to reject the second scan, as it’s most likely to be a mistake. If not, you can confirm it’s not by unassigning the original keg and re-scanning it.
If Breww just swapped out the keg as if the original wasn’t ever assigned, I think this would cause no end of confusion and mistakes.
And in a more complex example, say there are 3 kegs on the order:
- Someone assigns (either manually or via auto-assign) three specific kegs.
- Someone else scans another different keg to the same delivery.
Again, I think it’s most likely a mistake, but if you wanted it to swap out a keg, which of the original three should be kicked out? What if you scanned a further 4 kegs; which three would be left on the delivery? What would inform the person scanning that they’ve picked more than they should have by mistake?
To me, this doesn’t make much sense, sorry. If you don’t know which keg should be sent on the delivery, don’t assign a random keg. Just wait for the right one to be assigned. If you need a way for the sales department to tell the delivery team to send a specific batch, use what will be built for that other feature request.
Or am I misunderstanding something still? 
Hi Luke,
The process here means that if a specific container is assigned to an order we need to pick that one right? Now a team member in the office might raise the sales order and know that customer requires a specific batch and not necessarily operate the typical FIFO model in warehouse. Let’s presume the order is confirmed, and now the order picker has the pick/delivery note and begins. They get to line one on the order and see that keg ‘x’ (with bbe and batch) is actually three pallets deep and buried. Now without access to a computer (and only a phone) how would they pick another keg? - How would they knock that assigned keg ID of the order and pick one that is actually accessible? I think this is what Jason is getting at. You can have an order logged with all the keg IDs to signify the batch to pick, but then the order picker could, for example, click a button to say ‘pick other kegs’ which would then let you scan the kegs you wanted to pick. (as in, actually accessible to you). Otherwise, assigning batches to an order would literally be a needle in a haystack exercise in trying to find that exact keg…
Firstly, I just want to say that I’m trying to make sure we build the right solution, so I’m sorry if I’m coming over annoyingly; that’s not my intention
I understand what you’re saying, but my question is; Why was keg X assigned in the first place? The feature request looks to me to be asking for a solution to a problem that shouldn’t exist as the real mistake was assigning the wrong keg in the first place. Let’s fix the root cause, not stick a plaster on after the fact.
As I understand it, an analogy of where this feature request could be:
- I have a petrol car.
- I have put diesel in my car.
- Can my car please be modified to work with diesel?
- Instead, why not build a way to prevent diesel from going into a petrol car in the first place (like having two differently shaped pump heads).
Why was keg X assigned in the first place? Was this assigned because Allocate a beer batch (not a specific keg/cask) to an order at the point of ordering (in advance of assigning stock to the delivery) doesn’t exist yet?
Cheers
i think you’re sort of right in that if that feature is implemented to be able to “allocate batches rather than containers” we’re pretty much there… being able to override the allocated containers would be another approach to the same problem which would put the less important bit (the actual container that ends up on the order) back into the hands of the people who are physically WITH those containers - i.e. those using the app and handling the stock. Feel free then to ignore this is you think the “allocate batch without allocating container” is a quicker/simpler solution to this.
Thanks, Jason.
We’ll do the other suggestion as I think that’s an excellent feature Cheers