Issue resolution: from error to ticket to verified outcome

Every unresolved item starts as a row in your exception list (Content maintenance covers it). Whoever resolves it will ask the same questions, so fill the row in first:

• the item references: Walmart item number, GTIN at the affected packaging level (Supplier catalog covers the levels), supplier stock number;
• the exact message or mismatch, its scope — one item, a range, a department — and the date first seen;
• the submission reference, its date and per-item result, plus a saved copy of the result file: Supplier One purges submissions automatically (currently after about 90 days);
• the current value as Walmart holds it: the export row or a dated screenshot;
• the intended value and its source: packaging specification, approved image file, content brief;
• what you have already tried, with dates.

"Images broken on the new range" cannot be worked; "main image missing on item 100000001, submitted on the 3rd, placeholder showing" can.

Then ask three questions in order; each names a path.

1. Can I change this in Supplier One? If the field is editable — attributes, content, images and packaging data through the Maintenance Hub, or a pending setup in the Setup Hub — it is a supported correction: fix, resubmit, confirm in the Submissions Manager.
2. Did my change apply? If the submission shows complete, nothing waits on a Walmart review, and the record or page is still unchanged after Walmart's processing window, it did not take effect. That, and anything you cannot change, is a support ticket — one issue per ticket, on the matching issue type; Supplier support tickets covers filing and follow-up.
3. Who owns the decision? If the data is right and the outcome is a merchant's choice — assortment and stores, a declined review, live-item structure you cannot edit, a stalled ticket with commercial impact — it is a merchant request: item numbers, intended result, evidence, any ticket numbers.

Take the lowest path that can produce the result.

• Rejected or stalled setup — a validation rejection names a field: yours (Item setup covers it). A merchant review ends three ways: updates requested, declined with a reason (the merchant's decision), or no movement: nudge the merchant; Walmart's help docs currently allow a ticket after about five days in Walmart Action Required. Stuck before validation with no reason: a ticket.
• Content not applied — upload complete, page unchanged. Still in Walmart review: wait. Otherwise allow Walmart's stated window (its content FAQ currently says hours, with a ticket if nothing shows after about a day). Record right, page wrong: a ticket.
• Wrong packaging-level data — a unit value in a case field, a wrong each-count. Fix where editable. The hierarchy itself (levels, GTINs, quantities) cannot be edited on an approved item: a wrong structure means a new item, agreed with the merchant so the old one is wound down. A locked field: a ticket.
• Item not orderable — check its status in the Catalog; some values are yours to update. If right, the merchant routes it.

• Item not on site — read the publish status and reason in the Catalog: a missing image, name or other content field is yours; a date, price, tax code, category or assortment reason (not carried online, inactive) goes to the merchant with the reason text. Published, no reason, no page after the window: a ticket.
• Duplicate items — one GTIN under two Walmart item numbers, or a setup rejected for an existing GTIN. If the existing item is yours, discard the new setup and maintain it; otherwise a ticket with both references, the merchant informed; Walmart decides which survives. Never maintain both.
• Variant groups — a Variant Group ID, attribute names, per-item values and a primary variant (the item the page opens on). If you supply every item in a live group, you can change its structure and primary in the Catalog in most accounts; a read-only group (items you do not supply) is a merchant request: item numbers, intended structure, intended primary. A maintenance file never regroups a live item. Variant groups and re-parenting covers it.

A reply that says "resolved" is not a resolution. For each issue, work the loop in this order:

1. Triage the issue into a scoped row with its family and owner.
2. Make the correction, or send the request or ticket, with the evidence attached.
3. Resubmit where you changed data, and confirm the result in the Submissions Manager.
4. Open the item record or the live page, compare it against the original issue, and only then close the row.

If the result is not visible, keep the row open, add a fresh dated screenshot, and reply inside the ticket while it is still open. Supplier One does not reopen closed tickets: once it is in the closed list, file a new one on the same issue type, naming the old number in its first line with the evidence reattached (Supplier support tickets covers it). Close a row by writing what you saw and when, not who replied.