V5 - Bar Tab Setup


#41

The main expected issue is pre-order feature did not implemented to handle later pay cases. It implemented to handle pre-order case.

Using preorder tickets will overcomplicate the workflow. For example when customer asks how much he should pay you should list 3 unpaid tickets and say $35.55 due. He’ll give $30.00 and want to pay $5.55 later. You’ll convert these tickets to real tickets and distribute $30.00 payment properly. Later you’ll have lots of partly paid tickets. This is just an example. When you use pre-order tickets for that you’ll ask a lot of features that already implemented.


#42

Ok, I understand your point there.
Just the preorder type setup seems to best match what they would like to be able to do.


#43

What they would like to be able to do?


#44

To do what pre-order does LOL
Have a ticket run for several days…
When you said issues I was thinking more like technical issues or something breaking.


#45

So how do they know which ticket to pull up when customer comes back later?


#46

lol sounds like a trap question.

@JTRTech …Don’t say “from customer name”


#47

It would be using customer entities,
Local has an entity, obviously selected on first starting tab, customers names then displayed on customer tickets entity screen.
Customer entities are all fairly descript with full name/nickname ie they will know who is who, only limited number of local allowed to ‘carry over’ a tab.
At the minute they ring in each day and at end of day boss prints and voids, so in essence a paper based account.
When the customer pays he rings everything back in.

With V5 i was intending to do a customer entity grid like ive seen others do so that customer tickets will show balance also so he can easily see who owes what.
A customer account will mean a separate screen for ‘carried’ tabs and a diferent workflow for paying.
Ideally the preorder options does what we wants which is to run a ticket over work periods.
He can see which days drinks were had from the order’ title’ bars with time and date etc and tab can be easily printed and paid within the existing customer entity tickets screen.

I understand it is what accounts are made for but as he is not tech/accounts savey be ideally just wants a simple long running ticket. He isnt worries about part payment, he makes them pay in full LOL
If he did want to part pay I would tell him his only option would be to select orders totaling close to amount and move to new ticket and pay that one.


#48

You can setup customer payments to accounts through tickets. So you pull up ticket which was paid with customer account and press a command button to pay it off. The automation would correct the accounts. You don’t have to use accounting to make customer account payments.

You could even create a single screen for customer entities and show their balance on the entity button. Clicking it or a button to pay it down.

There are many ways to make it very simple much more simple than keeping tickets alive.

Just because you use accounts does not mean you have to go into accounts to make transactions. All of that can be automated how you like.


#49

Fair enough, will have a play and see what I can do. :slight_smile: thanks


#50

Oke, I will try to explain my situation.
A customer account is for me special (regular client) or a client who pay later by bank for example or keep a bill open for a week. (no partial payments)
I need to keep the ticket open in the customer account section, and be able cash later the money.
On the work period it should be mentioned, but not as credit / income as we did not receive the money yet.
I should be able to close the work period by having the debts transferred to the customer account or a customer account should be excluded from the work period account.
For example, our second outlet at a Hotel we manage, guest order a beer on there room number. We print a bill and the guest signs the debts. This amount will be transferred to the Customer Bill (the Hotel in this case) and paid monthly with proof of the printed and signed tickets.
Hope this clears up the request a little.


#51

You cannot keep a Ticket open and still close the Workperiod. You must Settle all Tickets by some means. In your case, you would settle the Ticket to the Customer or Room Account. This closes the Ticket, so you can close the Workperiod.

The V4 Workperiod Report will show this as a Sale, because “Sale” is an Account, and Settling a Ticket places funds into the “Sale” Account. But your Tender Accounts (i.e. Cash, Credit Card) will not reflect this value, which should be what you want.

In order to pay a Customer or Room Account, you will need to create Transaction Documents that handle payment of the Account via preferred methods, such as Cash or Credit Card. These Documents can appear as buttons on an Account Screen that contains Customer or Room Accounts, or both. You choose an Account, select Account Details, and it will reveal all charges. You can select a transaction, and click Find Ticket to bring up the Ticket for viewing or printing. You can also click one of your Document buttons to pay off the Account.


#52

Hi @QMcKay, yes this is what I mean, I will get this function implemented once I have some time.


#53

@Jesse
Quick one if I can,
Have potential of a big contract to instal/manage pos system for small chain of hotels.
My query on the subject of this topic would how would you handle room accounts/bills?
Obviously they will need to be carried over days, they are not pre-orders, but would not want to use accounts as obviously after a year you would have thousands of accounts for all the guests that have stayed over the year…
Any suggestions or would preorder be more suitable for this situation?
Thinking about implementation thee would probably be room entities as main entity type and although this would relieve the number of accounts if they are posted to room accounts there would be a limited number but think this could get troublesome as there would then be in essence many people going through one account over time.
My preference would be to use room entities as a form of ‘posing items to the bill’, and potentially use wither customer entities as a secondary entity in order to populate bill details (address etc).

I would not be attempting to use samba as a form of reservations as think that is asking too much of it to be honest however it should be easily usable as a pos/billing software.

Preorder enabled bills would be the solution which makes sence to me but would love to hear your opinion.


#54

I would probably use state logging for room entities. Checked in and checked out states. Tickets especially pre order are horrible idea.


#55

That would be a good idea but how would you handle a multi night stay?


#56

with the state logging. The entity keeps track of that. You only need tickets to ring up purchases or pay for reservations.


#57

Must have misunderstood, what do you mean by state logging?


#58

we use it for the time clock. Look up the time clock tutorials it shows examples of state logging.

Why use customer accounts… just use Room Accounts the customer has to pay the account down before they checkout so on checkout each room account would be balanced to 0 and ready for next customer.

Use State logging to track the stay over days. Use Tickets simply just to ring up anything. You can close work periods etc.


#59

@RickH I have just installed this onto a brand new database, but when I close the tab it doesn’t print off the tab receipt.

Although this is no big deal, I’m intrigued as to why this may be.

As I said its a fresh brand new install with literally just your bar tab on it…

Matt

Edit: I have also noticed that I can go over the initial £50 tab that has been put there.

Do you think maybe its a new setting thats been added to V5 that this zip doesn’t have within?


#60

Probably havent got the actions and rules for the print job or you may not have the print template

Check the print templates is there a bar tab one listed, also check actions to see of you have any that say AUTOPRINT and are related to bar tab. I use ticket states to determine what receipt prints so it could be that the ticket state isnt updated thats what the autoprint action does