Inventory Operations Guide

Overview

This guide is the complete reference for inventory in Kaptio — from initial setup through day-to-day operations. It covers choosing an inventory status, creating inventory contracts, generating allotment days, reading and adjusting availability, applying status controls, configuring release tiers, and auditing inventory health across a product portfolio.

Part 1 introduces the core concepts — inventory statuses and how allocation works. Part 2 walks through the hands-on setup: creating contracts and generating allotments. Parts 3–7 cover the inventory model, ongoing management, status controls, release tiers, and monitoring. Part 8 focuses on allotment utilisation in packages. Part 9 covers annual rollover and downstream impacts. If your services already have inventory contracts and allotment days in place, you can skip Parts 1–2 and start from Part 3.

Inventory management is an ongoing discipline, not a one-time task. Supplier allocations change. Dates sell out. Suppliers close for renovations. New seasons open. A well-run programs team checks inventory regularly, responds to supplier notifications promptly, and audits availability before each selling season begins.

By the end of this guide you will be able to create inventory contracts, generate allotment days, read and interpret availability records, adjust allocations, apply and remove stop sale flags, set on request and free sale statuses, configure release day tiers for returning unsold units to suppliers, and run audits that catch gaps, overbookings, and misaligned availability across multi-component packages.

Prerequisites

Before using this guide, ensure the following are already in place:

• Services created with price categories defined. See the Supplier & Service Setup guide for the full service creation workflow. After bulk import, confirm Sort Order is set on each price category — blank values can hide services from Pre/Post Stay package search while leaving standalone booking unaffected.
• Date ranges planned — decide which seasons and date windows your inventory will cover before creating contracts.
• Programs Manager, Delivery Consultant, or Admin access in Kaptio.

---

Part 1: Understanding Inventory Setup

This part introduces the core inventory concepts you need to understand before creating contracts and allotments — inventory statuses and how allocation type and behavior affect inventory consumption.

Inventory Statuses

Before creating inventory contracts, you need to decide which inventory status applies to each service. The inventory status determines how availability is managed:

Status	Function	Behavior	When to Use
On Request	Inventory Setup, Inventory Contract Status	Availability needs to be manually confirmed by the supplier	Dates where supplier confirmation is needed before a booking can be confirmed
Free Sale	Inventory Setup, Inventory Contract Status	Unlimited availability — no allocation tracking needed	Services with effectively unlimited supply where you do not need to manage unit counts
Advanced	Inventory Setup	Enables creation of an Inventory Contract and allotment to manage per-date availability	The starting point for creating an Inventory Contract and allotment; also enables you to specify a Closed contract (see Step 8: Create Closed Inventory)
Allotment	Inventory Contract Status	Active allocation — contracted units are tracked and consumed per date	Services where the supplier has provided a contracted block of units and per-date utilization needs to be managed
Closed	Inventory Contract Status	Blocks availability for specific days of the week — no allotment is consumed	The place is closed on a certain day of the week and should not be booked
Not Available	Fallback Status only	No applicable inventory contract covers the requested dates — the service is not bookable	Dates where no inventory has been loaded or contracted, and the service should not appear sellable
Sold Out	Fallback Status only	Applicable inventory exists for the requested dates, but there are no units left to sell	Allotment is in place but capacity is exhausted — all contracted units have been consumed

Sold Out and Not Available can only be used as Fallback statuses — they are not available as an Inventory Setup status or Inventory Contract Status. They are applied by the system (or configured as a contract/service fallback) when allotment is exhausted or no contract covers the requested dates.

On Request — The Default Inventory Status

On Request is the default inventory status when you first set up inventory on a service. It means there is no guaranteed space — the supplier will be contacted to check and book availability on a case-by-case basis. No inventory contract or allotment days are needed for On Request services.

When a traveller books an On Request service, the booking is created with an Inventory Status of “On Request” and Confirmation Status of “Unconfirmed”. The programs team must then contact the supplier, confirm availability, and update the booking status to “Confirm” if the request is accepted. If the request is not accepted then the Confirmation Status remains at “Unconfirmed” and the service choice reviewed for an alternative.

The system skips inventory checks for On Request services — the item is created with “On Request” status and requires supplier confirmation. On Request services are always bookable and confirmation is handled operationally outside the system.

Use On Request when:

• The supplier has allocation but requires case-by-case approval before confirming
• You do not have a contracted allotment with the supplier
• A service is conditionally available (e.g., pending a group cancellation that would free up space)
• You are close to sell-out and want to manage the last few units manually

On Request creates operational overhead — every booking on an On Request service requires manual supplier follow-up. If most of your inventory is On Request, consider whether contracted allotment agreements with your suppliers would reduce the manual workload.

Free Sale — Unlimited Availability Without Allotment Days

Free Sale is an inventory status that signals unlimited availability. When a service’s inventory status is set to Free Sale, the booking engine treats it as always bookable — no unit counts are checked or decremented.

Like On Request, Free Sale is set at the contract level, not on individual allotment days. When you create an inventory contract with a Free Sale status, the system creates time period records that define the date range the contract covers, but it does not generate allotment day records. There are no per-date unit fields to manage — no Units Total, no Available count, no Units Booked.

Use Free Sale when:

• The service has effectively unlimited capacity (e.g., airport shuttles, digital services, self-guided activities)
• The supplier has guaranteed unlimited allocation for the contract period
• You do not need to track per-date utilization within Kaptio

Because Free Sale services have no allotment day records, you cannot track utilization through the standard allotment fields. If you need to understand how many bookings occurred on a Free Sale service, query the booking records directly rather than looking at inventory.

Advanced — Time-Period Inventory Contracts

Advanced is the inventory status that unlocks the full inventory contract workflow. When you set a service’s inventory status to Advanced, you gain the ability to create inventory contracts with defined time periods — date-bounded rules that control how availability behaves across specific windows.

Advanced is the gateway to all contract types that operate on a schedule rather than open-endedly. Use it when:

• You need a Closed contract for specific days of the week — for example, a venue that is closed every Monday, or a supplier that does not operate on weekends. The Closed contract blocks availability on the selected days within the contract period.
• You need to set up allotment-based inventory where units are available for consumption — this is the standard path for creating inventory contracts with allotment days, as described in Step 1: Create Inventory Contracts and Step 2: Add Allotment Days.
• You need On Request or Free Sale contracts that apply to specific timed periods rather than applying indefinitely. For example, a service that is Free Sale during peak season but On Request during shoulder season can be modelled with separate time-period contracts under the Advanced status.

Advanced is the starting point whenever your inventory needs go beyond a simple open-ended On Request or Free Sale status. If you need any combination of date-bounded rules — allotment tracking, scheduled closures, or timed availability modes — set the service to Advanced and create the appropriate inventory contracts.

Not Available — No Inventory Contract Covers the Dates

Not Available (NA) is an inventory status that indicates a service is not bookable because no applicable inventory contract covers the requested date(s). Unlike Sold Out (where a contract exists but units are exhausted) or On Request (where availability needs supplier confirmation), Not Available means there is simply no inventory record for those dates.

In practice, Not Available is most commonly encountered as a service-level master fallback status:

• If a date has not been defined or covered in any inventory contract for that service, the system applies the master fallback and the item shows as NA.
• This is why setup guides recommend setting the Master Fallback Status to “Not Available” for certain services — so that uncovered dates do not accidentally appear sellable.

Use Not Available when:

• No inventory contract has been loaded or contracted for the requested dates
• You want uncovered dates to be clearly blocked rather than defaulting to a bookable status
• You need to distinguish between “no inventory exists” (NA) and “inventory exists but is exhausted” (Sold Out)

How it differs from nearby statuses:

Status	Meaning
Not Available	No inventory contract covers these dates — nothing to sell
Sold Out	An inventory contract exists but all units are consumed or released
On Request	The service is potentially available but requires supplier confirmation before booking

Important: A Not Available inventory status does not automatically prevent users from adding the service to an itinerary. It serves as a visual indicator that the service is not available on that date. If you need to enforce the restriction, a validation rule should be added to prevent users from saving bookings that include a service with a Not Available inventory status on the affected date. Without a validation rule, users may still add the service and only discover the issue during supplier confirmation.

Tip: Setting the Master Fallback Status to “Not Available” is a defensive best practice. It ensures that any date not explicitly covered by an inventory contract is blocked from sale, rather than silently falling through to a bookable status. This is especially important for services where accidental bookings on uncovered dates would be difficult to unwind.

Tip: Unavailable does not affect existing confirmed bookings and does not prevent new itinerary items from being created — it serves as a warning status indicating that there is no inventory for that date. If inventory becomes available (e.g., a new inventory is added for that date), the status does not revert automatically. Users must manually re-check inventory using the Re-check Inventory Status option on the Supplier Booking screen of the Itinerary to retrieve the updated status.

Closed — Day-of-Week Closures

Closed is an inventory status used when a service is not available on specific days of the week. For example, a museum that is closed every Monday, a restaurant that does not operate on Sundays, or a guided tour that only runs on certain weekdays. Rather than managing allotment counts for these days, the Closed status signals that the service should not be booked on the affected dates.

Closed contracts are created under the Advanced inventory status. When you set a service to Advanced and create an inventory contract, you can specify a Closed contract type and select the days of the week the closure applies to. The system creates time period records for the closed days within the contract’s date range, but no allotment day records are generated — there is no availability to track on a day that is closed.

Use Closed when:

• A supplier does not operate on specific days of the week (e.g., closed every Monday and Tuesday)
• A venue or service has a recurring weekly closure pattern
• You want to clearly communicate to users that a service is unavailable on certain weekdays, as distinct from being sold out or on request

Important: A Closed inventory status does not automatically prevent users from adding the service to an itinerary. It serves as a visual indicator that the service is not available on that date. If you need to enforce the restriction, a validation rule should be added to prevent users from saving bookings that include a service with a Closed inventory status on the affected date. Without a validation rule, users may still add the service and only discover the issue during supplier confirmation.

For step-by-step instructions on setting up a Closed inventory contract, see Step 8: Create Closed Inventory.

Sold Out — Capacity Exhausted

Sold Out (SO) is an inventory status that applies when a service is not bookable because applicable inventory exists for the requested dates, but there are no units left to sell. Unlike “Not Available,” which means no inventory contract covers the requested dates at all, Sold Out means the dates are covered — but capacity has been fully consumed.

Common cases where Sold Out applies:

• Allotment inventory is in place for the requested dates, and the requested quantity exceeds the units available in the allotment — the contracted block has been fully consumed.
• You want the system to treat “insufficient or no remaining” inventory as Sold Out via the fallback status on the allotment inventory contract (and in some setups, via the fallback on the service itself).

How it differs from Not Available:

• Not Available = no inventory contract covers the requested dates at all. There is no allotment to draw from.
• Sold Out = the dates are covered by an active inventory contract, but capacity is exhausted. Units were available at one point but have all been booked or released.

Sold Out is typically applied automatically by the system when allotment units reach zero and the inventory contract’s Fallback Status (InventorySeasonStatus__c) is set to Sold Out. It can also be set manually on a service’s inventory status if you want to pre-emptively block sales before the last units are consumed.

Important: Sold Out does not affect existing confirmed bookings and does not block creation of new itinerary items — it is a warning that capacity is exhausted on that date. If units become available again (for example after a cancellation), the status on the itinerary does not refresh by itself; use Re-check Inventory Status on the Supplier Booking screen of the Itinerary to pull the current inventory status. To prevent saves when Sold Out applies, add a validation rule; without one, users can still add the line and may only find the constraint at supplier confirmation.

How Allocation Type and Behavior Affect Inventory Consumption

Two settings on a service work together to determine how inventory is consumed when a booking is made: Allocation Type controls how many units are consumed (per night, per day, or per booking), while Allocation Behavior on a component assignment controls which dates those units are consumed against. Understanding both is essential for correct inventory setup.

Allocation Type

The Allocation Type field on the service (AllocationType__c) controls how duration and pricing units are calculated. This affects both pricing and inventory consumption:

Allocation Type	Pricing Calculation	Inventory Consumption	When to Use
Per Night	Price is multiplied by the number of nights	One allotment unit consumed per night	Accommodation (hotels, lodges, resorts)
Per Day	Price is multiplied by the number of days	One allotment unit consumed per day	Day-based activities, guided tours
Per Booking	Flat price regardless of duration	One allotment unit consumed per booking	Transfers, fixed-price excursions, supplements

Important: Allocation Type is set on the service and applies to all bookings of that service. It directly affects how the price appears in Costings / Builder — a 3-night hotel at $200/night shows as $600, while a transfer at $80/booking always shows as $80 regardless of trip length.

Allocation Behavior on Components

When services are assigned to package components through allotment categories, the AllocationBehavior__c field on the assignment controls how allotment units are consumed relative to the component dates:

Behavior	Effect
Standard (default)	Allotment is consumed for the exact dates of the component
Pre-Night	Allotment is consumed for the night before the component start date
Post-Night	Allotment is consumed for the night after the component end date
Pre-Night Extra	Extended pre-night allocation pattern
Post-Night Extra	Extended post-night allocation pattern

Pre-Night and Post-Night behaviors are used for Pre/Post Stay components where accommodation nights extend beyond the core component dates.

---

Part 2: Setting up an Inventory for Allotments

This part walks through the hands-on setup: creating inventory contracts, generating allotment days, and reviewing the results. Once setup is complete, Parts 3–9 cover the inventory model, ongoing management, status controls, release tiers, monitoring, package-level allotment utilisation, and annual rollover.

Understanding Inventory Contracts

An inventory contract defines a named availability contract for a service, linking it to one or more price categories and controlling how inventory is managed. Each contract has:

• A description — a useful description to identify the contract parameters, for example “2027 Double Rooms only”
• A service — the parent service the contract belongs to
• A price category — the pricing tier(s) the contract applies to
• An active flag — whether the contract is live for use

Inventory contracts are the mechanism that connects services to the calendar. Without at least one inventory contract, a service has no availability and cannot be booked.

Step 1: Create Inventory Contracts

Open the service record and navigate to the Inventory Contracts related list. Click New.

Field	Description	Example
Description	Descriptive name	”Summer 2026”
Service	Auto-populated from the parent service	Mountain Lodge
Price Category	The pricing tier this contract applies to. Each contract is linked to one or more price categories. When multiple price categories are assigned to the same contract, they share the same allotment pool — a booking against any one of those categories reduces the available units for all of them. For example, assigning Single, Double, and Triple to one contract means all three occupancy types draw from the same unit pool. To track availability independently per category, create a separate contract for each.	Double Occupancy
Active	Whether the contract is live	Checked
Inventory Status	Controls how availability is managed for this contract — see Inventory Statuses above	Allotment
Allotment Type	The type of allotment for this contract (e.g., Guaranteed, Free Sale). Only required when Inventory Status is set to Allotment — without this value, an allotment contract cannot be saved and allotment days cannot be created.	Guaranteed

The following fields are available when Inventory Status is set to Allotment. They are not required for initial setup but control how allotment is consumed, who can book against it, and how overlapping contracts are resolved.

Field	Description
Booking Availability	Controls which booking types consume allotment from this contract. Options: Package & Service (both package-level and service-level bookings consume units), Service only (only service-level bookings consume units), Package only (only package-level bookings consume units).
Channels	Restricts which distribution channels can book against this contract. Leave blank to allow all channels.
Accounts	Restricts which accounts (customers) can book against this contract. Leave blank to allow all accounts.
Supplier Allotment Code	Your supplier’s reference for this contract — useful for reconciliation and supplier communication
Priority	Controls which contract takes precedence when multiple contracts overlap on the same dates for the same service and price category. Higher priority contracts are evaluated first.
Fallback Status	The inventory status applied when allotment is exhausted (available units reach zero). Common values are On Request (allows bookings pending supplier confirmation) and Sold Out (blocks further bookings).
Release Fallback Status	The inventory status applied to allotment days after the release period has passed and units have been returned to the supplier. Options: On Request (the date moves to On Request status, allowing bookings pending supplier confirmation) or Sold Out (the date is blocked from further bookings).
Group Travel Support	Controls whether this allotment contract is available for group travel bookings. Options: No Group Tours (default — contract is not available for group bookings), All Group Tours (any group tour can book against this contract), Selected Group Tours (only specific group tours can book against this contract).

Step 2: Add Allotment Days

Once the inventory contract details have been entered, the allotment days need to be created. This step enables a quick add of allotment days which can be adjusted later.

1. Click Add to add Time Periods within the New Inventory Contract
2. In the new modal, enter the Start Date and End Date for the Allotment
3. On the DAYS OF WEEK tab, check the days of the week that the Allotment is available
4. In the top half of the RELEASE SCHEDULE tab, enter the number of units that will be available for each of the selected days of the week during the time period entered in step 2
5. In the lower part of the tab, enter the NO OF UNITS RELEASED and DAYS BEFORE TRAVEL. The release can also be done in multiple parts — see Understanding Release Tiers for details
6. Click Save & Copy to add further dates to the Allotment Table, or Save if you have finished
7. Finally, add the dates to the Allotment table and view them using the button Save and View Allotment Table

Important: The total number of units released must add up to the total number of units available for the selected period.

Tip: If release days are not needed. Set the release units to zero in the release schedule — the field still requires a value, but entering zero tells the system that no units need to be returned before travel.

Understanding Allotment Day Fields

Allotment days are the most granular level of the inventory chain. Each allotment day record represents availability for a single service on a single date. The fields on each allotment day record are:

Field	What It Tracks
Date	The calendar date this allotment day record governs
Inventory Contract	The parent inventory contract this allotment day belongs to
Units Total	The total number of units contracted with the supplier for this date
Units Available	Units currently available for new bookings
Units Reserved	Units held by quotes or bookings that have not yet been confirmed
Units Booked	Units locked by confirmed bookings
Units Temporary Held	Units temporarily locked during the checkout process for bookings processed using Booking Wizard (released automatically if the booking is not completed)
Units Released	Units returned to the supplier via the release schedule
Stop Sale	Checkbox that blocks new bookings on this date regardless of available units — see Part 5: Availability Status Management
Remarks	Free-text field for recording operational context (e.g., why an allocation was changed or why stop sale was applied)

Tip: The Units Booked and Units Available fields are managed by the booking engine. Do not edit them manually — doing so creates a mismatch between the allotment record and actual bookings.

The unit fields are linked: Units Total = Units Available + Units Reserved + Units Booked + Units Temporary Held + Units Released. When a guest searches for availability, the system checks Units Available on the allotment day for the requested date.

Allotment days do not have a status picklist — availability is determined by the unit counts above and the Stop Sale checkbox (see Part 5: Availability Status Management).

Tip: When reviewing inventory, check both the Available count and the Stop Sale checkbox together — a date with remaining units is not bookable if Stop Sale is checked, and a date with zero available units is not bookable even if Stop Sale is unchecked.

Step 3: Review Allotment Days

After generating allotments, review the records:

Navigating to Allotment Days

1. Open the Service record for the service.
2. Navigate to the Inventory tab of the Service, then use the View pill box under Inventory Status (for the required contract) to go directly to the allotment table.
3. Spot-check several dates to confirm:
   • Units Total is correct for the contracted allocation
   • Units Available matches expectations (no unexpected decrements)
   • Stop Sale is unchecked for dates that should be bookable
   • No dates are missing

The allotment table shows every date within the contract.

For day-to-day monitoring, scan the Available column for dates approaching zero and check Stop Sale for any dates where the checkbox is checked. Build a habit of reviewing the next 30, 60, and 90 days of inventory at least weekly. Flag any dates where available count is below a threshold you define (e.g., fewer than 3 remaining).

For bulk adjustments, update records in bulk via Data Loader.

Multiple Inventory Contracts

Most services require multiple inventory contracts to cover a full year. Common patterns:

Pattern	Example	Reason
Annual rollover	2026, 2027	Same structure, different years
Shared vs separate room types	Singles vs doubles (e.g., 4 singles + 10 doubles) vs one shared contract (14 rooms combined)	Different unit counts by room type when singles and doubles are not drawn from one combined pool
Channel or Customer Specific Contracts	Channel A, Account B	Contracts used for bookings made through a specific Channel or for a specific Account

When creating multiple contracts for the same service:

• Ensure no date gaps between contracts — a missing day means the service is unavailable on that date
• Date overlaps are reasonable in some patterns — for example, Channel or Customer Specific Contracts will commonly have overlapping date ranges. When contracts overlap on the same dates for the same service and price category, the Priority field on the inventory contract determines which contract is used.
• Name contracts clearly to distinguish them (e.g., “Summer 2026”, “Winter 2026/27”)

Mountain Lodge
  ├── Low Season 2026 (Jan 1 – Mar 31)
  ├── Shoulder Season Spring 2026 (Apr 1 – May 31)
  ├── High Season 2026 (Jun 1 – Aug 31)
  ├── Shoulder Season Autumn 2026 (Sep 1 – Nov 30)
  └── Low Season 2026/27 (Dec 1 – Mar 31)

Tip: When creating contracts, use a spreadsheet to map out dates first. This catches gaps and overlaps before they become booking issues.

---

Part 3: The Inventory Model

How Inventory Checking Works

When the booking engine checks availability for a service on a given date, it evaluates a series of conditions in order. The diagram below shows the decision flow — each check is evaluated top to bottom until a result is reached.

* In the Closed and Stop Sale branches in the diagram, blocked or Sold Out reflect the inventory check outcome. Assuming a validation rule is in place to prevent booking — without one, users can still add the line to an itinerary; enforcement depends on how your org is configured.

Important: Stop Sale always returns Sold Out. When the Stop Sale checkbox is set on an allotment day, the system returns Sold Out regardless of how many units remain. This is hardcoded behavior — the system does not consult the fallback status when Stop Sale is active. If you want units to go to On Request instead of Sold Out, do not use Stop Sale. Instead, set Units Available to zero on the allotment day. This causes the normal fallback logic to apply, and the configured fallback status (typically On Request) will be used. When doing this, fill in the Remark on the Allotment Day record with the reason for the change — this can be done manually by editing the Allotment Day record without using bulk editing tools.

Package-specific inventory — how the allotment chain connects packages to per-date availability, how package availability is determined, and how to audit cross-service availability — is covered in Part 8: Allotment Utilisation in Packages.

---

Part 4: Managing Allotment Days

Step 4: Adjust Allotments

When a supplier increases or decreases your allocation, update Units Total on the affected dates. There are two ways to make the change, and each behaves differently.

Method 1: Edit directly in the allotment table (recommended)

1. Open the inventory contract and navigate to the Allotment Table.
2. Edit Units Total on the allotment table row for the date you need — you do not have to open the allotment day record. Double-click the Units Total cell and enter the new value.
3. Save. The Available count recalculates automatically (new Total minus existing Booked, Released, and Temporarily Held).
4. Update Release Units as needed — that value does not recalculate automatically.

Method 2: Open the allotment day record

1. Click into the individual Allotment Day record for the date to adjust.
2. Update the Units Total field to the new contracted amount.
3. There is no automatic recalculation when you edit via the allotment day record. Manually update Number of Available and Release Units (when release tiers apply) so the numbers stay in balance — Number of Available should reflect new Total minus existing Booked, Released, and Temporarily Held, and Release Units must match your release rules for the new total.
4. Save the record.

Scenario	Action
Supplier grants 5 additional rooms for Jul 14	Increase Units Total by 5
Supplier reduces allocation by 3 for Aug 1–7	Decrease Units Total by 3 on each date
Allocation increase results in overbooking resolution	Increase Units Total until Available is positive

When reducing allocation, the platform validates that Units Total equals Available + Booked + Reserved + Held + Released, with none of those values negative. You cannot save a total below what is already committed across those buckets; free or reassign inventory first — see Part 7.

Step 5: Add Allotment Days (via Allotment Table)

If you need to add a new date to an existing allotment table:

1. Open the inventory contract and navigate to the Allotment Table.
2. Go to the end of the table and add a new line. Enter the date and the unit values in the Units Total and Release Days and Units columns — together with the date field, these are the only fields you can edit in this view when adding a row.
3. For the date: double-click the date field to open a calendar picker; the day of the week is filled in automatically. You can also type the date — the calendar opens as you type. The value must be in dd/mm/yyyy; invalid formats are not accepted.
4. Save. The new dates are then available in the allotment table.

Tip: Multiple dates can be added by copying existing lines (Ctrl + C or Cmd + C) and pasting into the new row (Ctrl + V or Cmd + V) — the dates and values can then be updated. If you forget to change a date, the system will prevent you saving with “Warning, an Allotment Day already exists for this date and assignment.(row: #)”.

Step 6: Delete Allotment Days

To remove an allotment day from the table:

1. Open the inventory contract and navigate to the Allotment Table.
2. Right-click the row you want to delete.
3. Choose Remove Row from the context menu. If you remove the wrong row, choose Restore Row before you save.
4. Save.

The Remove Row option does not appear when there are bookings assigned to that allotment day. Reassign or cancel those bookings first, then try again.

IMPORTANT

After you save, row removals cannot be undone.

Bulk Allotment Updates

Inline editing (small batches): See Step 4: Adjust Allotments for editing existing rows; use Step 5 and Step 6 above for adding or deleting rows in the allotment table. Those procedures are not repeated here.

For changes spanning multiple dates, updating records one by one through the allotment table is impractical and error-prone — each row must be edited individually, and it is easy to miss dates or enter inconsistent values across a large range. Use a bulk data tool such as Salesforce Data Loader or Workbench instead. These tools let you update hundreds of allotment day records in a single operation from a spreadsheet, ensuring consistent values across the entire date range.

IMPORTANT

Data Loader updates to allotment records are for experienced users only. Proceed at your own risk. Always perform bulk allotment updates outside of operating hours. Allotments can easily be corrupted if updates are made outside the allotment table at the same time as other users or customers are altering allotments by reserving, booking, or cancelling itinerary items.

1. Export the allotment day records for the date range using Data Loader or Workbench.
2. Update the Units Total column in your spreadsheet. Also adjust Units Available so that the unit fields remain balanced: Units Total = Units Available + Units Booked + Units Reserved + Units Temporary Held + Units Released (as described in Step 4: Adjust Allotments).
3. Re-import using the Allotment Day ID as the match key.
4. Verify a sample of records after import.

Always keep a record of allocation changes. Use the Remarks field on the allotment day or a shared tracking spreadsheet to document why allocations were adjusted and who approved the change.

---

Part 5: Availability Status Management

Step 7: Apply Stop Sale

Stop sale is the most common status override in day-to-day operations. There are two approaches, depending on how many dates you need to block.

Approach 1: Allotment table view (one or more specific dates)

1. Open the inventory contract and navigate to the Allotment Table.
2. Check the Stop Sale box next to each date you want to block.
3. Save. The affected rows turn red, indicating those dates are unavailable.
4. Optionally fill in the Remarks field to record the reason for the stop sale.

This is the quickest method when you need to stop-sell a handful of individual dates.

Approach 2: Deactivate the inventory contract (entire season)

If an entire season needs to be put on temporary hold, it is simpler to deactivate the contract than to flag every date individually:

1. Open the inventory contract record.
2. Uncheck the Active checkbox (as described in Step 1: Create Inventory Contracts).
3. Save. All dates in the contract are now excluded from availability checks.

Use this when a supplier suspends a full season — for example, during a renovation or contract renegotiation.

Common stop sale triggers:

Trigger	Scope	Expected Duration
Supplier renovation	Specific dates	Weeks to months
Rate renegotiation in progress	Entire season	Days to weeks
Safety or quality concern	Specific dates or season	Until resolved
Group hold pending contract	Specific dates	Until confirmed or released
Supplier seasonal closure	Entire season	Seasonal

When applying stop sale, always set a calendar reminder to review and lift it. Forgotten stop sale flags are one of the most common causes of “package unavailable” reports from sales teams.

Step 8: Create Closed Inventory

Closed inventory contracts block availability for services that do not operate on specific days of the week — for example, a museum closed every Monday, or a guided tour that only runs on weekdays. Unlike Stop Sale (which blocks individual dates), a Closed contract applies a recurring weekly pattern across the entire contract period.

To create a Closed inventory contract:

1. Open the Service record and set the inventory status to Advanced. The Advanced status is required before you can create a Closed contract — see Inventory Statuses for details.
2. Navigate to the Inventory Contracts related list and click New.
3. Fill in the contract details:

Field	Description	Example
Description	Descriptive name indicating the closure pattern	”Monday Closure 2026”
Service	Auto-populated from the parent service	City Museum
Price Category	The pricing tier this contract applies to	General Admission
Active	Whether the contract is live	Checked
Inventory Status	Select Closed	Closed

4. Click Add to add a time period. Enter the Start Date and End Date for the period the closure applies to.
5. On the DAYS OF WEEK tab, check the days of the week the service is closed (e.g., Monday).
6. Click Save.

The system creates time period records for the closed days within the contract’s date range. No allotment day records are generated — there is no availability to track on a day that is closed.

Tip: If a service has different closure patterns in different seasons (e.g., closed Monday–Tuesday in winter but only Monday in summer), create separate Closed contracts for each period with the appropriate days selected.

Important: A Closed inventory status does not automatically prevent users from adding the service to an itinerary. It serves as a visual indicator that the service is not available on that date. If you need to enforce the restriction, a validation rule should be added to prevent users from saving bookings that include a service with a Closed inventory status on the affected date. Without a validation rule, users may still add the service and only discover the issue during supplier confirmation.

---

Part 6: Release Day Tiers

Understanding Release Tiers

Release day tiers define how many units must be returned to the supplier if not utilised, by a certain number of days before the travel date. This mechanism allows the supplier to reclaim unsold allocation and resell those units through other channels.

Each allotment day supports up to four release tiers. Each tier specifies a number of days before travel and a number of units to release. When the scheduled job runs and the current date reaches a tier’s threshold, the specified units are added to the Units Released field on the allotment day and are no longer available for booking in Kaptio.

For example, if an allotment day has 10 total units with two release tiers configured:

• Tier 1: Release 5 units at 100 days before travel — the supplier gets 5 units back to sell elsewhere, and Kaptio’s available count decreases by 5.
• Tier 2: Release 3 units at 45 days before travel — the supplier gets 3 more units back, and Kaptio’s available count decreases by a further 3.

Multiple tiers allow the supplier to monitor sales progress at defined milestones. A supplier may request a first release at 100 days to gauge demand, then a second release closer to travel to recover any remaining unsold allocation.

Important: Release day tiers are processed by the InventoryManagementScheduler — a scheduled batch job that must be activated in the org. If this job is not scheduled, release-by-day will not run automatically. Contact your Kaptio admin or implementation consultant to confirm the job is active.

Step 9: Configure Release Tiers

Release tiers are configured when adding allotment days to an inventory contract. On the Release Schedule tab of the allotment day creation modal:

1. Open the inventory contract.
2. Click Add to add a time period.
3. In the lower part of the Release Schedule tab, enter the Number of Units Released and Days Before Travel for each tier.
4. Add additional tiers as needed (up to four per allotment day).
5. Save.

Field	Description	Example
Days Before Travel	How many days before the allotment date the release occurs	100
Units Released	Number of units returned to the supplier at this milestone	5

The total number of units released across all tiers should not exceed Units Total for the date. Plan your release tiers so that you retain enough units to cover expected bookings.

Release Tier Patterns

Common tier configurations for different supplier arrangements:

Standard two-tier release:

Tier	Days Before Travel	Units Released	Purpose
Tier 1	100	5	Supplier reclaims 5 units to assess early demand
Tier 2	45	3	Supplier reclaims 3 more units closer to travel

Single release (simplest):

Tier	Days Before Travel	Units Released	Purpose
Tier 1	60	5	Supplier reclaims all unsold units 60 days before travel

If release days are not needed. Set the release units to zero in the release schedule — the field still requires a value, but entering zero tells the system that no units need to be returned before travel.

The Inventory Management Scheduler

Release tiers do not process themselves. They are executed by the InventoryManagementScheduler — a scheduled Apex batch job that must be explicitly activated in the Salesforce org. If this job is not scheduled, release-by-day fields are ignored and no units are returned to the supplier automatically.

What it does:

The scheduler runs as a batch job across all allotment day records that meet these criteria:

• The allotment day’s date is today or in the future.
• At least one release tier is configured (any of Release1Day__c through Release4Day__c is populated).
• The inventory contract’s status is “Allotment” (active allocation).

For each qualifying allotment day, the batch calculates the number of days between today and the travel date. It then compares that number against each of the four release tier thresholds. When a match is found — meaning today is exactly the configured number of days before travel — the corresponding units are moved from available to released, incrementing the Units Released field on the allotment day.

Tip: An allotment day can have Reserved Allotments — child records that set aside a portion of the day’s units for a specific account or channel. Each Reserved Allotment has its own Release Day. When that release day arrives, the scheduler returns any unsold reserved units back to the allotment day’s available count.

Release Fields on AllotmentDay__c:

API Name	Type	Description
Release1Day__c	Number	Days before travel for Tier 1 release
Release1Units__c	Number	Units to release at Tier 1
Release1DayDate__c	Formula (Date)	Calculated calendar date for Tier 1 (Date__c minus Release1Day__c)
Release1Done__c	Checkbox	Whether Tier 1 release has been processed
Release2Day__c	Number	Days before travel for Tier 2 release
Release2Units__c	Number	Units to release at Tier 2
Release2Done__c	Checkbox	Whether Tier 2 release has been processed
Release3Day__c	Number	Days before travel for Tier 3 release
Release3Units__c	Number	Units to release at Tier 3
Release3Done__c	Checkbox	Whether Tier 3 release has been processed
Release4Day__c	Number	Days before travel for Tier 4 release
Release4Units__c	Number	Units to release at Tier 4
Release4Done__c	Checkbox	Whether Tier 4 release has been processed
Units Released	Number	Cumulative count of all units released across all tiers

How to verify the job is running:

1. Navigate to Setup → Apex Jobs (or search “Scheduled Jobs” in Quick Find).
2. Look for a scheduled entry with the class name InventoryManagementScheduler.
3. If it does not appear, the job has not been scheduled. Contact your Kaptio admin or implementation consultant to activate it.
4. Check the Last Run and Next Scheduled Run columns to confirm the job is executing on its expected cadence.

If the InventoryManagementScheduler is not running, release tiers are effectively decorative — the fields are populated but no units are actually returned. This is one of the most common reasons for “units should have been released but were not” reports. Always verify the job is active when onboarding a new org or troubleshooting release behavior.

---

Part 7: Monitoring and Auditing

Viewing Itineraries on an Allotment Day

Before reducing allocation, applying stop sale, or responding to a supplier query about who has booked a specific date, you need to see which itineraries are using units on that allotment day. Every allotment day record has a related list of Itinerary Item Allotment Days — junction records that link each booked itinerary item back to the allotment day it draws from. Each record in this list represents one itinerary item (a booked service) on one allotment day, and shows the parent itinerary (the booking) that the item belongs to.

Approach 1: Navigate from the allotment table to the allotment day record

1. Open the inventory contract and navigate to the Allotment Table.
2. Right mouse click on the date for the allotment day you want to inspect — then select Bookings.
3. In the new modal there will be a list of Itinerary Items that use or would potentially use the units on the allotment day. For example, itinerary items that have units reserved or booked already. This view also shows units that have previously been used but their allotment was cancelled, plus those that qualify for the allotment day but do not yet consume the units. For example, Itinerary Items that have been added, but the item has not been reserved or booked and therefore they are not consuming the allotment.
4. From each record, you can navigate to the Itinerary Item (the booked service) and from there to the parent Itinerary (the booking) to see full booking details.

This is the quickest method when you need to check a single date — for example, to see who has booked the last few units before applying stop sale.

Approach 2: Build a Salesforce report on Itinerary Item Allotment Day

For a broader view across multiple dates or services, create a report using the Itinerary Item Allotment Day object (KaptioTravel__ItineraryItemAllotmentDay__c):

1. In Salesforce, go to Reports → New Report.
2. Select the Itinerary Item Allotment Day report type (or a custom report type that includes this object with its parent lookups).
3. Add columns for the allotment day date, service name, itinerary item name, and parent itinerary name.
4. Group by Allotment Day (date) to see all bookings per date, or group by Service to see utilisation across services.
5. Filter by date range, service, or inventory contract as needed.

This approach is useful when you need to audit utilisation across a date range — for example, reviewing which bookings are affected before reducing allocation for an entire month, or preparing a supplier reconciliation report.

Tip: Always check the Itinerary Item Allotment Days list before reducing units or applying stop sale on a date. This lets you see exactly which bookings would be affected and reach out to the relevant consultants or customers proactively.

Tracking Utilization

Utilization is the ratio of booked units to total allocation. High utilization indicates strong demand; low utilization may signal overallocation or weak product-market fit.

The Allotment Day object includes an Inventory Utilization field that calculates the fill rate automatically. There is no need to export allotment data to view utilization — add Inventory Utilization to a Salesforce report on Allotment Day for the date range you need; group by service to identify which services are selling well and which are underperforming.

Utilization cannot exceed 100% — units booked can never be greater than the total allocation.

Key utilization thresholds:

Fill Rate	Interpretation	Action
90–100%	Near sell-out	Consider increasing allocation or applying On Request for remaining units
70–89%	Healthy demand	Monitor; no immediate action needed
40–69%	Moderate demand	Review pricing; check whether search visibility is correct
Below 40%	Low demand	Investigate — is the package active? Is pricing competitive? Are dates correct?

Seasonal Transition Checks

Date gap: Verify that the end date of one season and the start date of the next are contiguous. A gap means dates in between have no allotment days and will show as unavailable.

Allocation mismatch: Units Total in the new season should reflect the current supplier contract, not simply carry over from the previous season.

---

Part 8: Allotment Utilisation in Packages

This part brings together the package-specific inventory concepts — how the allotment chain connects packages to per-date availability, how package availability is determined by the most constrained service, and how to audit cross-service availability before each selling season.

The Allotment Chain (Fixed & Seasonal Packages)

This section applies only to packages with allotment-based inventory (Fixed or Seasonal Packages). On Request and Free Sale services do not use this chain — their availability is determined by the inventory status checks shown in Part 3.

Every availability check for an allotment-based service walks the same chain of objects, from the top-level package down to a single date record.

The chain works as follows:

• A Package contains one or more Components (accommodation nights, activities, transfers).
• Each Component is assigned one or more Services — specific supplier services that fulfill it.
• Each Service has one or more Inventory Contracts defining date ranges with total allocation.
• Each Inventory Contract contains Allotment Days — one record per date — holding the real-time availability count and status.

When a traveller searches for a date, the booking engine walks this chain for every component in the package. It resolves the service, finds the inventory contract covering the requested date, and reads the allotment day record. If any single service in the chain is unavailable, the entire package is unavailable for that date.

How Package Availability Works

Package availability is the intersection of all service availabilities across every component. The most constrained service is the bottleneck.

Consider a 5-night package with these components:

Component	Service	Available Units
Night 1–2: Accommodation	Heritage Lodge — Deluxe Room	20 rooms
Night 3–5: Accommodation	Coastal Retreat — Ocean Suite	8 rooms
Day 2: Activity	Sunset Cruise	30 seats
Day 4: Activity	Vineyard Tour	2 spots
Transfers	Regional Express — Airport Shuttle	Free Sale

The package can accept at most 2 bookings for that date — limited by the Vineyard Tour, even though other services have far more capacity. The transfer is on free sale and does not constrain availability.

This intersection model means that a single service with low allocation can block an entire package. When investigating why a package shows as unavailable, always check the allotment status of every service in the chain, not just the service you expect to be the bottleneck.

Cross-Service Availability Audit

Because package availability is the intersection of all component services, a single misconfigured service can make an entire package unavailable. Run this cross-service check before each selling season:

1. Identify all services assigned to a package via its components.
2. For each service, verify that an active inventory contract covers the package’s selling dates.
3. For each service with an allotment contract, verify that allotment days exist with Units Available. For Free Sale services, verify that an active contract covers the required dates (no allotment days are needed).
4. Flag any service where dates are missing, stopped, or at zero allocation.

Example audit for a 3-component package:

Component	Service	Season Covers Jul 1–Sep 30?	Allotment Days Exist?	Status	Units Available
Accommodation	Heritage Lodge — Deluxe Room	Yes	Yes	Available	12
Activity	Sunset Cruise	Yes	Yes	Available	25
Transfer	Regional Express — Airport Shuttle	Yes	No (Free Sale — active contract covers dates)	Free Sale	N/A

All three services pass — the package is available. If any row fails, the package is blocked for the affected dates.

---

Part 9: Annual Inventory Rollover and Downstream Impacts

Annual Rollover

Each selling season typically requires new inventory contracts. When transitioning between years (e.g., 2026 to 2027), follow these practices to avoid disrupting live bookings and availability.

Create new contracts — do not modify existing ones with bookings:

Action	When to Use	Risk If Ignored
Create a new inventory contract for the new year	Always, for each service that continues into the new season	None — clean separation between years
Modify an existing contract’s dates to extend into the new year	When a separate contract is not practical	Extending is technically safe — existing allotment days and bookings are not affected — but mixing years in one contract makes auditing harder and obscures year-on-year allocation changes
Copy allocation from a previous season	When supplier terms carry over unchanged	Review Units Total — supplier contracts may have renegotiated volumes

Managing expired inventory:

You do not need to deactivate inventory contracts just because a season is in the past. When checking inventory, the system only uses the date of the booking (usually today or a future travel date), so past-season contracts are not part of that evaluation. The inventory contract list also has no filter by active or inactive status, so turning old contracts off does not tidy the view or change day-to-day workflow in practice.

Action	Effect
Leave active	Past-season contracts stay in the list but do not affect availability for current or future booking dates. Allotment days and booking history remain intact for reporting.
Delete the inventory contract	Kaptio prevents deletion of an allotment contract while any units on it are reserved or booked. If there is no usage, deletion may be possible technically; keeping the record is usually better for audit trail.

Handling inventory tables that should no longer apply:

If a supplier no longer offers a service, or if a contract was created in error and has no bookings against it:

1. Set the inventory contract to inactive.
2. Confirm there are zero bookings referencing allotment days in the contract.
3. If bookings exist, the contract cannot be deleted — Kaptio prevents deletion of allotment contracts with existing reservations or bookings. Leave the contract inactive; the booking records need the allotment day reference for historical accuracy.
4. If no bookings exist, deletion is technically possible but deactivation is still preferred for audit trail purposes.

Downstream Impacts

Inventory changes have consequences for existing bookings. Understanding these “third rails” prevents accidental disruption to confirmed travellers.

Changing allotment on an allotment day:

Change	Impact on Existing Bookings	Impact on Future Bookings
Increase Units Total	None — existing bookings are unaffected	More units become available for new bookings
Decrease Units Total (new total ≥ booked count)	None — existing bookings retain their allocation	Available count decreases; fewer units for new bookings

Applying Stop Sale:

Action	Impact on Existing Bookings	Impact on Future Bookings
Apply Stop Sale to an allotment day	Existing bookings on that date are not affected — they remain confirmed	New bookings are only blocked if a validation rule is in place to enforce it

Deactivating an inventory contract:

Action	Impact on Existing Bookings	Impact on Future Bookings
Set inventory contract to inactive	Existing bookings retain their allotment day references and remain valid	The contract is excluded from availability checks — no new bookings can use it

Deleting allotment days:

Action	Impact on Existing Bookings	Risk Level
Delete an allotment day with zero bookings	None	Low — safe to delete

Best practices for sweeping changes across multiple services:

When making broad inventory changes (e.g., rebalancing allocation across an entire season, restructuring services for a new year):

1. Audit first. Export the allotment days for all affected services. Identify which dates have bookings.
2. Protect booked dates. Do not reduce allocation below the booked count on any date. Do not delete allotment days with bookings.
3. Stage the change. Use the controls your org relies on to limit new bookings on affected dates while you adjust allocation (often Stop Sale together with a validation rule or other automation that enforces it — Stop Sale alone does not block new itinerary lines unless your configuration enforces that). Lift Stop Sale after changes are verified.
4. Verify after. Run the cross-service availability audit (Part 8) for every package that uses the affected services. Confirm that no package has been accidentally blocked.
5. Document the change. Record the reason, scope, and date of the change in allotment day Remarks fields or a shared tracking sheet.

Treat inventory changes the way you would treat a database migration — plan it, stage it, verify it, and keep an audit trail. These edits are made on Inventory Contract and Allotment Day records — not in the booking flow. In the standard UI, destructive actions (such as deleting allotment days) prompt for confirmation before they are applied. Bulk methods (such as Data Loader) do not provide those guardrails — take extra care when editing outside the UI.

---

Validation Checklist

Run this checklist periodically — weekly during peak season, monthly during off-season. The Inventory Setup section applies during initial configuration; the remaining sections apply to ongoing operations.

Inventory Setup

• Inventory status matches fulfilment requirement for each service
• Every service has at least one active inventory contract covering the required date range
• No date gaps between consecutive contracts for any service
• Allotment days generated for every inventory contract
• Units Total is correct for the contracted allocation on each allotment day

Allotment Day Health

• No unexpected Stop Sale flags on upcoming dates
• All dates within 90 days have been reviewed
• Booked counts match actual booking records (spot-check a sample)

Season Continuity

• No date overlaps between seasons for the same service
• New seasons created for the next selling period
• Old seasons reviewed and archived if no longer needed

Status Controls

• Stop sale flags have documented reasons (Remarks field or tracking sheet)
• Stop sale flags have review dates — none are indefinite without justification
• On Request dates have an active follow-up process for pending bookings
• Free Sale is applied only to genuinely unconstrained services

Release Tiers

• Tiers are active for the correct seasons
• Release day thresholds are still appropriate (dates have not passed the release day without being updated)
• Release unit quantities match current supplier contracts
• InventoryManagementScheduler is active in Scheduled Apex Jobs

Annual Rollover

• New inventory contracts created for the upcoming season (preferred over extending existing contracts, for clean year-on-year separation)
• Previous season’s contracts reviewed once all travel dates have passed (deactivation is not required — the system only evaluates inventory for the booking date, and the contract UI has no active/inactive filter)
• Allocation on new contracts reflects current supplier agreements

Package-Level Availability

• Every active package has been tested with a search for a date within the next 90 days
• Any package returning “unavailable” has been investigated to identify the blocking service
• Cross-service availability check has been run for high-priority packages

---

Common Issues and Solutions

Package Shows as Unavailable

Cause	How to Identify	Solution
One component service has no inventory contract for the date	Check each service’s contract date ranges	Create or extend the inventory contract
Allotment days missing when you expected rows for future dates	Allotment table empty or incomplete for the contract period	Confirm the contract time period is not entirely in the past and that allotment days do not already exist for those dates — see Allotment Days Not Generating
Stop sale on one service’s allotment day	Check allotment day status for each service	Remove stop sale if no longer needed
Contract set to inactive	Check the Active checkbox on the inventory contract	Reactivate the contract by checking the Active flag
Available count is zero on one service	Check allotment day Available field	Increase allocation or wait for cancellations
Units released to supplier	Check the Units Released field on the allotment day	If units were released back to the supplier via a release tier, request additional allocation from the supplier or adjust the release schedule
Service is inactive	Check the Active flag on the service record	Reactivate the service

Allotment Days Not Generating

Cause	Solution
Start and/or end dates are in the past	Allotment days are only generated for future dates. Update the contract dates to a future date range.
Allotment days already exist for the future dates in the contract	The system does not regenerate days that already exist. If you need to reset them, delete the existing allotment days first, then regenerate.

Stop Sale Not Taking Effect

Cause	Solution
Stop sale set on allotment day but date still appears available	The day-level stop sale should take priority. Double-check that the allotment day record was saved correctly.
Contract set to inactive but search still returns the date	In Salesforce the contract updates immediately, but package search and many website or portal flows depend on a background data sync — you cannot check that sync or API status from your org. Expect a short delay (often a few minutes) before the date disappears from search. If the problem continues, contact Kaptio Support to investigate.
Wrong allotment day updated	Verify the date on the record matches the date you intended to block
Stop sale applied on the wrong service	If the package has multiple services for the same component, confirm you updated the correct service

---

Related Schema Objects

These records belong to the Allotment Day and Inventory Contract model (AllotmentDay__c is a child of InventorySeasonStatus__c). They are not relationships on a separate Salesforce Inventory object.

Object	API Name	Relationship to Allotment Day	Purpose
Allotment Day	KaptioTravel__AllotmentDay__c	—	Per-date availability record with unit counts and stop sale
Inventory Contract	KaptioTravel__InventorySeasonStatus__c	Parent (Master-Detail)	Contract for the service (or package) that owns the allotment pool — fallback status, release rules, and related configuration
Itinerary Item Allotment Day	KaptioTravel__ItineraryItemAllotmentDay__c	Lookup	Junction linking booked itinerary items to allotment days for reporting
Package Departure Allotment Assignment	KaptioTravel__PackageDepartureAllotmentAssignment__c	Child (Master-Detail)	Junction linking package departures to allotment days
Reserved Allotment	KaptioTravel__ReservedAllotment__c	Child (Master-Detail)	Sub-allotments reserved for specific accounts or channels, with their own release schedule

For the full Allotment Day field reference and relationships, see Allotment Day — Kaptio Technical Documentation.

---

See Also

• Package Fundamentals
• Supplier & Service Setup
• Cost & Pricing Architecture
• Content Management
• Anyday Package Setup Guide
• Seasonal Package Setup Guide
• Fixed Departure Management
• Package Search Troubleshooting