Compte
Mon compte
Affichage
Clés d'accès (sans mot de passe)
Une clé d'accès (empreinte, visage, code du téléphone ou de l'ordinateur) remplace le mot de passe sur cette instance de VIVA. Elle sert aussi quand une application vous demande de vous connecter.
Connecter un assistant ou un agent (MCP)
Adresse du serveur MCP de cette instance, à donner à Claude ou à tout autre client MCP : il vous demandera de vous connecter à VIVA, puis agira avec vos droits.
Pour un agent sans écran (Agora, script) : créer un jeton personnel et l'envoyer dans l'en-tête Authorization: Bearer …. Le jeton agit avec vos droits ; il ne s'affiche qu'une fois.
Copiez ce jeton maintenant : il ne sera plus affiché.
Applications connectées
Applications
Mécanismes
Statuts
Origines
Dernières recherches
Flux
| #ID | Nom | Source | Cible | Mécanisme | Type de données | Statut | Fréquence | Criticité | Origine | Actions |
|---|---|---|---|---|---|---|---|---|---|---|
| Aux. |
Graphe simplifié
Vue macro : une flèche = au moins un flux dans cette direction. Voir Schéma détaillé pour le détail flux par flux.
Schéma détaillé des flux
Chaque flèche = un flux individuel. Inspiré du schéma SnapLogic Pipeline (Parent).
Flux connectés
Données transitant
Entités de données
Applications
Entités de données
| Nom | Catégorie | Source maître | Description | Actions |
|---|---|---|---|---|
Base de connaissances
Infrastructure, sources, flux de données — Cartographie complète du SI idverde
Analyse des couvertures
Analyse les métadonnées de chaque flux (origine, mécanisme, protocole, IDs Althéa) pour déterminer automatiquement dans quelles sources il est documenté : MDM Althéa, SnapLogic, Script Python, SFTP.
Vue d'ensemble ✕ fermer
Tous les flux Toutes les applications Flux actifs Flux inactifs / désactivés Flux autres
L'écosystème applicatif idverde
Le SI d'idverde France s'articule autour d'un noyau central — SPOCK (ERP métier) — connecté à une dizaine d'applications spécialisées via des flux automatisés et manuels.
Noyau opérationnel
SPOCK gère les chantiers, la facturation, les visites terrain. C'est la source de vérité pour les codes chantier et l'analytique métier.
Pôle Finance
Arcole (Cegid) centralise la comptabilité. Tous les flux financiers transitent via des fichiers plats (CSV/XML) déposés sur SFTP.
Couche d'intégration
SnapLogic (iPaaS) orchestre les échanges entre applications. 20 projets en production, 12 actifs, 183 pipelines au total.
Applications du SI
SPOCK
ERP métier — chantiers, facturation, visites. Source de vérité des codes chantier. Remplace HKA3.
Arcole (Cegid)
Comptabilité / Finance. Lots toutes les 15 min, rejet total si 1 erreur. Remplacement prévu ~2027.
Coupa
Achats / Procurement. Initiation fournisseurs, bons de commande, approbations.
Itesoft
Dématérialisation factures / BL. Traitement OCR, workflow de validation BAP.
SnapLogic
iPaaS — orchestre tous les flux entre applications. 20 projets PROD, 42 tasks planifiées.
ADP Decidium
RH / Paie. Synchronisation des employés vers SPOCK pour les affectations chantier.
Comment circulent les données
Les données transitent entre les applications via 3 mécanismes principaux, chacun avec ses forces et faiblesses.
SnapLogic (iPaaS)
Plateforme d'intégration managée. Pipelines visuels, orchestration CRON, connecteurs natifs (Coupa Snap Pack).
Script Python (Rappro)
Patch temporaire remplaçant le flux SnapLogic ITESOFT→SPOCK désactivé. Appels API directs.
Fichiers plats (SFTP)
CSV et XML déposés sur serveur SFTP. Quasi-totalité des flux comptables Arcole passent par ce canal.
Cycles métier couverts
Deux cycles principaux structurent les flux de données.
P2P Purchase-to-Pay (Cycle Achats)
O2C Order-to-Cash (Cycle Ventes)
Sources de données consolidées
Cette base de connaissances agrège 4 sources d'information complémentaires pour établir la cartographie la plus complète possible.
MDM Althéa (2025)
Travail de Master Data Management réalisé par Althéa (avr–nov 2025). 113 flux recensés, 39 systèmes, 135 champs documentés. Référence exhaustive mais datée — inclut encore HKA3.
SnapLogic (PROD)
Extraction directe de l'espace idverdePrd (mars 2026). 20 projets, 183 pipelines, 86 flux SnapLogic référencés. Source la plus fiable pour les flux automatisés actuels.
Script Python Rappro
Patch temporaire développé pour remplacer le flux ITESOFT→SPOCK désactivé. Contient des règles de gestion métier absentes de SnapLogic. Solution critique mais fragile.
Tâches planifiées (SFTP)
Flux par fichiers plats (CSV/XML) déposés sur serveur SFTP. Principalement les flux comptables Arcole et les exports Decidium/ADP. Pas de monitoring centralisé.
Audit de revalidation — Couverture des sources
Vérification croisée : chaque source de données a été auditée pour confirmer que 100% de ses flux sont bien intégrés dans la base consolidée.
| Source | Éléments source | Flux en base | Résultat |
|---|---|---|---|
| Excel SnapLogic | 183 pipelines / 20 projets * | 86 flux SnapLogic | 100% |
| MDM Althéa | 113 flux documentés (dont 77 avec FL ID ***) | 113 flux référencés dans MDM Althéa | 113/113 |
| Scripts Python Rappro | 14 modules d'extraction | 7 flux Python (IDs 81, 86–91) | 7/7 |
| Tâches planifiées Windows | 25 tâches planifiées ** | 22 flux serveur (IDs 110–131) | 100% |
| Doc SnapLogic + Itesoft | 14 specs + 23 design mappings | Flux correspondants en DB | 100% |
* 183 pipelines → 86 flux : Un pipeline SnapLogic est une étape technique, pas un flux métier. Chaque flux logique (ex: "Comptabilisation Itesoft → Arcole") est porté par un pipeline principal, mais s'accompagne de plusieurs pipelines techniques. Les 183 pipelines sont consolidés en 74 flux initiaux (53 principaux + 21 auxiliaires) + 12 flux ajoutés lors de la réconciliation approfondie = 86 flux SnapLogic.
Pourquoi les garder ? Les replays et exécutions manuelles sont déclenchés par les équipes pour corriger des erreurs — c'est un indicateur de fragilité d'un flux. Les routines d'erreur documentent la gestion des échecs. Les 12 flux ajoutés correspondent à des routes réelles vers des destinations qui étaient masquées dans la hiérarchie parent/child SnapLogic.
** 25 tâches Windows → 22 pertinentes : Sur les 25 tâches planifiées du serveur Arcole/SFTP, 3 ne sont pas des flux de données et ont été exclues :
Ces 3 tâches relèvent de la maintenance système, pas de l'intégration de données. Les 22 restantes sont de véritables transferts de fichiers entre applications.
*** FL ID (Flux ID Althéa) : Identifiant unique attribué par Althéa à chaque flux dans leur cartographie (format : FL001, FL052, FL108…). Sur les 113 flux du MDM Althéa, 77 ont été rattachés à un FL ID dans notre base — c'est-à-dire qu'on a pu faire la correspondance entre le flux Althéa et un flux de notre cartographie consolidée. Les 36 restants sont des flux Althéa documentés mais qui n'ont pas de correspondance directe (flux UK/filiales, flux entre systèmes hors périmètre, ou flux trop génériques pour être mappés à un flux technique précis).
⚠ Pourquoi ≠ ? Ce tableau est un audit de couverture par source, pas une addition. Un même flux peut être documenté dans plusieurs sources : il est alors compté dans chaque ligne, mais n'existe qu'une seule fois en base.
Chaque ligne répond à la question : "de cette source, a-t-on perdu des flux ?" — pas "combien de flux uniques viennent de là".
ℹ Lien avec la matrice de couverture détaillée (en bas de page) : Ce tableau compte les flux par mécanisme d'exécution (86 flux SnapLogic, 22 tâches Windows…). La matrice en bas utilise des cases à cocher par source documentaire : pour chaque flux, dans quels documents de référence a-t-on trouvé de la documentation ? Un flux SnapLogic peut être documenté à la fois dans l'Excel SnapLogic, le MDM Althéa et les specs Itesoft. Les deux vues sont complémentaires : ce tableau = "d'où vient le flux techniquement", la matrice = "où est-il documenté".
Réconciliation : 183 pipelines Excel → 86 flux en BDD
L'onglet Pipeline de l'Excel SnapLogic liste 183 pipelines techniques. Après réconciliation approfondie (analyse parent/child), notre base en contient 86 flux SnapLogic. Voici la décomposition complète.
Pourquoi garder les 21 auxiliaires ?
Les replays et exécutions manuelles sont déclenchés par les équipes pour corriger des erreurs — c'est un indicateur de fragilité d'un flux. Les routines d'erreur documentent la gestion des échecs. Ils sont visibles et filtrables dans le schéma (toggle « Masquer auxiliaires »).
Détail des 12 flux découverts (réconciliation approfondie parent/child) :
💡 Principe clé : L'Excel compte des objets techniques (chaque pipeline = 1 ligne). Notre BDD compte des flux de données fonctionnels (chaque transfert logique entre 2 systèmes = 1 flux). La réconciliation approfondie a révélé 12 routes supplémentaires cachées dans la hiérarchie parent/child — des destinations réelles qui n'apparaissaient pas au niveau du pipeline parent.
📌 Note : En plus des 86 flux SnapLogic, 2 flux Coupa natifs (intégration fichier CSV vers Itesoft) ont été identifiés — ceux-ci ne passent pas par SnapLogic. Total BDD : 158 flux tous mécanismes confondus.
Périmètre de la base de données
Applications référencées mais non reliées à aucun flux.
Flux dans le périmètre du projet VIVA × VPWhite
Comment ce décompte est-il calculé ?
Filtrage du périmètre projet
Seuls les flux dont la source ET la cible (mode strict) font partie des applications du périmètre sont retenus, avec les statuts : .
| Catégorie | Périmètre | Total BDD | Exclus | Pourquoi |
|---|---|---|---|---|
| SnapLogic principaux | ✓ | |||
| Auxiliaires SnapLogic | ✓ | |||
| Script Python (Rappro) | ✓ | |||
| Tâches planifiées (SFTP) | ✓ | |||
| Total |
Formule de convergence :
= snap princ. + python + sftp + aux.
Détail de la classification technique
• SnapLogic — flux ayant snap_project + snap_pipeline. Les auxiliaires (Replay_, Manual_, _Errors…) sont comptés séparément.
• Script Python — flux avec src_python_rappro = true SANS pipeline SnapLogic.
• Tâche planifiée — flux avec src_sftp_tasks = true SANS SnapLogic ni Python.
Priorité : SnapLogic > Python > SFTP. Le flag is_auxiliary classe un flux mais ne l'exclut pas du total.
Pourquoi certains flux sont exclus du périmètre ?
Le mode strict exige que source ET cible soient dans les apps du périmètre. Les flux impliquant HKA3 (ERP déprécié) ou des apps périphériques (Acciline, BlueKanGo, Cash On Time, Sage, Active Directory…) sont donc exclus. Ils restent visibles dans le widget "4 quadrants" qui opère sur l'intégralité de la BDD.
| ID | Pipeline / Flux | Route | Statut | Origine | Sources |
|---|---|---|---|---|---|
|
MDM ✓
Absent MDM
|
|||||
| actifs, inactifs | |||||
⚠ du périmètre : le flux #14 — 01_Send_and_Clean_GR_Errors (Coupa → HKA3) est filtré car HKA3 n'est pas dans les applications du scope projet. En BDD, il existe bien flux auxiliaires au total.
| ID | Pipeline | Route | Projet | Statut | Type aux. |
|---|---|---|---|---|---|
| actifs, inactifs | |||||
Par statut
Par mécanisme
Par origine
Écarts entre sources — SnapLogic vs MDM Althéa ✕ fermer
✓ Vérification : + + + = flux
Points d'attention
Couverture par source
Matrice de couverture détaillée
Cliquez sur les niveaux de couverture ou sources pour filtrer le tableau.
Chargement de l'analyse…
| # | Nom du flux | Source → Cible | Score | Statut | |||||
|---|---|---|---|---|---|---|---|---|---|
| → | |||||||||
| Aucun flux ne correspond aux filtres | |||||||||
Chargement…
Alertes
Calculées en temps réel — corrigez la cause, l'alerte disparaît automatiquement
Simulation « What-If »
Simulez la suppression ou désactivation d'un élément| Sévérité | Message | Catégorie | Flux |
|---|---|---|---|
| — |
Aucune alerte — tout est en ordre
Exports & Import
Base de données
Partage entre collègues (Guillaume, Rami...)
Exportez le fichier SQLite complet pour le partager avec un collègue. Il pourra l'importer pour avoir exactement les mêmes données.
Télécharger la BDD (.db)Importer une BDD reçue d'un collègue :
Exports Excel
Pour le client (livrables idverde)
Fichiers Excel formatés et prêts à livrer. En-têtes stylisées, couleurs par catégorie, colonnes ajustées.
Export Technique
Tous les flags, champs internes et valeurs de référence
Export Excel brut avec tous les champs techniques : 5 flags booléens source, projets/pipelines SnapLogic, valeurs de référence, légende des champs et métriques calculées. Permet de comprendre ce qui alimente le Graphe, le Schéma détaillé, les Alertes et la Comparaison.
Export Technique (6 onglets)Onglets : Flux (26 colonnes) · Applications · Données · Valeurs de référence · Légende · Métriques
Export JSON
Données structurées (technique)
Export JSON complet de toutes les données. Utile pour intégration avec d'autres outils ou sauvegarde technique.
Valeurs de référence
Gérez les listes déroulantes : mécanismes, statuts, origines, criticités, écosystèmes, types…
Mécanismes
Cochez les mécanismes pré-sélectionnés au lancement. Vide = tous.
Statuts
Cochez les statuts pré-sélectionnés au lancement. Vide = tous.
Origines source
Cochez les origines pré-sélectionnées au lancement. Vide = toutes.
Applications (scope)
Applications pré-cochées dans le scope global. Vide = toutes.
Ajouter une valeur
| Valeur | Label | Couleur | Ordre | Défaut | Actif | Utilisations | Actions |
|---|---|---|---|---|---|---|---|
|
|
Défaut | 0 |
|
||||
| Aucune valeur pour cette catégorie | |||||||
Flags techniques
Gérez les booléens de source et classification sur chaque flux. Modifiez directement dans le tableau.
| # | Flux | Source | Cible | Statut | 🔒 | |
|---|---|---|---|---|---|---|
Utilisation
Qui utilise VIVA et pour quoi : pages ouvertes, fonctions appelées (interface, jetons) et outils utilisés par les agents (MCP). Les modifications sont dans l'Audit. Gardé 180 jours.
Accès non autorisé
VIVA monitoring
La chaîne de la phase 1 dans SnapLogic : chaque pipeline, ce qu'il lit et écrit, sa criticité, ses paramètres, et le détail de chaque étape (snap) avec sa note et ses réglages. Cliquer un flux pour l'ouvrir.
Schémas : · Fiches : · Dernières exécutions lues dans
Chargement…
Où est mon… ?
Collez une commande (C000…), un BL ou une réception, un fournisseur (FF…), un n° ou un identifiant de facture ITESOFT, ou un code chantier : VIVA dit où il en est le long de la chaîne et pourquoi il manque quelque part.
Dernières recherches
Horaires des synchros (ce qui sert à dire quand revérifier, heure de Paris)
Chargement…
| Synchro | Vers | Horaires | Tâche | Source | Relevé le | |
|---|---|---|---|---|---|---|
VIVA ne voit pas les applications en direct : il voit ce que ses passages ont lu, après les copies de fichiers de l'infra. Une synchro faite dans l'application n'apparaît ici qu'au passage suivant.
Passages du rapprochement
Simulation du flux de rapprochement de la phase 2 (fiches A13, A8, A1, A7, A14), lue dans idv_monitor_mathieu, idv_state_mathieu et idv_pointage_mathieu. Rien n'est écrit dans Spock, Coupa ni ITESOFT : les écritures et les mails du flux sont gardés dans les tables du bouchon. Cliquer un passage pour l'ouvrir.
Lancer un passage du proto
Écrit seulement dans les bases _mathieu et le bouchon, jamais dans les applications. Un seul passage à la fois, ni pendant un passage de la chaîne de cette instance.Pour lancer, il faut les cases « Prototype phase 2 » et « Relance des pipelines » dans Gestion des utilisateurs.
1. Incrémental de l'ORCH_MAIN du proto
Tous les flux, en incrémental : recharge les factures, les réceptions et la copie de Spock dans idv_monitor_mathieu, puis recalcule le rappro. À lancer avant chaque rapprochement et avant la comparaison avec le patch.
2. Rapprochement : ORCH_RECONCILIATION
Facture les lignes de la période dans le bouchon. Période vide : la dernière période de facturation du patch (07h00 à 21h00, ou 21h00 à 07h00).
Derniers lancements depuis VIVA
· · ·
1. La chaîne du proto : ORCH_MAIN
Les passages de l'ORCH_MAIN du projet de prototype, lus dans idv_monitor_mathieu, suivis comme dans la page Relance des pipelines.Suivi du passage de la chaîne du proto
Lu dans la base à · mise à jour toutes les 15 sPas de connexion à la base sur cette instance : le suivi n'est pas disponible.
| Flux | Statut | Période | Début | Durée | Temps restant | Lignes en table | Fichiers trouvés | Erreurs |
|---|---|---|---|---|---|---|---|---|
Alertes
- , , , :
Aucun passage dans la base.
Derniers passages
Les passages de l'ORCH_MAIN du proto, lancés à la main dans le projet de prototype (aucune tâche planifiée). Ceux d'avant le 05/11 à 19h40 viennent de la recette, recopiés avec la base. Cliquer sur un passage pour voir ses flux.Aucun passage dans la base.
| Début | Fin | Durée | Statut | Mode | Période | Origine | Flux | Erreurs |
|---|---|---|---|---|---|---|---|---|
Chargement…
| Flux | Statut | Période | Début | Durée | Lignes en table | Fichiers trouvés | Erreurs |
|---|---|---|---|---|---|---|---|
Alertes
- , , , :
Volumes par passage
Une carte par flux : lignes ajoutées (vert, vers le haut) ou retirées (rouge, vers le bas) à chaque passage, du plus ancien à gauche au plus récent à droite ; échelle propre à chaque flux, en racine carrée pour que les petits écarts restent visibles. Point gris = flux non lancé, point rouge = erreurs. Survoler une barre pour le détail. Lignes en table de chaque flux à la fin de chaque passage, le plus récent à gauche. En dessous : l'écart avec le passage précédent (vert = lignes en plus, rouge = lignes en moins, = inchangé) et les fichiers trouvés pour les flux qui lisent des fichiers.Aucun passage dans la base.
| Flux | |
|---|---|
Chargement…
Aucune alerte enregistrée pour ce passage.
2. Le rapprochement simulé : ORCH_RECONCILIATION
Le suivi du passage choisi (le dernier par défaut), la liste des passages, puis le détail métier du passage.Rapport du rapprochement
Tous les passages du flux simulé : opérations manuelles par mois, lignes facturées, écarts, fichier du jour des cas manuels, fichiers de retour, liste du lundi et mails. Les opérations manuelles mesurent ce qu'il reste à corriger en amont : elles baissent à mesure que les corrections des flux du quotidien sont mises en place.
Cas manuels
Un cas par ligne de facture et par motif, ouvert par le flux quand il ne doit pas continuer seul (fiche A14). Pour chacun : qui le traite, l'action attendue, l'échéance, et les liens vers la réception et la commande dans Coupa, la facture dans ITESOFT et les livraisons de la commande dans Spock.
Documentation du prototype
Ce qu'est le prototype de la phase 2, comment il tourne, ce que fait le patch Python, ce qu'il manque pour le remplacer, ce qui reste à valider, et les constats des passages.
Passages de la migration F26
PROTOTYPE MIGRATION F26Prototype de la migration F26 : l'ID chantier Spock est lu dans Coupa au lieu de reconstruire le code chantier. Lu dans idv_monitor_f26, idv_state_f26 et idv_pointage_f26. Prototype à part de celui de la phase 2 : aucune page ni base en commun.
Lancer la chaîne du prototype F26
Écrit seulement dans les bases _f26, jamais dans les applications. Un seul passage à la fois, ni pendant un passage de la chaîne de cette instance.Pour lancer, il faut les cases « Prototype migration F26 » et « Relance des pipelines » dans Gestion des utilisateurs.
1. Incrémental de F26_ORCH_MAIN
Tous les flux du prototype, en incrémental : commandes Spock, chantiers Spock et chantiers Coupa, rechargés dans idv_monitor_f26.
2. Migration F26
La reprise des chantiers par l'ID chantier Spock lu dans Coupa. Le bouton reste grisé tant que sa tâche n'existe pas sur cette instance.
Derniers lancements depuis VIVA
· · ·
Passages de la migration : F26_ORCH_MIGRATION
Un passage par lancement de la migration (flux F26_WKS-*, par exemple le chargement initial des identifiants Spock). Lignes = identifiants écrits. Les résultats se lisent dans les pages Résultats et À revoir.Aucun passage de la migration dans la base.
| Début | Fin | Durée | Statut | Flux | Lignes | Erreurs | Alertes | Origine |
|---|---|---|---|---|---|---|---|---|
| 0 |
La chaîne du prototype : F26_ORCH_MAIN
Les passages de F26_ORCH_MAIN (commandes Spock, chantiers Spock, chantiers Coupa), lus dans idv_monitor_f26, suivis comme dans la page Relance des pipelines.Suivi du passage de la chaîne F26
Lu dans la base à · mise à jour toutes les 15 sPas de connexion à la base sur cette instance : le suivi n'est pas disponible.
| Flux | Statut | Période | Début | Durée | Temps restant | Lignes en table | Fichiers trouvés | Erreurs |
|---|---|---|---|---|---|---|---|---|
Alertes
- , , , :
Aucun passage dans la base.
Derniers passages
Les passages de F26_ORCH_MAIN, lancés depuis VIVA ou à la main dans le projet de prototype (aucune tâche planifiée). Cliquer sur un passage pour voir ses flux.Aucun passage dans la base.
| Début | Fin | Durée | Statut | Mode | Période | Origine | Flux | Erreurs |
|---|---|---|---|---|---|---|---|---|
Chargement…
| Flux | Statut | Période | Début | Durée | Lignes en table | Fichiers trouvés | Erreurs |
|---|---|---|---|---|---|---|---|
Alertes
- , , , :
Volumes par passage
Une carte par flux : lignes ajoutées (vert, vers le haut) ou retirées (rouge, vers le bas) à chaque passage, du plus ancien à gauche au plus récent à droite ; échelle propre à chaque flux, en racine carrée pour que les petits écarts restent visibles. Point gris = flux non lancé, point rouge = erreurs. Survoler une barre pour le détail. Lignes en table de chaque flux à la fin de chaque passage, le plus récent à gauche. En dessous : l'écart avec le passage précédent (vert = lignes en plus, rouge = lignes en moins, = inchangé) et les fichiers trouvés pour les flux qui lisent des fichiers.Aucun passage dans la base.
| Flux | |
|---|---|
Chargement…
Aucune alerte enregistrée pour ce passage.
Résultats du chargement initial
PROTOTYPE MIGRATION F26Les ID chantier Spock que le chargement initial écrirait dans Coupa : une ligne par code chantier Coupa. Lu dans idv_pointage_f26 (ptg_coupa_worksites, fichier initial_load), pour le dernier passage ou celui choisi. Rien n'est écrit dans Coupa.
Codes chantier Coupa qui recevraient un ID Spock
ID chantier Spock distincts
dont actifs dans Coupa
dont inactifs
Aucun passage du chargement initial dans la base : la page se remplira au premier lancement de la migration.
| Écrit le | Nom du chantier | Actif | Code chantier Coupa | Agence | code | Agence | ID chantier Spock | Liste Coupa | Fiche |
|---|---|---|---|---|---|---|---|---|
Avant / après la migration
PROTOTYPE MIGRATION F26Toute la liste Coupa des codes chantier, valeur par valeur, face au chantier Spock qui lui correspond, pour le dernier passage de la migration ou celui choisi. Avant : aucune valeur n'a d'ID chantier Spock dans Coupa. Après : seules les valeurs « Repris » recevraient leur ID chantier Spock ; les autres sont montrées pour contrôle et ne seraient pas touchées. Lu dans les bases _f26 (copies de la liste Coupa et des chantiers Spock). Rien n'est écrit dans Coupa.
Aucun passage du chargement initial dans la base : la page se remplira au premier lancement de la migration.
Liste Coupa complète
Avant : 0 avec un ID chantier Spock (champ id-chantier-spock vide sur toute la liste, constaté sur la recette Coupa le 06/11)
Le flux des commandes retrouve aujourd'hui le chantier par son code reconstruit, avec la recherche texte de Spock (première réponse).
Repris par le chargement
On ne prend que celles-ci : ce sont les seules valeurs qui recevraient un ID chantier Spock dans Coupa. Rien d'autre n'est modifié.
Libellé Coupa et libellé Spock : ·
Pas repris
Montrées pour contrôle, elles ne seraient pas touchées.
Par agence (cliquer sur une agence pour voir ses valeurs)
| Agence | Valeurs Coupa | Reprises | À revoir | Ignorées | Non traitées | Reprises au libellé différent |
|---|---|---|---|---|---|---|
Vous voyez les valeurs reprises : c'est exactement ce que le chargement initial écrirait dans Coupa (une ligne = une valeur qui reçoit son ID chantier Spock).
| Dans Coupa | Dans Spock | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Statut | Agence | Code chantier | Active | Nom Coupa | Libellés | Libellé du chantier | Code chantier | ID chantier | Agence du chantier | Remarque |
| = identiques≠ différents | ||||||||||
Codes chantier à revoir
PROTOTYPE MIGRATION F26Les codes chantier Coupa que le chargement initial n'a pas pu trancher. Depuis la v147 du prototype, il n'y reste que les vrais conflits (plusieurs chantiers Spock pour un code, plusieurs valeurs Coupa dans l'agence du chantier Spock) : les codes sans chantier Spock et les anciennes valeurs d'une autre agence sont ignorés. Les passages plus anciens les listent encore. Lu dans idv_state_f26 (worksite_codes_to_review), pour le dernier passage ou celui choisi. Les actifs dans Coupa d'abord.
ID chantier Spock trouvés (dernier chargement)
Codes à revoir
Aucun code à revoir dans la base : la page se remplira au premier lancement de la migration.
| Motif | Code Coupa | Nom Coupa | Actif | Agence | code | Agence Coupa | Code Spock reconstruit | Chantiers Spock trouvés | ID Spock trouvés | Agence du chantier Spock | ID donné à | ID de la valeur Coupa | Écrit le |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Relance des pipelines
Lance la chaîne de la phase 1 (ORCH_MAIN dans SnapLogic) avec les flux et le mode choisis, puis suit le passage dans la base : chaque flux au moment où il démarre et se termine, et les alertes.
Tâche :
Suivi lu dans
Mode
Les flux de fichiers et de Spock sont relus sur la période ; le recalcul du rappro suit. Garder 1 mois par tranche sauf raison précise.
Flux
Sans AGG-001, le rappro n'est pas recalculé : les rapports ne bougeront pas.
Confirmer le lancement
La base de suivi ne répond pas : impossible de vérifier qu'aucun passage ne tourne déjà.
Le lancement peut partir quand même, mais la page ne suivra pas le passage. Ne relancez pas tant que le précédent n'est pas fini (le voir dans SnapLogic).
Envoi à SnapLogic en cours
VIVA attend que le premier flux du passage apparaisse dans la base : en général quelques secondes, une minute au plus. Un refus de SnapLogic s'afficherait ici tout de suite. Rien n'est bloqué, ne relancez pas.
Suivi du passage
Lu dans la base à · mise à jour toutes les 15 sPas de connexion à la base sur cette instance : le suivi n'est pas disponible.
| Flux | Statut | Période | Début | Durée | Temps restant | Lignes en table | Fichiers trouvés | Erreurs |
|---|---|---|---|---|---|---|---|---|
Alertes
- , , , :
Aucun passage dans la base.
Index du rappro
En place Absents : rapports et recherche « Où est mon… ? » lentsChaque recalcul du rappro (AGG-001) recrée la table et efface les index qui rendent rapides les pages Rapports et Faux positifs et la recherche « Où est mon… ? » par commande, chantier ou fournisseur. En attendant qu'AGG-001 appelle lui-même la procédure de la base qui les pose, ce bouton la lance : elle ne pose que les index absents (environ une minute).
Derniers passages
Tous les passages de la base, planifiés par la tâche SnapLogic ou lancés depuis VIVA. Cliquer sur un passage pour voir ses flux.Aucun passage dans la base.
| Début | Fin | Durée | Statut | Mode | Période | Origine | Flux | Erreurs |
|---|---|---|---|---|---|---|---|---|
Chargement…
| Flux | Statut | Période | Début | Durée | Lignes en table | Fichiers trouvés | Erreurs |
|---|---|---|---|---|---|---|---|
Alertes
- , , , :
Volumes par passage
Une carte par flux : lignes ajoutées (vert, vers le haut) ou retirées (rouge, vers le bas) à chaque passage, du plus ancien à gauche au plus récent à droite ; échelle propre à chaque flux, en racine carrée pour que les petits écarts restent visibles. Point gris = flux non lancé, point rouge = erreurs. Survoler une barre pour le détail. Lignes en table de chaque flux à la fin de chaque passage, le plus récent à gauche. En dessous : l'écart avec le passage précédent (vert = lignes en plus, rouge = lignes en moins, = inchangé) et les fichiers trouvés pour les flux qui lisent des fichiers.Aucun passage dans la base.
| Flux | |
|---|---|
Chargement…
Aucune alerte enregistrée pour ce passage.
Derniers lancements depuis VIVA
Aucun lancement depuis l'application.
Rapports du rappro (rapprochement)
Les rapports que publie le programme Python pour son Power BI, refaits dans la base de la phase 1 (SnapLogic charge, la base MySQL sur Azure calcule). Mêmes axes que le Power BI : mois de création du BL, famille et type d'anomalie, agence, montants. BL de 2026. Chaque rapport s'exporte en CSV (l'export du rappro garde aussi les colonnes avant / après passage de l'agence sur Spock du Power BI).
Relit les vues de la base du rappro (2 à 3 min) et remplace la copie gardée par VIVA. Ne relance pas la chaîne. Utile juste après un passage (sinon automatique dans les 10 min) ou après une correction faite en base.
Rappro complet
Tous les BL (environ 915 000 lignes), calculés par la chaîne SnapLogic dans la base de VIVA, au format du fichier full_rappro_pbi1 du Python (mêmes colonnes, même ordre). L'Excel ajoute des liens cliquables vers Coupa, Itesoft et Spock. Préparé à la demande : 1 à 3 minutes, puis gardé jusqu'au passage suivant.
Les autres fichiers, au format de ceux du Python (Cas 1, garanties, doublons, historique, statut)
Chargement des rapports…
Pas de valeur : la base ne contient pas encore de rappro calculé.
La page montre ce que contient réellement la base, en lecture seule. Les rapports apparaîtront après le premier passage complet de la chaîne.
Pas de base connectée : les chiffres ci-dessous sont une photo figée, ils ne se mettent pas à jour.
La page montre une copie des rapports de la . Ce sont bien les données du jour, issues des sources de production : la seule différence, c'est qu'il s'agit d'une photo prise à ce passage, et non d'une lecture en direct dans la base.
À savoir sur cette photo :
Base configurée : . Les vrais rapports remplaceront cette photo dès qu'un passage de la chaîne les aura calculés.
Dernier essai () :
Fraîcheur des données :
Heure de Paris. Les sources (Coupa, Spock, Itesoft, Arcole) sont lues au début du passage.
Photo figée : , chaîne DEV.
D'où viennent ces chiffres, et de quand ?
- Sources : Coupa, Spock, ITESOFT et Arcole sont lus par la chaîne SnapLogic au début du passage indiqué dans « Fraîcheur des données ».
- Calcul : la base du rappro (, MySQL) recalcule le rappro à la fin de ce passage.
- Copie de VIVA : les rapports de cette page sont lus dans les vues de la base puis gardés dans la base interne de VIVA (SQLite), parce que ces vues prennent plusieurs minutes. Copie faite le , . VIVA vérifie toutes les 10 minutes si un nouveau passage est fini et refait alors la copie.
- En direct, sans copie : les pages Détail et Tout, la liste et la grille des BL de la page Anos et les BL en double lisent la base au moment où vous les ouvrez.
Base · calculés le (, s) · recalculés automatiquement après chaque passage de la chaîne.
Calcul en cours depuis (rapport ) : quelques minutes, la page se met à jour à la fin.
Mois de création du BL
Détail des lignes et Tout
Tout : toutes les colonnes en CSVPages Détail et Tout du Power BI : une ligne par BL du rappro, lue en direct dans la base. L'export « Tout » reprend les colonnes du fichier full_rappro_pbi1 du Python, avec les filtres choisis ici (sans filtre : tout le rappro, plusieurs minutes).
| Ouvrir | |
|---|---|
Comparaison Power BI
Nos rapports du rappro, présentés exactement comme les pages du Power BI du programme Python : mêmes pages, mêmes tableaux et graphiques, montants en valeur absolue, Anos toutes années, mêmes couleurs de familles. Seule source : la base du rappro de cette instance. La page Fact n'existe pas ici : en phase 1, seul le Python intègre les factures.
Fraîcheur des données :
Anos (tableau), Historique, Cas 1 et Divers : copie des rapports gardée par VIVA (base interne SQLite), faite le . BL dups, la liste et la grille des BL d'Anos, Détail et Tout : lus en direct dans la base à l'ouverture.
Base DEV : l'historique 2025 n'y est pas rechargé, ses BL sortent en famille 4 ; la page Anos compte toutes les années, comme le Power BI.
Témoin Python actuel
Déposé
Fichiers générés par le Python le
Aucun témoin déposé pour l'instant. Déposez le zip d'un passage Python proche du nôtre.
Un nouveau dépôt remplace le précédent. Pour comparer seulement : le zip n'entre dans aucun calcul.
Le zip du Python est gardé tel quel par VIVA (stockage interne) et ne sert qu'à la page « Nous / Python » : il n'entre dans aucun de nos calculs. Côté nous, la comparaison prend les rapports de la copie gardée par VIVA (voir Fraîcheur des données) et, pour le BL par BL, le rappro de la base au moment de cette copie ; le résultat est gardé jusqu'au prochain dépôt ou à la prochaine copie. Pour une comparaison juste, déposez les fichiers d'un passage Python proche du nôtre : un écart d'heures donne des écarts d'octobre qui ne sont que du décalage.
Référentiels manuels
Contenu des tables manual_* de la base du rappro de cette instance, en lecture seule : ce que la chaîne utilise en ce moment. Les faux positifs se gèrent dans leur propre page.
Base lue :
Faux positifs du rappro (rapprochement)
BL déclarés déjà corrigés : ils sortent des anomalies au recalcul suivant. Le fichier exporté reprend les colonnes de la table du rappro (num_bl_coupa, code_agence, comment, ano_type, source).
Liste enregistrée dans :
BL DANS LA LISTE
Base du rappro non configurée sur cette instance
lecture…
BL de la liste ne sont pas encore dans la base du rappro. Ils y seront ajoutés :
Ils sortiront des anomalies au prochain recalcul du rappro (AGG-001). Rien n'est retiré de la base.
Pour confirmer l'envoi de BL, retapez le nom de la base :
AJOUTÉS CES 7 DERNIERS JOURS
AJOUTÉS CES 30 DERNIERS JOURS
DERNIER AJOUT
aucun
BL ajoutés par jour, sur les 30 derniers jours
Aucun ajout sur les 30 derniers jours
Barre coupée : jour hors d'échelle (chargement de la liste), sa valeur est écrite au-dessus.
Derniers ajouts
Aucun ajout enregistré
Importer des fichiers Excel
Les mêmes fichiers que ceux déposés aujourd'hui pour le Python : Excel (.xlsx) ou CSV avec une colonne rappro_primary_key ou num_bl_coupa sur la première ligne. Plusieurs fichiers d'un coup. Les BL déjà dans la liste sont ignorés. Télécharger le modèle Excel (une ligne par BL : numéro, agence, commentaire, type).
| BL | Agence | Type | Commentaire | Source | Ajouté le | Par | |
|---|---|---|---|---|---|---|---|
Anos à vérifier
Filtrer les anomalies comme dans la page Anos du Power BI, exporter la liste en Excel (toutes les colonnes de la page Tout), et ouvrir chaque BL dans Coupa, ITESOFT ou Spock. Les BL reconnus comme faux positifs s'ajoutent ensuite à la liste ci-dessus.
Journal d'audit
Traçabilité complète de toutes les modifications en base de données.
TOTAL MODIFS
CRÉATIONS
MISES À JOUR
SUPPRESSIONS
| Timestamp | Table | Enregistrement | Action | Champs modifiés | Utilisateur |
|---|---|---|---|---|---|
|
: →
|
|||||
| Aucun enregistrement d'audit | |||||
Gestion des utilisateurs
Gérez les comptes utilisateurs, rôles et permissions.
| Nom | Identifiant | Rôle | Statut | Faux positifs | Relance | Support | Prototype | F26 | Dernière connexion | Actions | |
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||
| Aucun utilisateur | |||||||||||