Best way to bypass paid and close on before ticket close

Anyone have a recommendation to not mark ticket as closed on 0 remaining.
My hotel setup does allot of dinner package bookings, given kitchen printer all items need ringing in but obviously don’t want the ticket to close before it should.
The reservation system uses preorder but not really ideal solution.
Struggling to think of a solution which wont interfere with normal workflow.

I do not know properly translated:smirk:

but alternatively you can save 0,01 remaining

for quick use
create automation command something like that:
Action pay ticket
Tendered amount: [={TICKET TOTAL}-0,01]

Why is preorder not a good solution for preorder bookings? Isn’t that what preorder option was designed for?

Its not for preorder, its for actual orders where orders are part of a package with accommodation.
They need to be rung in for kitchen printer but dont want ticket to be instantly closed if they hav’t had any chargeable items on the bill.

LOL you know how to keep ticket open so… what you’re asking? “Best way” depends on what you need.

It’s hard for us to understand your need. You have not really explained it yet

2 Likes

Am after suggestions on a low impact way so as not to increase work flow steps…

Think I have a plan now though…
The plan is to use an entity field for booking package which checks booking info to know if on bed and breakfast or dinner.
Using this field I intend to implement automatic price change for food orders to either 0 or thinking a new gift state of package (as integration I’ve setup posts zero priced with gift state in description exc void).
I’m hoping to implement this used cout order state (where I already have a course state) to automatically apply the gift state/price change to the order added for starter main and dessert up to the count equal to the number of guests field… Should be good if it works.

Anyway as part of this flow can in theory add a new ticket state for package which I can constrain the default before ticket closing action, and add an action to remove the state when the ticket is posted to the room…

Fingers crossed it will work as planned.

Fair point.
Hopefully the above will clarify a bit…
Dinner bed and breakfast guests will need their orders ringing in however the value will be 0 or have a gift state however if they were to bring drinks through from the bar or not order drinks before dinner the ticket total will be 0 and ticket closed before it wants to be.
Do not want it to be a manual proces of keeping open or allowing close so think/hope above works as think it should work well.

If it won’t close automatically it should close manually… Or you need a condition other than remaining amount…

I think my plan should work with only adding constraint to ticket state is not dinner package similar to the hold state on the tutorial for holding ticket from being sent to kitchen.

Holding it is not a big deal. I think the question is when you’ll release it.

I am sorry but I cant understand what you are trying to do and why. I am completely clueless to a bed and breakfast setup. Why would you be making it 0 priced? Are they not paying for it at all?

It would be released in the command flow of posting the ticket to the room through the PBS integration

Hmm @Jesse’s question made me think maybe you can just switch Entity’s state. I mean you don’t really need an open ticket to display a table (room, whatever) as occupied.

It dinner bed and breakfast, their dinner is included as part of their nightly tariff.
It is preferable to keep the ticket open until they are finished to be able to see what was ordered etc.

Generally they will have drinks or order dishes with supplements or order side orders which are not included which will give the ticket value bit encase they do not order any of the above the ticket would still want to be kept open until they leave the table.

@Jesse I’m not fully getting it either. I guess he wants to keep ticket open to make related entity occupied. Or maybe something like that.

1 Like

Yes :slight_smile: the ticket wants o stay open , not just to occupy the entity but also to be able to oversee.

Ok that makes much more sense. I was thinking it might be something like that but it was really hard to tell my brain reading powers were failing.

So you need to pick a point that you want the ticket to be closed and then let us know and we can help you automate it.

1 Like

I think I will try add state on room entity selected when entity field for package equals DBB
Constrain the rule against that state.
And remove the state when ticket is posted to room via api/integration ready to pass through before close rule.

That sentence makes me think what you need is much more like a kitchen display screen.