Wiki_DR13 - Contributions de l’utilisateur [fr]

Système de Gestion des Cartes

2022-10-04T08:53:06Z

193.49.133.28 :

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

=== Résolutions 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'idResedaPersonne 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)
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
* Sur l'enregistrement de la table "personnel" dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
* Supprimer l’enregistrement doublon de la table "personnel" qui ne possède pas de carte.
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.

=== 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 !

Système de Gestion des Cartes

2022-10-04T08:49:56Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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ésolutions 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'idResedaPersonne 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)
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
* Sur l'enregistrement de la table "personnel" dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
* Supprimer l’enregistrement doublon de la table "personnel" qui ne possède pas de carte.
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.

Système de Gestion des Cartes

2022-10-04T08:47:06Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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ésolutions 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'idResedaPersonne 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)
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
* Sur l'enregistrement dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.

Système de Gestion des Cartes

2022-10-04T08:46:29Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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ésolutions 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'idResedaPersonne 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)
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
* Sur l'enregistrement dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.

Système de Gestion des Cartes

2022-10-04T08:46:07Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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ésolutions 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'idResedaPersonne 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)
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
* Sur l'enregistrement dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet carte Personnels, cliquer sur la petite fiche à gauche du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.

Système de Gestion des Cartes

2022-10-04T08:41:38Z

193.49.133.28 : /* Résolution problèmes */

=== 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 : '''

[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ésolutions 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'idResedaPersonne 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)
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
* Sur l'enregistrement dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.

Système de Gestion des Cartes

2022-10-04T08:29:12Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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 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

Système de Gestion des Cartes

2022-10-04T08:23:44Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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 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 dans NewMySql

Système de Gestion des Cartes

2022-10-04T08:22:24Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

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

Système de Gestion des Cartes

2022-10-04T08:21:12Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

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

Système de Gestion des Cartes

2022-10-04T08:19:56Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

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

Système de Gestion des Cartes

2022-10-04T08:17:01Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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 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 Reseda dont une à une date de suppression logique (suppression intervenue après l'obtention de la carteCMS).
Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB.

Système de Gestion des Cartes

2022-10-04T08:13:19Z

193.49.133.28 : /* Problème d'accès à HNO */

=== 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 : '''

[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 d'accès à HNO ====

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

Applications DUO

2022-10-04T08:12:38Z

193.49.133.28 : /* HNO */

__TOC__

== Environnement technique ==

* Développé avec le framework symfony 5
* Les sources sont en production sur le serveur webserv2. La mise à jour se fait à partir d'un dépôt git stocké sur la forge de la DSI https://src.koda.dsi.cnrs.fr/
* Token de déploiement : https://gitlab+deploy-token-19:EyFF2vyEcw7XVs6v2jwB@src.koda.dsi.cnrs.fr/nelly.pernot.2/duo2.git

== Architecture ==

[[Fichier:Architecture.png]]

== Modules ==

=== Administration ===

Permet des données des droits aux différentes applications de DUO.
Pour le moment, on n'affecte pas ce pouvoir aux labos. Il est réservé aux personnes du SSI.

=== Listes de diffusion ===

[[Gestion Listes de diffusion]]

=== HNO ===

Pour avoir accès à ce module, il faut être en possession d'une carteCMS valide.

* Si ce n'est pas le cas, consulter la rubrique Résolution de problèmes de [[Système de Gestion des Cartes]]

Applications DUO

2022-10-04T08:12:20Z

193.49.133.28 : /* HNO */

Applications DUO

2022-10-04T08:12:00Z

193.49.133.28 : /* HNO */

__TOC__

== Environnement technique ==

* Développé avec le framework symfony 5
* Les sources sont en production sur le serveur webserv2. La mise à jour se fait à partir d'un dépôt git stocké sur la forge de la DSI https://src.koda.dsi.cnrs.fr/
* Token de déploiement : https://gitlab+deploy-token-19:EyFF2vyEcw7XVs6v2jwB@src.koda.dsi.cnrs.fr/nelly.pernot.2/duo2.git

== Architecture ==

[[Fichier:Architecture.png]]

== Modules ==

=== Administration ===

Permet des données des droits aux différentes applications de DUO.
Pour le moment, on n'affecte pas ce pouvoir aux labos. Il est réservé aux personnes du SSI.

=== Listes de diffusion ===

[[Gestion Listes de diffusion]]

=== HNO ===

Pour avoir accès à ce module, il faut être en possession d'une carteCMS valide.

* SI ce n'est pas le cas, consulter la rubrique Résolution de problèmes de
[[Système de Gestion des Cartes]]

Applications DUO

2022-10-04T08:11:07Z

193.49.133.28 : /* HNO */

Applications DUO

2022-10-04T08:10:29Z

193.49.133.28 : /* HNO */

Applications DUO

2022-10-04T08:08:53Z

193.49.133.28 : /* Modules */

Système de Gestion des Cartes

2022-10-04T08:06:54Z

193.49.133.28 :

=== 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 : '''

[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 d'accès à HNO ====

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

Affichage Web

2022-10-04T07:59:01Z

193.49.133.28 :

<h2 style="margin:0;background-color:#7cbdff;font-size:120%;font-weight:bold;border:1px solid #659ad0;text-align:left;color:#000;padding:0.2em 0.4em;">[[Image:Internet.png |25px]] Applications - Database Délégation</h2>

[[Flux scripts]]

[[Gestion Listes de diffusion]]

[[Applications DUO]]

[[shibboleth]]

[[WEBDAV]]

[[Image:Osiris.png |25px]][[OSIRIS]]

Affichage Web

2022-10-04T07:58:32Z

193.49.133.28 :

<h2 style="margin:0;background-color:#7cbdff;font-size:120%;font-weight:bold;border:1px solid #659ad0;text-align:left;color:#000;padding:0.2em 0.4em;">[[Image:Internet.png |25px]] Applications - Database Délégation</h2>

[[Flux scripts]]

[[Gestion Listes de diffusion]]

[[Applications DUO]]

[[Parc Auto]] (obsolète)

[[shibboleth]]

[[WEBDAV]]

[[Image:Osiris.png |25px]][[OSIRIS]]

Système de Gestion des Cartes

2022-03-28T07:34:49Z

193.49.133.28 : /* Changement de code unité */

=== 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 : '''

[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>

Système de Gestion des Cartes

2022-02-10T14:02:04Z

193.49.133.28 : /* Changement de code unité */

=== 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'

p1.`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 : '''

[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>

Système de Gestion des Cartes

2022-02-10T14:01:43Z

193.49.133.28 : /* Changement de code unité */

=== 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'

p1.`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 resuê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 : '''

[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>

Système de Gestion des Cartes

2022-02-10T13:59:14Z

193.49.133.28 : /* Changement de code unité */

=== 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'

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

==== 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>

Système de Gestion des Cartes

2022-02-10T13:55:14Z

193.49.133.28 : /* Changement de code unité */

=== 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`='UMS3725' AND p2.`codeUnite`='UAR3725' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL

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

==== 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>

Système de Gestion des Cartes

2022-02-10T13:54:31Z

193.49.133.28 : /* Changement de code unité */

=== 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`='UMS3725' AND p2.`codeUnite`='UAR3725' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL

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

==== 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>

Système de Gestion des Cartes

2022-02-10T13:51:54Z

193.49.133.28 : /* Changement de code unité */

=== 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 traiteement 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é, là où se trouve la table personnel qui contient les cartes :
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`='UMS3725' AND p2.`codeUnite`='UAR3725' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL

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

==== 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>

Système de Gestion des Cartes

2022-02-10T13:50:11Z

193.49.133.28 : /* Changement de code unité */

=== 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'une unité, on peut faire un traiteement 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é, là où se trouve la table personnel qui contient les cartes :
UPDATE `personnelTest` p1
JOIN `personnelTest` 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`='UMS3725' AND p2.`codeUnite`='UAR3725' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL

==== 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>

Système de Gestion des Cartes

2022-02-10T13:43:32Z

193.49.133.28 : /* Divers */

=== 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é ====

==== 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>

Système de Gestion des Cartes

2022-01-19T16:16:19Z

193.49.133.28 : /* Ajout unité spécifique */

=== 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 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>

Config Postes gardiennage ADV et RDM

2021-12-03T15:12:15Z

193.49.133.28 : /* Compte application visiteur Gardiens ADV et RDM */

'''Coordonnées du Responsable Opérationnel pour les rondes groupe ESI :'''

Monsieur David GUERIN

<u>E-mail :</u> david.guerin@esi-groupe.fr

<u>Tél :</u> 04 67 69 25 01

Voir lien pour le plan : [[ Media:bat B accueil plan.png ]]

=Compte Ordinateur PC1 Gardiens ADV et PC2 Hall Genopolys ADV=

Session PC Gardiens ADV et PC Gardien Genopolys

Login: gardien.adv

Mot de passe: .fort

Session Administration:

Login session Administration: SSI

mot de passe session SSI: Ep$!L0N2009

=Configuration IP PCs Gardien ADV=

'''Adressage IP PC1 Guérite Gardiens ADV'''

IP : 193.50.7.89

Masque : 255.255.255.254

Passerelle : 193.50.7.65

DNS : 193.49.132.10

DNS2: 194.57.118.10

'''Adressage IP PC2 ADV Hall Genopolys'''

IP : 193.50.7.73

Masque : 255.255.255.254

Passerelle : 193.50.7.65

DNS : 193.49.132.10

DNS2: 194.57.118.10

=Compte Ordinateur RDM=

'''Session PC Accueil_RDM:'''

Login: accueil

Mot de passe: .fort

'''session PC Gardiens_RDM:'''

Login: gardiens

Mot de passe session gardien: .fort

'''Session Administration:'''

Login: SSI

mot de passe: Rdm314coLons!

=Configuration IP PCs Gardiens RDM=

'''PC Acceuil_RDM '''

IP : 193.50.7.68

Masque : 255.255.255.254

Passerelle : 193.50.7.65

DNS : 193.49.132.10

DNS2: 194.57.118.10

'''PC Gardiens_RDM'''

IP : 193.50.7.88

Masque : 255.255.255.224

Passerelle : 193.50.7.65

DNS : 193.49.132.10

DNS2: 194.57.118.10

=Configuration Messagerie Gardiens ADV et RDM=

'''Messagerie Client Microsoft Outlook PC Gardiens ADV et PC Gardiens ADV Genopolys'''

<u>Messagerie gardiens ADV :</u> DR13.gardiensADV@ods.services

<u>Mot de passe messagerie :</u> Y2bR?9#Sn?b9

'''Messagerie Client Microsoft Outlook PC Accueil et PC Gardiens RDM'''

<u>Messagerie gardiens RDM :</u> DR13.AccueilRDM@ods.services

<u>Mot de passe messagerie :</u> Y2bR?9#Sn?b9

=Compte application visiteur Gardiens ADV et RDM=

Si problème de mot de passe pour les gardiens, voici la procédure pour le réinitialiser.
* Aller dans keepassX pour trouver le login et le mot de passe : Serveurs->SECU-CAB-Db->Compte QRCODE XXX (XXX = ADV ou RDM)
* Dans DUO -> Administration -> Utilisateurs compte extérieur
* Dans la colonne compte, cliquer sur l'icône pour afficher la fiche du compte, puis cliquer sur le bouton "modifier mot de passe"
* Renseigner deux fois le mot de passe

Config Postes gardiennage ADV et RDM

2021-12-03T15:11:27Z

193.49.133.28 : /* Compte application visiteur Gardiens ADV et RDM */

Config Postes gardiennage ADV et RDM

2021-12-03T15:04:24Z

193.49.133.28 : /* Compte application visiteur Gardiens ADV et RDM */

Config Postes gardiennage ADV et RDM

2021-12-03T15:03:46Z

193.49.133.28 : /* Configuration Messagerie Gardiens ADV et RDM */

Config Postes gardiennage ADV et RDM

2021-12-03T15:03:07Z

193.49.133.28 :

Système de Gestion des Cartes

2021-07-08T10:35:36Z

193.49.133.28 : /* Changement de site pour une unité */

=== 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>