Summary

You have built several DDAS objects and have grasped how to build basic conditions that might include looking for a specific client code or determining if the suit date is empty, but let’s talk about how to push the DDAS envelope even further. Advanced conditions, custom replacements, and running custom programs will be the topics of discussion in this session. For your reference, DDAS system triggers have been included as well.

Advanced Condition Writing

A basic condition is not always going to get you what you want. In some cases, conditions may become very involved and even very lengthy. Here is an example of a longer condition, and this is only the tip of the iceberg as conditions can be four times as long as this one:

upper(SCANFILE.DOCTITLE) = “DECLARATION IN SUPPORT OF DEFAULT JUDGMENT (585)” and inlist(upper(dserve.howserved), “PERSONAL”, “SUBSTITUTE”) and empty(dlegal.answerdue) and empty(dlegal.answerfile) and empty(special.userbdata) and empty(special.usercdata) and empty(spedial.date1) and not inlist(debt.statid, “STTL”,”STIP”,”CONT”) and iftask(dfile, “02DFLTATTY”, “F”) = .f.

Example conditions

• Contactseek command
• Seek command
• Iftask command
• Using “inlist” command

CONTACTSEEK command

The contact seek command allows the user to search for a specific contact in an account and test a field for that contact.

SEEK command

In some cases, there may be multiple records for one account. For example, multiple DSERVE records can be created to record the service information for multiple debtors. Behind the scenes, Q-LawE creates one record for each debtor in the DSERVE database. For example, if there is service information on three debtors, there will be three records in the DSERVE database. If you wanted the condition to test for the service date for debtor 2, you would need to use a seek command to allow the program to find the record for debtor 2. Seek commands can be complex, so Vertican can help you create them.

IFTASK command

The iftask command allows the user to look for the existence or nonexistence of a specific task in an account. This is useful if you are adding a task via DDAS as you can now check to make sure the task does not already exist on the account, preventing duplicate tasks. The chart below lists the different variations of the IFTASK command to check for a task called “900”. Replace the 900 with your task code when using in your system.

Using DDAS to Launch a Program

DDAS can be used to launch a custom program. This unique feature of DDAS truly reveals what DDAS can accomplish. DDAS is no longer restricted to what has been programmed in the DDAS screen; now a program can do something completely outside of the box. Below are a few examples of programs that have been implemented:

• A program that deleted every task on an account with the exception of specific tasks – this is extremely useful if an account falls out of a standard workflow, such as if a debtor files bankruptcy. Using a trigger, DDAS can now delete every task on the account and then add, for example, some sort of review task in its place.
• A program that automatically files suit with the default amounts – DDAS can now be set up to automatically file a suit on an account, saving users the trouble of manually going into the legal screen and manually recording the suit. With a specific action, DDAS can do that for the user.
• A program that can automatically create a new special screen or even a legal record when an action is performed.

How do I know when I need a program?

If you would like to automate something that is outside of what DDAS can do, a custom program may help.

Who can create a program?

Custom programs take a bit of skill to create. It is something that Vertican can do for you if you provide detailed requirements of what is to be accomplished. Many simple programs can be written in about an hour but, of course, the more complex the requirements, the more time will be needed to create and test the new program. If in doubt, contact a Client Service Representative and ask.

Troubleshooting DDAS

When things start to happen without check, it is extremely important to thoroughly test each and every DDAS item before activating it. Even though you carefully made sure that every scenario was accounted for in testing, there comes a time when DDAS does something unexpected and you need to figure out why to make sure it does not happen again. Troubleshooting DDAS involves a bit of investigative work, but the answer will be there. Here is how to troubleshoot DDAS items.

There are two scenarios to consider when troubleshooting DDAS items: whether DDAS will trigger and, if it does trigger, did it do what it was supposed to do. Each scenario will also have several imbedded scenarios within it. Below is the troubleshooting list from start to finish.

• Troubleshooting the DDAS trigger
• Troubleshooting the DDAS condition
• Troubleshooting the DDAS actions

Troubleshooting the DDAS trigger

When troubleshooting the DDAS trigger, all you really need to know is whether the Database and the Field are entered correctly. To troubleshoot this, it does not matter at this point whether the condition is valid, nor what this DDAS item will actually be doing. In this case, we can create a simple test DDAS with the intended database and field completed and with the condition simply pointing to a test file in your system. To show that the DDAS item actually triggered, set up the testing DDAS to display a reminder popup of your choosing. See the example below:

In the example above, it will test if the trigger of DLEGAL.LUSER1DATA is the correct trigger. The condition is set to only be true when this field is changed in the test account of “0” and, when it does trigger, the DDAS item will display a popup reminder window advising that DDAS did trigger.

When the user then goes into account “0” and makes a change to the User Data 1 field, the below response should appear.

This indicates the trigger selected is actually the correct trigger. Once you determine the trigger is correct, you can move to adding and testing your condition as well as the DDAS actions.

Troubleshooting the DDAS condition

When troubleshooting DDAS conditions, keep in mind that neither the trigger nor the actions that are performed are of concern at this point. To make things easy, create a test DDAS and select a simple trigger that users are not likely to be using, and select a simple action such as popping up a reminder window to indicate the DDAS item activated. The example below is a test DDAS that will be testing the condition of “Empty(debt.cdate) and debt.statid <> ‘ABC’”. The field of debt.cdate was purposefully mistyped to show debt.cdat. Note this is a simple example, and conditions can be much more complex than this.

Steps for troubleshooting

• Test expression tool
• Testing on an account

The test expression tool

The test expression tool allows the user to do a very simple test on a condition to validate whether it will come up as true, false, or error out. To use this tool, simply enter the condition and click on the [Test Expression] button to the right of the condition. In this example, the word date was misspelled, and the following error message will appear.

The message above indicates this condition is not valid. Once the condition is fixed, the following message will appear.

In this case the condition resolved as False. When testing the condition without an ourfile number, as in this example, the system will assume the ourfile number of zero. You can test your condition against an account that you know should come up as true or false. In fact, it is a good idea to have two accounts that you test, one that you know should come up as true, and the other that you know should come up as false. In the next example, an account that should come up as false is typed into the For Ourfile field.

An additional testing tool has been added to DDAS for SQL and is included in the ”What’s New” dated 05/18/2019. Individual portions of a condition statement can now be tested to pinpoint what piece of the statement is not a valid expression. Because after you have written something like …

(!qempty(GETPTP(debt.ourfile, “1”, “FIRDUEDATE”)) or !qempty(GETPTP(debt.ourfile, “2”, “FIRDUEDATE”)) or !qempty(GETPTP(debt.ourfile, “3”, “FIRDUEDATE”)) or !qempty(GETPTP(debt.ourfile, “4”, “FIRDUEDATE”))) and GETPTP(debt.ourfile, “1”, “METHOD”)<>”GARNISHMENT” and GETPTP(debt.ourfile, “2”, “METHOD”)<>”GARNISHMENT” and GETPTP(debt.ourfile, “3”, “METHOD”)<>”GARNISHMENT” and GETPTP(debt.ourile, “4”, “METHOD”)<>”GARNISHMENT” and not inlist(debt.custid,”LIN111″) and (iftask(dfile, “LKMC_POST”, “T”) = .f.) and (iftask(dfile, “CLOSED_PIF”, “T”) = .f.) and trans.trx <> “02”

… the last thing you want to do is stare at the string for an hour trying to find the piece that is misspelled or written incorrectly to fix it. Now each piece can be put in the test box and, after clicking test, the same popups as the [Test expression] box will appear.

Note: This new field/button should only be used for testing individual functions. To test a combination of functions, the test expression should still be utilized.

Remember when writing condition statements, when using an OR function to assess pieces of data, be sure to encompass the OR in parentheses to ensure the DDAS will not trigger erroneously.

For example, if the system should trigger for a list of clients and the court state is in CO or NJ, be sure to write the condition: inlist(debt.custid, “ABCCOM”,”WELLS”,”C6124”) and (dlegal.ct_state=“CO” OR dlegal.ct_state=“NJ”).

If the parentheses are not included on the last part of the statement, DDAS will look to see if the custid is in that list and in CO, or it will trigger if the court state is in NJ.

Test expression – what to watch for

Using the [Test expression] button is extremely helpful in testing whether the condition is valid and whether the condition will resolve as true or false. This is because things like Vendorin, YGC, or anything that triggers based on an import cannot fully tell you if it will evaluate to True/False because it will be trying to access bridge tables that are not currently importing. In these cases, the user should test the syntax on a different trigger to ensure it is working as expected before using it with the vendor import.

Once the condition has been validated, the next step is to test the actions that will be performed on the account, such as adding a task code or changing the status of the account.

Troubleshooting the DDAS action

Once a DDAS item is triggered and the condition resolves as true, the DDAS item will now go into action and do something on the account. Some of the actions are simple and self-explanatory, such as adding a task code. But even though it may be a simple action, assuming it does not need to be tested could be a mistake. For example, having the DDAS item add a task sounds simple enough, but a lot can go wrong. Maybe the task code was mistyped, or maybe the task was deleted from the system and a new task was created to replace the one you are trying to use. Always set up the DDAS and test what it does to prevent potential problems from showing up later.

Additional things DDAS can take action to do:

1. Complete tasks
2. Re-date tasks
3. Add notes to the file including X type notes to be exported with YGC updates
4. Update Q-LawE fields, including being able to prevent a field in Q-LawE from being changed by users
5. Send EDI Matrix codes
6. Move to a new desk
7. Update status code 1 and 2
8. Cost requests
9. Tags
10. New in SQL in 2019: DDAS has been enhanced to be able to add a special template to an ourfile. In the DDAS setup, on the Status, EDImatrix tab, there is now a field to select which special template to be added. The special template is added first via the DDAS, so a single DDAS can be set up to add a special template as well as update the fields within the new special template.

Notes:

• If the special template already exists on the ourfile, DDAS will not add a duplicate special template.
• If users are in an ourfile when the DDAS is triggered, they will have to exit the ourfile and reenter before they will be able to see the new special template.

Troubleshooting an existing DDAS from the account level

You have gone through all the steps above to troubleshoot your DDAS items, but something is still not right. Maybe it is something you did not account for, or maybe something changed in the system that affected the DDAS item, such as a task code change. Nonetheless, there will come a time when you need to troubleshoot a DDAS that activated on an account to see what it did and what it did not do. The steps to troubleshooting a DDAS item on an account are as follows.

• Review the note line.
• Review the actions.
• Review the change log.
• Review the error log.

Review the note line

The note line created by DDAS is the first indication that DDAS has done something on an account. This note line will contain the first DDAS ID that was activated as well as any changes it made to the account. In the example below, the first DDAS item to activate was ID 4, and it changed the status as well as added a task to the account.

Review the actions

The next step is to verify that what DDAS said it did, it actually did do. If the note line indicates a task was added, verify the task was actually added. Also, in the case of an added task, look at the create date, time, and user to verify they all match. If you cannot find any proof the action was performed, this will give you a place to start in testing the DDAS.

Review the change log

When DDAS makes a change to your account, it will record a record in the change log indicating what the value was before DDAS touched it and what DDAS changed it to. In the example below, the top item indicates the debt.statid field was changed to “A107” at a specific date and time and by a specific user. Verify this all matches with the date, time, and user of the note line to ensure this was the change made by DDAS. Although you can see the status change here, you will notice the new task code does not get logged in this table, so it is not foolproof.

Review the error log

In FOX, if the DDAS item caused an error, click [Maintenance] from the Main menu of Q-LawE, navigate to the [System Maintenance – Admin tab], click [Backup-Pack-Index], and click [Error Log]. Most errors a user will get in Q-LawE will be recorded in this screen, and DDAS errors are typically recorded with an “In Program” as “RUPDATES.FXP”. So, chances are, if you see an “RUPDATES” error, it is a DDAS error and, most of the time, it will be an error with the condition. In the top record in the screenshot above, “OURFILE” was mistyped by leaving out the “E” at the end of the word, and it is clear what the issue is here. Also notice the field called DDAS ID that indicates the exact item where the error exists. This is extremely helpful in troubleshooting. Keep in mind there are cases where the ID will not get recorded and, at that point, it is trial and error to find the offending DDAS.

In SQL, when there is an error evaluating the DDAS, a popup will occur stating which DDAS needs to be reviewed and fixed.

DDAS Tips

Here are a few tips to help when building and testing DDAS items.

• Do not activate a DDAS item before its time.
• If you do activate the DDAS item, make sure to add a filter for your test account at the end of the condition (“and debt.ourfile = “0 “. Always place a space after the ourfile number if it is less than 10 characters in length, as Q-LawE will find other matches that begin with the same numbers). Adding this filter for your test account will ensure the DDAS item will not activate on a live account before you have tested it.
• Use a test Q-LawE if you have one to test all your DDASs; this helps in testing and ensures you do not accidentally update an account with the incorrect data.
• Create temporary DDAS items to focus only on what needs to be tested, whether it is a trigger, condition, or action.
• Have fun with it and be creative; DDAS can do a lot.

DDAS System Triggers

Below is a list of System Triggers available in DDAS. These triggers can also be found in Q-LawE by going to [Maintenance] > [Setup DDAS] > [Select System].