UK-based consultant Grant Perkins continues to share his insights with us while I do my best to fight back against a touch of pneumonia.

As users will know (I hope!) Monarch offers a broad selection of Functions to help us extract information from a wide range of data sources and then shape it into the format required for further use in analysis or presentation. The list grows with every release and in recent versions the potential for people to be able to create their own “User Defined Functions” tuned to their particular regular needs has greatly extended the concept and aided productivity.

photo credit: Marcin Wichary

Some functions we will use pretty much every day, other so rarely we may almost forget about them or, worse, not be fully aware of what they can offer to make our lives easier or enhance our value to those authorizing our income payments!

So I thought a short list of some of my favorite irregularly used functions and features might spur others to suggest list of their own with the intention of providing everyone with a focal point for appreciating how they may gain by using tools with which they may not be familiar or, perhaps, in ways they has not considered.

Let’s start with functions.

TEXTLINE()

TextLine was introduced a few versions back and then quietly enhanced with an additional option that can be very powerful but may not be in everyone’s toolkit.

TextLine allows you to take a block of text derived from a multi-line field and split it into lines by specifying which line number you want. So far so good. The benefit is that Monarch, for database efficiency reasons amongst other things, will tend to ignore the format of the text and create a new concise display of the characters. However, sometimes the original format matters and so TextLine allows us to present individual lines or reconstruct the original text in its original lines.

What may be less well known is that TextLine also has a SEARCH mode. This allows you to show the content of a line if and only if the line contains a search string that you specify as a parameter for the function.

For those readers already familiar with the concept of the ‘Preceding String’ in the advanced field properties the TextLine SEARCH mode is quite similar in use. The obvious difference is that the search string will be embedded in the line rather than preceding it. (For anyone not familiar with the Preceding String feature …. you really should have that one in your tool kit. I encourage you to check it out.)

TextLine Search mode has many uses but perhaps the most common use is for financial type reports where encoded transactions appear as lists but the codes can be in any order. So it’s no good mapping line 1 to the field for the code “AA” since the value contained my not be AA’s value and, indeed, may not even be in the right format. (The latter situation would at least be likely to create an error to let you know there was a problem!).

TextLine with SEARCH mode would allow you to specify that you want the line that contains, for example “AA:” in the first 3 characters (or maybe position 3 to 5, or whatever you can define to make it unique) and so will populate you calculated field only when it finds that line somewhere in the target multi-line field extraction.

This is a very simple example and you can make the function perform much more complex searches by feeding in different variable parameters – say a reference to another field maybe, or a User Entry field provided when the model is run.

Why not take some time to experiment with it for a few minutes so that you can see and memorize its potential for a future model?

The SPLITS

I had been using Monarch for quite a while before something I read helped me to stumble across the real potential for using the SPLIT functions. These functions, variations on the same functionality, can be incredibly powerful and are usually very easy to apply, though some reports may introduce special challenges that require slightly more thought and effort.

NSPLIT is a specific Name Splitter that can be considered to be of rather specific application but the LSPLIT and RSPLIT functions are more widely applicable and provide easy to use facilities for dealing with reports that are not consistent in presentation or any sort of variable content input field that needs to be broken out into separate component parts.

Great tools and in my view a very important part of the Monarch modeler’s armory.

DTOC and CTOD

Or, in extended form, Date to Character and Character to Date conversions.

Once again these tools allow you to work in ways that direct working with a date of character field will not. One obvious use is for enabling lookup activity between sources that present date information in different ways but avoiding the need for extra work to convert one or other source file into the preferred format before making the connection.

A hidden calculated field as part of the model can make the link work for you.

Likewise if you have a specialized character based date input and wish to display in the same character format on output but perform date based calculations – like elapsed working days for example – you can convert to date format, calculate and then convert the result back to your date needs using hidden fields for the calculated part of the work

Being familiar and confident with these functions can make working with Monarch so much more productive.

Compound Filters

It’s usually relatively easy to build and test a simple filter but working on something complex can be a nightmare, and also may make it difficult to check the results.

So don’t.

Create simple filters that you are comfortable with and can be checked easily – and on sequential sets of data extractions if necessary so that you can see the effects as the filter build up one after the other.

When you are happy with the individual filters make a Compound Filter from all of them using the original stand alone results to test the final outcome.

The secondary benefit of this is that you and up with a known good set of single filters ready and waiting to be included in other Compound filters in many different combinations.

Better yet, if any of the single filters need to be changed (and the old version discarded for any future use) you only need to change one filter definition – all the compound filters that use that single filter will be updated.

(That said be sure that you fully document things for the future and if you work in an environment with shared models and multiple modelers you will need to be certain that you have some controls in place for the way the modeling ‘team’ operates …)

Filter by Value

This is a recently introduced feature that offers tremendous potential for specialized filtering work whether as the only filter applied to the data or as an additional filter used on a previously filtered subset of data.

From the modelers point of view it is probably the quickest way to see what values a field holds and of course to identify any and all records that do not have a value for the field.

By using the “Add current Values” button you make dynamic filtering (i.e. the values in that report) a possibility with virtually no effort. By ticking the option that will filter only unmatched values you can seek out anomalies compared to a desired list. Include empty or NULL value rows can help quickly identify records that might contain errors. All within the existing filter parameters of course.

Bear in mind that if you need a quick list of all possible values in a field this may be the way to get it. Un-filter everything, auto-populate from the table and the click in the top left hand corner of the 2 column display box. The box will turn black. Control-C will copy the entire 2 columns to your clipboard. (Sort the second column first if that is useful – just click the bar at the top of the column to flip the sort order.)

I’m sure that we will see a number of excellent uses of this feature as an output benefit presented on the forum as time passes. But for me the potential of Filter by Value as an assistance tool for model development to make life easier for the modeler is what stands out right now.

Summary

We all have our favorite ‘things’ and ways of working and to constrain people to specific approaches is more than likely to stifle creativity and stunt the options for problem solving. However at an individual level, as a Monarch Modeler, having comfortable familiarity with the tools available can make individual tasks that much more satisfying. Favorite tools, falling immediately ‘to hand’ and being usable without having to work out what to do with them each time you pick them up are important in our lives. I would encourage everyone think of the core tools they need for their Monarch activity in these terms. If your needs are similar to mine then the list above may be a good starting place from which to fill the ‘favorite tools’ drawer.

By my calculations, Grant has offered some tremendously valuable ideas. What are your “go-to” functions, features and/or other approaches that you use to excel with Monarch?

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:

TextLine(A,1)

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:

TextLine(A,2)

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:

Company + Chr(13) + Chr(10) + If(Skip=0,L2 + Chr(13) + Chr(10) + L3, If(Skip=1,L3 + Chr(13) + Chr(10), If(Skip=2,L4,"")))

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:

LSplit(RSplit(A,2,"Telephone: ",1),2,"URL:",1)

and the URL field with:

RSplit(A,2,"URL: ",1)

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.

During my teen years in grade school I was a consummate math geek. I “trained” and competed in national math contests, mostly for fun. Who’d have thought, huh?

In retrospect, I probably should have gone into something like engineering, but computing drew me in. It was probably the possibility of encountering and solving endless calculations and challenges.

Nowadays Monarch feeds the compulsion.

On day 8 of the 30 Days to Become a Better Monarch Modeler series, calculations take center stage.

The Magical Four

For many of us, Monarch would be a fantastic tool if the only thing that it did for us was purely report mining – extracting data from report files. But Monarch’s abilities have grown nicely over the years, and its current collection of calculation tools adds immense flexibility and power to the product.

For those of us who are relatively new to Monarch and formula building in general, I’d recommend reviewing The Basics of Building Monarch’s Expressions before getting too far along into developing calculated fields. The concepts covered in that post also relate to Excel, and any other software that lets you compare multiple values and conditions.

In a short series of posts from almost two years ago, I wrote about Monarch’s field types, and the four types of calculated fields. These include:

• formula-based calculated fields,
• runtime parameters,
• lookup fields, and
• user-edited fields.

I might be mistaken, but I think that those posts still hold up a good primers. Monarch’s functionality hasn’t changed significantly since they were written. So rather than rehash what’s covered there, it might be useful to supply some examples of each type of calculated field instead.

Formula-based

What’s the first thing that comes to mind when you think of formulas and math? I tend to think of basic math, like multiplication and division and such. I probably spent too much time in cost accounting. If you thought of something similar, then you’re on the right track: Monarch is perfectly capable of doing spreadsheet-like calculations to determine products, sums and the like. But I don’t think that basic math is why Monarch’s programmers gave it the ability to accept calculations.

Monarch’s main function is to mine data, and calculated fields help to refine what has already been captured. Sometimes, no matter how talented we become at defining just the right traps in our templates, it seems that some report designer just wanted to thwart us and mock us later. I can hear her now, “Ha! I told you that this was a closed system. You’re not getting my data even if you think that you can mine reports!” Well, I’ve got news for her…

By using Monarch’s special functions in formula-based calculated fields, we can carve up difficult data just like a Thanksgiving turkey (or a nice garden salad, if you prefer). This is the role in which formula-based fields shine. Just about any number cruncher with a spreadsheet can add value to a data set with a few mathematical calculations, but it’s tough to clean up messy data with a spreadsheet.

If you don’t believe me, try working with a 10 page report complete with headers and footers with Excel’s text to columns feature.

Once the data’s been cleaned up then we can add the other types of calculations and remove that work from the spreadsheet or database application.

Runtime Parameters

These fields let us interact with the Monarch model without editing it. They let us tell Monarch what value to use in calculations, like a commission rate or an exchange rate. They let us tell Monarch which customer we want to summarize. They let us tell Monarch to list the transactions which occurred between this date and that date.

Building runtime parameters into a model is easy, and integrating them into formula-based fields is child’s play. The true power of runtime parameters becomes apparent, in my opinion, when we integrate them into filter expressions, and optionally, use those filters with summaries.

Lookups

The logo that Datawatch uses for Monarch, and indeed the name itself couldn’t have been chosen better. Monarch transforms static, lifeless reports into dynamic, useful and actionable data. We might all be content with freeing our report data from its layout constraint.

When we introduce simple lookup fields the game changes: we begin to move from handling data to preparing information. With lookup fields we can add new meaningful and related data to empower us to provide better information. So much so that the entire extraction doesn’t just improve, but rather evolve.

The topic can be somewhat complex, and because of its importance to our work, I feel it best to delay a full discussion until we can devote an entire day to lookup fields.

User-edited

As the name implies, the purpose of these fields is to allow the editing of values by the model user. This is as close as Monarch gets to operating like a freestyle spreadsheet, only without the inter-cell connections and formulas.

When data (text, numbers, dates, times) is entered, it can be exported or printed, but when the model is closed, even if it was saved after the values were entered, the data is lost. It is not stored in the model for later use.

User-edited fields are, almost by definition, of limited use. They’re useful for tagging records while scanning a dataset for particular records, and then filtering based on the tag value.

And now, the editorial part of today’s post… Part of the attraction that Monarch has is that when people understand what it does, they trust the data that it delivers. I fear that some might distrust Monarch if they thought that they could be mislead by being presented with an extraction that included values from user-edited fields without their knowledge.

I have to admit that I struggle to find a truly effective and powerful use for user-edited fields. Maybe its simplicity is what makes it effective, and I’m just once again looking to overcomplicate things. If you have such a use for these fields, I’d love to hear about it.

Your Task for Today

Update: I missed the homework section when I originally posted this!

Today’s task is pretty straightforward: experiment with integration each type of calculated field into a single model. Be sure to set up the field and its calculation so that your output value matches the field type that you specified, or you’ll be greeted by a friendly error message.

Don’t worry too much about lookup fields if you prefer. As mentioned, we’ll cross that bridge soon enough. But if you really want to, have at it and have fun.

Monarch Computes!

If a value can be calculated, there’s a near certainty that Monarch can handle that work. In fact the justification to include the calculation in a Monarch model should increase with the complexity of the calculation, as it ensures that the data is accurate, and it shelters others from preparing that type of work.

Get accustomed to handling the different types of calculated fields available and as clear as a good proof, it’ll be obvious that you excel with Monarch.

—

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

Auto maker Chrysler recently announced their intent to close 789 dealerships (PDF) in the US as part of their recovery plan.

While it’s unfortunate, and will clearly have an impact on individuals and local economies, we can use their PDF list as an example of what can be done with Monarch Pro in terms of:

1. extracting data from a PDF file,
2. automatically handling address data, and
3. freeing the data from the constraints of the report in which it appears to derive further insights

Additionally, with Monarch Pro we can integrate some data from another source that may provide some background into how the Chrysler management team made decisions.

Handling the PDF

The first page is just a cover, so view the second page and “Auto Adjust” to convert the PDF to text and proceed with creating a detail template.

Select a single line for the template sample, including the dealer name and number. Don’t worry that all of the records appear on more than a single line. I used four numeric traps to capture the dealer numbers (not all of them are five digits).

Paint the fields as follows:

• Dealer Name: 31 characters – advanced properties: End Field On End of Left Justification
• Majority Owner: 23 characters – advanced properties: End Field On End of Left Justification
• Dealer Address: 38 characters – advanced properties: End Field On Blank Field Values: 1 (the record for Massey-Yardley Inc. doesn’t behave with End of Left Justification)
• Dealer Code: 5 digits
• Lines: 4 characters

Save your template, and remember to use the Verify feature to make sure that you haven’t painted the fields improperly.

That’s it. We’ve built the basics of extracting the data. Now we’ll have Monarch some more advanced work for us.

Separate the address data

In the Table window, use Monarch’s Address Block feature to automatically isolate regular address lines, city and state names, and zip codes. You’ll need the first three address lines, as well as City, Region, Postal Code and remember to always use the Error Code when working with Address Blocks. If Monarch thinks that it couldn’t handle an address properly, it’ll alert you by supplying a non-zero error code.

Count the product lines

To isolate which products will be affected by the closures, we need to work with the Lines field. The footer within the PDF instructs us that C is for Chrysler, J is Jeep, D is Dodge, and T is Dodge Truck. To track the individual lines, we need four calculated fields.

The report displays multiple combinations of character sequences when multiple letters are used in the Lines field, so we can’t count on a particular character appearing in the same column position. So how do can we tell which lines are affected at a particular location? We’ll use the Instr function to test if any of the specific characters appear anywhere within the field. Instr() returns a zero if the character does not appear, and returns the position of the character within the field if it is included in the field. So our new numeric fields become:

• Chrysler_Line: if(instr(“C”,Lines)>0,1,0)
• Dodge_Line: if(instr(“D”,Lines)>0,1,0)
• Jeep_Line: if(instr(“J”,Lines)>0,1,0)
• Truck_Line: if(instr(“T”,Lines)>0,1,0)

Finally, we may want to review the average number of lines affected by geography, so for a “Number of Lines” field, we can either add the four line counts, or, knowing that the line count is already reflected in the Lines field, we can use the length of the field to indicate the line count. Simply use

Len(Lines)

as the formula for a Number of Lines field.

Now we’ve completely freed the data elements from the constraints of the report, and we can examine the impacts a little more closely.

Build summaries to analyze data

Let’s determine which states are likely to be hit the hardest. Create a new summary named State, and use the state abbreviation as the only key field. Add count (a default field Monarch creates for summary purposes, a second instance of count (we’ll come back to it), and each of the product line counts.

Double click the key field, and set the sort order to be based on the count measure, descending.

Double click the second count field instance, and on the Calculation tab, choose the Percent of Total option, and set the field to display as a two decimal percentage. Double click each of the line counts in turn, setting an upper limit of 10 for the state count. Display the values in a bold red font. This will format all the values greater than or equal to 10 so that they stand out. Click OK to save the summary definition.

It looks like Pennsylvania, Texas, Ohio and Illinois will be the most affected, with 53 closures in Pennsylvania alone (6.72% of the total closures). More Truck and Jeep lines will be closed in Texas than any other state. The Jeep line gets hit the hardest, with 531 total closures, while the Dodge line takes the fewest, at 430. That’s still a significant number, though.

Let’s get a little more granular and build a city-based summary. First, to avoid grouping any potential identical city names in different states, we’ll build a new field in the Table. “City State” gets this formula:

DlrCity+", "+DlrRegion

I used the Dlr prefix for my address block. This formula ensures that we get two entries for Burlington; one in Iowa and one in Washington.

Now create a new summary named City. Our new City State field is the sole key, and again add the count and a Percent of Total count as the measures. Overall, we see that there’s a pretty good distribution of closures at the city level, though Elyria, Ohio will see eight dealerships close.

Creating a summary using the Number of Lines field as the sole key field and count as the measure reveals that most of the closing dealerships will have two product lines affected.

Monarch transforms static data into dynamic information

In just a few minutes and with minimal effort, we used Monarch Pro to convert a pretty standard list into a real information source. In the next post, we’ll look at how we can integrate what we’ve derived here with some additional data from another source to see what other insights might be available to us.

Building even concise summaries, which take advantage of just few calculated fields, can quickly provide practical tools which assist in understanding the information available, and showcase your ability to excel with Monarch.

Buying a T-shirt, in North America at least, means that you pick a shirt that has a label that that reads either Small, Medium, Large, Extra Large, or depending on the manufacturer, maybe Extra Small or Extra-Extra Large. This simplifies the choices rather than forcing an exact measurement.

It’s not about precision; it’s about being in the right ballpark. Estimating and approximating.

When it comes to numerical analysis, just about any metric – revenues, costs, receivables or payables balances, etc. – can be slotted into one of these familiar categories, and a useful and meaningful overview of the topic can be achieved.

Here’s how to implement this approach quickly and easily with Monarch.

We’ll assume that we simply want to analyze the distribution of revenue generated by our customers. First, create a new calculated Character field named Size, with an expression similar to this:

if(Revenue<3000,"1 X-Small",
if(Revenue<10000,"2 Small",
if(Revenue<250000,"3 Medium",
if(Revenue<3000000,"4 Large",
if(Revenue<10000000,"5 X-Large","6 XX-Large")))))

By adding the 1 through 6 prefixes to our Size labels we can easily use the Size field as a key field in a Monarch summary which will be sorted in the familiar manner, small to large, rather than being based on the normal alpha sort.

The amounts are arbitrary of course, and you should change them to suit your needs. You could even go so far as to create runtime parameter fields for each category level. Users of Monarch Pro could extend that functionality easily into other models by simply importing the new parameters, and the Size calculated field, into other models, and enhance a number of models in no time flat.

The expression for the calculated field using runtime parameters (RP) 1 through 5 could become:

if(Revenue<RP1,"1 X-Small",
if(Revenue<RP2,"2 Small",
if(Revenue<RP3,"3 Medium",
if(Revenue<RP4,"4 Large",
if(Revenue<RP5,"5 X-Large","6 XX-Large")))))

RP6 wouldn’t be needed as values larger than RP5 would default to the last label.

The expression could even be revised to incorporate the threshold into the label:

if(Revenue<RP1,"1 X-Small: < " + trim(str(RP1/1000,9,0)) + "k",
if(Revenue<RP2,"2 Small: < " + trim(str(RP2/1000,9,0)) + "k",
if(Revenue<RP3,"3 Medium: < " + trim(str(RP3/1000,9,0)) + "k",
if(Revenue<RP4,"4 Large: < " + trim(str(RP4/1000,9,0)) + "k",
if(Revenue<RP6,"5 X-Large: < " + trim(str(RP5/1000,9,0)) + "k","6 XX-Large: < " + trim(str(RP6/1000,9,0)) + "k")))))

Next, build a new summary using the Size field as a Key field, and simply using the count as the only measure. This will show the distribution of the customers, and instead of having a gut feel for what the distribution would be, you’ll know exactly. To make the summary even more useful, add a second instance of the count field and set it to display a percent of the total. Now you’ve got a real handle on where things are: what needs attention, and what’s doing just fine.

Does the T-Shirt concept fit?

How will you take advantage of this technique to benefit your organization?

T-shirt size estimating can be done very easily with Monarch, thanks to the summary feature, and provides powerful and flexible insights with minimal effort. It’s a great way to XL (sorry, couldn’t help myself) with Monarch.

It’s usually around this time of year that the panic starts in offices everywhere.

It often begins with “We need a clean list of contact information for the annual mailing”, and is just as often followed by an inordinate amount of stress on the part of the person who’s responsible for compiling the list.

The trouble spot, and the staffer in question knows this all too well, is that even though every organization has some kind of contact management system – maybe stand-alone, maybe integrated into something else – someone along the line has made data entry mistakes that mess up the list and what ought to be a pretty straightforward exercise. There are city names in the state field, and all manner of other chaos waiting to be discovered.

All of this, of course, will make filtering or otherwise reviewing the list more difficult than it ought to be, and may take more time and effort to generate a usable list than is available.

Monarch Finds the Problem Areas for You

Monarch offers a really unique feature for handling and isolating address information. The Address Block feature converts either a multi-line character field or several unique fields and automatically determines the logical pieces and splits them into distinct named fields.

First, you tell Monarch what types of address styles to look for in your report: US, Canadian, UK, etc. Next, select the field or fields that contain the address information you need. Finally, you select the fields that you want Monarch to generate from your initial data.

There’s also an option to generate an error code field, and including this field is always a good idea. If Monarch thinks that the address generation process went well for a particular record, it will give the error code field a zero value. But if Monarch believes that something doesn’t look right, it will supply a value of one through five. The descriptions for those values can be found in Monarch’s online help.

Using the error code field is a great way to screen your data, and you’ll find problems with the addresses in the report very quickly.

And if you do find errors, you can make corrections within Monarch. Just create a user edited style calculated field or two if you really must make some manual tweaks, or if some data isn’t just right, build another Address Block with the fields that you list re-sequenced in a way that you believe will let Monarch give you better results.

Once the list seems pretty accurate, you can use Monarch’s filtering ability to isolate particular regions, customer names that begin with the letter M, or even those within a particular zip code.

Directions for Useful Addresses

When all of that is done, it’s a simple affair to export the data out of Monarch to an Excel file or an Access database so that it can be used as an easy data source for a Microsoft Word document for a mail merge, providing personalized letters or just plain old mailing labels. After all, old fashioned snail mail isn’t totally dead yet.

You can find your troublesome address data automatically, stop working so hard to get the data right, and have your data do a good portion of the work for you. All you need to do is excel with Monarch.

When I’m at my desk for anything longer than just a couple of minutes, you can almost guarantee that there will be music playing. And it’s usually one of the many songs I copied from my constantly growing CD collection to my computer. It’s no wonder that the iPod and portable media players in general have taken off as they have. Using electronic copies is so much more convenient.

But when your collection grows it can make it quite to difficult to locate something specific. Unless you have a photographic memory, and if you do: lucky you! So when you hear only a part of song on the radio that you haven’t heard for awhile, and want to listen to the whole thing, how do you find it in your collection, if in fact you even have it?

At this point I should mention that I’m a bit of a renegade, and don’t have an iPod so I don’t use iTunes. I use an old freeware media player that doesn’t have fancy library functions like most of the new stuff does and I’m OK with that. My favorite player software works just fine for me in every other way, so I leave well enough alone.

Well you could start going through your cabinet, and if it’s anything like mine, you might find it eventually… Or you put Monarch to work for you!

It’s More Like Monarch for Fine Tunes

Start with creating a text list of your files (songs). This starts out very retro, in today’s Windows world. Go to the DOS prompt (Start, run command, or cmd). Switch over to the drive that has your songs, if necessary, and enter:

dir /s > myfiles.prn

When this completes, fire up Monarch and open myfiles.prn.

DOS produces a nice Monarch-friendly list, but depending on how you organize your files you may have song titles appearing in groups, separated by folder name. I use folders named by artist, then subfolders for album title, with only the songs for that album in that folder. It’s some sort of obsessive compulsive thing, I know. Oh well, a detail-oriented personality, right?

This sort of thing is right up Monarch’s alley. All of the individual file names become the detail lines (trap on the date, and specify a couple of blank traps where the <D characters appear on other lines in positions 25 and 26. Paint your field for the file names beginning in position 40. I went quite wide – 165 characters – to accommodate my longest file name.

Now add the folder as an append. I trapped using “directory of”, and painted the field from position 17 and went 127 wide.

That’s the heavy lifting done. Now for a little finesse. In the Table window, create a couple of calculated fields. Given that I use a fixed folder structure, I used this formula to extract the Artist name:

LSplit([ParentFolder],5,"\",4)

Then I used this similar formula to extract the Album name:

LSplit([ParentFolder],7,"\",5)

Then I took a couple of minutes to build summaries using Artist, Album and File Name as key fields, using count as the measure. This results in a nice, easy to read inventory report.

Finally, adding a runtime parameter field (SearchFor), that in turn is used in a filter formula (and saved as a separate model file), lets me look for songs that contain a certain word in the name:

Instr(SearchFor,[File Name])>0

All Play and No Work?

This whole exercise really only took a few minutes, and gave me a great tool for searching and managing my files. And while it was all in the name of fun, you can probably think up a way to apply at least some of this approach to something else.

If you’re lucky some great song might even inspire you to excel with Monarch.

Regular readers will recognize the name Nick Osdale-Popa from his contribution to the site a few months ago that gave all of us a better color management tool for Excel.

Well he’s been at it again, only his activity wasn’t recent; it was almost four years ago!

Nonetheless, I only discovered his idea this week and thought that I must pass it along to you.

You’re well aware that Monarch exports to Excel files and many other file formats, and I’d bet that you often just copy from the Monarch table window to Excel, without even exporting to a file.

One of my tried and true techniques is to build Excel templates that allow me to paste (or otherwise import) fresh data from Monarch into Excel sheets that already have formulas built to perform special calculations on that data that I just can’t do with Monarch.

Of course you have to be very careful to not accidentally overwrite and lose the Excel formulas when bringing the Monarch data into the sheet.

Well, Nick’s idea takes advantage of the copy and paste operation. It’s so simple, yet immensely useful and powerful.

He simply writes the Excel formula into a character type calculated field, enclosed in quotes, and includes a leading equals sign.

The wonderful part is that when you paste that text from Monarch into Excel, Excel treats it as if you’d just typed the formula and evaluates it as it would normally.

This opens up a whole bunch of possibilities for us.

I have some workbooks that I’ve programmed to update the values from Monarch automatically, and I’ve written a fair bit of program code to handle adding the correct additional formulas to those values and to place those formulas in the proper rows. Using the Excel formulas built into the Monarch model, I won’t need to do that.

As long as the calculated field with Monarch is built carefully, Monarch values can be integrated into the Excel formula, such as this:

"=HYPERLINK("+Chr(34)+URL+Chr(34)+")"

Chr(34) gives us a double quote. URL is the field name in Monarch.

Even the row references can be correct by using Monarch’s Rowno() function to get the row numbers in your Excel formula, like this:

"=F"+Trim(Str(Rowno()))+"*0.1"

The Rowno() function is a good choice, by the way, because it ignores any filtering that might be active, and always returns the current row number in the table, as opposed to the Recno() function which always returns the exact record number in the data source and then shows gaps if the records are filtered.

Thanks Nick!

By being creative and building Excel formulas carefully in Monarch, you’ll save a lot of time and effort in producing your final Excel product as you excel with Monarch.

I was recently required to review a thousand page PDF file. This file contained hundreds of financial summaries for specific topics. The challenge was, and the need for the review, was that just because certain numeric values were permitted by the online system, the updates the users provided might have been incorrect, incomplete or otherwise in need of some adjustments.

For instance, as it was a financial system, during the review one could check for specific business rules or conditions that the online system was not programmed to flag, such as a higher than normal accounts receivable balance as compared to total revenue, or that the gross margins didn’t make sense for that specific type of transaction.

Well, rather than print the document and mark it up with comments and calcuations, or reviewing on-screen and taking copious notes, I wondered how I could make the most of Monarch’s ability to extract data from PDF files.

A few hours later, I had one of the largest, most comprehensive models I’d built in quite some time.

Not All PDF Files are Created Equally

Unfortunately, the challenge that Monarch users often see when using PDF reared its head once more for me. On the one hand, the software used to create the PDF file itself did create a document that Monarch could read, but Monarch didn’t quite create the exact image you’d see if you opened the file with, say, Adobe Reader. It tended to shift the values somewhat within the line. All of this made the exercise of creating the templates, regularly incorporating many of the advanced field properties, some fun in and of itself.

Then I needed to use some of the “slice and dice” techniques to separate four fields that I had no choice but to initially capture as a single field, because of the way the values were shifting within the line, and because of how many occurrences of those values that I treated as a single field appeared differently throughout the report. It just wasn’t consistent at all.

Finally, after much more effort that was initially foreseen, it was time for the real work: to do something useful with all of this extracted data and save myself what would likely be an enormous undertaking.

1 or 0

If you read that heading as “true or false” instead of “one or zero”, congratulations: you know what’s coming next!

Since a major portion of the review was to essentially judge the integrity of the data (do these values make sense?) and to alert for specific trouble spots, all of which were based on numeric data, why not have Monarch perform all of these calculations for me, and let me know where the trouble spots are?

What I determined was that not only did I need to know where the trouble spots were, but I also had to know just how good, or bad, the data set was. Were the users supplying proper values overall, or did we need further training to reinforce our expectations of them? The only way I’d really know that would be to count how many problems I could find. Further, could I use this approach to determine more precisely where our main challenges lied, and where things were basically on track.

Finally, there were some business rules that wouldn’t generate error conditions so much as warnings, like margins were beginning to erode unexpectedly, but the user supplied values were just fine in and of themselves.

To help Monarch point out all of these indicators to me, I determined that I needed a few calculated fields that would return a value of 1 (true) when an error or a warning condition existed, and a zero value (false) when the data was acceptable.

To get started, I built about 20 of these calculated fields to model the various business rules. Then I added two more: one to indicate when any individual error exists within a record, and another to indicate when any warnings exist. Both of these return only a one or a zero value, not the count of the error or warnings.

Now with all of these indicators in place, I could begin some high level analysis.

First I built four simple filters which narrowed the table to show only those records:

1. with errors,
2. without errors,
3. with warnings, and
4. without warnings.

All of this made the final step both very easy and very powerful.

Putting Monarch’s Aggregations to Work

I concluded the model by building four summaries, each using one of the four filters. Within each of the summaries, I included the appropriate error or warning field as measures. In the case of the “Without” summaries, I use the “Count” aggregation instead of the “Sum” aggregation used in the other summaries.

The summaries included the ability to roll up to a high level department number, and to drill down to each level of business case within the department, grouped by the manager responsible. In this way we could review which managers and overall departments were maintaining the system well, and which needed a bit more guidance.

These few steps saved many hours of meticulous manual, likely error-prone review, just for this single review. If I did nothing else with Monarch all year long, as this is a monthly review process, this savings in time and effort alone would be worth investing in Monarch.

Do you have a similar review process with which you could save time and money, and would demonstrate how you excel with Monarch?

One of Monarch’s greatest strengths is its ability to add even more related data to the new data that has just been extracted.

This gives all kinds of flexibility and analytical capabilities to your main information system, be it a small accounting package or a large ERP system, that it doesn’t currently provide. Imagine being able to very quickly get the results that having your database modified and populated – complete with new reports – would provide. Now imagine achieving those results yourself. That’s the power that Monarch provides.

The two versions of Monarch, Standard and Pro, each offer an internal ‘lookup’ style calculated field, while the Pro version adds an external lookup so that you can import values from sources outside of your model automatically.

There are compelling reasons to use, and avoid, both types of lookup field. Let’s take a moment to examine them both, shall we?

While we’re not really comparing the Pro and Standard editions of Monarch (I’ll save both you and me another extended post here: just get the Pro version and thank me later ), an advantage of Version 9 Pro versus the Standard edition is its ability to import objects (like lookup fields) from existing models.

How does this relate to comparing internal and external lookups?

With internal and external lookups previously defined in existing models, you can make quick work of implementing lookups in a new model by simply importing the previously defined lookup into your new model. This is especially beneficial when the original is an internal lookup with a long list of output values. Build it once and reuse it as and when you need it. You can even define the import to be linked to the original lookup so that when the original is manually updated those edits automatically carry over to your other models.

New and Improved Analytical Abilities for Your Organization!

I can’t overemphasize the impact that using this single Monarch feature can have on the value of your work. It’s the first step towards developing new analytics and new insight for your organization.

By constantly looking for meaningful ways to add value to your data with lookups you’ll definitely excel with Monarch.