USING EXTRA SCREENS IN LEGALSUITE

INTRODUCTION

LegalSuite has always had the ability to store additional data in Extra Screens. In recent versions, however, this area of the program has been improved and enhanced:

The user can now create an unlimited range of screens which can contain complex fields with default values, calculations, help text and numerous different formats such as string, date, numeric, radio buttons and drop down lists. This enables users to extend the scope and functionality of program way beyond its basic, off-the-shelf purpose and design.

Extra Screens are accessed via the Setup menu.

Figure 1: Extra Screens are created in the Setup menu

TYPES OF EXTRA SCREENS

There are five different ‘types’ of Extra Screens:

Type	Location	Multiple?	Table	Access contents via
Matter Take On	Matter Take On Screen	No	MatField (MEF:)	MEF:Field1  . . . MEF:Field20
Desktop	List of Matters	Yes	MatDocSc (MDS:)	GetDocumentField() or GDF()
Party Role	Parties for this Matter (F4)	Yes	ParRolSc (PRS:)	GetPartyRoleField() or GPRS()
Address Book	Address Book	Yes	ParField (PEF:)	GetPartyField or GPF()
Safekeeping	Items in Safekeeping	No	SafeLog (SAL:)	SAL:Field1 . . . SAL:Field20

Each screen operates in a similar manner – it is their location within the program and the method of accessing the data stored therein that differs.

In some cases, like in the Matter Take On screen, only one Extra Screen is permitted. It’s data is therefore contained in a series of columns in the MatField table called MEF:Field1  . . . MEF:Field20.  Since there is only one screen per Matter, it is easy to access the contents of  Field number 3, i.e.  by referring to MEF:Field3.

Desktop Extra Screens , however, allow an unlimited number of screens. If a Matter has 4 Extra Screens linked to it, for example, there would be four screens each with their own set of Fields:

Screen 1	Screen 2	Screen 3	Screen 4
MDS:Field1 MDS:Field2 MDS:Field3 MDS:Field4 ... MDS:Field30	MDS:Field1 MDS:Field2 MDS:Field3 MDS:Field4 ... MDS:Field30	MDS:Field1 MDS:Field2 MDS:Field3 MDS:Field4 ... MDS:Field30	MDS:Field1 MDS:Field2 MDS:Field3 MDS:Field4 ... MDS:Field30

You cannot, therefore, refer to the data from these screens by using MDS:Field3. You have to use a function called GetDocumentField(screen, field number) which specifies the screen and the field number. This function is described in more detail below.

DESIGNING AN EXTRA SCREEN

Let’s presume you get instructed by FNB Credit Card Division to collect outstanding amounts from clients who have failed to settle their credit card debts. 

The existing Matter Take On screen in LegalSuite will allow you to record the basic details such as the Claim Amount, Interest Rate etc and the Document Database screens (F3) provide additional fields to generate the court documentation. It would be very useful, however, to also record some details about the credit card (e.g. the card number, the expiry date etc.) so that these could be used in letters to the Client and/or Defendant.  An Extra Screen would be ideal for this task.

Let’s create a ‘Desktop’ Extra Screen. These Extra Screens have a lot more flexibility and options when it comes to Document Assembly. For example, you can link the Extra Screen to a specific document,  you can prevent certain documents from being merged if the screen is not filled in and you can get the program to add them to every Matter automatically (based on a Condition).  You will also have to use the GetDocumentField(screen, field number) function to extract the data from these screens and this needs to be explained as part of this white paper.

At the List of Extra Screens (under the Setup menu) press INSERT to add an Extra Screen.

Figure 2: Adding an Extra Screen

Give the screen a description and title. The title will be the wording displayed to the user as the heading of the screen. Make sure the Desktop option is selected in the ‘Program Location’ field.

Figure 3: Adding Fields to the Extra Screen

Press INSERT to add a Field to the screen.

Figure 4: Defining a Field

This Field (#1) is a ‘String’ field i.e. it can accept any combination of letters, spaces and numbers (up to 255 characters).

We have also made it a required field, i.e. the user cannot complete the screen without filling in this field.

Figure 5: Adding another Field

Press INSERT again to add the “Expiry Date” Field.

Figure 6: Adding a date Field

Press INSERT again to add the “Card Type” Field

Figure 7: Adding a Drop Down Field

This Field is a Drop Down Field, i.e. the user chooses from a preset number of options from a drop down list. The list is created using this format:

option|#value|  . . . option|#value

option  -  the text displayed to the user
value     -  the contents of the field

In our example, we want to create a list that has ‘Silver’, ’Gold’, ‘Platinum’ and ‘Other’ as Card Type. To do this we put the following in the ‘From’ field:

Silver|#Silver|Gold|#Gold|Platinum|# Platinum |Other|#Other

This will create a drop down list that looks like this:

Figure 8: A drop down list

If the user chooses Silver, for example, this Field will contain ‘Silver’.

We have also specified some Help Text for this Field. This will create a tooltip which will pop up when the users hovers their mouse over the Field, like this:

Figure 9: Help Text creates Tooltips to assist the user

You may also notice that we specified a ‘Default Value’. That is why ‘Gold’ is selected . . . by default, i.e. it will be the chosen option unless the user changes it to something else.

Now that we have designed our Extra Screen, we need to see how it works in action.

USING IN AN EXTRA SCREEN

Desktop Extra Screens are accessed via the Extra Screen icon on the Desktop (Figure 10).

Figure 10: The Extra Screen icon

When the user clicks on this button, they will be go to the Extra Screen screen (Figure 11).

Figure 11: Adding an Extra Screen – manually

The FNB Credit Card screen is inserted and the user can then fill in the Fields we created.

Figure 12: Filling in an Extra Screen

The user can add an unlimited amount of additional screens.

LINKING AN EXTRA SCREEN TO A DOCUMENT

The manual method of filling in an Extra Screen as described above is unsuitable when used in conjunction with critical documents which require this information.  There are a number of ways to ensure that the user fills in the screen before a Document is assembled.

Let’s create a simple document (Figure 13) addressed to the Client acknowledging receipt of the instruction to illustrate some of these methods.

Figure 13: A document to FNB acknowledging instruction

We now add this new document (which we saved as  ..\LSW\General\FNBLetter.doc) to the list of Custom Documents in the LegalSuite program.

Figure 14: Adding the document

Tip: By giving it the description “1. Letter to FNB...” ensures it appears at the top of the list.

Figure 15: Some useful Document settings

You will notice that the Document will only be displayed if the Condition “MAT:ClientID = 8493” is TRUE.  In other words, only display this Document if the Client linked to this Matter has a RecordID of 8493.

The RecordID is a number used by the database to uniquely identify a record. It is the most reliable way of referring to a record within LegalSuite because it never changes – even if the user changes the Client Code or Name or any other details. The RecordIDs in LegalSuite are displayed between brackets in the blue bar at the top of the screen when editing a record.

You can get the RecordID of a Party from the Address Book by looking in the blue bar (Figure 16). Please see the white paper Using Conditional Statements in LegalSuite for more information on this subject.

Figure 16: How to find out the RecordID of a Party

Restricting the document to only display when the Client is FNB Credit Card Division is a very useful feature because it dynamically changes the program according to the data, i.e. adds some intelligence to the LegalSuite program and makes it much easier for the user to remember what to do.

You may also notice that there is a Condition that will prevent the user from assembling the document if “MAT:ClaimAmount > 0” is FALSE.  In other words, if the user has not filled in the Claim Amount, the program will display the message “Please fill in the Claim Amount” (Figure 17).

Figure 17: The user is prevented from assembling the document

The Claim Amount is used in our document so this ensures that it is not left blank.

The most important setting however is under the Miscellaneous Tab. Here we specify that the program must display the FNB Credit Card screen before assembling this Document (Figure 18).

Figure 18: Linking an Extra Screen to a Document

Since we have made the important Fields in this screen “Required Fields” the user will not be able to continue unless the Card Number and Expiry Date have been filled in. This ensures the integrity of the data within our Document.

The assembled document will look something like this (Figure 19).

Figure 19: The assembled document

EXTRACTING DATA FROM AN EXTRA SCREEN

You will notice that we used GDF(259,1) to extract the Credit Card Number information (Figure 20).

Figure 20: Fields used in the Document

Since there may be more than one Extra Screen linked to a Matter, we cannot put in MDS:Field1 here – we have to tell the program exactly which Field from which Screen to use. We do this by using a built-in LegalSuite function called GetDocumentField(). 

GDF() is an abbreviation for GetDocumentField(), i.e. you can use either

This function has two parameters which identify the screen and the field. It is used as follows:

GetDocumentField(screen, field) or GDF(screen, field)

screen - The RecordID of the Extra Screen
field       - The Number of the Field

The RecordID of the Extra Screen is displayed at the top of the Extra Screen and the Field Numbers are displayed in the left hand column.

Figure 21: The Field numbers are easy to determine

Therefore, to refer to the data stored in the 3^rd field in the FNB Credit Card Extra Screen you simply use GDF(259,3). In our example above, this will return the value ‘Platinum’.

To put it into a document you need to enclose it between double-square brackets [[ . . .]] to indicate it is a Field and then you need to enclose it in round brackets ( . . . ) to indicate that it is not a Merge Field nor a Party Field but it must be retrieved directly from the database.

[[(GDF(259,3))]]  à ‘Platinum’

You can put any valid database field between [[( . . .)]] in a document and the program will replace it with the contents of that Field. E.g. [[(MAT:Description)]] à ‘CREDIT CARD: MNR D LOUW’

You may also notice that we used the FORMAT() command to format the date. Please refer to the White Paper Formatting Dates in LegalSuite for more information on this subject.

ACCESSING THE EXTRA SCREEN DATA WITHIN THE LEGALSUITE PROGRAM

The data from these screens can be used in numerous other places within the program. For example, they can be used in conditional statements (Figure 22).

Figure 22: Extra Screen data can be used as part of a Condition

The data can also be used in the Management Reports (Figure 22) so the information captured by the user can be included in reports to Clients or internally for management reports.

Figure 23: Adding Extra Screen data to a Management Report

The report will look something like this:

Figure 24: The management report with the Extra Screen data

CONCLUSION

Extra Screens are a very powerful feature of the LegalSuite program as they basically extend the data storage capabilities of the program ad infinitum. The ability to add an unlimited number of screens and then insert the data into documents and management reports allows the user to easily customise the program to suit their particular needs.

APPENDIX A: PARTY ROLE EXTRA SCREENS

November 2007

INTRODUCTION

The LegalSuite program now allows multiple Extra Screens to be added per Party in the Parties for this Matter (F4) screen.

Figure 25: A Party for a Matter can now have numerous Extra Screens linked to it

This can be useful when designing complex litigation documents where defendants may have different information (e.g. service dates) which needs to be reflected in various documents. Also, if they have different service dates then the Reminders associated with the various Defendants will also have different base dates.

To get the contents of a specific field from one of these Party Role Extra Screens you use the function:

GetPartyRoleField(Screen,Role,Rank,FieldNo)

where

Screen                  = either the Description or RecordID

Role                       = either the Description or RecordID

Rank                      = the Rank of the Party (e.g. 1)

FieldNo                = the field number (1-30)

GPRF() is an abbreviation for GetParty RoleField()

Example:

GetPartyRoleField('Defendant','Defendant',1,2)

will retrieve the 2nd field from the first Defendant's extra screen called Defendant.

GetPartyRoleField(188,2,1,2) does exactly the same – in this case we are using the actual RecordIDs (188 = the Defendant Extra Screen and 2 = the Defendant Role)

Note:  This function can be abbreviated to GPRF, so GPRF(188,2,1,2) is exactly the same as GetPartyRoleField(188,2,1,2)

This saves space when using these in condition fields and in documents.

DOCUMENT ASSEMBLY

When using it in the Document Assembly process, you can leave out Role and Rank (i.e. put zeroes in their places) and the program will retrieve the fields for the CURRENT party, i.e. the one currently being merged.

For example, let’s say you are assembling a document that is repeating for Defendant and you have a very simple Party Extra Screen like this:

You could put this in the Document to get the Service Date (Field 1)

Service date = [[(FORMAT(GPRF(188,0,0,1),@D18))]]

When you assemble the document  and it is assembled for the above Defendant it will insert Field 1 from that Defendant’s Extra Screen (188) resulting in:

Service date = 1 November 2007

Likewise, you can also insert a Reminder as follows

 and the program will insert individual Reminders for each Defendant based on the date in each Defendant’s Extra Screen.

CONCLUSION

This adds another powerful dimension to the Document Assembly capabilities of the program and should greatly assist document designers who need to create complex documents that reflect disparate information from individual Parties.