Travunio
Travunio knowledge center

Supplier data updates without losing mapping history

Learn how to handle supplier hotel files, full snapshots, delta feeds, invalid rows and versioned mapping changes without losing source history.

The short answer

A controlled supplier update validates the incoming batch, compares it with the previous source version and publishes only approved changes. It distinguishes missing rows from explicit withdrawals and preserves the history of each supplier profile and master relationship.

Declare the scope before the import

Record the supplier, file timestamp, schema, geographic scope and whether the file is a full snapshot or a delta. A city-only export cannot be treated as the supplier's global catalog. A failed or truncated download should fail validation instead of deactivating records.

Stage records and detect changes

Validate required keys, country values, coordinate ranges and duplicate source keys. Preserve raw values before normalization. Use a repeatable fingerprint of relevant fields to classify records as new, changed or unchanged. Repeated uploads should produce a consistent outcome without duplicating completed work.

Separate profile changes from identity changes

An updated description, phone number or supplier status can change a profile without changing the underlying property. A reused hotel code or a move to a different property needs identity review. Do not overwrite an approved relationship silently when new evidence conflicts with its original basis.

Publish with a recoverable history

Store batch results, rejected rows, review decisions and the previous approved state. Missing rows become candidates for a supplier-specific status check only after full-snapshot completeness is verified. A release should make additions, changes and withdrawals explicit and allow a team to investigate or reverse an incorrect update.

Related questions

Does a new supplier file need to remap every hotel?

Unchanged records can retain their existing approved relationships. Identity-relevant changes should trigger reevaluation under the current versioned policy.

What if a supplier reuses a hotel code?

Treat a code whose property evidence has materially changed as an identity conflict. Preserve the old relationship history and require review before publishing a new relationship.

Should supplier updates automatically change the matching algorithm?

No. Incoming data and matching-policy releases are separate processes. Verified corrections can inform a candidate improvement, but it needs evaluation and approval before release.

Bring your data together

A clearer identity starts here.

Explore the mapping workflow. Build a brief around your data.

Find your next answer.