Running with the Pack

Today we continue our series looking at Monarch’s calculated fields. Yesterday we examined formula-based fields.

One of the options available to us when you begin to create a calculated field is the “Runtime Parameter”. What does that term mean, and why would we want to create such a thing, and how can we use this type of field to our best advantage?

When you create a runtime parameter in your model, Monarch will ask you for a value for that field every time you open that model. So think of it as “Every time I run this model, Monarch needs me to supply this value for this field.”

There are two primary reasons to use runtime parameters:

1. To supply information that isn’t already included in the original data source, and
2. To avoid having to manually editing the model to change the calculations used in the model.

When you build a runtime parameter, you begin with the same familiar options such as the field type and data length. But this time, you have a new tab: Runtime Parameter. On this tab, you’re asked for the current value of the field. This allows you to supply a value for the field to be used right now, in this session. The description allows you to tell the model user exactly what this value represents. Remember, just as we discussed on the topic of commenting, that user might not be you.

You have the option of saving this value in the Windows registry between uses of this model, so that Monarch can present a default value for the field when you need it next time. This is terrific if you’re using a value that needs to be changed only sporadically, like the first day of your fiscal period, or if it’s a very precise value that rarely needs to be changed, like a rate that is the result of other calculations, such as 3.141526.

Finally, you can indicate that the user must supply a value for this field - it cannot be left blank. Monarch won’t proceed with opening the model until a value is given if you’ve selected this option.

Why do we want to avoid manually editing the model? It’s pretty easy to revise a formula, right?

It might not be immediately obvious, but if you were doing something like a commission calculation, and the formula was something as straightforward as

SalePrice * 0.15

and you wanted to change the rate to 25%, you’d have to edit the formula. This would be even more of a problem if you were using that model as part of an automated solution, say if you were using a batch file, because it really wouldn’t be practical. The end user of your model may not even know how to do it.

Instead, you create a runtime CommisionRate, and revise the formula once:

SalesPrice * CommissionRate

Now you can set any rate you want, and you never have to change the model directly.

The Dynamic Duo!

Another way to use a runtime parameter is to create dynamic filters. Instead of being limited to a fixed value for a given filter, you can easily change the value every time you run the model.

Suppose you have list of all outstanding invoices for many customers, and you want to export an Excel table for a given customer only.

Change your existing filter expression from:

CustomerNumber = 12345

to:

CustomerNumber = RuntimeCustNumber

You can use a similar technique for isolating regional data, or product lines, or just about anything.

Sometimes your filters are more complicated. No problem. For instance, you could build multiple runtime parameters:

(InvoiceDate >= RuntimeStartDate) .And. (InvoiceDate <= RuntimeEndDate)

There’s no rule saying that you can only use one runtime parameter!

Now it’s your turn.

That’s it for our primer on runtime parameters. For your homework today, build a runtime parameter into one of your models that will help make the model much more useful. Factor the runtime parameter into another calculated field, and build a filter which relies upon your runtime parameter. In what other ways can you take advantage of runtime parameters for your information needs?

Get comfortable, and creative, with runtime parameters and you will quickly excel with Monarch.