I am busy with a setup now for a dry cleaner, however the customer is very new to POS systems, and has asked me for some very complicated functions.
They have multiple departments with multiple ticket types, and multiple menu’s, as they want to see everything reported separately, however, and this is where the trouble comes in, they want to be able to ring it all up under one sale, but keep multiple tickets printing off of that single sale, as the customer and they need to keep track of it like this.
As an example, Peter comes in and has some clothes for dry cleaning, it is added under the dry cleaning department with a dry cleaning ticket and dry cleaning ticket number. Simple enough, they use the dry cleaning department. But if Peter brings in the same pants for tailoring on the same sale, they do not want to close the dry cleaning department ticket,charge him his money, and then switch over to tailoring and create an entirely new ticket for Peter, and charge him apart for the same pair of pants.
I have thought of multiple solutions and discussed them with the client, including reporting by group code and such,but this was decidedly not what she wanted. Currently I am looking at menu switching and other options, but any help would be appreciated, even if it is just a link to another topic with some explanation of how to put such a thing together.
You don’t really need different Departments or Ticket Types to be able to report things separately. You can simply choose to change the Transaction Type for an Item in a normal Ticket.
Under “normal” circumstances, the Sale Transaction is used for Items/Orders on a Ticket, but this behavior can be altered. Using the Order Added Rule, you can fire an Action for Update Order which changes the Tx Type for that Order. You can use Group Code or Custom Product Tags to determine the Tx Type to use for the Order Product. This is how something like the Gift Certificate Tutorial is set up so that it does not Report the sale of a GC under regular Sales.
This is what the Sale Transaction Tx Type looks like…
Using the GC as an example, your Tx Type might look something like the following. Notice the Account Type and Account is different. This allows for Reporting of the Account Type and/or the Account itself. You could choose to still use the “Sales Accounts” Account Type, but a different Account if you want…
I understand what you are getting at here, but will this be able to print different slips with different number generators for the different items on the transaction? They use these numbers for keeping track of what goes in and what goes out. Won’t the above method set all the items on the ticket to the same transaction type?
If they get a customer with Tailoring, Shoes and Dry Cleaning, they need a to give him four print outs, one for the shoes order (Marked S-123), one for the tailoring order (Marked T-053) and one for the dry cleaning order (Marked D-289), as well as a total slip for the entire transaction. Also these transactions are ordered in with the reservation system, and can be picked up at different times.
I have full confidence that SambaPOS can do this, but i have no idea how.
You would need to control your own number generation. You would not be able to use the Ticket Number Generators. You could Tag the Order with the Number, or set an Order State to contain the Number, or both.
No, that is the point. It only sets the Tx Type for the Order (Item); not all Orders on the Ticket.
What is printed can be controlled in a number of ways in Templates. For example, in 3 of the Templates you could print only Items that have a certain Group Code or Custom Product Tag, or Order State. In the “regular” Template, you print everything as usual.
For example, if you were to create an Order State named Order Type, and when an Item is added to the Ticket, you set that State based on the Group Code or Custom Product Tag value, to something like Dry Cleaning or Shoes or Tailoring. You might also set another State to contain the Tx Num, and you also might Tag the Order with an Order Type Tag and Tx Num Tag. Then in your Template(s), you simply filter like:
[ORDERS:Tailoring]
{QUANTITY} {NAME}
{ORDER TAGS}
[ORDER TAGS:TxNum]
{ORDER TAG NAME}
Another Template would have:
[ORDERS:Shoes]
{QUANTITY} {NAME}
{ORDER TAGS}
[ORDER TAGS:TxNum]
{ORDER TAG NAME}
etc.
That’s just one way it could be done. You can also filter Orders by Group Code, Product Tag, or Custom Product Tag.
So I would start by doing “everything” to see what works best in the end:
create a Custom Product Tag Caption for Order Type
use Batch Tag Editor to set the Order Type for each Product
create an Order State named Order Type
create an Order State named TxNum
create an Order Tag Group named Order Type, with Tags for different Order Types like Shoes, Tailoring, etc
create an Order Tag Group named TxNum, set to Free Tagging, but not Save Free Tags
create an Action for Update Program Setting using [:variables] for all parameters like [:settingName] [:settingValue] [:updateType] [:isLocal]
create an Action for Tag Order using [:variables] for the parameters
create an Action for Update Order State using [:variables] for at least the State parameters like [:stateName] [:state] [:currentState]
On Order Added Rule (to keep things “cleaner” and more easy to follow, create 3 or more Rules -1 for each of your Order Types):
check the {ITEM TAG:Order Type} in a Rule Constraint so the Rule only fires for a particular Order Type
update the proper TxNum (Global Program Setting - isLocal:False) (ie. Setting Name could be: {ITEM TAG:Order Type}_TxNum}) and the Setting Value would be the previous Value +1 like [=TN('{SETTING:{ITEM TAG:Order Type}_TxNum}') + 1]
set State for Order Type to {ITEM TAG:Order Type}
set State for TxNum (ie, {SETTING:{ITEM TAG:Order Type}_TxNum}
tag Order with Order Type using {ITEM TAG:Order Type}
tag Order with Tx Num (ie, {SETTING:{ITEM TAG:Order Type}_TxNum})
Mostly for reporting purposes, if the customer picks up his shoes 3 days earlier, the shoes should show on the sales report, and the dry cleaning should stay there until he does pick it up. I am going to make the above changes and test them and come back to you then.
So you might need more States and/or Order Tags for Pickup Date so you can filter your Reports based on that. You will already need to filter your Reports based on the other stuff like TxType (which could also be a State/Tag, though probably not necesssary) and/or Order Type.
The default “Work Period Report” is not going to suffice just due to the need to filter TxType, so you will need to create Custom Report(s) for all of this.
If you need to add or change a State or Order Tag after the Order is Submitted (ie. to set the Pickup Date), then you will also need an Update Order Action that you can use to Unlock the Order prior to making additions/changes.
That Action has a parameter named Locked which you can set to False to unlock the Order. You need the Action to change the Tx Type anyway, so you might as well use the same Action to do either or both, but make it “generic” by using a [:variable] for each of the parameters.
IIRC, that Action can also update Order States, so you might not need an Update Order State Action at all.
Ok, so we’ve been running the new system for about a week, everything is working fine but now we see there is an error in the reports, specifically, it is reporting all items run up on the day, which is correct, but we also need to see totals for only what was paid concerning those items for the day.
Doing my research here i saw that only this amount was paid for the day. How would I do this?
For example, here are a few of the filters you can use for Order Details …
OS.<state name> Order State
OSD.<state name> Order State Date
OST.<state name> Order State Time
OSV.<state name> Order State Value
OSU.<state name> Order State User
OT<tag name> Order Tag
OTN.<tag name> Order Tag Note
OTU.<tag name> Order Tag User
OTP.<tag name> Order Tag Price
MT.<tag name> Menu Item Custom Tag Value
After some testing I found that orders started in older work periods only report in those work periods even if the state is changed in this work period.
Yes, this would work, but we would still like to do a daily work period report containing this information. As I’ve said the difference can sometimes be weeks between when an item is booked in and booked out, so seeing the entire periods totals would be incorrect. Currently I can set an item to collected on this date which is the information I need to see, but it will only show on the report if i extend it to last week, which will also show everything in between.
Not sure there are constraints available for Order State Date/Time, but maybe there are.
Parsing that in SQL is a PITA unless you have SQL 2016, and even then, the date is UTC so you would need to converts it (probably not difficult in SQL).
If I were have to set up the States, I probably would have done this:
State Name: Collected State: Date/Time (maybe 0 or something like that to indicate not yet collected)
What does your Report Template look like now? Are you using {REPORT ORDER DETAILS:X} ?
