3

Pricing Issue

Problem:

We have a item collection that has minimum and maximum price with max discount across different stores.

{
    "item_id":1,
    "price":{
    "min":1500.00,
    "max":3000.00
    },
    "max_discount":50
}

Now, we have different store with different pricing, Consider Store S1 has 0% discount & S2 has 50% discount & S3 has 20% discount. Here one item can have n number of stores.

Now we have a case where we want to show inventory based on selected store that can be a combination of S1x S2 or S1 or S1xS3 etc.

In above case

  • S1xS2 : Price change in this way
    • min price: 1500
    • max price: 3000
    • maxdiscount:50%
  • S1: Price change in this way
    • min price: 3000
    • max price: 3000
    • maxdiscount:0%
  • S1xS3: Price change in this way
    • min price: 2400
    • max price: 3000
    • maxdiscount:50%

Here pricing will changes on every combination, based on above given solution.

Currently, we show min and max pricing in product listing based looking at all stores. We do not show based pricing on listing based on combination of stores.

Is there an effective way to solve this problem at scale?

Fahim
  • 12,198
  • 5
  • 39
  • 57

3 Answers3

1

Based on the id fields I can see in your draft: deduplication and normalization are concepts that will get you not very far in Solr. They tend to make things more complicated and slow. But anyways, back to your issue.

I would model the schema differently. The basic idea is to model the offer for a certain item of each store. So that you can aggregate on that.

<fields>
  <field name="offer_id" type="int" indexed="true" stored="true" /> 
  <field name="store_id" type="int" indexed="true" stored="true" /> 
  <field name="item_id" type="int" indexed="true" stored="true" /> 
  <field name="price" type="float" indexed="true" stored="true" />
  <field name="msrp" type="float" indexed="true" stored="true" />
</fields>
  • offer_id the id of the offer, one item per store is an offer
  • store_id may be needed if the user wants to filter for certain stores or if you want to update your index based on stores. If this is no use-case you may also leave this out
  • item_id the id of the item. I kept this as you seem to have more details for the actual items stored somewhere else, so that you can enrich the search results with an API
  • price this is my main suggestion, just one price per offer. Remember an offer is the offer of one item in a certain store.
  • msrp the Manufacturer's Suggested Retail Price can be used to calculate the discount when displaying the actual offer. You could also name this standard_price or similar.

To perform your calculations you can then make use of the Stats Component. You may also add Currencies.

An example would look like this (offer 1 would be S1, offer 2 would be S2)

q=offer_id:(1 OR 2)&stats=true&stats.field=price

Included in your response you would get

<lst name="stats">
  <lst name="stats_fields">
    <lst name="price">
      <double name="min">1500.0</double>
      <double name="max">3000.0</double>
      <!-- etc. -->
      <lst name="facets"/>
    </lst>
  </lst>
</lst>

To display the max discount, I would calculate

(min value from the stats component) / (msrp)

e.g. 1500 / 3000 = 0,5 => 50%

cheffe
  • 9,345
  • 2
  • 46
  • 57
0

if I understand correctly - it is required to simply get aggregated data from all the stores, as if it were data from one store?

If this is the case, then depending on the solution in which it is implemented, either a complex query is required, which will calculate it, or an intermediate handler, which will prepare the result in the required form.

However, if this is an architectural solution, then it is better to use the principle of constructing "cubes", when obtaining new data on prices, to change the target result of statistics, and from there to collect generalized data, it will be fast and can be always counted.

P.S. if I do not understand the question correctly, please expand the source data

Fyodor
  • 149
  • 1
  • 2
0

This is possibly an "NP" problem and therefore may not have an effective (computational) solution. Assuming you have N stores and M products, doing quick combinatoric math (and hopefully I'm not wrong). The number of combinations will be: M * ( 2 ^ N).

Obviously, you cannot pre-calculate it.

I would go with heuristics (depending on your usecase), or apply specific calculations on demand (depending on your usecase). You may able to temporarily cache some of the calculations if it makes sense in your usecase.

Tomer
  • 1,594
  • 14
  • 15