> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axisdata.net/llms.txt
> Use this file to discover all available pages before exploring further.

# RatePlans and MultiContracting

## Purpose

This page explains how to implement **multicontracting** in both the **Push** model and the **Pull** model. It also clarifies how RatePlan codes are structured under multicontracting and shows concrete XML examples.

## Overview

Multicontracting lets you distribute **multiple contracts under a single hotel code** so that the system can surface **the best availability and rates across different contracting models** (e.g., integrated vs. manual), and also support **simple packages** (hotel + other products). This functionality is **ready for PROD**.

Under multicontracting, the **RatePlan code** is extended from the original 5-character concept to a **three-part code**:

\[simple-package-code]-\[contract-code]-\[rateplan-code]

Example:

**AR-OWN1-S0000**

Where `AR` is a simple package (Accommodation + Car), `OWN1` is the contract code, and `S0000` is the rateplan code.

> **Note on RatePlan code details**: visit [RatePlan codes](../glossary/codes#rateplan-codes)

RatePlan codes are constructed from the below elements
Rate Type(1), Rate Group(1), Rate Refund(1), Rate Sub Type(2)
Example: BHSP2 – BAR Rates - Hotel only - Semi-flexible – Promotional Rate 2

There is also a possibility of duplicating RatePlan which already exists in the contract. In this
case the “.” character, and a number starting with 1, and then subsecuently every iteration.
Example: BHSP2.1

### Code Construction

RatePlan codes are constructed from the below elements:\
**Rate Type (1), Rate Group (1), Rate Refund (1), Rate Sub Type (2)**

| Rate Type |              | Rate Group |            | Rate Refund |                | Rate Sub Type |                     |
| :-------- | :----------- | :--------- | :--------- | :---------- | :------------- | :------------ | :------------------ |
| 0         | Rates        | 0          | undefined  | 0           | Undefined      | 00            | Undefined           |
| R         | Retail rates | H          | Hotel only | N           | Non refundable | A0            | Advanced Purchase   |
| S         | Static rates | P          | Packaging  | S           | Semi-flexible  | A2            | Advanced Purchase 2 |
| F         | FIT Rates    | O          | Opaque     | F           | Flexible       | A3            | Advanced Purchase 3 |
| B         | BAR rates    | R          | Rack       |             |                | P0            | Promotional Rate    |
|           |              |            |            |             |                | P2            | Promotional Rate 2  |
|           |              |            |            |             |                | P3            | Promotional Rate 3  |
|           |              |            |            |             |                | P4            | Promotional Rate 4  |
|           |              |            |            |             |                | P5            | Promotional Rate 5  |
|           |              |            |            |             |                | P6            | Promotional Rate 6  |
|           |              |            |            |             |                | P7            | Promotional Rate 7  |
|           |              |            |            |             |                | P8            | Promotional Rate 8  |
|           |              |            |            |             |                | P9            | Promotional Rate 9  |
|           |              |            |            |             |                | 01            | \[1]                |
|           |              |            |            |             |                | 02            | \[2]                |
|           |              |            |            |             |                | 03            | \[3]                |
|           |              |            |            |             |                | 04            | \[4]                |
|           |              |            |            |             |                | 05            | \[5]                |
|           |              |            |            |             |                | 06            | \[6]                |
|           |              |            |            |             |                | 07            | \[7]                |
|           |              |            |            |             |                | 08            | \[8]                |
|           |              |            |            |             |                | 09            | \[9]                |

#### Rate Type

* **0** → Not defined – rate stays unchanged like in the basic contract edition.
* **B** → Bar - best available rates (changing due to rate updates)
* **S** → Static – unchanged contract rate till the time of a promotion or an offer introduction
* **F** → FIT - free individual traveller rates
* **R** → Retail – advised end-price

#### Rate Group

* **H** → Hotel only - rates valid when booking contains only hotel
* **P** → Packaging - rates valid when booking contains hotel + another product
* **O** → Opaque - hotel rates must not be visible for end consumer
* **R** → Rack - walk-in hotel rates for end consumer

Funcionality of the Rate Group:
The Rate Group indicates the distribution that needs to be followed. When the Rate Group is marked as P or O, these rates should not be visible to end users and may only be used as part of a package, ensuring they are not directly exposed.

#### Rate Refund

* **N** → Non refundable - immediately after booking
* **S** → Semi-flexible – cancellation without fees up to 12 hours after booking
* **F** → Flexible – cancellation without fees up to 24 hours after booking

Functionality logic of Rate Refund – 3nd character of rateplan:

* If there is a character N on the rateplan 3rd position means it’s completely non-refundable OR at the roomtype code on the last position
* When the character is 0 and IF there is no rateplan NOR N as the last character of the room code, means the room is refundable and conditions will be shared on the Vendor Messages on the AvailRS and ResRS (Quote/Book)

#### Rate Sub Type

* **A** → Advanced Purchase - booking has to be paid before confirming
* **P** → Promotion Rate

RatePlan Codes can be expressed by two following options:
**Concatenated codes** → adding to the room code the Rateplan Code - "RMSD000000;0PNA0"
**Separated codes** → this requieres the implementation of a RoomKey attribute, because the communication will be as a separate room code attribute RMSD000000" and an attribute RoomKey "0PNA0".

The option chosen by the client has to be set in our system.

## Pull Model

### What Changes in Search Results

Search results for the same hotel may include **multiple contracts as RatePlans**, allowing integrated and manual contracts to **compete** for best availability and price across seasons/windows.

If you need to **de‑duplicate or filter** multicontracting search results, you can use the following request switches explained in [OTA\_HotelAvailRQ](../hotel/searchRQ#pos-point-of-sale)

### What to Send / Receive in Realtime

* **Use `RoomTypeCode` in realtime messages** instead of a RatePlan ID.

**OTA RS examples (RoomTypeCode variations under multicontracting)**:

```xml theme={null}
<!-- Before: single-contract style -->
<RoomType RoomTypeCode="STSD000000;FP000" />

<!-- After: multicontracting examples -->
<RoomType RoomTypeCode="STSD000000;-ABC1-" />                <!-- Contract identified by ABC1 -->
<RoomType RoomTypeCode="STSD000000;AR-ABC1-FP000" />         <!-- Simple package AR + contract ABC1 + rateplan FP000 -->
<RoomType RoomTypeCode="STSD000000;-OWN1-FP000" />            <!-- Manual contract OWN1 + rateplan FP000 -->
<RoomType RoomTypeCode="STSD000000;AR-ABC1-" />               <!-- AR package + contract ABC1 with no specific rateplan code -->
```

### Package Examples (Search / Book)

* **Accommodation+Car**: `AR-OWN1-S0000` (room might be `STSD000000-ECMR` for car class).
* **Other simple packages** supported conceptually: ski (`SP1`), golf, spa, yoga, cooking classes, etc. (package prefix + contract + rateplan).

### Implementation Notes

* For **non‑refundable identification**, ensure you read the **3rd character from the end** of the RatePlan code (due to the extended prefixing), not the 3rd from the start.
* Clients using **pull** and **push** models have **no behavioral impact** beyond the longer RatePlan codes.

***

## Push Model

### What You Receive

Partners with a multicontracting + rateplan integration receive the relevant information **via notification files**; the format is equivalent across notification variants.

### How RatePlans Are Delivered

You can consume RatePlans in notifications in **two ways**:

1. **Concatenated** into the RoomCode, e.g. `RMSD000000;OwWN1-P0N00` (no dev to add a new field, but existing room mapping must be updated and any “best price” logic on mapped codes may only surface the cheapest option). Non‑refundable plans may exist in rooms without an `N` at the 10th position.

2. **Separate attribute** via `RoomKey` / `RatePlanID`, e.g. RoomCode `RMSD000000` and RoomKey `P0N00.2`. This keeps mapping unchanged, but requires implementing the RoomKey attribute (not available in OTDS).

#### Examples (Separate Code)

**OTA**

```xml theme={null}
<RatePlans HotelCode="AESSVQ4GKU">
  <RatePlan RatePlanID="OWN1-P0N00" ...>
    ...
  </RatePlan>
</RatePlans>
<SellableProducts>
  <SellableProduct InvCode="RMSD000000" InvType="ROOM" ... />
</SellableProducts>
```

**EDF / ASNF**:

```xml theme={null}
<!-- EDF (RoomKey + RateCode provided) -->
<Room Code="AP00T10000" RateCode="-SUP1-0P000" RoomKey="-SUP1-0P000" />

<!-- ASNF (RatePlans element) -->
<Room Code="AP00T10000" Name="1 Bedroom Apartment">
  <RatePlans>
    <RatePlan Code="-SUP1-0P000" />
  </RatePlans>
</Room>
```

### Packaging Support in Notifications

Simple packages are supported via the **simple-package-code** prefix. For instance, an Accommodation+Car package uses `AR`, with the car type appended to the room when applicable (e.g., `STSD000000-ECMR`).

### Flatfile Users

If you opted for concatenated codes, the **room code field and the rateplan code size** are extended in **Version 3** of the flatfile definition.

***

## At a Glance

**Examples tied to a single hotel & room:**

* HotelCode `AESPMI1234`, RoomCode `RMSDDB0000`, `RateplanCode="-ABC1-0P0A0"` → Contract `ABC1` with a **Packaging Advanced Purchase** rateplan from the hotel.
* HotelCode `AESPMI1234`, RoomCode `RMSDDB0000`, `RateplanCode="-DEF1-S0N00"` → Contract `DEF1` with a **Static, Non‑Refundable** rate.
* `RateplanCode="-OWN1-"` → Manual contract with **no rateplans** in the contract.
* `RateplanCode="AR-OWN1-S0000"`, RoomCode `STSD000000-ECMR` → **Accommodation + Car** package using contract `OWN1` and static rates; `ECMR` denotes an **Economy Manual A/C** car class.

***

## Next Steps

* INT examples (RQ/RS) and a Postman collection are available for integration tests. Provide feedback on your test cases, complete **certification for multicontracting**, and then roll out to **PROD**.

***

## Appendix

* If your distribution excludes Opaque or Packaging rates on hotel‑only websites, re‑check any code parsing logic to account for the **prefixed** code structure.
* Test users: `TST3` (separate code/RoomKey) and `TST4` (concatenated code).