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 codeUnite. 
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.

* 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 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 . 
* 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 de liste de badge chez les gardiens

Il arrive que les gardiens n'aient pas la liste complète des badges dans leur interface.

Un script tourne tous les matins pour venir renseigner le statut des cartes dans la base de donnée qui est interrogée par les gardiens.

Ce script fait appel au webservice d'unicampus. Pour des raisons inconnues à ce jour, l'import de l'information peut mal se faire. Il faut donc relancer le script.

Pour cela :

* se connecter sur webserv2 en root
* vérifier le log :  cat /etc/scripts/cartecms/log_yyyymmdd | grep Visiteur:statut
* si la majorité des statuts ne sont pas à 2, il faut relancer le script
* au préalable, on peut sauvegarder le fichier du jour pour contrôle
* script à relancer : /etc/script/scriptCms.sh

possesseur carte cms, fin de contrat différent

     un possesseur de cms dont la date de fin de contrat dans aeos et reseda est différente

Reponse Julien (06/2018) :

Normalement, Nelly maitrise la DB. Est ce qu’elle a regarder le minimum ? 
 * Entree correcte dans la vue cms par rapport a sa base source réséda
 * Presence unité à 1
 * Autorise export des données à 1
 * Pas de fiche en double (peut arriver en cas d’entrée / sortie


Ensuite il faut improviser en fonction des résultats. 

Si OK dans base RESEDA et KO dans la vue CMS -> Nelly doit voir pourquoi son script ne copie pas la fiche correctement
Si OK dans les 2, vous pouvez effectivement ouvrir un ticket chez Monecarte, ils maîtrisent leurs scripts d’export / import.