API Version >= 2020-04 Cannot make compare_at_price = price?

Chris_Forte
Shopify Partner
6 0 1

Here is the change: 

"New validations on pricing
As of version 2020-04, a product's compare_at_price must always be higher than its price. Adding this validation will enable apps to trust the relationship between these values, allowing them to surface the compare_at_price in new areas (i.e. on a receipt) without worrying about odd values."

Why only higher? Why can't I have compare_at_price >= price, only compare_at_price > price?

If I try to set compare_at_price = price I get an error on API versions >= 2020-04.

So, I can't have $10.00/$10.00, price/compare_at_price, but I must now have $9.99/$10.00?

This looks bad if you're displaying percentage discounts on the store front.

ryanpwaldon
Explorer
51 6 12

Can you set the compare_at_price to be undefined instead? Or does this not work either?

Chris_Forte
Shopify Partner
6 0 1

If you set a price and no compare_at_price in the API creation, you'll get a null value for compare at price, which isn't ideal. Not sure how that would display, but that is unacceptable for our processes.

If you set a compare_at_price with no price, then you get a price of $0.

0 Likes
Chris_Forte
Shopify Partner
6 0 1

API version < 2020-04 it worked fine. I know since that is what I have been doing for a couple of years with no issues. Only with API versions >= 2020-04 is a problem.

compare_at_price = price in the API would work before. I understand if compare_at_price < price there should be an error, but not compare_at_price = price.

I'm assuming Shopify made an error and instead of throwing an error when compare_at_price < price they did compare_at_price <= price.

 

 

0 Likes
Greg_Kujawa
Shopify Partner
1016 83 237

If I had to deal with this newly-discovered quirk in our shop, I would either set a true MSRP as the compare_at_price (i.e. - a higher value), or else explicitly set the compare_at_price to be null. And any front-website elements would be modified to conditionally display the compare_at_price if a non-null value is defined (i.e. - hide it if it's not defined). Not the most technically involved exercise, but one that should future proof the way things would operate.

Chris_Forte
Shopify Partner
6 0 1

If a shop would like to track an MSRP, as the compare at price, how would that happen under that scenario? We currently use Price as the Sale Price, which sometimes there is no sale (price = compare_at_price). Then the Compare at Price as always the MSRP.

Not sure how other shops are using these fields, however. But, that is how we have been using these fields. So, having a compare_at_price for our shop is essential, because it is the MSRP. We cannot have a null value.

0 Likes
Greg_Kujawa
Shopify Partner
1016 83 237

Not to sound obtuse, but I don't understand why you can't modify your business rules to account for this change, that's been in place for 8 months now in terms of API versioning.

How we put this into play...We have a subsidiary company that sells pre-owned luxury goods in Shopify. So the Compare_at_price is always the MSRP, and the Price is always the lower "special" price for the pre-owned item. And then we have our larger parent company in Shopify, which exclusively sells new luxury goods. For 95% of the items we feature online, the Price is going to be the MSRP, so we leave the Compare_at_price null since it's N/A really. But for the 5% of the items we want to put "on sale" we are going to define a lower Price value and will define the Compare_at_price as the true MSRP to reflect the discounted on sale price. We have business rules on the front-end website that will display the Compare_at_price if it's defined. So the web consumer will see the savings for the on sale item.

In front-end Javascript or Liquid it's literally a couple lines of code that can conditionally display both prices if they are both defined. Not sure if you have other API integrations that rely on different business rules, but even then there can be some type of adjustment to account for the change, right?     

Greg_Kujawa
Shopify Partner
1016 83 237

Here's a snippet from our product detail Liquid file. As you can see, it conditionally displays both prices, or displays a min and max price, or displays just the selling price. Depending on how the item is defined on the back-end. Of course the CSS might vary depending on what Theme is implemented and whatnot. But to make it somewhat more tangible.

<div class="ProductItem__PriceList {% if show_price_on_hover %}ProductItem__PriceList--showOnHover{% endif %} Heading">
            {%- if product.compare_at_price > product.price -%}
              <span class="ProductItem__Price Price Price--highlight Text--subdued" data-money-convertible>{{ product.price | money_without_trailing_zeros }}</span>
              <span class="ProductItem__Price Price Price--compareAt Text--subdued" data-money-convertible>{{ product.compare_at_price | money_without_trailing_zeros }}</span>
            {%- elsif product.price_varies -%}
              {%- capture formatted_min_price -%}<span data-money-convertible>{{ product.price_min | money_without_trailing_zeros }}</span>{%- endcapture -%}
              {%- capture formatted_max_price -%}<span data-money-convertible>{{ product.price_max | money_without_trailing_zeros }}</span>{%- endcapture -%}
              <span class="ProductItem__Price Price Text--subdued">{{ 'collection.product.from_price_html' | t: min_price: formatted_min_price, max_price: formatted_max_price }}</span>
            {%- else -%}
              <span class="ProductItem__Price Price Text--subdued" data-money-convertible>{{ product.price | money_without_trailing_zeros }}</span>
            {%- endif -%}
</div>
Chris_Forte
Shopify Partner
6 0 1

Greg, I appreciate your engagement. And, indeed every business is different. And I've probably assumed too much and that we were using Shopify the same way as others.

For our business, we need to have a field dedicated to the MSRP (the compare_at_price). This must always be the MSRP and cannot be a null value. It would be very inefficient (for our purposes) to use an entirely different field for MSRP (price), when the price = compare_at_price. We need to have the compare_at_price always the MSRP for a variety of business purposes. It is essential to our business and cannot change.

I'm still uncertain why a validation of compare_at_price <= price, is acceptable, but not compare_at_price < price, and uncertain why a price = compare_at_price is a problem. I completely understand that price > compare_at_price is a problem. But, again, I probably have a myopic understanding of how others are using Shopify and their business processes. This change may actually be better for them. 

Our business going forward will have to always have to have a price < compare_at_price. The issue with this is we like to display discounts to customers. If we display a 1% discount, customer's complain (e.g. $9.90/10.00). This may sound trivial, but customers would prefer there to be no discount (i.e. price = compare_at_price), rather than see a 1% discount. It is psychological, but this is what my customer service team has reported. From an IT perspective it doesn't bother me to have a 1%, but from a user experience it does. Also, if I were to do something like 9.99/10.00, the % discount is so small with rounding, it'll say that it is 0% off, which doesn't look right. We'll have to account for these and use some JS to smooth out the UX on the front end. 

Essentially, we'll just have to change our processes to have the price always at something like 0.95 * compare_at_price, or to not display the discounts if less than a certain percentage (e.g. 2-3%)

In regards to our business, it may be helpful that we sell over 8k different SKUs and we run promos weekly. So, prices are changing constantly would be impractical to switch those fields. I developed almost all the systems at our company and I have absolutely other way besides using that compare_at_price as the MSRP. We do have quite a few integrations as well that rely on the compare_at_price.

Nothing insurmountable, however, we'll change to accommodate this change. In regard to it being in use for 8 months, we didn't update our API version since none of the changes were essential to our business, and this statement on their documentation made it seem like there wouldn't be anything that broke our processes, but I misunderstood its behavior until I put it in action recently:

"Updated properties

compare_at_price property on the Product resource can no longer be set lower than the product's price property."

Thanks again Greg for the engagement. It has helped me realize this wasn't an error, but as designed by Shopify and other Shops are probably benefiting from this change. I really thought that this was an oversight or bug. I'll be working with our team to update our code and processes ASAP. 

Cheers to you and thanks again for the response.

Chris

0 Likes
Greg_Kujawa
Shopify Partner
1016 83 237

I appreciate the time and insight into how this quirk now impacts your business rules and what you've developed around the platform. After all of the replies, I think this might be a moot point moving forward. If the API 2021-01 release candidate is flipped into production the way it works now, it appears as if the development folks at Shopify have corrected the quirk! See screen shot from a GraphiQL app test call I just made. It allowed me to set both price fields to be equivalent. That's a win in my book. And points to my guess that someone on their team realized it was indeed a quirk.

 

Untitled.png

 

UPDATE: I might be mistaken. I changed the two prices to be equivalent using the legacy API version. Then issued the same command using the 2021-01 API version. It allowed me to do this, but only if the two values are already equivalent. I guess the routine on Shopify's end just ignores the command if they values aren't changing.

0 Likes