 Clubs, Branches, State, Data Conversion…what are my responsibilities. |
| Over the past nine months we have been doing a lot of database conversion for all three levels within the SLSA hierarchy. And when the conversion is delivered, there are a lot of questions as to what to do with it and who should act on the data received. |
| This article will go into detail as to what you should supply Caligular Group when requesting a data conversion as well as what you receive when finished. It will also talk about the flow of data from all three levels and discuss the responsibilities of each level in what they have to do to ensure data integrity and an even flow of information throughout the levels. |
Article Contents
1. Initial State Data Conversion
2. Pushing Data to Branches
3. New Clubs coming on-line
4. What are the Clubs responsibilities?
5. What is the Branches responsibility?
6. What is the State Responsibilities?
7. Ensuring you send data upstream
8. Data Transfer Rules
9. Is it important for me to read the instructions that are given out by Caligular Group?
|
| |
| Initial State Data Conversion (SLS NSW) |
| While this part of the article is pertinent to NSW clubs and branches, it is Ok for other state clubs, branches and states to read as it will explain the overall process used to convert the data. |
| SLS NSW initially provided us with a database containing all of the awards for NSW dating back to approx 1980. Now while this database was in a format that could easily be converted, the integrity of the data within the database was questionable. In reviewing this data it was found that the following integrity faults were present: |
A percentage of members were allocated with duplicate ID Numbers |
| During entry of new members obtaining awards, data entry personnel did not check to ensure that the next member ID had already been allocated. This generally occurred when multiple operators were entering award data at the same time. |
Members were duplicated based on names being spelt differently or spelt incorrectly |
| Duplicates occurred during entry of new and existing members awards. When data entry personnel entered new awards for members, there was a failure to ensure that the member did not already exist or that they had spelt their name differently. I.e. Anthony Smith and Tony Smith are the same person but this was not verified and a new member was created, therefore creating the situation where Anthony has the awards Bronze Medallion and ARC, but under Tony Smith he has the ROC awards. |
Member information was not correctly entered by data entry personnel |
| Data entry personnel during data entry made mistakes with the members details, in address and/or birth date. |
Member received duplicate awards |
| Members may have received duplicate awards during entry of awards, in that Anthony Smith may receive his BM, and then next year his proficiency will be put under Tony Smith, thus creating two members who are the same person with two BM awards. |
| |
| Pushing Data to Branches |
| Your State Centre will already have all of your State data already loaded and will be using this data presently. Branches that become active will be required to import the data for their clubs. The State Centre will provide you with this data and the import instructions are posted in the CPL Help manual located at the Caligular Web Site. |
| The Branch will then import this data and have a copy of the data for their clubs, which for the moment is synchronized with the State Centre. The Branch now has the ability to alter member details and awards for members within their clubs. |
| |
| New Clubs coming on-line |
| When new clubs come on-line, the following steps should be implemented for a successful integration to the SLSA Network. |
If club has it's own database and wishes this information to be merged with the already converted SLS NSW (or any other state data) information, this must be sent to Caligular Group at the following e-mail address: jason.hyde@caligular.com |
If the club does NOT have its own database, then the club can obtain the export from their Branch or State |
Once you have received your information from either Branch/State or Caligular Group (with Caligular Group conversions you will receive instructions on what steps must be completed in order to import the data) you will need to import or install the data |
After the import or install has completed you will be able to manage your clubs information |
Notes on Club Data for Conversion It should be noted that any award information a club supplies to Caligular Group will be ignored, as there is no way to verify that the award information provided is authentic. Award inforamtion will be matched up to member based on information already in the State Centre database passed to us. |
| |
| What are the Clubs responsibilities? |
| The club now on-line has certain responsibilities. These are; |
Ensure data that has been loaded is verified and updated |
Make note of duplicate members that have awards |
Delete duplicate members who have no awards or are incorrect |
Add new members who are not within the database |
| Once these tasks have been carried out the club is obligated to export the Membership Data back to the Branch. Now the common question is 'how often should I send my data to my Branch/State?', well lets use the rule below as a rule of thumb; |
| 'If you update your database once a week, then send an export once a week. If you update your database once a month, then send an export once a month, and so on.' |
| You must remember, if you do not send your data to the Branch/State they cannot add new awards to this member nor update their awards. If you are a club using CPL, then it is your responsibility to manage your club data and send it upstream. Branches and State Centres should not alter the details of member details for clubs that are on-line, that is not part of their responsibility. |
| |
| What is the Branches responsibility? |
| The Branch is the middleman between the club and the State, and for those States, which have Branches; they play a big role in the Award workflow. Branches have the following responsibilities; |
Update member Awards details for members a club has noted as being incorrect |
Via the Exam Request Module process Exam Requests and forward the results to both State and Clubs |
Manage member details for clubs that are NOT using CPL as yet |
Export club data that has been modified by clubs onto State Centre, again, using the rule of thumb for frequency of sending data |
Export State Centre information back to clubs, this will usually be Award information for new members |
| |
| What is the State Responsibilities? |
| The State as it stands is the highest of the hierarchy; this will change to a National level when the Internet version is released. |
| The State Centre has the following responsibilities; |
Process Exam Requests passed on from Branches or Clubs |
Manage member details for clubs that are NOT using CPL as yet, and are NOT being maintained by a ranch |
| The State Centre will hold all of the information for its States clubs. Apart from the Award processing the State Centre is basically a read only system, as Branch and Club maintain member data.
|
| State Centre should not be exporting member details back down to the Branches or the Club, as this will in the end waste the time of the importer, as by the rule of data transfer, any records that are imported that have a the same or greater update date/time will be ignored.
|
| |
| Ensuring you send data upstream |
| As has been said previously, it is important for both Clubs and Branches to ensure that any data that has been altered, by either direct manipulation of the record or via an import from another source, should be sent to its parent, being either the Branch or State. Failure to push this data upstream can lead to delays in Award processing as the State Centre or Branch will not be able to identify the member requesting the award. Should this occur your Branch or State Centre will contact you requesting an upload of your membership data. |
| |
| Data Transfer Rules |
| With the latest version of both CPL and StateWatch, a new Import/Export methodology has been implemented to ensure that the data is transferred with greater integrity. This method is using an XML standard to transmit files. These XML files are then zipped into a zip file for more efficient data transfer within E-mails. |
| It should be noted that CPL and StateWatch will automatically unzip these files for your. There is no need to do this yourself. |
| The data transfer algorithm also follows new rules when importing records from another source. These rules are; |
CPL or StateWatch will look for a key (field or fields) to base its search on for the record to be updated. I.e. currently for the member record this is IDNumber, therefore prior to importing CPL will look at the value of the IDNumber field and try to find it within the existing record in the database. |
If it finds it, CPL will then check the field LastAccessed. This will tell CPL when the target record was last accessed and will compare it to the source records LastAccessed field. |
If both values are the same value then the record will be skipped as it is assumed that the data is the same and does not require any updates. |
If the data target has a later date than the source then an exception is created and the update skipped. |
However, if the target record is not found, then the source record is created within the target database. |
| Using these rules duplication of data is significantly decreased, if not eliminated. |
| |
| Is it important for me to read the instructions that are given out by Caligular Group? |
| Yes. Not following steps/instructions given by Caligular Group can mean that your data will not be imported correctly, which then has upstream effects if you export to your parent entity. Always follow the instructions given and if any problems occur, please contact Caligular Group explaining what has occurred. |