How do I sell the same beer in both my own casks/kegs and rented/non-returnable containers?

If you use both your own kegs and non-returnable containers, then you first need to decide if you’d like to sell these as different products to your customers or as the same product (you can still choose which container to give the customer at the point of delivery if you use a single product).

For the purposes of understanding Breww’s terminology, examples of non-returnable containers may include E-Kegs, KegStar, PolyKeg, KeyKeg & others. In this article, we’ll use KegStar as an example of a non-returnable container to aid with explaining the process. Breww is not affiliated with any of these brands in any way.

  • If you wish to sell as different products - in this case, you’ll need to create two container types, one for your own kegs and one for the non-returnable, e.g. “30L Keg” and “30L KegStar” and then create a second product which points to the beer and the “30L KegStar” container type.
  • If you wish to sell as the same product - this is simpler as you need just the one keg container type and one product for the beer in that container. Breww will still know how many of this product you have in rented kegs and for your own kegs will know the exact keg numbers which are filled with the beer.

Once you’ve got the 1 or 2 products created (as per how you’d like it to work), you simply need to rack into them from the batch.

  • First, go to the batch.
  • Click Actions in the top-right.
  • Choose Rack (package).
  • Select the vessel and relevant product (make sure to choose the product that points to the “30L KegStar”, if you go with the option to sell these as separate products).
  • On the next screen, you’ll have the option to enter or scan containers, but for non-returnable containers, this should be skipped completely.
  • On that same screen, there will be an input box labelled Non-returnable quantity. Here you simply enter how many non-returnables you have filled.
  • Continue to fill in the form and complete the process.

Hi Luke, thanks for the handy guide. I have a quick question:

If using the single product approach, is it possible to pull a report which shows where non-returnable containers have been sent? Obviously this is possible when using a dedicated separate product for non-returnable containers, but I’m wondering if there’s a way to trace/report on non-returnable sales without having to split them out like that.

Cheers!
Greg

Excellent question, thanks Greg!

Currently, the only way to report on the difference between the sales of the two would be for them to be separate products. If helpful, we could certainly look to create a report that allows you see, for a set date range, something along the lines of:

Product Number of returnable containers delivered Number of non-returnable containers delivery
NEPIA 50 120
Bitter 190 10

This would then allow you to use the single product approach and get to this sort of data, but it would be in just the one dedicated report, whereas when using multiple products, you’ll be able to access the split in many different reports and places that can already report based upon different products (like you suggest).

Would a report like this be useful for you, if so, we can add this onto the requests list. Would another report be of more use instead (e.g. seeing the actual customers rather than a grand total of containers)?

Cheers

Hi Luke,

Thanks for confirming what I suspected! Ideally I’d prefer to go down the single product route to reduce clutter on the system (from having to create duplicates of every product sold using non-returnable containers), but would need to retain the ability to see a breakdown of the following in a report:

  • dates (issue, scheduled delivery etc.)
  • order/invoice numbers
  • customers (name, postcode etc.)
  • number of non-returnables delivered
  • products

Might that be doable? No need to go beyond a single dedicated report I don’t think!

Cheers,
Greg

Thanks Greg,

That all makes sense. We should be able to put this report together for you, and I can fully see the benefit of the single product approach, especially when this data is then available to you.

We’ll get this added to the list and try to get it scheduled in soon, but I can’t say just yet when we can expect it to be completed. It’s up to you if you’d like to go with the single product approach in the meantime, or if you’d rather split them until the report is ready and then consolidate the products later (marking one of each as obsolete).

If you go for the single product now, then when the report is ready it will know the container split for all orders, so you will be able to look back and see the split on orders delivered before the report is live. I hope that makes sense.

Cheers!

Hi Luke,

Really sorry I missed your response here! This sounds perfect, especially the fact that it would work retrospectively.

We’ve just made the decision to start using the single product approach for a recent batch of non-returnables. We should be able to make do without the report for a bit, but it would be really great to have as soon as you guys can squeeze it in!

Cheers,
Greg

1 Like

Hi Greg,

This report is now live in Reports > Pre-built delivery reports. Hope that helps, but any questions on it, just let us know here!

Cheers,
Max

1 Like

Hi Max,

Wicked, thank you! I’ll have a play around with it over the next couple of days and will let you know if any questions/issues come up!

Cheers,
Greg

1 Like

Hi team,

With the new Kegstar no-scan system being rolled out, we are concerned that our current system (using a single container type and product for house and non-returnable containers) is going to become unworkable. As well as Kegstars, we also occasionally use Polykegs and Keykegs, as well as using the non-returnable functionality to resolve racking errors (where a tracked container cannot be filled for whatever reason, and so a one-off non-returnable is created instead.) Obviously Breww won’t be able to determine which non-returnables are Kegstars, and which are other types.

We really want to avoid having to set up separate container types, and consequently separate products, for each different type of non-returnable, as it creates unnecessary clutter and opportunity for mistakes across all departments using Breww. The only way I can see to avoid this and still be able to use Kegstar’s no-scan system would be if there were various sub-types of non-returnable offered for racking within a container type/product. In that way we could have a single 30L keg product for example, choose to rack either a tracked/numbered container or a non-returnable, and if the latter is selected be given a choice of various options, one of which being “Kegstar”.

I appreciate this is not the way Breww has been designed, and it is likely that this suggestion would require a rather fundamental overhaul to how the system works, but I would be interested to hear your thoughts.

Thanks,
Greg

1 Like

You’re right there, Greg! :joy:

We’ll have a think about this and let you know what we come up with.

Thanks Luke, much appreciated!

Just thought I would add our experience in on this also - we have found that we have ended up with a deluge of products to get around this same issue - particularly a while ago when non-returnables were difficult to source. When you consider that alongside steels, non-returnables can also be bagged/non-bagged, have different spear types (D,S,A.etc), then multiply this by the different sizes (10L, 12L, 20L…) this becomes a lot - as it stands we have 21 different container types available in breww currently.

However, we do need these to be separate as breww currently works due to sales/customers/export needing to know type, spear & bag/non-bag availability due to their individual dispense setups.
Alongside this we also link these container types with our PO’s & Inventory management, and further this has an impact on the dispatch side as steel weighs more than one-way, so we need this information for couriers & van loadouts.

That said, I do like the idea of sub-items for clearing some of the clutter - but we would still need it to provide the same flexibility it does now.

1 Like