-1 Count

[gbare_benice]

Hello!
Is anyone else having an issue where servers are allowed to continue ordering an item on a count after running out and resulting in a -1 count. We are having it happen on a regular basis, but support says it is a fluke.

Please keep in mind we don't use online ordering or third party integrations at this location, so the orders are coming from our toast go 2s or flex terminals. We have not been in offline mode either.

This doesn't feel like it should be possible.

Please let me know if you've had the problem and hopefully a solution.

Thanks!
Greg

[rcmck]

Happens occasionally, if you put a count on something but the item is already on a check that hasn't been sent yet or has been held then it can still be sent even if the current count is 0. I try to get counts in as soon as possible to avoid it, or put it a lower number than we actually have if it is very busy at the time. 

[gbare_benice]

Thanks! Seems to happen to us often. We put the count in at the beginning of the shift on special items.  We have only been online at this store since 08/29/2023 and I have four documented cases. Starting with one less hasn't helped us, we still end up overselling since one is still showing. This sure feels like a bug to me, there has to be a better way  for the software to handle it. Perhaps removing it from the count as soon as it is added to the check instead of when it is sent?

[rcmck]

It is removed from the count when added to a check and before sending, but if there were some on a check before the count was actually put in that is when the issue comes up. I never have any issues with special counts that are put in before the start of service. One other thing to look out for is the use of void when there is an issue with something, if someone voids an item that was actually made but had to be re-fired or the customer didn't like for example then the count will be added back even though you have one less available. Should always use discount and comp the item, only use void when something was never actually produced like sending the wrong item or customer changed mind at the last second. 

[gbare_benice]

The discount procedure you described is the method we use. We have developed a testing protocol to see if we can consistently reproduce the issue in the production environment this week. Toast support seems to think that it may have to do with multiple servers sending orders simultaneously (we have up to 30 Toast Go 2s and four Flex Terminals in use at one time).  It may be the problem, but I would assert that there is better way to handle this than letting the server think their order has been placed and take us into a negative counts  -- given the speed of the network and of the hardware, real time updates within milliseconds would be possible. If sending too many orders at once is the problem, it is looking like the feature is not designed to keep up with our pace during peak periods.