About the benefits of a unified catalog

It is unlikely that the catalog scenario you are currently working with would change. Doing so would necessitate that any related POS systems or transactional databases must also change the way they store and transmit Item IDs. However, it’s important to note the benefits of using a unified catalog scenario, specifically:

• Catalogs do not have to be loaded multiple times.
• Catalog mappings need not be performed.
• Catalogs do not need to be updated across all stores, as all stores are working off of a single catalog.
• Additions or changes to the master catalog are not required, as the single, unified catalog is exactly the same across stores and master.

Lastly, when analyzing catalogs to determine which scenario they fall into, there are a number of key details to keep in mind. Here are a few items to watch out for:

• Do not confuse an external Item ID with a SKU. The Item ID is the identifier that is transmitted to SessionM when receiving transactions. SKU is the common identifier for classifying an item across all locations. While SKU typically remains constant per item within the catalog, Item ID can vary across locations in a disparate catalog scenario.
• While some stores may carry some items in stock and others may not, this difference alone does not disqualify using a unified catalog scenario. As long as the Item IDs are the same across stores, and the single catalog is uploaded to include all items that are covered across all stores combined, a single catalog should suffice.

As the difference between these two catalog scenarios results in varying steps for ingestion and management, additional instructions detail the disparate and unified versions. See Pre-Ingest: Assess Catalog Data and Methods of Catalog Ingest.