Travel & Tour Operators

Why a trading system cannot express this

An inbound operator receives a group from a partner agency abroad, books everything the group will need on the ground, and invoices the partner for the package. An agency sells the same arrangements to its own customers. Either way the business breaks three assumptions a stock-based module is built on.

Nothing is ever in stock. You do not hold a hotel night in a warehouse. You buy it for a specific group on a specific date, and if nobody comes it is simply not bought.

Your suppliers are the hotels themselves. A hotel, a restaurant and a tour guide are each their own master file carrying its own accounts. You do not create a shadow supplier record beside each one — when you raise a travel purchase invoice against the Nile Hotel, the Nile Hotel is the party, and its balance is a real payable.

One trip has dozens of moving parts across several days, several cities and several suppliers, and somebody has to see the whole thing at once.

The operations half carries no money

The tour program is the recipe; the tour is the meal being cooked, for a named group on a named date. A program is built once with day numbers rather than dates — day 1 arrival and transfer, days 1–3 at a five-star Cairo hotel, day 4 the flight south — because it is a template you will run a dozen times a season.

A tour is one real group. You name it, enter the arrival date and the pax breakdown, and pick the program; the system lays the itinerary out against real dates, working every check-in, check-out and service date forward from the arrival date. From there you adjust this group’s trip freely.

The header holds what operations actually need: the agent who sent the group, the guide and the tour leader, the flight numbers in and out with their dates and times, the visa count, and the room split. That last one is checked rather than trusted — pax must equal three times the triples plus twice the doubles plus the singles, so 10 triples, 4 doubles and 2 singles saves for a group of 40 and anything else is rejected by name. It is usually a sign somebody changed the room split without re-counting heads.

Hotel and restaurant vouchers are the slips that tell each supplier exactly what has been booked in their name.

None of this carries a rate, a cost, a total or a currency. That is the point: the operations desk can move a hotel or swap an excursion without anyone’s ledger moving, and the accounts desk can price and invoice without touching the itinerary.

The bridge is one button

Create Tourism Service Purchase Orders, on the tour, reads the bookings, groups them by the party you owe, and raises one purchase order per hotel, per restaurant, per guide and per airline. You enter the agreed prices on each, and as suppliers bill you those orders become purchase invoices — the cost of the trip.

On the other side you raise a travel service sales invoice on the partner agency for the package price. The difference between what you invoiced and what you were billed is the margin on that group, and it is arrived at without anybody reconciling a spreadsheet against an itinerary.

An invoice line sells a service, not a thing

Open an ordinary sales invoice and a line wants an item, a warehouse, a unit of measure and a quantity, because behind it stock has to move and cost has to be relieved. A travel line names a tour service — a private-car airport transfer, a five-night half-board double room, a full-day Luxor sightseeing, a guide day — and that is the whole of it. Nothing moves in inventory when a travel invoice is committed.

Everything else is the machinery the rest of Nama already runs on: discount levels, taxes, payment methods, instalment plans, contract clauses, dimensions, document books and e-invoicing. If you know the ordinary sales invoice, the only part of this screen that looks different is the details grid, and it looks different for one reason.

Programs, tours, vouchers and both sides of the money are documented screen by screen in the Travel guide.