Iceland - Minor (23.6)

2026-05-06

Minor Release

Booking Overview: Conditionally Enable Package Amendment Buttons Based on Package Departure Presence (ST-3203)

Cancel Room/Package, Modify, Transfer, and Change Occupancy buttons are enabled when at least one package with a package departure (ItineraryPackageDeparture__c) exists on the itinerary. Buttons are disabled if the itinerary contains only standalone services.

Cancellation Fee: Exclude Extension Package Items from BW Cancel Fee Total (ST-3239)

When cancelling a passenger via BW, the displayed cancellation fee does not include extension (Anyday/Seasonal) package price lines. Display only package related services (their cancellation fee).

Package + Any Day Package Amendments (Cancel/Modify/Transfer/Change Occupancy) (ST-3180)

This change improves amendment behavior when itineraries include extension packages (for example any-day or seasonal add-ons) alongside a principal fixed-departure package. Change Occupancy and Transfer Package Departure are now scoped to the principal package context so extension content no longer interferes with availability checks, room-assignment processing, or transfer execution. In practice, this prevents "no availability" and long-loading/hanging transfer scenarios caused by mixed package types, while keeping extension services out of principal-package amendment flows.

The update also improves Booking Overview behavior for agents by clearly separating what can be amended via Booking Wizard versus Cancel Services. Extension items are now surfaced as cancellable through Cancel Services without being treated as true standalone services, and action-button enablement better reflects itinerary state (including fixed-departure presence). Overall, users should see more predictable amendment outcomes: principal package changes complete correctly, extension services remain unchanged unless explicitly cancelled, and post-change screens (Booking Overview/Builder) stay consistent.

Support new supplier_cancellation_fees API endpoint (KT-14144)

Supplier cancellation fees via API: Salesforce now integrates with the new supplier_cancellation_fees KTAPI endpoint, sourcing cancellation fees directly from the backend instead of calculating them locally. This delivers consistent, up-to-date supplier cancellation fees across itineraries.

Hide Operations Pending itinerary items from Booking tab and clear Confirmed Quantity for cancellation items (KT-14297)

Itinerary items in Operations Pending mode are no longer shown on the Booking tab, and items moved to Unconfirmed Cancellation now have their Confirmed Quantity cleared.

Default Configurations for Price Model Modal (KT-14191)

Administrators can now define a reusable set of default Price Model configurations (Name, Sort Order, Occupancy Type, Integration Code) on a new shared ItineraryConfigurationTemplate__c object and link it to Channels via a new lookup. A dedicated Lightning record page with a visual editor (no manual JSON required) lets admins add, edit, and remove defaults in one place; updates propagate to every linked Channel automatically. When a user creates a new Price Model on a Channel with a linked template, the configuration table is auto-populated with the template’s defaults and remains fully editable before save. Edit and clone flows are unchanged, and Channels without a linked template keep the existing empty-row behaviour.

Data model changes for Fee Enhancements for Service record (KT-14244)

Data model changes for Fee Enhancements for Service record

Cancellation flow in re-evaluation processing (KT-14145)

Added automatic cancellation line creation during operational itinerary (OI) re-evaluation. When the re-evaluation detects that a previously confirmed service has reduced passenger quantity or has been deactivated, the system now automatically creates a hidden cancellation line linked to the original service. The cancellation line captures the cancelled quantity (confirmed qty minus new qty), sets the confirmation status to "Unconfirmed Cancellation", correctly assigns only the removed passengers, and calculate supplier cancellation fees. This covers scenarios including partial passenger removal (qty drops below confirmed), full service deactivation (mode changes from Active to Inactive), and passenger reassignments that exceed group size limits.

Service cancellation flow in operational itinerary (KT-14146)

Added support for triggering supplier cancellation cost calculations when cancelling services from operational itineraries. When a cancellation action is performed on an itinerary item in an operational itinerary (via deletion from the Builder tab or cancellation from the Booking screen), the system now automatically calculates cancellation fees based on supplier cancellation policies. The fix broadened the cancellation action matching from an exact "Send Cancellation" check to any action containing "cancel", ensuring all cancellation scenarios (including "Confirm Cancellation") correctly trigger cost calculations for operational itineraries.

Data Model & Metadata for Tax blending (KT-14168)

Introduced new objects (PriceModelTaxBreakdown__c, ServiceTaxBreakdown__c, ServiceTaxBreakdownAssignment__c) and a BeforeAdjustment__c field on Item_Price__c to support tax blending. These store the average tax split produced during Price Model calculation and propagate it through Tour Service Conversion to specific Departures and Price Seasons.

Extend KT-API Response Model to Include Tax Breakdown Data (KT-14172)

Tax breakdown data now persisted from KTAPI price calculations: When KTAPI returns a tax_info payload on price model output or season recalculation, the system now stores the revenue-weighted tax ratios as PriceModelTaxBreakdown__c records on the Price Model (one per Configuration and Sales/Cost applicability). Existing breakdowns are replaced on each recalculation, and responses without tax info continue to work unchanged.

Read PMTB and Create ServiceTaxBreakdown__c During Conversion + adjust the mapping for used price per person fields (KT-14175)

When converting a Tour to a Service, the wizard now reads PriceModelTaxBreakdown__c (PMTB) records from the source Price Model and generates corresponding ServiceTaxBreakdown__c (STB) records on the new service, so tax data is available for itinerary pricing.

Adjust Base Price for Tax exclusive scenario during Conversion (KT-14178)

When a Tour Service Conversion runs against a Price Model whose tax handling is exclusive, the per-person base price stored on Item_Price__c.Value__c is now re-derived from the inclusive quoted total using the effective blended tax rate from the ServiceTaxBreakdown__c. This ensures adjusted_base × (1 + effective_rate) = quoted_total for every pax band, even when the STB holds a single revenue-weighted tax ratio averaged across group sizes.

Full Reconversion - Clean Up and Recreate STB Records (KT-14179)

On a full reconversion, the Tour Service Conversion wizard now removes existing ServiceTaxBreakdown__c records (and their junctions, which cascade via Master-Detail) before recreating them from the current PriceModelTaxBreakdown__c data. This guarantees that the service-level tax breakdown, junction assignments, and BeforeAdjustment__c values always reflect the latest Price Model, with no orphans or duplicates left over from prior conversions.

Partial Reconversion - Selective Junction Record Updates (KT-14180)

When only specific departures (or seasons) are reconverted, the wizard now handles ServiceTaxBreakdown__c records selectively instead of wiping everything: existing STBs are preserved where the tax ratio is unchanged and only their junction records are refreshed for the affected departures, while STBs whose tax ratio has changed (because the Price Model was recalculated) are replaced with a new record and all junctions rebuilt. Non-reconverted departures/seasons and their Item Prices are left untouched.

Add tax rate to the TaxBreakdownJSON__c structure (KT-14322)

The TaxBreakdownJSON__c payload emitted by TourPriceModelTaxBreakdownService now includes the per-tax-group tax_rate alongside the existing tax_group_id, tax_group_name, and price_percentage. The rate is taken directly from the pricing API output rather than reconstructed downstream, so consumers (notably the tax-exclusive base-price adjustment during Tour Service Conversion) can compute the effective blended rate without having to re-resolve which tax / tax profile / validity window applies for a given tax group id.

'Add inventory' flow for package departures (KT-14120)

The Inventory Manager now supports creating inventory (allotment days) directly from Package Departure dates, extending the existing "Add Inventory" flow that was previously available only for Tour Departures.

What’s New:

"Edit inventory" for package departure flow (KT-14121)

Extends the inventory edit flow to fully support contracts that were created from Package Departures. Previously, only standalone date-range-based contracts could be edited; package-departure-linked contracts can now be opened, modified, and extended directly from the Inventory Manager.

What’s New:

Mass stop sales in Inventory manager (KT-14122)

Added Mass stop sales update logic in Inventory manager

Priority 1 by default in Inventory manager (KT-14124)

Changed Priority 1 by default in Inventory manager

Button styling improvements in Inventory Manager (KT-14126)

Changed button styling in Add/Edit Inventory modal

Form layout, spacing, and label alignment in Inventory Manager (KT-14127)

Changed Form layout, spacing, and label alignment in Inventory Manager as UI improvements

Mass delete in Inventory manager (KT-14129)

Added Mass delete logic in Inventory manager

- Add new section in OI re-evalaution request about booked and reserved inventory (KT-14280)

Introduced a new map in the request, allotment_day_changes, to ensure the API is aware of already booked and reserved units during Operational Itinerary (OI) re-evaluation, enabling correct inventory calculations

- Cancel Passenger from Operational Itinerary Grid (KT-14198)

Operational users can now cancel a passenger directly from the Passengers Grid on the Operational Itinerary, without needing to navigate to the passenger record or use a separate cancellation flow. Cancelling a passenger from the grid cascades through all related records (configuration assignments, room assignments, rooms) in a single transaction.

Switch off all payment schedule calculations for OI (should be patchable) (KT-14217)

Added logic to switch off all payment schedule calculations for Operational Itineraries

Long-term solution for payment schedules in Operational itineraries (KT-14218)

Added logic to run PaymentSchedule after re-evaluation is completed.

Cabin Allocation Tool: UI Improvements - row count, dropdown z-index, column sorting/width, filter UX, Booking Status mapping (KT-14221)

Made Cabin Allocation Tool: UI Improvements PDS - Remove CabinAndSeatingTool.flexipage-meta.xml in the packaging org before starting the build

Display Salesforce validation rules on payment tab (KT-14085)

Payments: Salesforce validation rule errors now displayed on the Payments tab. Previously, when a Salesforce validation rule prevented a payment from being saved, the error was silently logged to the browser console and not visible to the user. Validation rule messages are now displayed as toast notifications on the Payments tab, giving users clear feedback on why a payment could not be saved.

Prevent users from creating overlapping price seasons (KT-14195)

Improved Time Period overlap detection in Item Price Manager: The overlap check when saving Price Seasons now correctly compares Time Periods across all other seasons on the item (not just the one being edited), identifies the record being edited reliably, and uses correct date/weekday comparison logic. Behavior respects the Price Setting Overlap Validation setting (Soft warns, Hard blocks).

Prevent users from creating overlapping price items with same price category (KT-14206)

The Item Price Manager now prevents saving Item Prices whose Price Category / Add-on / Meal Plan assignment would overlap with another price on the same Item under an identical pricing context. The validation runs on both the server and the Price Manager UI, and is gated by a new AppSettings__c.PriceSettingOverlapValidation__c setting so orgs can choose Hard (block save) or leave it off.

Add custom setting for price season and price categories validation (KT-14219)

Configurable Price Season and Price Category overlap validation: Added a new Price Setting Overlap Validation option in App Settings that lets administrators choose how overlapping Price Seasons and Price Categories are handled: Soft (default) shows a warning the user can acknowledge, while Hard blocks the save until the overlap is resolved. Existing orgs keep current behavior via the Soft default and can opt into strict enforcement when ready.

Supplier Agreement - New field for Supplier Agreement Name/ Modal window extension (KT-14347)

The New / Edit Supplier Agreement modal now supports an additional, configurable input field rendered above the existing form rows. The field is driven by a new FieldsOnNewSupplierAgreement fieldset on SupplierAgreement__c, so admins can expose an extra field (for example, a descriptive Supplier Agreement Name) without code changes.

Truncate Supplier Name When Creating SupplierInvoiceBooking Records (KT-14338)

Release Notes:

Supplier Invoice Booking Name Length Handling

Problem/Background

In some cases, supplier names copied into Supplier Invoice Bookings could exceed the maximum length supported by the booking Name field. When this happened, booking creation could fail and interrupt supplier invoice processing.

Solution

Supplier Invoice Booking names are now automatically truncated to the maximum length supported by the Name field before the booking is created.

This update applies consistently to both supplier invoice booking generation paths.

Impact

Supplier invoice processing is now more resilient when supplier names are unusually long.

This reduces the risk of booking creation failures caused by field length limits and helps supplier invoice records continue to generate successfully without manual intervention.