Documentation

Section : Gestion scolaire / GPI

Mise à jour 8.0.146.9

Modifications

Dernier changement: lun, 09/30/2013 - 13:48
Par Équipe GPI | Produit GPI | Audience(s)

Dossier

Exporter les élèves vers JADE      *** modification importante ***

À partir de la version 8.0.39.2751 de GPI, seules les matières-élève dont la donnée « Matière officielle » est complétée à la table des matières, seront inscrites dans le fichier de transactions lors de l’extraction vers JADE.Vous devez vérifier l’ensemble des matières afin de blanchir la donnée « Matière officielle » pour les matières dont l’exportation vers JADE n’est pas souhaitée (exemple : les matières COM001 à COM005). Il faudra s’assurer également que le code officiel soit complété pour chaque matière à exporter dans JADE.

IMPORTANT :Au prochain transfert des matières de GPI vers JADE, les matières dont la donnée « Matière officielle »  est absente dans GPI seront détruites du dossier des élèves dans JADE.Il faut donc s’assurer que pour les matières transmissibles (secondaires 4 et 5) la donnée soit bien complétée.Rapport Dossiers des élèves

Lorsque le type de liste à imprimer est « Dossiers », il est maintenant possible de spécifier le(s) année(s) des dossiers annuels et/ou des matières à imprimer lors de l'impression.Au lieu de choisir entre « Dossiers annuels de l'année traitée » ou « Dossiers annuels de toutes les années », il est possible de spécifier les années directement en inscrivant une année par ligne (exemple : 2012,2013...). Si aucune année n'est saisie, l'année de la session sera utilisée. 

Fichier sentinelle

Lors de l’accès à GPI, l’application vérifiait le droit d'écriture dans le répertoire du lien sentinelle. La vérification consistait à créer un fichier temporaire dans le(s) répertoire(s) des sentinelles. Ce fichier était nommé « TEST.TST ».  Si le fichier existait déjà et qu'on avait les droits d'écriture, le test échouait et la sentinelle était désactivée.

Désormais, la vérification du droit d’écriture consiste toujours à créer un fichier temporaire, mais le nom du fichier est construit de la façon suivante: TSTXXXX.tmp où XXXX est un nombre hexadécimal aléatoire. Si le fichier existe déjà, ce nombre est incrémenté afin d’assurer l’unicité du fichier.

Ainsi, le message « Sentinelle désactivée » ne surviendra plus lors de l'accès simultané de plusieurs personnes à GPI.

 

Effets scolaires

 

Suivi des soldes par poste budgétaire

Afin de préparer la mise en place du lien entre GPI et Dofin, la ligne de trop-perçu a été retirée de l'activité « Suivi des soldes par poste budgétaire » pour être remplacée par la sous-activité simplifiée « Trop-perçus par année ». Dans cette sous-activité, les trop-perçus sont présentés pour chacune des années de travail de l'école. Deux colonnes totaux sont affichées: Crédits accordés par l'école (les trop-perçus provenant du mode de paiement  'T') et Encaissements (tous les autres types de trop-perçus).

Pour bien démarrer cette nouvelle sous-activité, vous devrez effectuer une conversion des données déjà saisies dans GPI afin de retirer les trop-perçus se trouvant sur les factures et les transférer dans le poste de trop-perçu global.

A noter que les factures de dépôt de sécurité (poste budgétaire DS) ne sont pas touchées par cette conversion.  Tous les trop-perçus engendrés par une remise ou annulation d'un dépôt de sécurité demeurent toujours rattaché au poste budgétaire DS.

IMPORTANT :Cette conversion se fait par une requête SQL qui se trouve sur le babillard GPI dans la section supplément/requêtes.

 AVANT LA CONVERSION

•    La banque de données doit avoir été mise à niveau à la version 8.0.39.

•    Nous recommandons de faire une prise de copie de la base de données.

•    Nous conseillons d'imprimer le suivi des soldes par postes budgétaires pour chaque école. 

EXÉCUTION DE LA CONVERSION

•    Le script doit être exécuté directement dans Microsoft SQL Server Management Studio.

•    Le script peut être exécuté plus d'une fois. Donc, en cas d'interruption du traitement (panne ou autre), il peut être ré-exécuté sans problème.

•    Durant l'exécution, il est important que personne n'utilise l'application GPI.

•    La conversion peut prendre quelques heures. Le délai n'est aucunement lié à la grosseur de la base de données, mais plutôt au nombre de factures négatives.  Un autre facteur pouvant influencer la durée de la conversion est la mémoire maximale permise du serveur SQL. Vous pouvez augmenter temporairement l'allocation de mémoire sur le serveur SQL durant l'exécution de la conversion. Nous conseillons d’exécuter la conversion sur une copie de la banque GPI afin d’obtenir la durée de l’exécution de la requête.

APRÈS LA CONVERSION

•    Lorsque le script est complété, une liste de données non converties peut s’afficher dans la fenêtre Résultats. Ces rares cas sont, pour la plupart, des erreurs d’intégrité de données. Il est important de conserver ce résultat afin d’apporter les corrections nécessaires.

•    La majorité des cas peut être corrigée en faisant une mise à jour de l'effet ciblé au dossier de l'élève. Dans ce cas, le système GPI s'occupe de reporter lui-même le montant en trop-perçu de la facture vers le trop-perçu global au dossier de l'élève.

•    Ces situations ne sont pas catastrophiques et n'empêchent en aucun cas les utilisateurs de GPI de se servir de l'application.

Voici les impacts possibles résultant de ces situations :

•    Si un montant est en trop-perçu sur la facture (facture négative), ce montant ne peut être remboursé à l'emprunteur.Par contre, il peut être utilisé pour payer de nouvelles factures et peut être reporté en tant que trop-perçu à l'année suivante.

•    Au niveau du suivi des soldes, le trop-perçu rattaché à un poste de revenu (facture négative) n'est pas comptabilisé dans la nouvelle activité « Trop-perçu par année ».

•    Toujours au niveau du suivi des soldes, il est possible de retrouver avec un poste de revenu négatif dans l'écran principal.

•    Si un remboursement d'encaissement est touché par l'une des situations non converties, la ventilation d'un remboursement peut être erronée selon les transactions à l'historique. 

Suivi des soldes - Retirer la notion de trop-perçu des postes de revenu

Dans le cadre des travaux visant à corriger le Suivi des soldes, il n'est plus possible d'avoir du trop-perçu rattaché à un poste de revenu (factures négatives). Le système a donc été ajusté de façon à ce que si une facture se retrouve avec un solde négatif, l'excédent des paiements sera automatiquement transféré dans le trop-perçu de l'année de la facture d'où le montant est prélevé.

Saisir les paiements - Rembourser uniquement s'il y a un trop-perçu

GPI permettait de rembourser tout ce qui avait été encaissé sur le dossier d'un élève et ce, même s'il restait des effets à payer au dossier. Dorénavant, seul le trop-perçu pourra être remboursé. Ainsi, si on doit rembourser un élève, l'utilisateur devra avant d'effectuer le remboursement, générer du trop-perçu au dossier de l'élève en diminuant ou en annulant le coût d'un effet.

Dépôts bancaires - Ajouter les numéros de chèque sur le bordereau de dépôt

La donnée Numéro de chèque est maintenant disponible à la section Paiements (détail) du format d'impression du bordereau de dépôt. Cette donnée n'étant pas affichée sur les formats d'impression GRICS, il faudra créer un nouveau format afin d’y ajouter l’information. La donnée Numéro de chèque est également disponible dans la sous-activité Liste des paiements de l'activité Dépôts bancaires. 

Saisir les paiements - Retrait des données Maximum remboursable/Maximum utilisable

Dans la sous-activité Répartition du paiement, la colonne Maximum remboursable/utilisable a été retirée car elle n'était pas utile aux usagers et amenait de la confusion. 

État de compte – Ajout d’une section Identification du payeur

La nouvelle section Identification du payeur a été ajoutée sous la section En-tête - État de compte dans le format de l'état de compte afin de faciliter la lecture du numéro de référence internet des payeurs. Cette section est répétitive horizontalement et permet d’afficher les payeurs associés à l'adresse de l'état de compte.Pour un type d'adresse Père/mère la section imprimera les informations du père à gauche, puis les informations de la mère à droite.Les données disponibles sont les suivantes:•    Numéro de l'école

•    Fiche

•    Numéro du payeur

•    Numéro de référence internet

•    Type de payeur

Pour afficher ces informations, il faudra adapter les formats d'impression. Il est important que la largeur de la section Identification du payeur ne dépasse pas la moitié de celle du rapport. Les sections répétitives s'impriment côte à côte et peuvent créer un débordement si la largeur est trop grande. La section peut être répétée un maximum de 2 fois dans le cas d'une adresse père/mère 

Répartition du paiement - Empêcher les changements de répartition sur un remboursement

Pour l'instant, pour ne pas faire d’incohérence à la banque, nous ne permettrons plus d'effectuer des changements de répartitions lorsqu'il s'agit d'un remboursement.

Bordereau de Dépôt - Imprimer le logo et le nom de l'école dans l'en-tête du bordereau de dépôt

Toutes les données concernant l'école peuvent maintenant être imprimées dans l'en-tête de la liste:

•    Code de l'école

•    Nom de l'école

•    Sigle de l'école (nom du fichier)

•    Sigle de l'école (image)

A noter que le format GRICS n'a pas été ajusté et qu'il imprime actuellement uniquement le code et le nom de l'école.

 

Saisir les paiements – Remboursement admissible

Une nouvelle donnée Montant de la session de travail admissible au remboursement a été ajoutée à l'activité Saisir les paiements afin de connaître le montant admissible aux remboursements pour la session de travail. Cette donnée calcule la somme des trop-perçus ainsi que les dépôts de sécurité dont la location a été retournée ou annulée dans l'année de la session de travail seulement La donnée existante « Total du remboursement admissible » a été renommée pour « Montant global admissible au remboursement »

 

Horaire

 

Rafraîchir les statistiques   *** ATTENTION! ***

Changement important demandant une validation des données GDE de la table Cours

Que vous utilisiez les données GDE ou non, le facteur de pondération des élèves est maintenant obtenu en divisant le « Nombre maximum d’élèves par groupe (GDE) » par le « Nombre maximum d’élèves » du code de difficulté.

Avant cette version, c’était le nombre de sièges maximum qui était utilisé. Le nouveau calcul permet la modification du nombre de sièges maximum sans affecter le calcul de la pondération des élèves. Lors de la transmission des dépassements vers la Paie, c’est depuis longtemps le « Nombre maximum d’élèves par groupe (GDE) » qui est utilisé. Par les modifications incluses dans cette mise à jour, nous rendons conforme l’affichage des données dans GPI avec celles transmises vers le système de Paie.

Les activités et impressions suivantes utilisent maintenant la valeur « Nombre pondéré d'élèves inscrits » calculée avec « Nombre maximum d'élèves par groupe (GDE) »:

•    Horaire maître - Planifier le nombre de groupes - Cours du champ d’enseignement

•    Horaire maître (cours et patron) - Affichage de la moyenne d’élèves inscrits par cours

•    Horaire maître (cours et patron) - Afficher le portrait des inscriptions - Portrait des cours

•    Horaire maître - Imprimer… - Planification des groupes

•    Tables - Imprimer… - Maquette de cours...

•    Tables - Cours - Modules de l'atelier

La donnée « Nombre maximum d'élèves par groupe (GDE) » est maintenant disponible dans la sous-activité « Planifier le nombre de groupe - Cours du champ d'enseignement » ainsi que dans l’activité « Portrait des inscriptions – Portrait des cours ».

 

Évaluation

 

Rapport « Résultats par élève »

Rapport « Résultats par élève - par étape et par objectif » La donnée « Catégorie de la matière-élève »  a été ajoutée à la section « Matière de l'élève »Cette donnée n’a pas été ajoutée aux formats GRICS.