The Cutek Blog

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.

Last year, Symitar added repgen access to the GLTRAN and GLENTRY files and hardly anyone noticed. These files store all of your daily transactions that have posted since the last Close Day; it’s the exact same information that you get from Teller Totals. Actually, it’s more than what you get from Teller Totals because it includes detail for all user numbers and it includes pseudo-transactions (things like Check Hold information).

Previously, if you wanted to list all checks received during the day, you had to go to the Teller Totals work area or you had to run Teller Totals by Batch and either eyeball the report or parse it with a custom specfile. Now that you have access to the raw data, you can generate this listing instantly with a specfile and present it anyway that you want.

Unfortunately, the release notes were a bit thin on details. Here’s where we can help a bit.

• You can use the cross-file access features to get to the GLTRAN file. So, if you’re sitting on a Share Transaction record and you want to get the full details for the corresponding transaction, you can use the following:

   KEYVALUE=FORMAT("99999999999",MONEY(SHARE TRANSACTION:SEQUENCENUMBER))
   FOR GLTRAN WITH SEQUENCENUMBER KEYVALUE
    DO
     [You are now sitting on the GLTRAN that corresponds to your Share Transaction]
    END

• It’s important to note that the GLTRAN file is emptied when Close Day is run, so you only have access to the GLTRAN for the current date
• To read through all GLTRAN records, either use a batch specfile or use the following in a demand specfile:

   FOR GLTRAN WITH SEQUENCENUMBER "+"
    DO
     [processing for each GLTRAN goes here]
    END

• GLTRAN:POSTCODE can be a little confusing. Rather than try to explain what Symitar means by “0 = Not posted” and “1 = Already posted”, if you want non-voided transactions, just check that GLTRAN:POSTCODE=0.
• An easy way to visualize the difference between GLTRAN and GLENTRY is to compare it to the teller detail shown on Teller Totals:
  Simply use a FOR EACH GLENTRY command to get to the GLENTRY records.

I had a great time at the SMUG meeting last week in Waukegan, Illinois. I saw a lot of old SMUG friends and got to tell both old and new friends about the projects that we at Cutek have been working on:

• New Member App – should be live by the end of the month – this looks sweet!
• CAMS Alert Processing – in beta testing at one client and will be in beta at another very soon
• Mergers – we just finished two in May and there are more coming down the line
• MCW customization, too many SymForms to count, and lot’s of other projects

As part of the SMUG conference (well, actually, after the main meetings were over), I got to teach an advanced repgen class for the first time since leaving Symitar. It was a two-day class (spread over three days) and I covered topics including “Procedures, #INCLUDES and Subroutines”, “Cross-file access”, “File I/O”, “Batch FM, FMPERFORM and Validation”, TRANPERFORM, all types of HTML specfiles (including the new silent HTTP post/get functionality), multiple outputs and a few other topics. I really enjoyed being in front of a class again and talking about things that, in some cases, I had designed while I was at Symitar.