Évolutions fonctionnelles

1. Objet du document

Ce document présente les principales évolutions fonctionnelles apportées aux logiciels édités par CARL Berger-Levrault depuis la précédente version majeure de chacun des produits.

En l’occurrence, ce document décrit exclusivement les nouveautés concernant la solution :

CARL Source Admin version 5.5
CARL Source version 7.7.0
CARL Touch version 7.7.0
CARL Xpress version 7.7.0
CARL Flash version 7.7.0

Par ailleurs, le document ne mentionne pas les modules ou les options auxquels se rattachent les évolutions fonctionnelles présentées par la suite.
Vos interlocuteurs commerciaux CARL Berger-Levrault se tiennent à votre disposition pour vous apporter toute information utile au regard de la configuration de votre licence CARL Source concédée.

2. CARL Source Admin

CARL Source Admin 5 utilise Java™ en version 17. Lors de son installation, il est obligatoire de lui fournir le chemin d’accès à ce dernier.

New 5.2

Pour des raisons de sécurité, à compter de la version 5.2, le compte root n’est plus fourni avec un mot de passe par défaut ; ce dernier doit être saisi lors de l’installation en respectant certaines règles :

longueur comprise entre 8 et 128 caractères
au moins un caractère minuscule
au moins un caractère majuscule
au moins un digit
au moins un caractère spécial

A noter qu’en mise à jour, le compte root conserve le mot passe déjà présent dans CARL Source Admin.
En cas de changement, les mêmes règles devront être suivies pour le nouveau mot de passe.

New 5.3

A compter de la version 5.3, la gestion de la licence de CARL Source est intégrée dans CARL Source Admin.

Pour plus de détails sur CARL Source Admin 5.5, veuillez consulter le document Utilisation CARL Source Admin 5.

3. CARL Source

3.1. Général

Les versions 7.X sont principalement enrichies par :

Des ajustements ergonomiques,
Un moteur d’affectation automatique des ressources,
Des évolutions sur le multidevises,
Des nouveautés autour du thème énergie et fluide,
Des nouveautés autour de l'intelligence intégrée,
Des évolutions sur le workflow d’états, la fiche caractéristiques, les points de contrôle,
Des évolutions sur les mémos RGPD, l’anonymisation et le consentement.
Des évolutions sur les produits mobiles.

3.2. Intégration des addons au produit standard & évolutions liées

New 7.2

La réintégration de certains addons dans cette version implique des réajustements fonctionnels sur l’exploitation de la solution.
Elle fait suite aux premiers travaux de réintégrations techniques commencés en version 6.x.

À partir de cette version, les addons ci-dessous sont intégrés à CARL Source et disparaissent des distributions liées au produit :

CNEH
Import BUREAU VERITAS
Import SOCOTEC
Les verticalisations :
- FACILITY
- SANTE
- TRANSPORT
- CITY

Cette intégration implique des adaptations fonctionnelles afin de mixer les addons sans conflit au sein d’une seule installation. La suppression de données standards et l’adaptation de principes de fonctionnements spécifiques de verticalisations a été nécessaire.

L’objectif des évolutions technico-fonctionnelles est la migration de l’application en mode Saas. Elle permettra à terme de simplifier la complexité de la maintenance, de la migration et le déploiement de la solution.
Le contenu du produit CARL Source en version 7.2.0 passe d’une 100^aine de distributions à un 50^aine.

Un Nouveau visuel de la page de login est mis en place afin de tenir compte du design BL CARL générique et exprimer l’aspect multi-métiers de l’application pour toute nouvelle installation. L’image est modifiable à partir du détail du document image de la bibliothèque.

La majorité des valeurs des listes de valeurs ajoutées par les addons ont été supprimées ou ne sont plus indiquées comme valeurs standard non modifiables.
En migration, ces éléments sont rendus non-standard mais ne sont pas supprimés.

L’ensemble des fonctionnalités dédiées à des verticalisations sont intégrées au produit.

Le profil par défaut proposé dans l’application autorise toutes les fonctionnalités des verticalisations. Il est alors plus simple de personnaliser un nouveau profil issu du profil Standard en désactivant en masse les autorisations, au lieu de chercher et activer les fonctionnalités une par une.

La notion de domaine métier lié aux labels à évoluée afin de rendre compatible la coexistence des différents contextes métiers sur une même instance de l’application. On parle maintenant de Vocabulaire métier.

Dans le cas d’une mise à jour vers la version 7.2.0.
Si l’environnement à mettre à jour contient l’add-on City ou Transport, des actions seront à mener après la mise à jour en 7.2.0.

Cas de l’add-on City
Dans les versions précédentes, l’add-on City était configuré avec un vocabulaire lié à une verticalisation (Factory, Facility, Transport ou Santé).
En version 7.2.0, l’add-on City a été intégré au standard avec un seul vocabulaire, celui de Facility.
Si l’environnement à mettre à jour utilise un autre vocabulaire, celui-ci sera écrasé par le vocabulaire Facility. Par exemple, une "Demande d’intervention" (vocabulaire Factory) sera nommée en 7.2.0, "Demande de travaux".
Il est néanmoins possible de personnaliser (manuellement) les libellés pour revenir au vocabulaire précédent.

Cas de l’add-on Transport
Lors de la mise à jour en version 7.2.0, un processus modifie automatiquement les formulaires personnalisés liés à la verticalisation Transport pour prendre en compte l’intégration dans le standard.
Ce mécanisme ne peut néanmoins pas prévoir toutes les spécificités de personnalisation, il est est donc impératif de contrôler, à l’issue de la mise à jour, l’ensemble des formulaires Transport et de les corriger si nécessaire.

3.2.1. Addon Control-S

Le déploiement des Addons ajoutait précédemment la configuration des imports de rapports de contrôles par l’intermédiaire de la création d’un fournisseur au nom du prestataire de rapports de contrôle (BV ou SOCOTEC).

Suite à l’intégration des addons BUREAU VERITAS et SOCOTEC dans l’application, une nouvelle installation de CARL Source ne doit pas imposer par défaut des données fournisseurs spécifiques. Ça ne sera plus le cas.
Dorénavant, la création d’un fournisseur et de sa configuration pour les prestataires BV et SOCOTEC se fera comme pour n’importe quel autre prestataire de contrôle, à l’initiative des clients.

Seuls les éléments techniques tels que les traitements, points de connexions et gestions d’erreurs sont intégrés par défaut dans le standard. Ils sont utilisables dans la configuration de ces 2 prestataires.

L’aide en ligne détaille les configurations par défaut de ces prestataires ainsi qu’une documentation dédiée du service projet.

3.2.2. Addon CNEH

Cet addon ajoutait les données CNEH de type Points principaux et/ou arborescence de Familles et/ou natures d’achats spécifiques concernant le domaine santé (francophone).
Ces données ne sont plus disponibles en addon mais ont été adaptées pour un chargement par interface XML standard de l’application. Elles sont disponibles en Fiche de connaissance sur le site support à la disposition des clients intéressés.

3.2.3. Addon verticalisation métier

Les addon verticalisations qui configuraient l’application dans un domaine métier unique ont été adaptés et intégrés au produit standard. Ils n’étaient pas compatibles entre eux. Au déploiement, ils spécifiaient l’application de façon dédiée à un contexte métier en modifiant définitivement la configuration globale du déploiement pour l’ensemble des utilisateurs et process.

L’approche Saas, pour un seul et même produit déployé contenant l’ensemble des contextes, nécessite la personnalisation d’un contexte métier à travers le paramétrage .
Les addons verticalisations ont donc été adaptés afin de s’intégrer et être compatibles entre eux, offrant la possibilité de mixer les contextes métiers sur un seul déploiement.

CARL Source peut être décliné dans différents contextes métiers et comporte des éléments de personnalisation préparés, à activer selon le besoin.
L’utilisateur va porter le contexte métier au travers d’éléments de personnalisation : Navigation, écrans, vocabulaire, droits de profils.

Certaines de ces personnalisations ne nécessitent qu’une simple configuration de l’utilisateur tandis que d’autres requièrent en plus la configuration d’éléments transverses, impactant l’ensemble des utilisateurs.

L’application dispose d’éléments préconfigurés permettant la mise en œuvre rapide de ces personnalisations au travers des données Utilisateur :

les nouveaux groupes de personnalisation standards dédiés à un contexte métier
les vocabulaires métier.

Il reste possible de dédier une instance complète de l’application à un contexte métier en remplaçant l’utilisation du groupe de personnalisation par l’activation "public" des formulaires personnalisés dédiés ainsi que le thème couleur général. Le vocabulaire métier et droits de profils reste à configurer sur l’utilisateur.

3.2.3.1. Facility

3.2.3.1.1. Personnalisation d’un utilisateur afin de porter le contexte Facility

Sur un utilisateur dédié Facility, il est nécessaire de renseigner au minimum :

le vocabulaire métier « Facility »,
le groupe de personnalisation standard « FACILITY » concernant les formulaires, menus, thème couleur et visuels de ce contexte standardisé utilisé lors du parcours utilisateur.
si nécessaire, un nouveau profil spécifique issu du profil standard, en ayant retiré l’accès aux fonctionnalités hors contexte Facility et/ou non utiles.

3.2.3.1.2. Personnalisation des éléments transverses de l’application (optionnel)

Si l’application entière est uniquement dédiée au contexte Facility, il est conseillé de renommer le code de structure équipement « PRINCIPAL » en « LOT_TECHNIQUE » pour plus de cohérence avec le libellé personnalisé (Vocabulaire métier) de cette structure. Cette surcharge spécifique précédemment appliquée au déploiement ne peut plus être appliquée, on garde les valeurs standards.

3.2.3.2. Santé

3.2.3.2.1. Personnalisation d’un utilisateur afin de porter le contexte Santé

Sur cet utilisateur dédié santé, il est nécessaire de renseigner au minimum :

le vocabulaire métier « Santé »,
le groupe de personnalisation standard « HEALTHCARE » concernant les formulaires, menus, thème couleur et visuels de ce contexte standardisé utilisé lors du parcours utilisateur.
si nécessaire, un nouveau profil spécifique issu du profil standard, en ayant retiré l’accès aux fonctionnalités hors contexte Facility et/ou non utiles.

3.2.3.2.2. Personnalisation des éléments transverses de l’application (optionnel)

Si l’application entière est uniquement dédiée au contexte Facility, il est conseillé de renommer le code de structure équipement « MATERIAL » en « INVENTAIRE » pour plus de cohérence avec le libellé personnalisé (Vocabulaire métier) de cette structure. Par défaut, cette surcharge de code, appliqué au déploiement de l’addon, ne peut plus être joué : on garde les valeurs standards.

3.2.3.3. City

Dans les précédentes versions de l’application, City était déployé avec une surcharge possible d’un autre verticalisation.
Dorénavant, le contexte métier City est géré comme tout autre domaine métier avec les spécificités de l’Addon FM.

Le nouveau vocabulaire métier City est composé des vocabulaires de la version 7.1.0 CITY et FACILITY.

3.2.3.3.1. Personnalisation d’un utilisateur afin de porter le contexte City

Sur cet utilisateur dédié city, il est nécessaire de renseigner au minimum :

le vocabulaire métier « City »,
le groupe de personnalisation standard « CITY » concernant les formulaires, menus, thème couleur et visuels de ce contexte standardisé utilisé lors du parcours utilisateur.
si nécessaire, un nouveau profil spécifique issu du profil standard, en ayant retiré l’accès aux fonctionnalités hors contexte Facility et/ou non utiles.

3.2.3.3.2. Personnalisation des éléments transverses de l’application (optionnel)

Concernant la gestion financière publique à l’aide de budgets en cascades, il peut être nécessaire d’activer les formulaires personnalisés standard de type « CUSTOMER ». Cette activation permet de bénéficier de tous les mécanismes liés à ce contexte concernant les processus ACHAT tel que Demande d’achat et Commande.

3.2.3.4. Transport

Cette verticalisation métier proposait un grand nombre d’écrasements de données et de comportements spécifiques standards suite à son déploiement.

Une refonte technico-fonctionnelle importante a été entreprise afin de traduire les comportements de navigation et les spécificités autour des matériels Roulants et Fixes sans pour autant modifier le comportement standard de CARL Source.

Cette évolution permet de paramétrer des groupes de Matériels spécifiques de façon standard, de les modifier, voir les adapter à un contexte autre que Transport si nécessaire.

Lors de la migration d’un client Transport, il faudra à vérifier les paramètres renseignés et le bon fonctionnement de l’application migrée.

3.2.3.4.1. Personnalisation d’un utilisateur afin de porter le contexte Transport

Sur cet utilisateur dédié transport, il est nécessaire de renseigner au minimum :

le vocabulaire métier « City »,
le groupe de personnalisation standard « CITY » concernant les formulaires, menus, thème couleur et visuels de ce contexte standardisé utilisé lors du parcours utilisateur.
si nécessaire, un nouveau profil spécifique issu du profil standard, en ayant retiré l’accès aux fonctionnalités hors contexte Facility et/ou non utiles.

3.2.3.4.2. Personnalisation des éléments transverses de l’application (obligatoire)

Dans le contexte Transport proposé par défaut, certains paramètres de modules sont à activer afin d’exploiter les mécanismes liés à ce contexte.

Ce paramétrage modifiera de façon transverse le comportement général de l’application pour tous les utilisateurs.

Les nouveaux paramètres de modules EqptTypeGroup1 et EqptTypeGroup2 sont à configurer respectivement avec les groupes de types d’équipements « Fixe » et « Roulant » (valeurs personnalisables si nécessaire). Ceci modifie le comportement de l’application envers les matériels mobiles et fixes mais également correspond aux formulaires personnalisés transport proposés en standard. Ce paramètre est effectif pour l’ensemble des utilisateurs de l’application.

Dans les profils d’utilisateurs, il est possible alors d’ajouter des droits pour faire apparaitre des menus de créations spécifiques pour les matériels, demandes d’intervention et interventions adaptés à ces valeurs spécifiques.

Lors de la création d’interventions ou demandes d’intervention, si une valeur de "catégorie de travail" (attribut "workCategory" de WO ou MR) est identique à une des valeurs de paramètres de modules renseignés (EqptTypeGroup1 et EqptTypeGroup2) et que le matériel associé est d’un type d’équipement appartenant à ce même groupe, alors le champ catégorie de travail sera initialisé par cette même valeur.
La recherche d’interventions ou de demandes d’intervention concernée par un des groupes de type d’équipement d’un matériel est alors possible en recherchant celui-ci directement sur le champ "catégorie de travail" (workCategory).

Pour la migration de version, les formulaires basés sur les formulaires spécifiques « Fixe » et « Roulant » seront automatiquement adaptés pour correspondre aux formulaires liés aux Matériels spécifiques du groupe 1 pour les "Fixe" et du groupe 2 pour les "Roulant".
Les 2 paramètres de modules seront également renseignés par « Fixe » et « Roulant » automatiquement.

3.2.3.5. Factory

CARL Source standard est la déclinaison Factory.

Aucun élément de personnalisation est nécessaire pour visualiser le contexte métier : Vocabulaire standard, pas de groupe de personnalisation.
Seul le profil est à adapter comme habituellement.

3.2.4. Vocabulaire métier

La notion de domaine métier progresse pour devenir un vocabulaire métier et définir un contexte métier à part entière.
Il n’y a plus d’écrasement de termes de vocabulaire qu’impliquait l’installation des addons Verticalisés.

Avant la version 7.2.0, certaines données standards étaient teintées du vocabulaire métier propre à l’addon installé.
Par conséquent, même les utilisateurs n’étant pas configuré pour le "Domaine métier" de l’addon voyaient ces données avec le vocabulaire métier propre à l’addon installé.

À partir de la v7.2, ces mêmes utilisateurs avec un "Domaine métier" par défaut (renommé "Vocabulaire métier" dans cette version) verront ces données avec le vocabulaire métier par défaut.
Seuls les utilisateurs configurés avec le "Vocabulaire métier" de l’addon verront ces données avec le vocabulaire métier propre à l’addon installé.

Exemple : le modèle de message TMPL_MRTRANSFER

Avec l’addon FM, le modèle de message TMPL_MRTRANSFER utilisé lors du transfert d’une demande d’intervention est vu avec ce libellé en fonction du contexte et des versions :

Jusqu’en 7.1.0
Utilisateur avec Domaine métier 'Défaut' : Transfert de DT
Utilisateur avec Domaine métier 'Facility' : Transfert de DT

À partir de 7.2.0
Utilisateur avec Domaine métier 'Défaut' : Transfert de DI
Utilisateur avec Domaine métier 'Facility' : Transfert de DT

3.2.5. Matériels spécifiques

3.2.5.1. Principe et paramétrages

Afin d’intégrer la spécificité des matériels Roulant et Fixe de l’addon Transport dans l’application standard et rendre son utilisation plus générique, la notion de matériels spécifiques a été ajoutée et est configurable par simple paramétrage.

La configuration des matériels spécifiques est transverse à toute l’application et n’est pas réservée à l’utilisateur connecté.

L’administrateur va pouvoir définir jusqu’à 2 groupes de types d’équipements matériels qui doivent être traités de manière différente dans l’application par rapport au reste des matériels.

La configuration d’un ensemble de types d’équipement de matériel spécifique se fait dans les paramètres de modules (section équipements) avec les paramètres :

EqptTypeGroup1 - Groupe 1 de types d’équipements pour les matériels spécifiques ( FIXE pour contexte métier Transport)
EqptTypeGroup2 - Groupe 2 de types d’équipements pour les matériels spécifiques ( ROULANT pour contexte métier Transport)

Une fois ces groupes de types d’équipements définis, l’administrateur peut agir sur les profils afin de configurer pour les fonctionnalités Matériel, DI, Intervention et Compte-rendu d’intervention les droits suivants :

Afficher le menu de création d’équipements du groupe 1 des types équipements spécifique,
Afficher le menu de création d’équipements du groupe 2 des types équipements spécifique,
Autoriser le menu de création des matériels autres que ceux du groupe spécifique. (A vrai par défaut)

3.2.5.2. Comportement dans l’application

Lors de la création via menu spécifique ou de l’accès au détail d’un matériel spécifique d’un des groupes défini, d’une Demande d’intervention, d’une intervention, d’un Compte rendu d’intervention lié à un matériel spécifique, l’application affiche :

le formulaire personnalisé pour ce groupe de matériels spécifiques s’il existe, avec l’IZ "matériel" ou le champ "type d’équipement" rendu obligatoire et filtré sur les éléments du Groupe
sinon le formulaire personnalisé (si existant) de l’entité en modifiant l’IZ "matériel" ou le champ "type d’équipement" rendu obligatoire et filtré sur les éléments du Groupe
alors sinon le formulaire standard en modifiant dynamiquement l’IZ "matériel" ou le champ "type d’équipement" rendu obligatoire et filtré sur les éléments du Groupe.

Dans une des entités impactées, si le détail affiché est standard et que le champ matériel ou type équipement est renseigné (ou modifié) par un élément du groupe 1 ou 2 des matériels spécifiques, le système propose alors d’adapter l’écran de détail en rechargeant le formulaire dédié au matériel spécifique concerné.

L’existence de formulaires personnalisés pour la gestion de matériels spécifiques n’est pas obligatoire.
Par défaut, l’application affichera le formulaire standard modifié dynamiquement au niveau des champs Type équipement ou matériel si nécessaire.

Pour personnaliser un formulaire spécifique pour l’une des fonctionnalités liées aux matériels spécifiques, une entrée de menu avec la référence au Groupe 1 ou Groupe 2 est disponible dans la configuration des formulaires personnalisés concernant le champ "Formulaire".

3.3. Ajustements ergonomiques

Les ajustements ergonomiques suivants ont été réalisés sur la version 7.0.0 :

Mise en place de la police Poppins,
Changement des couleurs des 3 zones de l’application :
- Zone de gauche : Menu,
- Zone de droite : Documents liés et commentaires,
- Zone du haut : Entête de l’application.

Figure 1. Couleurs des 3 zones

Nouveau style pour les onglets et sous onglets :

Figure 2. Nouveau style pour les onglets et sous onglets

Ajouter l’infobulle avec le nom du module au survol des icônes du menu :

Figure 3. Infobulle au survol des modules du menu

Ajouter sur les champs de type "Montant", le montant complet sans arrondi dans l’infobulle,

Figure 4. Montant complet (sans arrondi) au survol des champs de type "Montant"

Adapter le style des graphiques au thème de CARL Source :

Figure 5. Couleurs des graphiques de la page d’accueil

Augmenter le contraste de la ligne sélectionnée dans les listes,

Figure 6. Contraste marqué de la ligne sélectionnée

Mise à jour du témoin de chargement :

Figure 7. Barre de chargement

3.4. Affectation automatique des ressources

L’affectation automatique des ressources s’appuie sur un "solveur de contraintes" se basant sur un algorithme non déterministe dont le but est de proposer l’assignation d’intervenants et de moyens matériels pour tout(es) les intervention(s) sélectionné(es) et qui correspondent aux critères d’assignations définis au niveau du moteur d’affectation.

L’action d’affectation automatique des ressources n’est accessible que si vous disposez du droit de profil "Lancer l’affectation automatique des ressources" et que l’utilisateur possède le droit de modification sur les interventions.

3.4.1. Fonctionnement général du solveur de contraintes

Lorsque le solveur commence sa recherche de solutions, rien ne lui indique comment et quand il devra s’arrêter. Afin de trouver un équilibre entre la qualité de la solution générée et le temps d’exécution nécessaire à la recherche d’une solution acceptable, un mécanisme d’arrêt est paramétré.

Ce mécanisme permet d’observer l’évolution qualitative des solutions proposées par le solveur. Chaque solution générée est évaluée et se voit attribuer un score selon plusieurs critères. Le mécanisme d’arrêt de l’optimisation va observer l’évolution des scores attribués à chaque solution.

L’amélioration des solutions étant de plus en plus difficile au cours du temps, si aucune solution générée ne surpasse la meilleure solution trouvée pendant une durée (définie dans les paramètres de modules) alors l’optimisation s’arrêtera.

3.4.2. Contraintes de pondération

3.4.2.1. Contraintes fortes

L’affectation d’un intervenant à une ressource doit se faire en respectant les disponibilités du technicien,
Un intervenant ne peut pas être affecté à plusieurs ressources en même temps,
L’affectation est bornée par les dates de l’intervention,
L’affectation doit respecter l’équipe et/ou la spécialité et/ou l’intervenant renseigné.

3.4.2.2. Contraintes faibles

Utiliser le moins d’intervenants possibles.
Privilégier l’heure exacte définie. En revanche des solutions sont également évaluées avec des horaires autour de l’heure définie tout en minimisant le score de la solution. Le paramétrage se réalise au travers les paramètres de modules (WO_OPTA_PERIOD, WO_OPTA_STEP).

Une solution doit respecter toutes les contraintes fortes. Les contraintes faibles quant à elles permettent de minimiser ou maximiser le score de la solution.

3.4.3. Contraintes de lancement

Pour que l’affectation automatique des ressources puisse se lancer pour toutes les interventions sélectionnées, il faut qu’elles répondent aux contraintes suivantes :

L’intervention doit être dans un état appartenant à une famille d’états différente de TERMINER / SOLDER / ARCHIVER / ANNULER.
Pour chaque ligne de main d’oeuvre ou moyen matériel souhaité(e), il est nécessaire de renseigner :
- Au moins une équipe et/ou spécialité et/ou intervenant,
- Une date et heure,
- Une durée.
Les calendriers des intervenants doivent être renseignés.

A chaque lancement de l’action "Affectation automatique des ressources", un identifiant unique est généré et est associé à l’ensemble des données modifiées (intervention, lignes Main d’oeuvre et moyen matériel). Cette information est disponible en base de données et permet un meilleur suivi.

3.4.4. Scénarios

Renseigner les données de l’intervention en respectant les contraintes,
Lancer l’action "Affectation automatique des ressources",

Figure 8. Action de lancement de l’affectation automatique des ressources

un message informe du lancement de l’action en mode asynchrone et de la génération d’un mémo à la fin du traitement,

Figure 9. Message de lancement de l’affectation automatique des ressources

A la fin du traitement en mode asynchrone, un mémo est généré permettant de connaître le statut de l’affectation automatique :
- Affectation Automatique Terminée : ce type de mémo apparait lorsque l’affectation automatique a pu réaliser une affectation automatique pour au moins une intervention. Un lien permet d’ouvrir la liste des interventions où une affectation a pu être réalisée.

Figure 10. Mémo d’affichage du résultat Affectation automatique terminée

Affectation Automatique Impossible : ce type de mémo apparaît lorsque l’affectation automatique n’a pas pu réaliser d’affectation pour toutes les interventions soit à cause des contraintes de lancement non renseignées, soit à cause d’aucune solution trouvée.

Figure 11. Mémo d’affichage du résultat Affectation automatique impossible

New 7.1

CARL Source pourra être utilisé dans un environnement multidevise. Des utilisateurs travaillant dans des pays avec des devises différentes pourront utiliser un unique CARL Source. Le fonctionnement détaillé sera décrit dans le chapitre Gestion du multidevise.

3.5. Gestion du multidevise

3.5.1. Généralités

New 7.1

Si CARL Source est utilisé dans un contexte international, c’est-à-dire par des utilisateurs présents dans différents pays, travaillant dans différentes devises, il est possible d’utiliser le même environnement CARL Source dans les différents pays.

Pour chacun des utilisateurs / acteurs, l’administrateur peut sélectionner une autre devise, parmi celles définies comme étant des devises "multidevises". De cette manière, lors de sa connexion à CARL Source, l’utilisateur travaillera avec sa devise. On la nomme devise de contexte.

La devise de contexte de l’utilisateur est visible dans la zone utilisateur du bandeau.

Figure 12. Affichage de la devise dans le bandeau utilisateur

La devise de contexte correspond à la devise de référence indiquée dans la configuration du système lorsque CARL Source est utilisé dans un environnement monodevise.

3.5.1.1. Changement à la volée

En dépliant le bloc accessible par clic sur le nom de l’utilisateur connecté (en haut à droite), la liste déroulante donne accès à une liste de devises. Cette liste permet à l’utilisateur de basculer dynamiquement entre différentes devises considérées comme "multidevises". La sélection d’une autre devise change à la volée la devise de contexte.

Dans le cas où la devise de contexte est différente de la devise de l’entité et pour faciliter la compréhension des montants affichés, le montant converti dans la devise de contexte est visible dans l’infobulle s’affichant au survol d’un champ de type "montant". Il s’agit d’une donnée informative prenant le taux de change à l’instant T pour réaliser la conversion.

Lors de sa prochaine connexion à CARL Source, l’utilisateur sera de nouveau sur la devise renseignée sur sa fiche utilisateur.

3.5.1.2. Consultation d’une entité

Dans les formulaires de recherche ainsi que le formulaire de détail d’une entité, les données de type "montant" sont affichées dans la devise de l’entité.

Dans certains formulaires spécifiques comme les commandes et les DA, les données sont affichées dans la devise de l’entité mais également dans la devise de contexte pour une meilleure compréhension.

En création ou en consultation, la devise d’une entité est affichée dans la zone supérieure du détail.

Figure 13. Affichage de la devise dans l’entête d’un détail

3.5.1.3. Création d’une entité

A la création d’une nouvelle entité, celle-ci est automatiquement initialisée dans la devise de contexte de l’utilisateur. En revanche, la devise de certaines entités peut évoluer lorsque l’on sélectionne certaines informations dans le formulaire.
La description détaillée des entités est décrite dans le chapitre Description des entités dépendantes.

3.5.1.4. Modification de la devise d’une entité

Les règles applicables pour permettre la modification d’une devise sur une entité sont définies dans le chapitre Modifier la devise d’une entité maître.

Une fois la modification de devise réalisée :

Les données en consultation sont converties dans la nouvelle devise en appliquant le taux de change adéquat.
Les données en saisie prennent en compte la nouvelle devise mais la valeur saisie n’est pas convertie et reste identique. Si la valeur n’est plus en cohérence avec la nouvelle devise alors l’utilisateur devra modifier la valeur dans le champ.

Pour les opérations liées à une intervention, le changement de devise sur l’intervention entraine un recalcul dans la nouvelle devise du prix unitaire présent dans le détail d’une opération.

3.5.1.5. Recherche

Afin de ne pas surcharger les écrans de recherche, la champ "devise" n’est pas automatiquement ajouté sur les écrans correspondant à des entités porteuses de devise. En revanche, le mécanisme a été mis en place. Il est donc très simple de rajouter le champ devise sur un formulaire de recherche en passant par la fonction de personnalisation.

Se positionner sur le formulaire de recherche et sélectionner l’action "Entrer dans le mode personnalisation",
Ajouter un champ et saisir l’expression #{formAnimator.searchBean.currencyCode} dans l’attribut "valeur",
Ajouter, si besoin, la liste de valeur "CURRENCY" dans l’attribut "infozone" pour obtenir l’aide à la saisie au travers de la mise en place de la loupe.

3.5.2. Devise et taux de change

La fonctionnalité « Devise » permet de déclarer l’ensemble des devises nécessaires pour gérer le contexte des fournisseurs internationaux mais également pour gérer le contexte multidevise des utilisateurs de CARL Source.
Pour qu’une devise soit considérée multidevise, il est nécessaire de cocher la case multidevise dans la fonctionnalité.
Cette option est soumise au droit de profil CARL Source/Global/Gérer l’environnement multidevise.

Une fois l’enregistrement d’une nouvelle devise (standard ou multidevise) réalisée, la mise à jour des taux de change est proposée dans la foulée afin de faciliter la mise à jour (initialisé à 1 ou mise à jour manuellement par l’utilisateur).

La devise de référence est cochée par défaut comme devise multidevise. Elle ne peut donc pas être décochée.

Une devise enregistrée ne peut pas être supprimée. En revanche, si elle n’est plus utilisée, il est possible de la désactiver afin que celle-ci ne soit plus visible dans les listes déroulantes proposant un choix de devises.

3.5.3. Définition des types d’entités

3.5.3.1. Description des entités maître

Les entités maître sont des entités possédant des champs de type montant et dont l’entité est responsable de sa propre devise.
Ci-dessous la liste des entités maître :

Article
Budget
Client
Centre de coût
Contrats Locatifs
DI
Fournisseur
Localisation
Magasin
Matériel
Modèle / Article défini comme "Modèle"
Modèle de projet (si la case Centre de coût unique? n’est pas cochée)
Modèle de point de mesure
Nature d’achat
Point de structure
Profil
Spécialité
Types d’opération

3.5.3.2. Description des entités dépendantes

Les entités dépendantes sont des entités possédant des champs de type montant et dont la devise dépend d’une entité maître.
Ci-dessous la liste des entités dépendantes :

Commande : la devise dépend de la devise du fournisseur.
Contrat : la devise dépend de la devise du fournisseur.
Demande d’achat : la devise dépend de la devise du fournisseur (si ce dernier est renseigné).
Demande de transfert : la devise dépend de la devise du magasin demandeur.
Devis : la devise dépend de la devise du client.
Facture : la devise dépend de la devise du fournisseur.
Gamme : la devise dépend de la devise du centre de coût.
Intervenant : la devise dépend de la devise de la spécialité.
Intervention : la devise dépend de la devise du centre de coût.
Modèle de projet : la devise dépend de la devise du centre de coût si la case Centre de coût unique? est cochée.
Moyen matériel : la devise dépend de la devise de la spécialité.
Point de mesure : la devise dépend de la devise d’un modèle de point de mesure.

3.5.4. Règles fonctionnelles

Des règles fonctionnelles permettant de contrôler la cohérence des devises ont été mises en place dans l’application.

3.5.4.1. Règles générales

Budget : cohérence de devise entre le budget et le budget père.
Centre de coût : cohérence de devise entre le centre de coût et le centre de coût père.
Client : cohérence de devise entre le client et le client père
Demande de transfert : cohérence de devise entre le magasin demandeur et le magasin fournisseur.
Modèle / Article défini comme "Modèle" : cohérence de devise entre le modèle et l’article défini comme "modèle" associé. La mise à jour du modèle met à jour l’article associé et vice versa.

L’ensemble de ces contrôles ont été réalisés niveau backend afin qu’ils puissent être appliqués lors de traitements comme les interfaces ou les API REST.

3.5.4.2. Règles spécifiques au PMP par organisation

Les règles et contrôles ci-dessous sont réalisés lorsque le paramétrage Type de valorisation du stock = "PMP par organisation" est mis en place dans l’application.

3.5.4.2.1. Magasin

Tous les magasins d’une même organisation doivent avoir la même devise.
Tous les magasins sans organisation doivent avoir la même devise.

3.5.4.2.2. Article

Les magasins associés à l’article géré en stock dans les onglets approvisionnement et détail de stockage peuvent avoir des devises différentes. En revanche :

Les lignes de stockage sur des magasins possédant la même organisation auront obligatoirement le même PMP.
Les lignes de stockage sur des magasins ne possédant pas d’organisation auront obligatoirement le même PMP.

3.5.4.3. Règles spécifiques au PMP Global

Les règles et contrôles ci-dessous sont réalisés lorsque le paramétrage Type de valorisation du stock = "PMP global" est mis en place dans l’application.

3.5.4.3.1. Article

Les magasins associés à l’article "géré en stock" dans les onglets approvisionnement, détail de stockage et catalogue doivent être dans la même devise que l’article. Un contrôle a été rajouté pour que seulement les magasins en cohérence soient proposés.

3.5.4.3.2. Fournisseur

Le magasin associé à un lien fournisseur/article dans l’onglet catalogue doit être en cohérence avec la devise de l’article.

3.5.4.3.3. Mouvements de stock

Les magasins proposés dans ces fonctionnalités doivent être en cohérence avec la devise de l’article.

3.5.4.4. Règles spécifiques du Réapprovisionnement par magasin

Sur la fiche article, lors de la création d’une ligne d’approvisionnement de type recomplètement, un contrôle de cohérence de devise est réalisé entre le magasin demandeur et le magasin fournisseur. Le contrôle appliqué est le même que celui réalisé sur les demandes de transfert.

3.5.5. Modifier la devise d’une entité maître

La devise des entités maître peut être modifiée à tout moment dans CARL Source si :

Le droit de profil CARL Source/Global/Modifier la devise des entités est activé,
Les règles fonctionnelles autorisant la modification sont respectées.

La modification peut se réaliser au travers la liste ou le détail de l’entité souhaitée à partir de l’action "Modifier la devise" présente sous l’icône des actions disponibles.

Dans le cas où les règles fonctionnelles ne sont pas respectées, l’action "Modifier la devise" n’est pas accessible dans le détail de l’entité.

3.5.5.1. Description des règles fonctionnelles contrôlées

Ce chapitre décrit les règles fonctionnelles à contrôler pour accéder à l’action "Modifier la devise" "en détail et en liste.

DI : Aucune règle fonctionnelle à contrôler.
Famille : Aucune règle fonctionnelle à contrôler.
Localisation : Aucune règle fonctionnelle à contrôler.
Matériel : Aucune règle fonctionnelle à contrôler.
Nature d’achat : Aucune règle fonctionnelle à contrôler.
Point structure : Aucune règle fonctionnelle à contrôler.
Profil : Aucune règle fonctionnelle à contrôler.
Budget : Aucune écriture n’a été réalisée sur le budget concerné. Le budget ne possède ni d’ascendants, ni de descendants.
Centre ce coût : Aucune écriture n’a été réalisée sur le centre de coût concerné. Le centre de coût ne possède ni d’ascendants, ni de descendants.
Client : Aucune condition n’est renseignée sur le client dans l’onglet "Conditions". Ne pas avoir le champ "Client père" de renseigné, ni de devis associé à ce client.
Contrat Locatif : Aucune ligne de quittancement n’est liée au contrat locatif.
Magasin : Aucun mouvement de stock (quel que soit le type de mouvement) n’existe sur ce magasin.
Modèle d’un point de mesure : Aucun point de mesure n’est associé à ce modèle de point de mesure.
Point de mesure : Aucun relevé de mesure ne doit être réalisé sur ce point de mesure. Ne pas avoir le champ "Modèle de point de mesure" de renseigné.
Spécialité : Aucun moyen matériel ou/et aucun intervenant ne sont liés à cette spécialité.

3.5.6. Modifier la devise d’une entité dépendante

Concernant les entités dépendantes, la devise d’une entité peut changer à partir du moment où l’on change l’entité maître dont dépend l’entité dépendante et que cette dernière à une devise différente (Description des entités dépendantes).

3.5.6.1. Intervention

Lors du changement d’un centre de coût, un mécanisme de désengagement sur l’ancien centre de coût et de réengagement sur le nouveau centre de coût se réalisera en prenant le taux de change à la date du jour pour réaliser la conversion.

Pour les opérations liées à une intervention, le changement de devise sur l’intervention entraîne un recalcul dans la nouvelle devise du prix unitaire présent dans le détail de l’opération.

3.5.6.2. Fournisseur

La devise d’un fournisseur est modifiable tant qu’aucun catalogue et/ou contrat et/ou achat ne sont liés à ce fournisseur et ceci quel que soit l’état d’un achat.

Si vous souhaitez modifier la devise d’un fournisseur lié à un achat (commande, demande d’achat) annulé, il est tout d’abord nécessaire de supprimer l’achat annulé au travers de la fonctionnalité adéquate.

3.5.7. Interfaces

CARL Source propose en standard un certain nombre d’interfaces xml. Les interfaces ont évolué pour ajouter la notion de devises.

3 cas peuvent exister pour les interfaces XML :

La devise est renseignée au niveau d’une entité possédant un attribut de type "Montant".
la devise est non renseignée au niveau d’une entité possédant attribut de type "Montant".
La devise est non renseignée au niveau d’une entité possédant un attribut de type "Montant" mais on souhaite forcer la devise.

Pour les interfaces CSV, une nouvelle version de la norme a été créée.

3.5.8. Rapports

3.5.8.1. Rapports standards

L’ensemble des rapports standards possédant des notions de devises ont été mis à jour. La devise est dorénavant présente à coté de chaque champ monétaire.

Selon les rapports, les informations sont affichées dans:

La devise de l’entité
La devise de contexte.

Dans le cas où les rapports réalisent des agrégations dans des devises différentes de la devise de l’entité alors le libellé correspondant à l’agrégation affiche la date et l’heure de la génération du rapport. De cette manière, il est beaucoup plus simple de retrouver le taux de change appliqué.

3.5.8.2. Rapports personnalisés

Les rapports personnalisés antérieurs à la version 7.7.0 doivent être repris :

Si les rapports s’appuient sur des requêtes faisant des liens avec la table des devises. Dans ce cas, il est nécessaire de faire une mise à jour au niveau de la requête.
Si les rapports sont utilisés dans un environnement multidevise. Dans ce cas, il faut utiliser les nouvelles méthodes disponibles dans l’outil BIRT Designer.

New 7.1

Les fonctions de conversion sans la devise affichée :

Conversion d’un montant dans une devise cible : changeAmountToCurrency (montant, devise source, devise cible, date de valorisation)
Conversion d’un montant dans la devise de contexte : changeAmountToContextCurrency(montant, devise source, date de valorisation)

Les fonctions de conversion formatées avec la devise :

Formatage d’un montant dans sa devise : formatAmount(montant, devise du montant)
Formatage d’un montant dans une devise cible : formatAmountToCurrency(montant, devise source, devise cible, date de valorisation)
Formatage d’un montant dans la devise de contexte : formatAmountToContextCurrency(montant, devise source, date de valoration)

Autres fonctions BIRT multidevises :

Symbole monétaire d’une devise : getCurrencySymbol(devise)
Devise de contexte : getContextCurrency()

La date de valorisation n’est pas obligatoire dans ces fonctions. Si elle n’est pas renseignée, le taux de change utilisé pour les conversions sera celui de la date/heure du jour.

Les rapports personnalisés utilisés dans un environnement monodevise fonctionnent sans avoir besoin de reprendre les fonctions BIRT. En revanche c’est une bonne pratique de les mettre à jour.

3.5.8.3. Assistant de rapport

Au travers de l’assistant de rapport, il est possible de rajouter une nouvelle colonne possédant le code de la devise associé à un montant. En revanche, aucune évolution n’a été réalisée pour agréger des montants ayant des devises différentes.
Dans le cas où des totaux peuvent être réalisés sur des devises différentes, il est nécessaire de faire, en premier lieu, un regroupement par code devise.

3.5.9. Indicateurs

Les indicateurs standards possédant des données monétaires s’utilisent uniquement dans un environnement monodevise. Aucun indicateur n’a été repris pour agréger des montants ayant des devises différentes.

3.6. Energie et fluide

New 7.2

Le thème énergie est une nouveauté.

L’utilisation de cette fonctionnalité nécessite l’acquisition de droits complémentaires.
En savoir plus sur l’option "CARL Energy".

Pour plus d’informations, contacter CARL Berger-Levrault.

3.6.1. Type de compteur

Le type de compteur permet de classer les différents points énergie. Les informations définies au niveau du type de compteur permettent de faciliter la création d’un point énergie en initialisant certaines informations (centre de coûts, type de coûts, type d’énergie etc).

Des icônes standards pour chaque type d’énergie ont été ajoutées dans la bibliothèque CarlSource.

Le type de coût "énergie" a été ajouté à la liste de valeurs COSTTYPE pour traiter les coûts analytiques de type "énergie et fluide".

3.6.2. Point énergie

Le point d’énergie permet de regrouper en un seul endroit l’ensemble des informations liée au domaine de l’énergie et des fluides. Vous pouvez notamment suivre la consommation ainsi que les coûts engendrés par les différentes énergies utilisées sur les équipements.

Le détail d’un point énergie contient des données générales (fournisseur, distributeur, N° abonnement), des informations sur les points de mesure associés ainsi que les factures d’énergie liées.

Afin de répondre aux contraintes du décret tertiaire, les attributs "Décret tertiaire : année de référence" et "Décret tertiaire : consommation de référence" sont disponibles dans le dictionnaire. Il est possible de les ajouter facilement en personnalisation pour les faire apparaître sur le détail d’un bâtiment ou d’un site.

3.6.2.1. Général

Le point énergie peut être lié à un équipement CARL (Localisation, Point de Structure, Matériel), ce qui permettra de visualiser les informations sur l’énergie directement au travers de la fiche équipement.
Le point de mesure de facturation correspond au point de mesure principal lié au point énergie. Ce dernier est également celui qui est lié à la facturation énergie. Les relevés de mesure réalisés sur ce point de mesure sont ceux en cohérence avec les informations présentes au niveau de la facturation énergie.

3.6.2.2. Points de mesure

Cet onglet permet d’afficher l’ensemble des points de mesure liés au point énergie pour faciliter le suivi des consommations d’énergie au travers des relevés de mesure.

La saisie d’un point de mesure de facturation initialise cette information dans l’onglet "Points de mesure". Ce dernier est considéré comme point de mesure principal et est non supprimable.
Il est possible d’ajouter sur cet onglet d’autres points de mesure considérés comme des points de mesure de sous-comptage.
- Par exemple, un bâtiment peut être lié au point de mesure de facturation (principal) et chaque étage peut avoir son propre point de mesure (sous comptage).

Il est possible d’accéder directement à la fonctionnalité "Relevé de mesures" au travers de cet onglet.

3.6.2.3. Factures

Cet onglet permet de visualiser et de saisir l’ensemble des factures d’énergie lié au point énergie. Par défaut, on affiche les factures de l’année courante mais un filtre permet d’ajuster les dates.

Saisir les données présentes sur la facture physique telles que le montant de la facture et la consommation en volume, permettront de réaliser des comparaisons entre le facturé et le relevé mais également de connaître par équipement, le coût d’énergie.
Un lien existe entre la facture d’énergie saisie et le point de mesure de facturation.
Une répartition de la facture est possible afin d’avoir un découpage plus précis des coûts d’énergie par équipement / point de structure / localisation.
- Par exemple, la facture globale est sur le bâtiment mais une répartition par étage souhaite être faite (15 % sous-sol, 50 % RDC, 35 % ETAGE_1)
Les champs centre de coût, type de coût, point de structure, localisation ou matériel peuvent être initialisés avec les données renseignées sur l’onglet "Général" si celles-ci sont présentes.
Pour un gain de temps et de productivité, il est possible de répartir une facture d’énergie à partir de la répartition réalisée sur la dernière facture. Afin que cette opération se réalise automatiquement, il est nécessaire de mettre à jour le paramètre de module REPARTITION_MODE (Mode de répartition d’une facture énergie) en sélectionnant la valeur "Automatique".
Des montants négatifs peuvent être saisis sur une facture d’énergie pour pouvoir répondre au besoin des avoirs.

3.6.2.3.1. Mécanisme : répartition d’une facture d’énergie

L’ajout d’une ligne de facture d’énergie entraine obligatoirement l’initialisation d’une ligne dans cette sous liste selon un pourcentage par défaut de 100% de la ligne de facture saisie et le montant correspondant au montant TTC de la facture.
L’utilisateur peut ensuite ajouter autant de lignes de répartition qu’il le souhaite, en veillant à ce que :
- La somme des pourcentages de répartition fasse bien 100 avant l’enregistrement,
- La somme du montant TTC de chaque ligne de répartition soit bien égale au montant TTC présent sur la ligne de la facture.
La modification du pourcentage de répartition ou montant TTC de la ligne de répartition actualise automatique l’autre champ lié.
L’utilisateur peut modifier l’ensemble des informations de la sous liste de répartition de la facture s’il souhaite réaliser une répartition plus fine telle qu’une répartition par bâtiment, étage etc.

3.6.2.3.2. États des factures d’énergie et écritures analytiques

Des écritures d’engagements, de désengagement et de réalisation sont générées en fonction de l’état des lignes de facturation d’énergie.

En préparation : La facture a été créée. Il est possible de modifier les informations liées à la facture et à la répartition de la facture.
- Aucune écriture n’est engagée sur le centre de coût.
A payer : La facture est à payer.
- Lors du passage à l’état A payer d’une ligne de facture d’énergie, les coûts sont engagés sur le centre de coût et pour le type de coût de chacune des lignes de répartition de la facture d’énergie.
Soldée : la facture est soldée.
- Lors du passage à l’état Soldé d’une ligne de facture d’énergie, une ligne d’écriture analytique est générée pour désengager les coûts préalablement engagés sur le centre de coût et pour le type de coût de chacune des lignes de répartition de la facture d’énergie.+ → Une ligne d’écriture analytique est générée pour réaliser les coûts désengagés sur le centre de coût et pour le type de coût de chacune des lignes de répartition de la facture d’énergie.
Annulée : la facture est annulée.
- Si la ligne de facture était à l’état A payer alors une ligne d’écriture analytique est générée pour désengager les coûts préalablement engagés sur le centre de coûts et pour le type de coût de chacune des lignes de répartition de la facture d’énergie.

Une écriture analytique ne sera générée que si et seulement si le centre de coût ET le type de coût sont renseignés sur une ligne de répartition.

Les factures d’énergie ne sont pas liées au processus des factures existant déjà dans CARL Source au niveau du module achat.

3.6.3. Suivi facturation énergie

La fonctionnalité "Suivi facturation énergie" permet de visualiser les lignes de facturation d’énergie et leur répartition sur l’ensemble des points énergie à partir du moment où les factures d’énergie sont gérées au travers du point énergie.

Pour affiner les données de facturation à consulter, différents critères de recherche sont accessibles comme, par exemple, un équipement avec ou sans descendants.

Il est possible de visualiser le suivi des facturations énergie sur un équipement (matériel, localisation, point de structure) depuis sa fiche.

Un bloc "moniteur de relevés " contenant les informations en lien avec l’énergie peut être ajouté dans la zone d’informations.
Ce bloc ne concerne que les entités localisation, point de structure et matériel. Par défaut, ce bloc est désactivé en 7.2 mais il est possible de l’activer au travers de la fonctionnalité configuration de la zone d’informations.

3.7. Intelligence intégrée

New 7.2

Le thème intelligence intégrée est une nouveauté.

L’intelligence intégrée présente dans CARL Source a pour but d’alerter l’utilisateur d’une situation dont il n’aurait pas conscience dans la réalisation de son travail. Le but est de fournir une aide non intrusive à l’exploitation de CARL Source, paramétrable et désactivable au besoin.

3.7.1. Assistant conseil

Un assistant conseil permet de définir les paramètres ainsi que les destinataires des alertes conseil qui seront générés par l’exécution du traitement automatique associé.

Les assistants conseil standards ne sont pas supprimables. En revanche, ils peuvent être dupliqués pour servir de base à la création de nouveaux assistants conseil.

Les informations suivantes peuvent être paramétrées dans le formulaire de détail :

Un intervalle d’exécution (Jour, Heure, Minute),
Une durée d’affichage après laquelle l’alerte conseil n’est plus visible dans l’entête de l’application,
Un filtre permettant de restreindre les données passées en entrée,
Des paramètres d’entrée permettant de remonter une alerte conseil (spécifique à chaque assistant conseil),
Le conseil préconisé aux utilisateurs,
Les destinataires ayant accès à l’alerte conseil générée (utilisateur, profil, organisation).

Lorsque l’on active un assistant conseil, la date du changement d’état (d’inactif à actif) est conservée et est utilisée comme point de départ dans le mécanisme de lancement de l’assistant conseil. Cette logique a pour but de borner le lancement de l’assistant conseil (première activation ou réactivation).

Deux assistants conseil standards sont fournis par défaut dans CARL Source.

3.7.1.1. Assistant conseil : Récurrence des interventions sur équipement (WO_RECURRENCY_EQPT) - MATERIALOCCWOJOB

Cet assistant conseil permet d’alerter l’utilisateur d’une récurrence d’intervention sur équipement.

Les paramètres sont les suivants :

Plage de contrôle (en nombre de jours) : nombre de jours sur lequel on calcule le nombre d’interventions sur un équipement. Par défaut 30 jours.
Pourcentage d’évolution de l’occurrence : % d’évolution à partir duquel on peut parler de récurrence. Par défaut 20 %.
Intervalle de temps servant de référence pour calcul d’une moyenne (en nombre de jours) : intervalle de temps permettant de calculer une moyenne des interventions sur un équipement. Par défaut 180 jours.

3.7.1.2. Assistant conseil : : Surconsommation d’articles (ITEM_OVR_CONSUMPTION) - ITMOVRCONSUMPTIONJOB

Cet assistant conseil permet d’alerter l’utilisateur d’une surconsommation d’articles.

Les paramètres sont les suivants :

Plage de contrôle (en nombre de jours) : nombre de jours sur lequel on calcule le nombre d’articles sortis en stock. On parle ici d’un couple (article/magasin). Par défaut 30 jours.
Pourcentage d’évolution de l’occurrence : % d’évolution à partir duquel on peut parler de surconsommation. Par défaut 20 %.
Intervalle de temps servant de référence pour calcul d’une moyenne (en nombre de jours) : intervalle de temps permettant de calculer une moyenne des sorties en stock pour le couple (article/magasin). Par défaut 180 jours.

3.7.2. Visualisation des alertes conseil

CARL Source vous propose par l’intermédiaire des alertes conseil d’afficher le résultat de l’exécution des assistants conseil. Les alertes conseil sont accessibles depuis n’importe quel écran via la zone supérieure de l’application en cliquant sur l’icône associé. Une pastille sur l’icône permet d’indiquer le nombre d’alertes conseil.

Figure 14. Icône alerte conseil

Les alertes conseil affichées prennent en compte la date d’affichage maximale de l’alerte (date d’exécution du traitement + durée d’affichage) ainsi que la liste des destinataires définie dans le détail de l’assistant conseil.

Figure 15. Liste des alertes conseil

Figure 16. Détail d’une alerte conseil

Le détail d’une alerte conseil affiche :

Une description de l’alerte.
Le nombre d’occurrences concerné par l’alerte ainsi qu’un lien permettant d’ouvrir l’écran de résultats de l’entité concernée, filtré sur les occurrences.
Le conseil à appliquer.

Mais vous pouvez au choix cliquer sur :

CONSEIL VU → L’alerte sera alors marquée comme "lu".
SUPPRIMER → L’alerte ne sera alors plus jamais affichée.

3.7.3. Suivi des alertes conseil

La fonctionnalité "Suivi des alertes" vous permet de consulter toutes les alertes conseil qui ont été créées suite à l’exécution des traitements correspondants aux assistants conseil.

Cette fonctionnalité disponible dans le module "Système" permet à l’administrateur des assistants conseil de les analyser et de pouvoir ajuster les paramètres de lancement en conséquence.

3.8. Business Intelligence

New 7.2

La version 7.2 de CARL Source présente la nouvelle fonctionnalité "Configuration des données de BI", conçue pour simplifier la gestion des données au sein de CARL Source en permettant la création de modèles de données.

L’utilisation de cette fonctionnalité nécessite l’acquisition de droits complémentaires.
En savoir plus sur l’option "CARL BI Analyses".

Pour plus d’informations, contacter CARL Berger-Levrault.

3.8.1. Modèle de Données

Au cœur de cette fonctionnalité, le modèle de données est défini comme une représentation structurée et filtrée des données. Il permet à l’utilisateur de créer un jeu de données en fonction de ses besoins, sans nécessiter de connaissances particulières en SQL.

CARL Source est fourni avec plusieurs modèles de données standards, et vous avez la possibilité de les dupliquer et d’en créer autant que nécessaire.

Le modèle de données comprend des informations générales telles que le libellé, la description détaillée, l’objet métier principal, l’organisation, et le thème. Il est également composé de deux sous-onglets : [Données] et [Filtre]. Pour que ces sous-onglets soient visibles, un premier enregistrement du modèle de données est requis."

Le libellé du modèle de données correspond au titre de la table dans les résultats de l’API OData. En l’absence de libellé, le titre de la table sera celui de l’objet métier principal.

3.8.1.1. Données

Le sous-onglet [Données] permet de définir les éléments à intégrer dans le jeu de données. Vous pouvez sélectionner un attribut dans l’arborescence de gauche, et il sera ajouté dans le tableau à droite.

Les attributs proposés dans l’arborescence sont en lien avec l’objet métier principal choisi. Cette arborescence inclut tous les types d’attributs (persistés et non-persistés).

Le code de l’attribut est modifiable et correspond à l’entête de colonne dans les résultats de l’API OData.

3.8.1.2. Filtre

Le sous-onglet [Filtre] permet de définir les critères de filtre dans le modèle de données.

Les attributs proposés dans l’arborescence sont en lien avec l’objet métier principal choisi. Cette arborescence ne propose que les attributs persistés.

3.8.2. API OData

L’intégration de l’API OData offre une solution pratique pour récupérer facilement ces données dans des outils externes tout en respectant les droits d’accès aux données spécifiques à chaque utilisateur de CARL Source (groupes de restriction d’accès, droits de profil et groupes d’organisations).

Cette approche garantit la sécurité et la confidentialité des données, tout en offrant une expérience personnalisée pour que les données extraites soient dans la langue de l’utilisateur.

Afin de préserver les performances du système, il est essentiel de créer des modèles avec des jeux de données raisonnables, en limitant le nombre de lignes récupérées.

3.8.2.1. Utilisation de l’API Odata

Vous pouvez exploiter les modèles de données actifs dans les outils compatibles avec l’API OData en accédant à leur URL dédiée.

Vous pouvez également exploiter les objets de manière globale en utilisant l’URL Odata suivante : http://[hôte]:[port]/[contexte]/API/ODATA/V1

Les paramètres [host], [port] et [context] correspondent au nom de la machine, au port et au chemin où est installé CARL Source.

L’accès à l’API OData nécessite le droit de profil 'CARL Source -> Global -> Accès à l’API OData'.

3.9. CARL Optim

New 7.3

La version 7.3 de CARL Source propose une solution d’optimisation des plannings de ressources.

Génération automatique des plannings prévisionnels pour les techniciens
Optimisation des temps de trajet et de déplacements des intervenants
Prise en compte des contraintes métier liées à l’activité des services techniques
Visualisation graphique des plannings proposés

L’utilisation de cette fonctionnalité nécessite l’acquisition de droits complémentaires.
En savoir plus sur l’option "CARL Optim".

Pour plus d’informations, contacter CARL Berger-Levrault.

3.9.1. Configuration des optimisations

L’objectif est de pouvoir configurer les modèles d’optimisations qui seront appliqués au moment du lancement de l’optimisation pour répondre au mieux aux spécificités de chaque client.

Les contraintes d’optimisation sont standards et peuvent être désactivées par les administrateurs si nécessaire.
Les contraintes peuvent être appliquées individuellement ou combinées. Certaines contraintes incluent des sous-paramètres pour affiner les règles.
Il existe deux types de modèles d’optimisation : VRP (avec déplacement) et TASP (sans déplacement).

3.9.2. Exécution d’une optimisation

CARL Optim est un moteur d’optimisation conçu pour résoudre des problèmes de planification et de routage complexes en appliquant des contraintes spécifiques pour répondre le plus finement possible à vos besoins.

La sélection des contraintes ainsi que le choix du niveau de contraintes et de la pondération permettent d’orienter le résultat de l’optimisation.
En appliquant ses différents paramètres, un score par niveau de contraintes (fort, moyen, souple) est calculé pour chacune des solutions testées. La meilleure solution proposée est celle se rapprochant d’un score de 0/0/0.
En revanche, une solution avec un score négatif correspondant aux contraintes de type "fort" n’entraine pas une proposition de solution.

3.9.3. Historisation des optimisations

L’objectif est d’avoir un suivi des optimisations réalisées via le moteur CARL Optim dans CARL Source.

La fonctionnalité "Historique des optimisations" permet de suivre les optimisations avec des détails tels que le numéro du tir, la date, le modèle, l’utilisateur et l’état.
Les actions disponibles sur une optimisation incluent l’acceptation ou le refus, selon l’état "En attente décision" et la validité de la solution.
La durée de validité d’une solution est configurable et par défaut fixée à 24 heures, après quoi les actions deviennent inaccessibles.
Une option de purge permet de supprimer les données JSON des optimisations tout en conservant les informations pour la traçabilité.
La purge de la matrice de coût, qui calcule les temps de déplacement, est une action manuelle nécessaire pour intégrer les changements d’itinéraires.

3.9.4. Gestion d’une semaine type

Cette nouvelle fonctionnalité permet de définir les horaires d’ouverture d’une entreprise sous forme de semaine type afin de l’appliquer au lancement d’une optimisation sans avoir besoin de définir des horaires à l’intervenant près.

La fonctionnalité "Semaine Type" permet de définir les horaires de travail sur une semaine dans le module "Ressources".
Un calendrier graphique permet d’ajouter facilement des plages de disponibilités.
La plage d’affichage est configurable via les "Paramètres de module".
Cette fonctionnalité est destinée à optimiser les ressources en appliquant un modèle de semaine type à tous les intervenants.

3.9.5. Gestion des déplacements

Deux modes de gestion des déplacements TASP et VRP sont pris en compte lors de l’optimisation des ressources :

Le mode TASP répartit les tâches sans considérer les déplacements, tandis que le mode VRP optimise les tournées en tenant compte des trajets.
Le mode VRP utilise une matrice de coût basée sur ORS pour calculer les distances entre adresses, intégrant des paramètres comme le mode de transport et les lieux de départ/arrivée fixes.
Les temps de déplacement calculés en mode VRP sont intégrés dans les interventions comme ligne de main-d’œuvre, influençant la charge totale.
Les déplacements peuvent être gérés hors CARL Optim en renseignant directement la nature de la main-d’œuvre dans l’intervention.
Les informations sur les déplacements sont visibles et modifiables dans le planning des ressources.

4. Évolutions fonctionnelles générales

4.1. Module équipements

4.1.1. Ajustement d’attributs réglementaire / Localisations

La version 7.0.0 de CARL Source apporte une amélioration des attributs réglementaires pour qualifier une localisation.
La classification ERP a été revue et une partie du contenu a été isolée et est dédiée à la propriété IGH (Immeuble de Grande Hauteur).
Les ajouts d’une case à cocher E.R.T. (Établissement Recevant des Travailleurs) et d’une Case à cocher L.U.H (Locaux à Usage d’Habitation) permettront de classifier correctement les localisations.

4.1.2. Arborescences du parc équipements

La pop-in de recherche rapide de l’arborescence des équipements évolue afin de prendre en compte les attributs optionnels "Type équipement" et "Modèle" d’équipement afin d’affiner et compléter une recherche d’équipement.

4.1.3. Configuration des types équipement : Fiche de caractéristique

La configuration des types d’équipement existante prenait déjà en compte les caractéristiques. Elle fait maintenant référence à des fiches de caractéristiques permettant de définir rapidement un ensemble de caractéristiques à initialiser pour une configuration type.
Une priorité d’application entre les fiches est également disponible afin de préciser la priorité de création de caractéristiques en cas de caractéristiques identiques sur 2 fiches différentes renseignées.

Faire référence à une fiche de caractéristiques, par rapport aux caractéristiques directement liées à la configuration, permet en cas d’évolution des éléments de la fiche, de toujours appliquer ces caractéristiques à jour. La modification sur une fiche sera immédiatement prise en compte en cas de nouvelle application de la configuration du type équipement référençant la fiche sans autre manipulation.

Voir : Fiche de caractéristiques pour plus de précision.

4.1.4. Principe des points de contrôle

La version 7.0.0 de CARL Source introduit le concept de points de contrôle permettant le suivi de points spécifiques sur le parc équipement selon une liste d’états préétablis.

Par exemple, pour un bâtiment, le responsable de parc immobilier va positionner des points de contrôles "déclaratifs" sur chaque local d’un bâtiment afin de suivre l’état des prises électriques, des fenêtres, des portes, du sol, des appliques lumineuses, où il indiquera (ou les équipes terrain) l’état par saisie directe. Ceci sans déclarer d’équipement supplémentaire pour le suivi de ces points.
Il va ensuite définir des points de contrôle "calculés", à sa convenance, directement sur le bâtiment pour résumer l’état général des prises, des appliques, et/ou plus généralement du réseau électrique, mais aussi des menuiseries, des sols (etc.), pour un suivi et une gestion d’ensemble simplifiée et personnalisée.

Si la conception des modèles de points de contrôle est pertinente, les points de contrôle sources sont automatiquement déterminés par le système sur les points calculés à la création du point de contrôle calculé.

L’administrateur dispose de modèles de points de contrôle afin de générer les différents points de contrôle et apporter une cohérence dans les états disponibles.

Chaque point de contrôle est associé à un équipement mais peut également être associé à une structure indépendante de point de structure spécifique afin d’apporter une classification et un regroupement/une vision différent de celui de l’équipement porteur du point. Ceux-ci peuvent être des lots techniques personnalisés pour des équipements, des végétaux, ou bien des classifications du bâti officielles à l’instar de OmniClass, UniClass, Uniformat.

4.1.4.1. Points de contrôle

Un point de contrôle est un élément représentant un "état", l’information d’un élément liée à un équipement. Malgré un historique des valeurs passées disponible, seul l’état en cours du point est utilisé dans l’application. Le modèle de points de contrôle est obligatoire.
Il existe 2 types :

Déclaratif : un point situé sur un équipement, de bas niveau dans la hiérarchie en principe, pour lequel on renseignera un état. Cet état peut être déclaré sur le détail du point ou en liste (de résultat ou sous liste) en activant la ligne du point de contrôle : un lien apparait pour saisir l’état.
Calculé : un point situé en général en haut de l’arborescence équipements, qui indiquera un état issu d’une opération sur un ensemble d’états de points de contrôle issus d’équipements descendants généralement.

Le point calculé doit être lié à des points de contrôles "sources" pour effectuer son calcul. Ceux-ci peuvent être déterminés automatiquement à partir du modèle de point de contrôle calculé et/ou ajoutés manuellement.
Cependant, la liste de valeurs d’état est obligatoirement la même entre tous les points sources et le point calculé pour garder la cohérence du calcul.
Un job automatique déclenchera le calcul des points de contrôle calculés selon le paramètre de périodicité renseigné sur chaque point de contrôle calculé.

Correctement déclarés, les modèles de points de contrôle permettent l’ajout rapide et simplifié de points de contrôle sur les équipements.

Exemple : configuration de points de contrôles sur un bâtiment

Si l’utilisateur
1. a déclaré des modèles déclaratifs A, B, C pour les prises électriques, les plafonniers, les interrupteurs électriques avec une même liste de valeur d’état.
2. a créé des points de contrôles sur les locaux d’un bâtiment avec ces types avec ces modèles déclaratif.
3. possède des modèles de points calculés avec des calculs comme moyenne (par exemple) en ayant référencé comme modèle source déclaratif les modèles désignés précédemment A, B et C.
Il suffit alors à l’utilisateur de créer des points de contrôles calculés, à base des modèles de points calculés énoncés précédemment, sur les étages ou bâtiments ou sites se situant hiérarchiquement au-dessus des locaux.
Ces points calculés de haut niveau seront alors directement renseignés par l’ensemble des points de contrôle déclaratifs des locaux portant les bons modèles déclaratifs (A, B et C) à la création du point de contrôle.
Une fois les modèles configurés correctement, au niveau des liens, l’avantage est d’avoir les mêmes renseignements sur l’ensemble du parc équipements et avoir des déclarations simplifiées de points de contrôle calculés configurés automatiquement à leur création.

Les points de contrôle peuvent être générés automatiquement grâce aux modèles d’équipement : Un onglet a été ajouté sur le modèle afin de générer automatiquement les points de contrôle sur les équipements, comme déjà fait avec les points de mesure.

4.1.4.2. Modèles de points de contrôle

Les modèles de points de contrôle permettent de configurer et typer les points de contrôle. Le modèle est obligatoire pour créer un point de contrôle.
Ils servent à spécifier le type du point, la liste de valeurs d’état à utiliser, l’opérateur de calcul. Ils permettent également d’initialiser certaines valeurs des points de contrôle issus du modèle.
La structuration de modèles de point de contrôle est importante afin d’apporter de la cohérence aux points de contrôle qui en sont issus, notamment par génération automatique de ces points depuis les modèles des équipements.

4.1.4.2.1. Type calculé

Le modèle de point de type calculé possède des propriétés différentes de celui de type déclaratif.
Le calcul se base sur la valeur associée à chaque état. Il peut également se baser sur la "cotation" : une "note" ajoutée manuellement pour chaque état.

Une opération de calcul doit être renseignée (Somme, Minimum, Maximum, Moyenne, Moyenne pondérée) ainsi que la donnée servant au calcul : valeur associée à l’état ou la cotation.

Il est également possible de déclarer les modèles de point de contrôle déclaratifs sources du calcul :
A la création du point de contrôle calculé, ceux-ci conduisent à une déclaration automatique des points sources provenant des descendants de l’équipement.

4.1.4.3. Onglet suivi des mesures / détails équipements

La version 7.0.0 de CARL Source ajoute l’aperçu des points de contrôle et points de mesure de l’équipement directement dans le détail de celui-ci, au travers du nouvel onglet "Suivi des mesures".
Cet onglet est composé de 2 sous listes dédiées à chacune de ces natures de points.
Des options de filtrages dynamiques sont présentes en entête de chaque liste afin de trier rapidement et efficacement les éléments.

L’option Afficher les descendants de chaque liste permet d’afficher les points attachés aux équipements se situant hiérarchiquement en dessous de l’équipement actuellement affiché. Cette possibilité ajoute une vue rapide si besoin de ces informations sans sortir du détail d’un équipement de haut niveau.

Deux actions sont ajoutées sur le détail des équipements afin d’apporter une consultation rapide de ces éléments Points. Elles permettent d’ouvrir directement les fonctionnalités points de contrôle et point de mesures filtrées sur les éléments de l’équipement depuis lequel est effectué l’appel.

4.1.5. Interface d’import FUEL standardisée

L’interface d’import FUEL est désormais disponible en standard. Cette nouveauté implique une modification des formulaires de détail et de recherche des fonctionnalités Points de mesures et Modèles de point de mesure. L’attribut Catégorie est maintenant associé à une liste de valeurs.

4.1.6. Points de mesure

4.1.6.1. Calcul de la valeur de l’extrapolation linéaire

New 7.1

La version 7.1.0 de CARL Source introduit la possibilité de calculer la valeur de l’extrapolation linéaire du compteur en fonction des relevés de mesure précédents.

L’action n’est accessible que si l’extrapolation est linéaire.

Figure 17. Action de calcul de l’extrapolation linéaire

Le calcul de la valeur d’extrapolation linéaire utilise la période (j) spécifiée dans le vieillissement moyen. Si aucune période n’est indiquée, cette dernière sera considérée comme égale à 0, ce qui entraînera une valeur d’extrapolation linéaire également égale à 0.

Pour déclencher l’action de calcul, le point de mesure doit comporter au minimum deux relevés de mesure. Dans le cas contraire, un message d’erreur apparaîtra.

Figure 18. Message d’erreur si le point de mesure comporte mois de deux relevés de mesure

4.1.6.2. Automatisation du calcul de l’extrapolation linéaire

New 7.1

Cette version de CARL Source propose un traitement automatique qui permet d’automatiser le calcul de l’augmentation moyenne de la mesure du compteur en fonction des relevés de mesure précédents.

Cette automatisation peut être activée en cochant la case « Calcul auto », qui n’est sélectionnable que pour une extrapolation linéaire. Si l’extrapolation a la valeur Personnalisée ou Aucune, cette case devient inaccessible.

Figure 19. La case à cocher "Calcul auto"

Lorsque la case « Calcul auto » est cochée, les champs Valeur et Période deviennent également grisés et non modifiables.

Le choix de calcul automatique permet au traitement automatique « CALCULAGING » de calculer et de mettre à jour la valeur et la période de l’extrapolation linéaire en se basant sur ses paramètres à intervalle d’exécution choisi.

Figure 20. Le traitement automatique CALCULAGING

4.1.7. Fonctionnalité BIM

L’utilisation de cette fonctionnalité nécessite l’acquisition de droits complémentaires.
En savoir plus sur l’option "CARL Maps (BIM et CIM)".

Pour plus d’informations, contacter CARL Berger-Levrault.

4.1.7.1. Systèmes de coordonnées

New 7.2

Cette version de CARL Source introduit la possibilité de définir un référentiel de projections (Lambert, World Mercator).
Ces projections sont utilisées à la fois pour la transformation des fichiers IFC en tuiles (fichiers .b3dm) mais aussi pour la visualisation des Viewers BIM (Viewer 3D).
Des systèmes de projection standard ont été ajoutés à CARL Source, néanmoins l’utilisateur a la possibilité d’ajouter ses propres systèmes de coordonnées.
Ces systèmes de projections sont actuellement destinés uniquement aux processus BIM, et ne sont pas utilisés dans les processus SIG.

Figure 21. Système de coordonnées

4.1.7.2. Fonds de plan

New 7.2

Cette version de CARL Source ajoute une nouvelle fonctionnalité permettant de définir un référentiel de fonds de plan (IGN, OSM). Ces fonds de plan peuvent être utilisés pour la visualisation des Viewers BIM (Viewer 3D). Ces fonds de plan sont actuellement destinés uniquement aux processus BIM, et ne sont pas utilisés dans les processus SIG. Des fonds ont été ajoutés à CARL Source, néanmoins l’utilisateur a la possibilité d’ajouter ses propres fonds de plan. Chaque fond de plan doit être associé à un ou plusieurs systèmes de coordonnées.

Figure 22. Fond de plan

4.1.7.3. Maquettes BIM

New 7.2

Cette version de CARL Source ajoute une nouvelle fonctionnalité permettant de définir un référentiel de maquettes BIM. Ces maquettes sont utilisées pour la visualisation des bâtiments en 3D. Ces maquettes permettent de récupérer les informations issues des fichiers IFC (micro-services de parsing, de loading et de génération des tuiles). Chacun de ces traitements fonctionne de manière asynchrone. Un mémo est transmis à l’utilisateur une fois le traitement terminé.

Figure 23. Maquette BIM onglet Général

Figure 24. Maquette BIM onglet Classes IFC

Figure 25. Documents associés à une maquette

1. Le traitement de parsing permet d’identifier l’ensemble des classes IFC relatives au fichier importé, ainsi que le nombre d’équipements liés à ces classes.

2. Le traitement de loading permet de charger dans CARL Source l’ensemble des équipements liés aux classes IFC. Ce chargement peut être total ou partiel selon les besoins.

3. Le traitement de génération des tuiles permet de transformer le fichier IFC en fichier 3bdm. Ces fichiers sont indispensables à la visualisation du bâtiment dans le Viewer 3D.

4.1.7.4. Cartographie BIM

New 7.2

Cette version de CARL Source ajoute une nouvelle fonctionnalité permettant de définir un Viewer 3D.
Cette cartographie BIM possède les différentes propriétés propres à chacune des maquettes qui lui est associée. L’utilisateur a la possibilité de définir sur chaque couche (classes IFC), la visibilité, la priorité de sélection, sa présence dans la table des matières, la couleur de représentation. D’autres propriétés sont également reprises dans le Viewer, telles que la couleur de sélection, le fond de plan associé, le niveau de zoom, l’arborescence associée.

Figure 26. Cartographie BIM propriétés

Figure 27. Cartographie BIM accès au Viewer

Figure 28. Viewer 3D

4.1.8. SIG CARL

New 7.3

La version 7.3 propose son propre SIG CARL.

Ce SIG autonome permet de :

Conserver le périmètre fonctionnel :
- Chargement des données équipements
- Gestion des plans et des cartes
- Accès aux données externes
Faciliter la gestion des cartes / plans :
- Aucune connaissance nécessaire sur MapGuide^® / ArcGIS^®
Faciliter la maintenance et l’environnement technique :
- Aucun lien technique avec des serveurs déportés MapGuide^® / ArcGIS^®

4.1.9. Gestion des styles

Une nouvelle fonctionnalité de gestion des styles a été intégrée dans le SIG CARL pour améliorer la représentation graphique des éléments cartographiques.

Cette fonctionnalité permet de gérer les styles pour les géométries de type "Ponctuel", "Ligne" et "Polygone", avec des options de personnalisation comme la couleur et l’épaisseur.
Une nouvelle librairie permet d’obtenir des représentations graphiques, et des icônes peuvent être utilisées pour les géométries de type "Ponctuel".
Un formulaire de recherche a été ajouté pour retrouver les styles selon des critères comme la géométrie et la catégorie.
Un formulaire de détail permet de gérer les attributs des styles, incluant la géométrie, la catégorie, et d’autres paramètres visuels.
Une zone de prévisualisation est incluse pour visualiser les styles définis.

4.1.10. Configurer une carte

Une nouvelle fonctionnalité de gestion autonome des données cartographiques a été intégrée dans le SIG CARL, remplaçant les outils MapGuide^® et ArcGIS^®.

Le SIG CARL permet d’accéder aux données géolocalisées directement dans la base de données de CARL Source ou via des bases externes.
Un nouveau menu de création et un formulaire de détail ont été ajoutés pour gérer les informations des cartes, incluant des options pour les couches et les styles.
Les administrateurs peuvent ajouter des couches CARL Source et externes, telles que Geojson et WFS, pour enrichir les cartes existantes.
Des couches de regroupement peuvent être créées pour organiser la table des matières, toujours visibles et non sélectionnables.
La gestion des paramètres des couches externes et la définition de l’ID de sélection sont possibles via des icônes dédiées.

4.1.11. Configurer un plan

Une nouvelle fonctionnalité a été intégrée dans le SIG CARL pour gérer les plans sans utiliser MapGuide^®, avec un menu de création dédié et un formulaire de détail permettant de configurer les plans.

Un nouveau menu de création dans le module Equipement permet d’accéder rapidement au formulaire de détail d’un plan.
Le formulaire de détail est divisé en trois parties : informations générales, tableau des couches, et tableau de détail des couches.
L’initialisation d’un plan nécessite l’association d’informations techniques, avec un SRID fixe à 0.
Les couches CARL Source et de regroupement peuvent être ajoutées pour gérer les équipements et organiser la table des matières.
Les administrateurs peuvent gérer la visibilité, l’ordre d’affichage et le style des calques dans le Viewer.

4.1.12. Import des plans

Il est possible de charger et de synchroniser des plans et équipements dans CARL Source à partir de fichiers DWG et ZIP.

Les fichiers ZIP contiennent des données d’habillage et d’équipements, qui sont importés dans CARL Source pour afficher les plans.
Les fichiers DWG doivent respecter certaines règles, notamment pour les noms de fichiers et les géométries.
Une nouvelle fonctionnalité d’importation d’équipements a été ajoutée à CARL Source, permettant de comparer et de mettre à jour les données existantes.
La synchronisation des équipements est essentielle pour rendre le plan utilisable dans CARL Source, avec des informations obligatoires comme la date d’import.

4.1.13. Gestion des plans

Cette nouvelle fonctionnalité améliore la gestion des plans dans le SIG CARL en intégrant des imports d’équipements.

Les plans ne peuvent être créés que par importation depuis Draw2DB-SaaS, sans option de création manuelle.
Un nouveau formulaire permet de gérer les informations des plans, incluant le code, la description, et la date d’import.
Pour activer un plan dans une configuration, la date d’import et le point de structure associé doivent être renseignés.
Lors de la mise à jour d’un plan :
- Si un plan n’est pas associé à une configuration, il est écrasé par le nouveau plan sans changement de version.
- Si un plan est associé à une configuration, un nouvel import du plan le remplacera, la version changera et la configuration sera mise à jour automatiquement.

4.2. Module travaux

4.2.1. Mesures de l’intervention

New 7.2

L’action et le formulaire dédié appartement à l’addon Transport est dorénavant intégré au standard.
Le comportement a été ajusté.

Voici les règles d’apparition de l’action mesures de l’intervention sur un détail intervention :

Action disponible uniquement si l’intervention possède au moins un point de mesure (sur son matériel ou sur le référent)
Les libellés en standard de l’écran WOMeasure-DET et tout vocabulaire (hors TRANSPORT) sont :
- Compteur kilométrique ==> Point de mesure principal
- Compteur horaire ==> Point de mesure secondaire
Pour les utilisateurs avec le vocabulaire Transport : les anciens libellés sont gardés (affecté au vocabulaire métier TRANSPORT).

4.3. Module stock

4.3.1. Mouvement de stock - Date de péremption

La version 7.0.0 de CARL Source ajoute un contrôle sur la date de péremption de l’article lors de l’expédition, la sortie de stock ou la consommation sur intervention.

Si un article périmé est sorti, expédié ou consommé, une pop-up de confirmation va alerter l’utilisateur en lui donnant le choix de poursuivre ou non l’opération.

4.4. Module achat

4.4.1. Fournisseur - Import de la désignation de l’article

La fonctionnalité "Import (MAJ) des tarifs catalogue", évolue afin de prendre en compte le libellé de l’article sur le catalogue du fournisseur lors de l’importation des données.

Un champ "libellé" a été ajouté sur la fonctionnalité "Import (MAJ) des tarifs catalogue", pour renseigner le numéro de la colonne désignant le libellé de l’article dans le fichier des tarifs importé.

4.5. Module compte

4.5.1. Budget

New 7.2

Ajustement du détail Budget suite à l’intégration de City.

Les notions supplémentaires de budget de l’addon CITY sont ajoutées en standard.
Un nouvel onglet d'informations financières apparait dans le détail d’un budget, comportant des champs en saisie libre ainsi que l'AE/AP/Affectations rattachée.

Cet onglet est visible uniquement si la case à cocher Imputation autorisée est à vrai. (Elle est à Faux par défaut.)
Si imputation autorisée est à vrai sur un budget renseigné sur une ligne de commande ou une ligne d’achat, alors le sous onglet Informations financières est accessible pour cette ligne commande ou achat.

Pour rapidement cacher cette notion d'informations financières, il suffit de cacher la case à cocher Imputation autorisée sur le détail du budget, et ces informations ne seront jamais accessibles aux utilisateurs dans l’application.

4.5.2. AE/AP/Affectations

New 7.2

Réintégration de la notion d’autorisation d’engagement financier issue de l’addon CITY dans le standard.

A partir de cette version, la fonctionnalité AP/AE/Affectations est présente en standard.

4.6. Module ressources

4.6.1. Intervenant - Direction

Sur le détail d’un intervenant, l’attribut "Service" en saisie libre a été remplacé par l’attribut Direction pointant sur le code de l’entité Direction.

4.7. Module système

4.7.1. Utilisateur

New 7.2

Ajustements de libellés.

Sur la fiche utilisateur, le terme Domaine métier a été renommé en "Vocabulaire métier. Cet attribut désigne le lexique décliné par contexte métier applicable pour un utilisateur donné. + Il ne conditionne plus le comportement de l’application comme cela était fait pour la verticalisation Transport.
Personnalisation a été renommé en Groupe de personnalisation afin de lever toute ambiguïté.

4.7.2. Acteur - Direction

Sur le détail d’un acteur, l’attribut "Service" en saisie libre a été remplacé par l’attribut Direction pointant sur le code de l’entité Direction.

4.7.3. Groupes de personnalisation

New 7.2

Ajout d’un paramètre de profil.

Le paramètre de profil Structure affichée par défaut pour l’arborescence de localisation a été ajouté pour la fonctionnalité Équipement / Arborescences du parc équipements.
Elle surcharge pour un utilisateur lié au profil le paramètre de module de même nom.

Pour rappel, ceci permet de renseigner le code de la structure affichée par défaut lors de l’appel à l’arborescence depuis une IZ Point géographique/Localisation.

Ce paramètre de module était positionné sur Localisation lors de l’installation de l’addon FACILITY.
Avec les contextes métiers pouvant être définis par un utilisateur, cette propriété peut maintenant être configurée au profil près si nécessaire.

4.7.4. Modèle de caractéristique

La fonctionnalité "caractéristique" dans le module système est renommée Modèle de caractéristiques pour plus de précision dans la dénomination.
En effet, ces éléments permettent de générer les caractéristiques portées par des entités de l’application et ne comportent que des propriétés de la caractéristique à générer et non des informations directement utilisables.

L’attribut Groupe a été ajouté sur les modèles de caractéristiques et sur les caractéristiques. Il peut être initié sur le modèle de caractéristiques et est repris à la génération de la caractéristique sur les entités concernées.

4.7.5. Caractéristiques

L’attribut groupe a été ajouté sur les caractéristiques et est modifiable à la caractéristique près, comme peut l’être l’attribut "Important" déjà existant. Il permet des regroupements adaptés au contexte de l’entité près sans forcément être dépendant du modèle de caractéristique comme le propose l’attribut "Thème".
La notion est ajoutée sur toutes les listes caractéristiques ainsi que le Widget Caractéristiques.

Le bouton d’application de filtrage est enlevé.
Les filtres dynamiques disposés au-dessus des listes caractéristiques dans les onglets Caractéristiques sont directement appliqués à la liste pour plus d’efficacité et de simplicité de navigation.

L’implémentation des caractéristiques a été entièrement revue. Les caractéristiques, quelle que soit l’entité portant l’information, sont maintenant une seule et même entité.
Fonctionnellement il n’y a pas de changement apparent dans l’application, cependant les interfaces ont été modifiées pour faire référence à l’entité unique CHARACTVALUE contenant l’ensemble des caractéristiques de l’application.

Les listes de caractéristiques comportent une nouvelle action "Ajouter les caractéristiques d’une fiche". Cette recopie rapide permet avec des fiches organisées de rapidement générer des caractéristiques à partir d’une collection de caractéristiques préétablies.

4.7.6. Fiche de caractéristiques

La version 7.0.0 de CARL Source introduit le concept de Fiche de caractéristiques regroupant une collection de caractéristiques pré-renseignées prête à être utilisée selon les différents contextes de l’utilisateur.
La fiche de caractéristiques est un ensemble cohérent de caractéristiques pré-renseignées, adaptées pour des éléments dont la création est régulièrement effectuée dans l’application.

Par exemple, l’utilisateur peut créer des fiches de caractéristiques qu’il pourra utiliser au besoin de façon répétée pour les caractéristiques de la sécurité d’un bâtiment, la surveillance d’un site, des ensembles de caractéristiques par type de locaux etc.

4.7.7. Workflow multiple

La version 7.0.0 de CARL Source introduit le concept de workflow multiples.
Il est dorénavant possible, pour un workflow lié à une entité, d’envisager des comportements et cycles de vie différents selon certaines conditions de l’entité.

La possibilité de cycles de vie multiples pour un workflow est autorisée pour les entités Equipements (Localisations, points de structures et matériel) et Achat (Commande et demande d’achat).

New 7.2

La version 7.2.0 de CARL Source offre la possibilité de workflows multiples sur toutes les entités.

La modification de workflow est une manipulation délicate et réservée à des personnes maitrisant les concepts avancés des notions de cycle de vie des entités pour ne pas rencontrer d’erreur d’application.
L’ajout de Workflow multiples avec des conditions d’application spécifiques et dynamiques ainsi que l’ajout d’états spécifiques sur des branches alternatives, accroit la complexité et la nécessité de la maîtrise complète du sujet dans sa globalité et ses conséquences.
Concernant la mise en oeuvre de branches alternatives dépendantes de valeurs de l’entité, il est recommandé de se baser sur des attributs pas ou peu modifiables après la création de l’entité.

4.7.7.1. Détail Workflow

La fiche de détail évolue afin de prendre en compte la possibilité de cycles multiples pour une entité que l’on nomme branche de workflow.
On trouve un arbre du Workflow ainsi que ses branches sur la gauche du formulaire. L’utilisateur clique dessus pour afficher le détail sur la droite du formulaire :

Noeud principal en entête : les informations génériques du Workflow + attributs de condition déterminant le passage d’un cycle de vie à un autre pour l’entité. NB : l’entité doit être renseignée sur le WF pour accéder au Workflow multiple.
Une 1ère branche de Workflow : branche principale identifiée avec le numéro "0". Obligatoire et principale.
Eventuellement d’autres nœuds : les branches alternatives : basées sur l’héritage des éléments de la branche principale, l’utilisateur peut y renseigner les conditions qui déclenchent l’application de ces états et transitions adaptées (masquage des états et transitions héritées automatiquement de la branche principale + autres états et transitions valides uniquement pour cette branche).

New 7.2

Possibilité d’ajouter une condition sur les transitions du workflow.

Il est nécessaire de garder un état de création commun à toutes les branches en première position. Il faut également vérifier que les états/transitions standards qui sont à la base d’actions automatiques du système sur le Workflow standard, ne sont pas désactivés sur les branches alternatives afin de garder une stabilité de workflow sur les entités.
Il est plus aisé d’ajouter des états et transitions sur les branches de Workflow alternatives, contextuelles au besoin utilisateur, que d’en supprimer au risque d’endommager les actions de base prévues en standard.

4.7.7.2. Droits de profil sur Workflow

La gestion des droits de workflow sur les profils est adaptée au contexte multi Workflow : Chaque branche de workflow est affichée avec les droits de profils associés.
Des actions pour propager les droits de WF paramétrés sur un profil sont disponibles dans les listes de droits des Workflows. Elles permettent de recopier les droits de Workflow sur d’autres profils en une seule action depuis le profil paramétré.

4.7.8. Formulaire personnalisé - Menu de création personnalisé

La version 7.0.0 de CARL Source introduit les menus de création personnalisés en fonction des attributs de personnalisation, basés sur des formulaires personnalisés de détail d’entités.
Lorsque l’administrateur possède des formulaires personnalisés configurés sur un attribut de personnalisation d’une entité, il est possible pour chaque valeur de cet attribut d’indiquer si un menu de création personnalisé doit être affiché. Si oui, le libellé du menu est à renseigner.

Une entrée de menu complémentaire est alors ajoutée dans la liste des actions de création de l’entité concernée, avec le libellé de menu personnalisé. Celui-ci ouvrira l’entité en création avec le formulaire personnalisé et la valeur d’attribut de personnalisation initiée.
Cette représentation est affichée seulement lorsque le paramètre système lié aux menus personnalisés de création est positionné sur le mode En liste.

Cependant, certaines fonctionnalités ne peuvent pas afficher ces menus personnalisés en liste : le menu de création est déjà contextualisé de base pour ces entités dans le standard.
Dans ce cas, le style Menu avancé est automatiquement appliqué pour ceux-ci en affichant une "pop-in" de choix à la création (voir ci-dessous).
Ces fonctionnalités sont : Indicateur, Localisation, Demande d’achat, Contrat, Intervention sur matériel roulant.

Si le paramètre de configuration est positionné sur Menu avancé, les menus personnalisés en liste ne sont pas affichés directement en liste. Une pop-in de création personnalisée est affichée après que l’utilisateur ait actionné la création de l’entité standard.

La pop-in propose à l’utilisateur la possibilité d’une création standard de l’entité et des autres menus de créations à travers deux listes :

La première reprend le nom du formulaire souhaité,
La seconde reprend le libellé de menu personnalisé issu du formulaire personnalisé choisi.

Au travers de ces actions de création personnalisées, l’utilisateur accède directement au formulaire adéquat avec la valeur de l’attribut de personnalisation renseignée.

Cette configuration couplée à une branche de workflow spécifique possédant les mêmes conditions de personnalisation de formulaire offre directement à l’utilisateur un accès au Workflow spécifique sur l’élément spécifique en création.

Par exemple, si le Workflow matériel a été personnalisé sur le type équipement et que des formulaires personnalisés ont également été personnalisés en fonction de cet attribut, l’utilisateur pourrait accéder directement à la création de type comme "végétaux", "bien public", "matériel spécifique", chacun possédant ses propres branches de workflow contextualisés. Cet ajout permet une forte contextualisation par paramétrage d’entités de l’application, notamment coté équipement.

4.7.8.1. Groupes de personnalisation

New 7.2

Ajout de données standards.

La propriété Standard est ajoutée aux groupes de personnalisation.

Afin de personnaliser l’application rapidement et de retrouver la navigation équivalente du déploiement des anciens addons verticalisations, l’application dispose de groupes de personnalisation standards.
Ceux-ci permettent d’appliquer rapidement les formulaires et menus d’un des différents contextes métiers à un utilisateur.

Ces groupes de personnalisation standards ne sont pas modifiables mais peuvent être dupliqués et adaptés.

4.7.9. Consentement

La version 7.0.0 de CARL Source introduit la possibilité de pouvoir consentir certaines données pour lesquelles des informations à caractères personnelles sont présentes (exemple n° de téléphone, adresses, contacts).

Principe : la notion de consentement sur une donnée est caractérisée par un nouvel attribut Date d’anonymisation.

Si cette date n’est pas renseignée alors la donnée n’a pas encore été consentie.
Si cette date est renseignée alors la donnée a été consentie. Soit elle est acceptée, soit refusée. Une donnée dont le consentement a été refusé passe automatiquement à l’état inactif. Elle n’est donc plus utilisable dans l’application.

Le périmètre standard du consentement intègre les fonctionnalités : Acteur/Utilisateur - Intervenant - Client - Occupant - Fournisseur.

Deux modes de gestion différents sont envisageables pour un acteur.

Soit le type de consentement présent dans la fiche acteur est facultatif et dans ce cas, l’utilisateur n’a aucune nécessité de donner son consentement lors de sa connexion à l’application.
Soit le type de consentement est obligatoire et l’utilisateur est dans l’obligation de donner son consentement lors de sa connexion à l’application.

Néanmoins, à tout moment, l’utilisateur peut accéder au consentement au travers d’un nouveau menu Accès aux CGU pour modifier son choix.

Seul l’administrateur a la possibilité (nouveau droit de profil Système\Global\Gérer le consentement) d’accepter ou de refuser le consentement sur les fonctionnalités Intervenant - Client - Occupant - Fournisseur.
Mais il ne peut jamais se soustraire au consentement de l’utilisateur.

L’administrateur possède également des indicateurs graphiques dans le bandeau pour identifier si la donnée a été consentie ou pas.

4.7.9.1. Mémo RGPD

Dans la fonctionnalité Mémo, un champ "origine" donne la possibilité de déclarer un nouveau mémo de type RGPD. Ce type de mémo permet d’afficher les Conditions Générales d’Utilisation soit à la connexion de l’utilisateur, soit au travers d’un nouveau menu Accès aux CGU.

Les Conditions Générales d’Utilisation doivent être enregistrées dans la zone texte du mémo.

Ce mémo possède des propriétés qui lui sont propres. Il est obligatoirement de type Pop-up et se caractérise dans son utilisation par l’affichage de deux boutons Annuler et Refuser. L’utilisateur notifié est donc contraint de choisir parmi ces deux choix.

Si le client souhaite visualiser des Conditions Générales d’Utilisation dans des langues différentes, il est dans l’obligation de créer plusieurs mémos RDGP. Chaque mémo aura une zone de texte possédant chacune des traductions.

4.7.9.2. Anonymisation

La version 7.0.0 de CARL Source introduit la possibilité de pouvoir anonymiser des données pour lesquelles des informations à caractères personnelles sont présentes (exemple n° de téléphone, adresses, contacts).

Principe : la notion d’anonymisation sur une donnée se caractérise par la suppression ou la modification de celle-ci afin que le caractère personnel ne soit plus présent dans l’application.
Les traitements d’anonymisation peuvent se faire soit au travers d’une action directement disponible dans les fonctionnalités concernées, soit par un traitement automatique (traitement global de la base).

Le périmètre standard de l’anonymisation intègre les fonctionnalités : Acteur/Utilisateur - Intervenant - Client - Occupant - Fournisseur.

Néanmoins, il est possible au travers du dictionnaire d’ajouter une entité dans le périmètre de l’anonymisation. Pour cela, il suffit de cocher la case RGPD sur l’objet du dictionnaire, et de renseigner la durée de conservation des données. Seuls les attributs cochés RGPD sont pris en compte dans le traitement unitaire ou le traitement global d’anonymisation.

Seul l’administrateur a la possibilité (nouveau de droit de profil Système\Global\Gérer l’anonymisation) de gérer les traitements d’anonymisation (unitaire ou global).

Un traitement d’anonymisation est un traitement définitif pour lequel aucun retour en arrière n’est possible.

4.7.10. Mémo - Afficher l’expéditeur

La version 7.0.0 de CARL Source introduit la possibilité de pouvoir afficher l’expéditeur du mémo.

Dans la fonctionnalité Mémo, une case à cocher "Afficher Expéditeur" a été ajoutée et donne la possibilité d’afficher le nom et l’identifiant de l’acteur sur le mémo.

4.7.11. Rapport

4.7.11.1. Suppression de la duplication des rapports

Il n’est plus possible de dupliquer directement un rapport. Dorénavant, il est conseillé de procéder de la manière suivante :

Récupérer le fichier rptdesign depuis le rapport à dupliquer.
Modifier ce fichier rptdesign en dehors de l’application CARL Source.
Créer un nouveau rapport en téléversant le fichier rptdesign modifié.

4.7.11.2. Suppression de la police de caractères IDAutomationHC39M

Cette police de caractères permettait d’utiliser des code-barres au format Code-39 dans les rapports.
Elle n’est plus embarquée; en remplacement, la méthode javascript getBarcodeData doit être utilisée (prendre exemple sur les rapports standards eqpt_label_list.rptdesign et item_label_list.rptdesign).

4.7.11.3. Nouveau visuel de la page de login

New 7.2

Nouvelle image générique sur la page d’authentification.

Le document de bibliothèque "LEFT_LOGIN_PAGE" défini le visuel (gauche) de la page de login de l’application.
Par défaut, il est lié à la nouvelle image générique qui a une connotation métier neutre par défaut.

Un administrateur peut modifier l’URL de ce document afin de le faire pointer sur une image de même dimension mais personnalisée afin remplacer le visuel de la page login.

4.7.12. Signature

New 7.3

Une évolution de la signature électronique permet de la rendre compatible avec les utilisateurs connectés via un système Single Sign-On (SSO) en y intégrant un système d’authentification par code de sécurité à usage unique envoyé par e-mail.
Cette approche permet de :

Conserver la compatibilité avec le SSO.
Assurer la sécurité de la signature électronique.
Simplifier l’expérience utilisateur en éliminant la saisie d’un mot de passe.

Les nouveautés de cette version sont les suivantes :

Un système d’authentification par code à usage unique (OTC) est proposé pour permettre la signature électronique avec SSO, en envoyant un code par e-mail à l’utilisateur.
Le code OTC a une durée de validité limitée et est paramétrable, avec une longueur par défaut de 6 chiffres, et ne peut être utilisé qu’une seule fois.
Les utilisateurs peuvent choisir entre l’approbation par mot de passe ou par code OTC via un paramètre global dans la configuration du système.
Des adaptations de l’interface utilisateur incluent un bouton permettant de recevoir un code OTC et un champ pour saisir le code reçu, avec des contrôles pour prévenir les erreurs.
L’extension du mécanisme OTC s’applique également aux enregistrements de données sensibles, nécessitant un code pour valider l’opération.

4.7.13. Codification dynamique sur dates

New 7.3

L’objectif principal de cette amélioration consiste à rendre les codes des entités plus dynamiques et de simplifier la gestion des expressions basées sur des dates.

Voici les principes de cette amélioration :

Les codes des entités peuvent désormais être générés dynamiquement en utilisant des expressions basées sur des dates, avec un contrôle sur la longueur et la validité des expressions.
Une nouvelle colonne booléenne "Expr. interprétée" permet de sélectionner les lignes soumises à la codification dynamique, influençant l’affichage des dates dans les codes.
Un processus d’interprétation des expressions a été ajouté pour traduire les expressions en dates, et un message d’erreur est affiché si des expressions inconnues sont présentes lors de l’enregistrement.
Une action de configuration des expressions sur date a été introduite, permettant aux utilisateurs de personnaliser les préfixes et suffixes avec des expressions de date, tout en respectant les droits de modification.
Lors de la validation, des messages d’erreur ou de confirmation apparaissent selon la présence d’erreurs ou d’expressions valides, assurant une gestion efficace des modifications.

4.7.14. Mise à jour en masse des profils

New 7.3

Cette fonctionnalité permet à un administrateur CARL Source de gérer les profils en masse, en facilitant l’administration des autorisations, des paramètres de fonctionnalités et des workflows d’états. L’objectif principal est d’économiser du temps dans la gestion de multiples profils simultanément.

Une action "Administrer en masse" est ajoutée pour modifier plusieurs profils simultanément, nécessitant la sélection d’au moins une ligne.
Les profils standards ne peuvent pas être administrés en masse, et des restrictions basées sur les organisations sont appliquées.
Un formulaire dédié permet de renseigner manuellement les valeurs ou de copier les données d’un autre profil, avec une validation finale pour appliquer les changements.
Deux méthodes d’administration sont disponibles : manuelle et par recopie, avec des options pour copier les autorisations, paramètres et transitions d’état.
La validation du formulaire demande une confirmation avant d’appliquer les modifications, avec des mises à jour automatiques des domaines de profil si nécessaire.

5. CARL Touch

Cette version propose les évolutions suivantes :

Validation des CGU.
Nouveautés sur les tâches :
- Affichage d’un bloc Affectations sur le détail d’une tâche.
- Proposition des intervenants affectés lors du transfert d’une tâche.
Permettre la consultation de la planification des interventions.
Réaliser un recensement matériel.
Afficher le détail d’un mouvement de stock.

New 7.1

Option multi-environnement
Inventaire préparé partagé
Ajout d’opérations à partir d’une gamme

New 7.2

Création d’un compte-rendu
Nouveau tri des listes
Affichage en mode tablette

Davantage de détails sont disponibles au sein de Guide utilisateur CARL Touch.

Ces évolutions sont disponibles sur la version CARL Touch multiplateforme.

A partir de la version 7.1.0, les fonctionnalités existantes sur CARL Touch Android ont été reprises sur la version multiplateforme.

5.1. Nouveautés ergonomie

5.1.1. Multi environnement

New 7.1

Dans le menu Paramètres, l’utilisateur a la possibilité de paramétrer plusieurs environnements de connexion.
Sur l’écran de connexion et dans le menu général, l’utilisateur peut changer d’environnement rapidement en cliquant sur le logo de l’environnement.

5.1.2. Mode tablette

New 7.2

Pour les appareils mobiles ayant une diagonale de plus de 8 pouces en mode paysage, les écrans sont affichés en mode tablette 1/3 - 2/3.

5.1.3. Tri des listes

New 7.2

Sur toutes les listes principales, l’utilisateur peut trier à la volée sur les attributs par défaut mais également les attributs affichés dans la liste par la personnalisation.

5.2. Nouveautés tâches

5.2.1. Affectation d’une tâche

Sur la liste des tâches, l’utilisateur peut trier la liste par rapport à la date de planification des interventions.
Dans le formulaire de détail d’une tâche, le bloc d’affectations peut être affiché. Il est uniquement en lecture.
Lors du transfert d’une tâche, si des affectations sont présentes sur l’intervention, les utilisateurs affectés à celle-ci sont proposés en priorité.

New 7.1

Sur la liste des opérations, l’utilisateur peut ajouter des opérations à partir d’une gamme.

New 7.2

En création d’une tâche, l’utilisateur peut sélectionner Compte-rendu pour créer rapidement une intervention et ainsi saisir son compte-rendu.

5.3. Planification

La fonctionnalité "Planification" permet à l’utilisateur de voir les interventions qui sont planifiées pour lui.
La planification correspond aux affectations saisies sur les tâches. Il s’agit du contenu de l’onglet « Main d’Œuvre » du formulaire de détail d’une intervention dans CARL Source.
La planification est uniquement accessible en visualisation. Il n’est pas possible de la modifier depuis l’application mobile.

5.4. Recensement matériel

La fonctionnalité "Recensement matériel" permet à l’utilisateur de recenser le matériel à partir d’une localisation, d’un point principal ou d’un matériel père.
L’utilisateur a la possibilité de valider la présence d’un matériel, d’ajouter un nouveau matériel ou de casser le lien entre le matériel et le lien père sélectionné.

5.5. Nouveautés mouvement de stock

Dans la liste des mouvements de stock, l’utilisateur peut cliquer sur la ligne du mouvement pour afficher le détail du mouvement de stock.
L’écran de détail est personnalisable via les formulaires personnalisés.

5.5.1. Inventaires préparés

New 7.1

Dans les inventaires préparés, l’utilisateur peut définir des utilisateurs affectés à celui-ci. L’inventaire sera dispatché entre ces utilisateurs.
Un inventaire peut dorénavant être défini comme partagé, c’est à dire que plusieurs utilisateurs peuvent travailler en simultané sur un inventaire préparé.

5.6. Téléassistance

New 7.3

La téléassistance offre aux techniciens sur le terrain une assistance avancée incluant visioconférence, messagerie, annotations visuelles et bien plus encore. Les échanges sont enregistrés sous forme de rapports directement associés aux interventions dans CARL Source.

L’utilisation de cette fonctionnalité nécessite l’acquisition de droits complémentaires.
En savoir plus sur l’option "CARL Remote Assist (Profils technicien / gestionnaire de stock)".

Pour plus d’informations, contacter CARL Berger-Levrault.

5.6.1. Paramétrage de la téléassistance

Le paramétrage et l’accès aux fonctionnalités du module de téléassistance dans CARL Source et CARL Touch répondent aux points suivants :

L’accès au module de téléassistance nécessite l’achat d’une licence, activée par un fichier XML.
Les utilisateurs peuvent activer l’accès à la téléassistance via le paramètre de profil "Accès à la téléassistance".
Dans CARL Source, les utilisateurs autorisés voient des onglets et cases à cocher spécifiques pour les fonctionnalités liées aux experts et à la téléassistance.
Dans CARL Touch, le bouton "Téléassistance" permet de visualiser les rapports et d’accéder à la liste des experts pour les appels de téléassistance.

5.6.2. Configurer les experts

Les experts peuvent être internes ou externes à l’entreprise et n’ont pas besoin d’une connexion à CARL Source ou CARL Touch.
Un expert doit être actif et posséder une adresse e-mail pour être contacté via la téléassistance.
Les compétences des experts peuvent être associées à divers éléments comme le matériel, la localisation ou les modèles.
Un nouvel onglet permet d’associer plusieurs experts à une entité spécifique.
La configuration des experts facilite les appels de téléassistance via une webapp dédiée.

5.6.3. Appel d’un technicien

Ce paragraphe décrit comment un technicien peut initier et utiliser le module de téléassistance dans CARL Touch pour obtenir de l’aide d’experts.

L’accès à la téléassistance nécessite des droits spécifiques définis dans CARL Source.
Le technicien peut initier un appel de téléassistance à partir d’une intervention en cours en sélectionnant un expert parmi une liste proposée.
Le module de téléassistance permet d’activer/désactiver le micro et la caméra, de prendre des photos, et d’utiliser des annotations.
Un tchat intégré permet l’échange de messages et de documents entre le technicien et l’expert.
À la fin de l’appel, un rapport de téléassistance est généré et enregistré dans CARL Source.

5.6.4. Réception d’un appel par l’expert

Du côté de l’expert, la réception d’un appel de téléassistance se concrétise de la manière suivante :

Les experts reçoivent une invitation par e-mail pour se connecter à une session de téléassistance via un lien.
L’application permet de modifier la langue, activer ou désactiver le micro, le haut-parleur et la caméra avant de rejoindre la session.
Pendant l’appel, les experts peuvent prendre des photos, zoomer, accéder au tchat, et terminer l’appel.
Les photos peuvent être annotées avec des outils pour dessiner à main levée ou avec des formes, et les annotations peuvent être modifiées ou supprimées.
La fonctionnalité de tchat permet l’échange de messages textes, de fichiers et de photos annotées.

5.6.5. Visualiser les rapports de téléassistance dans CARL Touch

Les rapports de téléassistance sont accessibles à partir d’une intervention à l’état "Prise en compte" ou "Démarrée".
Le menu Téléassistance permet d’accéder à la liste des experts et à l’historique des rapports.
Chaque appel de téléassistance génère un rapport contenant les dates, heures, interlocuteurs, messages, documents et photos annotées échangées.
Les utilisateurs ne peuvent pas modifier les rapports de téléassistance via CARL Touch.
Une nouvelle action "Historique des rapports" est disponible pour consulter les rapports liés à un matériel spécifique.

5.6.6. Visualiser les rapports de téléassistance dans CARL Source

Les rapports de téléassistance sont consultables dans CARL Source :

Une nouvelle fonctionnalité "Rapports de téléassistance" est ajoutée dans le menu Interventions/Gestion, avec des onglets pour les critères de recherche et les résultats.
Les rapports de téléassistance incluent des informations détaillées telles que le code du rapport, le nom du technicien, et la durée de l’appel.
Un nouvel onglet "Détail" affiche les messages échangés, les photos annotées et les documents partagés lors des appels.
Une action "Historique de téléassistance" est disponible pour filtrer les rapports par code d’intervention ou entité initiale.
Ces améliorations visent à faciliter la gestion et la manipulation des attributs des objets dans CARL Source.

5.7. Relevés de points

New 7.3

Une nouvelle fonctionnalité nommée "Relevé" permet aux techniciens d’effectuer des relevés sur les points de mesure et sur les points de contrôle.
Cette fonctionnalité est aussi accessible à partir des équipements par une action.

La fonctionnalité "Relevé" est accessible via le menu général et nécessite des droits de profil pour y accéder.
Les relevés sont triés par date et heure, regroupés par matériel, et affichent des informations définies dans des formulaires personnalisés.
Une action "Relever à nouveau" permet de saisir de nouveaux relevés en utilisant les données initiales, avec la possibilité de modifier la date et l’heure.
Un assistant en trois étapes facilite la création de nouveaux relevés, incluant la sélection d’équipements et de points à relever.
Les relevés peuvent également être initiés directement à partir des équipements, simplifiant le processus pour les utilisateurs autorisés.

6. CARL Xpress

L’application mobile de saisie des comptes-rendus propose les évolutions suivantes :

Validation des CGU.
Tri de la liste des comptes-rendus.
Affichage des pastilles contenant le nombre de comptes-rendus présents.

Davantage de détails sont disponibles au sein du Guide d’utilisation et de configuration de CARL Xpress.

7. CARL Flash

L’application mobile de demandes de services propose les nouveautés suivantes :

Modification des informations du compte Flash.
Choix de l'onglet affiché par défaut.
Possibilité de trier la liste des demandes.
Possibilité d’afficher ou non l'étape de réception des travaux pour les utilisateurs Flash.
Ajouter plusieurs photos par demande d’intervention.
Possibilité de sélectionner la criticité dans une liste de valeurs.
Récupération de l'adresse via l’étape de géolocalisation.
Affichage du détail de la demande d’intervention.
Affichage des informations saisies sur l’étape de validation.

7.1. Création simplifiée

New 7.3

Cette évolution permet d’accélérer et de faciliter la déclaration d’incidents pour des utilisateurs occasionnels de l’application. Ainsi, il est possible d’enregistrer une demande en quelques actions seulement :

Scan d’un QR Code
Saisie du problème
Ajout d’une photo (optionnel)
Envoi de la demande

Pour davantage de détails sur ces évolutions, reportez-vous au Guide d’utilisation et de configuration CARL Flash.

Avis de marques déposées

Nous avons apporté tous nos efforts pour garantir l’exactitude des informations au moment de la publication de ce document.
CARL Source étant en constante évolution, CARL Berger-Levrault ne peut être tenu responsable des éventuels manques ou erreurs de ce document.
Si vous relevez une incohérence ou une erreur, merci de contacter le service support de CARL Berger-Levrault.

Toute reproduction, en tout ou en partie, sous quelque forme que ce soit, est formellement interdite sans l’autorisation préalable de CARL Berger-Levrault.

Toutes les marques et noms de produits mentionnés dans ce document sont les propriétés de leurs détenteurs respectifs telles que répertoriées ci-dessous :

Android™ et Google Chrome^® sont des marques déposées de Google LLC
ArcGIS^® est une marque déposée d’Environmental Systems Research Institute.
Elasticsearch^® est une marque déposée d’Elasticsearch B.V. aux États-Unis et dans d’autres pays.
Firefox^® est une marque déposée de Mozilla Foundation.
Java™ et Oracle^® sont des marques déposées d’Oracle Corporation.
PostgreSQL^® est une marque déposée de The PostgreSQL Community Association of Canada.
Safari^® est une marque d’Apple Inc., déposée aux États-Unis et dans d’autres pays.
Azure^®, SQL Server^®, Microsoft Edge^® et Windows^® sont des marques déposées de Microsoft Corporation.
Tomcat^® est une marque déposée de l’Apache Software Foundation aux États-Unis et dans d’autres pays.