How to map product variations across stores with different catalog structures
Stores often present the same catalog differently. One may use a Black/White variable product while another publishes two simple products. Inventory mapping should follow the physical sellable item, not the storefront layout.
Model the physical stock unit first
Create one master stock identity for each item that can be counted separately. If black and white quantities differ, they must remain separate even when a parent page presents them together.
Use platform IDs for writes and SKU for human verification
Remote product and variation IDs tell the API exactly what to update. SKU remains valuable for search, review and exception handling, but duplicate or changed SKUs should not silently remap inventory.
Allow cross-structure mappings
A local simple product can map to a remote variation, and another remote simple product can map to that same local stock identity. The relationship should not require every store to share the same parent type.
Handle parent listings separately
A variable parent is usually a catalog container rather than a sellable stock unit. If every child variation is mapped, the parent should not remain in an unmapped queue solely because it has no independent quantity.
Operational checklist
- Map physical sellable units.
- Do not force identical catalog structures.
- Keep remote product and variation IDs.
- Exclude non-sellable parents from false unmapped alerts.