Active Planner. How to Create and Use Database Query Formulas

Size: px

Start display at page:

Download "Active Planner. How to Create and Use Database Query Formulas"

Mark Porter
6 years ago
Views:

1 Active Planner How to Create and Use Database Query Formulas Table of Contents Introduction... 1 Database Query Part 1 - The Basics... 2 Database Query Part 2 Excel as the Data source Database Query Part 3 Column Dates Database Query Part 4 Case Statement, IIF and SWITCH Functions Database Query Part 5 Use Case Statement to mimic IF logic Addendum Conversion functions that I have found helpful Introduction Hello, I have been working with Active Planner for more than 10 years. I know from my experience that one of the strengths of Active Planner is its ability to use information from a variety of data sources within the enterprise. As I visit customers to help with their implementation or provide training, I find that most have existing data in SQL Server, MS Access, Excel or similar data sources that they want to use in their budgeting process. Database Query Formulas are a great way to access this data, but I find that some people are intimidated by these. So I have created this document to step you through the process of creating Database Query Formulas and applying them to your Plan Sheets, found in Part 1. I find that most financial people are familiar with Excel and as a result this is a typical source for database queries. However, there are a few quirks to using Excel, which I discuss in Part 2. In Part 3 we look at how the column dates are used to retrieve data specific to the column, whether it is defined as a single period or 12 periods. In Part 4 we look adding some conditional logic to our queries. Part 5 builds on that to show you how we can mimic IF logic with the other Formula Types. And Part 5 is just a small collection of functions that have helped me over the years. The information provided here applies to most versions of Active Planner and it is not dependent on any particular General Ledger. For those that use Advanced Allocations, you will find this information very applicable since both products use the same Calculation Engine. I hope you find this information helpful and informative. Thank you. Doug Leasure Doug.P.Leasure@gmail.com

We will create a new Plan Sheet: Create columns for Actual and Budget: We have data Salary

2 Database Query Part 1 - The Basics Active Planner ships with demo data, which we will use for the lesson. We will create a new Plan Sheet: Create columns for Actual and Budget: We have data Salary data available to us in a MS Access database. The PR-Employees table, shown below, contains columns of information. We are interested in the current salary which is located in the 2

To begin, we will enter account number 6000-100-200-00. Segment 1 (the natural account) is 6000 for salaries.

3 LastAnnualizedPayRate column. And we want to get the salary based on the Location number and Department number. To begin, we will enter account number Segment 1 (the natural account) is 6000 for salaries. Segment 2 (the Location number) is 100 and segment 3 (the Department number) is 200. Our first goal will be to create a database query formula that will bring in the salaries for Location 100 and Department

4 So we click the CALC button and select FORMULA for the Budget Group: Next we click the Formula Properties button and define our formula: 4

5 Now click the DATABASE QUERY button to define the query. Select Access for the Data Source Type and fill in the Database Filename by clicking the Ellipse ( ) and browse to the location of the MS Access database (Demonstration Data.mdb). Click the TEST button to make sure you have can open the database. Next move to the QUERY BUILDER tab and we can begin to build our database query. In its simplest form, the query uses a SELECT statement to return data from columns where the data matches certain criteria that we specify. It has the form: SELECT FieldName FROM DatabaseTable WHERE FieldName = MyCriteria. In our example, we want to select the salary where the Location is 100 and the Department is 200 so we will use: SELECT LastAnnualizedPayRate FROM [PR Employees] WHERE Location = '100' AND Department = '200' Note: The Location and Department are TEXT so they are entered with the single quotes so they are TEXT and not NUMERIC. Also, you have to put square brackets around objects that have spaces in their name, which is why the employees table is entered as [PR Employees]. 5

6 The QUERY BUILDER makes it easy to point and click to build the Select statement. Under AVAILABLE TABLES, select PR Employees, this will display a list of all the columns (also called fields) under AVAILABLE FIELDS. Double-click on LastAnnualizedPayRate and this will enter it in the SELECT row: 6

7 Next we need to build our WHERE clause. Click in the WHERE row and from the AVAILABLE FIELDS, double-click the Location, from OPERATIONS, double-click = and then in the WHERE row, type in

Finally we can test the query to make sure it is returning the data we desire.

8 Now we will finish by clicking in the WHERE row, from OPERATIONS, double-click AND, then from the AVAILABLE FIELDS, double-click the Department, from OPERATIONS, double-click = and then in the WHERE row, type in 200. Finally we can test the query to make sure it is returning the data we desire. First, put a check mark in each option of the TEST QUERY: Now click the TEST QUERY button. When the QUERY TEST screen appears, just click the OK button. 8

So we will need to modify the query slightly to tell it to summarize all salaries in to one total amount.

9 When the QUERY DISPLAY screen appears, just click the OK button. This will display the results of our query: You will notice that we are getting multiple results, one salary for each employee in Location 100 and Department 200. So we will need to modify the query slightly to tell it to summarize all salaries in to one total amount. This is easily done by typing SUM() around our salary field: Now, when we test the query, we get 563,512 which is the total of all salaries: While this query is working correctly for Location 100 and Department 200, we want the query to be able to handle a variety of account numbers. Typically our plan sheets are designed with multiple account numbers on each row: 9

The 2nd and 3rd segments (the Location and Department) are changing from row to row.

whatever value is in the 3rd segment, so we will use the ACCTSEG(segno) variable. Our WHERE row currently says Location = '100' AND Department = '200'.

variable into the WHERE row: Location = &ACCTSEG(2)& AND Department = '200' Now modify it for Department equal to segment 3 and the result is: Location = &ACCTSEG(2)& AND Department =

10 The 2nd and 3rd segments (the Location and Department) are changing from row to row. We can easily accommodate this in our query by using the VARIABLES: In our query, we want to say that the Location is equal to whatever value is in the 2nd segment and the Department is equal to whatever value is in the 3rd segment, so we will use the ACCTSEG(segno) variable. Our WHERE row currently says Location = '100' AND Department = '200'. Go to the WHERE row and erase 100, double-click the ACCTSEG(segno) variable which brings up the following screen, select 2 for the Segment Number: Click the OK button and it will enter the variable into the WHERE row: Location = &ACCTSEG(2)& AND Department = '200' Now modify it for Department equal to segment 3 and the result is: Location = &ACCTSEG(2)& AND Department = &ACCTSEG(3)& Using the Variables in our query will allow it to work for a variety of account numbers. We can test this by using the TEST QUERY button. Click the TEST QUERY and on the Query Test screen, enter as the account number: Click OK until you see the results screen and you will see that it is working when segment 2 is 100 and segment 3 is 200: 10

Try it again and on the Query Test screen, enter 6000-400-300-00 as the account number: And our new result is: Save this formula as a global formula and apply it

to learn from this portion of the lesson.

11 Try it again and on the Query Test screen, enter as the account number: And our new result is: Save this formula as a global formula and apply it to all 3 rows in our plan sheet, then refresh calculations for the Budget_1 column and you ll see that it is returning the right data: And there is one last thing to learn from this portion of the lesson. The total salary that was returned by our query is an annual amount so if we wanted to apply this to each of the 12 periods, we would want to divide the amount by 12. We can modify query to accomplish this easily: SUM(LastAnnualizedPayRate)/12. The new query would look like this: 11

One important thing to know is that the Excel file must be saved as version 2003 or earlier: Another important thing to know is that the values from the account segments are

12 Database Query Part 2 Excel as the Data source We often use Excel files as our source for database query formulas. There are a few things you ll need to keep in mind when using Excel files. One important thing to know is that the Excel file must be saved as version 2003 or earlier: Another important thing to know is that the values from the account segments are TEXT, not NUMERIC. So in the sample Excel file, HeadCount.xls, the Loc and Dept numbers are entered as TEXT by putting a single quote in front of the value. Eg: 100 Formatting the cells as TEXT is not sufficient to make the cell value a TEXT. It is also important that all values in the column are consistently entered the same way. 12

Let s switch the SELECT around so that we return the Dept number where Count = Segment 3. When Segment 3 = 300, we expect it will return Dept 100 because Count is 300.

13 Each Sheet in your Excel file will display under the AVAILABLE TABLES as the sheet name with a $ after it. When the data type of the column in Excel is NUMERIC, we can sometimes use conversion functions to convert it to TEXT (or TEXT to NUMERIC). As a way of explaining the problem, let s do an experiment. Let s switch the SELECT around so that we return the Dept number where Count = Segment 3. When Segment 3 = 300, we expect it will return Dept 100 because Count is 300. This query should work: SELECT [Dept#] FROM [HeadCnt$] WHERE Count = &ACCTSEG(3)& but when we run it we get this error: The error is caused by the segment number being TEXT but the Count is Numeric. So we can convert the Count to TEXT using the CSTR function. The correct query is: SELECT [Dept#] FROM [HeadCnt$] WHERE CSTR(Count) = &ACCTSEG(3)& 13

Database Query Part 3 Column Dates Another important concept in database query formulas is role that the column period beginning and ending dates play.

14 Database Query Part 3 Column Dates Another important concept in database query formulas is role that the column period beginning and ending dates play. We can use the Accounts Receivable table in MS Access to understand this. Looking at the AR- InvoiceDetail, shown below, we could pull the amt_cost where our Account Number equals the gl_rev_acct and where the date_applied falls within the period begin and period end dates of our column. Using what we ve learned so far, we can easily create a query that returns the total amt_cost where the gl_rev_acct equals the account number in Active Planner, as shown: 14

Use the variables &PERBEGIN& and &PEREND& for the beginning and end dates.

15 In order to return the correct amount for each column, we need to add some additional logic to limit the data to where the date_applied is greater than or equal to the period begin date AND less than or equal to the period end date. Use the variables &PERBEGIN& and &PEREND& for the beginning and end dates. The resulting query is: We can how it see how it easily returns the correct values based on the column dates. Even if your column is defined to be a single period, 3 months or an entire year, this query will return the correct values. 15

Database Query Part 4 Case Statement, IIF and SWITCH Functions Another important concept in database query formulas is how to handle the situation where there are sets of data that we have to treat

16 Database Query Part 4 Case Statement, IIF and SWITCH Functions Another important concept in database query formulas is how to handle the situation where there are sets of data that we have to treat differently. Again, we can use the Accounts Receivable table in MS Access to build upon our earlier work. Looking at the AR-InvoiceDetail, shown below, we have a variety of territory codes that represent the region of the world in which the item was sold. For our purposes, let s presume that we need to multiply the amount by a conversion rate to convert the amount to US dollars. The territory_code contains the following values: AS001, CN001, CN002, EU001, EU002, SA001, SA002, US001, US002, US003 and US004. Let s presume that we can use just the first 2 characters to tell us which conversion rate to use. We can use the function, left(territory_code,2), to give us AS, CN, EU, etc. So we will multiply the amount by 2.75 for AS; by 1.15 for CN, 0.75 for EU; 1.75 for SA and 1.0 for US. If we are using MS Access or Excel as our data source, then we could use the IIF function. The IIF function returns one value if a specified condition evaluates to TRUE, or another value if it evaluates to FALSE. The syntax for the IIF function is: iif ( condition, value_if_true, value_if_false ) If we are using SQL Server for our data source, then we can use a simple CASE expression: CASE WHEN Boolean_expression THEN result_expression [ ELSE else_result_expression ] END Since we have a list of 5 different items, we will be better served by the SWITCH function. In MS Access or Excel, the Switch function evaluates a list of expressions and returns the corresponding value for the first expression in the list that is TRUE. The syntax for the Switch function is: Switch ( expression1, value1, expression2, value2,... expression_n, value_n ) If we are using SQL Server, then we can use a CASE expression: CASE WHEN Boolean_expression1 THEN result_expression1 WHEN Boolean_expression2 THEN result_expression2 WHEN Boolean_expression3 THEN result_expression3 [ ELSE else_result_expression ] END 16

So to take this knowledge and put it into use in our query from the previous lesson, we will now have this resulting query: The syntax for our use of the SWITCH function is: SUM(amt_cost * SWITCH

17 So to take this knowledge and put it into use in our query from the previous lesson, we will now have this resulting query: The syntax for our use of the SWITCH function is: SUM(amt_cost * SWITCH (left(territory_code,2)='as', 2.75, left(territory_code,2)='cn', 1.15, left(territory_code,2)='eu', 0.75, left(territory_code,2)='sa', 1.75, left(territory_code,2)='us', 1,)) And if we were using SQL Server, then the syntax for the CASE statement is: SUM(amt_cost * CASE WHEN left(territory_code,2)='as' THEN 2.75 WHEN left(territory_code,2)='cn' THEN 1.15 WHEN left(territory_code,2)='eu' THEN 0.75 WHEN left(territory_code,2)='sa' THEN 1.75 ELSE 1 END) 17

Database Query Part 5 Use Case Statement to mimic IF logic One final concept that I want to cover is the use of the Case Statement to mimic IF logic in Active Planner formulas.

18 Database Query Part 5 Use Case Statement to mimic IF logic One final concept that I want to cover is the use of the Case Statement to mimic IF logic in Active Planner formulas. We can use formulas to pull values from GL Account balances, budget balances and from other Plan Sheets by Account Number, Row ID or Published Data. There is great flexibility in the formulas, especially when you use ACCOUNT MASKING, but there currently is no IF logic in the formulas. I would like to show you how you can mimic the IF logic in formulas. For our example, let s presume that if our natural account number is a revenue account (4000 thru 4999) then we want to use a PS-Acct formula to return values from the Global Assumptions Sheet, and if our natural account number is an expense account (5000 thru 7999) then we want to use an Accounts formula to return values from our GL Balances and if our natural account number is anything else then we want to return a 0 value. You should already be familiar with how easily we can create a formula where row 1 uses a PS-Acct formula to return values from the Global Assumptions Sheet, where row 2 uses an Accounts formula to return values from our GL Balances and our operand is the plus sign to add these 2 rows together. That formula would look like this: We can modify this formula to accomplish our IF logic by using some simple math and a Case Statement. We will take advantage of what we learned in basic mathematics; that if we multiply any number by 1 the result is that same number and if we multiply any number by 0 the result is 0. If our natural account (segment 1) is between 4000 and 4999 then we should multiply row 1 by 1, otherwise we will multiply it by 0. And if our natural account is between 5000 and 7999 then we should multiply row 2 by 1, otherwise we will multiply it by 0. 18

Here is how we easily accomplish this in our formula.

Set the operand to plus for this new row, set the Type to Database, and define it like this: For the Data Source: On

THEN 1 ELSE 0 END Now change the operand on row 3 to multiplication and insert a row right after row 3.

19 Here is how we easily accomplish this in our formula. Change the operand on row 1 to multiplication and insert a row right after row 1. Set the operand to plus for this new row, set the Type to Database, and define it like this: For the Data Source: On the Query Builder tab, click the ADVANCED tab and type in: CASE WHEN (&ACCTSEG(1)& >= 4000 AND &ACCTSEG(1)& <= 4999 ) THEN 1 ELSE 0 END Now change the operand on row 3 to multiplication and insert a row right after row 3. Set the TYPE of the new row to Database, and define it like this: CASE WHEN (&ACCTSEG(1)& >= 5000 AND &ACCTSEG(1)& <= 7999 ) THEN 1 ELSE 0 END The resulting formula is: That is how you can easily mimic the IF logic in Active Planner formulas. 19

20 Addendum Conversion functions that I have found helpful I had struggled for many years when trying to use database queries with MS Access, but especially Excel files. I had never been able to find a complete list of functions that would work in my database queries, primarily when I needed to convert from one data type to another. Well, I finally found a list of functions and I want to pass it on to you. You can use the following list of functions in Jet Engine queries (when your data source is MS Access or Excel). ABS array ASC ASCB ASCW ATN CBOOL CBYTE CCUR CDATE CDBL choose CHR CHR$ CHRB CHRB$ CHRW CHRW$ CINT CLNG COS CSNG CSTR CVAR CvDate CVErr date DATE$ DATEADD datediff datepart DATESERIAL DATEVALUE day DDB error error$ EXP fix format format$ fv hex hex$ HOUR IIF IMEStatus instr INT IPMT IRR isdate isempty ISERROR isnull isnumeric isobject lcase lcase$ LEFT LEFT$ LEFTB LEFTB$ LEN LENB LOG ltrim ltrim$ MID MID$ MIDB MIDB$ MINUTE MIRR MONTH NOW NPER NPV oct oct$ partition PMT PPMT PV QBColor RATE RGB RIGHT RIGHT$ RIGHTB RIGHTB$ rnd round rtrim rtrim$ SECOND sgn SIN SLN space space$ sqr str str$ strcomp strconv string string$ switch SYD TAN TIME TIME$ timer timeserial TIMEVALUE TRIM TRIM$ typename ucase ucase$ val vartype WEEKDAY YEAR 20

21 One other thing that I find helpful when working in SQL Server, is the Convert statement. You can use CONVERT to convert an expression of one data type to another in SQL Server. Syntax for CONVERT: CONVERT ( data_type [ ( length ) ], expression [, style ] ) And some examples of the CONVERT statements that you might find helpful. To convert the year of Active Planner s period begin date to TEXT: convert(varchar,year(&perbegin&)) To convert the year of a date field to TEXT: convert(varchar (4),Year(p.Year_End_Date)) To convert a numeric field to TEXT: CONVERT(VARCHAR(4), glseg1.seg_code) To convert one of Active Planner s Dimension segment values to an Integer: convert(int,&dimensionseg('employees', 2)&) 21

SWITCH(DatePart("w",DateOfYear) IN(1,7),"Weekend",DatePart("w",DateOfYear) IN(2,3,4,5,6),"Weekday") AS DayType,

SWITCH(DatePart(w,DateOfYear) IN(1,7),Weekend,DatePart(w,DateOfYear) IN(2,3,4,5,6),Weekday) AS DayType, SeQueL 4 Queries and their Hidden Functions! by Clark Anderson A friend recently exclaimed Can you really use this function in SQL! In this article of my series I will explore and demonstrate many of the