A local pub is looking to forgo it’s food business and lease the space to another company; both companies would then operate within the same premises and ‘co-operate’ and hopefully provide a seamless customer experience with the bar handling all beverages and restaurant handling all food.
Each company maintains separate finances and sales tax liabilities.
I understand that report and product design can separate the two within one system. Is there a way to separate payment processing into two separate instances?
The methods I’ve considered to resolve this issue when operating intermingled are:
Two cash registers and payment processing systems with final customer bill showing a ‘Bar’ and ‘Food’ distinction/total; with the cashier placing proper cash in proper Till and/or swiping customers card to two separate card readers producing two receipts for signature [could be an issue for customers who are charged per transaction ie. pre-paid credit cards]. This method would reply on full reporting and cashier’s skill/training.
One register and single payment processing system with ‘payouts’ from CompanyA to CompanyB [cash daily & check/charge weekly]. This method seems like it could cause accounting/tax nightmares and possible contention between the companies.
Interrupt the ‘seamless’ customer experience by requiring customer to pay for food at order. I’m thinking paying in advance or separately for food would decrease ‘add-on’ sales from initial order.
The flow of operation is that a bartender/server takes orders and delivers food with the kitchen only responsible for production of menu items [with the exception of delivery items where bottled/canned soft drinks are sold rather than poured products].
With a lot of modifications it could be achieved but since you cant limit reports per User/Department they would be able to look into each other revenue.
If it was up to me I would just run it off the same server but different SQL instance/database.
No, you will have a hard time accurately splitting payments where a ticket would contain sales from both parties.
Payments are ticket level and not directly linked to products.
Payment types shouldn’t matter too much beyond banking fees which I’d sugest the two parties come to an agreement. Most likly food will have a higher % of card from experiance with drinks having a greater proportion of cash payments.
Your right, 2 card machines etc is bad route for customer.
Your best route I think is sort reporting for tax which is one major thing.
Another option might be for say food party to receive money from customers and drinks party invoice the food party for sales of drinks, this then gives the food co a deduction against the sales that wernt theirs.
And likely they would negotiate some deductions etc like an xy account for card processing fees etc.
Just get reports correct and will be ok.
Since its within ticket, ticket type and department are probably not options.
So either product group code or my favorite for anything unusual product related is custom product tags. I use these for department and accounting code for my PMS intergrations, courses, a per product printing setup that doesn’t use mapping, open price option, tax options relating to PMS intergration with current split vat rates in UK in responce to covid, offers products are applicable in etc etc etc.
And you can report on custom tags pretty easily.
Just dont expect like many have before to be able to accurately report payment types based on products as there is no direct link, ie 50% cash 50% card of a ticket 75% food… gets complex pretty quick.
And isn’t a option you’ll likely find elsewhere since rarely a real reason to know that detail, people say for tax man but tax man doesn’t charge different rate on different payment types etc. They care about declared sales as that’s what generates the tax figures.