Y-vakken die uit deze query komen zijn gepland in een interface periode (eindigend op 2, bijv 2202) en hebben geen deelvakken in de samenstelling. Dit is NIET problematisch voor het aanmaken van de course offering zelf. Dit is WEL problematisch voor het aanmaken van werkgroep-course offerings, inschrijvingen daarop en de inschrijvingen op de moeder-course offering. Zolang er geen samenstelling wordt aangebracht zullen deze 3 zaken NOG niet functioneren in de koppeling. Het alsnog maken van een samenstelling triggert berichten in uSIS waardoor de werking van de koppeling uit zichzelf moet herstellen.

Als men per ongeluk deelvakken heeft geroosterd in de 2202 periode, dan zullen die ook uit deze query komen. Deelvakken hebben namelijk nooit een samenstelling (alleen Y-vakken hebben een samenstelling). Als dit het geval is komen deze deelvakken waarschijnlijk ook uit de INTF0005 query. Oplossing is om het geroosterde activiteit voor het deelvak in de 2202 periode te verwijderen. Mogelijk heeft men zich hier vergist en was het de bedoeling om werkgroep-course offerings voor een deelvak te maken. Hoe je dit op de juiste manier kunt doen is hier te lezen.

Deze query laat zien voor welke, in een interface periode (eindigend op 2, bij 2202) geplande, Y-vakken er activiteiten zijn die in een andere sessie (semester/onderwijsperide) zijn gepland. Het Y-vak is bijvoorbeeld in S1 gepland, terwijl er (ook) activiteiten zijn die in S2 zijn gepland. De koppeling herkent deze S2 activiteiten dan niet als onderdeel van de course offering. Deze logica is van toepassing op het versturen van zowel een cursusbericht als een cursusinschrijvingsbericht.

Bij een cursusbericht worden die activiteiten in S2 niet meegenomen in het bericht. Eventuele groepsindelingen daarin worden dus niet meegenomen en resulteren niet tot werkgroep-course offerings.

Bij een cursusinschrijvingsbericht worden inschrijvingen op die S2 activiteiten niet meegenomen.

Wanneer is dit een probleem?
-Als gewenst is dat groepsindelingen uit de afwijkende periode tot werkgroep-course offerings moet leiden
-Als studenten UITSLUITEND een inschrijving op een activiteit in de afwijkende periode heeft zal de student niet op de moeder-course offering enrolled worden in Brightspace.
-Als studenten een inschrijving op een werkgroep hebben die in de afwijkende periode is gepland zal de student NIET enrolled worden op de werkgroep-courseoffering in Brightspace (die ook al niet aangemaakt wordt, zie 1e bullet).

Wanneer is dit GEEN probleem?
-Als er geen groepsindelingen (en dus de inschrijvingen daarop ook niet) uit die afwijkende periode naar Brightspace hoeven voor dit vak.
-Als de student naast de inschrijving op de activiteit in de afwijkende periode OOK nog op zijn minst 1 inschrijving heeft op een activiteit die wel in de periode is gepland waarin het Y vak ook is gepland. In dat geval wordt de student gewoon enrolled op de moeder-course offering in Brightspace. Dus in het voorbeeld: als student een S1 activiteit heeft EN een S2 activiteit zal de student gewoon enrolled worden op de moeder-course in S1.
-Als een vak in meerdere sessies is ingeroosterd.

Uitkomst van deze query zijn vakken die zijn ingeroosterd in een interface periode (eindigend op 2, bijv 2202) terwijl het vinkje 'Studiedeel naar LMS' bij het geroosterde Y-vak niet is aangevinkt. Consequentie hiervan is dat er geen moeder-course offering en werkgroep-course offering wordt aangemaakt. De inschrijvingen gaan als gevolg daarvan ook mis.

Dit kan opgelost te worden door bij de geroosterde activiteiten van het Y-vak in de interface periode het vinkje Studiedeel naar LMS aan te zetten op het tabblad LMS-gegevens. De cursus en eventuele reeds gedane inschrijvingen worden op dat moment alsnog verstuurd naar Brightspace.

Is het vinkje uitgezet omdat voor dit vak de koppeling niet (meer) nodig is? Dan volstaat het niet om alleen het vinkje uit te zetten. Verwijder in dat geval de gehele activiteit voor het Y-vak in de interface periode (2xx2). Na dit te verwijderen kan in Brightspace de (niet meer nodige) course offerings verwijderd worden. Dien hiervoor een aanvraag in bij Functioneel Beheer LMS SOZ.

Deze query is het omgekeerde van query INTF3 en toont juist Y-vakken waarbij het vinkje Studiedeel naar LMS aangevinkt is, maar het Y-vak zelf niet in een interface periode (eindigend op een 2, bijv 2202) is geroosterd. Oorzaak kan zijn dat per ongeluk een verkeerde periode is gekozen (bijv 2201 ipv 2202). Dit kan opgelost worden door het Y-vak alsnog in de juiste periode te roosteren. De cursus wordt op dat moment alsnog verstuurd naar Brightspace. Verwijder als laatste ook nog de activiteit in de verkeerder interface periode (bijv 2201). Op deze manier komt het vak de volgende keer niet naar boven in deze controle.

Het kan ook zijn dat er deelvakken uit deze query komen. Dat is het geval als het vinkje 'studiedeel naar lms' is aangezet bij een deelvak. Dit is echter niet de bedoeling en moet bij het Y-vak gedaan worden. De oplossing is in dit geval om het vinkje 'Studiedeel naar LMS' uit te zetten bij het betreffende deelvak.

Deze query laat activiteiten zijn van NIET-Y vakken die ingeroosterd zijn in een interface periode (eindigend op een 2, bijv 2202) EN/OF waarbij het vinkje Studiedeel naar LMS is aangevinkt. Dit zijn invoerfouten en dienen opgelost te worden. Het kan zijn dat er verkeerde informatie naar Brightspace is verstuurd en er dus bijvoorbeeld course offerings voor verkeerde activiteiten worden aangemaakt. Zodra dit voorkomt is het raadzaam om contact op te nemen met de LMS coordinator om te beoordelen of er iets verwijderd moet worden in Brightspace.

Zo kan het bijvoorbeeld zijn dat iets anders dan een Y-vak is ingeroosterd in de interface periode. Denk aan een deelvak (bijvoorbeeld een W- of H- vak). Als dit het geval is zal dit vak ook verschijnen in de output van query INTF0001 (aangezien een deelvak geen samenstelling heeft). Door het 1 keer op te lossen verdwijnt deze fout uit beide queries.

Ook kan het zo zijn dat bij het Y-vak het veld onderdeel niet de waarde 'Zelfstandig studiedeel' bevat. Als dat zo is komt de cursus ook uit deze query. Dit moet dan gecorrigeerd worden.

Het probleem waar deze query op controleert zijn deelvakken (bijvoorbeeld, W- H- of T- vakken) die aan meerdere Y-vakken zijn gekoppeld in de samenstelling. Als een deelvak uit deze query komt dan is het zo dat 2 of meer van deze Y-vakken, waaraan het deelvak is gekoppeld, zijn ingeroosterd in de interface periode. Dit zorgt er voor dat niet alle inschrijvingen goed over komen. De koppeling kan dan immers niet weten voor welk Y-vak de student ingeschreven moet worden in Brightspace. Het oplossen van dit probleem kan gedaan worden door Y-vakken uit te roosteren uit de interface periode of de samenstelling aan te passen en gebruik te maken van een bundel. 

Dit probleem trad eerder op bij het inrichten van een workaround om meerdere uSIS vakken samen als 1 vak in Brightspace te krijgen.Deze workaround is niet langer nodig en niet langer mogelijk sinds gebruik gemaakt kan worden van de bundel functionaliteit in uSis.

Voorbeeld:

• 1234W is gekoppeld aan 1234Y en aan 2345Y en aan 3456Y
• 1234Y en 2345Y en 3456Y moeten allen ingeroosterd worden in de interface periode (bijv. 2202)

Oplossing:

• Haal 1234W uit de samenstelling van 2345Y en 3456Y
• Richt vervolgens een bundel in met de vakken 1234Y, 2345Y en 3456Y voordat het vinkje “Studiedeel naar LMS” wordt aangezet bij de betreffende Y-vakken
• Zet ná inrichting van de bundel de vakken door naar de afnemende systemen m.b.v. het vinkje “Studiedeel naar LMS”

Met behulp van deze query wordt gemonitord hoeveel error 400 messages optreden om ongewoon gedrag van berichten tussen uSis en Brightspace te signaleren.

Deze controle query is uitsluitend in gebruik bij FB-SOZ.

Deze query geeft ingeroosterde vakken weer waarbij in de tabel “Docenten voor rooster bijeenkomsten” op het tab “Bijeenkomsten” in menu “Studierooster beheren” ID’s zijn ingevuld die niet met een G (Gast) of een M (Medewerker) beginnen.

De gebruikte waarde kan bijv. een incorrecte waarde of een studentnummer zijn.

Het advies aan faculteiten is om de output van deze query te controleren en incorrect gekoppelde docenten te corrigeren.

Y-vakken die uit deze query komen zijn helemaal goed ingericht in uSIS. De koppeling werkt voor deze vakken dan ook optimaal. Verder laat deze query per Y-vak zien hoeveel inschrijvingen er op dat Y-vak zijn. Dit is een optelling van alle studenten die op zijn minst voor 1 van de onderliggende activiteiten is ingeschreven in uSIS. Dus als er 5 studenten op een W vak zijn ingeschreven en die 5 plus nog 2 andere studenten op het H vak, dan laat deze query zien dat er 7 studenten zijn ingeschreven op dit Y-vak.

Deze query is bijna gelijk aan query INTF6, alleen bij deze query zijn de aantallen inschrijvingen uitgesplitst naar de onderliggende deelvakken. Dus in hetzelfde voorbeeld als bij query INTF6: de query toont dan dat er 5 studenten op het W vak zijn ingeschreven en dat er 7 studenten op het H vak zijn ingeschreven.