Barcode for picking/assigning stock to represent the product & batch number (then have Breww auto-assign)

[tom-goodingham]

Hello,

I’m struggling to find a way to use the barcodes and merge that with how we pick stock/package.

We pre-print labels for our smallpack and keg racking. We also print a single sheet and photocopy it so we keep a master label sheet as a physical record.
At the end of packaging we throw away the excess labels. This for us, is naturally the easiest way to operate.
If we were to introduce barcodes to the labels, we’d have to make sure the labels are used chronologically, which creates a big area of mistake (especially is multiple people are labelling). And also change the way we print.

Adding a task of scanning barcodes during packaging is also an additional practice that is prone to mistake.

I wanted to know, is there an additional option to have the barcode on the label show product code and batch number?
So that every SKU+batch is represented by a barcode. Allowing the pick in a way that’s relevant for them and, not complicating the packaging process.
Ideally allowing us to use the barcode pick function you have implemented.

Hope this makes sense.
Thanks,
Tom

[luke]

Thanks for the question, Tom.

Firstly, to answer this specific question:

@tom-goodingham

I wanted to know, is there an additional option to have the barcode on the label show product code and batch number?
So that every SKU+batch is represented by a barcode. Allowing the pick in a way that’s relevant for them and, not complicating the packaging process.

No, this isn’t possible at the moment. It may be possible to add this as a new feature, but it would only be usable for smallpack and non-returnable containers (it could in effect, be a guide for the auto-assignment, to assign a container but limited to the batch/SKU suggested by the barcode). Tracked casks/kegs always need to know the specific containers. This may also lead to issues, such as your barcode scan telling Breww to assign product X, batch Y and there not being any more of that batch left.

This would need to be a feature request if this is something that you’d like.

@tom-goodingham

We pre-print labels for our smallpack and keg racking. We also print a single sheet and photocopy it so we keep a master label sheet as a physical record.
At the end of packaging we throw away the excess labels. This for us, is naturally the easiest way to operate.

Breww will print the same barcode for all smallpack in a specific racking, so they may work for you there, but this will cause problems with casks/kegs where the barcodes are always different. Even with smallpack, Breww will know how many smallpack products were packaged and so you could lead yourself into problems down the line by photocopying and reusing labels if you try to use more than Breww expected.

@tom-goodingham

If we were to introduce barcodes to the labels, we’d have to make sure the labels are used chronologically, which creates a big area of mistake (especially is multiple people are labelling). And also change the way we print.

Why do they need to be used chronologically? You should be able to just make sure the labels used have been scanned during racking, and Breww will work out the rest for you. Have you seen our guide on pre-printed labels with reserved barcodes and then using these during packaging? I suspect this workflow would cover what you’re looking for as it’s meant for just this - printing barcode labels in advance of racking, with at least enough labels, and then confirming which were actually used when actually racking.

Please do let us know if you have any further questions on this. Cheers.

[tom-goodingham]

Hey Luke,

Thanks for getting back.

No, this isn’t possible at the moment. It may be possible to add this as a new feature, but it would only be usable for smallpack and non-returnable containers (it could in effect, be a guide for the auto-assignment, to assign a container but limited to the batch/SKU suggested by the barcode). Tracked casks/kegs always need to know the specific containers.
This would need to be a feature request if this is something that you’d like.

We only use non-returnable containers. The auto-assign feature is useful, but doesn’t tally up with what gets done on the ground 100% of the time. Hence the need for barcode scanning. And order fulfillment will never follow a single rational, so barcodes at our size is starting to become very necessary.

I don’t quite understand this part:

This may also lead to issues, such as your barcode scan telling Breww to assign product X, batch Y and there not being any more of that batch left.

This sounds like a stock issue rather then an issue with a barcode or label.

Breww will print the same barcode for all smallpack in a specific racking, so they may work for you there, but this will cause problems with casks/kegs where the barcodes are always different. Even with smallpack, Breww will know how many smallpack products were packaged and so you could lead yourself into problems down the line by photocopying and reusing labels if you try to use more than Breww expected.

When we print our labels, we use however many we need from our photocopied amount, then update the planned packaging amount in the batch of how many where actually packed.
Each keg has a NR and the SP number is for all small pack for the batch. So our labels sort of exist separate to the method of keeping track of containers in Breww.
For us there isn’t any imperative to keep track on individual packaged items, traceability here doesn’t serve us (from what I can see).

So the barcode system currently set up requires us to change the way we work in a way that on the floor becomes more convoluted and easier to make mistakes without any benefit other then gaining access to a Breww function.

Why do they need to be used chronologically? You should be able to just make sure the labels used have been scanned during racking, and Breww will work out the rest for you. Have you seen our guide on pre-printed labels with reserved barcodes and then using these during packaging? I suspect this workflow would cover what you’re looking for as it’s meant for just this - printing barcode labels in advance of racking, with at least enough labels, and then confirming which were actually used when actually racking.

My mistake with the chronological comment, I see that the NR number doesn’t have to be chronological when assigned to products. However, it would be a pain to manually remove the in-between numbers since we don’t use a scanner whilst packaging. (and wouldn’t want to if we can help it)

I can see why it looks like a complete system. But for us, it is requiring change across several departments and invites mistakes.

Happy to arrange a call so we aren’t getting crossed wires. -Hazel-

Thanks, Tom

[luke]

Thanks, Tom. Our recommended approach would be:

• Pre-print labels with reserved NR numbers from the planned packaging
• Scan these labels when actually packaging
• Use the picking system to pick stock, and scan the specific NR numbers when picking

From what you’ve said, I think you want to use scanning when picking (to ensure the right stock is assigned, rather than Breww’s auto-assigned stock). However, you don’t want to scan labels when packaging (and want to use pre-printed labels with barcodes).

If I’ve misunderstood, please let me know, but assuming that’s correct, that’s not really going to work (with how Breww works currently, at least). If you want Breww to understand the barcodes when picking, you’ll need to also scan them when packaging. Step 1 (scanning at packaging) needs to happen for Breww to know which labels have been used and understand them at step 2 (picking for deliveries). It’s a case of either scanning at both steps, or at neither step, to be honest, but just wanting to scan at step 2 leaves a gap in the data.

As you mentioned, a feature request for generating barcodes on labels that reference just the batch and product, then letting Breww auto-assign an NR that fits these criteria does sound like a good suggestion and would mean that you could just scan at step 2 and have pretty good traceability When picking, this could also use the location that you’re currently at, but if used from other methods, Breww wouldn’t know the location so would have to choose one (at random) if the same batch/product was in multiple locations and this may lead to discrepancies, but as long as these were always used during the mobile app picking process, this wouldn’t be a problem.

If this sounds like a good plan to you, I can convert this thread into a feature request?

[tom-goodingham]

Hey Luke,

Thanks for replying!

No misunderstandings here, and it would be helpful to have this as the feature you mention.

Please convert the tread!
Thanks again,
Tom

Side note: We do have trade and Web customers fulfilled from two different locations, but web shop deals with single cans which don’t have a NR and also exist with a different product code. So the proposed barcodes wouldn’t effect these (right?).

[luke]

Thanks, Tom, this has been converted now.

Can you please give this a vote (and get others in your team to do so if this is important to them too)?

@tom-goodingham

Side note: We do have trade and Web customers fulfilled from two different locations, but web shop deals with single cans which don’t have a NR and also exist with a different product code. So the proposed barcodes wouldn’t effect these (right?).

Yes, if these are separate Products in Breww then they would get separate barcodes, so there would never be confusion between the two

[justin-hutton]

Hi Luke - I know you ae working on this at the moment, just wanted to know a realistic timeline so i dont do a load of work then have to do it again!

[luke]

Apologies for the slow response, Justin.

This project hasn’t been started yet, but it is very high on the list and will certainly be started soon. I don’t want to promise 100% before we get stuck into it (in case there are any unexpected complications that come to light), but I expect this will be in late January or February

[justin-hutton]

Heya Luke - has this project gone into progress yet? Just holding off doing some bits waiting for this to roll out!

[luke]

I’m sorry, Justin, the start of the year has been much busier than we expected (which is great in many ways), but sadly it meant that this slipped. It’s still very high on the list, but it’s looking more like April now.

[max]

Great news everyone: this is now live!

New option for non-returnable stock label barcodes to represent the product...

To enable this new stock barcode type, simply head to Settings → Label & printing settings → Scroll down to Non-returnable & smallpack stock labels → Set the Barcode option to Use the product and batch combination barcode on stock labels.

If you have non-returnable stock that is already labelled with the previous barcode type, we’d recommend enabling the new Treat unique non-returnable barcodes as a product and batch combination barcode if the non-returnable stock isn’t available setting in the same place to effectively turn these barcodes into product and batch combination barcodes.

Please be aware you will need to be using the latest version of the Breww mobile app to scan the new stock barcode type onto deliveries.

It’s also worth being aware that changing this setting will mean the method of printing pre-packaging labels also changes slightly (although it will be more straightforward!). To read more, please see the guide on printing pre-packaging labels.

We hope that helps, but as always, if you have any feedback, please let us know!