is@dom

Introduction à l'interface OPTITIME NFS

Pour les structures équipées du logiciel d’optimisation des tournées NFS (Nomadia Field Service), certains rendez-vous is@Dom seront gérés directement par cette interface.
Le principe est : is@dom génère des besoins et NFS renvoie des rendez-vous.

Liste des données interfacées avec NFS :
-    Création/mise à jour des tiers (customers)
     => tous les types de tiers ayant les paramètres Synchroniser sur NFS et Synchroniser les tiers cochés.
-    Création/mise à jour des intervenants (workers)
     => tous les intervenants avec « Planification par OptiTime » coché et dont l’antenne est paramétrée pour utiliser NFS
-    Création des besoins (jobs) / des rendez-vous O2L ou de livraisons planifiées
     => tous les besoins (besoins prévisionnels ou besoins manuels) des types de visites avec « Rendez-Vous OptiTime » coché
     => tous les rendez-vous liés à des tournées O2 ou de livraisons planifiées pour lesquels le type de visite est coché « Rendez-vous OptiTime »
     Les jobs sont préfixés avec un R.

Les deux applications dialoguent entre elles :
•    is@Dom vers NFS : via une notification à l’api paramétrée, sur la route paramétrée
•    NFS vers is@Dom : via une notification qui pointe sur l’api « api-isadom-V2 »

Attention, le traitement des notifications is@Dom vers NFS et NFS vers is@Dom sont à votre charge (le développement de ces interfaces n’a été analysé).

Paramétrage à mettre en place

. Paramétrer les routes : Paramètres généraux - volet Planning Visites - onglet NFS (Nomadia)
. Annuaire - Type de tiers
. Planification Visites - Type de visite
. Personnel interne : cocher Planification par OptiTime
. Antenne : Cocher Les tiers de cette antenne sont synchronisés sur NFS

is@dom vers NFS

Tiers (customers)

Les tiers sont synchronisés sur NFS dès qu’ils sont créés ou modifiés.
Les conditions de synchronisation sont les suivants :
•    Le paramétrage général Synchroniser les tiers est coché
•    Le type de tiers est coché Synchroniser sur NFS
•    L’antenne du tiers est cochée Les tiers de cette antenne sont synchronisés sur NFS
•    L’antenne n’est PAS cochée Les tiers de l'antenne ne sont pas synchronisé vers les logiciels d’optimisation de tournée
•    Le tiers a une Adresse principale saisie.

Données synchronisées : Cette interface est à la charge de la structure ; export vers NFS des données choisies.

Personnel interne (workers)

Pour le personnel interne coché Planification par OptiTime, la modification de ses informations va synchroniser sur NFS.

Données synchronisées : Cette interface est à la charge de la structure ; export vers NFS des données choisies.

Besoins prévisionnels ou manuels (jobs)

L’écran d’export des prévisionnels vers une interface de planification de tournées permet de sélectionner les besoins que l’on souhaite exporter vers NFS.
La validation de la liste des besoins à exporter va notifier l’api paramétrée sur la route « Service de notification » qui va réaliser le traitement.
Cette interface est à la charge de la structure ; export vers NFS des données choisies.

Les besoins (jobs) devront être manipulés depuis NFS pour pouvoir devenir des rendez-vous dans is@dom.
Le fonctionnement est identique pour les besoins manuels, à la différence qu’on peut préciser dans un besoin manuel, les types de prestation ainsi que les intervenants pour le besoin.
Cette interface est à la charge de la structure ; export vers NFS des données choisies.

Rendez-vous issus des tournes (O2 / planifiées)

Selon le paramétrage général Exporter les tournées O2 et/ou Exporter les tournées de livraisons planifiées, is@Dom va synchroniser les rendez-vous issus du calcul des tournées vers NFS.
La synchronisation est toujours réalisée via une notification (asynchrone) à l’api paramétrée.
Cette interface est à la charge de la structure ; export vers NFS des données choisies.

NFS vers is@dom

La mise à jour d’un « job » dans NFS va devoir appeler la route de l’api-isadom-V2 : /api-isadom-V2/externe/optitime-nfs/rendez-vous avec dans le corps.
Cf. documentation de l’api : https://api-isadom-v2-documentation.ads31.com/docs/nfs/overview

Ces actions sont réalisées par l’api-isadom-V2

Selon l’état du job, l’api-isadom-V2 va :
·  Créer un rendez-vous
·  Mettre à jour un rendez-vous
·   Annuler un rendez-vous
·  Lier un « job» à un « besoin » ou un « rendez-vous » selon son origine

Déterminer si le « job » est un « rendez-vous » pour is@Dom

Les conditions suivantes doivent être réunies pour qu’un « job » puisse devenir un rendez-vous, il faut :
· Un tiers visité
· Un intervenant précisé
· Un type de visite précisé
· Une date de planification
· Une heure de début et une heure de fin
· L’état « status » doit être (au choix)
     o   Planifié (2)
     o   Accepté (28)
     o   Réservé (30)
     o   Terminé (31)

Si le rendez-vous est possible, on va chercher s'il existe un rendez-vous lié à l’identifiant du « job »
· Créer le rendez-vous (si aucun rendez-vous lié trouvé)
· Mettre à jour le rendez-vous   
· Annuler le rendez-vous si on a un rendez-vous lié et que le rendez-vous n’est plus possible

Le traitement des rendez-vous issu du calcul de tournées (O2/planifiées) est spécifique.
Dans ce cas, c’est is@Dom qui décide de la date et de l’intervenant qui fait le rendez-vous.
Pour cette raison, seules les heures du rendez-vous et les commentaires sont mis à jour.
Ne pas modifier ces rendez-vous directement dans NFS (date, intervenant, annulation) sous peine de ne plus être synchronisé entre is@dom et NFS.

Communications entre les systèmes

is@Dom et NFS s’appuient sur une api à la charge de la structure :
• Api (externe à votre charge)
   o Traite les notifications envoyées par is@dom pour envoyer les données
   o Traite les modifications des « job » notifiés à l’api-isadom-V2

Une étude peut être réalisée par ADS pour des traitements manquants dans le process :
• Tiers vers NFS
• Personnel interne vers NFS
• Géo-codage des adresse par NFS
• Envoi des besoins vers NFS
• Envoi des rendez-vous O2 / planifiés vers NFS
• Récupération des « jobs » de NFS vers api-isadom-V2
   (le traitement existe, il manque le contrat d’interface entre NFS et l’api)

Système de notifications

Is@dom synchronise avec NFS en envoyant des notifications à une api.
Une notification est un objet JSON :

x
 {
  "notificationID": 0,
  "action": "string",
  "objetType": "string",
  "objetID": "string",
  "dataComplementaire": "string",
  "etat": "string",
  "creePar": "string",
  "creeLe": "string",
  "modifiePar": "string",
  "modifieLe": "string",
  "etatInformation": "string"
}
 

Chaque notification doit comporter des données en fonction du type d’action et d’objet demandé.
La liste est détaillé sur https://api-isadom-v2-documentation.ads31.com/docs/notifications/overview

 

 

 

 

© ADS - 2024