SNMP printer counters

Définitions

Un compteur sera un nombre entier associé à un type de compteur.

Les types de compteur seront paramétrables et, à titre d'exemple, pourront être A4-monochrome, A3-monochrome, A4-couleur, A3-couleur, A4-2 couleurs ou A3-2 couleurs, recto-verso, A4-scan, A3-scan, fax'

Un modèle de relevé compteurs sera un ensemble de type de compteurs associé à un Object Identifier (OID) de la MIB (Management Information Base) du protocole SNMP (Simple Network Management Protocol).
Le nombre de compteurs sera variable d'un modèle à l'autre. Ce modèle de relevé compteurs intègrera une liste de mentions de description de l'hôte (Sysdescr) pour soutenir les tests de conformité matérielle.
Il sera associable au périphérique avec la possibilité de modification en masse depuis la liste des périphériques. Un périphérique ne pourra être associé qu'à un seul modèle de relevé compteurs.

Le relevé compteurs reposera sur le modèle de relevé compteurs associé au périphérique. Il sera horodaté.
En plus des valeurs numériques des compteurs par type, s'ajoutera le type de relevé, et l'entité de tutelle, la localisation, le budget de facturation (voir « suivi des enveloppes budgétaires ») à la date du relevé
Le type relevé pourra être manuel (par un opérateur), ou automatique (par le moteur d'interrogation).
A ces deux types de relevé, dit à succès, s'ajoutera les types erreur hôte et erreur relevé.
Ces derniers permettront de tracer tous les relevés automatiques.

L'authentification snmp est un ensemble d'informations permettant le relevé compteurs en automatique du périphérique via son adresse IP et le protocole snmp.
L'authentification devra être gérée avec la version du protocole (version 1 et 2 au minimum), la communauté en lecture, le couple utilisateur - mot de passe.

Un modèle de facturation sera un ensemble de coûts à la page associable à un modèle de relevé compteurs.
Chaque type de compteurs du modèle de relevé compteurs sera associé à une valeur numérique réelle exprimée en cent-millième d'euro associé à un affichage en euro les 1000 pages (exemple 5,18'/1000 pages).
Le modèle de facturation comportera une date d'application. Le modèle de facturation sera associable à un tiers, un budget, à un contrat (objets GLPI existant).

Une enveloppe budgétaire sera une valeur numérique monétaire associée à une entité et représentant un plafond de dépense pour une période donnée (date de début et date de fin).
Cette enveloppe pourra être repartie en sous-enveloppe reparties pour les sous-entités pour la même période.

1. Besoin initial

Mise en place d'un plugin de gestion des compteurs des imprimantes basé sur le protocole SNMP.
Le plugin se base sur l'inventaire déja existant de GLPI, pour récupérer les adresses IP des imprimantes de chaque entité.
Le plugin permet :
  • d'effectuer le relevé des compteurs des imprimantes sur le réseau
  • de configurer et de gérer l'interrogation des compteurs pour chaque imprimante
  • d'afficher et de gérer les coûts par entités

1.1. Contraintes

Le plugin sera développé :
  • en version 0.84.x de GLPI,
  • à partir de la version 5.4 de PHP.

Le plugin doit pouvoir interroger 3000 à 4500 imprimantes potentielles.

1.2. Performances

Temps de réponse des fonctions en mode transactionnel < 1 seconde.
Le relevé automatique ne doit pas induire de dysfonctionnement ni sur le réseau ni sur les hôtes sollicitées par les requêtes IP.
L'outil doit être optimisé pour assurer un relevé automatique hebdomadaire sur la totalité du parc d'imprimantes.

2. Fonctionnement de l'interrogation / suivi des compteurs

2.1. Menu

Le menu se divise en deux parties, le suivi des compteurs et le suivi des budgets.
Pour la partie suivi des compteurs qui concerne cette partie, Il est possible de :
  • Gérer les modèles de compteurs
  • Gérer les types de compteurs
  • Consulter les prochains relevés de compteurs planifiés
  • Configurer les authentifications SNMP du plugin

2.2. Gestion-SNMP

L'agent SNMP est géré en PHP, grâce à une bibliothèque SNMP orientée objet (à partir de la version 5.4) faisant office de « surcouche » et proposant plusieurs fonctions pour interagir avec les imprimantes SNMP.
Cette bibliothèque permet aussi de mieux gérer les erreurs renvoyées par l'agent SNMP.
Le serveur prendra à charge l'interrogation des imprimantes en tant que client de l'agent SNMP du périphérique dans un mode de fonctionnement du type Nagios.

2.2.1. Configuration SNMP

Le paramétrage du binaire d'interrogation se fera par son chemin d'accès (ex : /usr/bin/net-snmp ; C:\usr\bin\snmpget.exe) dans la page de configuration générale du plugin.

2.2.2. Authentification SNMP

L'authentification SNMP devra être gérée avec la version du protocole version 1 et 2 au minimum, elle sera configurable dans une vue du plugin « Authentification SNMP ».
Plusieurs modèles d'authentifications peuvent être créés et seront visibles dans une liste.
Elle se compose des champs suivants :
  • Nom : Nom donné à l'authentification
  • Version SNMP : version SNMP utilisée (1, 2c ou 3)
  • Communauté : Nom de la communauté (pour la lecture / écriture) utilisée uniquement pour la version 1 et 2c de SNMP
  • Utilisateur : uniquement pour la version 3 de SNMP
  • Protocole de cryptage pour authentification : uniquement pour la version 3 de SNMP
  • Mot de passe : uniquement pour la version 3 de SNMP
  • Protocole de cryptage pour les données (écriture) : uniquement pour la version 3 de SNMP
  • Mot de passe (écriture) : uniquement pour la version 3 de SNMP

2.4. Système multiprocessus

Le plugin lance la recherche des imprimantes sur plusieurs processus en parallèle pour gagner en performances.
L'exécution de l'interrogation SNMP est divisée en plusieurs processus. Chacun de ces processus exécute les fonctions d'interrogation et d'ajout des valeurs de compteurs des imprimantes.
Les imprimantes disponibles en base de données GLPI sont divisées entre les processus.
Chaque processus à sa propre pile d'imprimantes à interroger.

2.5. Critères de sélection des imprimantes à interroger

Plusieurs critères permettent de sélectionner une imprimante à interroger :
  • Imprimante non supprimée
  • Possédant au moins une adresse IP
  • Interrogation automatique activée
  • Possédant un modèle de relevé
  • La périodicité de relevé est vérifiée : Différence entre la date d'interrogation et la date du dernier relevé est supérieure ou égale à la périodicité.

2.6. Exécution de l'interrogation

Le point d'entrée de la recherche d'imprimante est un script .sh. appelé par la tâche automatique (CRON) du système. Cette tâche doit être paramétrée au préalable sur le serveur exécutant le plugin printercounters.
L'interrogation SNMP s'exécute dans cet ordre, dans le cas ou aucune erreur n'est survenue lors des tests IP, de conformité, et sur les valeurs de compteur :
  • Une tâche automatique permet de lancer le script d'interrogation tous les jours
  • Les imprimantes sont groupées par entités
  • Sélection des imprimantes à interroger. Voir 2.5
  • Répartition pour chaque processus
  • L'interrogation SNMP s'initialise pour chaque adresse IP des imprimantes, avec la configuration de l'authentification SNMP, et la configuration du relevé.
  • Les OID correspondants aux types de compteurs du modèle de relevé sont chargés
  • Création du relevé pour chaque imprimante, avec l'état « en cours »
  • Les tests de conformité correspondants au modèle de relevé sont exécutés
  • Chaque compteur des imprimantes sont relevés
  • Un test sur la valeur des compteurs est fait (ne doit pas être inférieur au dernier relevé)
  • Enregistrement du relevé, mise à jour de l'état en « Terminé », ajout de la date du relevé.

2.7. Gestion des erreurs

Le schéma ci-dessous résume l'interrogation et la gestion des erreurs :

2.7.1. Règles de conformité

Lors d'un relevé automatique, le moteur d'interrogation devra gérer les erreurs de caractéristiques du périphérique renseignées dans GLPI-Ports réseau et celles du périphérique répondant à l'adresse IP :
Règle Description
Adresse IP Le périphérique ne répond pas avec l'adresse IP spécifiée dans GLPI.
Adresse MAC OID ifPhysAddress (.1.3.6.1.2.1.2.2.1.6 ' RFC 1213) à comparer avec l'adresse MAC de l'imprimante dans GLPI
SysDescr OID SysDescr (.1.3.6.1.2.1.25.3.2.1.3.1 ' RFC 1759) à comparer avec le sysdescr de l'imprimante définie dans le plugin printercounters
Numéro de série OID spécifié dans le modèle de relevé compteur (paramétrable) à comparer avec le numéro de série de l'imprimante dans GLPI
Le résultat de l'opération de relevé sera inscrit en base de données avec les valeurs suivantes :
Résultat Description
Succès Tests de conformité ok, les compteurs répondent au relevé
Echec IP Time-out sur toutes les tentatives de relevé
Echec MAC OID ifPhysAddress (.1.3.6.1.2.1.2.2.1.6 ' RFC 1213) retourne une valeur différente de celle de la connexion réseau associée au périphérique
Echec SysDescr OID SysDescr (.1.3.6.1.2.1.25.3.2.1.3.1 ' RFC 1759) retourne une valeur différente de celles définies sur le modèle de relevé compteur.
Echec Serial OID spécifié dans le modèle de relevé compteur (paramétrable) retourne une valeur différente que celle définie sur le périphérique.

Lors d'un relevé automatique si le test de conformité matérielle est négatif, le relevé sera inscrit dans la base avec le type « erreur hôte ».

2.7.2. Erreur relevé

Lors d'un relevé, la valeur d'un compteur ne pourra être inférieure à celle du dernier relevé typé « automatique » ou « manuel ».
Dans le cadre d'un relevé manuel, l'erreur sera signifiée à l'opérateur sans enregistrement dans la base.
Dans le cadre d'un relevé automatique, le relevé sera enregistré dans la base avec le type « erreur relevé ».

2.7.3. Interruption

Les relevés automatiques doivent être conçus pour être stoppés manuellement ou arrêtés inopinément (coupure réseau, coupure électrique) et reprendre par la suite les opérations de relevé sans dysfonctionnement notoire.
En cas d'interruption lors du relevé automatique (arrêt du périphérique, coupure réseau'), le relevé ne sera pas enregistré dans la base.
Lors de la reprise de l'interrogation, la périodicité des relevés automatiques est vérifiée :
si la différence entre la date d'interrogation et la date du dernier relevé est supérieure ou égale à la périodicité, alors l'imprimante doit être interrogée.

Par exemple pour une imprimante « IMP01 » : 
L'interrogation SNMP est lancée tous les jours avec une CRON du serveur.
Date du dernier relevé de l'imprimante : 12-03-2014
Périodicité de relevé de l'imprimante : 1 jour
Le 13-03-2014 le relevé de l'imprimante s'est interrompu
Le 14-03-2014 l'interrogation se lance
Pour l'imprimante IMP01 la différence entre la date du dernier relevé et la date de l'interrogation actuelle est 2 jours.
Or la périodicité est de 1 jour.
L'imprimante sera donc interrogée.

2.7.4. Adresses IP multiples

Dans le cas d'adresse IP multiples pour un périphérique (Ethernet et Wifi par exemple), le moteur d'interrogation devra gérer le doublon en n'inscrivant qu'un relevé.
En cas d'erreur sur l'une et Succès sur l'autre adresse, seul le résultat du Succès est à inscrire.
En cas de double erreur, les deux relevés sont à inscrire en erreur dans l'historique.

2.8. Compteurs

2.8.1. Types de compteurs

Les types de compteurs sont consultables en cliquant sur « Type de compteurs » dans le menu du plugin, ou dans « Configuration/intitulés » de GLPI.
Les types de compteurs sont associés à un Object Identifier (OID) de la MIB (Management Information Base) du protocole SNMP (Simple Network Management Protocol).
Plusieurs
Le nombre de compteurs sera variable d'un modèle à l'autre.
Les types de compteur et leurs OID seront paramétrables au niveau des modèles de relevé de compteurs.

2.8.2. Compteur

Un compteur sera un nombre entier associé à un type de compteur.

2.9. Modèle de relevé de compteurs

Les modèles de relevés de compteurs sont consultables en cliquant sur « Modèle de relevé de compteurs » dans le menu du plugin, ou dans « Configuration/intitulé » de GLPI.

2.9.1. Formulaire du modèle de relevé de compteur

Voici le formulaire du modèle de relevé de compteur, des cases à cocher permettent d'activer ou non les règles de conformité.
Ces règles peuvent être modifiées massivement dans la liste des modèles de relevé de compteur.

2.9.2. Ajout des types de compteurs

Dans un onglet « Type de compteurs » du formulaire des modèles de relevé de compteurs, il sera possible d'ajouter des types de compteurs en l'associant à un OID.
Une liste est présente à l'ajout des compteurs pour préciser le type d'OID qui va être ajouté. Il peut être de type « Couleur », « Monochrome » pour la prise en compte dans les ratios.
Il peut être « Numéro de série » pour la prise en compte dans les tests de conformité. Par défaut ce champ peut être vide.
Il sera possible de modifier l'OID et le type d'OID en cliquant sur le nom du type de compteur dans la liste.

2.9.3. Association aux imprimantes

Un onglet « Imprimantes liées » permettra d'ajouter ou de supprimer les imprimantes d'un modèle de relevé de compteurs.
Un périphérique ne pourra être associé qu'à un seul modèle de relevé compteurs.

Les modèles de relevé de compteurs pourront aussi être associés aux imprimantes grâce à une action massive disponible sur la liste des imprimantes.

2.9.4. Ajout des sysdescr

Un onglet « Sysdescr » sera disponible dans les modèles de relevé de compteurs pour renseigner les valeurs des « sysdescr » possibles pour le modèle de relevé de compteurs.
Plusieurs « sysdescr » peuvent être ajoutés pour chaque modèle de relevé de compteurs.
Lors des tests de conformité, les valeurs de « sysdescr » du modèle de relevé de l'imprimante sont testées. Si aucune ne correspond, le test a échoué.

2.9.5. Transfert de l'imprimante vers une autre entité

Si une imprimante est transférée vers une autre entité, il y a un impact sur le modèle de relevé de compteurs, qui dépend d'une entité.
Le modèle de relevé de compteur lié à l'imprimante devra être dupliqué sur la nouvelle entité de l'imprimante selon.
Note : Si le modèle de relevé de compteur est défini sur une entité parente en mode récursif, il ne sera pas dupliqué sur l'entité fille.

2.9.6. Règles de conformité

Un modèle de relevé compteurs associera une liste de mentions de description de l'hôte (ex. SysDescr) pour soutenir les tests de conformité matériel.
Ces règles de conformité pourront être activées ou non sur chaque modèle de relevé compteurs avec la possibilité de modification en masse depuis la liste des modèles de relevé compteurs.

2.10. Relevés de compteurs

Le relevé compteurs reposera sur le modèle de relevé compteurs associé au périphérique, et portera la valeur de tous les compteurs associés.
La date du relevé compteur sera l'horodatage de fin de relevé pour l'ensemble des compteurs.
Si le modèle de relevé compteurs est modifié après des relevés, dans la vue de l'historique la valeur affichée pour les types de compteurs ajoutés sera « 0 ». Le relevé de compteur ne peut être supprimable, c'est juste un historique.

2.10.1. Type du relevé de compteurs

Le type de relevé de compteurs pourra être manuel (par un opérateur), ou automatique (par le moteur d'interrogation). A ces deux types de relevés à succès, s'ajoutera les types erreur hôte et erreur relevé. Ces derniers permettront de tracer tous les relevés automatiques.

2.10.2. Configuration

La configuration du relevé de compteurs se fait dans l'onglet « relevé de compteurs » des imprimantes.
La périodicité et l'activation du relevé automatique sont modifiables en masse sur la liste des imprimantes.

Ces paramètres sont utilisés pour initier l'interrogation SNMP de l'imprimante :
  • l'activation ou non du relevé automatique, par défaut oui
  • l'authentification SNMP à utiliser
  • la périodicité du relevé automatique (minimum 1 jour), par défaut un jour
  • le nombre de ré-essais (de 0 à 10) sur erreur de communication IP, par défaut 2
  • le délai (de 1mn à 24h) à entre chaque tentative, par défaut 1mn
    Ces actions de paramétrage feront l'objet d'une trace historique pour ce périphérique.

2.10.3. Actions supplémentaires

Des actions sont disponibles dans l'onglet « Relevé de compteurs ».
Note : Ces actions seront aussi disponibles dans les actions massives des imprimantes.

2.10.3.1. Relevé immédiat

Sur cet onglet, une fonction devra permettre l'interrogation immédiate du périphérique pour un relevé compteurs automatique.

2.10.3.2. Mise à jour de l'attribut « position compteur »

Une fonction sera proposée pour mettre à jour l'attribut « position compteur » du périphérique (existant sous GLPI) sur la base de l'OID prtMarkerLifeCount.1.1 (1.3.6.1.2.1.43.10.2.1.4.1.1) du RFC 1213.

2.10.3.3. Relevé manuel

Le relevé manuel sera utilisé pour initialiser les positions compteurs à réception du périphérique et pour les imprimantes non interrogeables par le réseau (non connectés, sur des réseaux autonomes').
En cliquant sur « Ajouter un relevé manuel », des champs d'édition des compteurs apparaissent dans une fenêtre modale.
En cliquant sur « Ajouter » l'historique se met à jour avec le nouveau relevé.
Le relevé ne s'ajoute pas et affiche un message d'erreur, si un compteur est inférieur à celui du relevé précédent.

2.10.4. Historique des relevés

Dans un onglet « Relevé de compteurs »du périphérique, une vue offrira l'historique des relevés des compteurs pour le périphérique.
En plus des valeurs numériques des compteurs par type, s'ajoutera le type de relevé, l'entité de tutelle, la localisation, le budget de facturation (voir la deuxième partie des spécifications fonctionnelles) à la date du relevé.
L'affichage par défaut sera chronologique, du plus récent au plus ancien.
Un filtre pourra être appliqué pour les champs entité, localisation, type de relevé et budget. Le filtre par nombre d'item sera applicable.
Le total des valeurs monétaires des relevés pour la vue sera affiché en bas de la liste.
Un relevé ne pourra être supprimé par l'utilisateur.

2.10.5. Champs supplémentaires de recherche des imprimantes

Il devra être possible d'ajouter sur la liste des imprimantes les colonnes suivantes pour le périphérique :
  • Date du dernier relevé
  • Type relevé du dernier relevé
  • Coûts du dernier relevé compteurs
  • Relevé automatique actif
  • Modèle de relevé de compteur

2.10.6. Modification d'un relevé

Une habilitation spéciale devra être allouée pour modifier les relevés.
Cette modification peut avoir lieu que dans le cas d'une mise à 0 forcée ou de positions inférieures au dernier relevé.
La modification massive n'est pas possible.
Si l'utilisateur dispose du droit de modifier les relevés, ceux-ci seront éditables dans l'historique des relevés.
En cliquant sur la ligne concernée, un formulaire apparaît dans une fenêtre modale.

2.10.7. Planification

Une vue sur le plugin listera la planification des relevés automatiques programmés par ordre chronologique croissant, filtrable par entité, par périodicité et par état.
Le filtre par nombre d'item sera applicable. Par défaut seuls les états « en cours » et « programmé » seront affichés.

Le résultat de l'opération de relevé sera inscrit en base de données avec les valeurs suivantes :
Résultat Description
Succès Tests de conformité ok, les compteurs répondent au relevé
Echec IP Time-out sur toutes les tentatives de relevé
Echec MAC OID ifPhysAddress (.1.3.6.1.2.1.2.2.1.6 ' RFC 1213) retourne une valeur différente de celle de la connexion réseau associée au périphérique
Echec SysDescr OID SysDescr (.1.3.6.1.2.1.25.3.2.1.3.1 ' RFC 1759) retourne une valeur différente de celles définies sur le modèle de relevé compteur.
Echec Serial OID spécifié dans le modèle de relevé compteur (paramétrable) retourne une valeur différente que celle définie sur le périphérique.
L'état du relevé est mis à jour au début et à la fin de l'interrogation des compteurs :
Etat Description
En cours Initialisation du relevé des compteurs
Terminé Fin du relevé des compteurs, et la date du relevé est ajoutée
Programmé Par défaut, pour l'affichage du prochain relevé de type automatique avec une périodicité définie

2.10.8. Création automatique de ticket

Une fonction sera proposée pour l'action automatique de création d'un ticket lié au périphérique portant sur un nombre paramétrable d'erreurs consécutives (« erreur relevé » et/ou « erreur hôte »).
Une fonction sera proposée pour l'action automatique de création d'un ticket lié au périphérique portant sur une absence de relevé de type « automatique » ou « manuel » depuis un délai paramétrable en nombre de jours,
et fonction du statut du périphérique, la règle du OU s'appliquant pour lister les statuts éligibles.

Ces tickets seront affectés au groupe et au responsable technique du périphérique avec le statut « nouveau » et seront associés à l'entité du périphérique.
Une catégorie de ticket spécifique peut être crée pour le traitement des imprimantes.
Ces paramètres de création de tickets seront disponibles dans la configuration générale du plugin :

2.10.9. Blocage général des relevés automatiques

Une option sera disponible dans la configuration générale du plugin pour bloquer les relevés automatiques.
Note : la désactivation du plugin de GLPI a aussi pour effet de bloquer les relevés automatiques.
Il sera possible d'arrêter les processus d'interrogation en cours en appuyant sur le bouton « Interrompre les relevés en cours ».
Si tous les compteurs du relevé n'ont pas étés enregistrés, il ne sera pas enregistré. Il faudra attendre sa prochaine exécution par la CRON, en fonction de sa périodicité.

2.11. Suppression/restauration d'une imprimante

A sa suppression, le matériel n'est plus pris en compte dans l'interrogation SNMP.
A la restauration du matériel, une action manuelle permettra de réactiver son interrogation automatique.

2.12. Droits du plugin

Une habilitation spéciale devra être allouée pour modifier les relevés (mise à 0 forcée ou positions inférieures au dernier relevé), mais pas possible en modification massive.
Il faudra avoir un droit en lecture sur son profil pour pouvoir accéder aux formulaires du plugin.
Un doit en écriture permet de modifier les objets du plugin.

3. Fonctionnement du suivi des budgets

Le suivi des budgets repose sur la valorisation monétaire des différentiels des relevés compteurs. Ces coûts agrégés sont imputés à une enveloppe associée.

3.1. Menu

Le menu se divise en deux parties, le suivi des compteurs et le suivi des budgets.
Pour la partie suivi des budgets qui concerne ce document, Il est possible de :
  • Gérer la liste des modèles de facturation
  • Gérer la liste des enveloppes budgétaires

3.2. TCO

Pour calculer le TCO global du périphérique, il faut d'abord obtenir la somme des coûts de ses relevés de compteurs.
Ces coûts sont ensuite ajoutés au TCO disponible dans l'onglet « Gestion » de GLPI, qui se compose de :
  • La valeur d'achat (existant dans GLPI)
  • Les coûts d'intervention (existant dans GLPI)
    Le nouveau TCO calculé sera stockée dans le champ « global_tco » de la table glpi_printercounters_items_recordmodels du plugin.
    Un bouton sera disponible dans les actions supplémentaires de l'imprimante de l'onglet « Relevé de compteurs », pour mettre à jour ce champ :
    Cette action sera aussi disponible massivement.

Le champ « TCO global » intégrant la somme des relevés, sera injecté dans le formulaire existant de l'onglet « Gestion » des imprimantes. Il sera visible en dessous du champ TCO déjà existant.
La colonne « TCO global » intégrant la somme des relevés devra être visible au niveau de la liste des imprimantes.

3.3. Coûts des copies

3.3.1. Transfert d'entité

Si deux relevés successifs sont imputés à deux entités différentes, le coût du relevé sera imputé à l'entité du relevé le plus récent.

3.3.2. Calcul des coûts

Le coût d'un relevé sera calculé sur la différence des positions d'un relevé compteurs pour un type de compteur donné multiplié du coût à la page pour ce type de compteur, au tarif le plus récent applicable à la date du relevé.
S'agissant du plus ancien des relevés compteurs, la différence des positions compteurs retournera la valeur « 0 ».
En cas de différentiel négatif pour un type de compteur, le coût est fixé à 0'.
Le calcul sera réalisé lors de l'association du modèle de facturation au périphérique sur l'ensemble de ses relevés compteurs en fonction de la date d'application du modèle de facturation.
Dans le cas d'une date d'application d'un modèle de facturation (ex : 03/03) entre deux dates de relevé compteurs (ex : 01/03 et 07/03), la règle de prorata des jours s'appliquera : du 2/6 du volume avec l'ancien modèle de facturation 4/6 sur le nouveau modèle de facturation.

3.4. Modèles de facturation

Les modèles de facturation sont consultables en cliquant sur « Modèles facturation » dans le menu du plugin, ou dans « Configuration/intitulé » de GLPI.
La modification d'une valeur monétaire du modèle de facturation entraine une mise à jour des calculs de coûts de relevés compteurs pour les périphériques associés au modèle de facturation.
Une absence de modèle de facturation entraine des coûts à « 0 ».

3.4.1. Formulaire du modèle de facturation

L'ajout d'un nouveau modèle de facturation s'initiera avec l'association d'un modèle de relevé compteurs pour y reprendre la liste des types de compteurs à valoriser.
Ce modèle de facturation sera caractérisé par une date d'application et associable à un budget, un fournisseur, un contrat et valable pour l'entité de création de l'objet et sous-entité le cas échéant.
Une fois le modèle créé et associé à son modèle de relevé de compteurs, il sera possible d'ajouter de modifier, et de supprimer les coûts de chaque type de compteurs.
Un type de compteur ne sera pas supprimable au niveau du modèle de relevé de compteurs, s'il est ajouté au modèle de facturation.
Il sera possible d'ajouter de nouveau type de compteurs au modèle de relevé de compteurs, ils apparaîtront ensuite au niveau du modèle de facturation associé.

Note : Il ne pourra pas y avoir plusieurs modèles de facturation ayant la même date et le même modèle de relevé de compteurs.
Il ne sera pas possible de changer le modèle de relevé de compteurs au niveau du formulaire du modèle de facturation, car les types de compteurs renseignés dépendent du modèle de relevé de compteurs.

3.4.2. Ajout des types de compteurs

Un onglet « Type de compteur » permettra d'ajouter et supprimer des types de compteurs associés à un coût.
Il sera possible de modifier le coût en cliquant sur le nom du type de compteur dans la liste.

3.4.3. Association aux imprimantes

Pour un modèle de facturation, un onglet « Imprimantes liées » listera les périphériques associés.
Il sera possible d'ajouter et de supprimer de nouvelles imprimantes.
Les champs Nom, Entité, Statut, Type, Modèle et Lieu sont des champs renseignés au niveau des imprimantes de GLPI.

Il peut y avoir plusieurs modèles de facturation pour les imprimantes.
Il sera possible d'ajouter en masse les modèles de facturation
Un onglet sur le périphérique devra permettre l'affichage des modèles de facturation associés. Il sera possible d'ajouter et de supprimer des modèles de facturation.

3.4.4. Critères de prise en compte d'un modèle de facturation

3 critères seront vérifiés pour prendre en compte les modèles de facturation de l'imprimante :
  • Il faut que le modèle de relevé de compteurs du modèle de facturation corresponde au modèle de relevé de compteurs de l'imprimante
  • Si aucun modèle de relevé de compteurs n'est défini dans l'imprimante, aucun modèle de facturation ne sera pris en compte
  • Le choix du modèle de facturation dépend de sa date d'application
  • Il ne peut y avoir 2 modèles de facturation avec la même date d'application sur une même imprimante

3.4.5. Coûts à la page

Un modèle de facturation sera un ensemble de coûts à la page associable à un modèle de relevé compteurs. Chaque type de compteurs du modèle de relevé compteurs sera associé à une valeur numérique réelle exprimée en cent-millième d'euro associé à un affichage en euro les 1000 pages (exemple 5,18'/1000 pages). Un modèle de facturation est valable pour l'entité de création de l'objet et sous-entité le cas échéant.

3.4.6. Transfert de l'imprimante vers une autre entité

Si une imprimante est transférée vers une autre entité, il y a un impact sur le modèle de facturation, qui dépend d'une entité.
Le modèle de facturation lié à l'imprimante devra être dupliqué sur la nouvelle entité de l'imprimante.
Note : Si le modèle de facturation est défini sur une entité parente en mode récursif, il ne sera pas dupliqué sur l'entité fille.

3.4.7. Liste des modèles de facturation

En cliquant sur « Modèles de facturation » dans le menu du plugin, une vue permettra l'affichage de l'ensemble des modèles de facturation avec la possibilité d'afficher tous les types de compteurs de manière paramétrable. Un filtre sera possible sur la date d'application, le fournisseur, le budget et le contrat.
Note : GLPI gère nativement les listes d'objets, avec un paramétrage possible des colonnes à afficher. Il ne serait pas possible de paramétrer l'affichage de tel ou tel type de compteur pour chaque modèle de facturation.
Il est possible d'afficher ou non l'ensemble des types de compteurs pour chaque modèles de facturation.

3.5. Enveloppe budgétaire

Les enveloppes budgétaires sont consultables en cliquant sur « Enveloppes budgétaires » dans le menu du plugin, ou dans « Configuration/intitulé » de GLPI.
Le plugin devra soutenir la méthode de rationalisation par enveloppe budgétaire contrainte attribuée aux entités et sous-entités associées.

3.5.1. Formulaire de l'enveloppe budgétaire

Le formulaire de l'enveloppe budgétaire permet d'ajouter un montant et des dates à chaque enveloppe de l'entité courante.
Note : Pour ajouter une enveloppe sur une entité il faut se positionner sur l'entité voulue au préalable.

3.5.2. Sommes des enveloppes

Une enveloppe budgétaire sera une valeur numérique monétaire associée à une entité et représentant un plafond de dépense pour une période donnée (date de début et date de fin). Cette enveloppe pourra être répartie en sous-enveloppe réparties pour les sous-entités pour la même période.
Pour une même entité, deux périodes ne peuvent se superposer.
La somme des enveloppes budgétaires de sous-entités ne peut excéder l'enveloppe budgétaire de l'entité mère sauf si l'enveloppe budgétaire de l'entité mère n'existe pas ou est nulle.

3.5.3. Taux d'usage

Le taux d'usage de l'enveloppe budgétaire pourra être supérieur à 100%.
Ce taux est calculé avec la somme des coûts des relevés compteurs de cette entité et ses sous-entités sur la période de l'enveloppe.
Le calcul se fait en plusieurs étapes :
  • Sélection des entités ayant une enveloppe budgétaire
  • Affectation des relevés de compteur sur une enveloppe en fonction de l'entité et de la période de l'enveloppe.
  • Somme des coûts des relevés pour chaque enveloppe
  • La somme de chaque enveloppe est imputée aux enveloppes de son entité parente, si la période correspond. Cela est fait de manière récursive.
  • Une fois les sommes réparties les taux d'usage peuvent être calculé :(Somme des relevés / Budget de l'enveloppe) X 100

3.5.4. Ratio couleur

Le ratio couleur sera inférieur à 100%.
Ce ratio est calculé avec la sommes des coûts des relevés compteurs de type « Couleur » de cette entité et ses sous-entités sur la période de l'enveloppe.
Un paramétrage sur le greffon permettra de choisir les compteurs à prendre en compte dans le ratio couleur sur la base des types de compteur définis. Le choix portera sur les compteurs monochromes et couleurs car il est envisagé de relever les compteurs de numérisation avec éventuellement un coût « copie » associé.
Note : Cette exigence est aussi visible dans la première partie des spécifications fonctionnelles.
Le calcul se fait en plusieurs étapes :
  • Sélection des entités ayant une enveloppe budgétaire
  • Affectation des relevés de compteur sur une enveloppe en fonction de l'entité et de la période de l'enveloppe.
  • Somme des coûts de compteurs de type « Couleur » pour chaque relevé
  • Somme des coûts relevés
  • La somme de chaque enveloppe est imputée aux enveloppes de son entité parente, si la période correspond. Cela est fait de manière récursive.
  • Une fois les sommes réparties le ratio couleur peut être calculé. La valeur maximum est 100% : (Somme des relevés « Couleur » / Budget de l'enveloppe) X 100

3.5.5. Nombre de page total

Cette valeur affiche la somme des compteurs de cette entité et ses sous-entités sur la période de l'enveloppe.
Le calcul se fait en plusieurs étapes :
  • Sélection des entités ayant une enveloppe budgétaire
  • Affectation des relevés de compteur sur une enveloppe en fonction de l'entité et de la période de l'enveloppe.
  • Somme des compteurs pour chaque relevé
  • Somme des relevés
  • La somme de chaque enveloppe est imputée aux enveloppes de son entité parente, si la période correspond. Cela est fait de manière récursive.

3.5.6. Ratio nombre de pages couleur

Cette valeur affiche la somme des volumes des compteurs de type « Couleur » par rapport au nombre total de pages calculé ci-dessus.
Le calcul se fait en plusieurs étapes :
  • Sélection des entités ayant une enveloppe budgétaire
  • Affectation des relevés de compteur sur une enveloppe en fonction de l'entité et de la période de l'enveloppe.
  • Somme des compteurs de type « Couleur » pour chaque relevé
  • Somme des relevés
  • La somme de chaque enveloppe est imputée aux enveloppes de son entité parente, si la période correspond. Cela est fait de manière récursive.
  • Une fois les sommes réparties le ratio nombre de pages couleur peut être calculé : (Nombre de pages « Couleur » / Nombre de pages total) X 100

3.5.7. Liste des enveloppes budgétaires

En cliquant sur « Enveloppe budgétaire » dans le menu du plugin, une vue permettra de lister les sous-entités de l'entité active avec les enveloppes budgétaires associées et le taux d'usage de ces enveloppes budgétaires.
Un filtre sur les dates début et fin, le nom de l'enveloppe et l'entité sera possible.
Les totaux seront à poser en fin de vue avec le total des valeurs monétaire pour le montant, et la moyenne pour les valeurs %.

3.5.8. Suppression/restauration d'une imprimante

Si l'imprimante est en corbeille, il faut la prendre en compte dans le calcul du taux d'usage de l'enveloppe budgétaire.

4.Base de données

Voici la structure complète du plugin printercounters, prenant en compte la première partie des spécifications fonctionnelles.

4.1. Modèle logique de données

5. Proposition d'intégration dans le coeur / Partage des données

La partie facturation et budget pourrait être gérée à terme par le coeur.

Cela permettrait d'avoir un socle commun de facturation (coûts des copies) pour les plugins de relevé de compteurs SNMP tel que printercounters ou Fusion Inventory.

L'idée serait que GLPI gère les modèles de compteurs contenant des types de compteurs pour chaque imprimantes.
Il serait possible de renseigner les coûts de chaque compteur grâce à un modèle de facturation lié à l'imprimante et au modèle de compteurs.

5.1. Liaison avec les plugins

Il faudrait pouvoir établir une liaison avec les modèles de compteurs et les types de compteurs du plugin.

Pour lier un modèle de compteurs du plugin à celui de GLPI deux champs seraient disponibles :
Champ Description
foreign_recordmodels_id Id du modèle de compteurs du plugin
foreign_itemtype Nom du plugin
Pour lier un type de compteur du plugin à celui de GLPI deux champs seraient disponibles :
Champ Description
foreign_countertypes_id Id du type de compteur du plugin
foreign_itemtype Nom du plugin

Cela permettrait au plugin d'exploiter les données de GLPI.

5.2. Modèle logique de données

Le modèle de données ci-dessous représente une proposition de fonctionnement de la facturation adaptée au coeur de GLPI :

Observations

David : pourquoi tu fais tes specs de plugin dans le wiki de glpi ?
et pourquoi ne pas te rapprocher du projet FusionInventory qui fait déjà pas mal de choses par rapport à tout ça'

Il faudrait qu'on en parle avec tsmr, il est en congé il revient lundi

Tsmr :
- pourquoi tu fais tes specs de plugin dans le wiki de glpi ?
C'est un souhait du client pour une possible intégration future au coeur

- pourquoi ne pas te rapprocher du projet FusionInventory qui fait déja pas mal de choses par rapport à tout ça ?
Le client au départ souhaitait améliorer Fusion Inventory (email qui t'était adressé - sans suite je pense). Puis il a décidé de lancer une consultation sur les partenaires (hors Fusion Inventory).

Oki ;)

JMD : Je ne vois pas dans ce qui a été poussé ce qui relève du coeur. Là j'ai le copié/collé du cahier des charges d'un plugin... On pouvait tout à fait imaginer s'appuyer sur l'agent FusionI et un mode dégradé/simplifié du plugin FusionI pour faire le job par exemple. Tout cela me laisse perplexe...

Ludo : J'ai ajouté une proposition d'intégration au coeur à la fin du wiki

MLD_final.png (76.5 KB) ludo, 03/10/2014 02:25 PM

Moteur_interrogation.png (40.6 KB) ludo, 03/10/2014 02:32 PM

record_model_2.png - Ajout des types de compteurs (67.4 KB) ludo, 03/10/2014 02:37 PM

record_history.png - Relevés de compteurs (84.9 KB) ludo, 03/10/2014 02:42 PM

planification.png (42.5 KB) ludo, 03/10/2014 02:46 PM

menu_-_final.png - Menu (23.2 KB) ludo, 03/10/2014 02:49 PM

billing_model_3.png - Modèle de facturation (63.4 KB) ludo, 03/10/2014 02:56 PM

billing_model_2.png - Modèle de facturation - Imprimantes liées (69.1 KB) ludo, 03/10/2014 02:58 PM

budget.png - Enveloppe budgétaire (55 KB) ludo, 03/10/2014 03:06 PM

record_model_printers.png - Modèle de relevé - Imprimantes liées (62.2 KB) ludo, 03/10/2014 03:06 PM

sysdescr.png - Modèle de relevé - sysdescr (48.9 KB) ludo, 03/10/2014 03:11 PM

SNMP_Authentification.png - SNMP authentication (36.7 KB) ludo, 03/10/2014 03:11 PM

budget_form.png - Enveloppe budgétaire - formulaire (21.9 KB) ludo, 03/10/2014 03:23 PM

record_model_llist.png - Modèle de relevé - liste des modèles (57.7 KB) ludo, 03/10/2014 03:23 PM

MLD_Intégration_GLPI.png (32.4 KB) ludo, 03/11/2014 11:35 AM