Can someone please help with a strange issue. Our app changes the item price of the items automatically every 10 minutes. We have one client who is reporting that the item prices are updating all previous orders on their iPad. However, when we test in the virtual terminal, this isn’t happening. For example, assume the price of an item called Yammy changes three times and there are three separate orders. Yammy at $5. Yammy at $6. and Yammy at $7. In the virtual terminal, when I place the order three times, I correctly see that Yammy is at all three price points. However, on the clients iPad, the price of the two previous items has changed to match the latest price. Here’s a screen shot comparing the virtual terminal order with the clients actual order at their bar. Is there any logical reason why this is happening? Again, we have many Square bars using our app and no one has reported this issue. Thanks for the help!
I was able to replicate it. It looks like the update to the price is happening right before the item is actually added to the open ticket. This is can happen when updating item prices during business hours. Technically the item hadn’t been added to the open ticket so the previous price wasn’t applied to the ticket. The item and the seat need to be added to the open ticket for the price to be locked in.
Hi Bryan, not sure if I should be replying here or on Slack. The prices are actually changing for old items that were placed in the tab or order a long time ago. For example, the bar added a Beer to a tab at 5pm, and another at 5:15pm. The price of the Beer was $6. Then at 5:30pm we changed the item price of the beer via API. The two items that were ordered 30 minutes ago and 15 minutes ago changed price in the open tab. Are you able to replicate that?
Hi Bryan, just checking to see if you have any updates. I have a receipt # for one of the transactions that has had the problem, is that the same as the order ID? If not, where do I find the order ID?
The receipt in question is #9aK8
Okay, I figured out how to replicate this consistently. I’m reaching out to the team to see if this is the expected behavior.
Oh yeah? Ok great job figuring it out. Hopefully they have a solution. Do you know how to replicate it? Is it only a problem with Square Restaurant POS?
Hi Bryan, just checking to see if you have any updates. I haven’t heard anything in 2 hours. Our client is expecting a call from us this morning, hopefully with a solution. I’m worried it’s a bug in the Square Restaurant app…there’s no way it’s supposed to revert all previous prices the way it is…
I’m waiting to hear from the team. I was also able to replicate this with the Square app as well as the Restaurants app. It seems that the behavior is if you add an item to an open ticket than the price changes when you add that item again to the open ticket the price updates across the entire quantity of the item in the open ticket. Please note this may be the default behavior rather than a bug but I’m double checking with the team.
Oh really? Hmm, in the test I just ran on my Square app I started a new sale, added the item, changed the item price, and then added the same item again, and the price was correct for both items. Is that not the correct way to test?
Was that to a sale or an open ticket? Cause if you save the open ticket then later add the item with the new price it will update the price of the previous items.
Uh oh, you’re right, that was for a sale. With an open ticket the price changes just as you said. This will completely ruin our software, and we’ve spent years integrating with Square to make it our main source of business. Assuming the worst, what are our options?
I see that Square has an API call for applying product discounts. Could we apply a discount instead of changing the item price? For example, if Bud Light changes from $5 to $3 we would apply a discount of $2. If Bud Light increases from $5 to $7 we would apply a reverse (negative) discount of $2. Would that work in theory?
Hi Bryan, my developer has one other potential idea. we could use the api to add the new product with same data but different price and maybe different category (so it doesn’t mess with orders on their end), this way in open tab the patron would have two different Budweiser’s, with same names, but different prices and different ID’s
How would the waiter know which one to add to the open ticket?
We would automatically apply the correct item based on the current item price in our app.
However, do you know if the discount option would work? That would be much easier to implement.
Still no word from the app development department I assume?
We really need to figure out a solution next week. I’m hoping it’s just a bug that can be fixed with Square. If not, we need to come up with a plan B.
Right, however I believe this is the expected behavior because it consistent across all products. As for a work around I’m not sure there is a viable workaround cause Open Tickets aren’t available via the API. Any work around would be the employee having to know that discount or item to apply at that time.
We don’t need to modify open tickets. We just need to be able to charge a different item price. I’d think applying a discount to the items via the API would work, right? Or our creative method of using the API to create a new item with the new price point, and then deleting it after via API? Who can I speak with about these ideas.
Creating a new item and deleting the old might work. I just tested and was able to add the items without the open ticket adjusting.
Thanks for testing, I really appreciate it! I’m assuming if we assign a new category to the items, they won’t show up anywhere on the POS that can confuse the bartender or server, is that more or less correct?
They will show up in an item search which may be confusing. That search would return all the items.