Print Jobs Based on Users

[JohnS]

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?

[emre]

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?

[JohnS]

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.

[emre]

- 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?

[JohnS]

- 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.

[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.

[JohnS]

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)

[emre]

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.

[JohnS]

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.

[emre]

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.

[emre]

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

We have department selection on terminal settings for fixing department.