Introduction à l'interface ANTSROUTE

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

Liste des données interfacées avec AntsRoute :
- Création/mise à jour des tiers (customers) => tous les types de tiers ayant les paramètres Synchroniser sur AntsRoute et Synchroniser les tiers cochés.
- Création/mise à jour des intervenants (agents) => tous les intervenants avec un compte AntsRoute paramétré sont synchronisés
- Création des besoins (orders) / des rendez-vous O2L ou de livraisons planifiées
  => tous les besoins (besoins prévisionnels ou besoins manuels) des types de visites avec Code AntsRoute paramétré
  => tous les rendez-vous liés à des tournées O2 ou de livraison planifiées pour lesquels le type de visite a le Code AntsRoute paramétré
Les orders sont préfixés avec un R.

Les 2 applications dialoguent entre elles :
. is@dom vers AntsRoute : via une notification à l’api « api-isadom-V2 »
. AntsRoute vers is@dom : via une notification non bloquante (webhook) qui pointe sur l’api « api-antsRoute »

Paramétrage à mettre en place

Application - Paramètres généraux - volet Planning Visites - onglet AntsRoute
Annuaire - Type de tiers
Planification Visites - Type de visite
Prestation - Type de prestations: Paramétrer le Code AntsRoute
Prescriptions - Code de prescription : Paramétrer les Code AntsRoute
Personnel interne : Indiquer le compte AntsRoute
Antenne : Case à cocher Les tiers de cette antenne sont synchronisés sur AntsRoute

is@Dom vers AntsRoute

Tiers (customers)

Les tiers sont synchronisés sur AntsRoute dès qu’ils sont créés ou modifiés.

Les conditions de synchronisation sont les suivantes :
. Le paramétrage général Synchroniser les tiers est coché
. Le type de tiers est coché Synchroniser sur AntsRoute
. L’antenne du tiers est cochée Les tiers de cette antenne sont synchronisés sur AntsRoute
. 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 à une adresse principale saisie.

Données synchronisées :
. Nom
. Prénom
. Adresse
. Coordonnées GPS de l’adresse
. Téléphone fixe (de l’adresse principale)
. GSM
. Émail
. Informations
. Référence externe (type de tiers + code annuaire : PAT0001 par exemple)
. Champs annexes (patients uniquement)
    Liste des codes de prescription en cours du tiers
    Date de naissance
    Nom de l’antenne du tiers
    Sorti O/N
Consigne (bloc-notes)
. Intervenants préférés
. Intervenants interdits
. Temps de parking (en minutes)
. Préférences de passage de l’adresse principale

Personnel interne (agents)

Pour le personnel interne avec un Compte AntsRoute paramétré, la modification de ses informations va synchroniser sur AntsRoute.
Données synchronisées :
. Nom
. Prénom
. GSM
. Émail
. Référence externe (type de tiers + code annuaire : INT0001 par exemple)
. Compétences (skills) selon les habilitations et avec un « Code AntsRoute » paramétré
    Types de visites possibles
    Types de prestations possibles (selon le paramétrage général Utiliser la compétence PRESTA
    Codes de prescription possibles (selon le paramétrage général Utiliser la compétence FORFAIT

Besoins prévisionnels ou manuels (orders)

L’écran d’export des prévisionnels vers une interface de planification de tournée permet de sélectionner les besoins que l’on souhaite exporter vers AntsRoute.

La validation de la liste des besoins à exporter va notifier l’api-isadom-V2 qui va réaliser le traitement.
Cette fonctionnalité est asynchrone, is@dom n’attend pas le résultat de l’export.

Les besoins (orders) sont placés dans le panier sur AntsRoute, et devront être manipulés depuis AntsRoute 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.

Données synchronisées dans le panier (basket) :
. Tiers visité (si le tiers n’existe pas dans AntsRoute il est ajouté automatiquement)
. Date min
. Date max
. Créneau
. Champs annexes
    Type de visite (obligatoire, ne doit pas être modifié dans AntsRoute)
. Durée (minutes)
. Localisation de la visite
    Adresse spécifique
    Ou Localisation du tiers
. Contraintes (skills) selon paramétrage (FORFAITS et/ou PRESTA)Conditions : Paramétré avec un « Code AntsRoute », en cours pour le tiers, compatible avec le type de visite.
    Liste des « CodeAntsRoute » des codes de prescription
    Liste des « CodeAntsRoute » des types de prestation

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 AntsRoute.
La synchronisation est toujours réalisée via une notification (asynchrone) à l’api-isadom-V2.

A la différence des besoins, les « orders » sont envoyés directement dans le planning et pas dans le panier sur AntsRoute.

Données synchronisées dans le planning
. Même données que pour le panier (basket)
. Dates de planification (scheduledDate)
. Intervenant obligatoire (mandatoryAgent)
  C’est l’intervenant prévu dans le RDV is@dom si il a un « Compte AntsRoute »
. État : planifié (PLANNED)

AntsRoute vers is@Dom

La mise à jour d’un order dans AntsRoute va déclencher une webhook qui va communiquer avec l’api-antsroute pour indiquer qu’une action a été réalisée sur un order et qu’il faut réaliser des actions dans is@Dom.

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

Selon l’état de l’order et le type de notification envoyée (action), l’api-isadom-V2 va :
. Créer un rendez-vous
. Mettre à jour un rendez-vous
. Annuler un rendez-vous
. Lier un « order » à un « besoin » ou un « rendez-vous » selon son origine

Déterminer si l’order est un rendez-vous pour is@Dom

Les conditions suivantes doivent être réunies pour qu’un order puisse devenir un rendez-vous :
. Il faut un tiers visité
. Il faut un intervenant précisé (affectedAgent)
. Il faut un type de visite précisé (champ annexe : TYPEVISITE)
. Il faut une date de planification (scheduledDate)
. Il faut une heure de début et une heure de fin
. L’état « state » doit être, au choix :
    Planifié (PLANNED)
    Confirmé (CONFIRMED)
    Terminé (DONE)
    En cours (IN_PROGRESS)
    Ajourné/reporté (POSTPONED)

Si le rendez-vous est possible, on va chercher s'il existe un rendez-vous lié à l’identifiant de l’order :
. Créer le rendez-vous (si aucun rendez-vous lié existant)
. 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 issus 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.
Il ne faut pas modifier ces rendez-vous directement dans AntsRoute (date, intervenant, annulation) sous peine de ne plus être synchronisé entre is@dom et AntsRoute.

Communications entre les systèmes

is@Dom et AntsRoute s’appuient sur des API :

. api-isadom-V2
Traite les notifications envoyées par is@dom pour envoyer les données
Traite les modifications des « order » notifiés à l’api-antsroute par l’api de l’éditeur AntsRoute

. api-antsroute
Traite les demandes d’interface entre l’api-isadom-V2 et l’api de l’éditeur AntsRoute
Traite les demandes d’interface entre l’api de l’éditeur AntsRoute et l’api-isadom-V2(via un webhook)

. capi (antsRoute)
Envoie les informations de mise à jour d’un « order » à l’api-antsroute(via un webhook)

Diagrammes de communication