Policies vs. prices
A MAP policy is the document for a brand. It contains many MAP prices — one per product identifier — that state the minimum advertised price. Policies are versioned: when a brand issues a new one and it is approved, it supersedes the previous active policy for that brand. Each policy carries a status:MAP policies are usually ingested from a brand’s uploaded file. A per-brand parser
template maps that file’s columns and date format so future uploads for the brand
extract consistently.
Sharing is off by default
MerchantOps is multi-tenant, and most reference data (brands, product knowledge) is shared across organizations. MAP policies are the exception. Because a MAP policy is a legal agreement between a specific brand and a specific reseller, sharing it across organizations carries legal and compliance risk. So MAP-policy sharing is off by default: a policy you contribute stays private to your organization unless sharing is explicitly enabled.Governance
MAP policies follow a review workflow with roles and organization-scoped rules:requires approval permission
Approving or rejecting a policy requires the MAP approval permission. Approving
a policy supersedes the brand’s previously active policy. Rejecting requires a
reason; rejected data is preserved and flagged, and the contributing
organization can fix and resubmit or delete it.
restricted
Only policies in
pending_review, rejected, or draft states can be deleted —
an approved (active) policy cannot. Only the organization that contributed a
policy can delete it. Deleting a policy removes its prices but never touches
your products.The MAP Policy page
The MAP Policy page (Pricing → MAP Policy) is where a policy meets your catalog. Pick a brand and MerchantOps shows that brand’s active policy merged with your products, grouped by product and then by colorway, so you can see the brand’s MAP and MSRP next to the prices you actually carry. Viewing the page needs pricing read permission; everything that changes data needs pricing write. Each row is classified by how the policy and your catalog line up:Detecting changes
When a brand issues a new policy, MerchantOps compares it against the brand’s previously active policy and shows exactly which prices were added, modified, or removed — as a banner with counts, as filter chips, and as markers on the affected rows. Refresh re-runs that comparison for the selected brand. Working through the changes:requires pricing write
Where the brand’s value is wrong or you have agreed something different, you
can override an individual field on a colorway. Overrides stay visible on the
page so the difference between your value and the brand’s is never hidden.
requires pricing write
Flag a colorway — or a whole product — as ignored, to record that you have
decided not to act on it. The row and its MAP data stay fully visible, dimmed
and badged as ignored. An ignore is anchored to your catalog, so it survives
future policy uploads until you un-ignore it.
requires pricing write
Accept All Changes (or Accept Overrides, when overrides are the only
thing pending) records the current merged view — brand values plus your
overrides — as your organization’s accepted snapshot of the policy, and clears
the banner. Until you accept, an override counts as pending. Editing an
override after accepting flags it as pending again.
requires pricing write
For a colorway the current policy does not price, search the brand’s earlier
policy versions for a matching colorway and link its prices to your colorway,
rather than leaving the row empty.
The Style-Color ID column is filled from a per-organization display-ID
template set under Settings → Pricing. A blank cell means either that your
organization has no template configured, or that this particular colorway is
missing one of the values the template refers to — MerchantOps leaves the cell
blank rather than showing a half-resolved ID. It is not an error.
Stale changes from a superseded policy
When a new policy supersedes an older one, price records and batches you generated from the old policy are not cleaned up automatically. If any exist for the selected brand, a banner appears on the MAP Policy page; reviewing it shows what is stale, and purging supersedes those price records and cancels batches that are entirely stale. Records and batches that have moved on under their own steam are left alone.Generating price changes
From an accepted policy, price changes are generated one colorway at a time from the MAP Policy page — there is no bulk “compare the whole brand and generate everything” run.1
Generate Price Changes
On a colorway, choose Generate Price Changes. MerchantOps takes the
MSRP, MAP, and step-down values as displayed for that colorway (including
any overrides) and diffs them against the prices you currently have for its
variants.
2
Review the pre-filled Set Prices dialog
The Set Prices dialog opens pre-filled with the result. Each line is
marked New or Changed and shows the price it would replace. Lines
that match what you already have are treated as unchanged and left out, so
you only submit real changes. You can still edit any amount or date before
saving.
3
Resolve conflicting future prices
If those variants already have future-dated price records that the new ones
would collide with, the dialog lists them so you can decide what happens to
them.
4
Save into a policy batch
Saving creates the price records and puts them in an open
price batch named after the brand’s policy and
version, so everything generated from one policy travels together. From
there the normal batch lifecycle applies: submit for review, approve, and
publish on the effective date.
Price records
MAP as a per-variant price record.
Price batches
Review, approve, and schedule the generated changes.