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 what was added, changed, or removed — as three counts directly above the table, and as markers on the affected rows. Refresh re-runs that comparison for the selected brand. The three counts are clickable: choose one to show only the products carrying that kind of change, choose it again (or Clear) to go back to everything. Each count is a number of rows, not of individual price fields — a colorway whose MSRP and MAP both moved counts once. They stay visible even when the filter narrows the table to nothing, so you can always get back out.Change highlights persist until the brand’s next policy version. There is no
“accept” or “acknowledge” step that clears them, and nothing is marked as read
when you look at it. The counts and row markers are wholly replaced the next time
a new policy for that brand is approved and compared. Refresh re-computes the
same comparison on demand, so if nothing upstream has moved it returns the same
result — it is not a way to clear the highlights.
Colorways the previous policy priced and the new one does not. Shown as ghost
rows so you can see what stopped being covered.
Colorways the new policy prices that do not match anything you carry. These
never appear as table rows, so without this panel the counts above would be
larger than the number of marked rows you could find.
Rows in the Removed panel show a name of
— when they were recorded before
MerchantOps started stamping names onto removed entries. Pressing Refresh for
the brand re-computes the comparison and fills them in. Rows in the Added
panel always carry their names.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
MSRP, MAP, the four step-down prices and their start dates, and End MAP are
also editable on the product row. Saving there applies the value to every
colorway under that product as an ordinary colorway override — the same write
you would have made colorway by colorway.Each colorway is saved independently, and the result is reported honestly: you
are told how many of them took the value (
Applied to 3 of 5 colorways) and
how many already had a value that was replaced. A colorway that fails is never
counted as applied, and the ones that succeeded are kept — re-save to retry the
rest.The product row also carries its own note. That note belongs to the
product; it is deliberately not copied down to the colorways, which keep
their own notes.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.
Finding a row: identifiers, filters, and columns
Three identifier columns sit at the left of the table, before the prices:The MerchantOps product key, on the product row. (This column was previously
labelled Product Key; it is the same value, renamed and moved next to
Source.)
Your organization’s own colorway identifier, on catalog rows and on policy
rows that matched one of them. It is blank on a policy row that matched
nothing, because there is no colorway of yours to identify.The value is built 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.
The brand’s own code for the colorway, on catalog and policy rows. On a
product row it shows the brand’s style-level code, but only when every matched
colorway under that product agrees on it — if they disagree, or none of them
carries one, the cell is left blank rather than showing one colorway’s code as
if it stood for the whole style.
Any column except Source and Product / Colorway can be hidden from the
Columns menu, and your choice is saved to your own account — it follows you
to another browser and does not affect anyone else. A column that appears later
(a newly added identifier, or a product property newly set to show in lists)
starts visible. Column widths are not adjustable.
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.