Print Jobs Based on Users

[JohnS]

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.

[JohnS]

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.

[emre]

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.

[emre]

I uploaded final solution. Let me know if something not working as expected.

[JohnS]

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.

[emre]

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 :

[JohnS]

How are you setting a department to a terminal? It's the user that sets the department.

[emre]

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

[JohnS]

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.

[emre]

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.

[emre]

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?

[JohnS]

That's great. Layout is easy to read. Already showed a manager and he found it simple to read.

Great work Emre.

[JohnS]

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.

[emre]

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.

[JohnS]

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.