Author: Oz du Soleil
As much as some people try to avoid VLOOKUP(), it is an incredibly useful function for Excel pros. Those who love it will certainly want to replicate its functionality in Power Query at some point. The thing is, however, depending on which version of VLOOKUP() you need, such as VLOOUP True, it can be quite tricky to implement.
In truth, we don’t need to do anything special to emulate VLOOKUP’s Exact Match, as this functionality can be replicated by simply merging two tables together.
Replicating VLOOKUP()’s approximate match is a totally different case than the exact match scenario. It requires some logic to emulate these steps, as we’re not trying to match records against each other. We’re actually trying to find the closest record to our request without going over.
It’s always bothered me that VLOOKUP True is considered an approximate match. For example, 64 and 65 could be considered approximate until you need VLOOKUP True to make 65 the line between passing and failing. Suddenly, 64 and 2 have more in common, and 65 is in a whole different world that includes 66, 83 and 99.
This point became relevant recently when I needed to use Power Query to replicate the real function of VLOOKUP True: assigning records to a category or tier.
Up until now, it’s been easy to replicate VLOOKUP-True functionality: just stack up a few conditions, Load To, then move on with life.
To assign each of these amounts to the categories of Small, Medium or Large, it takes just two conditions.
Recently, I took on a project where that wouldn’t work because of the way Power Query hardcodes values and does other things that we’ve come to understand are shameful and immoral.
There are two main reasons why this new project was problematic:
Let’s say we need to figure out the right discount amount and make it easy for a user to do something like remove the 30-pound tier and make the 20 – 50 range $2.65.
So, how can this be made simpler?
After a few hours of internet searches for a solution… I remembered to think TIERS, not about approximate matches. Thus, it would be fantastic if:
Oh lord, I could suddenly envision the path to glory!
Here’s the video of my solution:
My first step was to make a column of flags as an easy visual check during the development process, and an obvious record to delete if everything worked.
With the queries created, the Amount columns needed to be exact so that the queries could be appended. Thus, change the Discounts query’s Amounts (lbs) column to Amounts. Then append the 2 tables:
Things were looking great. But here’s the missing step in the video.
After posting it, Szilvia Juhasz noticed that the sort had a problem. The 30 in row 19 is equal to the tier demarcation 30 in row 20, but shows above the demarcation. WRONG! The demarcation needs to be listed first.
This is solved with a Sort by Transaction to assure that null comes before any transaction where the demarcation is equal to an actual value.
(*NOTE: one thing to think about is tiers that have no values. What happens? Fortunately, that’s not a problem here. The Xs in rows 18 and 19 don’t make problems for us just because there are no orders that are >= 20 and < 30.)
The Hard Part is Over!
We’ve got this thing whooped now!
In the next screenshot, you can see that the flag isn’t totally necessary. To get rid of the demarcations, we can filter out either, the x in the Flag column or the null in the Transaction column.
Filter out the Xs
Remove the Flag column then Load To…
Brothers and sisters, we’re done!! But let’s try it out.
Does it work? With the following changes to the Discounts what happens when we refresh?
Result!
Thanks to Ken Puls and Miguel Escobar for allowing me to share this guest article with you. I appreciate their early efforts and passion for Power Query. So, it’s a real honor to be here with you. Now, go forth and help keep this world’s data clean!
