Otter Beam / Guides
Comment les données circulent dans Otter Beam Workspace
Par Otter Digital Pte. Ltd. · Mis à jour le 17 octobre 2026
Otter Beam Workspace réunit Sales & CRM, Achats et Gestion de projet dans une seule base de données d’entreprise, sur l’ordinateur de l’entreprise. Quand un événement dans un module intéresse un autre module, Otter Beam le lui transmet automatiquement. Nous appelons chacune de ces transmissions un transfert. Cette page liste tous les transferts : ce qui les déclenche, ce qu’ils créent ou modifient, quand ils ne font rien, et ce qui se passe quand ils ne peuvent pas aboutir.
Comportement de chaque transfert
- Au même instant, dans la même base. Un transfert s’exécute dans la même transaction de base de données que l’action qui l’a déclenché. Soit les deux sont enregistrés, soit aucun : personne ne voit jamais un état à moitié terminé.
- Votre action compte toujours. Si le transfert lui-même ne peut pas aboutir (par exemple parce qu’un fournisseur est suspendu), l’action qui l’a déclenché est quand même enregistrée. Un devis accepté reste accepté même si l’étape suivante échoue. Le transfert en échec est annulé séparément et signalé.
- Enregistré par « Otter Beam ». Les enregistrements qu’un transfert crée ou modifie sont écrits par le système, pas par une personne ni par l’agent, et chaque modification entre dans le journal d’audit avec les valeurs avant / après et le numéro du transfert (F1–F8) en commentaire.
- Visible dans Data health. Chaque exécution est consignée comme OK, Skipped (rien à faire) ou Failed, avec le motif exact. Une exécution en échec ouvre aussi une erreur. Une fois la cause corrigée, les exécutions en échec peuvent être relancées depuis Data health ; la relance ne refait que la partie restante. Les erreurs peuvent être marquées comme résolues.
- Les enchaînements sont limités. Un transfert peut en déclencher un autre (un devis accepté crée une commande client, qui crée un projet). Les chaînes s’arrêtent après quatre étapes : une erreur de configuration ne peut donc jamais provoquer de boucle.
- Aucune ressaisie. Chaque ligne créée renvoie à la ligne dont elle provient : quantités, prix et avancement se suivent du devis jusqu’au paiement final.
Circuit des ventes
| # | Se déclenche quand | Ce qu’il fait | Ne fait rien quand | Échoue quand |
|---|---|---|---|---|
| F1 | Un prospect est converti | Crée le client (entreprise ou particulier) si le prospect n’en a pas, un contact principal si le prospect en nomme un, et une opportunité liée aux deux. Le prospect est marqué comme converti. | — | Les enregistrements ne peuvent pas être créés (le motif s’affiche dans Data health). |
| F2 | Un devis est accepté | Crée une commande client confirmée avec le numéro de commande suivant, en copiant toutes les lignes du devis et l’adresse du chantier ; marque le devis comme converti et l’opportunité comme gagnée. Un devis d’avenant ajoute à la place ses lignes à la commande d’origine et met à jour ses totaux. | — | La commande ne peut pas être créée. Le devis reste accepté. |
| F3 | Une commande client est confirmée (y compris par F2) | Si la commande contient des articles qui lancent un projet, crée le projet (budget = sous-total de ces lignes) et ses tâches à partir du modèle de projet, avec des dates en séquence et des dépendances fin-début entre elles. | La commande ne contient aucun article de projet, ou a déjà un projet. | Aucun modèle de projet n’est disponible. La commande reste confirmée. |
| F8 | Un paiement est confirmé, affecté ou annulé ; une facture est émise ou annulée | Recalcule les montants payés et restant dus de chaque facture et facture fournisseur concernée, et les passe à « partiellement payée » / « payée » ; met à jour le "Invoiced x% · Paid y%" de la commande client et l’état de paiement du bon de commande. Seuls les paiements confirmés comptent. | Le paiement n’est encore affecté à rien. | — |
| — | Une facture est créée à partir d’une commande client qui n’a pas encore de lignes | La préremplit : une facture standard reprend les quantités pas encore facturées ; une facture d’acompte ou de situation ajoute une ligne au pourcentage convenu, moins les demandes précédentes. | — | — |
Circuit des achats
| # | Se déclenche quand | Ce qu’il fait | Ne fait rien quand | Échoue quand |
|---|---|---|---|---|
| F4 | Une demande d’achat est créée pour un projet | Rattache la demande au projet. Les lignes ajoutées sans prix sont préremplies avec le dernier prix du fournisseur préféré (ou le prix le plus bas connu quand aucun fournisseur n’est préféré). | — | — |
| F5 | Une demande d’achat est validée | Répartit la demande en un bon de commande brouillon par fournisseur, au dernier prix d’achat de chacun. Quand toutes les lignes sont sur un bon de commande, la demande passe à « commandée ». | — | Un fournisseur est suspendu ou bloqué, ou une ligne n’a pas de fournisseur ("Vendor Tampines Paint & Coatings is on hold."). Les commandes des autres fournisseurs sont quand même créées ; "Retry later" ne crée que celles qui manquent. |
| F6 | Une réception de marchandises est enregistrée | Ajoute les quantités reçues aux lignes du bon de commande et fait passer la commande à « partiellement reçue » / « reçue » ("Received 90%"). | — | — |
| F7 | Une facture fournisseur est créée à partir d’un bon de commande, ses lignes changent ou elle est validée | Préremplit la facture à partir du bon de commande, puis compare la quantité et le prix facturés à ce qui a été reçu (rapprochement à trois) : conforme, écart de quantité ("Qty mismatch: billed 40, received 38"), écart de prix, ou pas encore de réception. À la validation, enregistre sur le bon de commande ce qui a été facturé. | — | — |
Projets
| Se déclenche quand | Ce qu’il fait |
|---|---|
| Une tâche démarre | Refusé tant qu’une tâche dont elle dépend n’est pas terminée ("Waits for: Site survey"). |
| Une dépendance est ajoutée | Refusé si cela créait une boucle. |
| Des tâches, des affectations, des estimations ou des heures saisies changent, ou F3 crée des tâches | Recalcule la charge hebdomadaire de chaque personne concernée pour les semaines à venir ; la vue Workload affiche les surcharges en rouge. |
Ce que l’agent IA peut et ne peut pas faire
L’agent n’écrit jamais directement dans la base de données. Il envoie des requêtes structurées qui passent par les mêmes règles qu’une personne : la même validation, les mêmes transferts, le même journal d’audit. Les brouillons qu’il crée n’ont aucun effet sur l’activité tant qu’ils ne sont pas approuvés ; tout ce qui engage l’entreprise (valider, envoyer, payer) attend sur une carte d’approbation que le dirigeant approuve ou refuse, généralement depuis son téléphone. L’accès en lecture de l’agent se limite à des requêtes structurées en lecture seule. Toute réponse contenant des données personnelles (noms, e-mails et numéros de téléphone des contacts et du personnel) est signalée comme telle, et l’agent a pour consigne de ne l’utiliser que pour la tâche en cours.