Suppliers

The Suppliers navigation group in Arkana manages every land-service provider (DMC) that Volāre buys from, their bookable inventory, the commercial contracts behind that inventory, insurance products, and the operational queues that suppliers and staff use day to day.

Ordered as they appear in the sidebar:

Item	Manages
Suppliers	The provider companies (DMCs): contacts, banking, currency, documents
Supplier Hotels	Master hotel catalog (rooms, amenities), per supplier
Supplier Activities	Master activity catalog, per supplier
Supplier Transfers	Master transfer catalog, per supplier
Supplier Services	Sellable services with their own rates, linked to a hotel/activity/transfer/insurance
Tours	Tour programs (the primary product entry point)
Travel Windows	Bookable date ranges (with blackout dates) for a tour
Supplier Contracts	Commercial contracts with Signaturit e-signature lifecycle
Insurance Policies	Intermundial insurance products available for sale
Insurance Contracts	Issued/attempted insurance certificates tied to bookings (read-only)
Stop Sales	Date-range blocks that pull a tour’s offers off the web
Trips to Deliver	Supplier-facing operational queue of trips to fulfil (read-only)

Supplier lifecycle

A Supplier is the top-level provider record: contacts (commercial, emergency), address, banking details, default content language (source_locale) and the currency all its prices are quoted in. Changing the currency only re-labels existing prices — it never converts values — so it is treated as a deliberate, high-impact edit.

Under each supplier sit the master catalogs — Supplier Hotels, Supplier Activities, Supplier Transfers — and the sellable Supplier Services that reference them and carry the actual rates. Tours assemble these into day-by-day programs, and Travel Windows define when a tour can be sold.

For the full data model (suppliers, hotels, per-hotel rate periods, tour itineraries and how a tour becomes a market product) see the Suppliers service, and the allotment counters that cap how many bookings a rate can absorb in the Allotment reference.

Blackout dates belong to the season you file them on

A closure only closes dates inside the rate period that carries it. Filing a Christmas closure on a March rate now closes nothing at all — where it once blocked the calendar wholesale, which is how one misfiled range shut every Christmas 2026 departure on a tour.

So the Blackout Dates pickers — on Supplier Services, on Travel Windows, and in the Tours wizard — only offer dates inside that rate’s own start/end, and the limit is enforced when you save, not merely greyed out in the calendar. To close Christmas, open the Christmas season and add the closure there. Two things to expect: an entry already stored out of season still loads and saves untouched (there are pre-existing ones), but editing it to a different out-of-season date, or adding a new one, is refused; and if the rate’s own dates cannot be read the picker falls back to accepting anything, rather than guessing a limit that might reject a date you need.

The spreadsheet import is not bounded this way — it will happily write an out-of-season closure, which then closes nothing. Check closures you loaded from a file against the season they were meant for.

Prices of 0 are no longer accepted

Every price on a service’s rate — room-type and package prices, activity per-adult/per-child, per-trip transfers — must now be at least 0.01. A 0 always meant “not quoted yet”, and offer pricing now reads it that way: it refuses to publish the trip rather than treating the component as free (which, on a single-package tour, would have sold the trip for the flight alone). If a supplier has not quoted a room type, leave that row out entirely instead of entering 0.

The import again is the exception — a spreadsheet can still bring a 0 in, and it will not sell. On a package-priced tour (which is how essentially every live product is priced) a 0 on a package price row stops offers generating for those dates and refuses activation, and the activation refusal is what tells you the package, rate and room type to fix; generation itself only logs a generic “no land price”. A 0 on a hotel or activity rate blocks the same way on tours priced item by item — there the refusal names no rate — and has no effect at all on a package-priced tour, which ignores itemized prices. Correct such rows in the admin panel.

Excel template import

Supplier Services can be bulk-loaded from a spreadsheet instead of hand-entering rows. From the Supplier Services list, Export Template offers two options for a chosen supplier and type (Hotel, Activity, Package or Transfer): a blank template, or the same template pre-filled with the supplier’s current data — edit what exists (or add rows) and re-import, instead of retyping everything. Import from Template uploads the filled file, creating the services, rates and prices that don’t exist yet and updating those that do.

The spreadsheet round-trip is an admin-only tool: suppliers hand their data over in their own formats, and the admins convert and import it. Supplier managers do not see the export or import buttons.

In a with-data export every rate period is one row (a rate blocked for several separate date ranges appears once per range), and untouched rows re-import as no-ops — so it is safe to change only the cells you mean to change and import the whole file back.

Prices are entered in occupancy columns — 1A through 8A (1 to 8 adults), plus mixed-occupancy variants such as 2A+1CH, 2A+2CH and 2A+1B (adults + children / baby) — each priced in the supplier’s own currency. Activities and transfers price per adult and per child instead. Column semantics live in SupplierTemplateService; the import is handled by SupplierTemplateImportService.

Four things are worth knowing before re-importing a file over services that already exist:

Blank cells leave the stored value alone. Fill in only what you want to change. To clear a field, use the admin panel — an import cannot empty one.
An import never deletes — except blackout dates. Rate periods, prices and services are only added or updated; removing them is an admin-panel action. Blackout dates are the exception: on a row that carries a Rate ID, the Blackout Start/End cells are the complete list for that period, so you can extend one, change it, or clear the cells to remove it. A period with several blackout ranges spans one row per range, and all of those rows together are its list. On rows without a Rate ID they are only ever added. The import does not check that a range falls inside the period it is filed on — one that doesn’t closes nothing.
The Rate ID column identifies a rate period, so its dates are editable. A with-data export fills in this last column, greyed out, and it must not be edited: it is what lets you change a period’s start or end date and have that period move rather than a second, overlapping one appear beside it. Leave the cell empty to add a new period — and if you copy an existing row to add one, clear its Rate ID first and give it different dates, or it is describing the same period twice and the file is refused. A file whose Rate ID is unknown, belongs to another supplier, or repeats across two periods is rejected outright too, with the offending row numbers listed.
Identity columns decide what gets matched: Hotel Name + Category, activity Name + Start Time, Transfer Name, or package Service Name. Changing one creates a new record instead of renaming the existing one. City and address are safe to correct — they are updated, not used to identify.

Each template’s Instructions sheet repeats these rules, and identity columns carry a note in their header comment.

Content translation

Hotels, activities, transfers and services are translatable. Their edit screens carry a Manage Translations action (per-locale field forms across the markets’ supported locales) and an Auto-translate with AI helper that pre-fills a translation for review before saving. Untranslated fields fall back to the source-locale content.

Contracts and e-signature

Supplier Contracts are the formal agreements between Volāre and a supplier, optionally generated from a tour (pulling its title, currency, validity and covered service rates). Each contract carries a status lifecycle — Draft → Sent → Negotiating → Signed → Active → Expired, with Terminated available at most stages.

Contracts are sent for digital signature through Signaturit directly from the contract’s edit page: Send for Signature generates the PDF and sends it to the supplier’s commercial contact, with Resend Email, Sync from Signaturit (a manual pull for when the webhook never arrives), Cancel Signature, and PDF downloads (contract and signed copy). Signed and active contracts can then be activated, and terminated with a recorded reason. See the Signaturit integration for the signing flow and recipient resolution.

Addendums: renegotiating a signed contract

A signed contract is locked, so a mid-season rate change has to be agreed in a second document. An addendum is that document: it hangs off the contract it amends, carries only what changes, and leaves the parent untouched. The supplier re-reads a one-page delta instead of the whole agreement, and the two documents stay linked.

Create Addendum sits on a contract’s view and edit pages and on its Addendums list, and appears only on a contract that is Signed or Active — one still in Draft, Sent or Negotiating is editable in place, and an addendum never nests another addendum.

The new document inherits and locks whatever must not diverge from the contract:

Field	On an addendum
Supplier, currency	Inherited from the parent and not editable
Reference	The parent’s reference plus `-A{n}` (`SC-2026-0001-A1`), assigned when the row is inserted so two people drafting at the same time cannot claim the same number
Title	Defaults to “Addendum to {parent title}”
Reason	Required — it is the headline of the addendum PDF and a column in the contracts list
Applies From	Defaults to today, or to the contract’s own start date when its season has not opened yet
Applies Until	Defaults to the parent’s end date
Services	Starts empty — you add only the lines that change, and Generate from Tour is not offered

Every line states what it does to the parent, and the form follows that choice:

Change	Meaning	What you fill in
Added	A service or rate period the contract does not cover	Price and allotment, prefilled from the rate
Changed	A new price and/or allotment over something already signed	Currently agreed shows what is in force today; price and allotment are editable here (they are read-only on a plain contract) and start from the agreed values
Removed	The supplier withdraws the service	No price or allotment at all; Effective From is required and is the date sales stop

What the contract agreed at the moment the addendum was drafted is stored on the line, so the signed PDF keeps printing the same before/after however many addendums follow it.

The addendum PDF is a short document: the amendment clause naming the parent contract (“all other terms remain unchanged”), the reason, the validity dates, then an Added, a Changed (before → after, printed only for the value that actually moved) and a Removed table (with the withdrawal date), and the same two signature blocks a contract carries. Signing is the same flow — the supplier signs first, a Volāre admin countersigns.

On the parent contract, an Overridden by addendums section lists the contract’s own lines that a signed addendum has since replaced, so nobody quotes a price off the contract page that is no longer in force.

The contracts list holds contracts and addendums together: an addendum’s row is labelled Addendum to {reference}, and a Document filter narrows the list to contracts only or addendums only.

An addendum is the wrong tool for several neighbouring jobs:

To do this	Use instead
Close dates temporarily	A Stop Sale
Agree a new season, or change the currency	A new contract
Correct the supplier’s legal or tax data	The supplier record
End the relationship	Terminate on the contract

Signed documents set the price; unsigned ones agree nothing

Across a contract and its addendums, the most recently signed document wins for each rate. An addendum still in Draft, Sent or Negotiating agrees nothing: until the supplier signs it, a rate it introduces or renegotiates is not sellable. (A contract in Draft is different — its rates have always been sellable, and there the gate is the offer’s own status.) Offer activation refuses those offers and names the addendum to chase, and a customer checkout on one is refused as temporarily unavailable with the reason logged for operations. A rate that a signed addendum withdrew from a date on or before the departure is refused the same way, and that refusal cannot be lifted — the supplier has withdrawn it.

The unsigned case can be lifted, but never anonymously. Authorise Selling Without Signature — visible only to a user holding the authorise_sell_without_signature permission, and only on an addendum still awaiting signature — puts its rates on sale after asking for a mandatory reason, and records who authorised it, when and why. The document then carries an Unsigned sale badge in the contracts list (reason on hover), the authorisation is printed on its edit page, and a Selling without signature filter lists every document currently in that state, which is also how the practice gets reported on. Revoke Selling Without Signature puts the signature requirement back; anything already sold is untouched.

Signing an addendum re-prices the supplier’s offers

Published offers keep selling on the margin they were generated with, so a signed addendum would otherwise be a rate change no price reflects. Signing one queues a re-pricing of that supplier’s Draft, Approved-by-supplier and Active offers through the same mechanism an operator runs by hand. Offers with a committed booking are never touched — a confirmed booking keeps the cost it was closed with. See Recalculating Prices.

Insurance

Insurance Policies is the catalog of Intermundial insurance products available for sale: product name, Intermundial policy IDs, the market it applies to (blank = global / all markets), whether it is included by default, and its checkout display order. This is an admin-managed global catalog — it is not scoped per supplier.

Insurance Contracts are the actual certificates issued (or attempted) against a booking. This resource is read-only — contracts are emitted asynchronously during booking finalization, so operations can only inspect them, never create them. Each contract carries a status of Pending, Issued, Failed or Cancelled, the full request/response for auditing, and (when Issued) a live Download certificate action that fetches the Intermundial e-cert on demand.

Cancelling a booking annuls its insurance automatically, but not every policy may be annulled: the included one always can, the optional ones only within the window Intermundial publishes for them. When it cannot, the policy stays Issued — because it is still live at the insurer — and the reason appears on the contract as a Cancellation note. The Needs manual cancellation filter lists exactly those: bookings that are cancelled while their insurance is not, waiting for someone to annul it with the broker. See Travel Insurance (Intermundial).

Stop Sales

A Stop Sale marks a tour unavailable for a date range with a required reason. When creating one, Arkana previews the affected offers live — matched by the offer’s arrival date in destination (suppliers care about when the client lands, not the origin departure). Stopped offers are hidden from the web and flagged in the Trips to Deliver view. See Stop Sales for how the block propagates to offer visibility.

Trips to Deliver

Trips to Deliver is a supplier-facing operational queue, backed by bookings but stripped of all commercial data. It shows only what a supplier needs to operate a trip: passengers, dates, contact details, allotment, stop-sale and extra-night flags, flights, and the hotels/activities/transfers actually purchased. It carries no pricing, payment, sales attribution or checkout-funnel data, and is strictly read-only (no create/edit/delete). See Trips to Deliver.

Supplier-manager visibility

Several people using Arkana are supplier managers — external partner users tied to a single supplier via supplier_id. The Suppliers group enforces this scoping in code:

Row scoping — Suppliers, Hotels, Activities, Transfers, Services, Tours, Travel Windows, Contracts and Stop Sales all filter their listings to the manager’s own supplier. Admins see everything.
Catalog privacy — the Supplier filter is hidden from supplier managers on the Tours, Travel Windows, Services and Contracts tables, so the partner catalog cannot leak between suppliers.
Trips to Deliver is visible only to supplier managers (staff use the full Bookings resource instead), and on multi-supplier tours a manager sees only their own hotels/activities/transfers.
Price gating — where a supplier manager can reach a booking or offer view scoped to their supplier, Volāre’s internal figures (margins, costs, flight economics) are replaced by a “Not visible” placeholder (GatesSupplierManagerPrices). Insurance Policies and Insurance Contracts are not supplier-scoped at all — they are global/ops resources.
Template export/import is admin-only — the header actions on Supplier Services are hidden for everyone else, and both actions also authorize the chosen supplier server-side (SupplierPolicy), so a populated export can never disclose another supplier’s price list.

Suppliers service — data model, per-hotel pricing, publishing tours to markets
Allotment — per-date inventory caps
Signaturit E-Signature — contract signing
Travel Insurance (Intermundial) — insurance issuance
Stop Sales — offer availability blocks
Trips to Deliver — supplier fulfilment queue