I have a suggestion for the batch schedule rules. After I had designed my decision tree and tested it, I ran in some issues. One of them was that the decision pathway, once it reaches its first reading schedule gets terminated and stops there. However, I would want more conditions to follow at the same time. Example.
When we put a tank on chill, we start draining hops and check the co2 level in the beer.
The condition now is “needs draining” - > yes, process terminates here. However, at the same time CO2 might need measuring but it will never reach this condition as “needs draining” was not answered with “no”.
My suggestion would be, why not implement an optional output from a reading schedue? Meaning, the ability to connect this “draining hops” reading schedule to the “co2 not measured yet?” condition input. Therefore, a reading schedule could be a terminal endpoint or it could be a measurment that is running paralllel.
Thanks for writing this up, Matthias, and for the diagram, it makes the problem really clear. It ties in with what you raised in your other post: each vessel follows the tree until it reaches its first reading schedule, and that’s the one it uses.
That’s deliberate, and I think it’s worth keeping as-is, to be honest. If a vessel could pick up several schedules at once, a few things get messy quickly:
Each schedule has its own form, frequency and number of readings, so one tank could have “every day”, “every 3 days” and “weekly” all running together, each with its own due date and its own tick marks on the tile.
When a reading is recorded, it becomes unclear which schedule it counts towards. If two forms both include gravity, does one gravity reading satisfy both, or only one?
The tree gets harder to reason about. At the moment you can follow a vessel’s path and know exactly what it will be asked for. With parallel branches you’d have to work out every branch it touches and how they combine, and a “No readings required” at the end of one branch wouldn’t really mean that anymore.
I think the existing structure can already do what you need, though. A reading form can hold as many readings as you like, so rather than running two schedules side by side, you can describe the combination directly:
Needs draining? Yes → CO2 not measured yet?
Yes → a schedule using a “Draining hops + CO2” form containing both readings
No → your current “Draining hops” schedule
Needs draining? No → CO2 not measured yet?
Yes → a CO2 schedule
No → whatever comes next in your tree
So the tank on chill that needs both gets a single schedule asking for both readings at once, which is also one entry for the operator to fill in rather than two. Each reading on a form can be marked required or optional, so if the CO2 reading is only a “nice to have” on that combined form, you can make it optional.
This does mean the tree grows a little for each combination, but for two or three overlapping checks it stays manageable. Would this work for you? If there’s a case you can’t express this way, let me know what it looks like, as that would help us understand whether something more is needed.
With the new changes to how breww can implement batch readings it looks like an incredible useful tool for streamlining our day to day operations. We will be able to have staff check the batch readings screen and known exactly what needs to be checked or manipulated on each vessel. The only slight problem we have is that is we have a vessel where our process requires 2 different readings/manipulations they don’t always happen at the same time. For example quite often we will need to check carbonation levels of a batch and also need to drain hops from a batch. For our workflow it makes sense for an operator to go and do all the co2 readings and either then do all the draining or another operator might be doing the draining later. We can assign a check that says both need doing BUT if brewer 1 does the co2 reading they either can’t input it into breww in real time as they won’t have the information on how much has been drained (and therefore cause jobs being done twice for no reason or reading not being recorded) or they would put in the co2 reading and temporarily put a 0 amount for what’s been drained but then when brewer 2 looks at the batch readings screen they see that the tank has already completed its reading for today and the draining could easily be missed.
Is it possible that if there are multiple required readings for daily reading process, that if one or more of those is not entered that the daily reading has an “in progress” status and can show in orange so brewer 2 in our scenario can see instantly from the batch reading tab that a tank still needs some sort of check or reading and can then click on the reading to find out what, rather than the overview showing the tank is done for today? Could add a little tick box that needs to be manually ticked to allow this to happen on the reading (like starting batches if an ingredient is is not in stock at time of starting) to ensure the person entering the data knows that they haven’t entered a required reading before being allowed to submit the reading.
Thanks opening a new feature requests, @josh-wise. It feels like yours is a continuation of the one Matthias opened yesterday and ultimately you’re looking to solve the same issue.
I’ve merged it on the end of the one by Matthias and renamed it to more broadly cover what you’re looking to solve rather than specific individual ideas for the solution.
Good news - we’ve released a solution for this A vessel’s required batch readings can now be recorded separately, at different times and by different people, and still complete its reading schedule.
To use it:
Edit the batch reading form you use for the schedule and enable Allow saving without all required readings. The form then shows a Partial saving allowed badge in your list of batch reading forms.
When recording a reading, enter the readings you’ve taken so far and select Save without all required readings.
The vessel shows as In progress on the Production dashboard’s Batch readings tab and in the batch’s Analysis tab, with a Still needed line listing what’s left.
When someone records the rest, the form shows which readings are already recorded, when and by whom, so they only need to enter what’s missing. Once everything required is in, the vessel is marked as done.
Forms without the setting enabled work exactly as before, so nothing changes unless you turn it on.
A vessel’s required batch readings can now be recorded separately, at different times and by different people, and still complete its reading schedule.