SambaPOS Forum
English Boards => Support => Topic started by: JohnS on February 08, 2012, 06:54:43 am
-
Emre,
I have a puzzle to solve.
The Restaurant & Bar Departments can cross sell. Each Department has their own User - named after the Department - Restaurant & Bar.
We want all Restaurant Orders to go to the Kitchen Printer - that's easy, set Restaurant as Department in Print Job.
But, I need a Bar Order to print to a Bar printer only when the Restaurant orders drinks against a Table.
So I have added the bar Department to the Kitchen Orders Print Job, and selected the Bar Printer & Template (Just to test that the orders are going to the right printer)
All print OK if no tables are selected - regular cash sales.
If I select a Table and order from the Restaurant - all OK.
If I then change Department to Bar, select a Table, pick a Bar item and close the ticket - the order prints on the Kitchen Printer. If I pick a Bar item again then select a Table - then it prints to the Bar Printer.
Now, if I go back to the Restaurant, and order more, it prints to the Bar Printer, and continues to then print to the Bar Printer for that current Table.
Even if I use separate print jobs, this still happens.
Now I'm confused :-[
It is definitely only an issue when using Tables.
Part 2 - I actually only need the Bar Orders to go to the Bar Printer if it is ordered by the Restaurant user - Do we need a User in the printer mappings for the print jobs?
-
We store department id on ticket and use that department information while printing from any department. If users are not dedicated to departments like your situation this feature is useful. Department Id sets to active department when you create a ticket or change ticket table.
Print jobs supports filtering maps by ticket tags. Instead of department information can we use that?
-
My first thought was to use ticket tags, and that's when I started having the above issues, so I tried to simplify the setup. Because we have many different product groups for both departments, using product group is too messy.
Ticket tags are assigned to a ticket not an order, so once set, we can only print to one printer, unless we try to remove the ticket tag when they switch departments.
What we need is
- All restaurant orders to print to kitchen printer - no matter what user enters an order
- Only bar orders to print to bar printer when the restaurant user enters a bar order
I'll try again later today. Now that I have had some sleep I may be able to think clearer.
-
- All restaurant orders to print to kitchen printer - no matter what user enters an order
- Only bar orders to print to bar printer when the restaurant user enters a bar order
Couldn't get the logic here. With bar orders do you mean bar department or bar products?
-
- Restaurant products are only available in Restaurant Department
- Bar products only available in Bar Department
- Users can access both departments
I need orders created (and assigned to a table) in the Bar Department to print to a bar printer only for Restaurant users.
The logic here is that the Restaurant is physically away from the main bar, and if a restaurant guest wants a drink (instead of walking to the main bar and getting it them self), the restaurant staff can enter the order in the Bar Department, it prints an order ticket at the Bar. The Bar staff gather the order and deliver to the Restaurant Table.
-
John, I think I understood your point. "Bar items prints to bar printer" is a very common configuration but in most restaurants staff frequently rotates. If product based mapping does not solve your problem we should focus on improving product mapping. If you can tell me why product group based mapping does not solve this restaurants requirement maybe we can find a solution better than user based mapping.
-
I have played with different print jobs and found that relying on the Department within the print job settings is unpredictable when a user can switch between departments.
So the only solution I have found that seems consistent is to use separate print jobs by terminals, and list all product groups (messy when you have 30 or more different product groups across 2 departments). What this does mean is that a terminal is locked to a department - which may or may not be an issue based on its location or role.
I think the issue using the Departments with the print jobs is that SambaPOS gets confused when initially adding items to a ticket within another department, and the result can vary whether you select the table first or last and what has been ordered and in what order.
Despite this, after testing and reviewing the reports, I have found major discrepancies in the reports, in relation to the department that the sale took place in and the department that collected the money. See the attached files
WorkPeriodReport.pdf - The only accurate data is Incomes, User Sales & Item Sales.
ItemSalesReport.pdf - Everything is accurate except for Tickets
Export_Sales_Data_2012-02-12_03-18-57_txt.csv - Lines 2, 16 & 17 are Bar items, all others are Restaurant items. TicketNumber RT298 is a cross department sale, and this is where everything gets mixed up.
In summary, the Bar took $9 in sales and the Restaurant took $196 in sales, of which $11 is owed to the Bar - as $20 of bar items was sold across both departments.
Bar Incomes and Restaurant Incomes on the WPR needs to reflect the department total sales and Sales on the WPR needs to reflect who collected the money for the sales. But if a User logs into another department terminal then all this will be wrong again. We may need to list sales by Terminal name as well.
Now, I have been sick for the last two days, and feeling a little fuzzy in the thinking department, but the reports do make sense that things just don't add up.
-
Hello, thank you for the detailed information. Can we simplify it more?
Scenerio 1: Customer eating pizza ($15) in restaurant and requested beer ($5). Restaurant user switched to bar menu and ordered beer. Customer paid the bill ($20) in restaurant.
Scenerio 2: Customer ate a pizza ($15) in restaurant, saw a friend and moved to bar seat. He requested beer ($5) and bar user ordered it. Customer paid the bill ($20) at bar.
Scenerio 3: Customer was drinking beer at bar ($5), moved to restaurant table, ate pizza ($15), ordered one more beer ($5) and paid everything ($25) at restaurant.
SambaPOS reports will display these values.
WPR Sales will be:
S1. Restaurant $20, Bar $0
S2. Restaurant $0, Bar $20
S3. Restaurant $25, Bar $0
Department Based Incomes will be (Everything paid cache):
S1. Restaurant $20, Bar $0
S2. Restaurant $0, Bar $20
S3. Restaurant $25, Bar $0
Ticket counts will be:
S1. Restaurant 1, Bar 0
S2. Restaurant 0, Bar 1
S3. Restaurant 1, Bar 0
Are you Expecting?
WPR Sales:
S1. Restaurant $15, Bar $5
S2. Restaurant $15, Bar $5
S3. Restaurant $15, Bar $10
WPR Department Incomes:
S1. Restaurant $20, Bar $0
S2. Restaurant $0, Bar $20
S3. Restaurant $25, Bar $0
Ticket counts:
? (I don't know since on sales report we virtually divided tickets between departments by orders)
We thought WPR Sales, Incomes and Product Report Tickets area should match and does not confuse user. On second example reports will display Bar sold $5, Bar Income $0, Restaurant sold $0 but Restaurant income is $5 since customer ordered from bar but paid at restaurant. Is it what we should do?
Now I'm designing V3 accounts feature and what I'm doing now is very related with this topic. I'll be happy if you can help me on finding the best answer.
-
Emre,
Reading it again I think I was backwards in my logic.
You are right in your logic. We need to capture income for each department (actual sales tickets processed in each department despite the items) as this must match cash in the drawer.
Department sales needs to capture the total items sold in each department and their value. The theory is that the difference between departmental income & sales should equal the missing or extra income from the other department.
So in your scenario 3, the difference between the Restaurant income and sales is $10 - which is owed to the bar for the drinks.
We need a simple way to highlight these amounts so when the staff cash up at the end of the night, they can easily see which department owes the other and by how much.
In my example reports, very little data was relative to the actual transactions which in turn creates confusion.
Where this is critical is when you have fanchises within a venue, very much like we do in the Club Industry. While the bar is owned by the Club, the Restaurant is leased out, and in the case of a Golf Club, then the Pro Shop is leased out too.
We need a way to show the income per department, and then how that is broken up amongst the other departments if we have cross sold items.
So ideally, we need
Bar Income
Cash $580
C.Card $0
Voucher $0
Total $580
Being For Sales
Bar Sales $470
Restaurant Sales $110
Pro Shop $0
Then Restaurant income, sales, etc.
-
John, as I understand your tickets belongs to multiple departments and you consider departments as independent sections. So we need to sort out department sales individually on reports. Hmm.. There are more factors we should consider. For example discounts or Services maybe.. I have to think about it for a while.
-
Emre,
Have you found a solution for this yet?
I'm only asking as we are 2 weeks from going live with a 3 terminal site (1x Restaurant & 2x Bar)
-
John, Your request perfectly fits to your situation but for other type of businesses that difference between sales an income amounts might create questions. I think we should leave it as is.
One solution I can think is using product tags. I can add a section in WPR for displaying sales grouped by product tags. Since you don't have shared products between departments you can tag all products as "Bar Item" or "Restaurant Item" and these amounts might help identifying cross sales. If it helps I can include mapping by product tags in printer mapping too.
-
The problem is that the Department Sales match the Department Income. Which is fine if a user can only run in one department - which is usually the case.
Sales should always reflect the total products sold for that department - never income received.
Income should always reflect the total payments received by that department - never sales made.
User sales shows the performance of a user, and the total of all users should equal total income. Because a user can move between departments, you can not accurately use them for tracking sales and/or incomes - it has to be by departments.
Even if you own the whole business, you still need department breakdowns by sales & income. The way it currently is, you will never balance the cash drawers within a department - you have to balance the site.
I don't think product tags are the answer (but they will help). I think it is the way the report is generated is the issue.
There are only two scenarios.
1. Sales solely within one department
2. Cross selling between departments.
If you don't cross sell, then there is no issue with the reports.
If you do cross sell, then you need to track why the Bar cash drawer is down compared to the report, and why the Restaurant cash drawer is up.
John, Your request perfectly fits to your situation but for other type of businesses that difference between sales an income amounts might create questions. I think we should leave it as is.
If businesses are cross selling like our situation, then I think they will have the same issues as me.
I think it is the logic in the report calculations that are the issue - and it only shows up in my situation.
I have discussed this with a couple of managers, and they can not understand the calculations.
Simply put - I think there is an error in the WPR calculations when a ticket has products from more than one department.
-
John.. :) You are in the middle of the problem, you talk to people and you have a solution. But I'm thousands of miles away from it and I need to satisfy myself about if I'm understanding the problem right and if the solution really solves it. While trying to simulate your setup by myself I realized what SambaPOS permits is really amazing. But that was something that I never experienced before. Generally our real life users have a single menu for all departments but different seat plans. Some of them have different menus too but they have cross selling items in both menus. Every drink orders goes to bar printer but this is not something considered as cross sale. If we sell a beer from bar it is a bar sale and if we sell a beer from restaurant it is a restaurant sale. For this reason what I'm understanding from "Cross Sale" at first was different from your intention because of my past experiences. But now I can guess your setup. I think you have separated menus for multiple departments but a single seat plan and most probably your Bar department is a fast food department with a location button.
Yes I understand things slowly but at least I can do that :) Now after understanding the problem lets talk about the solution.
* We can't fix departments to user role department. Think of a user who both collects bills and also receives phone orders. He switches frequently between restaurant and delivery departments and he wants to see department amounts separated.
* When we have more than two departments we won't be able to calculate cross sales by comparing sales and income amounts.
* Even thinking about half payments hurts my brain. I'm sitting with a friend at restaurant. He pays the half, I leave the ticket open and walk to bar. I pay the rest at bar. (Is there any other software that can handle that without splitting tickets?)
But no worries.. I believe I'll be able to solve that soon :) As always, thank you very much for helping me on this. Every piece of work makes us better.
-
I have still things to do but you can test if it fits for your needs or not.
http://code.google.com/p/sambapos/downloads/detail?name=SambaSetup287.exe (http://code.google.com/p/sambapos/downloads/detail?name=SambaSetup287.exe)
We have department selection on terminal settings for fixing department.
-
Emre,
You have a copy of my database it sent you before about the Ticket Tag issues and WPR.
I have 2 departments and 2 menus. One menu for each department, but users can change department and tables are shared between departments (which is what we want so all sales are captured and nothing gets missed)
I will test 2.87 shortly.
People say you can not misunderstand a written document - but what they don't realize is that people can interpret it in different ways because we all think differently about the same situations. This is why I prefer showing problems by example as you can see what I am doing and then explain why I do it that way.
You designed SambaPOS to do specific functions based on your requirements, and therefore you work to a designed rule set and workflow. I on the other hand don't have these limitations (and that is not meant as a bad thing) so I push SambaPOS to it's limits by testing it's capability in different scenarios which you may or may not have ever considered.
Whether you realized this or not, you have not created just another POS system, you have created a whole new POS solution - you are running outside of the "POS Box" so to speak, and a not limiting yourself to what other POS Systems do.
SambaPOS is so unique because of this, and so much better. Most people look for a POS System that fits their business. You have created a POS Solution that is so flexible that it can fit any business.
I believe that SambaPOS is going to be so powerful, that other POS developers will start to look to SambaPOS for ideas on how to improve their software.
If I was you, I would start registering design patents to protect your unique features in the future.
-
Emre,
2.87 just adds more confusion as it shows all bar sales ($26.90) as Cross Sales, when it should only be $14.00. See Attached.
I will also email my currently database to info@sambapos.org so you can use it for testing.
Lets do a controlled example with my database.
- Start a new work period.
- Login as Restaurant User (9999)
- Make a Restaurant department sale and settle
- Login as Bar User (1111)
- Make a Bar department sale and settle
- Check that WPR is showing correct totals - Sales & Incomes should match in each department.
- Login as Restaurant User (9999)
- Make a Restaurant sale and close ticket
- Change to Bar department, make a sale and select the open table to merge tickets and add drinks to Restaurant ticket.
- Change to Restaurant department, select open ticket and settle
- Check WPR - Bar sales & income are too high as second Restaurant ticket has been added to Bar sales & income.
-
Hello John while uploading test setup I had little time so I gave little instruction about he solution.
First of all we need to dedicate a terminal to a department because SambaPOS needs to know the base department. We can do it by adding a Bar Terminal and choosing bar department for this terminal. We'll do the same for restaurant terminal and update local settings. For this reason we can't test it on a singe terminal by only switching users. We need to change terminal department too.
Let's create an example on your data:
I logged in with 1234 and selected POS01 terminal from local settings. To simulate Restaurant terminal I'll select Restaurant for POS01 terminal.
I'll sell 1 Garlic (5,50) to R01 table. WPR seem fine.
I'll switch to bar menu, open R01 table and sell 1 Jug Heavy (13,80) The ticket total is 19,30
Now WPR shows 19,30 for restaurant sale since all items sold from restaurant. But a new section appeared under sales section which shows Cross Sales. That shows 5,50 of 19,30 is Restaurant sale but 13,80 of it is Bar Sale. If Customer pays on restaurant we should pass 13,80 to Bar. Whatever user does sales on this terminal all sales will go to restaurant department on top section but cross sales from other departments will listed under bold Restaurant title.. User department is only effective for the active screen when we click on "POS" button. Settle ticket and see how WPR displays it.
Now change terminal department to bar and logoff login again. (or we can set P02 terminal to bar and start two sambapos with different local settings) Now sell one "Jug Lite (12,50)" and settle it with cash. Now we sold 31,80. Things sold from restaurant is 19,30 and things sold from Bar is 12,50. But cross sales reports shows 13,80 of 19,30 is cross sale so restaurant will pay 13,80 to bar department...
Now we'll try something different. Switch back to restaurant department and sell one Jug Post($11,00) to R02 table. Now Restaurant Sales increased to 30,30 and the amount we need to pay to Bar increased to $24.80. Is it true? It is true if customer pays amount at bar but if he walks away to bar and orders one more Jug Post and pay everything at bar what will happen? Lets try. We need to switch terminal to bar and login again.
I this case adding items to a restaurant table from bar is not logical. So we'll move table to F01 for simulating a seat change. (I'll disallow settlement when there is a terminal department and user tries to settle ticket from another department) You'll see Restaurant cross sale amount decreased from $24.80 to $13,80 back since customer paid bar item at bar. This is the key point because you won't be able find $13,80 by comparing sale and income amounts if there are three departments. For this reason cross sale part is useful.
Now I'll finish my implementation and create another test release.
-
I uploaded final solution. Let me know if something not working as expected.
-
Lets do a controlled example with my database.
- Start a new work period.
- Login as Restaurant User (9999)
- Make a Restaurant department sale and settle
- Login as Bar User (1111)
- Make a Bar department sale and settle
- Check that WPR is showing correct totals - Sales & Incomes should match in each department.
- Login as Restaurant User (9999)
- Make a Restaurant sale and close ticket
- Change to Bar department, make a sale and select the open table to merge tickets and add drinks to Restaurant ticket.
- Change to Restaurant department, select open ticket and settle
- Check WPR - Bar sales & income are too high as second Restaurant ticket has been added to Bar sales & income.
Try my example, and make substantial purchases in the Restaurant.
You will see that Bar sales & income are too high for the transactions.
-
OK. I set restaurant department for POS01 terminal and selected it from Local Settings. Logged out...
* Logged with 9999
* Sold 1 Garlic (5,5) and settled it.
* Logged with 1111
* Sold 1 Jug Heavy (13,80)
* Logged with 9999
* Sold 1 more Garlic (5,5) to R01 table, left it open.
* Changed to bar Selected Jug Heavy (13,80), Merged it with restaurant table, clicked open table, clicked R10, added one more Jug Heavy (13,80) Closed ticket, switched back to restaurant, clicked to table again and settled it.
Now we sold 3 Jug Heavy and 2 Garlic. Total should be 41,4 + 11 = 52,4. Let's see WPR. I logged out and logged in with 1234 pin.
This is what I'm getting :
(http://i.imgur.com/CACCO.jpg)
-
How are you setting a department to a terminal? It's the user that sets the department.
-
To be able to detect cross sales we need to know both the active department and the physical department. In your example "restaurant" is the physical (fixed) department and we switched the active department between restaurant and bar. We can't determine physical department from user login because it breaks "single user works on multiple departments" case. So we are reading physical department from terminal - if set...
-
Emre,
I found where to set the terminal department - Manage -> Settings -> Terminals
The cross sales totals needs to be better designed, because most users will have problems understanding it as it lists actual sales and what is owed to the other department - which both added equals the sales total above it and equals the income. Technically you have two sales figures that don't equal each other, but then you have sales equaling income, which makes sales redundant.
As it is with 2.87, Cross Selling works correctly with the WPR, and it can be managed, but this is a supervisor only report - most general users will make errors reading the WPR.
Maybe we need
Restaurant Income $xx.xx
Restaurant Gross Sales $xx.xx
- Restaurant Sales $x.xx
- Bar Cross Sales $x.xx
Bar Income $xx.xx
Bar Gross Sales $xx.xx
- Bar Sales $x.xx
- Restaurant Cross Sales $x.xx
But gross sales still equals income, and therefore makes gross sales redundant.
But that was something that I never experienced before. Generally our real life users have a single menu for all departments but different seat plans. Some of them have different menus too but they have cross selling items in both menus. Every drink orders goes to bar printer but this is not something considered as cross sale. If we sell a beer from bar it is a bar sale and if we sell a beer from restaurant it is a restaurant sale.
This is where my situation is vastly different from yours. Because you do not cross sell between departments, but rather duplicate items in both, you don't actually cross sell and therefore your sales will equal your income.
When we cross sell we are actually selling someone else's stock and therefore owe them money for those products.
In saying that I still believe that Sales should be the departments actual sales not including cross sell products, the under Cross Sales we should have
Restaurant owes Bar $xx.xx
When you add Cross Sales to Sales you get Restaurant Income (cash in drawer)
If you do not cross sell like we do, then Sales will always equal Income and you will not see Cross Sales totals.
It's not that your logical is wrong (it's more likely my explanations aren't that good), it's just different to our way of doing business. Therefore our way of reading the WPR is different.
It's like if you outsource a part of a project to a specialist programmer. You don't include that cost in your own internal costs, but list it as 3rd party contractor, which is added to your costs to get the total project cost.
-
Maybe we need
Restaurant Income $xx.xx
Restaurant Gross Sales $xx.xx
- Restaurant Sales $x.xx
- Bar Cross Sales $x.xx
Bar Income $xx.xx
Bar Gross Sales $xx.xx
- Bar Sales $x.xx
- Restaurant Cross Sales $x.xx
Yes that's great.
Most probably I've used reporting terms wrong and that creates a confusion between us.
What I mean with income is payment totals. Yes at the end of the day Income will be equal to sales but if we create a snapshot report in the middle of the day Income totals will not contain non-paid sales and they will be different. So I think Income value is redundant here. Income amounts can stay on it's current location and we can use Gross Sales instead. I liked how you organized amounts. When we do that, top sales section will become redundant too and we can hide it if we display cross sales report. So we can name Cross Sales report as Sales report :) Hmm.. I think it will be same as the current sales report but it will contain department specific sales and cross sales and in detail.
Side note: Matching income and sales numbers is important for me because we calculate them from different sources by different methods and that match is a kind of data integrity proof. At the end of a day detailed item sales total, WPR sales total and income total should always match. This is the most easy way of testing a restaurant application if it does calculations correct or not. Believe me there are lots of programs even they can't match these three numbers because of discounts, taxes or similar detailed calculations.
-
This is my final result. To be able to show the need for cross sales in detail I've inserted one more department. That shows Restaurant will pay 41.40 and Coffee Shop will pay 3.40 to Bar department. That looks fine to me.. What do you think?
(http://i.imgur.com/24GsB.jpg)
-
That's great. Layout is easy to read. Already showed a manager and he found it simple to read.
Great work Emre.
-
Emre,
With V2.87, I have noticed that I can not settle a ticket from another department unless it also has items from your own department, or for the restaurant it has to be assign a table number then they can settle a Bar only ticket (ie no food).
Is this what you expected due to setting a department for a terminal?
I understand that you must settle from within your own department, but if someone walks to the bar and wants to pay for their food and they have no drinks, then they have to pay in the Restaurant as the table will not show up in the Bar terminal.
Update - If you are on a Restaurant terminal and order drinks from the Bar menu and close the ticket without selecting a table, the ticket is only visible on the Restaurant menu from either terminal and can not be settled from the Bar terminal.
Workaround is to (on the Bar terminal)
- Click Restaurant menu
- Close table screen
- Select ticket
- Click Select a Table
- Switch to Bar menu
- Select Table
- Then you can settle ticket
If the Restaurant has a ticket assigned to a Table, the Bar terminal can not settle the Table unless (on the Bar terminal)
- Click Restaurant menu
- Select Table
- Click Change Table
- Select same Table
- Switch to Bar menu
- Select Table
- Then you can settle ticket
Realistically the tickets and Tables should be visible from any terminal and you should be able to settle from any terminal.
-
John, Bar terminal should be able to settle any ticket from "All Tickets" button or by finding a ticket via find ticket button. Settle button is disabled only if the active department is different from the terminal department. Restaurant terminal shouldn't create & settle tickets directly from bar screen. I thought we need that rule because if restaurant user creates and settles bar tickets without assigning it to a table, that order will go to bar printer and bar user won't understand where it comes from since there is no table information.
I think on your examples the terminal department is still restaurant department or something might be half implemented on your version. I'll release final 2.87 soon. Maybe trying these cases with latest release will be better.
-
Settlement should only happen in the department that the terminal belongs to, but they need to be able to settle any tickets from any department.
V2.86 handled this OK (from memory - I may need to go back and check)
Found that if I have Fast Food set for the Bar department, then all Tables are visible and can be settled.
If I have no department type set, then only tickets that the Bar has added items to are visible.
Update - If you have tickets created on Bar terminal and assigned to a Table, then the Restaurant adds food. If you close the Tables screen, the ticket will not show - it only shows tables that started as a Restaurant ticket.
-
I'm sure I'm really understanding something wrong about your setup. I couldn't understand how bar terminal creates a table ticket.. Is it a restaurant customer or bar customer? If he is sitting at restaurant, how he gives his orders at bar? If he is sitting at bar why he orders to a restaurant table?
If a bar customer moves to a restaurant table without paying his previous bar ticket, restaurant user will switch to bar screen, find his ticket, move it to a table and go on... Restaurant user will do that because restaurant user knows where customer sits. If he goes back to bar without paying to restaurant, this time bar user will click all tickets, find his table ticket and do what needed...
That settlement issue will only prevent restaurant users from settling bar tickets before moving it to a table. I don't know why bar customers wants to pay at restaurant without sitting there?
Update: If I display all tickets to all departments some of our users will complain because of seeing unpaid delivery tickets next to table tickets. Should we really display all open tickets to all departments? Maybe you are dealing with a different issue that we are not talking about. Why you need to see all tickets when there is no department type selected? Where are you using it?
-
I think I understood your problem. There is a little trick that might be useful for bar terminal. You can close tickets at fast food screen without payments by tagging them with a ticket tag. Create a ticket tag button named "Seat", add a single tag value as "Seat" and assign it to "Bar" department. After restart you'll see the "Seat" button at fast food screen. If bar user needs to leave ticket open he'll click at "Seat" button and the "Close" button will appear :) Or you can configure tag for automatically closing ticket.
Clicking Seat button when there is no open ticket will display all tickets tagged as "Seat" too.
-
I'm sure I'm really understanding something wrong about your setup. I couldn't understand how bar terminal creates a table ticket.. Is it a restaurant customer or bar customer? If he is sitting at restaurant, how he gives his orders at bar? If he is sitting at bar why he orders to a restaurant table?
Customer may go to the Bar and get drinks after they have been seated in the Restaurant but before they have ordered.
If a bar customer moves to a restaurant table without paying his previous bar ticket, restaurant user will switch to bar screen, find his ticket, move it to a table and go on... Restaurant user will do that because restaurant user knows where customer sits. If he goes back to bar without paying to restaurant, this time bar user will click all tickets, find his table ticket and do what needed...
All Tickets is only available for Fast Food department type - which is fine but you can't close a ticket in this type, it has to be assigned to a table or customer. This will probably be the way it will run as we done want open tickets without a table or customer assigned.
That settlement issue will only prevent restaurant users from settling bar tickets before moving it to a table. I don't know why bar customers wants to pay at restaurant without sitting there?
During restaurant hours, the Bar can not serve coffee, tea or snacks, therefore they must order from the Restaurant, and they may pay for all drinks and sit in the lounge. Some customers will be allowed to run tabs, and this is where flexibility comes in.
Maybe you are dealing with a different issue that we are not talking about. Why you need to see all tickets when there is no department type selected? Where are you using it?
No department type allows closing of tickets which is handy for 2 or 3 staff using one terminal as tickets can be suspended so other sales can be processed, then the suspended ticket is selected and sale completed.
Update: If I display all tickets to all departments some of our users will complain because of seeing unpaid delivery tickets next to table tickets.
Yes, and this is where I needed to know if it was by design or not. And it is - so that's OK.
-
I think I understood your problem. There is a little trick that might be useful for bar terminal. You can close tickets at fast food screen without payments by tagging them with a ticket tag. Create a ticket tag button named "Seat", add a single tag value as "Seat" and assign it to "Bar" department. After restart you'll see the "Seat" button at fast food screen. If bar user needs to leave ticket open he'll click at "Seat" button and the "Close" button will appear :) Or you can configure tag for automatically closing ticket.
Clicking Seat button when there is no open ticket will display all tickets tagged as "Seat" too.
And there is the workaround :)
Thank you.
-
John I've noticed restaurant user won't be able to see tagged tickets by switching to bar menu and clicking 'Seat' button. He still can use "All Tickets" button but I'll fix that too.
-
I've released 2.88.
Note: On the first message of this topic we talked about print jobs. I fine tuned map selection by order department too. It will work as expected now. Thanks.
-
Emre,
Works great - exactly what we need, and the settlement restrictions are working as expected.
The only thing I have found is in the WPR that the Department Totals heading is left justified on the screen and when its printed its right justified. See attached.
Note: On the first message of this topic we talked about print jobs. I fine tuned map selection by order department too. It will work as expected now. Thanks.
This topic did end up long and drawn out, and finished in a different subject, but look at what was achieved. SambaPOS now supports franchises within shops and documents all cross sales.
Awesome feature.
Thank you Emre.
-
OK, so now back to the original problem.
When a Restaurant terminal orders Bar products, we need a ticket to print out at the Bar with the order.
Solution is to have two order tickets and two print jobs.
- Kitchen Order Template & Kitchen Order Print Job
- Bar Order Template & Bar Order Print Job
All terminals will have Kitchen Order Print Job.
Only Restaurant terminals will have Bar Order Print Job.
-
A single printjob should work too. First map line for Bar department and a second one for the rest.
-
Emre,
Works great - exactly what we need, and the settlement restrictions are working as expected.
The only thing I have found is in the WPR that the Department Totals heading is left justified on the screen and when its printed its right justified. See attached.
Note: On the first message of this topic we talked about print jobs. I fine tuned map selection by order department too. It will work as expected now. Thanks.
This topic did end up long and drawn out, and finished in a different subject, but look at what was achieved. SambaPOS now supports franchises within shops and documents all cross sales.
Awesome feature.
Thank you Emre.
John, In software development good communication is everything. That conversation might ended up with a result of nothing. Mostly your persistence and patience for delivering the information did it. From technical side that was not a big implementation but I think we handled an interesting case.
While evaluating a software people focuses on features and if there are lots of buttons, menus or settings they thinks that software is good. Features by themselves have no value. The important thing is what cases that software can handle. There are lots of software filled with awesome features but %80 of it implemented without thinking the full case and when user tries to use these features together in real life it simply doesn't work as expected.
Lots of development teams does this mistake. Thinking about nice features is simple but generally it ends with no real value. Thinking about cases is harder and needs more time but when people contributes like John did, it generates great value. Technically we only added a department selection feature for terminals and added about 40-50 lines of code. Any developer can do that. Understanding the need is our real job. I hope every restaurant owners focuses on their cases instead of the features they think they'll need.
John thank you very much again for investing your time for that great result.
-
A single printjob should work too. First map line for Bar department and a second one for the rest.
Emre,
That's what I thought, but the department in the printer mapping is the active department, not the physical department. On a Restaurant terminal, to print a Bar order from the Bar menu the department in printer mapping is Bar - which means all Bar terminals will print Bar orders too.
I actually typed all this up ready to post, but decided not to as separate print jobs fixed the problem.
If you change the department print mapping to physical, then you need to list all of the product groups to print - too messy.
The other option is to add Terminal Name to the printer mapping which will replace the need for two print jobs.
What we have now is two simple print jobs that work.
-
Last note: It might seem weird at first but I intentionally right aligned all sub titles over numbers for easier reading.
-
That makes sense. It just looks out of place compared to the rest of the layout.
Maybe a blank line above it may look better.
-
A single printjob should work too. First map line for Bar department and a second one for the rest.
Emre,
That's what I thought, but the department in the printer mapping is the active department, not the physical department. On a Restaurant terminal, to print a Bar order from the Bar menu the department in printer mapping is Bar - which means all Bar terminals will print Bar orders too.
...
hmm... doesn't direct bar orders prints? Yes, not needed :)
Since we'll create a separate terminal setting for bar, alternatively we can remove print job from bar terminal.
-
That makes sense. It just looks out of place compared to the rest of the layout.
Maybe a blank line above it may look better.
I tried it before but adding blank line creates longer prints and people said it wastes paper :) It will look fine on thermal print. If not we can think different solutions.
-
Have you ever printed a 'Z' tape from a cash register ??? Some are 2mtrs long.
One extra line on a printout 60+ lines long is kinda trivial. I will take a nice clean layout over an inch of wasted paper any day.
-
John, In software development good communication is everything. That conversation might ended up with a result of nothing. Mostly your persistence and patience for delivering the information did it. From technical side that was not a big implementation but I think we handled an interesting case.
While evaluating a software people focuses on features and if there are lots of buttons, menus or settings they thinks that software is good. Features by themselves have no value. The important thing is what cases that software can handle. There are lots of software filled with awesome features but %80 of it implemented without thinking the full case and when user tries to use these features together in real life it simply doesn't work as expected.
Lots of development teams does this mistake. Thinking about nice features is simple but generally it ends with no real value. Thinking about cases is harder and needs more time but when people contributes like John did, it generates great value. Technically we only added a department selection feature for terminals and added about 40-50 lines of code. Any developer can do that. Understanding the need is our real job. I hope every restaurant owners focuses on their cases instead of the features they think they'll need.
John thank you very much again for investing your time for that great result.
I have no problems in investing my time into the SambaPOS project, because I believe in the project.
-
Emre,
We have put the system into production, and have found a bug in the WPR around the Cash & Credit Card sales between departments.
The Restaurant was the only one to receive payment by Credit Card, yet this was added to the Bar Income. And there was $30.30 in cash mis-allocated to the Bar.
Please see the attached WPR. I can supply the DB if needed.
-
Yes, I'll be happy to investigate DB..
Update:I think I found the problem. When a bar customer wants to pay with credit card does Restaurant department settles bar tickets? As I see in code that can only happen when a bar ticket settled with credit card. I thought I avoided that by disabling Settle button but I think I forgot disabling fast payment buttons. If credit card payments can only made through restaurant department it looks like we should support cross payments too. But If we support that another problem arises because we should display this ticket as a restaurant cross sale because it paid at restaurant. Hmm.
-
Emre,
The Restaurant has taken orders, then the customers have gone to the Bar and gotten drinks which were added to the Table ticket. Then at the end of the meal the customer has paid for all at the Restaurant with Credit Card.
Update:I think I found the problem. When a bar customer wants to pay with credit card does Restaurant department settles bar tickets?
Not normally, but yes they can.
As I see in code that can only happen when a bar ticket settled with credit card. I thought I avoided that by disabling Settle button but I think I forgot disabling fast payment buttons.
You can not settle a ticket outside your own terminal department. ie, For the Bar to settle a Restaurant ticket, they need to settle in the Bar department on a Bar terminal. All payment buttons will be disabled if they try to settle using the Restaurant department on a Bar terminal.
If credit card payments can only made through restaurant department it looks like we should support cross payments too. But If we support that another problem arises because we should display this ticket as a restaurant cross sale because it paid at restaurant. Hmm.
You are correct. A cross sale technically happens when one department receives money on behalf of another department.
The cross sales are working great for the items, its just the payment side that needs fixing.
-
The Restaurant has taken orders, then the customers have gone to the Bar and gotten drinks which were added to the Table ticket. Then at the end of the meal the customer has paid for all at the Restaurant with Credit Card.
That case does not creates that problem but after investigating it further I found the problem.
1. Bar terminal creates a ticket
2. Clicks "Select Table" and moves that ticket to a table. At that point this is still a bar ticket because user did it while bar terminal is active. Assigning it to a table does not change ticket department because this is still a bar sale and at that point we don't consider it as a cross sale from restaurant to bar.
3. Restaurant user settles that bar ticket with credit card. Since he accessed it from restaurant department screen he could settle that.
The cross sales are working great for the items, its just the payment side that needs fixing.
What we should do is changing ticket department to restaurant and display it as a cross sale. That will fix that case. (In fact I don't call it a bug fix, I call it cross payment feature :) ) By disabling settle buttons I tried disabling cross payments but that case was something I didn't noticed. If it is the case, cross sale numbers should be wrong too.
Changing ticket department will solve that case without disabling settle buttons but permitting it creates other problems. Since we permit half payments and if customer drinks a $10 beer and pays $5 cash at bar and $5 credit card at restaurant, we'll show that beer sale as restaurant cross sale and they won't be able to match numbers. Our current database scheme won't permit splitting a beer sale between departments by payment amounts. So we'll assume users won't do that or disable some features.
Maybe your user does not do what I found and another case we didn't noticed created that problem. We should find the reason of the problem to be able to fix it.
-
The cross sales are working great for the items, its just the payment side that needs fixing.
What we should do is changing ticket department to restaurant and display it as a cross sale. That will fix that case. (In fact I don't call it a bug fix, I call it cross payment feature :) ) By disabling settle buttons I tried disabling cross payments but that case was something I didn't noticed. If it is the case cross sale numbers should be wrong too.
Cross Sale numbers were correct. Restaurant started the ticket, the Bar added to the ticket, then the Restaurant (in some cases) added more items and the Restaurant took payment at the end.
Changing ticket department will solve that case without disabling settle buttons but permitting it creates other problems. Since we permit half payments and if customer drinks a $10 beer and pays $5 cash at bar and $5 credit card at restaurant, we'll show that beer sale as restaurant cross sale and they won't be able to match numbers. Our current database scheme won't permit splitting a beer sale between departments by payment amounts. So we'll assume users won't do that or disable some features.
There will never be part payments across departments for a single ticket. If that is needed, then the items would be moved to a new ticket and then paid. People here don't expect to run a tab, and pay at each department - they want to pay for the whole ticket at one department.
Maybe your user does not do what I found and another case we didn't noticed created that problem. We should find the reason of the problem to be able to fix it.
Summed up - all departments added to a ticket, then only one department took the money.
-
Am I understanding it wrong? Restaurant user processed credit card payments but WPR showing these CC totals under bar department. The reason of that problem is :
Restaurant started the ticket, the Bar added to the ticket, then the Restaurant (in some cases) added more items and the Restaurant took payment at the end.
Does your test setup produces that error when you do that? I've tested lots of different uses but I didn't noticed an error other than I described on my previous post.
-
OK. It won't fix old data but if you can reproduce that error you can test if it fixes it or not.
http://code.google.com/p/sambapos/downloads/detail?name=SambaSetup288c.exe (http://code.google.com/p/sambapos/downloads/detail?name=SambaSetup288c.exe)
-
Thanks Emre. We're are in the middle of moving house. I have started testing if I can reproduce the scenario before I update to 2.88c.
-
Update - I can reproduce the problem with payment allocation, and have found that it is to do with merging tickets.
If you have an active Restaurant table and add Bar items by selecting the table first then the items - all OK at payment time.
If you select the items and then select the table, you get the ticket merged message, then when you settle, the payment is allocated to the Bar.
I reproduced this by
Start new Work Period
Make 1x cash Bar sale
Take Restaurant order and assign to a Table
Select Bar items and then select the Restaurant Table (Merged Msg)
Settle at Restaurant.
Check WPR.
I will check with 2.88c shortly.
Update - Confirmed fix in 2.88c - after short testing, I was unable to reproduce the issue. All payments allocated correctly.
Good work Emre.
-
Emre,
Is it possible to get the Account Balance total (from Incomes) into the separate Department Income totals aswell?
-
Emre,
Is it possible to get the Account Balance total (from Incomes) into the separate Department Income totals aswell?
I have to check implementation but I think it is possible.
-
John, while checking it I realized that was something missed.
http://code.google.com/p/sambapos/downloads/detail?name=SambaSetup288d.exe (http://code.google.com/p/sambapos/downloads/detail?name=SambaSetup288d.exe)
If everything works fine I'll refresh translations and release 2.89 tomorrow.
Thanks.
-
Emre,
It's been a hectic day with work and moving house. I haven't had a chance to test the new version yet. I'll look at it in the morning when I'm more awake.
The pilot site has been working well since installed last Saturday. The staff have accepted SambaPOS with open arms, and we even used an iPad for table service at a function and it was a great success. The staff loved that the table service tickets would print at the bar so they could gather the drinks and deliver to the tables in a fast and smooth manner.
Even the guests commented on the high level of service and the "High Tech" approach to the table service which usually (at most venues) is handled in a poor manner.
The Restaurant owner couldn't be happier, and he loves the simplicity of the system. He has used other systems in the past, some good and some not so good. He now wants to use an iPad for table service like they used in the function room.
Overall a great success.
In a little over 8 weeks, we have made some amazing updates to SambaPOS and have put it thru some tough scenarios with great results.
Thank you to Emre and the SambaPOS Team.
-
Ok, still not that awake :) , but have tested.
Perfect thank you.
-
Emre,
...
In a little over 8 weeks, we have made some amazing updates to SambaPOS and have put it thru some tough scenarios with great results.
Thank you to Emre and the SambaPOS Team.
Great news John. I read your post 3 times and nothing could make me happier today. Yes these updates was great but not technically. The great thing was your experience on that subject. We have lots of great things to do in the future. Thank you.