The issue occurs when matching BC items to the shopify items. The graphXML request being made by BC to the shopify site is using a fuzzy match rather than a unique match so if an item shares a similar SKU name it can match on the wrong item, so when it uploads the item it overwrites the existing item details with the new details.

when it sends

{"query":"{productVariants(query: "sku:BB GIN ", first: 1) { edges { node { legacyResourceId product { legacyResourceId }}}}}"}

Shopify have checked the issue and responded with the following reply.

Thanks for the detailed evidence on the BB GIN / BB-246 case, that made it much easier to pin down exactly what happened. Good news: this comes down to how the search query was formatted, so it's something your Business Central partner can fix on the connector side.

Here's what's going on. When a search value contains a space, like "BB GIM", it needs to be wrapped in quotes to be matched as one exact phrase against the sku field. Without quotes, Shopify only sends the first word (BB) to the sku field, and treats everything after the space as a separate, open-ended search term that gets checked against title, tags, vendor, and other fields on the product, not just the SKU. That's why an unrelated product, BB-246, came back as a match: its SKU contains "BB", and something elsewhere on that product happened to satisfy the second part of the query.

A couple of related points worth passing on to your Business Central partner:

* Any SKU search containing a space (or similar composite value) should be quoted, for example: productVariants(query: "sku:"BB GIN", first: 1). This ensures the whole value is matched as a single phrase against the sku field only.

* The first: 1 argument only limits how many results come back, it doesn't guarantee an exact match. If the underlying query is broader than intended (as it was here), first: 1 will simply return whatever ranks highest for that broader search, which is exactly what happened.

* As an extra safety net, it's worth having the connector double check that the sku field on the returned variant matches the intended SKU exactly before treating it as a valid match and writing any updates.

But as the code is from microsoft we cannot change this behaviour, also BC does have events in this functions that we could use to overwrite this behaviour but they are all marked as internal so are no accessible in custom code.

They are saying it should be

{"query":"{productVariants(query: "'sku:BB GIN '", first: 1) { edges { node { legacyResourceId product { legacyResourceId }}}}}"}