HotDocs Instruction – ASCEND [VAR]

The ascend instruction is used with the REPEAT instruction to sort the resulting output.  Here’s what the official HotDocs help file states:

The ASCEND instruction sorts lists of answers (gathered using a REPEAT instruction) in alphanumeric order, from 1 to 9, and from A to Z. The DESCEND instruction sorts lists of answers from 9 to 1, and from Z to A.

There are two major uses for the ASCEND instruction: in a computation and in a template.

Consider a lease where you may wish to generate a list of lessors, sorted ASCENDING by last name, then first name (say, a husband and wife on the lease – the last name isn’t quite enough).  Your template may look like this:

«REPEAT LESSORS RPT::>LESSORS Name Last TE:>LESSORS Name First TE»
– «LESSORS Name Full CO»
«END REPEAT»

The above template code is generated for you by HotDocs’ REPEAT builder, using the advanced options (1 or 2 level sorts, filters and list format example.

Alternatively, you may wish to create a list of all Plaintiffs in a single variable.  This is a very handy and common use in litigation type systems – you use computations to generate a list of parties in the matter in different formats, and output the result to a text variable.  Thereafter, you dont have to REPEAT every time you want a pre-set & formatted list of parties – you simply use the text variable you SET..  Your computation to output a list of all Plaintiffs may look something like this:

SET PLF Names All TE TO “” // clear our variable where the result will land
“” //start off the computation with an empty (but necessary) result
REPEAT PLAINTIFFS RPT
FORMAT (“a, b and c”)
ASCEND PLFS Name Last TE
RESULT + PLFS Name Full CO
END REPEAT

SET PLF Names All TE TO RESULT

After this computation is run via your interview process, PLF Names All TE will now hold the value of all plaintiff full names in the matter, sorted alpha by last name, and may appear something like this:

Billy Blogs, John Doe and Marcus Fitzgerald

ADD TEXT TO MULT_CHOICE – dynamic

Recently, we looked at how to use the ADD and CLEAR instructions in HotDocs to dynamically create an option for widows and widowers, so that regardless of gender of our client, the user was always presented with a gender appropriate reference, that still had an identical option under the hood.  This time, we’re going to look at the real power of these instructions: with dynamic repeating content.  For this article, we’re going to look at a situation where we have to address a single letter to multiple vendors and have those vendors specified by the user during the interview.  Here’s the pieces:

VENDOR RPT – repeating dialog that collects vendor data
VENDS Name Full TE – the full name of the vendor on VENDOR RPT
VENDS Addr Block CO – a computation that calculates for address block for each vendor (code not listed, it could just as easily be a text/memo field that is filled in)
LETT Vendors MS – a multi select, multiple choice variable that will ask the user which vendors they wish to send a letter to (dynamically created)
flt LETT Vendors CO – a filter that will look at the user selections in LETT Vendors MS, and filter out the ones that weren’t selected.
COUNTER – the HotDocs system variable that will return the number (as a number) of the current repeating dialog. This can ONLY be used inside a repeat instruction.

Here are the steps:

1) Clear LETT Vendors MS and ADD all vendors to it
2) Present LETT Vendors MS to the user for selection
3) REPEAT VENDORS RPT in the template with the appopriate filter, so only those vendors selected in LETT Vendors MS appear in the resulting document.

Firstly, somewhere in your interview process (you DO use interview computations to calculate, control and regulate data collection for your templates, right?), you will have ASKed the user to fill in the vendor details.  Presuming that we have already collected our vendor details, we now need to build the multiple choice variable.  So somewhere in your interview computation, but AFTER you have ASKed VENDOR RPT, we do this:

ASK NONE
CLEAR LETT Vendors MS //clear first, then ADD
REPEAT VENDOR RPT
ADD "«COUNTER»|«VENDS Name Full TE»" TO LETT Vendors MS //the option is the counter, the prompt is their name
//you could wrap the add instruction inside an IF statement, if you are uncertain as to whether VENDS Name Full TE is ANSWERED() or some other logic particular to your system
END REPEAT
ASK DEFAULT

We now have LETT Vendors MS containing a full list of all vendors.  So at somepoint after the above script runs, you would ASK LETT Vendors MS, most likely as part of a dialog that relates to the letter we are drafting.  Now for what our FILTER looks like.

"«LETT Vendors MS::a|b|c»" CONTAINS "«COUNTER»"

This is a little tricky.  Multiple choice variables store their results as text, but multi-select multiple choices store their values as an ARRAY of text – much like a repeat.  Because of this, a multi-select variable cannot be directly compared to a straight line of “regular” text.  Additionally, no multi choice variable can be compared directly to a number.  So there are three solutions in that one line of code.  The value of LETT Vendors MS is converted to a REGULAR line of text, using the chevrons embedded inside double quotes.  That’s the first solution.  The second solution is to use a custom list format, “a|b|c”, which means that each selection is split by a pipe | character.  I’ll explain this in a later!  The third solution was to wrap COUNTER in chevrons and quotes, which takes COUNTER – a numeric value, and converts it to a string.  With all of this going on, we can now use CONTAINS to correctly compare the selections of LETT Vendors MS and the value of COUNTER.

Now, for the template….

«REPEAT VENDOR RPT::::flt LETT Vendors CO»
«VENDS Name Full TE»
«VENDS Addr Block CO»

Dear «Some Variable Here»

Some letter content here....

{-- conditional page break --}
«END REPEAT»

This instruction will repeat the template infinitely whilever there are iterations inside VENDOR RPT, but will ONLY include iterations where the filter is true.  For the sake of this article, lets say there are three vendors: 1) John Doe 2) Jane Doe and 3) Billy Blogs.  When presented with LETT Vendors MS, it looks like this (brackets contains options):

(1) John Doe
(2) Jane Doe
(3) Billy Blogs

Lets say the user selects 1 and 3.  Here’s what our FILTER looked like:

“«LETT Vendors MS::a|b|c»” CONTAINS “«COUNTER»”

Here’s what happens when our template repeats:

Repeat #1: “1|3” CONTAINS “1” (evaluates to TRUE, John is included)
Repeat #2: “1|3” CONTAINS “2” (evaluates to FALSE, Jane is excluded)
Repeat #3: “1|3” CONTAINS “3” (evaluates to TRUE, Billy is included)

Congratulations.  Your multi select multiple choice variable has allowed you to quickly present a list of ALL vendors to the user and ask them which one gets a letter.  No databases (although you could use one), nothing too heavy; simply collect the vendors, build the multiple choice variable in HotDocs, ask which vendors get the letter, then repeat and filter for the selected values.

Now, I promised a bit more explanation on the whole “a|b|c” thing.  To do that, lets look at a concept called DELIMITING.  Delimiting is simply putting a specific character between each value you want to look at.  Common delimters are commas and pipes.  I prefer pipes, as they aren’t ever used in names, addresses and other pieces of data – they truly do identify the end of one bit of data and the start of the next one.  But lets say we DIDNT delimit our selections from LETT Vendors MS.  Lets say we have 14 vendors (wow!), and the user selected 1, 4, 5, 6, 12.  The value might look like this:

145612

That’s right – its just a string of numbers.  This would mean our filter would “break” when repeating vendor #14.  Because the text “14” appears inside “145612”, even though the user did not selection option #14.  However, with delimiters, our value looks like this:

1|4|5|6|12

And 14 does NOT appear in that value, so the comparison is run correctly.

Clear as mud? Its a bit to get your head around, but when comparing multiple selections in multiple choice options, it is definitely best practice to delimit your strings and use CONTAINS instructions.

ADD TEXT TO MULT_CHOICE – static

Two of the more useful instruction models in HotDocs for dynamic interviews and variables are ADD and CLEAR, which go hand in hand to dynamically construct multiple choice variables.  This is the first of two HotDocs tips, which will deal with the basic CLEAR/ADD instructions with “static” content.  The next article will be about dynamically building a multiple choice variable in HotDocs with a REPEAT instruction.

Lets say we wish to ask for a client’s gender (CLI Gender MC) and their marital status (CLI Marriage MC).  Because we have different language in our template that concerns married clients versus divorced or widowed clients, we need this variable.  However, if a client is a widow/widower, there are two options based on their gender.  Because our language content is the SAME for a widow or widower (with gender specific references), we only want ONE option to denote the widow(er) marriage status.  Here’s how we do it.  We create a computation (say, called build CLI Marriage CO)

ASK NONE
CLEAR CLI Marriage MC //always CLEAR before ADD, as ADD simply appends options to the multiple choice variable
ADD "Single" TO CLI Marriage MC
ADD "Married" TO CLI Marriage MC
IF CLI Gender MC"Male"
ADD "Widow|Widower" TO CLI Marriage MC
ELSE IF CLI Gender MC"Female"
ADD "Widow" TO CLI Marriage MC
ELSE
ADD "Widow|Widow/Widower" TO CLI Marriage MC
END IF
ASK DEFAULT

If the client is male, we add “Widow” as the option, but “Widower” as the prompt.  That’s what the pipe | character is for.  Anything BEFORE the pipe is the option. Everything AFTER the pipe is the prompt for that option, which is what the user sees.  Note that because we chose “Widow” as the generic option for someone who’s partner has deceased, we don’t actually need a prompt for the female specific entry – the option IS the prompt.  If there is no client gender specified, we run with a generic prompt, but the option NEVER actually changes for the widow(er) option.  That means we lessen our code on the template end of things, because our option value is generic.

So now, we have a dynamic looking MC variable that will produce its own options based upon the gender of the client.  No doubt, in the dialog that these variables appear on, you would have something like the following script:

IF !ANSWERED ( CLI Marriage MC )
build CLI Marriage MC
END IF

The dialog script basically says that if CLI Marriage MC is NOT answered, then run the computation that builds the options.  This would likely be a part of a SHOW instruction, so that the variable doesn’t show up until it has options.  Depending on your version of HotDocs, there may be alternate ways to structure this to ensure smooth running of the dialog.

And that’s all there is to it.  This is a very simple way to use logic and the CLEAR/ADD instructions in HotDocs.  It is far more powerful to use ADD in conjunction with a repeat, which we’ll be looking at in my next article.

Restarting and Rescusitating the Time Matters Indexer

The Time Matters indexer may get stuck or corrupted.  This article steps you through solution to that problem.

TRASH AND RECREATE THE LNDATA INDEX

1. Log Everyone out of Time Matters
2. Find the Index Folder and Rename LNDATA
e.g. P:TMW9DataIndexLNDATA
3. There may be a locked open file.  You need to make sure it gets unlocked before you move the file.
4. Log into Time Matters and leave it open to allow LNDATA to be recreated.
5. Check for the Icon in the system tray.

OPTIONAL STEP: ACTIVATE SYNCHRONIZATION
1. File -> Setup -> Program Level
2. Synchronization -> Activate Time Matters Synchronization
3. Give it a name:  MAIN OFFICE
4. Log out of Time Matters

OPTIONAL STEP: REINDEX DATABASE
Now Go to the Time Matter Utilities
1. Select the Database
2. Check box to Reindex Main Database

[Note: Potential problems if there is a SPACE in the File Path to the Data Folder]
[Caveat:  If you have extra licenses, you can leave the indexer running on the server]

Clearing out Temp Files

LOCATE THE USER PROFILE SPECIFIC “LNPTA” FOLDER and TRASH THAT
1. Make sure you can see Hidden Files.
2. You should rename the LNTPA folder.
C:Documents and Settings[UserProfile]Local SettingsTempLNTPA
3. You may need to copy the TMWORD.DAT into the new folder

Time Matters Indexer Issues

The Time Matters indexer, on occasion can get corrupted. This abstract explains how to purge and restart the indexer. The text is courtesy of Matt Stone.

TRASH AND RECREATE THE LNDATA INDEX

  1. Log Everyone out of Time Matters
  2. Find the Index Folder and Rename LNDATA
  3. P:TMW9DataIndexLNDATA
  4. There may be a locked open file. You need to make sure it gets unlocked before you move the file.
  5. Log into Time Matters and leave it open to allow LNDATA to be recreated.
  6. Check for the Icon in the system tray.

OPTIONAL STEP: ACTIVATE SYNCHRONIZATION

  1. File -> Setup -> Program Level
  2. Synchronization -> Activate Time Matters Synchronization
  3. Give it a name: MAIN OFFICE
  4. Log out of Time Matters

OPTIONAL STEP: REINDEX DATABASE

Now Go to the Time Matter Utilities

  1. Select the Database
  2. Check box to Reindex Main Database

Affording Document Assembly: the Group Approach

As a document assembly consultant, I am often contacted by solo or small attorney firms who are overloaded with work, champing at the bit to get a Document Assembly system, realize the value but are understandably nervous at the cost. And, they should be. Creation of a good document assembly system is expensive in both time and money. Your law school education wasn’t cheap, setting up your office wasn’t cheap and setting up a potential profit generating document assembly system that will become absolutely integral to your practice won’t be cheap either.

 

So what do you do – bite the bullet and get your money back on the ROI or give up? Here’s a possible third solution – Group development. Two or three lawyers with similar practices might be able to create a system that all of them can use and share the development cost. This, of course, requires collaboration, cooperation and a willingness to compromise. It’s a midpoint between buying a pre-canned system and getting one custom made for your own needs.

If you decide to go with this approach, the first thing you should do is find a developer to build it for you. It’s a very bad idea for 3 or 4 busy lawyers to try to build pieces of a document assembly system and hope they’ll hang together properly. You need a central expert who will advise your group, develop the templates and interviews and make sure everything works with everything else.

After that, devising a group document assembly system is similar to devising one for a single firm. You need to determine the universe of documents that will be automated, set up meetings with the developer and designate an expert from your group to work with the developer.  For the period of development, think of your group as one firm.

Some ideas for setting up your group:

1. KEEP IT SIMPLE. When choosing the attorneys for your group, stay in your area of expertise. DO NOT grab the real estate lawyer from down the street, the PI guy from next door and the estate lawyer from down the hall. These are very different areas of law with very different automation and document gathering needs. Stay within your area – if you’re basically a PI litigation firm, go to other PI lawyers to make up your group.

2. KEEP IT SMALL. It may seem that a system like yours would be good for the 20 other PI lawyers in town. Ever been in a meeting with 20 people? Doesn’t work very well for general consensus, does it? Don’t bring in more than 4 other attorneys.

The bottom line is – We, Basha Systems have been in business since 1996. In that time, we have never seem anyone remove or stop using a document assembly system. Once they’re built, people use them and use them. So, if price is what’s stopping you . . . try the Group approach to keep your costs in line.

All Thumbs

Last week I stubbed my thumb … And while this may not have seemed like a major injury, I came to realize the cost on my productivity.

The thumb is something that we take for granted.  And we use the phrase:  “we are all thumbs”.  This phrase usually refers to clumsiness.  The reality is that the thumb (in opposition to the other fingers in the hand) is a very precise and versatile instruments.

Last week I stubbed my thumb.  The injury led to an infection.  Over the course of a day a blister appeared and spread.  The green puss grew.  My knuckle started to ache.  And by the end of the day, my whole hand was sore.  I could not enjoy the new Wii Console we had bought for my sons.  I could not even type effectively.  In fact, I tried to relearn the way I used the keyboard to avoid using my thumb.  Try to train yourself not to use your left thumb for the Spacebar, Alt and Control keys.

By the next day, the growth of the infection had stopped, but my thumb was a pretty ugly site … It was covered with a layer of green and red puss under the skin.  My children would not touch me for fear of infection.  I could waive my magic thumb, and they would instantly loose their appetites … great for dieting.  The little infection still has a scar over a week later as the skin underneath is healing.  I am now a little more cautious with my thumb and have gained more respect for the critical role of the lowly thumb.