Bundle Variant - Financial Calculation Request

GraphQL Admin API Troubleshooting
1

Hi There,

With the current mutation VariantRelationshipBulkUpdate when a bundle is sold it attributes to value of the bundle proportionally to the items within the bundle (assuming by price on product).

I would be really useful if you would be able to control how the bundles price is applied across the components, so that the cost is only associated to the products you want them to be.

This would help with refunding/exchanges specific products and duty/taxes where it is calculated off the lineitems on the order, and non-deliverable items will not be included due to the weighting.

see below suggested inclusion (happy to field ideas)

mutation CreateBundle($input: [ProductVariantRelationshipUpdateInput!]!) {
    productVariantRelationshipBulkUpdate(input: $input) {
      parentProductVariants {
        id
        productVariantComponents(first: 10) {
          nodes {
            id
            ****
            costWeight {
               includeInCalc (Yes/No)
               weightForCalc (0-100)
            }
            ****
            productVariant {
              id
              displayName
            }
          }
        }
      }
      userErrors {
        code
        field
        message
      }
    }
2

Hi @ChrisBradley! You’re right that currently the bundle price allocation uses a weighted algorithm that’s automatically calculated based on component prices - you can’t control how the bundle’s price is distributed across components.

Right now there’s no way to control this weighting through the productVariantRelationshipBulkUpdate mutation or any other API. The ProductVariantRelationshipUpdateInput only has fields for parent/component associations, quantities, and the parent price - nothing for controlling individual component price allocation.

This could definitely be a useful addition however, so I’m going to go ahead and raise a feature request on your behalf internally. Can you share a bit more detail about:

  1. What types of products are in your bundles that should have different price weightings? (e.g., physical products + non-deliverable digital items)
  2. Which markets/countries are you most concerned about for the duty/tax calculation issue?
  3. Are there specific scenarios where refunds/exchanges are particularly problematic with the current proportional allocation?

In the meantime, Cart Transform functions with the expand operation let you set individual fixedPricePerUnit for each component, giving you full control over price allocation. This might solve your use case - you could allocate $0 to non-deliverable items and distribute the bundle price however you want across the physical components.

3

Hi @Donal-Shopify

Thanks.

From our side, we have Bundles that include both physical items and services, so for example we have a product that has the option to engrave something on it.

We cant really include the service in the import documents, as the item does not exist in the package and has no HTS/HS code, but we are effectively undervaluing the item(s) that are being delivered.

We can’t reduce the price of the services, as it is effectively an option to add on as well.

From our point of View, we are concerned about USA/UK/Europe mainly but assume this would be an issue for other regions that collect VAT/Duty at the boarder.

With regards to refunds, as the price is being split across say a bundle of 4 items, the price of that item is being split unevenly. If we need to do an exchange of an item, the price would not align with the replacement price. additionally, if we needed to refund an item, the price would not be the price of the individual item.

For example:

  • Bundle = $300

Item A = $200RRP / In Bundle $200 / Weighted Value $176.49
Item B = $100RRP / In Bundle $100 / Weighted Value $88.24
Service C = $30RRP / In Bundle $0 / Weighted Value $26.47
Service D = $10RRP / In Bundle $0 / Weighted Value $8.82

Current Scenario
a) we would only be declaring Item(s) A-B on import, so Duty/Tax Declaration would be $264.71 vs $300.
b) if we needed to exchange say item B, we would be returning $88.24 and then replacing with $100.00
c) if the customer no longer needed say service D, they would assume they are getting a refund of $8.82 whereas we are just including it in the price.
d) If the customer is returning item B, the price displayed on the UX would be not aligned to the expected price.
e) Customer would see total of invoice/declaration of only $264.71 not $300.00

4

Appreciate the detailed breakdown Chris!

I’ve passed this context as a feature request to the Bundles team internally. I can’t make any promises at this juncture, but the more a specific feature is requested by our merchants and partners, the more likely it is to be considered for future development by our product teams.

In the meantime, the Cart Transform functions approach might be able to give you the granular control you’re looking for - you’d just be managing it through the function rather than directly on the bundle mutation.

Thanks again for raising this with us!