New cost property on InventoryItem

[KieranMasterton]

On Thursday October 25th, Shopify will start introducing Product Cost. This feature enables merchants to record the unit cost of their variants, track margin, and report on product performance within Shopify. This feature will roll out to all stores over the next few days. 

Merchants will see a new cost per item field when editing variant pricing and will be able to bulk update this cost via the product CSV importer and the product bulk editor. There will also be changes to analytics, including the addition of new Profit Margin, Cost of Goods, and Gross Profit reports.

In order to enable our partners to leverage this feature in their apps we are exposing a new cost property on the InventoryItem. Please see the examples below for implementation details.

GraphQL

To pass Shopify the unit cost of a variant via the GraphQL Admin API you will use the productVariantUpdate mutation, see example below.

Mutation:

mutation productVariantUpdate($input: ProductVariantInput!) {
 productVariantUpdate(input: $input) {
   userErrors {
     field
     message
   }
   productVariant {
     id
   }
 }
}

Input variables:

{
 "input": {
   "id": "gid://shopify/ProductVariant/35437260802",
   "inventoryItem": {
     "cost": "25.00"
   }
 }
}

For more information about variant mutations please see our documentation.

REST

To pass Shopify the unit cost of a variant using our REST Admin API you will use the InventoryItem endpoint, see example below.

PUT /admin/inventory_items/#{inventory_item_id}.json
{
 "inventory_item": {
   "id": 808950810,
   "cost": "25.00"
 }
}

For more InventoryItem endpoint information see our documentation.

As always, if you have any questions, or concerns, please don't hesitate to reply in the thread below.

[Maris]

Hi, Kieran!

This seemed like good news initially, but...

For us, the concern is (the same as with Multi-Location Inventory) the following - to read and write this value, that would require additional API call for each of variant inventory items.

Making the request complexity to be N+1 - as many requests as there are variants.

The suggestion (and expectation from us as API "customers") would be that this is the read+write attribute of the variant.

Earlier we suggested clients to store their "cost" in Variant Metafields which also is N+1 complexity, and my hope when reading this post, was to have good news for clients that now they can update their cost much faster with this attribute.

Can we update this attribute for all the variants of one product with one single request?

Thanks!

[Danijel]

Good change. This will be useful.

I strongly agree that the api needs support for batch operations. That, or relax the frustratingly low rate limit. 

[KieranMasterton]

Hi Maris & Danijel,

Glad that you both welcome this change. In terms of bulk updates to the cost property, I would suggest going the GraphQL route where you can add the cost on create and update for multiple variants.

Here's an example of creating a product with two variants and setting the variant's inventory item cost:

Mutation:

mutation productCreate($input: ProductInput!) {
  productCreate(input: $input) {
    userErrors {
      field
      message
    }
    product {
      id
    }
  }
}

Input variables:

{
  "input": {
    "title": "Product",
    "variants": [{
	  "title": "Variant 1",
      "options": "Red",
      "price": "55.00",
      "inventoryItem": {
      	"cost": "33.00"
      }
    },
    {
      "title": "Variant 2",
      "options": "Blue",
      "price": "55.00",
      "inventoryItem": {
      	"cost": "33.00"
      }
    }] 
  }
}

The same principle applies with the updateProduct mutation as well.

I hope that helps!

[Maris]

Yey, that's great, Kieran!

That's just what's needed!

Thanks!

[Adriano_S]

As others have said, a very welcome change! Well done to the team!

From a business use perspective, one further request is to enable calculation of profit margins based on Product Prices that are exclusive of tax.

Example:

• A store's product prices are stored inclusive of tax
• "All taxes are included in my prices" is checked in Taxes settings
• Provide a store setting to use the tax-exclusive product prices when calculating profit

[Chris_C_]

Hi there.  Will we be able to inupt/update this info via Transfer?  Also, will the COG update as they either increase/decrease depending on existing vs new stock?

[Rick_Murt]

Will the cost data be surfaced in the order admin? I applied a cost to a variant, then placed an order, and don't see any cost, margin or profit data anywhere. 

[Jonathan-HA]

Hi Kieran,

Would the `cost` field be availabe in the `Variant` API endpoint by any chance (even just as a read-only attribute)?

This would save us an additional API call to the InventoryItem just to pull the data (we have a reporting app).

Thanks!

[ClementG]

Well done! I think a lot of merchants will be super happy about that.

I have to second others comment regarding bulk loading.

I have wondered since day one of the multi-location feature why the inventory item entity is not merged into the variant entity since there is a 1-1 relationship between them.

Unless there is a plan to enable inventory of non-variants in the future?

[Steve54]

HI Kieran,

Great new feature.  We will get around to adding it later on to our app, but for now if we don't pass the 'cost value' when updating products/variants that will be fine (ie. make no change to our existing processes)?

Thank you

[GhostApps]

Let me start by saying this is a useful feature that has been asked for by merchants for a while.

However, yet again your roll out has been terrible. After numerous delays to the app store and Locations API, you decide to roll out a new feature (that will kill a fair few apps) with 2 days notice!

Ultimately (after some redevelopment) this will help my app but the way you treat developers leaves a lot to be desired and I will have to look at reducing my dependence on your marketplace.

[KieranMasterton]

From a business use perspective, one further request is to enable calculation of profit margins based on Product Prices that are exclusive of tax.

Hi Adriano, great question, the new finance report gives an overview of margin without taxes. Shopify, Advanced, Plus plans also get the new Profit Margin reports which give this breakdown, per product and per variant.

Will we be able to inupt/update this info via Transfer?  Also, will the COG update as they either increase/decrease depending on existing vs new stock?

Hi Chris C, at present these feature are not available but this is a great suggestion and I'll feed this back to the product teams working on transfers and product cost.

Would the `cost` field be availabe in the `Variant` API endpoint by any chance (even just as a read-only attribute)?

Hi Jonathan & Clement, I'm afraid not. Our rationale is that anything which is an attribute of a physical good (their location, their weight, their cost, their quantity etc.) is at the inventory item level. Meanwhile, anything dealing with how an item is presented for sale to buyers (description, price, where it's published, images etc.) are at the product and variant level. I hope that makes sense.

if we don't pass the 'cost value' when updating products/variants that will be fine (ie. make no change to our existing processes)?

Hi Steve, it's great to hear you'll be adding product cost to your app and you're absolutely right, there's no requirement to pass the cost property.

However, yet again your roll out has been terrible. After numerous delays to the app store and Locations API, you decide to roll out a new feature (that will kill a fair few apps) with 2 days notice!

Hi GhostApps, thank you for your feedback on the timelines. It's not always possible for us to give advanced notice of feature releases but we are aware that the timeframe was particularly short in this case. I'll certainly raise your concerns internally and we'll envedour to give as much notice as possible in future. By enabling developers to set the product cost natively, we hope that partners will be able to leverage this data point, reducing their apps' dependency on storing cost data elsewhere and enabling them to concentrate on taking advantage of the huge opportunity in the product cost space.

[Dan41]

Perhaps I'm missing it, but to us the Cost of Goods Sold (and getting data out of shopify to complete taxes in general) challenge with Shopify isn't whether it can retain a product cost. 

The challenge for Cost of Goods Sold (and getting data out of shopify to complete taxes in general) is that this is no efficient way to get required data out of Shopify.  Also, in some cases there's no way to get the tax related data out of shopify tied back to the products/orders they came with. For example, Shopify has charged/refunded my customers and Charged/refunded me, but this needed tax related information/data is only avaiable under Shopify Bills with no way one can tie those amounts back to shopify orders, sales, etc.

We can and do record product cost today outside of shopify.  What we need from shopify for Cost of Goods Sold (and getting data out of shopify to complete taxes in general) is a feature where we can:

1) download all our shopify data,

2) download the data in a single area,

3) download data with its related keys (say between orders and bills (see above) in addition to sales, transactions, products, et al.) 

Will this new product cost (and/or report) also come with features to support (the above) so we can complete our Cost of Goods Sold and complete taxes in general? 

[Tom48]

Some of my clients have been asking for this for a while so it’s good to see it finally implemented. 

What would be really good is When raising an order via the pos or back office, the seller could view how much margin & profit is in the order. This would help them when they need to discount orders for customers. 

[MercOlogy_Colla]

I was pointed to this article as a solution to a Create Product Rest API error I am receiving:

Return Code: 400 Message: {"errors":{"smart_collection":"Required parameter missing or invalid"}}.  Oddly, when I run the same JSON in Postman, it created the Product.  

The Smart Collections use Vendor, Product Type and Tags to automatically associate the Product to the Collect.  I have confirmed that there are smart collections for the data in the JSON:

Can you help me understand why I was pointed to this article?  Doe the Create Product Rest API require Product Cost?

David

[Dominique_Simon]

Hi David,

I don't know why you were directed here, but if you are having issues creating products, you can create a new topic with the JSON youre sending to get help here:

https://ecommerce.shopify.com/c/shopify-apis-and-technology

Your issue is unrelated since you're using the product API. Is this a new error or did you just start using the API? (Please respond in the new topic)

Dominique

[ClementG]

Hi Kieran,

1) There seems to be a pretty bad bug: the cost property is not included in webhook requests for the inventory_items/update topic! I assume this is a bug?

It might affect inventory_items/create too but I didn't test it.

2) Is it possible to add a property on order line items with the cost at the time of the sale? Otherwise, we only have access to the current value, which may have changed since then.

[KieranMasterton]

Hi Clement,

1) Thanks for raising this, I've replicated the issue and will raise it with the engineering team immediately.

2) I know this isn't available at this point but I will ask the team if this is on the roadmap and update you shortly.

[Maris]

Hey, guys!

Today we ran into weeeird stuff with the Cost field with one of our Plus customers.

When setting the "cost" property though API to say "10.06", the Admin in the Plus store shows it as "10".

When reading from API the "cost" property, it is legitimately "10.06" there.

On the non-Plus Admin everything shows correctly of the same import.

Can Shopify Devs check this, please?

The client tried on many browsers, many computers - to eliminate the chance that this is a "OS/Browser" issue. It's the same. The only "common denominator" is that it is a Plus store.

Thanks!

[Gravy_Sales]

Not yet seeing the "cost" on my store when I use the below format, with 12345 being inventory_item_id ... any ideas?
myshop.com/admin/inventory_items/12345.json

[ClementG]

Repricer Admin, we noticed the same thing when hitting the url in your browser, but if you use the API, the cost property will be returned. It seems pretty inconsistent...

It's missing in webhooks though. I'm waiting for a fix on that one...

[Gravy_Sales]

Ah, thanks for confirming that... maybe/hopefully this is by design, to protect costs of shop owners. 🙂

So, just to confirm I have this right... this should work?  On my dev store I'm still having no luck after iterating through $cost ...

$inv_request = $shop->api()->rest('GET', '/admin/inventory_items/12345.json');  
$cost = $inv_request->body->inventory_item->cost;

[KieranMasterton]

Hi all,

For those implementing product cost in their apps we have just released a guide to supporting the new feature: https://help.shopify.com/en/api/guides/supporting-product-cost

Also, regarding the webhook issue Clement raised, we have just pushed an update which resolves this issue and also exposes the cost property to admin authenticated requests in the browser. Thanks for your patience while this was resolved.

[ClementG]

Thanks Kieran, I can see the cost in the webhook now.

[Zapfor_Apps]

Hi Kieran,

I noticed when merchants update the cost per item field with CSV product import, the inventory_items/update webhook is not triggered. Is this by design? If it is, what do you recommend apps should do to detect changes in costs? 

Thanks.
Sam

[KieranMasterton]

Hi Zapfor Solutions, thanks for the heads up on this, we're investigating the issue and will report back as soon as it's solved.

[Ameed_Akhdar]

Hey guys!

Is there any way to record cost of previous goods sold prior this feature was introduced? 

Thanks!

[Zapfor_Apps]

Hi Keiran,

Hi Zapfor Solutions, thanks for the heads up on this, we're investigating the issue and will report back as soon as it's solved.

I'd like to check if you have got any update regarding bulk import costs does not fire inventory_items/update webhooks?

Sam

[ClementG]

We have deprecated our own cost field in favor of this new built-in field.

However, some merchants have reported to us that the field doesn't allow $0 cost.

It might seem strange at first but there are some valid scenarios that warrant a $0 cost, such as items on consignment or free items.

Is it possible to change the field to allow for this?

UPDATE:

It's worth noting that it is possible set a product price at $0 so it only makes sense to allow for the cost to be $0 as well.

[KieranMasterton]

@clement interesting question, can I ask for more context on the use case of a 0.00 cost? The cost can be set to null via GraphQL (coming to REST shortly) but I'm guessing perhaps your merchant has a specific use case for zero cost?

@sam this is still in the works, sorry for the delay and thanks for your patience. 

[Adriano_S]

As a merchant, I'd like to add my vote to Clement's request for a 0.00 cost.

We often have promotional inventory provided by suppliers free of charge, which we then re-sell. These sales should be recorded as 100% profit. It's my understanding that a product with a "null" cost field is ingored in the profit reporting.

[ClementG]

Hi Kieran,

Would you like me to put you in touch with a merchant that requires $0.00 costs?

Like Adriano said, setting the cost to null doesn't work for reporting. A null cost is semantically different from a $0 cost. If the cost is null, we might want to exclude from profit reports or assume the margin is 0.

[PaulNewton]

Seeing what type of information can be stored in this field via admin as is shopify tradition to be able to repurpose everything as a store needs with unexpected data. Just like most shopify handling of currency as pennies:

• cost can't be less than 0.01 , e.g. foodstuff  $/lb to$/oz, etc bulk.
• admin will automatically round off with very little warning eg. 0.054
• not relevant just trivia: can't store a negative number 

[John_R]

HI Kieran,

Please be informed that Google has already made the decision that the "Cost" field is important with how an item is presented for sale.  

We need to map it properly to the Google Merchant Center "Cost_of_goods_sold" field so that we can optimize our marketing and the selling of our items.

Please confirm how we can do that.

[KarlOffenberger]

Subscribed

[ClementG]

Kieran, any update on allowing $0 cost?

I've just been pointed to another obvious use case by a merchant: digital products.

It's hard to argue with that one!

[ClementG]

And yet another case with a merchant selling services.

Hello Shopify? Can you please allow $0 cost? It's impacting real merchants and real scenarios.

[KieranMasterton]

Hi Clement, sorry for the delay in replying over the holiday period. The development team working on product cost are in the process of implementing the zero cost option and it should be available very soon, I'll update the thread as soon as the feature is shipped. Thanks for your patience.

[ClementG]

Thanks Kieran, great news!

Any update on capturing the historical cost on the order line items?

[ClementG]

Just got another merchant asking about computing historical COGS.

[KieranMasterton]

Good morning Clement and others who have requested an option for $0 cost. I'm now pleased to share with you that this is now available both in the admin and via the Inventory Item API.

In terms of historical cost on order line items, this is something the team are considering but not something we have a timeline for at this point. We'll keep you posted as we explore this further. Additional information about your use case for this data is always super useful in these discussions, so please share!

Thanks,

Kieran

[KarlOffenberger]

Awesome Kieran! Big thank you to y'all.

[ClementG]

Fantastic thank you.

Regarding the historical cost scenario, for us it's for reporting accurately costs over time.

It's very much the same as reporting revenue over time, which uses the historical retail prices of course.