Système de Gestion des Cartes

Divers

Administration local des cartes visiteurs

https://duo.dr13.cnrs.fr/cartecms/index

Les PC d’édition doivent être sur le réseau src-cab-gestion

Nouvelle unité Reseda

Lorsqu'une nouvelle unité Reseda est créée, le script quotidien Reseda va la créer dans la table reseda.unites, reseda.implantations_unites 
et la table unites_fixes. 
Il faut renseigner le champ site dans la table reseda.implantations_unites (mettre l'id du site qui se trouve dans la table campus.site), 
vérifier que le champ uniteFixe contient bien le même id que le champ idResedaUnite. 
Et dans la table reseda.unites_fixes mettre le codeSite de la table campus.site dans le champ siteUnite

Ajout unité spécifique

Il se peut que le STL demande de rajouter un sigle unité, souvent parce qu'une nouvelle société doit entrer sur le campus. Et on veut leur donner un badge.

* Faire préciser pour quel campus si ce n'est pas fait.
* Aller sur la base de données reseda sur le serveur MySQL de la délégation, actuellement IP 10.13.102.9
* Sur la table unites_fixes, rechercher les unités dont l'idResedaUnite commence par 999999% 
  (on doit avoir la liste des unités fictives que l'on a créé pour la gestion des cartes)
* SELECT * FROM `unites_fixes` WHERE `idResedaUnite` LIKE '999999%'
* Rajouter l'unité en décrémentant de 1 l'idResedaUnite du plus petit. 
* Champ à renseigner : idResedaUnite, codeUnite (pas d'espace), intituleUnite, sigleUnite, siteUnite (ADV/RDM/BAILLARGUET)
  delegationRegionale_code = 13, date_insert = date du jour

Changement de code unité

Lors d'une re-codification d'un code unité, on peut faire un traitement en masse pour que les cartes d'accès restent valides. Pour cela, il faut vérifier dans la base de données Reseda sur le serveur NewMysql que les champs sigleUnite et sigleUnite de la unites_fixes sont bien renseignés.

* lancer la commande requête sql sur le serveur sécurité (via phpmyadmin), là où se trouve la table personnel qui contient les cartes, cela mettra à jour les informations de la carte actives.
  UPDATE `personnel` p1
  JOIN `personnel` p2 ON p1.`idResedaPersonne`= p2.`idResedaPersonne`
  SET p1.`etatPersonnel`=p2.`etatPersonnel`, p1.`presenceUnite`= p2.`presenceUnite`, p1.`codeUnite`=p2.`codeUnite`, p1.`fonction_libelle`=p2.`fonction_libelle`, p1.`fonction_code`=p2.`fonction_code`, p1.`dateFinImplantation`=p2.`dateFinImplantation` 
  WHERE p1.`codeUnite`='UPS3035' AND p2.`codeUnite`='UAR3035' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL

 p1.`codeUnite`='AncienCode'
 p2.`codeUnite`='NouveauCode'

* Il faut ensuite supprimer les doublons par la requête : 
 DELETE t1 
 FROM `personnel` AS t1, `personnel` AS t2
 WHERE t1.id > t2.id
 AND t1.`idResedaPersonne` = t2.`idResedaPersonne`
 AND t1.`codeUnite` = t2.`codeUnite`
 AND t1.`codeUnite` = 'UAR3035'
 AND t1.`categorie_code` != 'CARTE_V'

 t1.`codeUnite`='NouveauCode'
 la requête supprime le doublon qui a l'id le plus élévé.

* Si l'unité a des cartes de catégorie CARTE_V, il faut lancer la requête suivante :
 UPDATE `personnel` SET `codeUnite`='UAR3725' WHERE `codeUnite`='UMS3725' AND `categorie_code`= 'CARTE_V'

 UAR3725 -> nouveau Code
 UMR3725 -> ancien code

Changement de site pour une unité

Lorsqu'une unité change de site (typiquement unité Balard), il faut changer l'affectation de site dans la base de données Reseda (serveur Mysql)

* dans la table Reseda implantations_unites, changer le champ site par l'id du site qui se trouve dans la 
  table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité.
* dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM .

Contacts

HOTLINE : 02.47.92.90.32

et demander l’ouverture d’un incident « Monécarte ».

Gestionnaire de tickets :

[1]

Log : 34032
Mot de passe : XY1JO3

Technicien SAV, passer par les tickets, uniquement en cas de problèmes :

Clément Wigy
Technicien Support 
4 avenue Jean Monnet - 37160 Descartes
Tel: +33 (0)2 47 92 90 32 
 
clement.wigy@capmonetique.com - www.capmonetique.com

Installateur : CAP MONETIQUE

Technicien : 
Sébastien Arnault
Chargé de projet
4 avenue Jean Monnet - 37160 Descartes
Tel: +33 (0)2 47 91 85 87 - Mob : +33 6 (0)11 29 97 68
sebastien.arnault@capmonetique.com - www.capmonetique.com

Commercial :
Sylvain Févrilliez
Responsable secteur Grand Est – Enseignement Supérieur
4 avenue Jean Monnet - 37160 Descartes
Tel: (+33) 2 47 91 47 50 - Mob : (+33) 6 99 06 48 43
sylvain.fevrilliez@capmonetique.com - www.capmonetique.com

Consommables :

A utiliser de préférence :

Sylvie Méreau <sylvie.mereau@capmonetique.com>

Ruban Primacy YMCKO, 5 panneaux. Kit de nettoyage Primacy

Urgence rubans livré le lendemain mais il vaut mieux passer par monecarte si pas urgent :

http://www.cardalis.fr/evolis-primacy-simplex-et-primacy-duplex/1561-ruban-evolis-primacy-couleur-ymcko-300-cartes.html 

Protèges cartes :

http://www.cardalis.fr/porte-badges-souples/1444-porte-badge-souple-transparent-bandeau-transp-double-perforation.html

CROUS :

Emmanuelle Ricard
Chargée de mission inter-universitaire-Crous 
Carte étudiant électronique Languedoc-Roussillon
Crous de Montpellier
2 rue Monteil CS 85053 34 093 Montpellier cedex 5
04 67 41 50 66 / 06 78 44 19 05

CNOUS (gestion des numéros IZLY):

Sylvain Cammas
Responsable du département Monétique
Cnous
15, rue Guillaume VII le Troubadour – 86022 Poitiers
05 49 60 88 05 / 06 80 90 62 32

IZLY

• Nous gérons la numérotation nationale des numéros de carte IZLY : voir SSI/CMS/CNOUS
• Nous avons 3 SAM CNOUS
• Le fichier de lecture de la SAM est aussi dans SSI/CMS/CNOUS

Nous ne faisons qu’envoyer les nom prénom et numéro de carte au CNOUS, les indices sont ensuite synchronisés par le SSI de la DR11.

En cas de soucis, voir dans cet ordre :

1. Monecarte
2. DR11
3. CNOUS

Connecteurs

Import RESEDA vers base carteCMS

sur secu-CAB-DB (10.13.102.8) :

00 6 * * 0-6 /etc/scripts/scriptResedaCarte.sh >> /etc/scripts/logCarte

20 13 * * 1-5 /etc/scripts/scriptResedaCarte.sh >> /etc/scripts/logCarteMidi

le script se décompose en deux partie:

 importReseda2Carte.php
 Permet de copier les infos utiles de la base de données Reseda qui se trouve sur le serveur 10.13.102.9 et va importer les données dans la table carteCMS.Personnel du serveur secu-CAB-DB.

fonctionLadap2Carte.php
Permet de renseigner la fonction adminlabo depuis l'annuaire ldap vers la base carteCMS.Personnel 

Le SGC utilise la base carteCMS comme sources de données

Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut.

Import application cartes

https://duo.dr13.cnrs.fr/cartecms/index

L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag

provenanceDonneesIndividuelles = LOCAL

Export vers le contrôle d'accès

Il y à 3 connecteurs d'exports vers le controle d'accès :

C:\Program Files (x86)\Monecarte\ConnecteurAEOSP\AEOSProcess.exe

Connecteur d'export des personnels (permanents / non premanents / retraités)

Il est lancé automatiquement toutes les 30 minutes

C:\Program Files (x86)\Monecarte\ConnecteurAEOSV\AEOSProcess.exe

Connecteur d'export des visiteurs

Il est lancé automatiquement toutes les 30 minutes

C:\Program Files (x86)\Monecarte\ConnecteurAEOS_Cartes_Visteurs\AEOSProcess.exe

Connecteur d'export des carte visiteurs sans nom.

Il faut le lancer manuellement.

Les logs des connecteurs sont dans E:\Logs

Pour les 3 connecteurs, ils vont aller vérifier sir il faut exporter les carte dans la table AEOS. Si le flag export est a 0, le script va pousser la carte et rebasculer le flag à 1.

Les connecteurs insèrent ensuite les données sur le serveur AEOS dans la table import. Il faut vérifier le champ status en cas de soucis, il doit être à OK. SI pas OK, voir le champ errorcode. Attention, il n'y a pas de contrôle automatique !

Erreurs connues :

• -1 : ne doit plus se produire, erreur de longueur de champ dans la base ou problème d'ecriture. Voir le champs status pour plus de détail (c'est assez explicite)
• 33 : mise en opposition d'une carte pas encore insérée dans le système : RAS ne pas en tenir compte

Export vers la base de données carteCMS

C:\Program Files (x86)\Monecarte\ConnecteurDatabaseProcess\DatabaseProcess.exe

Lancé automatiquement 2 fois par jour.

Permet de récupérer les infos de numéro Nedap + numéro de carte + Id de la base CMS et de les ajouter a notre base de données (10.13.102.8)

Mise à jour depuis la base carteCMS

C:\Program Files (x86)\Monecarte\SynchroPersonProcess\SynchroPersonProcess.exe

Lancé automatiquement 2 fois par jours

Le script va aller verifier si la base carteCMS a été mise a jour. En cas de MAJ, elles sont répercutées vers le SGC puis vers AEOS avec les scripts précédents.

Les carte visiteurs et les retraités ne sont pas mis a jour car nous n'avons pas d'infos sur leur départ.

Export CNOUS

C:\Program Files (x86)\Monecarte\Connecteur CNOUS\CnousProcess.exe

Pas encore en service !

Opposition CNOUS

C:\Program Files (x86)\Monecarte\CnousOppositionProcess\CnousOppositionProcess.exe

Pas encore en service !

Résolution problèmes

Problème d'accès à HNO

Pour avoir accès à l'interface HNO sur DUO, il faut avoir une carteCMS valide.

Il se peut qu'une personne possède deux entrées dans la base de données Reseda dont une à une date de suppression logique (suite à du nettoyage DSI).

Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB. En général l'entrée qui renseigne le numéro de la carte correspond à l'idReseda de l'enregistrement possédant la date de suppression.

Avant d'engager toute modification, vérifier que la personne est toujours dans l'unité à laquelle correspond la carteCMS. Pour cela :

• Aller sur la base de données Reseda sur NewMySql (si possible par un phpmyadmin)
• Vérifier les deux entrées dans la table personnes (repérer l'idReseda valide et celui qui possède la date de suppression logique)
• vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations
• repérer l'unité, l'idReseda de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1