Close workperiod with open tickets

I think this post/ workaround should be in the tutorials. Helped me a lot.

Continuing the discussion from Work period - 2 or 3 shifts in a cafe/restaurant:

If using preorders I would usually recommend against it, from my use of preorders and seeing others strugling they are often a nightmare to report on.

If its for credit accounts always look to use accounts.

The link refers to shifts, I personally wouldnt recommend multiple work periods per day, again it will probably cause issues with reporting like you wont be able to recall the report for one shift at a later date, only the whole day due to the way reports work with dates.

My thoughts in a multi shift setup for reports would be to setup a time based or program setting based ticket tag or state which you can key on to to segregate the reports into shifts.

Just my 2pence worth.

I’ve changed this to a V5 Question since this isn’t actually a Tutorial

I have a customer and he’s staff can’t get away with the customer accounts. So I think this isa reasonable solution, as long as you take in mind you have a difference in your accounts and cashdrawer. For example:

Some1 comes in,on Monday, orders and pays on Friday. This means you have a shortage on Monday, On the other hand when he pays, you have a overkill on Friday. So this leaves the only option to print the bill, and put them in the cashdrawer, like an I-OWE-U note.

Here is my end of day report:

    Werk periode: {WORKPERIOD ID}

[VERKOOP 21%:2,1, 1]
{ACCOUNT TRANSACTION DETAILS:Sales Hoog}
>Sales Hoog||€ [=F(TN('{ACCOUNT CREDIT TOTAL:Sales Hoog}'),'#,#0.00')]
>BTW Hoog||€ [=F(TN('{ACCOUNT CREDIT TOTAL:BTW Hoog}'),'#,#0.00')]
>Totaal||€ [=F(TN('{ACCOUNT CREDIT TOTAL:Sales Hoog}')+TN('{ACCOUNT CREDIT TOTAL:BTW Hoog}'),'#,#0.00')]
[VERKOOP 6%:2,1, 1]
{ACCOUNT TRANSACTION DETAILS:Sales Hoog}
>Sales Laag||€ [=F(TN('{ACCOUNT CREDIT TOTAL:Sales Laag}'),'#,#0.00')]
>BTW Laag||€ [=F(TN('{ACCOUNT CREDIT TOTAL:BTW Laag}'),'#,#0.00')]
>Totaal||€ [=F(TN('{ACCOUNT CREDIT TOTAL:Sales Laag}')+TN('{ACCOUNT CREDIT TOTAL:BTW Laag}'),'#,#0.00')]

[VERKOOP TOTAAL:2,1, 1]
{ACCOUNT TRANSACTION DETAILS:Sales Hoog}
>TOTAAL||€ [=F(TN('{ACCOUNT CREDIT TOTAL:Sales Laag}')+TN('{ACCOUNT CREDIT TOTAL:Sales Hoog}'),'#,#0.00')]

[BTW TOTAAL:2,1, 1]
{ACCOUNT TRANSACTION DETAILS:Sales Hoog}
>TOTAAL||€ [=F(TN('{ACCOUNT CREDIT TOTAL:BTW Laag}')+TN('{ACCOUNT CREDIT TOTAL:BTW Hoog}'),'#,#0.00')]

[BETALINGEN:2, 1, 2]
>ONBETAALD|€ [=F(TN('{ACCOUNT CREDIT TOTAL:BTW Hoog}')+TN('{ACCOUNT CREDIT TOTAL:Sales Hoog}')+TN('{ACCOUNT CREDIT TOTAL:Sales Laag}')+TN('{ACCOUNT CREDIT TOTAL:BTW Laag}')-TN('{REPORT PAYMENT DETAILS:P.Amount.Sum:Payment.Amount > 0}'),'#,#0.00')]
>BETAALD|{REPORT PAYMENT DETAILS:P.Amount.Sum:Payment.Amount > 0}

[Orders:1, 1]
{REPORT TICKET TYPES:TotalAmount >= 0}

[Refunds:1, 1]
{REPORT TICKET TYPES:TotalAmount < 0}

[Payments:2, 1, 2]
{REPORT PAYMENT DETAILS:P.Name,P.Amount.Percent,P.Amount.Sum:Payment.Amount > 0}
>Totaal|{REPORT PAYMENT DETAILS:P.Amount.Sum:Payment.Amount > 0}

[Refund Payments:2, 1, 2]
{REPORT REFUND PAYMENTS}

[Ticket Details:2, 1, 2]
>>Ticket Counts
@!{TICKET TYPE LIST}
$1|{REPORT TICKET COUNT:(TY=$1)}|{REPORT TICKET TOTAL:(TY=$1)}
Total|{REPORT TICKET COUNT}|{REPORT TICKET TOTAL}
Amount per Ticket||[=F(TN('{REPORT TICKET TOTAL}')/TN('{REPORT TICKET COUNT}'))]
>>Order Counts
@!{TICKET TYPE LIST}
$1|{REPORT ORDER COUNT:(TY=$1)}|{REPORT ORDER TOTAL:(TY=$1)}
Total|{REPORT ORDER COUNT: }|{REPORT ORDER TOTAL: }
Orders per Ticket||[=F(TN('{REPORT ORDER COUNT: }')/TN('{REPORT TICKET COUNT: }'))]
Amount per Order||[=F(TN('{REPORT ORDER TOTAL: }')/TN('{REPORT ORDER COUNT: }'))]
>>Ticket Counts per State
{REPORT TICKET STATES}
>>Order Counts per State
{REPORT ORDER STATES}

>>Order Counts per State
{REPORT TICKET PAYMENT TOTAL}

[Payment Details:2, 1, 2]
@{TICKET TYPE LIST}
@{TAX TYPE LIST}
>$1
{REPORT PAYMENT DETAILS:P.Name,P.Amount.Percent,P.Amount.Sum:(TY=$1)}
{REPORT CALCULATION DETAILS:C.Name,C.X,C.CalculationAmount.Sum:(TY=$1)}
$2||{REPORT TICKET DETAILS:TX.$2.Sum:(TY=$1)}

[User Sales:1, 1] 
{REPORT ORDER DETAILS:O.User,O.ExactTotal.Sum}
@{REPORT PAYMENT DETAILS:P.User,P.Amount.Sum::{0}:,} 
[Settled by $1:1, 1, 1] 
{REPORT PAYMENT DETAILS:P.Name,P.Amount.Percent,P.Amount.Sum:(PU=$1)} 
>Total Income|{REPORT PAYMENT DETAILS:P.Amount.Sum:(PU=$1)}

[Item Sales:2, 1, 2]
{REPORT ORDER DETAILS:O.ItemGroup,O.ExactTotal.Percent,O.ExactTotal.Sum:(ODI=True)}
Total||{REPORT ORDER DETAILS:O.ExactTotal.Sum:(ODI=True)}

Not quite sure what that means…
Cant get away with customer acounts?

Unless its changed the issue I found with pre order was you need to change the ticket date aswell, if you leave the date as it is the sales are counted but when paid the payment is backdated to the ticket tade (in the past).
If you change the date the sales are moved forward each time untill they are paid. This them makes it hard to track balances and debt age.
Preorder was not made to be used in this way which is why its not usually the best method to use for account type systems.

The staff are all students, and switching randomly. Its is too complicated too explain to every newbie that only stays for about a week or 2. So there are a lot of mistakes made. Now the manager can keep track, but he is’nt always around. So these mistakes like mistype, paying wrong account etcetra. etcetra… So, If ticket is stored on a simple Entity screen in red, the just pick the name, and press Settle to pay the bill.

Now next problem:

Rick is comming on Monday, drinking 2 beer, and put it on the “Ticket account”.
Rick is comming back with 2 buddy’s on Wednessday and put another 5 beers on the same ticket.
Rick is coming back on Friday, Drinks a couple of beers, and pays he’s bill.

after a orderline is submitted, you can’t make it a Pré order, open it again to some more orderlines, and make it a Pré-order again, can you?

Lol society is going to degress to the point that they will require a single button to do anything and adding a second button will be too difficult. Sorry for sarcasm I just really find it amazing that Students of all people find customer accounts difficult.

You can probably work out some automation for that. You do know that all your sales will go in for Friday…the Monday and Wednesday sales never happened because you used pre order ticket. That works ok for you?

Your daily sales will always be wrong on your reports.

2 Likes

Yes, Daily sales as explained above will always be wrong. For the students, he sorts on boobs, not brains…:yum:

So actualy, I am already doing a state change to mark ticket as pre-order, but for some reason not all the way…

1 Like

lol makes sense. [quote=“Michiel_Visser, post:8, topic:12077”]
but for some reason not all the way…
[/quote]

What do you mean by that? Your having trouble?

Wel, not realy trouble, it works, but it is stated as pre-order, so I can close the workperiod, but it is also stated as “unpaid”, and so it is taken in to the End WorkPeriod" total, but it will print the amount of the unpaid bill, just like the Customer Accounts gets printed.

Have to go now, But I will come back to this :stuck_out_tongue:

Maybe i can give it a try to Move it around to a other pre-order ticket type or something.

1 Like

I have 2 questions.

  1. How operator can know (at the time of ordering) customer will pay later and find the old unpaid ticket to add orders in it?
  2. What will happen if customer pays half of the unpaid ticket? When a single ticket used for unpaid orders that ticket may never close.

95% are regular customers, known by name, and good faith they pay most of the time on the end of the evening…

It just works as a regular ticket, with “Settle screen” used. So If the bill is 22,00 and customer pays 11,00, the remaining ticket stays on 11,00. Just type in 11,00 and cash, then close button to return to ticket, then close button again to close ticket. it will return to pre-order state, since there is no orderline added.

BOOOOOOOOBBBBSSSSSSSSSSSS, AAAhhhhhhhhhhhhhhhhhhhhhhhhhhhhh, nice!!!

sorry…

1 Like

Should have just said that in the first place LOL :wink:

1 Like

What he is saying that this will just keep carrying the ticket forward.
Using preorder method means that that ticket, its sales and payments will continue as preorder untill you make final payment and properly close.

Yes, but pre order is usualy not counted in receivebles, am I right? This pre order is.

Preorder is just a setting which allows to be left open for work period close.

Transactions etc behaive like normal tickets it based on ticket date.
Most people ive seen use preorder setup to change ticket date to keep current.
This is why I avoid preorder after spending a couple of days trying to get it to work how I wanted and strugling, after admiting defeat trying to take the easier option I changed to use accounts and made like so much easier as is doing it properly rather than hacking a feature to do something different which there is already a proper feature to do the job.

For now it works, and the boobs have their workaround. :basketball::basketball: (misging the boob smiley)

When you end up looking at using accounts :yum: this is something allong the lines you might want to look to do.

Its more than what you need as does bookings and rooms but main thing for your use would be the second entity screen with grid formatting to show balance.

1 Like