What is a School in Schoolworks?
School is an object which groups together Services (products) / Resources / Accommodation and links Users, Account, Enrolment(s), Booking(s) and Finance for reporting purposes. It was designed to work with individual schools or organisations that have more than one school location. It is possible to segregate or combine schools when needed.
So, for example, it is possible to segregate or share across schools the following:
Services (products), Accommodation, Teachers & Rooms.
This works particularly well for schools that are close in location and can share resources, such as residence rooms or teachers.
How does School work in Schoolworks?
It is possible to book any service with a student across different schools within the same Enrolment,
(This has one exception currently: if you are operating in different currencies in different locations and services are priced in a different currency, different currencies cannot be combined within the same Enrolment.)
School works as a ‘top down’ value, so in most cases, setting the School at one level ‘defaults’ the School to the records below which can help guide the user by limiting options available (although these can be overridden). e.g. adding a School means that the user is initially presented with only that schools services in an enrolment when booking a course, accommodation etc.
Given that the majority of students usually study at one school, this approach helps avoid mistakes and presents fewer options to the user.
Each system user also has a designated School to either limit their access, or to default various screens to show them relevant information without having to always select their school. For example, a user based in one school will most likely wish to see lists of students studying in that school only in the various scheduling, classing or accommodation screens by default.
Account – Default School
There is a field called ‘Default School’ on the account record – we used the word ‘default’ to designate that whilst this is the typical school of the account it can be overridden at a later stage – in the Enrolment or Booking.
Relevant information held on the account, including Default School is then copied to each enrolment created. This also includes Default Agent and a number of finance settings, e.g. Price List Group.
Single currency per account
Currently our Finance Account Balances and Aged Debt routines cannot deal with multiple currency, we therefore ‘force’ each account to have only ONE currency. This is done by having a relationship between Default School (from which we have a currency on the school), Price List Group (to force GBP / EUR pricelists) and Currency (to force currency).
Agent Account – Default School
We also have a relationship between Default School on the Agent, and the Agents which are allowed / presented in the Enrolment screen – so that agents can be segregated by school if needed or shared across all schools but restricted by one currency per Enrolment.
We can set up All Schools GBP and All Schools EUR schools so that we can prevent GBP agents being used with EUR Schools and EUR agents being used with GBP Schools in the Enrolment screen.
Enrolment - School
There is a field on the enrolment called ‘School’ which is copied from the Account when a new enrolment is created. Other settings are copied from the Account as well – Currency, Pricelist group (although this is then overridden by the Agent settings if an agent is linked to the Enrolment). Currently an Enrolment can be linked to one school, although the bookings within the Enrolment can be multi-schooled (again though, currency needs to be considered).
Booking - School
Each Booking (course, accommodation, transfer, exam, sundry) has a related school.
When a Booking is created, there is an option within the booking selector to change the school which defaults from the Enrolment to any other school – this opens up the Services list so that services from other schools can be booked within the same Enrolment.
When finance is created, finance is then linked to the school of the booking.
By storing School on each record, we have a clear audit trail of School – in the event that any of the School relationships are subsequently changed.
Limitations & considerations
Multi school bookings
We will be reviewing this requirement to provide an improved solution
Invoicing
Multi-currency is currently a barrier to multi-schooled bookings across GBP and EUR schools (for example)
If a EUR school and a GBP school require bookings in the same enrolment and, therefore, the same invoice, we would have to consider how to deal with this.
It is obviously not possible or desirable to combine a EUR price and a GBP price on the same invoice
We are considering development to allow for conversion of the EUR pricing at a prevailing rate to GBP or vice versa
Reporting
It is important to correctly use the ‘school’ to determine where a student is and therefore arrival, departure, ‘in school’ reports and alerts
The Booking school is currently available at the Booking reporting level to ascertain the correct school.
We are currently working on a small development change to identify the ‘first’ school booking in an enrolment and the ‘last’ school booking in an enrolment which will assist in reporting changes/movements from one school to another within the ‘same’ enrolment
Certificates
We are seeking agreement on how to manage the production of certificates when students move from school to school.