Journeys & operations

Catalog operations

The working procedures: how catalog updates flow to InComm, how to judge whether an old offer is safe to reuse, and how to check whether a UPC was in a catalog on a given date.

How a catalog update works

1. A catalog change (new items, removals, a new catalog) is written to our database and pushed to InComm's catalog API in the same operation. One update, two destinations.
2. InComm applies the change on their side. From then on the registers enforce the new list.
3. Because both sides update together, our incommcatalogitems mirror is normally in sync. The reverse direction (pulling InComm's state into ours) is a manual per-catalog sync action, used when you suspect drift.

Every pushed item carries a UpcSource tag and a CreatedOnDate. These are your audit trail: they tell you which sweep added an item and when.

Judging an offer's age and health

Before reusing an existing offer, establish how old it is and whether it ever ran:

1. Open the offers list view. Read Start Date (this is OfferStart) and No. of Clips.
2. Sync first: No. of Clips is populated only by the sync action. An unsynced row shows stale counts.
3. Rules of thumb: an offer from 2023 predates the current team, treat it as suspect. A near-zero clip count means it was retired quickly or never used.

An old offer is still usable if you do two checks:

1. Check the offer's fields. Open it and make sure every field carries current taxonomy (name, tags, verbiage, terms).
2. Check the catalogs powering it. Go to the catalogs list, find the offer's catalogs, and read their update time. Download the catalog and compare its size against other catalogs that do similar work. Check whether our newer offers use the same catalog or a newer replacement.

Checking a UPC against an offer's catalogs

The classic support question: "should this item have been approved?" Two methods:

Option 1: download the catalogs (slower)

Download each catalog in the offer and search the GTIN_FOR_CATALOG column of the Excel for the UPC. That column is our incommcatalogitems.Upc field, already in InComm space. Works, but slow across multiple catalogs.

Option 2: query the database (faster)

SELECT IncommCatalogId, Upc, CreatedOnDate, UpcSource, ProductTitle
FROM incommcatalogitems
WHERE IncommCatalogId IN (151,138,157,144)   -- the offer's catalog IDs
  AND Upc = '00005310074943';                -- the UPC you are checking

Why an ineligible item was approved anyway

When item-level data shows a purchase that looks like it should have been blocked (nail polish remover on a food benefit, say), check the dates before calling it a bug:

• The register enforces the exclusion list as it existed at purchase time. If the UPC was added by a later catalog sweep, the purchase was legitimately approved back then and would decline today.
• CreatedOnDate and UpcSource on the catalog item tell you exactly which sweep added it and when.

This false alarm has already come up in real item-level reviews. Date-check first.

Where catalog source data comes from

Catalog sweeps pull UPCs from three source systems. The UpcSource tag on each item tells you which one it came from: