When managing your deliveries, you can assign specific stock (such as specific kegs) to a delivery. Sometimes, at the point of ordering, you will want to choose which batch of stock must be used to fulfil the delivery but don’t yet know which specific cask/keg numbers will be used.
Following the implementation of this feature request, Breww now supports this workflow.
To set the allowed batches to use, you should first add the product to the order. Then use the edit button:
Thanks for implementing this! Unfortunately this would let us select every batch, even batches that are sold out or not complete yet. Is there any way this drop down could be refined to what is available in the specific order Fulfilment site?
Hi Alice, thanks for your comment and thoughts on this! I think you have raised some great points here; however, there are some benefits to including every batch. Having the ability to select incompleted/ in-progress batches allows users to choose a ‘fresher’ batch to use on a future order rather than the batch that is currently being consumed by current orders. It also means that users who have an in-progress batch split across two vessels, in which only one of the vessels has been packaged, can assign the products racked from the batch to orders. In terms of sold-out batches, having these listed also allows the flexibility to assign batches for any scenarios where there will be stock adjustments. However, I think having some clearer messaging on batches that are being selected would help and improve clarity here and should hopefully solve this problem. For example, perhaps clearly showing ‘Sold-out’ on a batch when selecting batches. Likewise, possibly showing a warning message as to what site the stock is held at would be useful. If you think this would help, it would be great if you could raise this as a feature request for our dev team to review! Cheers!
Hi,
This is a great feature! Thanks for implementing. I can see that this pulls through to the deliveries page when using the web browser but it doesn’t seem to on the app. Is there a way it can also say ‘Fulfill from batch:xxx’ on the app too? We don’t scan out our kegs/casks/cans and have no plans to for now so it would be a massive help!
I also noticed that if you allocate stock from a future/in progress brew, it takes it out of available stock for the current batch, unfortunately I can see that causing a lot of issues for us as people will think that the beer is sold out, when in fact it isn’t, it’s just got orders in for future brews. Consequently, I think this will cause a lot of ‘old’ batches of beer to sit around waiting for the next brew to be packed before being sent out. Even if you look on the outstanding orders section for that beer, it doesn’t tell you if an order is allocated from a future brew. Although it would be easier if you could just see this in the toggle display in the products list.
We are glad you think so! Currently, the app really is designed for scanning. Are you auto-assigning stock or manually selecting it on the web version of Breww? Both of these functions are really optimised for the web version of Breww and really only available on the app by navigating to the main Breww deliveries page by selecting Breww at the bottom left of the app, opening the menu at the top left and navigating to deliveries as you would on the web version of Breww. If there are some additional functionalities you would like in regards to assigning stock to deliveries from the Breww app if you can raise them as feature requests I am sure our dev team will be happy to review these for you.
Regarding the stock impact, I don’t think this is actually directly related; I would imagine this is, in reality, the issue discussed in this feature request on Improvements to Planned packaging and delayed racking release stock control (allow overselling if stock will be available in time) whereby today’s available stock is impacted by orders which would use future planned packaging. The batch assigned on the order although it might look like it actually has no impact on this. The only thing I could suggest for now is to keep orders using future stock as draft until the stock is packaged and in Settings → Product settings, turning off “Include draft orders in product quantity allocated to orders” so that this does not impact current stock levels.
I don’t believe this has been mentioned before(apologies if it has) but what is the possibility on showing the “Delayed Racking Releases” batches or planned packaging stock to the list of options for assigning batches to orders. This may help a lot of issues with available stock being taken up by large orders for future delivery. I know this would probably relate to both requests.
Great question! Currently, it is possible to restrict an item on an order to use any batch, be it a completed batch, one in progress or a batch that is just planned. However, it’s important to note that this doesn’t mean Breww will exclude this assignment from today’s stock availability. These two mechanisms are currently not connected.
When you create an order, it will deduct the assigned amount from your current available stock. If you have a planned packaging scheduled after the delivery date, you can still create the order, factoring in this stock. Nevertheless, your available stock for today will still show a reduction. The workaround explained above is still the best method I can suggest, which is unchecking the option in Product settings to “Include draft orders in product quantity allocated to orders” and leaving your large future orders as draft rather than confirmed. This is currently the most effective way to manage this situation.
A great new feature could be to prevent the available stock figure from decreasing when an order is assigned to a batch with planned packaging or delayed releases unless the ordered stock quantity exceeds the planned packaging or delayed release stock quantity. Essentially allocating stock from a planned packaging directly to an order to prevent an impact on your current available stock figure. I don’t think this would be an easy feature to implement, but if you want to raise it as a feature request, I am sure our dev team will be happy to review this for you.
I hope this answers your question, but let me know if you have any more questions at all.
