Tesco Price Update
Version | Date | Created / Updated | Notes |
---|---|---|---|
v1.0 | Hristiyan Georgiev | Initial version |
Just like the Stock update we need to update variant by variant. We are practically using the same GraphQL mutation, the only difference is in the variables.
All triggers, validations etc are as per the abstraction - Price Update General requirements
GraphQL Query
mutation VariantUpdate($input: VariantUpdateMutationInput!) {
variantUpdate(input: $input) {
variant {
id
displayable
}
errors {
field
messages
}
}
}
Query Variables:
{
"input": {
"variantId": "VmFyaWFudC0xMDU2MTA=",
"attributes": {
"price": 100,
"salePrice": 79
}
}
}
Variables mapping:
Integration Field | Hemi Mapping | Hemi Notes | ||
---|---|---|---|---|
input |
||||
variantId |
Product Account Tesco > Variant ID |
|||
attributes |
||||
price |
Product Account > RRP |
We need to have a validation and if we have RRP less than or equal to Price we need to return an internal error as Tesco would not allow this. The RRP always has to be higher than the Price . If we don’t have RRP at all in Hemi, we just exclude it from the payload. |
||
salePrice |
Product Account > Price |
We need to have validation and we should not be able to send negative price or price equal to 0 |
Example Success Response :
{
"data": {
"variantUpdate": {
"variant": {
"id": "VmFyaWFudC0xMDU2NDI=",
"displayable": true
},
"errors": null
}
}
}
Example Error Response :
{
"data": {
"variantUpdate": {
"variant": null,
"errors": [
{
"field": "sale_price",
"messages": [
"must be greater than or equal to 0"
]
}
]
}
}
}
We don’t need to map anything from the success response.If we have errors want to concatenate the field
and messages
and store the error message as per the abstraction Product Listing general requirements