Pre Order/Reservation v.s. (Customer) Accounts

Correct. I don’t believe dates are the way to handle workperiods, because a workperiod could go past midnight.

This isn’t usually an big issue, even with default reporting, but it kind of makes the “Today” filter a bit ambiguous… really it means “currently open”, or similar.

Other summary reports based on dates is fine… to track sales history etc, and the Workperiod really has no bearing on this at all.

From the ground up, SambaPOS was built to use date-based Workperiods, so changing this I think will be a large undertaking. I am not saying it is wrong, it simply is not ideal for certain scenarios. The Workperiod ID, or as I use it: the Z-number, is the basis for my reporting, for the tax man. And that ID has a date range assigned to it… so there is my daily report. Works for me.

But If I want data for the week, month, year, etc, I use SQL and set the date range. No other way to accomplish this… and the ID is useless in this case, but that is to be expected since it is summary data.

My request was more to include the WPID in the Ticket, so that I would not need to deal with date constraints and all the issues that arise in SQL with date comparisons. But this is not what you’re asking for really… and I am not sure the ID has any basis in your requirement. That is to say: you really have no choice other than to use dates for your reports, period. I am unclear as to how having the WPID as the basis for reports is going to help you in this scenario.

The WP table has a [Name] field in it that stores the description. It can be anything you want.

That is another matter. @emre needs to provide a Report Tag to access that data in the WP table.

But description is freely editable on close, the field would want to be hidden and automatic to ensure correct date formatting etc and that it is filled every period.

Where else does work period id get logged?
Are tickets or orders logged with work period ID?

In my system, it is not. I do not use the built-in method to open/close workperiod. Instead, I use the actions for Start/End Workperiod, and I set the descriptions programmatically. The actions are triggered by an automation command.

No. That was my point, and that is why I requested the feature to have WPID stored in the Ticket. This would allow the Ticket to be based on WPID rather than Date, which is very useful for Z-reports.

Actually, the WPID is referenced in 1 other place that I can think of: [PeriodicConsumptions] … but this is an “inventory-related” table.

1 Like

Nice that’s a good idea…

Am on phone so can only quite one thing. The second point of work period on tickets would defiantly be benificial however that wouldn’t solve the multi day preorder ticket route as you would look to populate the sales figures on order level as on ticket level new orders on preorder ticket would would count sales to the work period ID of the work period that is logged wether it is on ticket created or whatever.

But of a cross over with my other discussion with qmacay on booking entities although same pro staple as customer entities although even a returning customer would have a seperate booking entity for each stay would be the entity list would become HUGE and on which subject maybe entity list screen could be set to have the entity types/groups minimised by default or once 100 entities a bit like the products list page although minimised rather than reduced list at first as alphabetically booking type would be before tables and customers and you would have to show all every time to edit a table entity.
Or have them tabed like on entity batch editor
Or have them on sub pages like menus

I Shall post a reply just to let you all know i’m still tracking the discussion i started :smile:

For now I’m using 2 SQL sripts that will assign all untagged open tickets to preorder and when starting a work period will put them back again to normal.
Probably in any workflow used by most restaurants, hotels or what ever this will cause mayor issues in reporting and assigning sales to the correct person but in my case it will be just me and my wife doing the sales. So i will test it end to end with dummy sales and reporting and see where issues will arise.

Ok been thinking about this VS discussion and one thing which would be good if a ‘booking’ account was needed would be the ability to access a number generator for the booking numbers/entities.
I did have a forum search but couldn’t see a solution.
Along the line of something like {NUMBER GENERATOR:Booking Number} which can be used in an action field to be sure to gen a unique number and also the sequence wouldnt be a bad thing.
I setup that system using {RANDOM:4}{RANDOM:6:0123456789) and although the possible outcomes are ridiculously high it is not a guarantee that you wouldn’t get a duplicate.

Apologies if we can already use number generators but couldn’t see a way.
Sure other applications for this although slim bill exist.

There are, by default, 2 Numerators: one for Tickets, and one for Orders.

You can define your own Numerator, though in practice, I do not know how to use it … :stuck_out_tongue_winking_eye:

Once that is answered, you could combine them…

{NUMERATOR:BookingNumberGenerator}{RANDOM:4}{RANDOM:6:0123456789}

1 Like

You wouldn’t need to, as number generator would never give duplicate.
I only used the long random string to try and decrease the chance of a duplicate as much as possible.

@proeftuin

I just did a check and confirmed what I thought.
using preorder option is not going to work without making your own reports.
Although I just set preorder for ticket type ticket and was not truing reorder back off I believe all prep-order does is make workperiod close buttons ignore it (may be wrong)

Anyway once a preorder ticket has past into a new work period NOTHING of it will show on stock work period report - new orders added and even payments.

This makes me believe that all reports are linked to work period through ticket ID/
Was hoping possibly {REPORT ORDER… and {REPORT PAYMENT… might not be effected like that and although I understand the logic/reason behind it.

This would mean a complete rewrite of the report would be needed to make a preorder type system.

This does make me question as to what the possible use of preorder is/was as orders added and payments taken on the preorder on a work period after the one the ticket is started on are backdated on to the old work period which is really not good as this means you can alter the work period figures after the work period is close which should not be the case…

I was hoping that the new orders and the payment might show on new work period as have a non TICKET based report tag and if they did it would be fine as all you would need to do was work out a way to show the NEW sales for the room tickets as ‘Room debit’ and payments as credit and a way to show the balance but its not going to be that easy.

(This point does make me wounder about the reopen closed ticket action, I would personally say that reopen ticket could only justifiably be used legitimately within a work period as in theory you would reconsile against ‘X’ reading/work period before EOD and then correct mistakes and then do ‘Z’ and close work period - just a thought as changes to the ticket - although in theory there is no real reason for it with a correctly configured setup)

I think using the accounts would be the best route,
I mean the only real issue to a basic setup is the ability to work efficiently with account statements which in essence would become room bills although this may just be something I have missed.

@emre has already implied he is happy to improve the abilities here if required to enable use in hotel environment and just needs to know what is needed to get it right.

I dont know effectively we can use the current account tags within a printer template in a sense of feeding into the print which account to report on, presumably would work using the account of the selected entity.
The next question if looking to not use booking entities and just using room entity with single room account is how to only report on the current guest.
That was the reason I used booking account for that setup as was only way I could see to separate the transactions on the statement/account transaction list.

Next point would be if not using the booking entity to go with the booking (which would be better as booking entity was only to use the account) is a way to dynamically allocate the account to the room entity. My first thought would be the ability to set the entity account within an action to match the account created with the api through a script.

Another point would then be how to efficiently log customer details as while we could tag the individual tickets it not ideal, and would then push back to keeping the booking entities.

I would think the link is the Ticket Date and not the ID. That’s also why in the simple reservation example @emre is changing the the ticket date when marking a ticket to Non-preorder.

Changing the Ticket Date will ‘pull’ it back into current Workperiod. And sales and payments will show on your workreport (I Haven’t had time the last days to actually fully test the reports though)

At this moment i run a simple SQL script that sets Preorder = false and updates the Ticket date.time for all unpaid tickets when starting a workperiod.

This way i’m sure that there will be no PreOrder tickets when a workperiod is started.
If tickets are marked as a Preorder they are hard to keep track of; You can add orders in the PreOrder state but indeed they will not show, also keeping them visible in the POS is a lot harder.

In an ideal world sales added to a room account would count as sales for that day, which is what will happen with accounts, going the route your suggesting with changing the ticket date the rooms sales for the whole stay will be dropped in to the sales for the checkout day.
Im not sure what amount on info is stored on an order level but think SQL report would be the only way to go if sticking with preorder, at least for the part handling the rooms.

Given accounts is 90% there as is and in theory we just need a way to improve the statement/account transactions to create a ‘bill’ think accounts is the way to go.
As it stands sales are handled as would be expected, in that they go through on the day of the transaction and the payment would go through on the pay paid.
Altering ticket dates like that I think is going to cause nothing but nightmares. for reporting accurately and reconciling sales to banking.

Am yet to try but hoping a ticket template with {ACCOUNT TRANSACTION DETAILS:{ENTITY NAME:Booking}} will work in ticket template to list account transactions for the booking entity currently selected.
This would still require booking entities unless we can feed dates into it from the room entity (checkin and checkout dates and times)

@proeftuin
“At this moment i run a simple SQL script that sets Preorder = false and updates the Ticket date.time for all unpaid tickets when starting a workperiod.” Would you mind showing me how to set this up in Sambapos since I’m just getting to know Sambapos and I need to implement this for the same reason please?
Thank you in Advance!

Here you go, keep in mind that this will F*ck up your default workperiod reports

I’ve added one button to pre order all open tickets

Which is visible on the main screen

With this Rule

And this Action

For setting as non-Pre Order i use this rule

And this Action

And this is the setting for the Script

And the script itself:

function UnpaidToPreOrder()
{
//create SQL statement
var sqlexec = "UPDATE Tickets SET Tickets.PreOrder = 'True' WHERE Tickets.PreOrder = 'False' AND Tickets.IsClosed = 'False' AND Tickets.TicketStates LIKE '%Unpaid%' AND Tickets.RemainingAmount > 0";
// Execute SQL
sql.ExecSql(sqlexec); 
dlg.ShowMessage('Unpaid tickets saved as PreOrder');
}

function PreOrderToUnpaid()
{
//create SQL statement
var sqlexec = "UPDATE Tickets SET Tickets.PreOrder = 'False', Tickets.Date = { fn NOW() } WHERE Tickets.PreOrder = 'True' AND Tickets.IsClosed = 'False' AND Tickets.TicketStates LIKE '%Unpaid%'";
// Execute SQL
sql.ExecSql(sqlexec); 
dlg.ShowMessage('Unpaid PreOrder tickets set as normal');
}

This is a key point to giving using accounts for tickets which are not being paid that work period.
I was looking at reorders as seamed easier to implement but cause a NIGHTMARE when it came to making good reports as what this is doing is moving sales between workperiods when changing ticket dates.
In the end it was easier to get to grips with the accounts option than to spend ages failing to create a work period which allowed easy reconciliation of daily revenue vs sales

If anything - although not sure if it would be possible, you would be better of changing the ticket date BEFORE ending work period, this would mean the CF sales are moved before reported.