Quick and/or automated conversion between tracked and non-tracked kegs

Ideas & feature requests
1

We use Breww keg tracking at our brewery, but struggle with how to handle this when we ship kegs to our consignment distributor (Connect Logistics Services in Alberta). We currently send non-tracked (“non-returnable”) kegs to the distributor, because they do not use any tracking system, so we lose tracking on those kegs once they leave the brewery.

It would be very helpful if we could set up an automation rule, such that when we stock transfer to a certain Breww site (i.e. in our case our Connect Logistics site), any kegs transferred become non-tracked, and vice versa - when kegs are transferred from Connect to the brewery, Breww would require keg ID numbers in order for that delivery to be completed.

At the very least, it seems like conversion of kegs from tracked to un-tracked should be much easier than it currently is. Right now it is especially painful to turn a non-tracked keg into a tracked keg (for example when we RTV product from the distributor). We have to use the “rack from container” process, which has a lot of steps and also has some pitfalls.

The conversation linked to below contains some additional context specific to Alberta. But the feature I’m proposing seems like it could be more generally useful to for any breweries who both self-distribute and sell through distributors, and who also want to implement keg tracking.

1 Like
Alberta CLS Keg Auto Assign
2

Thanks for the suggestion, Dave. Do you physically move the beer from one keg to another? Or does the beer remain in the same physical container?

3

Hey Luke,

No, we seldom move beer from one keg to another - we general keep the beer in our own cooperage.

The problem is that as soon as the beer gets sent to Connect Logistics (CLS), we lose track of the keg until it returns to the brewery. In a perfect world, CLS would track kegs for us and we would know which customer they have been delivered to. However I don’t see this happening anytime soon.

Our current workaround is to treat kegs that go to CLS as “non-returnable”. This is necessary because otherwise we’d be receiving empty tracked kegs back to the brewery that are still marked as containing beer at CLS, rather than properly showing that they’d been sold to a customer, emptied and returned.

Does this make sense? I’m probably not explaining it very well.

Thanks,

Dave

4

I had posted in the other thread, but I would like to re-iterate that it would be useful to have tracked kegs going to CLS. Without it, my 50L float is basically untracked and I have no idea how many I have.

Is is possible to treat CLS like a direct delivery account, or make a special warehouse type that allows tracked kegs to be sold without the number mattering? We would ship tracked kegs to them and when we get the empties back, we would scan them back into the system. Once it’s at CLS, it’s like a black box from a tracking perspective, it only matters to me when the keg leaves and when it returns.

From a keg float perspective, I would have a much better idea of how many kegs I have. 50s for example almost exclusively go to CLS and from Breww’s perspective, they never get filled since we fill them as NR. If I could also see a report that shows the average time a keg sits at an account/CLS, that would allow planning for float sizing.

1 Like
5

Hello,

We have the same problem as well. This is a proposal that lines up with Chase-Gordens post with a bit more possible implementation detail:

Issues:
We send a mix of non-returnable and our own branded kegs to CLS. As stated, they no longer get tracked once they have gone to CLS. We still get the CLS orders indicating that products were ordered and delivered, but nothing is assigned. This means that we get a build up of of incomplete deliveries in CLS that we at some point have to weed through do something with. The build up of unassigned deliveries make the delivery module of Breww very difficult to use and it requires time and effort to clear out.

When our own kegs are returned to CLS we eventually get them back (showing as full) and we have to go through and ‘empty’ them in Breww. We are not able to simply ‘return them’ because Breww sees them as never assigned and therefore still full. The current options for these are to ‘dump them and effect taxes etc’ or ‘return them to stock’. Neither are correct and at this time I do not recall the workaround we ended up doing. We need to be able to return them like they went to a customer and came back.

Possible Solution:

If we could tag a location/entity as a 3rd party distribution location, it could potentially solve the CLS and other 3rd party distribution issues.

If a location is tagged as such, there could then be additional Boolean options available as follows: Options 1, 2 and 3 are Radio-Button mutually exclusive and Option 4 is an additional check-box option. Option 1 is the default using current Breww behavior and selecting it makes Option 4 true and also grayed out.

Option 1) “Default Breww Behaviour, Track User Owned Containers and not NR Containers:
Option 2) “Track Container Quantities Only, Do Not Assign Containers To Customers”
Option 3) Containers Delivered to This Location are Not Tracked”,
Option 4: “When Containers From This Location Are Scanned, Allow Them to be Returned As Empty/Used”

Result:

Now Breww would be totally flexible for all types of 3rd party distribution locations, (ok, I ignored the possibility that a 3rd party could track Breww kegs through to customers). With Option 2 enabled (for example with CLS) Breww can track the total quantity of a particular container at a 3rd party distribution center based on quantities of container products delivered to the 3rd Party and ordered but there is no insight into which container went where. We do not get it anyway so that is not a loss. With Option 4 enabled (like for CLS), a keg that was delivered to the location and later scanned can be returned as empty just like it had been assigned and delivered to a specific customer. And, the total quantities of a particular container type at the location would be known if Breww sees that locations orders, like with CLS. In this case we are just blind as to which container went to which customer but I think it solves the assignment and container returns issues.

I believe this proposed solution should be generic enough that it can solve a wide range of different 3rd party distribution issues around container tracking and notably, the CLS issues.

Thoughts?

2 Likes
6

Thanks for the extra context, Ian - that’s really useful.

We’ll give this some thought and get back to you if we have any questions.