REFERING TO SPECIFIC PARTIES IN A DOCUMENT

 


INTRODUCTION

The Party Fields were designed to make it easy to refer to specific Parties in a document. Using syntax such as [[Defendant.1.Field.Name]] one could be sure to get the correct Party in the right place in the document.

Sometimes, however, one does not know beforehand which Parties need to be inserted. For example, if there are multiple Defendants in a Matter and only the first and fourth defendants enter an Appearance to Defend, the document should only refer to these and not the second and third defendants. In other words, it should be able to construct something like “... an Appearance to Defend was filed by AB Smith First Defendant and CD Jones Fourth Defendant...”

Obviously, one does not know which Defendants will be needed in the Document at design time. This information is only known to the user at the time the document is being assembled – i.e. in real time.

To cater for this, additional functionality has been added to the program (Ver 4.560  or later) and the Party Fields syntax has been expanded to allow one to refer to ‘tagged’ Parties.

 

TAGGED PARTY FIELDS

A Party Field has the following format:

[[role.whichone.type.description.listtype]]

The role parameter typically refers to the role of the Party (e.g. “Defendant”) or the keyword “Current” (which referred to the Party the document is currently being assembled for).

 

[[Defendant.1.Field.Name]] - will insert a Field called ‘Name’ for the first Defendant Party.

An additional keyword “Tagged” has been added to this syntax.

For example:

[[Tagged.1.Field.Name]] - will insert a Field called ‘Name’ for the first “tagged” Party.

 

HOW IT WORKS

When the program discovers a “tagged” field in a Document, it will pop-up a list of the Parties and ask the user to tag the relevent parties (Fig 1)


Fig 1: Tagging the relevant Parties

 

The tagged Parties can then be referred to by using the new “Tagged” prefix of a Party Field.

In the example above, there are four Defendants, therefore the traditional Party Fields will contain the following information:

 

Field Name

Contents

[[Defendant.1.Field.Name]]      

JORDAN R

[[Defendant.2.Field.Name]]      

STEEDMAN CHRISTOPHER CHARLES

[[Defendant.3.Field.Name]]      

STEYN JM

[[Defendant.4.Field.Name]]      

ANDREW DOUGLAS

[[Defendant.All.Field.Name.List]]

JORDAN R, STEEDMAN CHRISTOPHER CHARLES, STEYN JM and ANDREW DOUGLAS

 

The user, however, has tagged the first and fourth Defendants, therefore the TAGGED fields will look like this:

 

Field Name

Contents

[[Tagged.1.Field.Name]]             

JORDAN R

[[Tagged.2.Field.Name]]             

ANDREW DOUGLAS

[[Tagged.All.Field.Name.List]]

JORDAN R and ANDREW DOUGLAS

 

As you can see, inserting specific Defendants in a Document is easy, you simply insert the Party Field [[Tagged.All.Field.Name.List]]  to get a list of the Parties tagged by the user while they are assembling the document.

 

PROMPTING THE USER WITH A “MESSAGE”

When the user assembles a Document and a list of Parties pops up, they may need to be reminded why they have to select certain Parties for this particular Document.

To assist them, the document designer can place a “message” in the Document. The way to do this is to insert a special message field before any other TAGGED fields in the Document  using the folowing syntax:

[[Tagged.Party.Message.Text]]

The word “Party” can be replaced with a Role description to limit the list of Parties to only those playing a particular role.


EXAMPLE #1:

[[Tagged.Party.Message.Choose the parties for this document by tagging them]]

The program will display a list of all Parties and display the message “Choose the parties for this document by tagging them” at the bottom of the screen (Fig 2a)

 


Fig 2a: The message prompts the user to select from all the Parties

 

EXAMPLE #2:

[[Tagged.Defendant.Message.Choose the defendants who put in an Appearance to Defend]]

The program, in this case, will only display the Defendants and display the message “Choose the defendants who put in an Appearance to Defend” at the bottom (Fig 2b)


Fig 2b: Only the Defendants are displayed

Messages can be very useful by reminding the user what to do while assembling a particular Document and ensuring the appropriate Parties are selected.

 

INSERTING THE RANK OF THE DEFENDANTS

The names by themselves, however, are sometimes not enough – we have to include the “ranking” of the Party as well, e.g. Rick Jordan First Defendant and Andrew Douglas Fourth Defendant.

In Litigation, Defendants are ranked first, second, third and so on.  In LegalSuite, this is determined by their position in the List of Parties (F4) screen (Fig 3)

 


Fig 3: The ranking of the Defendants

 

To insert the Ranking after the names, one could create a Party Field (lets call it NameAndRank) that looks like this (Fig 4):

 


Fig 4: A Party Field showing the name and the Rank

 

The first two variables are straightforward – they are the First Names and Last Names of the Party separated by spaces. Lets look at the third one in more detail (Fig 5):

 


Fig 5: Creating the ranking variable

 

As you can see, this variable will insert MP:Sorter which is the number which sorts the Matter Parties. It simply contains the values 1, 2, 3 etc depending on the position of the Party in the list of Parties (F4) screen. Conveniently we can use this as the ranking as well.

We set the Format to “Ranking” which tells the program to format the number as 1st, 2nd, 3rd etc in the Document.

We actually want it in words (i.e. first, second, third etc) so we tick the “Convert Variable to Words” option.

 

At this stage, if we assemble a document using our newly created Field

 

                [[Tagged.All.Field.NameAndRank.List]]

 

the contents will look like this (if the user tags the first and fourth Defendants)

 

                RICK JORDAN First and ANDREW DOUGLAS Fourth

 

We still need to add the word “Defendant” after the ranking. Since we want this field to work with any role, we don’t hard-code the word “Defendant” , we insert a fourth variable to this field, the “role” of the party (Fig 6).

 


Fig 6: Adding the role Variable to the Field

 

The role is stored in a new Variable (RLL:Description) which contains a description of the role in both Languages (Fig 7).

 


Fig 7: The new Party Role Variable

 

This Variable was added in Ver 4.560 of LegalSuite. In prior versions of the Program, the Role (ROL:Description) was in one language. In the latest version, an additional table has been created (RoleLang) to store the description in the various languages.

Note: If you have added custom Roles to the program you may have to check the wording of these Role in both languages by going to the Setup menu (Fig 8).

 


Fig 8: Setting up the wording for the various Party Roles

 

Anyway, once you have added the “Role: Variable to the NameAndRank Field and then assemble the primary document, the resulting contents of

 

                [[Tagged.All.Field.NameAndRank.List]]

 

should look like this (if the user tags the first and fourth Defendants)

 

RICK JORDAN First Defendant and ANDREW DOUGLAS Fourth Defendant

 

This is now a very useful Field that can be used in Documents that requires one to refer to specific Parties to the exclusion of others.

 

ACTIONS AND APPLICATIONS

In the field of Litigation, there are two major processes that can be followed, Actions and Applications.

Actions typically follow these steps:

Summons à Appearance to Defend à Trial à Judgement

or

Summons à No Response à Default Judgement

Actions are a lot cheaper but can take a long time. In an Action, the party issuing the Summons is called the “Plaintiff” and the other party is called the “Defendant”

An Application can be used if the matter is more urgent (e.g. a ship is about to leave port with the evidence on board) and the facts are not really in dispute. The Magistrate or Judge will often make a (provisional) ruling based on oral evidence or sworn affidavits. In this case, the party making the Application is called the “Applicant” and the other party is called the “Respondent”.

To complicate the issue slightly, one can sometimes make an Application while pursuing an Action.

Fortunately, LegalSuite is able to handle these idiosyncrasies quite easily.

To summarise, from a document assembly point-of-view, one needs to refer to “Applicants” and “Respondents” if the Matter is an Application (Fig 9) or if the Document being assembled is an Application (Fig 10).

 

Fig 9: Specifying that the Matter is an Application

 

Fig 10: Specifying that a Document is an Application

 

In either of the above cases, the program will automatically change the description of the Party Role to reflect the correct wording. For example, if this field is used

                [[Tagged.All.Field.NameAndRank.List]]


the contents should look like this :

 

RICK JORDAN First Respondent and ANDREW DOUGLAS Fourth Respondent

 

No further adjustment needs to be made to the Fields nor to the Roles in the Parties screen. The program will automatically swop the descriptions based on the settings in Figs: 9 & 10. This feature is available in Ver 4.569 or later.

Finally, we have to consider the situation where the Attorney is acting for the Defendant, say, and wants to make an interim Application on behalf of the Defendant. The Defendant now becomes the Applicant and the Plaintiff becomes the Respondent – but just for this particular document.

This situation is catered for by selecting the “Swop the Plaintiffs and Defendants” option (Fig 11). When this is ticked, the program will make the Defendants the Plaintiffs and vice versa, but just for the current document.

 

Fig 11 Swopping the Parties around - temporarily


In this case, the Party Fields

[[Defendant.1.Field.NameAndRank]]
[[Plaintiff.1.Field.NameAndRank]]

will contain

Standard Bank Respondent
Rick Jordan First Applicant

This feature is in Version 4.573 or later

 

NEW KEYWORD: SELECTED

A new keyword “SELECTED” has been added to the Party Fields and is available from Ver 4.561 onwards.

When the program encounters this word in a Document, it will pop up the list of Parties and ask the user to select one Party from the list. This Party can then be referenced in the document using the “SELECTED” prefix. For example:

 

[[Selected.Party.Field.Name]] - will insert a Field called ‘Name’ for the Party selected by the user.

 

This keyword can be useful if the document designer wants to allow the user to specify a certain party, for example, the addressee, while they are assembling the actual document.

Previously, one would have to create a numerous letters which were basically identical except the addressee changed. For example:

 

Document 1 : Letter to Client giving an update on Matter

[[Client.1.Field.Name]]
[[Client.1.Field.Address]]
.. body goes here ...

 

Document 2 : Letter to Advocate giving an update on Matter

[[Advocate.1.Field.Name]]
[[Advocate.1.Field.Address]]
.. same body goes here ...

 

Now, one can have one document ...

Document : Letter giving an update on Matter

[[Selected.Party.Field.Name]]
[[Selected.Party.Field.Address]]
.. body goes here ...

 

..and the program will prompt the user to select who the addressee is and this Party’s details will be inserted in the SELECTED fields.

Note: You can also prompt the user using the same ‘message’ syntax as with TAGGED fields. For example you could put this field in the Document to remind the user that they should select the Party who the Document should be addressed to:

 

Document : Letter giving an update on Matter

[[Selected.Party.Message.Select the Addressee for this letter]]
[[Selected.Party.Field.Name]]
[[Selected.Party.Field.Address]]
.. body goes here ...

 

In this case, the message “Select the Addressee for this letter” will appear on the screen to assist the user.

 

SCOPE

The scope of the TAGGED and SELECTED contents, i.e. the time they are active or remain in memory, is limited per document. In other words, if the user has chosen to assemble two documents,  for example, they will be prompted to chose any TAGGED and SELECTED Parties again in the second document.

 

CONCLUSION

The ability to refer to Parties that are tagged ‘on the fly’ is another powerful feature of the LegalSuite document assembly process and should allow one to automate the sometimes complex documents required in the Litigation field of law and others.