La réservation de la fenêtre temporelle est créée dans Time Slot Control. Cependant, l’ordre selon lequel il faut décider de son approbation dépend de l’ERP. Comment connecter les deux mondes sans réécriture manuelle et sans interroger constamment l’API ?

L’une des options est le flux cloud automatisé dans Microsoft Power Automate. Time Slot Control envoie un webhook, Power Automate complète le contexte nécessaire via OData, vérifie la commande dans Microsoft Dynamics 365 Business Central ou Dynamics NAV et, selon le résultat, approuve la réservation ou informe le répartiteur dans Microsoft Teams.

Scénario pratique : approuver une réservation par ordre dans l’ERP

Imaginons qu’un transporteur crée une réservation pour le déchargement. L’opération ne veut l’approuver automatiquement que lorsqu’il y a une commande ouverte dans l’ERP pour l’entreprise correspondante et une date de livraison programmée.

Cette exigence ne peut être résolue par une règle simple à l’intérieur du système de réservation. La décision dépend des données actuelles dans Business Central ou NAV. Par conséquent, l’intégration combine trois interfaces :

webhook sortant de Time Slot Control comme déclencheur instantané,
OData pour récupérer la réservation et les détails de la société,
API REST pour réécrire le résultat dans Time Slot Control.

Power Automate workflow connecting Time Slot Control with Microsoft Dynamics 365 Business Central or Dynamics NAV

Comment fonctionne le flux de travail

1. Le TSC envoie l’événement sans attendre le sondage

Le flux commence avec un déclencheur HTTP dans Power Automate. Son adresse est utilisée par abonnement dans le Time Slot Control pour l’événement reservation.pending. Ainsi, l’intégration commence lorsqu’une décision doit être prise, et il n’a pas besoin de faire défiler l’API à chaque minute pour chercher des changements.

Le webhook utilise un wrapper stable avec le schéma, l’ID de l’événement, le type d’événement, le locataire, l’heure d’origine et les brèves données de réservation :

{
  "schemaVersion": "1.0",
  "eventId": "7d897a13-9ac6-4d3f-9cdb-4ad2dd943be1",
  "event": "reservation.pending",
  "tenantId": "2d90ece5-b724-49b0-a19c-08e5b0a63cda",
  "occurredAt": "2026-09-18T07:58:42Z",
  "data": {
    "id": "37efcb13-f1cb-4a61-baea-adfb4337036f",
    "approvalStatus": "pending",
    "deliveryDateUtc": "2026-09-18T08:00:00Z"
  }
}

La charge utile est intentionnellement rentable. Elle ne contient pas tout le contexte métier et ne devient pas obsolète en copiant des dizaines de champs. Power Automate ne récupère les détails nécessaires à la décision qu’à l’étape suivante.

2. Le flux complète le contexte de réservation via OData

La première action HTTP récupère les détails de la réservation de TSC, tels que son numéro, le début de la fenêtre temporelle, la source et l’utilisateur qui l’a créée. La seconde action détecte la compagnie de cet utilisateur.

C’est un détail important : la société transporteur indiquée sur la réservation n’a pas besoin d’être la même que celle dont l’utilisateur a effectué la réservation. Par conséquent, la correspondance au numéro client dans l’ERP doit correspondre au processus métier spécifique.

3. Business Central ou NAV valide l’ordre

Dans Business Central, Power Automate peut appliquer l’action standard Find records (V3) sur les commandes de vente. Un filtre typique combine le numéro client, la date de livraison requise et le statut de la commande. Vous pouvez ajouter un lieu, un entrepôt, un lieu d’atterrissage ou un identifiant d’intégration personnalisé selon les besoins.

Avec Dynamics NAV, la logique décisionnelle reste la même. Le flux fonctionne avec les données publiées via le service OData de l’installation. L’entité spécifique, les noms de champs et la méthode de connexion sont personnalisés selon la version NAV et les paramètres client.

Ainsi, Power Automate n’est pas une autre base de données. Il ne fait que coordonner les étapes et prendre des décisions sur les données actuelles dans TSC et ERP.

4. L’ordonnance trouvée approuve la réservation

Si l’ordre ouvert correspond à la réservation, le flux appelle l’action API REST pour approbation :

POST /v3/{tenant}/Reservations/{id}/Approved

Le Time Slot Control poursuit ensuite le processus standard : le changement de statut est visible pour les utilisateurs et l’opérateur peut recevoir une notification régulière selon la configuration du client. L’intégration ne contourne pas le flux de travail existant, elle automatise seulement la décision pour laquelle il dispose de suffisamment de données.

5. L’ordre manquant reste une tâche pour l’humain

Si aucune commande appropriée n’existe dans ERP, la réservation reste en état d’approbation en attente. Power Automate envoie une carte adaptative dans Microsoft Teams au répartiteur avec le numéro de réservation, l’entreprise, le rendez-vous et le lien TSC.

Le résultat n’est pas un rejet aveugle. Le répartiteur reçoit l’information au bon moment et peut vérifier la présence d’une exception, corriger la cartographie ou prendre une décision manuellement. L’automatisation résout les cas standards, on conserve le contrôle sur les cas non standards.

Pourquoi webhook plutôt que des sondages classiques

Lors des sondages, l’intégration doit demander des données à plusieurs reprises même lorsque rien n’a changé. Avec le nombre croissant de locataires, de réservations et de systèmes connectés, cela signifie un trafic inutile et une surveillance des fenêtres temporelles plus complexe.

Le webhook inverse la direction de la communication. Le TSC n’envoie un événement que lorsqu’il se produit réellement. Power Automate récupère alors uniquement les données nécessaires à une décision spécifique. Le résultat est une réponse plus rapide, moins de requêtes inutiles et une intégration plus claire.

Approbation automatisée des réservations à travers TSC et ERP

Microsoft propose son propre connecteur Power Automate pour Dynamics 365 Business Central avec des actions permettant de trouver et de travailler avec les enregistrements. Dynamics NAV peut être connecté via le connecteur approprié et le service OData publié, selon la version. La différence réside dans la connexion technique, pas dans le processus : l’événement est créé dans TSC, ERP fournit le contexte métier, et le résultat est réécrit dans TSC.

Pour plus d’informations, consultez l’aperçu des intégrations de Time Slot Control, la documentation du connecteur Dynamics 365 Business Central et le connecteur Dynamics NAV.

Où d’autre les webhooks peuvent-ils aider

L’approbation automatique des réservations n’est qu’un exemple. Le même schéma d’intégration peut être utilisé à d’autres étapes du processus pour connecter TSC à Business Central, Dynamics NAV, WMS, les systèmes de transport ou la communication d’équipe.

Enregistrement automatique de l’arrivée du véhicule

L’événement reservation.markedasarrival peut immédiatement écrire l’heure réelle à l’ERP à l’arrivée du véhicule, mettre à jour le statut de la commande concernée, et informer l’entrepôt ou le réparti dans Microsoft Teams.

Heures exactes de début et de fin de chargement

Webhooks reservation.processingstarted et reservation.processingcompleted transmettent le processus d’enregistrement à Business Central ou WMS. L’entreprise obtient ainsi des données plus précises pour évaluer l’attente, la performance des rampes et le respect des délais prévus.

Réaction immédiate aux absences du transporteur

Un événement reservation.carrier.notarrived peut créer une exception dans l’ERP, notifier le répartiteur et commencer le processus à une date alternative. Le problème commence à être résolu immédiatement, pas seulement lors d’une vérification manuelle ultérieure.

Synchroniser les changements de réservation sans réécriture manuelle

Lors du déplacement d’un rendez-vous ou d’un véhicule ou d’une agence, les événements reservation.moved, reservation.vehicle.platechanged, et reservation.driver.changed reservation.branchoffice.changed. Les systèmes aval fonctionnent donc avec les mêmes données que TSC.

Fermeture automatique du transport et étapes de suivi

Webhooks reservation.markedasdeparted et reservation.delivered peuvent conclure le transport ou la commande en ERP après le départ ou la livraison, remettre les documents pour documentation et initier les étapes ultérieures de la facturation.

Voulez-vous vérifier un processus similaire sur vos propres données ?

Le même schéma peut être utilisé non seulement pour l’approbation des réservations, mais aussi pour la revue des commandes, l’affectation des rampes, la synchronisation de statut ou les alertes de données manquantes. D’abord, le scénario est validé dans le bac à sable TSC et l’environnement de test ERP, et ce n’est qu’ensuite que les systèmes de production sont connectés.

Contactez-nous. Ensemble, nous concevrons un flux de travail d’intégration selon vos processus, permissions et une version spécifique de Business Central ou Dynamics NAV.