Block Parameters and Settings
Block parameters apply if your interface transmits blocks. All parameters are set at the global level.
Table 27-1 Block Group parameters and settings.
Parameter Name | Parameter Values | Direction of transmission where parameter applies.Parameter Description | Recommended Setting |
---|---|---|---|
EXTERNAL LOCKED YN |
Y/N |
From the external external system to OPERA Cloud. The system creating the block can remain the owner of it, which means the block can only be modified by the originating system. Set this parameter to Y if the block created by the external system should be locked in ORS and cannot be modified by ORS users. Set to N if the block created by the external system should be fully changeable in ORS. |
Set to Y in case blocks are sent two ways and both systems wants to retain ownership of their blocks. The default setting is Y for OXI-OPERA |
EXT SYS BLOCK GENERATES INVENTORY |
Y/N |
Direction: Data from the external system to OPERA Cloud When a block message from CRS is received, OXI will generate inventory snapshots for the affected dates and room types. |
Setting depends on the situations described. |
HANDLE BLOCK SOLD |
1) EXT_SYS- >OPERA 2)NONE 3)OPERA- > EXT_SYS 4)TRANSMIT_BOTH_ WAYS |
Direction: Data from the external system to OPERA Cloud (EXT_SYS- >OPERA) Update block sold count from external system when sent to OPERA Cloud. This assumes that the external system has all block reservations but not OPERA Cloud. In this case we need a sold count update as part of the block messages. Direction: Data both ways between the external system and OPERA Cloud (NONE) Block sold counts will not be transmitted between the systems. Use this if both systems transmit full reservations both ways, including block reservations. In this case an additional sold count update in the block message is not necessary. Direction: Data from OPERA Cloud to the external system (OPERA- >EXT_SYS) Send block sold counts from OPERA Cloud to external system. This assumes that OPERA Cloud has all block reservations but external system has not. In this case we need to send a sold count update as part of the block messages. Direction: Data both ways between the external system and OPERA Cloud (TRANSMIT_BOTH_WAYS) Update block sold counts from external system when sent to OPERA Cloud, and also return sold counts to external system. Use this if block reservations are not transmitted between the systems at all. In this case the block messages must mutually update the sold counts. |
Setting depends on the situations described. The default setting is NONE for OXI-OPERA |
HANDLE MASTER BLOCKS |
Y/N |
Direction: Data both ways between the external system and OPERA Cloud. OPERA Cloud can convert a single block into a master block, which is used when multiple sub blocks are linked to one block as master. A common scenario for this is a tour series, in which a former single block becomes a master block from which all tour series copies are made. The master block is visibly flagged as such in OPERA Cloud and has no inventory. A sub block is linked to a master block through the master block ID. If this parameter is set to Y, OXI will send master blocks in OPERA Cloud with the respective flags so that the external system can apply the same logic. Sub blocks are sent with the master block ID and need to be linked properly to the master block in the receiving system again, where the master could have a separate ID. If the external system is not capable of handling master and sub blocks, this parameter should be set to N. In this case OXI sends a block cancel in case a block converts into a master, to make sure that the external system releases the inventory from that block accordingly. All sub blocks in OPERA Cloud will be sent as normal single blocks without amaster block ID to such as an external system. |
Setting depends on the situations described. The default is Y for OXI-OPERA Cloud. |
KEEP BLOCK PACKAGES |
Y/N |
-> Direction: Data from the external system to OPERA Cloud. KEEP_BLOCK_PACKAGES parameter determines how to handle the existing OPERA Cloud block packages. This parameter setting will be significant only when the packages are not received as part of the blocks. If this parameter is set to Y, then do not full overlay, keep the block packages as-is. If this parameter is set to N, then full overlay the OPERA Cloud block packages with received block packages. If this parameter is set to Null, then the received allotment entity packages value will gain significance in determining whether to full overlay block packages or to keep them. |
|
SPLIT INV DETAILS |
Y/N |
-> Direction: Data from OPERA Cloud to external system. If Y, OXI will split the block inventory detail message into multiple chunks of size less than 32K. If N, OXI will send the entire inventory detail message to the external system. |
Set to Y if typical Block inventory is created with long date ranges and all room types. The default setting is N for OXI-OPERA. |
UPL CATERING BLOCKS |
Y/N |
-> Direction: Data from OPERA Cloud to external system Blocks can be flagged as Catering in ORS or SFA. Set this parameter to Y to send catering only blocks to the external system. If set to N, catering only blocks will be suppressed from sending to the external system. |
The default setting is N for OXI-OPERA |
UPL DED ONLY |
Y/N |
-> Direction: Data from OPERA Cloud to external system If the external system does not distinguish between deductible and non-deductible blocks, you may want to suppress non- deductible blocks from sending, as these would affect the other system’s inventory directly and cause inventory imbalances. In such a case you would set this parameter to Y and OXI_HUB will only send deductible blocks. If the external system has a similar concept of handling deductible and non- deductible blocks, you can set this parameter to N and OXI_HUB will send all blocks regardless of their status. In OPERA Cloud, the block status code determines whether a block is considered deductible. Check the OPERA Cloud block status configuration for further information. |
Set to N if external system handles deductible and non-deductible blocks. Otherwise set to Y. The default setting is N for OXI-OPERA. |
UPL OPEN ONLY |
Y/N |
-> Direction: Data from OPERA Cloud to external system. If the external system does not have a concept of ‘open for pickup’ blocks, you may want to suppress non-open blocks from sending, as these would still allow pickup in the other system and cause inventory imbalances when a reservation is sent to non-open block in OPERA Cloud. In such a case you would set this parameter to Y and OXI_HUB will only send open for pickup blocks. If the external system has a similar concept of open for pickup blocks, you can set this parameter to N and OXI_HUB will send all blocks regardless of their status. An open for pickup block is defined by its status. Check the OPERA Cloud block status configuration for further information. |
Setting depends on whether external system has a concept of open/non-open blocks. The default setting is N for OXI-OPERA |
WAIT FOR BLOCK EXT REF |
Y/N |
-> Direction: Data from OPERA Cloud to external system. If a block is created in OPERA Cloud, OXI can send the block header first and expect a result message with the external system’s confirmation number. Only once this confirmation is received would OXI send the block details, as it is now safe to assume that the block details would be accepted by the external system as well. This external confirmation can even be displayed on the block header as of OPERA Cloud 33.02, ensuring OPERA Cloud users that they can pickup reservations from a block without problems, as the external system knows the block as well. Set the parameter to Y if block transmissions shall be handled like this. Set the parameter to N if the external system does not return a response, or if it can safely handle block header and details at the same time. |
Set to N unless there is an explicit need that OXI should wait for the returned block confirmation number. |
Parent topic: Interface Controls