Michelle, Who is a sweet lady and regular reader of the blog sent me this question via e-mail. (aside: why is she a sweet lady? Because she saw the new cell post and sent me pics of her son and told Jo and me are about to encounter most amazing experiences of our lives 🙂 )
I handle the invoices we give to our customers (we build and sell furniture), but sometimes such customers can be stores or just regular folks that come directly to us.
For the stores I have to give an invoice that has a NCF number which is a tax related number that increases the cost in 16% but stores require this number which must be unrepeatable. Each company has a “list” of numbers that they can provide their customers. Regular customers (not stores) have no interest in this number, obviously trying to avoid the 16% increase in the price!
So far what I did was create a database of our customers with the basic info of each one. Many of our customers keep buying so this way I just have to place myself in the invoice and select from a list and with a simple vlookup I get the rest of the customer’s information: phone, address and RNC number.
Now… the RNC is the number that tells me if it’s a store or not. Stores must have their registration number (RNC) in order to receive invoices with NCF (boring, I know… I’m gonna get to the point in a sec). Ok, so if I choose my dear customer “Chandoo Enterprises” and this store has RCN, then I automatically need for the invoice to pull form “my list” of government assigned NCF numbers, the next one in line. If in my previous invoice (say invoice 1455) to another store I used NCF number A010010010100000002 (that’s how they look) for Chandoo Enterprises -invoice #1456- I am going to need the next number in line A010010010100000003 and so on. Now, say that my next invoice (1457) is not to a store but to John Doe, for him I don’t want an NCF number to show.
I keep thinking that there’s a very stupid and simple way to do this but I just can’t nail it!! My problem is to get to a formula that will work only when the RNC field has information and therefore avoiding NCF numbers to appear on non-store customers (not so complicated I think) and that it chooses the next NCF number in line, no repeating… this is the part that I have no idea how to do!! Is there a way to solve this without using VBA? VBA is scary!! Hehehe
Okay, that is a big question, but may be we can come up with a small solution for it.
If I understand it correct, Michelle is looking for something like this:
So, in order to generate such numbers,
- First we will make 2 named ranges – customer_list and ncf_numbers. You know what they mean.
- Now, we will enter the customer name in column B, and based on that we will fetch RNC number in column C.
- For this, we will use VLOOKUP () formula. The simplest formula looks like this: VLOOKUP(B5,customer_list,4,FALSE)
- But, simplest formula also has problems – it doesn’t handle errors and can return 0 when the RNC number field is blank. So we will add some fat to it, mainly on the front side. It now looks like this: =IF(ISERROR(VLOOKUP(B5,customer_list,4,FALSE)),””, VLOOKUP(B5,customer_list,4,FALSE))
- In the third column, we will fetch the next available NCF number if the customer has an RNC. For this, we use a simple IF() and COUNTIF() formulas along with INDEX() formula. We write: =IF(OR(C5=””,C5=0),””,INDEX(ncf_numbers,COUNTIF($C$5:C5,”RNC*”))).
- Above formula simple fetches the nth NCF number from the named range ncf_numbers if RNC number is not blank.
- That is all. We now have a simple logic to generate invoice numbers that suit tax authority’s whims and fancies.
Download the example workbook:
You can download the excel tutorial workbook and see how you can generate such invoice numbers yourself.
More material if you are getting stuck with formulas
50+ Excel Formulas – Explained in plain English, Excel formula tutorials, Excel array formula examples
One Response to “SQL vs. Power Query – The Ultimate Comparison”
Enjoyed your SQL / Power Query podcast (A LOT). I've used SQL a little longer than Chandoo. Power Query not so much.
Today I still use SQL & VBA for my "go to" applications. While I don't pull billions of rows, I do pull millions. I agree with Chandoo about Power Query (PQ) lack of performance. I've tried to benchmark PQ to SQL and I find that a well written SQL will work much faster. Like mentioned in the podcast, my similar conclusion is that SQL is doing the filtering on the server while PQ is pulling data into the local computer and then filtering the data. I've heard about PQ query folding but I still prefer SQL.
My typical excel application will use SQL to pull data from an Enterprise DB. I load data into Structured Tables and/or Excel Power Pivot (especially if there's lot of data).
I like to have a Control Worksheet to enter parameters, display error messages and have user buttons to execute VBA. I use VBA to build/edit parameters used in the SQL. Sometimes I use parameter-based SQL. Sometimes I create a custom SQL String in a hidden worksheet that I then pull into VBA code (these may build a string of comma separated values that's used with a SQL include). Another SQL trick I like to do is tag my data with a YY-MM, YY-QTR, or YY-Week field constructed form a Transaction Date.
In an application, I like to create a dashboard(s) that may contain hyperlinks that allow the end-user to drill into data. Sometimes the hyperlink will point to worksheet and sometimes to a supporting workbook. In some cases, I use a double click VBA Macro that will pull additional data and direct the user to a supplemental worksheet or pivot table.
In recent years I like Dynamic Formulas & Lambda Functions. I find this preferable to pivot tales and slicers. I like to use a Lambda in conjunction with a cube formula to pull data from a power pivot data model. I.E. a Lambda using a cube formula to aggregate Accounting Data by a general ledger account and financial period. Rather than present info in a power pivot table, you can use this combination to easily build financial reports in a format that's familiar to Accounting Professionals.
One thing that PQ does very well is consolidating data from separate files. In the old days this was always a pain.
I've found that using SQL can be very trying (even for someone with experience). It's largely an iterative process. Start simple then use Xlookup (old days Match/Index). Once you get the relationships correct you can then use SQL joins to construct a well behaved SQL statement.
Most professional enterprise systems offer a schema that's very valuable for constructing SQL statements. For any given enterprise system there's often a community of users that will share SQL. I.E. MS Great Plains was a great source (but I haven't used them in years).
Hope this long reply has value - keep up the good work.