Conventional software works just fine for date based analysis if your fiscal year starts on January 1^st. Excel will happily let you group dates placed in pivot tables as row or column fields into months, quarters or years. You’ll have nice looking and accurate summary tools in no time – if your fiscal dates match standard calendar periods.

But what about the rest of us whose fiscal years don’t line up with that? Or our fiscal periods aren’t all the same number of weeks in duration? How do we get the same results?

To calculate if July 2^nd in a particular year was actually fiscal June or fiscal July, or in which fiscal quarter it belongs, we typically had to resort to all manner of formulas and devices. And if your quarters are comprised of a four period followed by a five week period and then another four week period, well then you’re on your own buddy. Yup, good luck with that.

If this sounds like a challenge that you constantly have to combat, then you’ll love day 20 of the 30 Days to Become a Better Monarch Modeler series, because the topic today is Monarch’s time interval feature. New to v10, this brilliant feature offers us special abilities to handle dates related to both atypical calendar years and fiscal years. I like this feature so much I’d swear that it was devised just to appease me.

By configuring your Monarch models with your specific date needs, you’ll give your models the kind of easy to implement analytical abilities that would make even the most skilled Excel modeler tremble in fear.

Manipulate Space and Time with Monarch

We access the Time Intervals dialog, the master control of this feature, under the Options menu. It shows samples of how various date styles will be displayed in the Table and Summary windows, including:

• Calendar year
• Calendar half-year
• Calendar quarter
• Calendar month
• Calendar week
• Day
• ISO8601 year
• ISO8601 week
• Fiscal year
• Fiscal half-year
• Fiscal quarter
• Fiscal period, and
• Fiscal week

If you’d prefer to display a value in a different you change its “mask”.

If you need to customize the manner by which you define calendar weeks, you do that here. As make changes, Monarch shows you some dates to confirm the impact of your selection.

To make changes to the default fiscal year and its related periods, you do that here too.

You can choose to have your fiscal year consist of 12 calendar months. With this option, Monarch will calculate that your year begins on the first day of any month you choose.

Alternatively, you can define a year that contains 52 or 53 weeks. If you do, Monarch wants to know that your year starts or ends with reference to any day of the year that you specify. We’ll refer to this as “Day 1”.

Once that’s configured, you pick the day of the week that starts your fiscal week. We’ll refer to this as “Week Day”

The last requirement of this section is to tell Monarch that your year:

• Starts on the first Week Day on or after Day 1, or
• Starts on the Week Day closest to Day 1, or
• Ends on the day before the Week Day on or before Day 1, or
• Ends on the day before the Week Day closest to Day 1.

With that set up, Monarch wants to know if your year is divided into four 13-week quarter, or 13 four-week periods.

If you choose the former, you then select from either of a 4-4-5, 4-5-4 or 5-4-4 weekly pattern, and tell Monarch how to handle the extra week in 53 week years.

If you choose the latter, you simply tell Monarch which period gets the extra week in 53 week years.

And that’s it: you’ve defined custom date controls in your Monarch model.

Now it’s time to have some fun.

New Date Functions

Fourteen new functions have been added to Monarch to let us easily access proper date information according to the fancy fiscal year and calendar year customization. They are:

• CalendarWeek
• FirstDay
• FiscalDayOfYear
• FiscalHalfYear
• FiscalPeriod
• FiscalQtr
• FiscalWeek
• FiscalYear
• HalfYear
• IsoDayOfYear
• IsoWeek
• IsoWeekDay
• IsoYear and
• LastDay

I’ll let you refer to the online help for full descriptions, but the intended purpose of each function is pretty apparent just by the name. The ISO functions offer a good compromise between customized calendars and a predefined standard methodology.

As we’ve seen with calculated fields, any time that we utilize Monarch’s functions we introduce all kinds of possibilities, and these new functions add to our creative toolbox nicely.

Using the Intervals in Summaries

To take advantage of the new date powers at your disposal, first add a date field to your summary as a key field. Double-click its name in the key field list to display the dialog box and activate the Matching tab. The last option is labeled Time Interval. Select this and then pick one of the date styles (see the list above).

Monarch will give you a preview of the values it calculates based on your selection on the right side of the dialog.

Once again, Monarch shelters us from all kinds of complexity and gives mere mortals effective and easy to use tools that let us get back to doing what we’re supposed to be doing instead of forcing us to be some kind of expert technology master.

Your Task for Today

Make today the day that you master Monarch’s customized calendars. Test the effects of defining a fiscal year, building some calculations using the new functions and define a few summaries that employ different time intervals on the Matching tab of the field definition.

Now revise the calendar customization and review the effect of your changes to your calculations and summaries.

Becoming a better Monarch modeler means that you know what to expect your outcomes to be before you implement them, and that best way to know that is to practice, practice, and practice.

Master the Space-Time Continuum

Well that’s a bit of a stretch, but with a little up-front effort you’ll find that there’s little that you can’t analyze where dates are involved.

If today you fight with summarizing date based activity, fight no more. Instead, just excel with Monarch.

—

Continue your commitment to Become a Better Monarch Modeler with Part 21 of the series, or review Part 19.

As we’re at the midpoint of the 30 Days to Become a Better Monarch Modeler series, today on day 15 I have a real-life challenge and proposed solution that I think quite nicely reinforces some of the concepts and tools that we’ve discussed so far.

This week a new Monarch Forum member named MikeMetta posted a sample multi-column address list and asked for the forum’s assistance in creating a model to handle the extraction properly, as he wasn’t yet achieving the results that he needed. It was, in Mike’s own words, “tricky”.

Looking at his sample it was clear that Monarch, using its regular address handling facilities would have a tough time with it, due to the now-you-see-it-now-you-don’t nature of some descriptive comments that appeared within the addresses. If that weren’t enough, telephone numbers and web site addresses were tacked onto the address without any blank lines in between that information and the address.

What to do?

Instead of trying to extract different pieces with detail and append templates as was being discussed as possible approaches, I began working on capturing the entire block as a single field, with the intention of breaking it up by using a few different calculations myself, and by letting Monarch do some of the heavy lifting too.

The method successfully extracted the sample data properly, so I thought that it might be interesting to share this with you, as this type of challenge, or variations of it, isn’t as unusual and in fact is probably pretty common.

Setting it up

First up was defining the multi-column region which was pretty straight-forward work for a two column layout. On to the detail template…

Looking at the sample, the largest block was six lines long. I created a detail template that was six lines long to handle this painting the single field across the width of the column, trapping on a single alpha character at the start of the field (a non-blank trap would work too, and would probably be better for numbered companies). In the Advanced tab of the field definition, I set the End Field On the end of left justification. To keep it easy for future formula building, I named the field simply as “A”, and that’s the end of the template building. On to the slice and dice work…

Breaking it down

The following employs functions that have already been cited in this series of posts.

In the Table window, deriving the Company name needed a Character field with the formula:

Now the real data separations start. In order to isolate the true address data, I thought it necessary to separate each component of the block, so line 2 of the block became the field named L2 with the formula:

Similarly, L3 and L4 with built with TextLine(A,3)and TextLine(A,4).

Now we’ve got the name and address bits broken out, but how do we get Monarch to know which lines are truly address related, and which are descriptive text? The unfortunate answer is that we can’t. At least, I can’t determine a universal solution to that. Still, where there’s a will there’s a way.

I added a user-edited calculated field to the model named Skip. Skip represents the number of lines to ignore in the address block after the company name, since all of the sample address showed descriptive lines, when they existed, between the company name and the address.

Then I keyed into the model a value of zero if no descriptive text existed for that record, or a value of one or two as applicable when descriptive text did exist, as appropriate.

With this prep work done, I could finally build a field that I could use to feed a Monarch Address Block. My AddBlock character field got this formula:

Using AddBlock as the data source for an Address Block, I instructed Monarch to extract Address line 2 as “Address”, City as City, Region as State, and Postal Code as Zip Code (for US addresses in the sample). There’s the heavy lifting done as Monarch automatically populated those tough to extract bits into the table.

Finally, the built the Telephone field with:

and the URL field with:

Your Task for Today

With a reasonably quick effort, I’d developed a single reusable model that was able to extract all of the important data. That said, can you see a shortfall in this model as has been described? What component isn’t clearly (and entirely) isolated?

Your task today may be tougher than the previous tasks, but you’re now equipped to complete it. Add the functionality to the model that I didn’t describe: duplicate this model and to it add the full descriptive text that is integrated in the original address chunk, if any.

Mission Accomplished

While I certainly wouldn’t expect that you’d want to use an approach that employed user-edited fields when hundreds of addresses are to be extracted, but for reasonably small samples it could be a workable long-term solution. It really shouldn’t take too long to populate the Skip field for even a fairly long list of addresses, and given the end result, that time spent doing manual data entry might be viewed as a good investment.

Admittedly we’ve had some bumps in the road, but I hope that you stay tuned for the second half of the 30 Days to Become a Better Monarch modeler, and discover even more that you can do to excel with Monarch.

—

Continue your commitment to Become a Better Monarch Modeler with Part 16 of the series, or review Part 14.

On day 10 of the 30 Days to Become a Better Monarch Modeler series, we’ll put Monarch’s functions to work to improve our models, both by facilitating finicky data extractions and by adding useful calculations that are based on the extracted data itself.

On day 8, I wrote about the types of calculated fields. In the Table window, functions can only be used in formula-based calculated fields, filters, user-defined functions, and in the Find dialog’s expression builder.

Monarch supplies us with a good number of built-in functions. So much so in fact that in order to better locate them, Monarch presents them by category. At the top right of the formula tab dialog we can change the default from “All Functions” to one of the six available groups:

1. Date: everything related to calculations with dates
2. String: everything related to calculations with text (why didn’t they call it text?),
3. Numeric: everything related to calculations with numbers,
4. Conversion: everything related to changing from one data type to another,
5. Special: a handful of logical and verification functions,
6. Report: functions which return data about the report itself, and
7. User-defined:

I should mention that the term string is often used by programmers to refer to text, and to be consistent with Monarch’s terminology I’ll use it here too.

There’s no practical way to discuss the purpose and proper syntax for each and every function here; there are just too many of them. Besides, I’m not certain that doing that would be of any value as Datawatch has done a fantastic job of documenting each function within the formula tab. As a function is selected, the online help is displayed at the bottom of the dialog.

So what’s my job here today? I suppose that it’s to reinforce the need to understand what data type a function will return. Many if not most of the difficulties that I’ve seen Monarch students struggle with when creating calculated fields is not understanding why Monarch is giving them an error; most often the all too brief “Operand Types” message.

The “Operand Types” message is telling us that we’re mixing data types within the formula, such as attempting to divide a string value by an integer. The root cause is often not understanding the type of data that the function used in the formula will return.

Functions to Assist in Modeling

Some of the functions used to often assist in capturing data that is difficult to isolate in a template alone, for whatever reason, include:

• LSplit and RSplit, which break up long strings into pieces based on your instruction
• Extract, which seeks out particular strings or characters within a longer string
• Left, Right, and SubStr which extract text from the left side, right side and middle of strings
• InTrim, which cleans up duplicate spaces within a string, and
• The indispensible TextLine which, as the description indicates, can be a life-saver by isolating a particular line within a block of text.

Functions to Improve Captured Data

Even when you are able to capture data with a template alone, the results aren’t always optimal when they’ll be used for other systems or calculations. When that’s the case, some of the go-to functions include:

• CtoD, which converts Characters to Dates,
• Str, which converts numbers to strings,
• Val, which converts strings to numbers, and
• Chr, specifically Chr(13), which represents a carriage return character and acts like the Enter key on your keyboard.

You might be wondering about that last one. Sometimes a report might have address data scattered on the report and you might have to paint the fields separately instead of within a single multi-line field. Add to that the complexity that data entry isn’t always perfect, and suddenly you’ve got, say, State and Country data appearing in the wrong place. By combining separate fields while using a “hard” return with Chr(13), as in State+Chr(13)+Country, you can then use that calculated field as the input for an Address Block (which we’ll discuss later) to have Monarch do the data cleaning for you.

Your Task for Today

Nobody expects you to memorize every available function in Monarch. But what you can do is begin to examine the functions. Just a couple every day will probably do. In a model that you store just for testing and experimentation purposes, build calculated fields using the functions of the day. In very little time, you’ll get familiar with them.

Adding Functions Makes for Less Work

Using the right function in the right role will vastly reduce the time that it takes to build accurate models, and the quality of the model too. Instead of fighting with particular trapping methods, and potentially re-inventing the wheel to derive a calculated value, put functions to work for you, and you’ll excel with Monarch.

—

Continue your commitment to Become a Better Monarch Modeler with Part 11 of the series, or review Part 9.

In a prior post, I wrote about how Monarch outperformed Access as a report writer. Today the wind has blown the other way, and we’ll focus on how Access can provide additional functionality for your Monarch models.

Monarch user Diane recently asked whether a logarithmic function was available in the software. Unfortunately it is not, so the hunt was on to find an alternate solution.

Initially I thought that she might be able to export values out to Excel and then apply Log functions to the data, and would then finally be able to import back into Monarch with an external lookup. But the large data sets would prevent that with Excel 2003.

And that was a good thing, because it forced me to look for another option, and what I devised was, I believe, a better solution.

It occurred to me from my SQL programming efforts that many functions can be called in the process of querying the database, so I checked to see if the Log function could be called in an Access query. It could!

This small act can let you effectively add to Monarch’s abilities pretty easily. I described the steps to take in detail on Datawatch’s forum, but here is the general concept.

First, we need to create the initial Access database in which to build our custom query, so export the table records to a new Access database. For this type of need, there’s a good chance the query will be used regularly, so be sure to setup a Project Export with Monarch.

There’s an important step while defining the export, and that is to tell Monarch not to overwrite the file when exporting, but instead to add data to the database. Why is that? If Monarch overwrites the Access database, it will destroy the custom query that will be defined in the next major step. Finish defining the database definition by electing to overwrite the destination table within the database and running the export.

Now start up Access and open the newly created database and create a new query with the query wizard. Add all of the fields that you need to the query and select the default of Detail and finish the query. Open your new query and under the View menu select SQL View. You’ll see something like

SELECT Table.Field1, Table.Field2
FROM Table;

This is where you can define a new field using a function. Just add a little bit to the SQL that Access creates.

SELECT Table.Field1, Table.Field2, Log(Table.Field1)/Log(10) AS LogValue
FROM Table;

The “AS” lets you name the field as you desire, instead of letting Access assign a name for you.

Saving the query stores your customization in the database and this addition to the database will be used by Monarch Pro. This is the next step of the process.

Back in the Monarch model, create a new external lookup. Select the Access database, and instead of selecting the table that was exported from Monarch, select the new query.

When Monarch runs the query, the SQL statement calculates the function using the values in the table, and the results of those calculations are brought into Monarch.

OK, interesting enough, but what can be done with it?

There are a number of functions that are available in Access that aren’t built into Monarch. Which one can you use to your advantage to help you excel with Monarch?

I always found Batman to be the cleverest of the famous super heroes. He always had the coolest gadgets, had designed them himself, and always had them at the ready.

Batman doesn’t have to be the only one building cool and useful tools. One of the best ways for you to excel with Monarch is by building what Monarch calls “user defined functions“.

In and of themselves, they’re a fantastic feature of the product. But when you share your expertise with them with the rest of your group, alleviating them from the nitty-gritty details, you’ll be their hero.

All you need to do is get comfortable with Monarch’s linked objects features, available in V9. Being a fairly extensive topic, Datawatch felt that it was such a significant addition Monarch that it warranted separate documentation. You’ll find that there’s a very nicely written guide (a PDF file) available when you install Monarch.

Once you’re up to speed, give your fellow Monarch users a quick tour of how they can benefit from your hard work by instructing them how they can simply import the various Monarch objects that you’ve created into their models, or by creating links to your work in their models.

To The Bat Cave!

Be a super hero to your organization. Load up your utility belt with high powered custom functions, make them accessible to all, and you and your group will excel with Monarch.

Over the past week, we’ve been discussing Monarch various functions that you can use in your calculated fields and filters. So far, we’ve covered date functions, the special report functions that return data related to the origin of the data (as opposed to the data within the report), and we even had a quick look at the set of special functions that Monarch offers to check data values, generate random numbers (often used in auditing) and its implementation of the “if then else” type of function seen in many software packages.

Accurate Data: The Final Frontier

It’s tough enough sometimes just getting the data we need properly captured from within our reports and other source. But sometimes our data isn’t always exactly what we want it to be, at least in terms of type, and since some manipulations are easier to perform than one type than another, today we’ll examine the functions that allow us to convert from one data type to another.

Asc()

Every single character, number and symbol that you can type in a document and view on your computer (and some that you can’t see too), are stored internally by the computer as values. “Asc” is short for ASCII, an acronym for what essentially is referred to as the standard way that your computer converts characters to values to store and use in its memory. There are countless web pages (even entire sites) that can inform you about the ASCII values (or “ASCII table”), but one of the cleaner, more concise ones available just happens to be on the Datawatch support site.

One additional benefit of the table on the Datawatch page is that at the bottom you’ll find how all of this relates to the Monarch Utility program, and may well be the only official documentation on how to perform search and replace tasks with the Utility.

So what’s the big deal with converting letters and symbols and such into a decimal number, and what would you ever possibly need this for with Monarch? Have you ever seen odd square boxes, or symbols that don’t seem to belong, in a data file? With the Asc() function you can determine exactly what that thing is, and deal with it properly yourself, or tell the supplier of the data file exactly what bad data is being inserted incorrectly into your report.

CharToSeconds()

This function converts a string that looks like a time, like “10:09:36″ into the number of seconds since midnight, a numeric value.

Chr()

Chr() is the opposite of the Asc() function. Where Asc(“A”) returns 65, Chr(65) returns “A”. Chr() is great for inserting symbols like a carriage return: Chr(13).

CtoD()

This indispensable gem has been discussed on this site more than once already, to convert a Character field to a Date field.

DateToJulian()

This function converts a regular date field to a Julian date value. Some ERP systems built with Sybase or JD Edwards software seem to use Julian dates, or variants of them.

DtoC()

Opposites are at work again, this time reversing the CtoD() function, and returning a character string that looks like a date.

JulianToDate()

Anyone care guess what this does?

SecondsToChar()

Yet another opposite function, this time converting the number of seconds from midnight into a character string that looks like a proper time.

Str()

This function converts a numeric value into a character string. The function has a few optional arguments, which allow you to specify how long you want the string to be, the number of decimal place to round the value, and a character with which to optionally fill up any remaining space in the string.

Val()

The final function of this set is also the final opposite; this time converting a character string that looks like a number into a true numeric value.

Universal Translator

I often refer to Monarch, when introducing it to those unfamiliar with it, as a type of universal data translator; able to almost effortlessly convert data from one format or location to another. These functions really do extend the analogy, easily changing and translating raw data from one presentation into another. Use them wisely and you’ll live long and prosper, or at least excel with Monarch.

Over the last couple of posts, we’ve examined some of Monarch functions. Since we’re on a bit of a roll, let’s carry on with the topic.

Today we’ll look at a special category of functions, known as, well, special functions. There aren’t too many, so this might be pretty quick.

If()

Just about every application that allows you to do any kind of analysis has an “If” function, and Monarch is no different. The format is If(condition, result if true, result if false). Incredibly simple, but simultaneously really powerful. If() doesn’t care what kind of data you use for the condition test, as long as it can properly resolve the condition. That means that these conditions are valid, and can be used in an If() function:

but these are not valid in an If() function:

As well, you can include, or “nest” multiple If() functions together in one expression, such as:

In this example, a ProfitAmount of 300 would be “Good”, 800 would be “Great”, and -100, a loss, would be “Poor”.

IsEmpty()

The IsEmpty() function tests to see if a field is empty. I suspect that this is really meant to test character or memo type fields, but Monarch’s online help doesn’t specify that requirement. The function returns a numeric value, either one if the test field is empty, or zero if it isn’t. So if the field MiddleName is blank,

would return a one, but if the field held the value “Stephen”, it would return a zero. Close to the IsEmpty() function is…

IsNull()

Where IsEmpty() tests for (I suspect) an empty string, IsNull() tests for absolutely nothing. That is, there’s no value in the field at all. Since IsEmpty works well for character or memo type fields, I would use IsNull() exclusively on numeric or date fields. And just like IsEmpty(), IsNull returns a one when the test is true, and a zero when the test is false.

So if your report has a field where a date is optional for a specific record or transaction type, you can test to see if a date exists for a record before you do a calculation with that date. Let’s suppose that you need to calculate a due date of 30 days after an invoice date, when an invoice date exists, that is. The formula would be:

CtoD(“”,”m/d/y”) properly returns a null value to a date type field.

The last two functions in the “special” category are:

Rand() and RandEx()

They both generate a random integer value. Rand() gives you a value between zero and 32,767. RandEx() goes considerably higher; from zero to 4,294,967,295. Random number generators have many practical purposes, but honestly, I rarely use them. In fact, I use Rand() from time to time for creating data from scratch in Excel, but I really don’t recall having ever used either of the random functions in Monarch.

That’s a Wrap

As I said at the top, the list of functions in Monarch’s “special” category of is pretty short. But mastering these functions, especially If() in it’s multiple instance version, can be key in your ability to excel with Monarch.

Last week we touched on a couple of useful conversion functions that are available to us in Monarch. Today we’ll continue looking at functions; this time focusing on one of the smaller function categories, that of the “report” functions. Report functions are those which give us data related to the actual report file in use, not the direct data included in the report itself.

File()

The File() function returns the full path and filename of the report from which your record was extracted. While this is a pretty straightforward function, and you might wonder why you would ever need to include text like “D:\Reports\Shipping Report.txt” in your data, there are times when I find it absolutely indispensible.

I like to keep my historical data handy, effectively creating mini data warehouses. I like to create topic folders for these mini data warehouses. For instance, I might have an AR folder and a Shipping folder. Within each folder I’ll store reports representing the monthly activity for that topic, as this makes it much easier to extract periodic data which can easily analyzed graphically.

When you store many instances of a report within a topic folder, you need to organize your reports a little. My convention is to start with the topic name, like Shipping, and always include a three letter month and a four digit year, along the file type extension, like “Shipping Jun 2008.prn”. At a glance I know what the file is, and for what period the report was run. Additionally, your report may or may not include data that you can extract to determine a period. And if that’s not troublesome enough, you may share my situation, in which the date that appears in the report isn’t actually properly representative of the actual fiscal period.

So my solution is to extract the period from the filename. Since I know that I will always use a “.prn” (or “.txt” extension, I know that the last four characters in the filename will be an extension. Further I know that I’ll always use a “mmm yyyy” structure just before the extension. That’s seven characters, plus the four for the extension, for a total of 11 characters. So using a Right(File(),12) on “D:\ReportsShipping\Shipping Jun 2008.txt” will give me “Jun 2008.txt” regardless of the category name. Changing that slightly to Left(Right(File(),12),3), I get “Jun”. To get the year, Left(Right(File(),8),4) will return “2008″. Put it together with a “/1/” string in the middle, and you get Left(Right(File(),12),3) + “/1/” + Left(Right(File(),8),4).

Finally, using all of that as the input for a CtoD function, like:

and you get a valid period in your data that you’ve derived from your filename.

ID()

I find ID() to be a bit of an odd one. It returns the number of the report from which your record was extracted. As you open multiple reports in Monarch simultaneously, Monarch assigns a value of 1 to the first report opened, and adds one to each successive report. In all these years, I’ve yet to find a use for this. Have you?

Line()

The Line() function returns the line on which this record appears in the report. You can get some odd looking, yet accurate, values with Line() when you’re using filters.

Page()

Similar to Line(), Page() returns the page number of the report from which the record was extracted. From time to time I’ve taken advantage of the Page() function when building filters. Some times data appears on the first page of a report that gets captured by an extraction template (based on the trap created in the template), but I didn’t necessarily want that part of the data set. Rather than playing with the trap to somehow exclude that bit, I’ll use the Page() function and filter out all the page one data (Page()<>1).

Recno()

Recno() returns the sequential detail record number, starting at 1. If your data set has 100 records, and your filter only returns three records, you may see 7, 43 and 89 as the only values returned.

Rowno()

Rowno() is similar to results of the Recno() function for some reports, but the notable, and useful, exception is that Rowno() isn’t affected by filters. If your filter returns 100 records, Rowno() will return 1 through 100.

It’s the Function of the Function

The importance of the various functions available isn’t so much what the function actually does, in and of itself, but more how you can use it creatively to achieve something that isn’t immediately obvious. Use your imagination and a little experimentation, and you’ll excel with Monarch.

Yesterday I received a message from a reader asking about how she could resolve a challenge with extracting dates from her report.

The problem was that the date in the report appeared in the form of 01-Oct-07, and she wanted 10-01-2007. She’d been trying to use, correctly, the CtoD function, but kept getting null values no matter what she did.

I supposed that she was really close to a possible solution. If she was indeed using CtoD(RptDate,”m/d/y”), where RptDate is a character field, then Monarch would indeed return a null value. A subtle change to CtoD(RptDate,”d/m/y”) yields 10/1/2007.

The date is correct, but that’s not the exact format she wanted. To get that, with leading zeros for both the month and the day numbers, it takes a much more complex formula:

This formula uses the basic date conversion formula as above, but extracts out the day, month and year values, adds leading zeros with some string conversion and manipulation functions, and ties them all together with a couple of dashes.

Just a few minutes later, a member of Datawatch’s online Monarch Forum asked another date related question. In this case, the character date appeared as mmm-yyyy, and once again, CtoD was returning null values.

CtoD needs three values in order to convert to a date: day, month, and year. If you’re missing any of them, CtoD will fail in every case. This means that you’ve got to supply what’s missing yourself to make it work.

Since the report itself didn’t include a day value, then the day number that we supply the CtoD isn’t really important; it’s just an arbitrary value to make the function work. To make sure that your formula works for every month, you could pick the 15th or the 28th, but in situations like this you’re probably better off with choosing the first of the month.

A possible formula to resolve this challenge is as follows:

Again, string manipulation functions play a role as we pull off the left and right sides of the report date, and add our own day number in the middle, and the “m/d/y” tells Monarch what format to expect in our final string.

Today’s the Day

Monarch includes quite a number of date related functions, and we’re sure to explore them further in the future, but the thing to keep in mind is that sometimes they need a little help from you to get you the right results. Do some more homework today on Monarch’s functions and you’ll soon feel that you can excel with Monarch.

From time to time you may run into a report designed by some renegade programmer who thought that having values shift positions from line to line on the report was actually a good idea. Additionally, maybe she thought that, rather than display zero values, it would be best if the report simply doesn’t display anything at all for that field.When it comes to making it easy for the Monarch modeler, nothing could be further from the truth. We like predictable (in that we know that a value – something! – will appear where it should) and nicely aligned values.

When the Floating Trap Isn’t Enough

Sometimes you can handle these situations nicely with the floating trap feature. But sometimes there just too many problems with the line for Monarch to make sense out of it.

Fear not! All is not lost. But it will take a little extra work to get the results you need.

Recently a user of Datawatch’s Monarch Forum posted this snippet from his report:

Hmm. This sample doesn’t post very well here. Rather than spending my time fighting with it, I’ll point out the original post with the sample.

You can see that there are both floating and missing values in the sample. The best of both worlds, as it were…

The solution involves knowing how many fields you expect to see on the line, and introducing a device – an unusual character, anything that you wouldn’t expect to normally see in the report – to allow for extracting the values easily with one of Monarch useful functions. This character will allow us to split up the fields later on.

The first step is to capture the entire line as a single field, rather than even trying to get this field and that field at the outset. We’ll name that field “A” as it really doesn’t matter what we call it.

Next, we insert our splitting character. Field B has the expression:

In field A, any occurance of 11 consecutive spaces will be replaced with a single vertical bar, otherwise known as a pipe character. Why 11 spaces? Any time there are 11 spaces in this sample, we know that a needed field is completely missing. You’ll need to carefully assess your particular report to determine this number.

Next, we clean things up a little bit more. We’ll still have a number of repeated spaces, so determining exactly where our fields are is still a bit of a challenge. Now we eliminate the repeated space, replacing them with just a single space. Field C has the simple expression:

Now it’s a simple matter to replace all of those unwanted spaces with the splitting device (our delimiter). Field D has the expression:

Be a Data Chef: Slice and Dice!

Finally we have string with nothing but values and pipe characters. Monarch can dissect values from such a string easily. Our first field that we really want from the report, Open, is a Numeric field and has the expression:

Monarch will split field D into 40 sections, based on the location of the pipe characters. You can always supply a higher number of sections than you really need. Monarch doesn’t care. Just make sure that you’ve supplied enough. The exact number is fine if you want to count the fields.

Once Monarch extracts that bit of the original field, it’s still a character string, so we use the Val() function to convert it to a number, as that’s expected by the field type we defined.

The next field, NetBilled, simply increases the last value in the last formula by one, like this:

By spending a few minutes creating the remaining fields (use the Duplicate button), you’ll have tamed this beast of a report that you thought was not possible to model with Monarch.

The process could be streamlined a fair bit by combining the separate calculated fields. Instead of using the various fields B, C, and D as presented above, you could establish field B as:

Then your final fields would use:

Additionally, by introducing just a couple more fields, you could make this a portable solution for any report that is giving you the same problem, and the only work you need to do to model for that particular report would be to define the final values fields themselves.

By using runtime parameter calculated fields for the number of spaces (SpaceCount), the delimiter character (NewDelimiter), and maybe the number of fields if you really want to be picky, the final expression would be:

Alternatively, Let Excel Split The Fields

Building the various numeric fields that split our B field (with all of the pipe characters), might be avoidable. And you can achieve with the same end result too!

Just export the B field, and any other fields you’ve appended, to an Excel file or text file, then import that file into Excel and use Excel’s Text to Columns feature, specifying the pipe character as the Other delimiter. Excel will put each field value in its own cell properly across the columns.

Now that’s using Excel with Monarch!

Powerful Data Mining Technology for Everyone

It’s easy to take your tools for granted, especially after you’ve been using those tools for awhile. But every time I see a really oddly designed report, and someone has created a Monarch model for it, I’m reminded of just how good Monarch really is.

Combining many of Monarch’s features, and perhaps using them in unusual or even possibly an unintended manner, will really let you excel with Monarch.