English Boards > Support
Print Jobs Based on Users
emre:
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.
JohnS:
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.
emre:
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.
JohnS:
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.
emre:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version