Multiple active timetables in parallel

At the standard tier, a single timetable can be published at a time over a given period. This is enough for the typical operation of a middle or high school. In some contexts — typically higher education, modular programs, schools with multiple tracks — the need arises to publish several timetables in parallel that complement each other. This capability is included by default with Premium accounts.

In some mixed school accounts, for example middle-high school or primary-middle-high school with several genuinely separate timetables, Omniscol can enable this capability specifically. Scoping and billing are then adapted to the actual need.

Why several timetables in parallel

A few typical scenarios:

  • Common core + specializations — a weekly timetable covers the common core (subjects shared by all cohorts), timetables per specialization or per track are added on top with their own constraints.
  • Regular + one-off calendar — a regular weekly timetable carries most of the courses, a calendar timetable carries the dated lessons (lectures, exams, juries).
  • Multiple sites — one timetable per site with local management, merged at viewing time for students who move from one site to another.
  • Programs of different lengths — for example an 18-month EMBA track, a Grande École cycle running on calendar semesters and a weekly preparatory program, with shared teachers and rooms.

Without this option, these cases force you to merge all the complexity into a single timetable, which quickly becomes unmanageable.

How it works

You create several timetables in the Timetable management module, as usual. At publication time onto the weeks, the allocation screen accepts several timetables on the same weeks rather than just one.

On the consumption side (portals, display panels, iCal, API), the timetables published on a week are merged dynamically: a student sees all the lessons that concern them, regardless of which timetable they come from.

Within the same account, the timetables active in parallel share the occupancy of the resources concerned: rooms, teachers and, in the cases where it is relevant, classes. This prevents the same teacher or the same room from being booked twice by two active timetables. Classes shared across several timetables exist too, but this case remains more marginal and depends heavily on the pedagogical organization.

Cross-timetable conflict detection

Two mechanisms complement each other, depending on where you are working.

While building the timetable

When you build or reorganize a timetable in Timetable management, the Synchronization button (in the toolbar of both the reorganization and the calendar timetable editing views, on shared dates) checks your work against the other published timetables. It automatically takes into account those whose dates overlap those of the current timetable and which share at least one teacher, room or class — locally (same account) as well as with linked accounts. It therefore activates on its own as soon as there are shared resources (orange = active). This automatic coupling links dated (calendar) timetables.

A welcome exception: it ignores a plain copy of the current timetable (same lessons). You can therefore work on a duplicated draft without being put in conflict with yourself.

The occupancy of these timetables then feeds into the conflict engine:

  • the candidate time slots for placement (colored dots) turn orange or red if the teacher or the room is already taken elsewhere;
  • the diagnostic reports double bookings across timetables.

The reported conflict then clearly states that it comes from an external timetable, with its precise reference.

The button's drop-down menu lists the timetables and accounts taken into account: untick those you do not want to monitor, for example to deliberately accept an overlap.

At viewing time (operational timetable)

Once published, the timetables merge into a single operational timetable — the viewing screen in Omniscol (the Timetable module), and everything that consumes the timetable (portals, display panels, iCal, API). Conflicts between timetables can be read there naturally: a teacher (or a room) taken by two simultaneous lessons from two published timetables sees them overlaid on the merged grid. That is the point of the merge: it forms the timetable as actually experienced, all types combined (including a weekly timetable and a calendar timetable). In the reorganization view, this creates a conflict.

In both cases, resolution remains a scheduling action: move, adapt or accept the conflict as appropriate.

How-to

Publishing a regular timetable + a calendar timetable in parallel

  1. The classic hybrid case: a regular weekly timetable for most of the courses, plus a calendar timetable for the dated lessons (guest lectures, exams, juries).

  2. Prerequisite: two timetables created in Timetable management — a weekly one with the regular courses, a calendar one with the dated lessons. Configure them independently. See also Calendar mode.

  3. Run the generation on each timetable separately if you use the solver. First check the conflicts specific to each timetable.

  4. Publish the weekly timetable on the desired weeks (typically: the whole year). See Publication. Then publish the second timetable (calendar) on the same weeks. The allocation screen accepts several timetables in parallel (vs a single one at the standard tier).

  5. Check the merge: open the student or teacher portal — the lessons from both timetables appear on the same grid, merged dynamically. iCal, the API and display panels see the same thing.

  6. Cross-timetable conflicts: between a weekly timetable and a calendar timetable, the overlap shows up mostly on the merged operational timetable (viewing screen, portals) — if a lecture (calendar) lands on the time slot of a regular course (weekly) for the same teacher or the same room, the two lessons overlay each other there. Resolve it like an ordinary conflict: move, adapt or accept.

See also