Let’s say that “Firm X” has developed the above report in order to help manage the on-going issue of billing WIP in a timely fashion.  As we all know (for most law practices) the expeditiousness with which WIP is billed directly correlates to its collection realization.  As a result, Firm X typically runs this report in order to try to identify where certain thresholds are being broached. 

For the purposes of this demonstration, let’s say that the categories of interest for Firm X are where any responsible employee has either of their “150 Days” or “1 year” buckets with greater than $15K in unbilled time.  Rather than having to review line by line (what would normally be) a very long report searching for offenders, we can incorporate this business rule directly into the report by making a simple change to the formatting of the responsible employee group row on the report.    

So, firstly, highlight the group row, and on the Properties Tab, under Appearance, click the dropdown arrow next to BackgroundColor and select Expression:

Once in the Expression, type the following:

This simple “if” statement instructs the row to change color should our business rules be offended (the severity of pink indicating just how offensive the user’s unbilled time is). 

Now when we preview the report, we can very quickly identify which of our responsible employees needs to be followed up with:

With the addition of a single expression change,  I think you would agree that the report is now a much more valuable management asset. 

If you would like any other details, please post a comment below or email me at chris.sabine@kelburnconsulting.com.

In Aderant Expert, all address data is stored in a table called HBM_ADDRESS.  Some examples of the columns in this table are: ADDRESS1, ADDRESS2, ADDRESS3, ADDRESS4, CITY, COUNTRY_CODE, POST_CODE.  Depending on the age and origination of the data (i.e. was it converted from a previous system that only stored addresses in text fields?), and the business rules now enforced at the point of data entry, some database rows may only contain data in the ADDRESS text fields (1, 2, 3, 4), while others have been populated with data in the appropriate placeholder fields (i.e. “Toronto” is populated in the CITY field, instead of ADDRESS3), and some are no doubt a combination of both.  Herein lies the challenge: how can I present non-standard data in a standard format?

In DDRAFT, address data might contain logic that resembles something like this:

{If not empty(p_address1)}{p_address1 + “[Hrt]“}{END IF}{IF not empty(p_address2)}{p_address2 + “[Hrt]“}{END IF}

This code instructs the format to only return data if the field in question has a value.  If it does, then it will return that value and enter a hard return in order to maintain the format.  When a null or a blank is encountered, the entry is skipped, and the next field is evaluated in the same way.

In Basicscript, the same logic might look something like this (where address1$ and address2$ have already been populated with the db values):

In both examples, you would be returning the fully formatted result to a single field or table cell.  In Reporting Services, it is my recommendation that the same approach be taken.  So, once you have completed your data set, drag and drop a text field or table onto your report layout.  Right click on the field to contain the address data and select “Expression”.  Once in “Edit Expression”, you would need to enter the following (where address1 and address2 are fields in your data set):

Obviously this example is fairly simplistic, but hopefully you can see how you might extrapolate this logic to meet your more complex formatting requirements.