Skip to main content
A comparison run measures a brand’s MAP policy against the prices in your catalog and produces a set of price-change proposals — one per product/colorway where your price differs from the policy. You review each proposal, approve or reject it, and roll the approved ones into a price batch. This page is for merchandisers keeping catalog prices aligned with brand policy. See also MAP policies and Price batches.

​
The flow

1

Run a comparison

Trigger a comparison for a brand against its active MAP policy. It runs in the background and produces proposals for the differences it finds.
2

Review the proposals

Work through the proposals — each shows the current price, the proposed price, and the change. Approve, reject, or modify the amount.
3

Group approved proposals into batches

Preview how approved proposals group into batches (by effective date, or by brand and date), then create the batches.
4

Approve and publish the batches

From here the normal batch lifecycle applies: submit for review, approve, and publish on the effective date.

​
Comparison runs

A run is scoped to a brand and compares against that brand’s active MAP policy. Each run is tracked with a status and summary counts, and you can list, search, archive, or delete runs. Deleting a run also removes its proposals — but a run whose proposals have already been assigned to a price batch cannot be deleted until those batches are removed first, so batched work is never orphaned.

​
Reviewing proposals

Each proposal represents a proposed price change for a product colorway. When you review it you can:
​
Approve
accept the change
Accept the proposed price as-is.
​
Reject
decline the change
Decline the change; the current price stays.
​
Modify
accept a different amount
Approve the change but override the proposed amount with your own.
You can review proposals one at a time or batch-review many at once with the same decision. Proposals can be filtered by brand, status, comparison run, or an exception flag, and searched by product name, key, or style ID.

​
Matching and coverage

A proposal is expressed at the style-color level and fans out to the underlying variants. Because merchant catalog identifiers vary, MerchantOps flags how confident the match is (matched, not_carried, or unsure), and you can:
  • Override the match status when the automatic classification is wrong.
  • Manually link variants to a proposal when the automatic fan-out missed them.
  • Check unpriced colorways — catalog colorways in the run with no matching proposal — so nothing slips through unpriced.
You can also create a manual proposal for a colorway directly, without a comparison producing it.

​
From proposals to batches

Once you have approved the proposals you want, preview the batches they form and create them. Grouping is configurable:
Grouping modeBatches are formed by
effective_dateEffective date only.
brand_and_dateBrand together with effective date.
The created batches then follow the standard review and scheduled-publishing workflow described in Price batches.

MAP policies

The policies comparisons run against.

Price batches

Review, approve, and schedule the resulting changes.