T24 integration

T24 has the ability to restrict data access at various levels. That includes login authorization, access restriction to a certain company within T24 database, files within a company, and individual records in a file. All these SMS restrictions may have an impact on query results which are being produced in T24. Therefore, if a company develops T24 online reporting using external tools, that would certainly involve exporting of raw jBASE data outside the system with all sensitive data being exposed for unauthorized view. The workarounds usually involve simulating SMS functionality outside T24 which is redundant and inefficient comparing to core T24 SMS.

Vultar ODBC driver for TAFC/T24 fully supports T24 SMS module, hence, allowing secured access to T24 files out of the box. The functionality includes:

• T24 user login authorization
• Company restriction (in multi-company T24 environments)
• Application restrictions
• Data range restrictions within a file

In the following example, a group named ACC.EUR has been created to use only ACCOUNT file, and see only the accounts in euro currency (USER.SMS.GROUP file). The GTSUSER user is attached to @ACC.EUR group. Below is a screenshot of the ODBC DSN setup dialog where GTSUSER is set to access T24 data.

SMS.GROUP.ID...... ACC.EUR ---------------------------------------- 1. 1 GB DESCRIPTION. Euro accounts group 2. 1 APPLICATION.... ACCOUNT 4. 1 FUNCTION....... S 5. 1 FIELD.NO....... 8 CURRENCY 6. 1 DATA.COMPARISON EQ 7. 1 DATA.FROM...... EUR

 

The following screenshots represent SQL results retrieved with Microsoft Query. On the left side (1) GTSUSER has full access to T24, and on the right side (2) the user has restricted access, being a member of ACC.EUR group.

1

 

2

The ACC.EUR group does not have access to any other file except F.ACCOUNT. Hence, on any attempt to select some data from another file (ex. F.CUSTOMER), the driver will raise an exception as shown on the screenshot below. The same applies to company level restrictions - users from one company will not be able to query data from another company.

By default, the driver will return CHAR field type for all tables. However, T24 users may switch on a feature that will force the driver to look into STANDARD.SELECTION file in order to find actual field types for a given table.

The following field types are currently supported by the driver:

The driver will automatically extend LOCAL.REF field into a set of data fields accessible in the same table. The resulting fields will have assigned names according to LOCAL.TABLE definitions. See below an example with four local fields defined in T24 environment (on the left), and how these fields are mapped by the driver into the resulting table (on the right).

LOCAL.REF.TABLE containing links between applications and local fields.

LIST F.LOCAL.REF.TABLE @ID............. CUSTOMER APPLICATION..... CUSTOMER LOCAL.TABLE.NO.. 601 602 603 501

In LOCAL.TABLE file we have definitions for each local field.

LIST F.LOCAL.TABLE SHORT.NAME @ID. SHORT.NAME..... 601 SEC TYPE TRADE 602 SEC TYP MGT FEE 603 SEC TYPE SAFEKP 501 FID DEPOSIT REF

Data field 40 (LOCAL.REF) of the CUSTOMER file is being mapped by T24 environment in a set of local fields.

CUSTOMER.CODE..... 300102 ----------------------------------- 33 DISPO.EXEMPT...... 34 ISSUE.CHEQUES..... 35 CLS.CPARTY........ 36 RESERVED04........ 37 RESERVED03........ 38 RESERVED02........ 39 RESERVED01........ 40. 1 SEC TYPE TRADE. 40. 2 SEC TYP MGT FEE 40. 3 SEC TYPE SAFEKP 40. 4 FID DEPOSIT REF

 

A third-party database explorer displays local fields as normal data fields. There is no need for any additional setup, the driver will map them automatically.

In a multi-company environment, customer and financial data are isolated in separate physical files. As an example, and environment with two companies BNK and BR1 will have two customer files FBNK.CUSTOMER and FBR1.CUSTOMER. T24 core provides enough flexibility to get data from the right source, depending which user is running the reports. However, the solution is not so obvious with an external reporting system.

The driver offers an elegant solution in such cases - relative file names. It lists and accepts T24 file names with suppressed company mnemonics, i.e. FBNK.CUSTOMER and FBR2.CUSTOMER can be accessed with F.CUSTOMER name. Each request to F.CUSTOMER will trigger a validation mechanism that will check whether target file exists in the system, and whether the user has enough privileges to read it.

This feature is especially useful in situations when the same report is being produced by users from different companies. There is no need to develop special procedures in order to find out which file to query, the driver will take care about it.

The driver accepts absolute file names as well. This is particularly useful when the reports contain SQL requests to several companies (ex. consolidated reports).

Please note, with T24 support enabled, the driver will provide a list of RELATIVE file names. However, SQL requests may contain both, relative and absolute file names. Also, before selecting data from another company, make sure the user has access permission to it (COMPANY.CODE field in USER application).