Running the term
Moving to the next academic year
Every summer the same work. Last year's timetable has to be kept, next year's has to start from the same rooms and lecturers, and the databases have to end up the right way round — in the fortnight when the people who know how are on holiday.
- One screen, all three databases
- A full backup before every action
- Room bookings up to five years ahead
- Free 5-page manual
One screen, instead of several steps and a script
The rollover used to be spread across the product, with one part of it run by hand on the server.
The Year Transition screen puts the whole operation in one place. It shows the databases your licence covers side by side — the academic year each one is set to, its name on the server, and how much course scheduling is actually in it — so the first thing you do is read rather than remember.
Every action that changes a database names that database, states exactly what it is about to do, and asks you to type the database name back before it runs. And every one of them writes a full backup of the database first, before it touches anything, whether or not you expect to need it. Nothing here deletes a backup, ever.
- Copy to DB — replace one database's contents with another's. This is how next year's database is seeded from this year's.
- Swap DB — exchange the contents of two databases. Both are written out first, so a failure halfway still leaves you both halves.
- Save empty to file — build next year's starting document from this one and write it to a file. Nothing on the server changes.
- Delete all schedules or delete all bookings — separately, because they are not the same decision.
The summer sequence
Four steps, in this order, and only the last one is the part anybody enjoys.
Read the three databases
Decide which one keeps the year that is ending and which one becomes the new year. The screen states the year and the contents of each, so this is a decision you make from the screen rather than from memory.
Save the empty starting document
Built from the year that is ending: rooms, lecturers, programmes, branches, groups, courses and settings kept, schedules and bookings and the student list removed, the year advanced by one. It goes to a file, and the server is untouched until you say so.
Set the new year's dates
The first day of the winter semester is what decides which calendar week becomes week 1, so nothing else can be trusted until it is right. There is a button on the transition screen that takes you straight to it.
Load it, enter the changes, generate
Put the starting document into next year's database, add the courses and groups that are new, and run university scheduling as usual. The second year is dramatically shorter than the first, because only the changes need entering.
What carries forward, and what is deliberately left behind
The starting document keeps everything that describes the institution and drops everything that describes one particular year of it. That is not a limitation to work around — it is the distinction that makes an annual rollover possible at all.
- Kept: rooms, lecturers, programmes, branches, groups, courses and every setting you have tuned.
- Dropped: the timetable itself, the bookings inside the year, and the student list.
- Advanced: the academic year, by one.
- Unlimited parallel copies, so most institutions run the live year, next year during the transition, and one for internal verification.
Booking a room for a date that has no academic year yet
A Wise Timetable year is 52 weeks. Week 1 is the week the winter semester starts in, and everything the product stores is addressed by a number in that range. That is exactly right for teaching, and it is the reason a timetable can be moved from one year to the next at all.
It is wrong for one request, and every institution gets it: “can we have the big hall for the conference next June?” — asked in November, for a date in an academic year that does not exist in the database yet. The usual answer is a note in somebody's calendar, and the hall is double-booked the following spring by whoever builds the new timetable without knowing.
Perpetuum is the setting that lets one database hold weeks outside its own year, so the request is recorded where the scheduling is and is seen by everybody who looks. Open the window one year forward and weeks 53 to 104 exist; up to five years either side is allowed. Nothing is renumbered and nothing moves — the count simply continues, and the window travels with the data through every save, export and copy.
Only rooms may be booked out there, and that is on purpose
A booking that names one or more rooms and nothing else can sit outside weeks 1–52. A lecture cannot, and neither can a booking that also names a lecturer, a group or a subject.
A room is the one thing that survives a transition unchanged — the same hall, the same name, the same internal number. Groups are re-formed every September, subjects are re-entered, and the transition gives all of them new internal numbers. A booking made two years out against a group would arrive attached to whichever group inherited that number, which is worse than not having been allowed to make it.
The web booking module enforces the same rule and says so on the form as soon as the dates leave the year, so nobody fills in a long recurrence only to be refused at the end of it.
When the year turns, the booking moves with it
That conference was entered against this year's numbering, somewhere above week 52. Next September the same date is an ordinary week of the new year — so when the new year's document is loaded, the window slides one year to the right and every kept booking moves 52 weeks down with it. Week 53 becomes week 1, and the conference in week 92 becomes week 40: the same hall, the same three days in June, now an ordinary part of the timetable everyone is about to generate around.
Bookings that would land in the past, or beyond the new window, are dropped — and the screen reports both numbers, how many were carried and how many were not, rather than leaving you to find out in March. The ones that were dropped are still in the backup written before the step began.
It is worth being plain about where these are looked up: the desktop application works in the current 52 weeks, as it always has, and that is where the long-lead booking is made. Reading one back two years out is done on the web timetable, which pages through the full range. The mobile apps show the current year, which is what a student needs.
Download the manual
- Year transition (PDF, 5 pages)The screen box by box, the sequence in full, perpetuum bookings with a worked example of the week numbering, and what to do when something stops halfway. Free, and no form to fill in.
- Room bookingWho may book which rooms, and the approval queue that sits in front of it — including the long-lead bookings this page is about.
Related capabilities
See Wise Timetable on your own data
Book a 45-minute online presentation. We will walk through your institution's scheduling problem, show how Wise Timetable handles it, and answer anything your team wants to test.