roosterchef

Members
  • Content count

    80
  • Joined

  • Last visited

Community Reputation

11 Good

About roosterchef

Recent Profile Visitors

3,133 profile views
  1. Anyone else having a damn difficult time reconciling cash at the end of the day? We've been using Lavu for 3 years now, and for a long time we didn't have this problem. Lately (last few months) we are over some days, short some days. We've been counting and recounting, checking everything twice, and can't find any mistakes. So I'm beginning to think it must be something wonky with Lavu. Our situation: we operate as a server bank restaurant, meaning servers carry their own bank, and we take cash from them at the end of their shift. We also pay them for credit card tips at the end of their shift. We first make sure they have no open tickets remaining, then use lavu.com reports to tell us how much the server owes us, and how much we owe them for tips. Paid outs are entered properly, we record all these cash flows manually on a log sheet, all money changing hands is counted twice, and after all servers are done we count the drawer. And balancing has become the exception not the rule. Some days over, some days short. So we go back and check all the numbers, server totals against paid out and in, starting cash count, etc. etc. It all checks out, no errors, but still we are off. I'm suspecting some type of data corruption. When we tried version 3, we had all kinds of ticket corruption issues, lost tickets, etc. We backed down to Lavu Retro and it has been better since, until more recently. We still get occasional duplicate tickets, but those aren't hard to find and adjust for. Anybody else finding cash mysteriously appearing and disappearing?
  2. Quickbooks Integration

    I've been looking for QBO integration since we started on Lavu in early 2013. Can you provide a link for Shogo? I feel your pain on some of the other stuff. Seems crazy that we still have to use version 1 reports to get customer counts, server sales with tips by payment method (for more than one server at a time), etc. Plus we still run on Lavu Retro because we kept losing so many tickets on version 3, although to be fair, we haven't tried since we downgraded earlier last year. On the upside, the new reporting is great if you are trying to do ad-hoc drill-down analysis of your sales. So it's a mixed bag. To Pablo: if you read any user community forum for any product, you'll mostly find people talking about the problems they have with the system. Who's got time to log in and write how wonderful everything is going, right? It's kind of like Yelp, it's mostly the pissed off people who take the time to write. That said, Lavu is more modestly priced than the bigger names with better developed products, like Breadcrumb. So it also depends on what you can afford whether Lavu is the right choice for you.
  3. Missing order

    We downgraded back to Lavu Retro months ago because of this very problem. Still on Retro, with little appetite to try the latest version. I'm sure some day they'll force us to upgrade, and then we'll have to fight these battles again.
  4. API Support

    I was never able to get any support for the API. Most of the support people don't know anything about it anyway, only the developers do. But I think they probably don't want anyone to actually use the API because it can cause later problems for them when they break your code with some API change or feature upgrade. That said, I was able to get things to work, mostly. But you have to hunt and peck, because what data is in what fields is a bit of a challenge, and the data isn't strictly normalized in the database design sense. It definitely takes experimentation.
  5. Lavu 3.0.1 - Will it work?

    We have been upgraded for 5 days now and we are still seeing the same oddball behaviors as with 3.0. Tickets that magically re-open on following days. Orders that get re-assigned from one table to another. Items disappearing from orders. That sort of thing. We're going back to retro for now, at the suggestion of the Lavu support tech. Our servers and floor managers are up in arms with the order problems, looking forward to getting back to stability. I'm glad Lavu has kept the old version available. -Jim
  6. Lavu 3.0.1 - Will it work?

    So . . . . Anyone try it yet? Or are we all waiting for someone else to be brave? -Jim
  7. Lavu 3.0.1?

    Can we get an update on 3.0.1? In your comment on 3 June it was supposed to be the following week, but when we checked the Apple store yesterday it still listed 3.0 as the current version. -Jim
  8. Lavu 3.0.1?

    RafaelT, you told us to expect improvements on the 3.0 problems in 3.0.1 and closed the 3.0 discussion topics. But then I think you need to give us some idea of the timetable for 3.0.1. Being a beta tester in a live environment is a worrisome thing for most of us. So that means most of us will wait for someone else to take those hits and bruises. Therefore, to help us decide whether to regress to Lavu Retro or wait it out in 3.0: What is the forecasted release date for 3.0.1?When will the 3.0.1 Beta be available if we are willing to test it?Thanks, -Jim
  9. Lavu 3.0 problems

    As I've dug deeper into the tickets with problems at our site, almost all of the mysterious behavior involves modifying a ticket on one device (doesn't matter what - adding items, splitting the ticket, closing the ticket), and then opening the ticket on another device. If this second device had an earlier version of that ticket, then frequently the earlier, but now outdated, version of the ticket is uploaded to the server and it stomps on the later correct version, reverting back to a prior version. MantheDan hit the nail on the head I think. Given the slow delay in getting ticket state updates from the cloud to the client app whenever someone pins in (e.g. the delay in seeing the dining room view update), this would make sense. If a server pins in and then quickly opens a ticket before update comes down from the cloud, then the re-opened local ticket becomes the "newest" official version because it will be time-stamped later than the correct version sitting on the server. For instance, we had a group of 25 the other night, sitting in our small group room. The server took their orders on her tableside iPad. After saving and exiting, a guest changed something on their order. While getting drinks, the server pulled the order up on the register iPad next to the drink station and made the correction. Later, she was asked to split the ticket into two as two different people were paying, and to put the bottles of wine on a third ticket because that would be payed differently also. She did this on her tableside iPad. When it was time to pay, she pulled the group ticket(s) up on the register iPad to print the tickets, and both the split and the wine were gone. So the changes she made in the third edit of the ticket were eliminated by the second version that still remained on the register iPad's local cache. A bunch of the other problems we have had seem to fall into this exact same pattern. With the exception of the problem of tickets not closing upon payment, but maybe this is also related, I don't know. Anyone else besides us and MantheDan seeing their problems fit this pattern? -Jim
  10. Lavu 3.0 problems

    We were advised to raise our dining room refresh value from 10 seconds to 60 seconds, even though that seemed counter-intuitive. Problems seemed to increase (no objective measure) so we put it back to 10 seconds after a couple days. That said, we have seen ticket data sync problems occur when subsequent openings of the ticket on a different device were well past even the 60 second limit. We have seen tickets re-open two days later, just because, it seems, they were stuck as "open" on one of the devices the ticket had originally been on. When that server used that iPad again (they grab different ones each shift), the ticket appeared to magically re-open 2 days later. So I don't think the user-settable sync time value has an impact here. Something else, but still related to data syncing between client and cloud, is broken. -Jim
  11. Lavu 3.0 problems

    I made a descriptive error in my prior post. The tableside delay is not waiting for the dining room with table layout to display in the app, but rather it is waiting for the tables to update to their correct status. In other words the dining room with tables comes up in the app right away after the server enters his/her pin, but it takes up to a minute or more for that display to update with the correct status (open or occupied) of the various tables. Sorry for the inaccurate description. -Jim
  12. Strange Behaviors Today

    I posted an update about our situation on the concurrent topic that is running on this board called "Lavu 3.0 Problems" - https://talk.lavu.com/ipad-pos-topic/lavu-30-problems-2226/ There were more posts there already listing the precise problems we have also been having, but in summary, we are still experiencing all of the above (minus the sort issue) as well as discovering some new tangles. This still has a ways to go before it is sorted out I'm afraid. -Jim
  13. Lavu 3.0 problems

    We too are having many of the exact same behaviors described above: Items (like a glass of wine) disappearing from checksChecks not closing upon payment even though balance due is zero (getting this quite a bit)CC payments indicating declined but the payment actually does go throughClosed tabs and table tickets suddenly re-opening, one re-opened two days after it was closedThe mysterious disappearing or re-appearing tickets is causing problems with server checkout.Ticket modifications made at a register terminal (like splitting up the ticket across multiple checks) are then not showing up when the ticket is re-opened tableside (yes it was saved).Speaking of check splitting, we're getting checks that were split being recombined onto one check after being saved and later re-opened.And still on check splitting, servers are telling me that the 3.0 check splitting demo that is available from Lavu simply doesn't work as it is demo'd in that video (it's on YouTube and a support site I think). So you can imagine how much #7 above pisses them off if they struggled with getting the split correct in the first place.And here's the one that is really driving my servers crazy: it takes the iPads tableside forever to sync up and display available versus busy tables so the server can start a new ticket. For instance, server walks up to newly sat Table 42. Opens up Lavu and waits well over a minute for the dining room layout to come up with tables. Then frequently Lavu indicates Table 42 still has an open ticket, so the server has to start a tab instead. Of course, since Tabs don't have guest counts, this is totally hosing our guest count totals tracking. On the plus side, Lavu support has been communicating with me (email) almost daily. Unfortunately, none of these problems are reproducible on demand. They happen inconsistently. We've started keeping a problem ticket log during service and will be sending them more ticket numbers tomorrow or Monday. Also on the plus side, we are NOT seeing the cash count discrepancies between version 1 and 2 end of day reports that others are seeing. As long as you remember that version 2 reports are all "Closed On" reports it seems to agree. Of course, we ARE having the problems where server summary reports are wrong, but that is related not to reported rather the problem with re-opening or not-closing tickets. It seems to me that almost all of this relates to problems in syncing transaction data between the client side app and the servers. Lavu touts one of the big enhancements in 3.0 is a faster & more seamless experience for servers in terms of this syncing between local data and server data. If you think about it, inconsistent data syncing would explain many of the problems above. RafaelT, you are waging a brave battle here to try and keep us all happy, but I think 3.0 is really still very buggy. And being what amounts to a beta test site, where we have to document all problems in detail so Lavu can track down and squash these bugs is enormously inconvenient when you are trying to handle a busy full house where seconds matter when it comes to your POS system. I'm expecting that we will make the call to regress back here very shortly. The prior version was actually quite stable for us. -Jim
  14. Strange Behaviors Today

    RafaelT: OK, did that and we'll see. I'm skeptical because the transaction flow on a checkout with cc payment goes from card swipe - prompt - print - close ticket and exit server (matter of couple seconds or less). Hard to see how dining room view refresh is involved there.Have not yet heard the floor managers discussion of last night. I'll update later. Might be fixed.Emailed those this morning.Tableside, single device, iPad mini, iOS 8.3Old reports, and it has been fixed.Thanks.
  15. Strange Behaviors Today

    Update: sort order on reports seems to be fixed.the orders not being meal period stamped is still a bug. Last night, one of our servers (but only one) had 19 of her 21 orders not be called "dinner" even though the time stamps show them as such. Her last two orders were properly stamped.still having issues with how credit card payments are handled.did not hear again about the tabs problem, maybe fixed, I can't yet say.-Jim