Evidence packages : quand l’auditeur veut le bundle, pas la trail

Un auditeur ne veut pas naviguer dans votre plateforme. Il veut un fichier sur son bureau contenant tout ce qu’il faut pour vérifier une affirmation précise — et il veut que le suivant ait exactement la même tête, pour que la deuxième revue prenne une heure et non une matinée. Les evidence packages sont cet export : choisissez un scope, générez, téléchargez, transmettez.

Six scopes

Un package peut se construire autour d’un asset unique, d’un inbound order, d’un outbound order, d’un contrat, d’une company sur une fenêtre de dates ou d’un batch d’assets sélectionné dans une liste. Le scope n’est pas décoratif : il décide quels assets seront résolus dans le bundle. Un contrat tire ce qui a tourné sous lui, une company plus une fenêtre tire ce qui a bougé sur la période, un batch tire exactement les lignes que votre opérateur a cochées. Prenez le plus petit scope qui répond à la question qu’on vous a réellement posée.

Ce qu’il y a dans le ZIP

À la racine se trouve summary.pdf — le récit lisible du package, de son scope, de ses assets et de la façon dont il a été généré. À côté, un dossier photos contient un sous-dossier par asset tag avec la galerie de l’appareil ; les certificats d’effacement générés sont rangés de la même manière, un dossier par asset tag, quand ils appartiennent au scope. Les certificats de recyclage externes arrivent sous forme des PDF originaux du recycleur, classés par numéro de certificat, parce que le document d’un recycleur downstream vaut plus non retapé. Si une galerie a dépassé le plafond de taille, une note à l’intérieur du ZIP le dit, plutôt que de livrer discrètement une série tronquée.

Le PDF de résumé est le manifest, et c’est de toute façon la partie que l’auditeur ouvre en premier. Il existe aussi un format PDF seul, pour les revues où les photos ne sont pas le sujet : le résumé, et rien à dézipper.

Prêt, expiré, purgé

Un package traverse pending, generating et ready, et peut finir failed, expired ou revoked. Un package prêt porte un lien de téléchargement signé valable sept jours par défaut — un réglage plateforme, pas un nombre gravé dans le code. Un balayage horaire expire les liens arrivés au bout ; un balayage quotidien supprime définitivement les packages expirés depuis quatre-vingt-dix jours, objet de stockage compris. Tant que le fichier lui-même est encore là, la page de détail peut rafraîchir un lien périmé au lieu de tout régénérer.

Quatre-vingt-dix jours est un compromis assumé. Un régulateur qui pose une question sur un decommissioning un mois après la livraison ne devrait pas tomber sur un lien mort, et un bucket plein de ZIP oubliés n’est la stratégie compliance de personne.

Envoyer et reprendre

Un dossier intermédiaire prêt et actuel peut être envoyé par vos administrateurs, responsables ou opérateurs. Les dossiers de service définitifs contiennent des documents financiers et nécessitent un administrateur, responsable ou utilisateur financier. Un dossier lié à la demande de collecte attribuée devient accessible aux utilisateurs autorisés du portail client. Les autres dossiers vont aux contacts de la commande ou de l’entreprise, avec des adresses supplémentaires choisies par votre équipe. Les destinataires reçoivent un lien temporaire.

La page de détail conserve le résultat pour chaque destinataire : accepté par le service de messagerie, refusé, en cours ou incertain. L’acceptation ne prouve ni la réception ni le téléchargement. La reprise réutilise le message original et ignore les destinataires déjà acceptés. En cas d’incertitude ou de fin de la période de relance sûre, un administrateur ou responsable vérifie le service de messagerie et enregistre le résultat confirmé avec un motif.

Si la preuve d’effacement change, générez une nouvelle version avant de partager à nouveau. La version déjà publiée et son historique d’envoi restent disponibles. Les dossiers partagés sont exclus du nettoyage courant après expiration des liens.

Rapport intermédiaire ou dossier de service définitif

Utilisez l’action Générer les preuves d’une commande entrante, ou sélectionnez cette commande dans la liste des dossiers. Choisissez Rapport intermédiaire pour une synthèse PDF ou un ZIP des preuves disponibles. Chaque source d’effacement actuelle sélectionnée doit être lisible ; un effacement échoué ou partiel reste présenté avec son résultat réel. Ce rapport ne confirme pas que le service est complet.

Le Dossier de service définitif réunit une seule commande entrante, un client, un contrat et une sélection d’appareils. La boîte de dialogue affiche les effacements obligatoires et réussis, les sources lisibles, les retours livrés avec signature et photos complètes, ainsi que la facture de service émise. Les exigences manquantes sont listées avant la génération. Un administrateur, responsable ou utilisateur financier peut créer le ZIP définitif lorsque ces contrôles réussissent. Il contient la synthèse, la facture, les preuves de retour, les fichiers originaux et le manifeste des sources.

L’empreinte produit reste complémentaire, avec une couverture actuelle, importée, provisoire ou manquante explicite. Une couverture Carbontrace incomplète n’empêche pas la livraison du service. Les sources sont revérifiées avant l’enregistrement ou la diffusion de la version définitive. Si les preuves changent, le dossier enregistré devient obsolète : créez une nouvelle version avant de partager à nouveau. Les versions antérieures et leur historique d’envoi restent traçables.