How to import existing bookings into Palisis

What does it mean?

When you start using Palisis, you may want to import bookings that were created in another system (for example, your previous booking or ticketing platform).

Palisis does not provide a standard, self‑service booking import feature. Instead, imports are handled as a manual, one‑off process by our team using a dedicated spreadsheet template and internal scripts.

This article explains:

• What you can expect from a booking import

• How to prepare your data

• The limitations of the import

• How to request an import from Palisis support

Before you start

What a booking import is (and is not)

• A booking import is a best‑effort migration of historical or in‑flight bookings from another system into Palisis.

• It is performed manually by Palisis teams using your data in a specific spreadsheet format.

• It is not:

  • A real‑time integration between systems

  • An automated or recurring synchronisation

  • A way to replicate every technical detail of your previous system’s data model

Because booking data is complex and distributed across multiple entities (products, departures, prices, passengers, etc.), imports are case‑by‑case and may require several review rounds with you.

Prerequisites

Before we can start an import:

• Your products, prices and departures must already exist and be configured in Palisis.

• You must be able to export your bookings from the previous system into a spreadsheet (CSV/XLSX) or similar.

• You must be willing to transform your data into our required spreadsheet template (or work with us to do so).

What should I do?

Step 1 – Contact Palisis

1. Contact Palisis Support or your Customer Success Manager and request a booking import. Please include:

   • A brief description of your current system and desired import scope (for example, “all future bookings from the next 3 months” or “last season’s bookings”).

   • Any example export files (CSV/XLSX) you already have from your current system.

    

2. We will:

   • Confirm whether an import is feasible for your specific case.

   • Share the latest version of the Palisis booking import spreadsheet template with you.

Step 2 – Prepare your data in the Palisis template

You are responsible for providing clean data in the required format.

Using the template we provide:

• Fill in all mandatory fields (marked as required in the template).

  • The import will not run if mandatory fields are missing.

• Optional fields may be left empty if you do not have the information.

Important structural rules:

• One row per ticket

  • Quantifiers (e.g. “4x Adult”) are not supported.

  • If a booking has 4 adult tickets, you must create 4 separate rows.

• Tickets from the same booking must be consecutive

  • All rows belonging to booking A should be grouped together, then all rows for booking B, and so on.

• Do not change the structure of the template

  • Do not add, remove, rename or reorder columns.

  • Do not modify data validation rules in the template.

  • If the file structure is changed, it will be rejected.

Practical tip:
A common approach is to:

1. Paste or import your raw export from the old system into a new sheet within the same spreadsheet file.

2. Use formulas to map and transform this raw data into the exact format required by the Palisis template sheet (including all mandatory Palisis columns).

3. Keep the Palisis template sheet as the only sheet that will be delivered back to us for import.

   Here’s wording you can paste into the article, under “Step 2 – Prepare your data in the Palisis template”, after the “Practical tip” section (or as a new sub‑section like “### Column‑by‑column guidance”):

Column‑by‑column guidance

Below is an explanation of what to enter in some of the key columns of the Palisis booking import template. The exact columns you see may vary slightly depending on the version of the template we provide.

• Booking UID 
  Enter the order ID from your current reservation system (for example, from Regiondo). 
  This should be the unique identifier of the booking/order in your old system.

• Ticket UID 
  Enter the ticket ID from your previous system (for example, the ticket ID from Regiondo). 
  If your old system does not have a separate ticket ID, you can reuse the Booking UID plus a suffix to make it unique per ticket.

• Operationline 
  Enter the product name in Palisis that corresponds to this ticket. 
  This must match the name of an existing operation line in your Palisis back office.

• Route 
  Enter the route name from Palisis. 
  Use exactly the same route name as configured for the operation line in Palisis.

• Passenger Category 
  Enter the passenger type, for example: 
  Adult, Child, Infant (or the passenger categories you actually use in Palisis).

• Seat Category 
  Enter the seat category from Palisis, for example: 
  STANDARD (or another valid seat category configured in your account).

• Priceplan 
  Enter the name of the price plan in Palisis that applies to this ticket. 
  Use the exact price plan name as configured for the operation line/route in Palisis.

• Payment Type 
  Enter the payment method from your previous system (for example, from Regiondo). 
  Typical values are similar to: Cash, Credit card, Online payment, depending on how you want them to appear in Palisis.

• Vat Rate % 
  Enter the VAT percentage associated with the price plan or product in Palisis. 
  For example, enter 7.7 or 21 (depending on your configured VAT rates and local tax rules).

• Sales Person 
  Enter the name of any user in your Palisis account to be recorded as the salesperson for this ticket. 
  This can be a real user (for example, “John Smith”) or a generic user (for example, “Online Sales”) if you prefer.

Step 3 – Internal validation and mapping

Once you share the filled‑in template with us:

• Our Customer Success team will:

  • Check that your file follows the structural rules.

  • Validate that the referenced products, prices and departures exist in Palisis.

  • Help to resolve obvious mismatches (for example, unknown product codes).

• Our technical team will:

  • Add any required additional data in internal sheets (if necessary).

  • Prepare the data for import following internal guidelines.

We may contact you to clarify data issues or request corrections.

Step 4 – Import and confirmation

After validation:

1. Our technical team will run the import into your Palisis backend.

2. You will be asked to:

   • Review a sample of imported bookings.

   • Confirm that the data appears as expected (product, date/time, price, passenger details, etc.).

If issues are identified, we may need to adjust the data and repeat the import step (fully or partially), depending on the situation.

Best practices for a smooth import

To increase the likelihood of a successful and timely import:

• Start small:

  • Begin with a sample dataset (for example, a single day or small period) and validate the result before preparing the full history.

• Keep data clean:

  • Remove obviously invalid records (for example, incomplete bookings, test bookings) before sending data.

• Align on identifiers:

  • Make sure that product, price and departure identifiers in your file clearly match what you see in Palisis (names, IDs, codes).

• Do not modify the template structure:

  • Always work within the provided columns; use separate sheets and formulas for any transformations.

Good to know

Known limitations of booking imports

Due to technical constraints and the complexity of booking data, the import process has several important limitations:

• No partner sales / external vouchers

  • Bookings involving external partners or external voucher codes cannot be reproduced as such in Palisis via this import.

• No bundles or packages

  • Multi‑product bundles or packages are not supported.

  • Each imported row must correspond to a single ticket on a single route/operation line.

• No discounts

  • Historical discounts or promotions from your previous system are not imported as discount entities.

  • If required, you may reflect a discounted price in the final ticket price fields instead (subject to template structure).

• No external references

  • External system references (for example, legacy IDs used by another platform) are generally not supported as linked entities. Only limited reference information may be stored as plain text where fields allow.

• Departure existence checks are limited

  • The import process itself does not automatically verify that every departure in the file exists at the specified date and time.

  • Our team will help confirm that your products, prices and departures are configured, but it is ultimately your responsibility to ensure that the bookings you provide correspond to valid departures in Palisis.

• No support for multi‑route per operation line

  • Each row may only reference one route / one operation line.

  • Complex multi‑route structures from your legacy system cannot be reproduced exactly.

• Check‑ins and passenger counts are not supported

  • Historical check‑in status or passenger count metrics from the previous system are not imported.

• No information is sent to Blackboxes / Fiskal units

  • Imported bookings do not trigger any communication to fiscal devices or blackbox systems. Only the data inside Palisis is updated.

Because of these limitations, the imported data is intended mainly for reference and operational continuity, rather than a complete historical reconstruction identical to the previous system.