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

I was just wondering, and correct me if i am wrong.

For a setup which uses bills that will span multiple days, like in Hotels, B&B’s and campsites there are two ways to make a setup: (Three if you just never close a workperiod)

1 - Transfer all tickets to a (customer) Account and when a customer checks out/Pays the Bill Balance the customer account.
Disadvantage:

  • Not a single Ticket (I Guess it is possible to make a single Bill with reporting)
  • By default the normal payment screen isn’t used, so no amount Due, etc.
    Advantage:
  • Inventory keeps up with the actual status.

2 - Create a PreOrder ticket.
Disadvantage:

  • Inventory will not decrease until payment (Am i wright?) .
    Advantage:
  • Single Ticket

Are there more Advantages and Disadvantages to take in to account?
So for example if i don’t use inventory why shouldn’t i create all of my (new)tickets as an preorder?

Please share your thoughts.

I am working on hotel room account system at the moment.
The issue you will have either way (or at least as far as I could tell as am used to accounting for room bills as a guest ledger account) is the clearly showing figures which will allow easy reconciliation of sales and banking.
The default work period is based on work period report and as such doesnt show ‘balance’ of the ‘guest ledger’ wether it be preorder or accounts and you will need to work on some custom reporting.

As standard SALES = PAYMENT but when you have multi work peiod tickets this is no longer true however the work period report is just that and report for that work period.
The difference between SALES and PAYMENTS would obviously be relative to the difference between the BF and CF balance of the ‘room accounts’ ie if lots of sales onto account but not paid SALES will be more than PAYMENTS say on a Saturday night, but then sunday will be the other way round when there are more PAYMENTS than SALES as a chunk of the account balance has been paid off.

The forum leaders would generally recommend against preorder as it is not what the feature was originally intended for HOWEVER using accounts makes it tricky to give a bill/guest invoice which is customization.
There is an account statement type print but is very minimal with tickets transfer-ed and payments received.

The issue then with statements is that it would show transactions from the previous guest without more advanced custom reporting.

I combatted this by making a setup which generated a ‘BOOKING NUMBER’ entity and linked it to the room entity. Although not finished yet this in theory should mean it is more usable for this type system like most PMS systems use guest accounts rather than room accounts for this reason.

Here is a snippet from my setup;

How bigger place are you setting up for as I am also working on a PMS intergration for the booking system NewBook;

I’ve been following your posts about your setup and that’s more or less the reason i came up with this question,

As you said yourself [quote=“JTRTech, post:1, topic:7918”]
Was allot of work, should have tried the pre-order method that is always recommended against :frowning:
[/quote]

And thinking about it, the method you are using seems to be the best way for using accounts.
A seperate account linked to the room. Because ihmo the customer account isn’t the best option.
A returning customer will have several old Tickets on his account so you will have difficult reporting combining all tickets to a single bill/guest invoice. The method you’re using doesn’t have that problem.

But Iwas always taught: KEEP IT SIMPLE.
And it seems to me that the most of the setup is so much easier if Pre Order Tickets are used. O.K. you will have a challenge in reporting but that’s also a challenge with Customer/Room/Intermidiate Accounts.
So what’s the real drawback for using Pre Order?

I know the Pre Order function was never designed to be used for keeping Tickets alive for several days, but then again there are many ‘features’ in SambaPOS which are used in a way they where never intended for.

The place i’m setting up will be small, about 25 campsite places and a couple of rooms. Not enough to try and implement/integrate a full booking system.
And because i’m that small i can do without a warehouse/inventory, if that’s the main thing you will mess up using PreOrder tickets.

Which brings me to another question; Is VAT tracking on inventory items possible? Can you track how much VAT you’ve paid on your Inventory items and Debit against products sold? … Sometime I should start a new topic for this question, for now not really important.

Funnily enough the NewBook dev testing account is a campsite setup…

Seen others track expences/payouts so with the correct account transactions you probably could but obviously you dont want to literally offset it - well as far as I understand you declare the vat on sales and the vat on purchases rather than just the difference but never had to deal with VAT returns.
If tracked you would be best to just have a calculation on the report.
Estimated VAT Owed: (VAT ON SALES) - (VAT ON PURCHASES)

That’s a coincidence :smile:
But for what we are planning we won’t have so much real reservations, most guests for the campsite will be walk-in guests. And we won’t have really fixed pitches, which could also mess up any reservation system if somebody uses more or less space.

That’s right, so to keep track you would need Accounts for VAT ON PURCHASES, which would Debit, and the VAT ON SALES will be Credit. Indeed the difference between those two Accounts will be your owed VAT.
The thing is; i don’t think it’s possible to apply Tax templates for your purchases. So with calculation it will be doable with a single VAT Rate but for multiple rates it will get very tricky to assign the right rate for your purchases.
But enough off-topic.

My main question for this topic. What is the real issue with using PreOrder tickets for a hotel/b&b/campsite setup?

I think the issue is SambaPOS default configuration targeted Restaurants and for hotels you need to redesign most default SambaPOS features like rules, reporting, accounting, etc. from scratch. That needs good knowledge of SambaPOS automation, SQL and JScript.

The other issue is most people is Restaurant people here so it is really hard to track Hotel related topics without prior knowledge about common Hotel terms and workflows. For example I’m trying to think booking as table booking and start thinking that way but hotel booking is probably different. So we need more detailed explanation to be able to understand the exact point.

Well I guess the problem or issue is “rooms or sites will be hired out for days at a time OR across Samba work periods”. Following the lots of healthy discussions about this it seems PreOrder has little accounting ability and will make life hard controlling or tracking cashflow? (Even though JTRTech will probably find a way :stuck_out_tongue_winking_eye:)

Sorry to bud in but interested in these discussions.

The accounts system will be the way to go but think we will need some improved functionality in the way to produce a room INVOICE which in effect will actually be a STATEMENT in terms of how Samba is treating the transactions.
It would likely be posible at the minute but only with a heivy dependence on SQL and Scripts
At the minute I am concentrating on getting the system most recently discussed useable and shipped ready for the weekend.
The customer has accepted that is he wants the new system for the weekend the room accounts function will be limited and have to be finalised at a later date.
Once I have the actual transactions working I will then look to sorting the printable templates but for now my issue with actually charging to the account is holding me back.

I am yet to completly understand pre-order option.
I thought it was more than just an option for allowing work period closed but now having an slightly better understanding of the work period report I think that is all it is.

The accountability is mainly based on the default work period which I beleive is heivily based on ticket date (creation date), a rewrite of the bulk of the report to work on ticket closed date I think would in theory get you allot closer to a viable system using the preorder option.

In short the reporting would need to be based mainly on order level when related to SALES,
TICKET type info would only realy be used for reporting BALANCE of preorders.
PAYMENT parts I think is fine as these are only ever relevent to that period and once processed obviously become a credit on the tickets/balances.

Your’e welcome, that’s what this topic is for, it’s an open discussion :smile:

I already noticed that setting preorder directly infuences the Report Ticket TAG, it will not show anymore. And my guess is that will happen for a lot more things.
On the other hand in the Accounts you will have a Sale but no Payment, which seems valid to me in the setup i was thinking of using.
For a real Reservation this doesn’t seem completely right to me, I wouldn’t think of a Reservation as a real sale yet, but that’s just my opinion.

I Think I’ll write a SQL script that will allow you to set all Unpaid tickets to PreOrder:True in the evening when closing your workperiod and a script that will automatically set all PreOrder Tickets to PreOrder:False when starting a workperiod, and just start working from there and just see what issues i’ll encounter…

@emre It seems to me that the current work period system in general is not ideal for hotel since hotel is 24 hours and doesnt really use a work period like we are using in restaurants.

We can probably modify SambaPOS to work just fine but I agree with Emre that if we knew more about the entire business flow we can maybe come up with some ideas that can work for Hotel and be beneficial for some restaurants too.

I Agree, But SambaPOS is such a nice, flexible and affordable system for which more and more functions, features etc. are being developed that for me it is worth my time trying to set it up to my needs (Which are absolutely not the same level as a Hotel).

What I meant by that is we can possibly explore reasonable alternatives for the current work period system that might work for hotels and some restaurants. But we could really use more explanation of how Hotels typically work.

1 Like

I dont think its the work period system thats an issue, the hotels current system still has end of day.
I think they got arround it by making work periods into reporting dates…
Thats probably a hard one to explain…
If you rang something in at 00:25 04/11/15 but didnt do end of day for 03/11/15 untill 00:30 04/11/15 that sale would be reported as 03/11/15.
This is the system I am used to and is why I took part in the discussion about reports being based on work period ID rather than dates.

Well what you explained is directly related to the Work period system. You gave a hint of how it works with this:

If we had more information like that we can probably help with this more.

1 Like

The transaction etc was still dated as 00:25 04/11/15

I think the KEY DIFFERENCE which is probably what you need to understand how their system works is WORK PERIOD = DAY ie;
If today is 04/11/15 and tonight I did end of day twice 05/11/15 would have no sales and tomorrow sales would be reported as 06/11/15.

I will be able to help more once I have a better understanding of the report code.
I dont think necerserally anything in samba would need to change and the ‘preorder’ type setup could be very viable the report just needs to be adjusted to work a little like this;

Oh also their EPOS reports for tickets etc were seperate to there sales and accounting reports.
That in theory I think would be the way to do with samba so that multiple reports covering days sales on one and accounting on another so that report dates can be extended to incorporate the open tickets as a balance on the room by filtering to ticket state is not isclosed so that we can seperate from past tickets (which would be closed)

This situation is why I was interested in reporting by work period ID rather than by date as am used to my work period being directly related to a date.

Report start and end date would be inclusive of the sales within the work period ID for those dates.
Ie if end date of report end work period was 00:30 04/11/15 the work period would be ID of 03/11/15
So when selecting start and end date for report it would include and sales which were dated next day but outside of the report date range.

That make sense.

1 Like

@QMcKay probably understands as think he was the other person wanting work period ID

Perhaps we can figure out a way to implement work period tag/fields which can but used in reports.

We could have a field for work period business day and setup for on work period end a confirmation / ask question prompt showing {DATE} which would be used and an option of today={DATE} and yesterday={{DATE} minus 1 day.

Then if we can used this date as a filter in the reports start and end it would include work periods allocated to those business days and ALSO allow multiple work periods within a day which some people probably use for shifts for lunch/dinner.