Consulter le registre des écritures

Le Registre des écritures est une console au niveau du locataire, extérieure à tout projet, où la finance et la comptabilité consultent les écritures ERP de tous les projets et connexions qu’elles sont autorisées à voir. Alors que l’historique des envois ERP se limite à un projet auquel vous avez déjà accès, le Registre des écritures offre la vue transversale conçue pour un relecteur qui doit voir au même endroit les écritures de nombreux projets et connexions.

Le Registre des écritures est conçu d’abord pour la revue. Deux actions groupées (effacer les écritures simulées et réessayer les écritures en échec), un bouton Réessayer à l’unité dans le panneau de détail, l’inversion et l’inversion d’un run intersociétés entier en une seule fois vous permettent d’agir directement depuis la grille et le panneau de détail. L’assistance IA vous aide à trouver et à comprendre les écritures plus vite, et les tendances, le lignage, les totaux de contrôle, les clôtures et l’export vous permettent d’analyser, de remonter à la source, de verrouiller une période et d’extraire les données. La collaboration permet à une équipe de commenter, de valider et de suivre une écriture ensemble, sans jamais faire figurer un montant dans une notification.

La console est un espace de travail unique à panneaux ancrés, et non un ensemble de fenêtres flottantes. Une barre de navigation à gauche ouvre chaque écran (écritures, simulé, exceptions, approbations, délégations, synthèse, tendances, totaux de contrôle, lignage, exports et alertes et assistance IA) sous forme de volet en place : changer d’écran remplace donc le contenu du centre de l’espace de travail au lieu d’empiler une nouvelle fenêtre sur la précédente. Ouvrez une écriture et son détail s’affiche depuis la droite sans masquer la liste sur laquelle vous travailliez.

Un seul espace de travail ancré : la barre ouvre un écran au centre, en place, et le détail d’une écriture s’ouvre dans un panneau à droite sans masquer la liste.

Qui peut l’ouvrir

L’ouverture du Registre des écritures exige l’un des quatre scopes de realm Keycloak : erp.register.view, .operate, .approve et .admin. Ce sont des autorisations indépendantes, et non une échelle progressive : détenir .admin n’accorde pas à lui seul ce qu’accorde .operate, et chaque action qui modifie l’état ou fait sortir des données vérifie explicitement son ou ses propres scopes requis au lieu de les déduire d’un niveau supérieur.

Scope	Autorise
`erp.register.view`	Ouvrir le registre et consulter les écritures : file d’attente des exceptions, grille, vues de synthèse, tendances, lignage et assistance IA. Rien de tout cela n’applique, n’exporte ni ne notifie quoi que ce soit.
`erp.register.operate`	Le socle de tout ce qui modifie l’état ou quitte la console : actions groupées, lancement d’une inversion, demande d’approbation pour celle-ci, ouverture de la boîte de réception des approbations et décision sur une demande dont vous avez l’autorité, consultation ou restitution d’une délégation, export ou planification d’une livraison, abonnement au résumé de l’assistance IA, et publication d’un commentaire, d’une validation ou d’un suivi. Les actions soumises à `.approve` et `.admin` sont vérifiées en plus de `.operate`, jamais à sa place ; voir ci-dessous.
`erp.register.approve`	L’autorité d’approbation d’une inversion dont le montant atteint ou dépasse le seuil de séparation des tâches du locataire (soit en détenant directement ce scope, soit par une délégation active de la part de quelqu’un qui le détient), et la résolution d’une tentative d’inversion bloquée (`released` ou `confirmed`). Accorder à quelqu’un d’autre une délégation de cette autorité exige aussi de détenir soi-même `.approve` ; l’utiliser, la consulter ou la révoquer ne l’exige pas. Toujours en complément de `.operate`.
`erp.register.admin`	L’export d’audit et le profil de lecture à date (montants et identité de l’émetteur non masqués), ainsi que la définition de la politique de rétention du locataire, chacun en complément de `.operate`. Permet aussi de supprimer ou de déclencher la planification d’un autre membre.

Quatre groupes de sécurité intégrés regroupent ces scopes de façon cumulative, par commodité : Posting Register Viewer (.view), Opérateur (ajoute .operate), Approbateur (ajoute .approve) et Administrateur (les quatre). Mais la matrice des Groupes de sécurité vous permet d’attribuer n’importe quelle combinaison de façon indépendante, puisque les scopes ne s’impliquent pas les uns les autres. .approve et .admin n’ont chacun aucun sens seuls : toute action qu’ils contrôlent exige aussi .operate, donc un groupe destiné à résoudre des inversions ou à démasquer des exports doit se voir accorder .operate explicitement en plus, et non le supposer acquis par le niveau supérieur. Attribuez le niveau (ou la combinaison) qui correspond à ce qu’un membre doit faire, et pas seulement .view à tout le monde.

La règle de visibilité

Détenir un scope erp.register.* ouvre la console, mais ne rend à lui seul aucune écriture visible. Une écriture n’est visible dans le registre que si vous détenez aussi une autorisation de connexion personnelle sur la connexion de cette écriture et, lorsque l’écriture appartient à un projet, un accès à ce projet. Une écriture qui n’est rattachée à aucun projet est contrôlée par l’autorisation de connexion seule.

Il s’agit d’une autorisation distincte du scope de registre ci-dessus, et les deux sont requises :

Autorisation de connexion. Vous devez être propriétaire explicite de la connexion, ou être nommé individuellement, ou être membre d’un groupe de sécurité nommé sur celle-ci : ce sont les mêmes autorisations que celles que contrôle le Modèle de sécurité d’une connexion. Une connexion définie sur All Workspace Members n’accorde pas la visibilité dans le registre. Ce paramètre rend la connexion utilisable par tous ; ce n’est ni une autorisation personnelle, ni de groupe, ni de propriété, et le registre exige précisément l’une de celles-ci.
Accès au projet, pour toute écriture qui appartient à un projet : le même accès que celui exigé par le reste de votre travail sur le projet.

Un membre qui détient erp.register.view mais aucune autorisation de connexion voit un registre correctement vide, et la console le lui indique au lieu de sembler défaillante. Une autorisation de connexion ou de projet révoquée prend effet au prochain chargement de page : il n’y a aucune visibilité périmée à purger.

Ce que vous voyez selon votre rôle

La console est adaptée au rôle : une entrée de la barre ou un bouton d’action pour lequel vous n’avez pas le scope est masqué, et non simplement grisé, de sorte que l’espace de travail n’affiche que ce que vous pouvez réellement faire. Cela reflète ce que le serveur applique, sans s’y substituer :

Vous détenez	Vous voyez
`erp.register.view`	Les écrans de revue : file d’attente des exceptions, grille, synthèse, tendances, lignage, totaux de contrôle et assistance IA.
`erp.register.operate`	Ajoute les boutons d’action : réessayer, inverser et effacer les écritures simulées.
`erp.register.approve`	Ajoute la boîte de réception des approbations, les décisions d’approbation et la délégation.
`erp.register.admin`	Ajoute les paramètres de rétention et l’export d’audit non masqué.

Masquer un contrôle relève uniquement de la présentation : c’est une commodité pour ne pas vous proposer ce qui serait refusé. Le serveur reste souverain : chaque action qui modifie l’état ou fait sortir des données revérifie son propre scope requis, ainsi que vos autorisations de connexion et de projet, au moment où vous l’exécutez. Rien n’est autorisé parce que le client a affiché un bouton, et rien n’est réellement bloqué simplement parce que le client en a masqué un.

La file d’attente des exceptions

L’ouverture du registre vous place sur la File d’attente des exceptions, et non sur la grille : les écritures les plus susceptibles de requérir votre attention, regroupées en quatre catégories et présentées par ordre de priorité :

En doute : l’envoi a été soumis et rien ne confirme encore ce qu’il est devenu.
Non confirmé : soumis, et au-delà de l’échéance à laquelle il aurait dû être confirmé.
En attente : un envoi asynchrone, au-delà de l’échéance à laquelle il aurait dû être résolu.
Échec : rejeté par l’ERP.

Chaque catégorie apparaît sous forme de tuile de comptage au-dessus de la file, avec son total en temps réel, de sorte que l’ampleur du travail est visible avant d’ouvrir quoi que ce soit. Sélectionner une tuile filtre la file sur cette catégorie, tandis que les autres tuiles continuent d’afficher leurs propres totaux : passer à Échec ne fait donc jamais paraître vide le compteur En doute.

L’ancienneté est mesurée par rapport aux minuteries propres à la plateforme, et non à un seuil inventé : une écriture entre donc dans une catégorie exactement au moment où la plateforme elle-même la jugerait en retard. Dans chaque catégorie, les écritures les plus anciennes viennent en premier.

Les écritures simulées n’apparaissent jamais dans la file ni dans ses compteurs : la file indique combien ont été exclues, afin qu’un faible compte ne soit jamais pris pour « rien à examiner » lorsque ce sont les simulations qui l’expliquent. Filtrer sur une catégorie réduit les lignes affichées, mais ne modifie pas les compteurs des autres catégories ; passer à Échec ne fait donc jamais paraître vide En doute.

La même règle de visibilité que pour la grille s’applique ici : vous ne voyez que les exceptions des écritures rattachées à une connexion qui vous a été personnellement accordée, dans un projet auquel vous avez accès.

Inversions encore en suspens

La liste des exceptions exposée par l’API, GET /erp/register/exceptions, signale aussi une cinquième catégorie, reversal_outstanding : une écriture comptabilisée dont l’inversion a été envoyée mais jamais réglée, parce que l’ERP n’a donné aucune réponse ou que la tentative a été interrompue en cours d’envoi. Elle a son propre compteur à côté des quatre autres, remonte en tête avec En doute, et chaque ligne indique la tentative d’inversion et son état. Une telle écriture reste dans la liste jusqu’à sa résolution, comme décrit sous Inversion ; elle n’en sort pas d’elle-même avec le temps.

État des connexions

Une bannière au-dessus de la File d’attente des exceptions et des vues de synthèse (ci-dessous) répond à une question à laquelle aucune des deux ne répond seule : l’une de vos connexions est-elle en panne ? Pour chaque connexion qui vous a été personnellement accordée, et uniquement celles-ci, elle affiche le dernier envoi réussi et indique si la connexion est actuellement en erreur. Une connexion accordée sans aucune écriture le dit plutôt que d’être omise de la liste, et si la vérification d’état elle-même ne peut pas aboutir, la bannière le dit aussi au lieu de signaler discrètement que tout va bien.

Mise en forme des montants

Chaque montant affiché par le registre (grille, synthèse, totaux de contrôle, panneau de détail, file d’attente des exceptions, boîte de réception des approbations, assistance IA et boîte de dialogue d’inversion) s’affiche comme un chiffre comptable : séparateurs de milliers, négatifs entre parenthèses et chiffres tabulaires (à chasse fixe) pour qu’une colonne de montants s’aligne sur la virgule décimale. Le nombre de décimales suit la devise elle-même plutôt qu’un format fixe à deux décimales : le JPY n’en affiche aucune, le KWD en affiche trois.

Les sous-totaux ne sont jamais additionnés entre devises. Un groupe ou un lot contenant plus d’une devise se scinde en une ligne par devise, chacune libellée avec sa propre devise, dans les vues de synthèse comme dans les totaux de contrôle : aucun taux de change n’est supposé nulle part dans la plateforme.
L’arrondi d’affichage ne masque jamais une différence réelle. Lorsque l’arrondi aux décimales habituelles de la devise supprimerait un chiffre non nul, le panneau de détail affiche la valeur exacte capturée à côté de la valeur arrondie. Les chiffres des totaux de contrôle ne sont jamais arrondis, pour la même raison : un écart vérifié par rapport à une tolérance reste à pleine précision, de sorte qu’une réelle différence hors tolérance comme 0.004 ne peut pas s’afficher 0.00 à côté d’un verdict « Déséquilibré ».

La grille du registre

Passez à la grille pour voir toutes les écritures et pas seulement les exceptions : elle liste les écritures de tous les projets et connexions que vous pouvez voir, une ligne par écriture. Une barre de périmètre court en haut de la grille, où vous restreignez ce que vous regardez :

Projet
Environnement
Connexion
Type d’ERP
Entité
Date de comptabilisation
État
Mode de comptabilisation

Pour construire votre propre filtre de type d’ERP, GET /erp/register/erp-types renvoie, triés, tous les types d’ERP des écritures que vous pouvez voir.

La barre de périmètre utilise des sélecteurs : vous choisissez un projet, une connexion ou une entité par son nom dans une liste limitée à ce que vous êtes autorisé à voir, plutôt que de saisir un identifiant. État est une sélection multiple, ce qui vous permet de suivre plusieurs états à la fois.

Mode de comptabilisation est un commutateur à trois boutons toujours visible, pour que vous voyiez d’un coup d’œil ce que les chiffres incluent. Réel n’affiche que les écritures parvenues à l’ERP, Simulé n’affiche que les écritures issues d’exécutions en mode Simulation, et Tous (la valeur par défaut) affiche les deux. La colonne Mode de comptabilisation de la grille indique le type de chaque ligne. Les écrans Reconcile et Synthèse ont leur propre sélecteur Mode de comptabilisation avec les mêmes choix, par défaut sur Réel. Lorsque le mode n’est pas Réel, une note à côté des totaux monétaires indique qu’ils incluent des écritures simulées qui ne sont jamais parvenues à l’ERP ou, sous Simulé, qu’aucune n’y est parvenue. Ce que vous avez défini reste visible à l’écran pendant votre travail : vous n’avez jamais à deviner ce que la grille affiche actuellement.

Actions groupées

Depuis la grille, sélectionnez plusieurs écritures et agissez sur toutes ensemble. Sélectionnez les écritures en cochant leurs lignes, ou en choisissant tout sélectionner selon le filtre actuel, ce qui atteint toutes les écritures correspondant au filtre sur toutes les pages, et pas seulement celles déjà chargées.

Deux actions sont proposées :

Effacer les écritures simulées : une suppression logique pour les écritures simulées que vous n’avez plus besoin de conserver.
Réessayer les écritures en échec : renvoie les écritures que l’ERP a rejetées ou qui n’ont jamais été envoyées.

L’aperçu d’impact

Avant l’exécution de l’une ou l’autre action, PlaidCloud affiche un aperçu d’impact : le nombre d’écritures concernées, les montants en jeu (ventilés par devise ; les montants ne sont jamais mélangés entre devises, et un montant non capturé s’affiche vide, jamais 0.00), ainsi que les connexions et entités auxquelles appartiennent les écritures concernées. Tout élément de votre sélection sur lequel l’action ne peut rien est signalé séparément : « 24 de vos 30 écritures sélectionnées ne feront rien » est donc visible avant de confirmer, et non découvert après.

Saisie de confirmation

Au-delà d’un seuil, Appliquer reste désactivé tant que vous n’avez pas saisi exactement le montant concerné.

Le réessai ne porte que sur ce que vous avez coché

L’effacement d’écritures simulées peut porter sur l’un ou l’autre type de sélection : lignes cochées ou tout ce qui correspond à votre filtre. Le réessai en action groupée ne le peut pas : il ne s’exécute que sur les écritures que vous avez cochées individuellement. Une sélection portant sur tout le filtre n’a pas de liste fixe d’écritures à laquelle limiter le réessai ; le réessai vous demande donc de recoller les écritures et refuse de continuer si ce que vous collez n’est pas exactement ce que l’aperçu a montré : les mêmes écritures, sans doublon, et le même nombre. C’est cette liaison qui garantit l’honnêteté de la confirmation : le lot que vous avez confirmé est le lot qui est envoyé.

Ce qui peut être réessayé

Seule une écriture rejetée par l’ERP, ou qui n’a jamais été envoyée, peut être réessayée. Une écriture encore en cours, en doute ou déjà comptabilisée ne peut pas être réessayée d’ici.

Lorsque l’ERP de la connexion le permet, PlaidCloud interroge directement l’ERP avant de réessayer : si l’ERP détient déjà le document comme comptabilisé, le réessai est refusé et l’inversion est suggérée à la place. Si l’ERP ne peut pas répondre à cette vérification, le réessai est refusé plutôt que risqué : il ne devine jamais. Quelques connexions ne prennent pas du tout en charge cette vérification ; pour celles-ci, le réessai s’appuie sur le rejet enregistré de l’écriture elle-même.

Le réessai exige erp.register.operate et votre propre autorisation personnelle sur la connexion de cette écriture : la même autorisation de connexion que la règle de visibilité exige pour voir l’écriture.

Réessayer depuis le panneau de détail

Le panneau de détail d’une écriture comporte aussi son propre bouton Réessayer, à côté des contrôles de suivi : le même réessai, une ligne à la fois, accessible sans passer par la grille. Ce n’est pas un clic unique : son ouverture affiche le même aperçu d’impact et, au-delà du seuil, la même saisie de confirmation que l’action groupée : il n’existe qu’un seul chemin de réessai, emprunté depuis deux endroits. Le bouton s’affiche sur chaque ligne pour un membre détenant erp.register.operate ; le panneau ne présume jamais qu’une ligne est réessayable avant de le proposer, de sorte qu’une ligne qui s’avère inéligible (déjà comptabilisée, en cours, ou déjà détenue par l’ERP) est refusée par l’aperçu avec la raison du serveur, et non masquée silencieusement.

Effacer les écritures simulées

L’effacement est une suppression logique : PlaidCloud enregistre qui l’a effectué et quand, et exige un motif avant d’activer Appliquer. Il retire les écritures du magasin d’aperçu de simulation et du journal de simulation du grand livre lui-même ; il ne touche jamais une écriture réelle, et il n’existe aucun moyen de le diriger vers l’une d’elles.

La vue des écritures simulées

Écritures simulées s’ouvre comme un volet depuis la barre, et liste le contenu du magasin de simulation au lieu de vous obliger à chercher les lignes simulées dans la grille principale. Filtrez par connexion, projet, environnement ou identifiant d’exécution de simulation.

Inclure les effacées est désactivé par défaut, comme la valeur par défaut du serveur : une ligne effacée est la trace d’audit d’un effacement et n’est conservée que brièvement pour cette raison ; la vue s’ouvre donc sur ce qui est encore actif dans le magasin plutôt que sur son propre historique.
L’effacement depuis cette vue passe toujours par le même aperçu d’impact que l’action groupée de la grille, jamais par un effacement en un clic, limité à ce que correspondent actuellement les filtres de la vue.
La ligne de synthèse de la vue indique aussi le même chiffre simulated_excluded que celui de la File d’attente des exceptions : combien d’écritures simulées du registre des écritures (une table distincte du magasin de simulation) sont écartées de la file, parce qu’une ligne simulée n’est jamais parvenue à l’ERP et n’est donc jamais une exception.

Assistance IA

Assistance ouvre une zone de recherche, une rangée de cartes proactives et un panneau de conseils par ligne : chaque chiffre qui y figure est calculé par le registre lui-même, sur vos propres autorisations en vigueur ; le modèle, lorsqu’il y en a un de configuré, se contente d’expliquer ou de rédiger, et n’invente jamais un chiffre ni un prédicat.

Demander en langage courant

Saisissez une phrase (« écritures en doute pour la connexion EMEA la semaine dernière ») et elle est analysée dans le vocabulaire de filtres propre au registre au moyen d’une table fixe, et non d’un appel à un modèle : une analyse ne peut que restreindre les lignes que la grille vous montrerait déjà, sans jamais atteindre une ligne qui ne vous a pas été accordée. Le seul rôle du modèle est d’expliquer l’analyse en une phrase : il nomme le champ reconnu et le nombre de vos lignes que le filtre obtenu trouve.

Cartes proactives

Sept cartes résument ce qui mérite un coup d’œil, chacune avec un compteur en temps réel et des lignes d’exemple limitées à vos propres autorisations : Restant à clôturer, Quasi-doublons, Écart intersociétés de net zéro, Modifié depuis la dernière clôture, Confirmé dans l’ERP, Ancienneté et responsables et Déjà contrepassé. Une courte phrase de commentaire accompagne les chiffres lorsqu’une connexion LLM est configurée pour votre espace de travail ; sinon, la carte s’affiche quand même en entier et indique pourquoi le commentaire est absent. Un montant non capturé sur une carte est toujours vide, jamais 0.00 : la même règle que celle des vues de synthèse.

Conseils par ligne

Choisissez une écriture et obtenez deux types de conseils, selon son état :

Un brouillon d’inversion, pour toute écriture : ce à quoi ressemblerait son inversion, c’est-à-dire si le pilote de la connexion la prend en charge, le total de contrôle auquel elle devrait correspondre, et une vérification de période. Ce n’est qu’un brouillon ; rien ici n’inverse quoi que ce soit.
Une piste sur l’échec, pour une écriture rejetée ou en doute : pourquoi elle a échoué, s’il faut la réessayer ou d’abord corriger les données sources, quel champ corriger, et le risque de doublon en cas de réessai. Le message d’erreur de l’ERP est du texte libre ; il est donc classé côté serveur en une cause plutôt que de vous être montré directement : la même règle qui tient le texte libre à l’écart du reste du registre.

Le résumé quotidien

Un résumé prévisualise, à la demande, les cartes ci-dessus limitées à un sous-ensemble pertinent pour la clôture (restant à clôturer, ancienneté et responsables, quasi-doublons, écart de net zéro intersociétés et confirmé dans l’ERP), telles qu’elles vous seraient envoyées aujourd’hui. Un interrupteur vous abonne ou vous désabonne ; l’abonnement ne stocke que votre identifiant de membre, de sorte qu’une autorisation que vous perdez ensuite retire simplement ces lignes de votre prochain résumé au lieu de divulguer une vue périmée.

Inversion

Inverser une écriture (créer dans l’ERP un nouveau document opposé) est possible depuis le contrôle Inverser du panneau de détail, et directement par l’API pour l’automatisation.

L’éligibilité dépend de l’état de l’écriture elle-même (seule une écriture comptabilisée avec un identifiant de document ERP confirmé peut être inversée), du pilote de la connexion (Business Central, Oracle Fusion et Acumatica ne prennent en charge aucune inversion programmatique, et le disent lorsque vous essayez) et de l’existence éventuelle d’une tentative d’inversion déjà en suspens. Le panneau revérifie l’éligibilité à l’ouverture d’Inverser, puis juste avant l’envoi, de sorte qu’une ligne devenue périmée entre-temps (une autre inversion déjà en suspens, par exemple) affiche le refus du pilote avec ses propres mots plutôt que d’émettre une requête vouée à l’échec.
Inverser exige erp.register.operate et est protégé par une saisie de confirmation : vous ressaisissez l’identifiant de document ERP de l’écriture, vérifié uniquement dans le navigateur et jamais envoyé, avant que Inverser ne se déverrouille : le même schéma d’étendue d’impact que celui des actions groupées, une invite de sécurité plutôt qu’une étape d’approbation.
L’inversion peut éventuellement rediriger la nouvelle écriture vers une période cible différente de celle de l’écriture d’origine : honoré sur les adaptateurs dont l’ERP accepte une période de comptabilisation explicite, refusé avec une erreur claire sur ceux qui ne peuvent pas la viser. Une redirection peut tout de même atterrir dans une autre période que celle demandée : certains adaptateurs ne savent qu’après l’envoi s’ils l’ont honorée, de sorte que le panneau n’indique une période d’arrivée qu’une fois la tentative effectivement réglée comme inversée, jamais avant, et s’en remet au message du serveur pour tous les autres résultats. Un verrou strict en base de données empêche qu’une seconde tentative d’inversion soit jamais envoyée tant qu’une autre est en suspens, même en cas de plantage du processus en cours d’envoi ; un rejet de l’ERP libère automatiquement ce verrou, puisque rien n’a été créé.
Une seule inversion à la fois, quel que soit son point de départ. Une inversion envoyée depuis le Registre des écritures et une envoyée par un workflow ou par l’API d’inversion au niveau du projet partagent le même verrou, et chacune relit l’écriture une fois qu’elle le détient : une écriture n’est donc jamais inversée deux fois, ni par une réexécution, ni par deux requêtes simultanées.
Une réponse inconnue est conservée, pas devinée. Lorsque l’ERP expire, renvoie une erreur serveur ou répond d’une façon que PlaidCloud ne reconnaît pas, l’inversion est enregistrée in_doubt plutôt que rejetée, et le verrou reste tenu. Un document d’inversion ne compte comme l’inversion que s’il reflète l’original : même entité et même devise, daté au plus tôt de la même date, débit et crédit de chaque ligne échangés ; tout le reste reste en doute pour que vous le vérifiiez.
Une inversion laissée pending ou in_doubt, dont le résultat est inconnu, le reste jusqu’à ce qu’elle soit réglée. Pour Workday et Dynamics 365 Finance & Operations, PlaidCloud recherche une inversion in_doubt dans l’ERP lors de la prochaine tentative d’inversion de cette écriture, et la règle d’après ce qu’il trouve. Une inversion pending sur ces connexions, et toute inversion non réglée sur toutes les autres connexions, se résout avec les contrôles de résolution du panneau, soumis à erp.register.approve en plus de .operate : une personne vérifie directement l’ERP et enregistre ce qu’elle a trouvé, soit Libérer (rien n’y a été créé, donc le grand livre est intact et l’écriture redevient inversible), soit Marquer comme inversé (un document d’inversion existe, avec son identifiant) : c’est le seul moyen de lever ce verrou. Marquer une inversion comme confirmed est définitif ; il n’existe aucun moyen de l’annuler via le produit.

Séparation des tâches

Une inversion dont le montant atteint ou dépasse le seuil configuré de votre locataire exige une approbation avant de se poursuivre, et l’approbation est quelque chose que fait un approbateur, et non un nom fourni par l’émetteur dans la demande.

Émetteur≠vérificateur. Le membre qui soumet l’inversion ne peut pas en être l’approbateur, ni être son propre autorisateur d’urgence.
Mesurée en valeur absolue. Le seuil compare l’ampleur de l’inversion quel que soit son signe : inverser un crédit est mesuré comme inverser un débit.
Les inversions récentes comptent dans le seuil. Une fenêtre glissante totalise les propres inversions d’un émetteur sur la même connexion, de sorte qu’une inversion importante ne peut pas être scindée en plusieurs plus petites pour rester sous le seuil. Les montants sont additionnés en valeur absolue, sans compensation : une inversion négative et une positive ne s’annulent pas.
Refus par défaut. Si une inversion antérieure dans la fenêtre ne peut pas être vérifiée (un montant ou une devise non capturé, par exemple), l’inversion exige une approbation au lieu de sauter la vérification.
L’approbateur doit être qualifié. Il lui faut erp.register.approve, ou une délégation active de la part de quelqu’un qui le détient, ainsi que sa propre autorisation sur la connexion inversée. Si moins de deux membres détiennent les deux, les inversions atteignant ou dépassant le seuil sont refusées plutôt que laissées passer.
L’autorisation d’urgence reste l’unique chemin où l’émetteur nomme directement qui a autorisé une dérogation : une véritable urgence, décidée par un autorisateur indépendant de la chaîne opérationnelle (détenant erp.register.admin mais pas .operate ni .approve, plus sa propre autorisation sur la connexion), et chaque dérogation est enregistrée de façon permanente dans la piste d’audit.
Un refus n’en donne pas la raison. Qu’une demande n’ait aucun approbateur qualifié, qu’elle ait été décidée par la mauvaise personne ou qu’elle n’ait jamais été ouverte, l’inversion est refusée avec le même message, volontairement, afin qu’un refus ne puisse pas servir à cartographier qui détient quel rôle ou quelle autorisation. La raison réelle figure dans la piste d’audit, et non dans l’erreur.
L’inversion d’un run exige une approbation par jambe, et non une pour le run. Inverser d’un coup un run intersociétés entier n’obtient pas une approbation unique au niveau du run : chaque jambe exige la sienne, car une approbation est liée à une écriture, une connexion et un approbateur détenant une autorisation sur celle-ci, et il n’existe pas de nom unique auquel lier toutes les jambes d’un run.
Les inversions passent par le registre. Tant que la séparation des tâches est active, une inversion demandée par l’API d’inversion ERP au niveau du projet (le chemin qu’emprunte un projet, une fonction définie par l’utilisateur ou un compte de service) est refusée avant que quoi que ce soit n’atteigne l’ERP, avec un message invitant à l’inverser depuis le Registre des écritures. Une écriture pour laquelle le registre ne détient aucun détail de capture ne peut pas non plus y être inversée et doit être corrigée dans l’ERP. Les envois ne sont pas affectés, et Business Central, Oracle Fusion et Acumatica continuent de donner leur propre raison : ils ne prennent pas en charge l’inversion.

L’activation de la séparation des tâches et la définition de son seuil sont configurées pour votre locataire par PlaidCloud : il n’existe pas encore de bascule dans la console.

La boîte de réception des approbations

Lorsque le seuil l’exige, Demander l’approbation, proposé à côté d’Inverser dans le panneau de détail, achemine l’inversion à tous les approbateurs qui détiennent une autorisation personnelle active sur cette connexion. Il n’y a personne à qui l’adresser ; l’autorisation de connexion est l’acheminement. Les approbateurs traitent la file depuis Approbations dans la barre : une boîte de réception des demandes en attente de leur décision, et une seconde file montrant les demandes qu’ils ont eux-mêmes soumises. Chaque ligne indique le montant, l’entité et la période de l’écriture, ainsi que depuis combien de temps elle attend, de sorte que décider ne suppose jamais de quitter la file pour aller chercher quelque chose d’abord. Approuver ou Rejeter prend un motif unique, enregistré avec la décision.

Une approbation est liée exactement à ce pour quoi elle a été accordée (l’écriture, sa connexion, le motif indiqué et la période cible) et ne peut pas être réutilisée pour une autre inversion, un autre motif ou une autre période cible ; une demande modifiée exige une nouvelle approbation. Une seule demande peut être ouverte à la fois sur une écriture, et une approbation est consommée à l’instant où elle est utilisée. Un bref délai de rétractation suit chaque approbation, pendant lequel l’approbateur comme l’émetteur peuvent encore l’annuler ; une fois ce délai écoulé, l’inversion peut déjà être un document dans l’ERP, et rien ne l’annule. Tout est revérifié au moment où l’inversion est réellement appliquée (le rôle de l’approbateur, l’accès des deux parties à la connexion et le minimum de deux approbateurs du locataire), de sorte qu’une approbation accordée plus tôt ne survit pas à la perte d’accès de l’approbateur entre-temps.

Délégation

Un approbateur peut déléguer son autorité d’approbation à un autre membre pour une fenêtre limitée, depuis le volet Délégations de la barre : utile lorsqu’un approbateur va être indisponible et que des inversions doivent tout de même être décidées. Accorder une délégation exige erp.register.approve ; en utiliser une, voir les siennes et en restituer une n’exigent que .operate, puisque le délégataire typique ne détient pas du tout le rôle d’approbateur : c’est tout l’intérêt de lui déléguer.

L’autodélégation est refusée, de même qu’une paire réciproque (déléguer à quelqu’un qui vous a déjà délégué) ou toute chaîne plus longue : aucune n’est honorée, afin que deux membres ne puissent pas faire compter discrètement les décisions de l’autre comme les couvrant tous les deux, directement ou par un intermédiaire. Émetteur≠vérificateur s’applique encore par une délégation : un délégataire ne peut pas approuver une demande de la personne qui lui a délégué, ni dans les deux cas une demande qui est la sienne. Chaque décision d’un délégataire est enregistrée dans la piste d’audit comme prise sous l’autorité de l’approbateur délégant, et non comme si le délégataire détenait pleinement le rôle.

Escalade

Une approbation qui reste trop longtemps sans décision déclenche une alerte, afin qu’elle ne vieillisse pas en silence dans une file que personne ne surveille. Chaque destinataire n’est informé que des demandes qu’il pourrait lui-même décider : l’e-mail d’escalade d’un collègue ne nomme jamais une demande acheminée vers les autorisations de quelqu’un d’autre, et l’alerte ne porte ni montant ni texte libre, avec la même minimisation que celle suivie par le reste des notifications du registre.

Runs intersociétés

Un run intersociétés est le groupe d’écritures (ses jambes) passées ensemble pour une même clôture, identifié par le jour de clôture et la séquence qui leur ont été apposés à l’époque, jamais par le run de workflow qui les a produites. (Cet identifiant de run de workflow subsiste séparément dans l’historique propre du grand livre et peut survivre au cachet de clôture d’une écriture ; il n’est donc pas un moyen sûr d’identifier un run.) Listez les runs, ouvrez-en un pour voir ses jambes rapprochées et appariées, et inversez le run entier comme une seule action encadrée.

Accessible uniquement par l’API pour l’instant (GET /erp/register/runs, GET /erp/register/runs/{run_day}/{sequence} et POST /erp/register/runs/{run_day}/{sequence}/reverse) : il n’y a pas encore d’écran dans la console.

Net zéro et appariement

Ouvrez un run et ses jambes sont rapprochées de deux façons, toutes deux limitées aux connexions qui vous ont été personnellement accordées (la même règle de visibilité que partout ailleurs dans le registre), de sorte qu’un run couvrant des connexions que vous ne voyez qu’en partie est signalé comme partiellement visible plutôt que comme déséquilibré.

Net zéro, par devise : un verdict Équilibré, Déséquilibré ou Indéterminé, avec le détail des entités derrière chaque net. Une devise n’est pas rapprochée tant que chaque jambe qu’elle contient n’a pas été capturée : une seule jambe non capturée rend toute la devise Indéterminée, jamais un net calculé sur ce qui s’est trouvé mesuré.
L’appariement associe chaque jambe fournisseur à sa contrepartie client au moyen d’une clé d’appariement que le workflow de comptabilisation appose sur les deux avant qu’aucune ne soit soumise. Une paire appariée s’équilibre à zéro dans une devise ; tout le reste porte une raison nommée : aucune jambe de contrepartie visible pour vous, un montant non capturé, un net réellement différent de zéro, ou multidevise, qui est signalé et jamais rapproché, puisqu’il n’y a de taux de change nulle part dans la plateforme.

Un run de plus de 200 jambes est trop volumineux pour être rapproché ou apparié en une seule réponse : les deux reviennent indéterminés plutôt que calculés sur une tranche tronquée du run, de sorte qu’un grand run ne signale jamais un faux équilibre, ni une fausse contrepartie manquante, causés par sa seule taille.

Inverser un run

Inversez chaque jambe d’un run en une seule action, avec POST /erp/register/runs/{run_day}/{sequence}/reverse.

L’éligibilité est vérifiée d’avance pour chaque jambe. Tout ce qui est connaissable à l’avance (état, prise en charge par l’adaptateur, tentative en suspens, votre propre autorisation de connexion) refuse le run entier avant qu’une seule requête n’atteigne un ERP.
Ce qui ne peut pas être connu d’avance est signalé ensuite, jambe par jambe. L’état en direct de l’ERP et des autorisations peut changer en cours de run, de sorte qu’un run peut se terminer partiellement inversé alors que rien ne semblait anormal lors de la vérification préalable. Rien n’est compensé automatiquement : comptabiliser d’autres documents pour défaire un échec partiel est une écriture plus risquée que celle qui a échoué. Un run partiel se corrige jambe par jambe, comme une inversion unique.
Relancer l’inversion d’un run est la façon de terminer une inversion partielle. Les jambes qu’une tentative antérieure a déjà inversées sont écartées plutôt que refusées, de sorte qu’un nouvel essai n’inverse que ce qui reste réellement.
La séparation des tâches s’applique par jambe, et non au total du run. Lorsque la politique de séparation des tâches de votre locataire est appliquée, chaque jambe exige sa propre approbation avant que le run n’expédie quoi que ce soit, à n’importe quel montant, et pas seulement au-dessus du seuil. C’est volontairement prudent : l’exigence propre à une jambe ne peut être réglée qu’au moment de son envoi (une fenêtre glissante anti-fractionnement qui compte les propres jambes du run au fur et à mesure de leur inversion, et une relecture en direct de l’ERP qui peut échouer) ; exiger toutes les approbations d’avance évite donc qu’un run inverse la moitié de ses jambes avant de découvrir en cours de route que les autres exigent aussi une approbation.
Les actions groupées couvrent tout le run en un appel. POST /erp/register/runs/{run_day}/{sequence}/approval-requests ouvre une demande d’approbation pour chaque jambe sur laquelle l’émetteur peut agir, et POST .../approval-decisions décide chaque jambe pour laquelle un approbateur est qualifié : un appel chacun au lieu d’une demande et d’une décision par jambe (20 appels pour un run courant de 10 jambes). Le modèle de sécurité sous-jacent est inchangé : chaque jambe obtient toujours sa propre approbation, liée à cette écriture, à sa connexion, au motif et à la période cible, et l’approbateur a toujours besoin de son propre accès à la connexion de chaque jambe ; une jambe qu’il ne peut pas autoriser reste simplement en attente pour quelqu’un qui le peut, sans jamais être incluse d’office. Un appelant sans aucune autorité d’approbation est refusé d’emblée, sans apprendre quelles jambes ont des demandes ouvertes. Les résultats reviennent par jambe, de sorte qu’un run autorisable en partie indique exactement quelles jambes ont été décidées et lesquelles sont restées en attente, et pourquoi.
L’autorisation d’urgence n’est pas disponible pour l’inversion d’un run. C’est une dérogation à deux personnes pour une écriture, et appliquer l’autorisation d’un seul témoin à tout un run la multiplierait par le nombre de jambes du run. Utilisez plutôt l’autorisation d’urgence jambe par jambe avec POST /entries/{ledger_id}/reverse.
Les runs de plus de 200 jambes ne peuvent pas être inversés en une seule action. Inversez-les par parties depuis la liste des écritures.

Tendances

Tendances affiche le taux d’échec et la latence, regroupés par connexion ou par type d’ERP, ainsi que la répartition des codes motifs d’inversion : chaque chiffre, y compris chaque dénominateur, est calculé sur vos propres autorisations en vigueur. Une connexion sans aucun état terminal dans la fenêtre affiche un tiret cadratin pour son taux d’échec, jamais 0%, car un zéro parfait placerait en tête d’une liste d’état de santé une connexion que personne n’utilise. La latence est un échantillon borné sur les écritures terminales les plus récentes, présenté comme un échantillon et non comme s’il couvrait toute la fenêtre. Les motifs d’inversion n’apparaissent que sous leurs codes structurés : le motif en texte libre saisi par une personne n’est jamais regroupé ni affiché ici.

Lignage

Lignage remonte d’une écriture jusqu’au run de workflow qui l’a produite, puis jusqu’au document dans l’ERP lui-même. Recherchez-le par identifiant de run ou par identifiant de grand livre d’une écriture : une recherche par identifiant de grand livre résout d’abord le run à travers vos propres autorisations, de sorte qu’une écriture sur une connexion que vous ne pouvez pas voir ne résout rien au lieu de révéler de quel run elle provient. Lorsque PlaidCloud peut vérifier la forme de l’URL de document de l’ERP pour cet adaptateur, le lignage inclut un lien direct vers le document ; lorsqu’il ne le peut pas, ou que l’écriture n’a jamais été confirmée, il indique laquelle de ces raisons s’applique plutôt que de deviner un lien. La clé métier de l’ERP n’apparaît toujours pas ici : la clé de lignage est le run_id du workflow, et le pointeur vers l’ERP est confirmation_id, comme partout ailleurs dans le registre.

Clôtures

Demandez une clôture pour verrouiller une période (pour une ou plusieurs connexions et entités) dans un instantané immuable à un instant donné : tout ce que le registre savait de ces écritures à ce moment-là, conservé même si les lignes en direct sont ensuite réessayées, inversées ou effacées. Elle vise une période comptable verrouillée pour laquelle vous avez besoin d’une trace défendable et inchangeable plutôt que de ce que la grille en direct montre aujourd’hui. La demande ou la lecture d’une clôture n’est accessible que par l’API pour l’instant ; il n’y a pas encore d’écran dans la console pour en demander une ou en parcourir.

Demander une clôture (erp.register.operate) est une action administrative à l’échelle du locataire, et non personnelle : les connexions et entités que vous nommez sont exactement celles qui sont verrouillées, quelles que soient vos propres autorisations de connexion. Reclôturer une période déjà clôturée n’est jamais destructeur : cela produit toujours une nouvelle révision numérotée séparément plutôt que d’écraser la précédente.

Les clôtures se matérialisent d’elles-mêmes. Demander une clôture ne la verrouille pas immédiatement : une tâche d’arrière-plan balaie automatiquement chaque clôture en attente, selon une planification quotidienne, et écrit son instantané Iceberg sans autre action de votre part. Si un balayage ne peut pas aboutir pour une clôture donnée (une panne d’entrepôt, par exemple), cette clôture est marquée en échec plutôt que laissée bloquée, puis reprise et réessayée automatiquement lors du balayage du lendemain : elle n’est jamais ignorée en silence. Une clôture exceptionnellement volumineuse (couvrant plus d’environ 500 000 écritures) est le seul cas qui ne se résoudra pas ainsi : le balayage refuse de la verrouiller en une seule passe, et il faut l’aide de PlaidCloud pour la clôturer en lots plus petits. C’est un cas limite rare pour la plupart des périodes de reporting.

Une fois une clôture matérialisée, sa relecture applique les règles habituelles du registre, résolues à nouveau en direct à chaque lecture plutôt qu’intégrées à l’instantané lors du verrouillage : vous ne voyez que les lignes des connexions et projets qui vous sont actuellement accordés. Contrairement à la grille en direct, qui montre les montants et l’identité de l’émetteur à tout lecteur pouvant voir la ligne, les chiffres d’une clôture sont masqués sauf si vous détenez erp.register.admin : la même règle que celle qu’applique l’export. Une clôture indique aussi son propre nombre d’arrivées tardives : les écritures soumises ou modifiées après le point haut de la clôture, et donc jamais capturées dans le verrouillage, visibles uniquement en demandant une nouvelle clôture pour la même période, puisque rien ne rouvre une ancienne.

Export

Exports et alertes est l’endroit où le registre quitte la console sous forme de fichier ou de notification, et la seule surface où les contrôles de PlaidCloud cessent de s’appliquer dès que les octets sortent. Produire un export ou planifier une livraison exige erp.register.operate ; ouvrir le registre pour le consulter ne l’exige pas.

Télécharger maintenant

Exportez le registre que vous consultez en CSV compatible Excel ou en JSON, construit à neuf sous vos propres autorisations en vigueur. Deux profils de masquage s’appliquent selon votre rôle :

erp.register.operate obtient le profil standard, masqué : les montants et l’identité de l’émetteur sont retenus.
erp.register.admin obtient le profil d’audit, le seul qui porte les montants et l’identité de l’émetteur non masqués.

Chaque export suit les mêmes règles que le reste du registre : natural_key n’apparaît jamais, les champs de texte libre (commentaires, valeurs de dimensions et de worktags) sont exclus d’emblée plutôt que simplement nettoyés, et un montant non capturé est vide, distingué d’un montant masqué, de sorte qu’un champ vide ne se lit jamais comme « rien n’a été comptabilisé » alors qu’il signifie « votre rôle ne voit pas ceci ».

Planifier une livraison

Créez une planification : un filtre, une cadence, un format et une liste de destinataires par membre, ou une connexion Slack pour une notification sans aucun contenu de ligne. Deux types sont proposés :

Export : une livraison récurrente en CSV ou JSON du registre filtré.
Alerte : une notification déclenchée par l’une de trois conditions : un envoi réel en échec, une autorisation qui vieillit, ou l’inversion d’une écriture. Prévisualisez ce qu’un déclencheur correspondrait actuellement pour vous avant de vous y abonner.

Le fichier de chaque destinataire est construit à partir de ses propres autorisations en vigueur au moment de l’envoi, et non de celles du propriétaire de la planification : deux destinataires d’une même planification peuvent recevoir deux fichiers différents, et un destinataire qui a depuis perdu le rôle d’export, perdu toutes ses autorisations de connexion, été désactivé ou n’a aucune adresse enregistrée est ignoré individuellement avec un motif indiqué plutôt qu’écarté en silence. Seul le propriétaire de la planification ou un détenteur de erp.register.admin peut supprimer ou déclencher la planification de quelqu’un d’autre.

Rétention

Configurez la durée pendant laquelle le registre conserve trois types d’historique : le détail des charges utiles capturées, les écritures simulées et la piste d’audit, chacun en nombre de jours, à l’échelle du locataire, ce qui exige erp.register.admin. Chaque champ est écrit à chaque appel ; un champ omis efface cet horizon plutôt que de le laisser inchangé, et un locataire non configuré conserve tout (chaque horizon vaut null, sans valeur par défaut cachée).

Le balayage de rétention qui applique cette politique s’exécute désormais automatiquement, une fois par jour, à l’échelle du locataire : le même mécanisme de tâches périodiques qui pilote aussi les exports et alertes planifiés, fait vieillir les écritures en retard dans la file des exceptions et fait expirer les anciennes écritures simulées.

Vues de synthèse

Synthèse s’ouvre comme un volet depuis la barre. Regroupez le registre par run, période ou connexion pour voir des sous-totaux et une synthèse des statuts au lieu de lignes individuelles : le regroupement est un contrôle segmenté en haut du volet, ce qui vous permet de passer en place entre Par run, Par période et Par connexion sans rien rouvrir.

Un montant vide reste vide. Une écriture sans montant capturé (toute écriture SAP, une écriture née terminale, ou une écriture saisie avant l’existence de cette fonctionnalité) ne contribue à aucun sous-total et n’est jamais affichée 0.00. Chaque groupe indique en toutes lettres si chaque écriture qu’il contient a été capturée, si certaines ne l’ont pas été, ou si aucune ne l’a été.
Les devises ne sont jamais mélangées dans un même total. PlaidCloud n’effectue aucune conversion de change, de sorte qu’un groupe couvrant plus d’une devise obtient une ligne par devise plutôt qu’un chiffre unique mélangé ; voir Mise en forme des montants.
Une liste de groupes plafonnée totalise quand même correctement. Si un regroupement produit plus de groupes que la vue n’en affiche, la ligne de totaux couvre quand même tous les groupes, et pas seulement ceux affichés, et le précise.

La bannière État des connexions apparaît aussi dans cette vue.

Totaux de contrôle

Totaux de contrôle s’ouvre comme un volet depuis la barre, sur les mêmes connexions et entités auxquelles la règle de visibilité vous limite déjà. Il regroupe les écritures en lots et énonce, pour chacun, un verdict à trois états (Équilibré, Déséquilibré ou Indéterminé) avec la raison indiquée par le serveur, jamais un simple mot.

Indéterminé est une vraie réponse, pas un passage indulgent. Un lot n’est Équilibré que si chaque ligne qu’il contient a été mesurée et que ses groupes concordent. Une fenêtre vide, un montant non capturé, un adaptateur qui envoie sans attendre de réponse, ou une lecture interrompue avant que tout le lot ait été lu reviennent tous Indéterminés, avec la raison précisée, jamais un vert par défaut.
Un montant est vide, jamais zéro. Les totaux source et comptabilisé d’un groupe, ainsi que son écart, sont vides chaque fois que le montant n’a pas été capturé ou confirmé : la même règle que celle des vues de synthèse, car un 0.00 fabriqué sous-estimerait un lot non mesuré tout en passant pour un chiffre faisant autorité.
Les groupes sont par devise et par entité, et jamais additionnés ensemble. PlaidCloud n’effectue aucune conversion de change ; un lot couvrant plus d’une devise ou d’une entité liste donc les totaux propres à chaque groupe côte à côte plutôt que de les mélanger ; voir Mise en forme des montants pour l’affichage de ces chiffres.
Les lignes antérieures à la capture ont leur propre compartiment (no batch id). Une écriture saisie avant l’existence de la capture par lot ne peut pas être regroupée dans un lot qui ne l’a jamais contenue ; elle est donc montrée comme sa propre ligne plutôt qu’intégrée ou supprimée.

La même lecture couvre aussi deux questions connexes : la préparation à la clôture de période, par entité et par période, qui se dégrade en Indéterminé (et non en un faux Bloqué) pour un compartiment pour lequel la plateforme n’a pas encore de chiffres, comme une ligne antérieure à la capture lors d’une clôture de bascule ; et l’écart de confirmation, signalé par document plutôt que par groupe, car deux documents dérivant en sens opposés au sein d’un même groupe devise/entité peuvent s’équilibrer au total et masquer les deux.

Le panneau de détail

Le panneau de détail s’ancre à droite de l’espace de travail, de sorte que la liste reste visible pendant que vous lisez une écriture. Ouvrez-le depuis l’icône en loupe d’une ligne, en appuyant sur Entrée sur la ligne sélectionnée, ou en double-cliquant sur la ligne. Il est organisé en onglets :

Onglet	Affiche
Journal	Les lignes de débit et de crédit de l’écriture, lues comme le ferait un comptable. Voir L’onglet Journal.
Requête/Réponse	La requête sortante et la réponse de l’ERP, filtrées pour la minimisation des données (voir ci-dessous).
Erreurs	Toute erreur renvoyée par l’ERP ou par l’étape de comptabilisation.
Chronologie	Les états de l’écriture dans l’ordre, de la soumission à son état actuel.
Liés	L’écriture d’origine et son inversion, liées l’une à l’autre, lorsqu’il en existe une.
Audit	Un enregistrement en lecture seule de l’activité sur cette écriture. Maigre pour l’instant ; voir L’onglet Audit ci-dessous.
Commentaires	Commentaires en fil sur cette écriture, avec @mention par identifiant de membre. Voir Collaboration.
Validation	L’état de revue actuel de l’écriture (Examiné, Soldé ou Suivi requis) avec tout son historique. Voir Collaboration.

L’onglet Journal

L’onglet Journal lit une écriture comme le ferait un comptable : ses lignes de débit et de crédit par compte, plutôt que la charge utile brute de la requête.

Uniquement les colonnes que chaque ERP capture réellement. L’onglet affiche les champs qu’un système donné envoie, et aucun autre : une écriture Acumatica affiche son sous-compte, alors qu’un système qui n’en envoie jamais n’affiche aucune colonne de sous-compte vide : vous n’avez pas à parcourir des colonnes qui ne contiendront jamais rien.
Les dimensions et les worktags figurent sous chaque ligne. Le détail analytique d’une ligne (ses dimensions, ou ses worktags Workday) apparaît sous la ligne à laquelle il appartient, et non entassé dans des colonnes supplémentaires en haut.
Un cumul par devise avec un contrôle d’équilibre exact. Chaque devise se cumule séparément ; le contrôle ne mélange jamais les devises et n’arrondit jamais à zéro une écriture déséquilibrée, de sorte qu’un véritable déséquilibre s’affiche comme le chiffre qu’il est plutôt que de disparaître dans un 0.00.
Un adaptateur qui ne capture aucun détail de ligne le dit. Lorsqu’un pilote (SAP sur site, par exemple) n’enregistre aucune ventilation par ligne, l’onglet l’indique clairement plutôt que d’afficher une grille vide que vous pourriez lire comme « aucune ligne ».

Triage au clavier

Dans la File d’attente des exceptions, les flèches haut et bas passent d’une écriture à la suivante, le panneau de détail suivant la sélection : vous pouvez ainsi mener tout un passage de triage au clavier, en lisant le détail de chaque écriture à tour de rôle sans toucher à la souris.

La grille principale conserve volontairement la sélection à la souris, Entrée et le double-clic : sa sélection multiligne pilote les actions groupées comme le réessai et l’effacement des écritures simulées ; les flèches y déplacent donc la sélection au lieu de balayer le panneau sur chaque ligne.

Collaboration

Travaillez une écriture avec votre équipe sans quitter le registre : commentez-la avec @mention, enregistrez une validation, ou suivez une connexion ou un run pour son activité future.

Les commentaires sont des notes en texte brut, en fil, sur une écriture, depuis son onglet Commentaires. @mentionnez un collègue par identifiant de membre et il est notifié, s’il peut actuellement voir l’écriture ; cette vérification est refaite au moment de l’envoi, jamais présumée d’après la personne mentionnée.
La validation enregistre l’un de trois états (Examiné, Soldé ou Suivi requis) avec une note facultative, et conserve tout l’historique de qui a défini quoi, et quand. C’est un enregistrement, pas une barrière : rien ne bloque actuellement une écriture ou une inversion en fonction de son état de validation.
Suivre une connexion ou un run (deux bascules distinctes) pour être notifié de l’activité de l’un ou de l’autre à partir de maintenant.

Publier un commentaire, une validation ou un suivi exige erp.register.view et .operate ; les relire n’exige que .view.

Minimisation des données

Le registre est conçu pour montrer ce dont un relecteur a besoin pour confirmer qu’une écriture a eu lieu, sans faire apparaître les données sensibles qu’une étape de comptabilisation a manipulées pour y parvenir.

Les charges utiles de requête et de réponse sont en liste d’autorisation par adaptateur. Un champ n’apparaît que s’il a été explicitement classé comme sûr à conserver. Les numéros de compte bancaire, numéros d’acheminement, IBAN, identifiants fiscaux et autres identifiants personnels sont supprimés avant que vous ne voyiez la charge utile.
La clé métier de l’ERP est entièrement retenue. Elle peut intégrer le nom d’un fournisseur ou un autre jeton de référence ; elle n’atteint donc jamais le registre, y compris l’assistance IA : la même liste d’autorisation qui décide de ce que vous voyez décide de ce qu’une invite de modèle peut voir, et une valeur de clé naturelle n’importe où dans cette charge utile est refusée d’emblée plutôt qu’envoyée. Identifiez une ligne par son identifiant de grand livre, et utilisez confirmation_id comme pointeur de l’ERP vers le document : le même champ que l’historique des envois ERP appelle confirmation_id.
Les champs de texte libre sont nettoyés par motifs à la lecture, et exclus d’emblée (pas seulement nettoyés) du résumé, de toute invite de modèle d’IA et de tout export. Le nettoyage par motifs repère une forme comme un IBAN ou un identifiant fiscal ; il ne peut pas repérer un nom de fournisseur saisi dans un mémo, c’est pourquoi tout ce qui quitte la console sous forme de fichier abandonne ces champs entièrement plutôt que de se fier au seul nettoyage.

L’onglet Audit

L’onglet Audit est en affichage seul. Son détail est volontairement maigre dans cette version, car le vocabulaire d’audit sous-jacent n’a pas encore été classé : attendez-vous à ce qu’il s’étoffe à mesure que ce travail avance, et non à ce qu’il change la façon dont vous lisez le reste du panneau.

Tout le reste de cette page (la file d’attente des exceptions, l’état des connexions, les vues de synthèse, les actions groupées, le réessai à l’unité, l’inversion, les totaux de contrôle, l’assistance IA, les tendances, le lignage, les clôtures, la collaboration et l’export) fonctionne dès aujourd’hui.