You cannot directly correlate between products and payments.
It is not logical, products are order level and payments are ticket level.
If a ticket has an omlette say 8 and a milk say 2 and is paid 5 cash and 5 card how do you intend to work that out?
omlete is 5 cash 3 card and milk is 2 card?
Do you understand what Im getting at?
you do not allocate payments to orders you set them to ticket.
Only remote possibility would be to prevent possibility of multiple payments per ticket and report on a ticket level by payment however this to me is counter productive and you will most likely be on your own in finding a solution.
That makes sense. I honestly don’t know why I didn’t see it that way. Banging my head against a wall trying to fit a square peg in a round hole.
Well the situation I’m in, multiple payments per ticket is pretty much non-existent.
I’m deploying Samba for a customer and their set up is basically 3 departments with each department having a specific menu. The cashier should be able to populate a single ticket with any product from the 3 menus.
The owners want to be able to track sales per department i.e. sales per menu.
I think you are going to wrong direction. You better explain in details incl what type of business, how your business flows. So, we can see overall picture and may be end up with better idea.
I never seen owner of business want to know how much this item pay in cash and card. They just want to know how much is the sales a day and maybe what the most popular items. Which items should be removed? No sales mean loss. Also, they want to know how much sales in cash and card per day, not per item.
Maybe over simplistic but why are you conserned about cash split?
What I saying is if for a minute you ignore card processing charges at end of day what difference does it make if paid cash or card?
Ignoring card payment charges cash or card its money at end of day.
I put it like that as you say to split cash NOT to work out card charges, so if it who gets the money it’s erelivent is cash or card as sale=payment…
Does that make sence?
I enfisise that as you said split cash not card suggesting your more worried about who gets money and less who covers card processing charges…
If it were me I would push for an agreement that you base takings on sales values which are directly link able to orders and you divide card fees by sales %per department.
If each department has a similar average transaction total it’s more likely card spit is more proportional to sales that is you had a cafe and a electronics store as the larger ave transaction value on electronics I put a likely hood of more card trans vs cafe with heigher cash payment but if similar it will likely average out fairly evenly.
It has a Restaurant, a Cafe and a “Fireplace” (food is cooked over an open fire). Each have a different menu with different products. These are the 3 departments I created.
Guests can order from any of the 3 menus. So for example, a guest may order a drink from the cafe and a meal from the restaurant.
All 3 need to account for sales of their products at the end of the day. The kicker here is that there is only one POS that handles all payments for food so they want to be able to split payments at the end of the day for banking to their separate bank accounts.
The owner only really cares about the Cafe and “Fireplace” and likes to know how much they are making.
But as @JTRTech is saying, it’s probably best for everyone if we kept it simple. So I’m just going to ignore card charges.
Do you guys think having a report that shows total sales by department and then sales by payment type be sufficient for them to be able to balance up and deposit the correct amounts to the correct accounts?
I still don’t understand the need for payment split before banking since you still haven’t shown any consern about bank charges…
I mean if you only have one epos and one card machine all card payments will go into a single bank account anyway…
I think typical process for a setup like yours would be to have a ‘control account’ that everything gets banked into and then you transfer the apropeate amounts from that to each department account.
As I said before the only way I can see this happening of you insist on reporting as you asked is to either disable multiple payments per ticket so you can report orders based on their group and their ticket payment type. If multiple payments with this method you will get duplicate tickets included do the seperate on of orders and payments.
Other option would be a more complex system like I mentioned above where on payment you ‘allocate’ that payment over orders pragmatically looping through orders used parts of the payment and maybe using an order state to record on the product what payment type is allocated.
But I still think your going about it the wrong way.