If you’re not the type of person that religiously pores over the release notes for each new Symitar Episys release (like I am), you may have missed the addition of “User Tracking” in Release 2006.01 almost two years ago. Or, maybe you saw that enhancement but you didn’t know the value of it or perhaps you read the release notes for it, found that the sample code in the release notes didn’t work (it didn’t) and you gave up on it. I’m going to explain why they’re extremely useful.
User Tracking records are just like Tracking records on your member’s accounts, except that they’re stored for each of your users (employees). You can define your User Tracking Types through the User Tracking File Type Parameters, you can create screen definitions for them, you can set security privileges to allow only some employees to create, revise and delete these records (probably the same employees that can modify User records and privileges) and, most importantly, you can validate these records and use FMPERFORM in demand specfiles to create, revise and delete these records.
But, why, you ask, is this important? It’s important because while Symitar still does not allow you to perform batch or demand FM on User records to change any User fields or User privileges, you can now store employee-specific data in User Tracking records and Symitar allows you to both read this data in any specfile and to FM this data with a demand specfile. So, you can use User Tracking to do any of the following things:
- Define a User Tracking Type for sales incentive tracking and store the number of times a user sells up to 20 different items (using User Number 1-20 or User Code 1-20). You can tie this into your Teller Tran specfile, your Account Manager specfile or ACS (if you have it).
- Define a User Tracking Type to store approval limits for loan officers and modify your VALIDATE.TELLERTRAN, VALIDATE.LOAN and VALIDATE.LOANAPP specfiles to reference the limits stored in these records for each user.
- Define a User Tracking Type to store employee information, such as email addresses, branches the employee works at or job titles and create a demand specfile that acts as a front-end to allow specific users to modify this data without giving them access to User Control. You could then reference this data in other specfiles.
Before you start using User Tracking records, you have to know how to read the data stored in them and, while you could manually FM these records using User Control, you will have better results if you know how to FM them with a specfile.
Reading them is easy and, thanks to cross-file access, you can read them regardless of the Target of your specfile. For example, if you store the lending limit for your loan officers in a User Tracking Type 30 record, you can use the following code to get the lending limit for the current user:
USERNUM=FORMAT("9999",SYSUSERNUMBER)
FOR USER WITH NUMBER USERNUM
DO
FOR EACH USER TRACKING WITH
(USER TRACKING:TYPE=30)
DO
LENDINGLIMIT=USER TRACKING:USERAMOUNT1
END UNTIL USER TRACKING:TYPE=30
END
Up until this enhancement, you could only use FMPERFORM on records in the Account file. With this enhancement, you can now also use FMPERFORM to create, revise and delete User Tracking records… if you know the syntax. That last part is key because the release notes and the current Online Publications from Symitar have the wrong syntax. Here are some examples with the correct syntax.
To create a User Tracking record under User 123 with a Tracking Type of 30 and set User Amount 01 to $1,000.00:
FMPERFORM CREATE TARGETFILE USER 123 TRACKING LOC AFTERLAST (0,30,ERRORTEXT)
DO
SET USERAMOUNT1 TO $1,000.00
END
To revise a User Tracking record under User 123 with a Locator of 5 and set User Amount 01 to $10,000.00:
FMPERFORM REVISE TARGETFILE USER 123 TRACKING LOC 5 (0,0,ERRORTEXT)
DO
SET USERAMOUNT1 TO $10,000.00
END
March 24, 2009 Update: Cutek staff recently discovered and reported a bug to Symitar that affects the FMPERFORM command and will cause your specfile to terminate prematurely in an ungraceful manner and in such a way as to leave a login process running (a “ghost” login). The problem occurs if you try to use two or more FMPERFORM commands in the same specfile and those FMPERFORM commands try to FM records in both the User file and the Account file. The workaround is to only use FMPERFORM on either the Account file or the User file in any single specfile and call a SUBROUTINE specfile if you need to FMPERFORM a record in a different file. For example, the calling specfile can perform FM on the account file while the subroutine specfile will perform FM on the User Tracking record. The Symitar defect number is 402514.
November 23, 2009 Update: FMPERFORM of User Tracking records is broken in Release 2009.01, but Symitar tells us they will have a fix in Release 2009.02 (reference Case 4303053), due next month.
