Modification de 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 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 : '''

[http://www.capmonetique.com/cws]

 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 : 

# Monecarte
# DR11
# 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

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

</pre>