This discussion is archived
2 Replies Latest reply: Oct 9, 2012 6:25 AM by Ben Rogers RSS

How to show logic of picking multiple stores to fulfill an order line item

966498 Newbie
Currently Being Moderated
I'm still learning some basics with OPA.

How do I represent the logic of picking multiple stores to fulfill an order line item when no one store has the requested quantity? A concrete example would be greatly appreciated as I'm still thinking procedurally for solutions.
  • 1. Re: How to show logic of picking multiple stores to fulfill an order line item
    Ben Rogers Journeyer
    Currently Being Moderated
    Hi!

    I believe this is following on from the thread:
    Calculating least cost of a product across stores using OPA

    So I'm assuming we're using a similar data model.
    If we want to involve quantity as well as cheapest price, then I'm assuming the requirement is:

    Find the cheapest price for the product from all the stores which still have quantity left of that product.

    This is where inferred relationships come in handy.

    Here is an example of what you can do with them to help solve this requirement.

    the store is a member of the product's stores if
    .ExistsScope(the store's prices)
    ..the price's product name = the product name

    the store is a member of the product's stores with remaining stock if
    .the store is a member of the product's stores and
    ..ExistsScope(the store's quantities)
    ...the quantity's product name = the product name and
    ...the quantity's amount > 0

    Then we basically want to pick the cheapest price for the product from the members of the relationship "the product's stores with remaining stock"

    Note that "the product's stores with remaining stock" could obviously be many instances, all with different prices. But for an order, a product needs to come from only one place! The deciding factor to "pinpoint" one place from this potential list of many could be based on anything, such as location, sales ranking, etc. But in this case Im going to assume lowest price is the decider.

    In the previous post we created a simple relationship between "the product" and "the prices" (which are contained by the store).

    We can make a more powerful relationship now:

    the price is a member of the product's available prices if
    ForScope(the price's store, the main store)
    .the main store is a member of the product's stores with remaining stock

    (I'm using an alias here to be 100% sure of which store is in scope)

    Now we can use the rules in the previous post, but change the relationship to the more advanced one we just created:

    the product's cheapest available price = InstanceMin(the product's available prices, the price's amount)

    Then

    the product's cheapest available store name = InstanceValueIf(the product's available prices, the price's store name, the price's amount = the product's cheapest available price)


    This is all psuedo code so many need some slight tweaks when you put it into OPM. Make sure you set up the relationships in a property file and declare all the attributes etc.

    Inferred relationships are really useful as "filters" sometimes. Here we first filtered all the stores which have prices for the product (i.e. have it in their catalogue). Then we filtered to get a list of all the stores which have stock remaining for the product. From that, we could find the cheapest available price.

    This is by no means the only way to do it! It's also by no means a simple problem but the great thing about OPA is that you can put all of the relationship config rules in the system rule folder / word doc, meaning that the source / business rules can still look relatively simple (in the end, it only took 2 lines of source rules to find the cheapest available price!). Once you've got the right set up and invested time in designing your data model, you will find it much easier to solve seemingly complex problems across entities.

    One word of warning though: if you have thousands of instances of prices, stores, products etc. then there is a performance impact of using many inferred relationships and alternatives should also be considered.

    Hope this helps!

    Feel free to contact me for more help on this. If you are relatively new to OPA and trying to tackle this you should consider investing in some training.

    Cheers,
    Ben
  • 2. Re: How to show logic of picking multiple stores to fulfill an order line item
    Ben Rogers Journeyer
    Currently Being Moderated
    A couple of more notes.

    If no store can be found which has stock of the product, perhaps you could set the product's cheapest available price & the product's cheapest available store name to uncertain.


    You could achieve this with a rule table e.g.:
    --
    the product's cheapest available price
    --
    uncertain : InstanceCount(the product's available prices) = 0
    --
    InstanceValueIf(the product's available prices, the price's store name, the price's amount = the product's cheapest available price) :otherwise
    --


    Another thing to consider is the rule:

    the product's cheapest available store name = InstanceValueIf(the product's available prices, the price's store name, the price's amount = the product's cheapest available price)

    Now, if more than one store has the cheapest price (which is likely), then InstanceValueIf will actually return uncertain. InstanceValueIf can only pinpoint one instance.

    For demonstration purposes, make sure that each store has a different price for the product.
    For a "real" application you will need to ensure that there is always a way of selecting a unique store, even if more than one has the cheapest price. You could take the logic one step deeper and select the store with the least / most amount of stock remaining of that product. But then, of course, two stores may have the same amount of stock. So the final level should always be something that is guaranteed to be unique. It could be something like "store sales rank" or "store id" (which are unique).

    Either way, there is the possibility to make a very intelligent order processing / store selection rulebase in OPA and although it seems complex, there actually aren't many rules which need to be written to achieve this.

    Thanks,
    Ben