Capita Education Software Solutions is a trading name of
Capita Business Services Ltd. Our Registered office is 30
Berners Street, London, W1T 3LR and our registered number
is 02299747. Further information about Capita plc can be
found in our legal statement.
There are a significant amount of browser forms in SIMS, these allow the selection of an entity within SIMS such as a student and their processes are available for partner use. Experience shows that these forms have been coded by different teams, hence the concepts will be applicable in the same way between say a staff and a student browse, the implementation may be significantly different.
Basic Rules
A SIMS Login is required.
The user must have sufficient access to complete the process.
Do bear in mind that you might be able to browse and select a member of staff and then have no access to the employee entities and processes that you may wish to use thereafter.
Relationship with the screen in SIMS
The student browse process is likely to accept entries just for the set of filter fields shown in SIMS. Indeed in the case of the student browse this is the case. Other browses may be generic and may show a subset of the available filters.
Filters
There are 2 types of filter
Free Text
Admission Number, Surname and Forename are free text filters. They do not allow the passing of SQL wild card characters and are designed to prevent SQL injection attack. Matching is done on a begins with! Be warned! Some results may appear wrong! For example…
This however searches legal forename, preferred forename and middle name for a match.
Drop Down Standard Filters
Tier, Year, Reg and House are standard filters.
The other filters allow a selection from a list. Multiple selection is not allowed on a student browse but check in SIMS to see if this is supported for any other browse that you wish to implement.
Often the drop down filters will add the ‘<Any>’ or ‘<None>’ values. Other browses may have additional special options which usually will be in angle brackets. For example the year group filter will use a pre-loaded set of year groups from the cache to display the set of available year groups and then ‘add in’ the special values.
Default Drop Down Filter
The status filter is the most important filter and hides significant complexity.
Current
Ever on Roll
On Roll
Leavers
Guests
Future
The effective date is not editable via the student browse but will be in code. This is used to define
Name
Definition
<Any>
Any person who is, was or ever will be a student.
On Roll
Students who are on roll at the effective date will have been admitted to the school, they will have admission numbers and a school history record for the current school with a status of ‘Single Registration’ or ‘Dual Main’ spanning the effective date.
Guests
Students who are not on roll at the effective date. They will have a school history record for the current school with a status of ‘Guest’ or ‘Dual Subsidiary’ spanning the effective date.
Current
The union of On Roll and Guests
Ever on Roll
Students who have a school history record for the current school with a status of ‘Single Registration’ or ‘Dual Main’ as of the effective date or at any time prior to that. (NB: Students may well have more than one period of attendance at the ‘Current School’.
Leavers
Students who have a school history record for the current school in the past
Future
Students who have a school history record for the current school in the future
Please note that the definitions are different to the reporting engine and are strictly students and not applicants. (Although applicants may also be students – past present or future)
Usage
The sample code covers this in more detail. In the case of a student browse, the process is created and a request made to get the set of students passing in the filters selected. This then returns a set of student summaries which can be iterated as required.
Caution
This is often not the best way to get say the set of students in 4A. Usually it is easier to use the reporting engine to achieve this. The benefit of the reporting engine is that it will UNION all of the students and pre-admissions who are expected to be in the group on the effective date. If you want to achieve the same using the student browse, you would also have to invoke the applicant browse and union the results. Indeed, it may be appropriate to mix code and use the reporting engine to get all of the students and then use business objects to process them!
Feedback
Have something to say? Want to suggest improvements?