Shopify - auto-tagging by 'compare at price' difference - shopify

The shopify store I edit has a 'sale' collection. This consists of products which have been auto-tagged on the condition that the 'compare at price' is higher than the actual price.
I want to create a new 'clearance' section, which would consist of products where the actual price is cheaper than the compare at price by 50% or greater. I can't find a simple way to do this (i.e. by using the inbuilt collection creator).
Can anyone help me out?

Discounts are applied at the checkout, not when browsing a product. That is why the Smart Collection logic has no conditions based on discounts. If I were you I would try and work out how to build a collection "clearance" with conditions that make sense, and then you could create a price rule/discount that would apply to that collection (50% off). It seems like that is the way to go.

Related

How do I create specific quantities for specific products within Shopify?

I've got a few products where I need the quantities for a specific product to start at a number, 240 for example and then the customer can select in intervals of 240, and for a different product, say 100 units. I need a way to separate a list of quantities for separate products.
You can examine the documentation related to InventoryItem endpoints which leads to InventoryLevel endpoints. Once you get a handle on Locations, you are free to set inventory levels. Note that setting explicit amounts is no longer the fashion, instead you ask how much is there, and then modify that amount with a delta change.
So if you ask for a product's variant level, and it tells you the current availability is 0, your delta might be +240.

How to set custom price for products on the basis of quantity in shopify?

Greetings.
I am working on a eCommerce website based on shopify. And for product I want to set a custom price. For example, The standard price of product is $500 but price will vary if user increased the quantity i.e. On 5 - 10 it will cost $450, On 11 - 15 it will cost $400 and on 20+ quantity it will cost $300.
I have searched module for this and also found a module i.e. https://apps.shopify.com/quantity-breaks. But its working on the basis of "Percent" that I don't need. Because I want to place price manually on the basis of quantity.
So please help me out from this and provide your valuable thoughts on the same.
Thanks in advance.
The way this is generally done in Shopify is to create variants where the option values are the price breaks. You have to modify your theme so that when a Qty > price break is entered the product page selects the variant that corresponds to that price level.
Other than the coding portion of this the main issue becomes inventory management since Shopify treats each variant as a separate inventory item but if you use variants to manage price breaks they are not actually separate items.
I think the easiest way to do this would be with a Shopify App. There are many that have price breaks etc. and they are usually easier to set up than using variants as the price break amounts.

Elastic Search, Nest. functional sorting

I'm building a filter page, with facets etc, which works as it should.
Now the our customer has a request to, basically "Be able to decide which sorting the items comes out in".
Each product is decorated with a Product Display Order, and is in a Product Line.
We got these example Product Display Orders:
1. Featured Item
2. Core Item
3. Spare Part
4. Utility
And these Product Lines:
1. Hammers
2. Saw
3. Wood
and the sorting is like this:
Sorting should firstly be based on Product Display Orders, secondly by product lines, thirdly Alphabetically.
So all products which is a Featured Item is listed first, and all these Featured Items is then sorted by their product line, and if some product are in the same Featured Item and Product Line, then its alphabetically.
The challenge is: I can't just get the sorting of Product Display order items and product lines as a number on the product, i only got a name/id.
We've thought of Boosting based on if the product are in the different categories, but it seems a bit messy.
OR
See if it possible to have some logic in the Sorting.
Sort by productDisplayOrder:
1. featured, 2. core Item ...
Then by ProductLines:
1. Hammers, 2. Saw ...
Then by Name DESC.
Which way is the best way to have this sorting, is it possible to give this logic to elastic, if it is a match and then sort it. Or are we needed to twist the boosts of product?
Hopefully this makes sense for you.
Thanks in advance! :)
Option 1). Quickest/Best performing solution would be to create new/separate integer fields for productDisplayOrder and ProductLine and then use those in your sort criteria as described (after reindexing and validating the the data is indexed as expected).
Option 2) If you want more nuance than described (eg higher scoring matches can 'break through' the ordering ceiling described) then you can explore using a Function Score Query to implement a custom scoring strategy that takes productDisplayOrder and ProductLine into consideration in generating an overall match score.
Option 3). If you can't change the mapping and reindexing your data, you can use Script-Based Sorting to generate sorting values from the currently indexed productDisplayOrder/ProductLine text using a script (eg Groovy). Keep in mind that query performance will be worse than the first two options.

Prestashop: use BlockLayered class methods and/or DB tables for price range button?

I've got to build a standalone menu button with submenu that contains links to price ranges.
I activated the blocklayered module (not for this task, only for regular left-column filters). So the relative db tables are in place and populated.
I want to make a controller specific for price ranges. So I've got to do the right query and maybe set up the same url vars as the blocklayered module so they wil not conflict.
Would it be too crazy to import blocklayered or blocklayered-ajax in my controller and use part of their functionality? Maybe not good because of object duplication or other issues?
Or maybe, would it be a bad idea to use the blocklayered tables (for example layered_price_index) to help me get filtered products? I'm wandering if it would be a better solution than re-doing all by myself, or if instead it's not good for some reason.
Any idea?
It really depends on which amount (among the ones below) you would like to take into account in your price range filter:
Amount without taxes
Amount including taxes
Amount including discount/promotion
Amount in several currencies or only one currency
Amount for a specific customer group or for everyone
Amount base on any other product price rule
The easy way:
You can build a price range controller easily by yourself, handling only a single currency and prices without taxes and reduction. It will probably be 90% accurate (because of the missing discounts a product might not show up for a certain range).
In that case, you can easily build a query on the ps_product and ps_specific_price tables and SELECT in real-time the right products for a given range.
The proper way:
You want to handle discounts, price rules, specific prices, etc. If you build a real-time query including all these calculations and parameters, it may slow down the server.
Build a product price cache or re-use the one setup by the Block Layered module.

Need advice in designing tables in SQL-Server

I have a quote that contains items (store in table QuoteItem):
QuoteItemId, QuoteId, ItemId, Quantity etc.
Now, I need to be able to create a group of chosen items in the quote and apply a discount on it.
Well that's simple, I create two more tables:
Group: GroupId, DiscountPercentage
GroupQuoteItem: GroupId, QuoteItemId
Let's say I have 30 items in a quote.
I made a group that contains items 1-20 from the quote and I applied a discount on it.
Now I need to have another group that contains items 10-30, the problem is about those inner 10 items, I need to control whether the discount should apply on the items after the other discount or it should be on the items' base price.
For instance, I am gonna talk about item no. 15 in the quote: QuoteItem.Cost = 100
I applied 1st discount of 10% = 90.
Now I want to apply the second discount, I need to be able to control if the discount should be on the 100 or should be on the 90.
Same is when I have multiple discount groups and when I wanna apply a complex architecture of discounts.
Any assistance will be really appreciated.
I would look into adding a column to the GroupQuoteItem table, GroupQuoteItem.Priority. This column would be used in the query that determines the final price. If you have N discounts with the same, highest priority, they will be stacked atop each other (the order doesn't matter, thanks to associativity of multiplication).
If all of these high-priority discounts are later removed, lower-priority discounts can take their place. This should help you in setting up pretty complex discount structures.
I hope that at least gives you somewhere to start from.
It really depends on your own business rules. Do you want to apply the discounts on the price after discount or on the original price. When you ask questions like this it helps with SAMPLE Data then show us expected results.
This may be one of those rare times in normalization when you want to store data that you could calculate otherwise. So, in QuoteItem, you could have a Cost field and a DiscountedCost field. If they're the same, then you know no discount has been applied, if they are not, then a discount has been applied. By having this field, you would also be able to do comparisons on what the discount is already and whether you want to add the additional discount. In fact, you could also store that number in an ExistingDiscount field.
Why not store a column in the Group table that specifies whether or not the discount can be accumulated with other discounts versus if it must be applied to the base price only? You could name the field something like "ApplyToBasePriceOnly."
Other than that, I agree with JonH that a lot of this logic should be placed in business rules. I think your general database structure looks pretty good.