Posts Tagged ‘code’

CLEAR MULT_CHOICE

Unfortunately, the CLEAR instruction model doesn’t really have any use on its own.  Its job is simple: to remove all the options and option prompts from the specified multiple choice (“MC”) variable.  That’s it.  When used in conjunction with the ADD instruction (which adds options & option prompts to a specified MC variable), you end up with a pair of commands that can dynamically build MC variables on the fly, based on whatever data you desire.

For the sake of this example, lets say we are drafting real estate documents.  We have BORROWERS RPT, which collects information on…well, borrowers!  We have BORRS Full Name CO which constructs the full name of each individual borrower (ie: can only be used inside the repeat).  Lastly, we have BORRS Guaranteed MS, which is a multi select MC variable which asks which borrowers have guarantors.  Here’s how we’d build our BORRS Guaranteed MS variable:

CLEAR BORRS Guaranteed MS
ASK NONE
REPEAT BORROWERS RPT
ADD "«BORRS Name Full CO»" TO BORRS Guaranteed MS
END REPEAT
ASK DEFAULT

That’s it.  We firstly clear the MC variable, then inside an ASK NONE/ASK DEFAULT pair, we add the full name of each borrower to the MC variable.  The user may now select borrower names from the MC variable for insertion into the template.  In conjunction with the list format applied to the variable, you can quickly and easily generate user-specified lists of any data from any repeat you have in your system.

There are far more uses for CLEAR/ADD, but this covers what we consider to be the most useful one.

ASSEMBLE

One of the cooler instructions is the ASSEMBLE command, which allows you to queue up a template for assembly in HotDocs.  When it comes to assembling individual documents in packages/batches (as opposed to a template package in a single document output), assemble is the only way to fly.

The syntax is easy enough:

ASSEMBLE "FileName.ext"

The true power comes from being able to conditionalize the ASSEMBLY command, as well as apply command switches to the ASSEMBLE command.  Imagine that you are drafting a Will or similar document for a client.  You could have a multi-select multiple choice variable (WILL Docs Additional MS) that asks what additional documents you wish to draft after the will.  You could then have something like:

IF WILL Docs Additional MS"Cover Letter"
ASSEMBLE "WillCoverLetter.rtf"
END IF

IF WILL Docs Additional MS = “Trust Deed”

IF ANSWERED ( WILL DEED Exec to Trustee TF ) AND WILL DEED Exec to Trustee TF

WILL POA Exec to Trustee Duplicator CO //duplicates data from executors in will to deed trustees – run before assembling
ASSEMBLE “POA.rtf /ni” //no interview – Trustees uses same Will executors!

ELSE

ASSEMBLE “DeedOfTrust.rtf” //use interview as the trustees are different

END IF
END IF

Between optional use of command line switches, and optional additions of templates to be assembled, the ASSEMBLE command offers a very flexible way to build packages of documents on the fly, based on interview choices.  Many times, this is far more flexible and easier to build than master templates that actually contains 10 or so templates inside it.  Certainly, where a firm wishes to individually profile each document in their DMS, ASSEMBLE is nearly always the right answer.

Final note: you can use the ASSEMBLE instruction directly in templates, inside or outside IF statements – it works the same way you would use INSERT, but with the difference of assembling a separate document, not an ‘in-line’ document.  For basic ASSEMBLE usage, this is fine.  But if you’re writing conditions around them, it is nearly always more elegant and easier to work with in a computation (and quicker for HotDocs to process!).

ASK DIALOG and ASK VAR

The ASK instruction does exactly what it appears it will do – forces HotDocs to ASK (present to user) a specific variable or dialog.  ASK is quite often under utilized, as many developers permit HotDocs to generate a template interview.  For those developers in the know, there is a lot more functionality, flexibility and control possible when you write your own interview.  For those developers who design their own interviews, use of the ASK statement is absolutely critical.

In its simplest form, you simply ASK a variable or dialog.  Lets say we are designing a conveyancing/real estate master interview.  We have borrowers, lenders, their counsel and perhaps a guarantor or two.  The borrowers may not necessarily always have representation, nor will the borrowers always have a guarantor.  So here’s how our interview might look:
In its simplest form, you simply ASK a variable or dialog.  Lets say we are designing a conveyancing/real estate master interview.  We have borrowers, lenders, their counsel and perhaps a guarantor or two.  The borrowers may not necessarily always have representation, nor will the borrowers always have a guarantor.  So here’s how our interview might look:

ASK INTRO DLG //ask whatever intro/matter information we need
ASK PROPERTY DLG //get property information
ASK LOAN DLG //get loan related information

ASK BORROWER DLG //basic information - how many borrowers, any shared address for service - details common to all borrowers

IF ANSWERED ( BORR Num LMT//force user to specify how many borrowers there are going to be
ASK BORROWERS RPT //info for each borrower
END IF
IF BORR Counsel TF //did the user specify that the borrowers had counsel?
ASK BORROWER COUNSEL DLG
END IF
IF LOAN Guaranteed TF //did the user specify that the loan was guaranteed?
ASK GUARANTOR DLG //if so, grab guarantor details as well
END IF

With developer designed interviews and the ASK instruction used in conjunction with IF statements, we can minutely control the interview and user experience.  ONLY those dialogs necessary are presented to the user, which reduces the chance of erroneous data entry, while forcing the user to be presented with the dialogs and questions that are necessary to complete the specifics of each transaction.  Dynamically. Efficiently. Correctly.

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

Limit Spreadsheet Lines Appearing

You want to control the number of lines that appear on a dialog that displays in “Spreadsheet” style.  Quite often, the default number of lines visible on a spreadsheet style dialog are aesthetically offensive. We need to control this for two reasons: 1) its ugly; and 2) screen real estate is quite often at a premium.

Basha Systems use a CNT prefix for specific purpose number variables, to differentiate between a “true” number variable used in document assembly templates, and those number variables used for tracking, counting & limiting. Lets presume we are dealing with a spreadsheet to enter in children’s names and DOB’s. In the dialog PRIOR to the spreadsheet dialog relating to children, create a variable something similar to Var_CNT. The prompt should be something like “How many children do you wish to enter?” In the script of the spreadsheet dialog, place the following:

LIMIT Var_CNT

This will ensure that the spreadsheet is LIMITed to the number of lines that the user has indicated are required. You may wish to REQUIRE the Var_CNT variable, so the user must enter a number to gain access.

If the spreadsheet dialog is actually “Spreadsheet on Parent”, you should script the dialog so that it doesn’t even appear until such time as the Var_CNT variable has been answered. Using this approach, the REQUIRE option is redundant.


Basha Search

Loading

Basha Network

Basha Product Sites