When You Say No, the System Does Not Say Yes for You
“Not written down” and “written down as no” are two very different things.
Sellers can disable a supplier for a hotel in their own catalogue. Searches used to ask that supplier anyway whenever the platform’s master data held a mapping. An explicit no now never falls back to the platform mapping, only pairs with no record use the platform default, and a catalogue that cannot be read stops the search with an error instead of a guess.
A hotel can usually be booked through several suppliers. Sometimes a seller decides that for this hotel, one supplier should not be asked for prices: the room types do not line up, or there is a commercial reason. So the seller marks that hotel-and-supplier pair as disabled or not listed in their own catalogue, and expects the obvious result: searches stop asking that supplier for that hotel.
The trouble was that “none” and “no” were treated alike. When a catalogue had no usable mapping, the logic fell back to the platform’s master mapping. Disabled rows were dropped entirely, which looked exactly like having no mapping, so the platform mapping stepped in and the supplier was asked anyway. The seller said no, and the system said yes on their behalf.
Each hotel-and-supplier pair in a catalogue now has three states. Enabled with the seller’s own supplier code: that code is used exclusively and the platform mapping steps aside. Explicitly disabled or not listed: no request is sent, nothing falls back, and the result records the supplier as skipped. No record at all: the platform default applies, so catalogues that cover only some hotels keep working.
A state the system cannot read sends nothing and falls back to nothing, and a catalogue that cannot be loaded stops the search with an error rather than a guess. The rule covers hotel lists, single-hotel rates and date-window searches alike, so every “no” in a catalogue is honoured, and the same supplier hotel code resolves separately for each seller’s catalogue.