Aller au contenu principal

Rapports d'intégrité

Le modèle système Integrity reports regroupe des contrôles SQL qui comparent NomaUBL à un système source et listent ce qui manque ou diverge : travaux d'impression jamais intégrés, écritures comptables dont les montants diffèrent des factures électroniques… Chaque contrôle exécute des SELECT en lecture seule — une requête unique, ou une requête source et une requête cible sur deux bases différentes, comparées en mémoire — et chaque ligne renvoyée est une anomalie. Les résultats s'affichent dans l'onglet Intégrité de la page Rapports, où un contrôle peut aussi proposer une action sur les lignes sélectionnées.

Il s'ouvre dans Configuration → Système → Integrity reports. Sur une installation qui ne dispose pas encore du modèle, le bouton Add integrity reports le crée sans redémarrer le service. Le modèle est livré vide : rien n'apparaît dans la page Rapports tant qu'aucun contrôle n'est défini.


Vue d'ensemble​

Contrôlemissing-pdfSELECT … NOT IN F564230connecteur · colonnes clésaction facultativeLecture seulepériode → variables de dateSELECT / WITH uniquementplafond de lignes · délaiRapports → Intégritéune ligne = une anomalierecherche · filtres · exportcocher les lignes à corrigerActionIntégrer les travaux BIPfetch-single … bipcontrôle relancéles lignes intégrées sortent du résultat suivant

Paramètres généraux​

ChampDéfautDescription
Max rows5000Nombre maximal de lignes par exécution. Au-delà, le résultat est tronqué et signalé résultat tronqué au plafond de lignes dans la page Rapports.
Timeout (s)120Délai maximal d'exécution de la requête, en secondes.

Modes​

Le champ Mode d'un contrôle détermine la façon dont ses lignes sont produites.

ModeRésultat
Direct (défaut)Une seule requête ; ses lignes sont les anomalies. Pour deux systèmes dans la même base.
MissingLignes source dont la clé est absente de la cible.
ExtraLignes cible dont la clé est absente de la source.
MismatchClés présentes des deux côtés dont les colonnes comparées diffèrent.

Les trois modes de comparaison exécutent une requête source et une requête cible, chacune sur son propre connecteur — par exemple JD Edwards sur SQL Server et NomaUBL sur PostgreSQL — et rapprochent leurs lignes en mémoire sur les colonnes clés. Les clés sont normalisées avant le rapprochement : espaces de fin, zéros de tête, nombre de décimales et formats de date ne faussent plus la correspondance.

Requête sourceSource connector · Source SQLRequête cibleTarget connector · Target SQLRapprochement sur les clésclés normalisées"0042 " = "42"Missingdans la source, absente de la cibleExtradans la cible, absente de la sourceMismatchdes deux côtés, colonnes comparées différentes

Contrôles​

Chaque contrôle est un groupe repliable — un clic sur son titre l'ouvre, × le supprime, + Add check en ajoute un.

ChampDescription
NameIdentifiant affiché dans la page Rapports (par ex. missing-pdf). À garder stable.
DescriptionUne ligne qui dit ce que le contrôle détecte (par ex. Travaux d'impression PDF non intégrés).
Start fromFacultatif. Préremplit le contrôle à partir d'une comparaison JD Edwards connue — voir Modèles de requête.
ModeDirect, Missing, Extra ou Mismatch — voir Modes.
ConnectorLe connecteur de base de données sur lequel s'exécute le SELECT — la base JD Edwards, la base NomaUBL ou tout autre connecteur déclaré sur la plateforme.
Key columnsFacultatif. Colonnes du résultat, séparées par des virgules, qui identifient l'enregistrement visé par une action (par ex. JCPID, JCVERS, JCJOBNBR, ou numéro + type de document + société).
SQL (SELECT only)La requête. Une seule instruction SELECT (ou WITH) ; toute autre instruction est refusée avant d'atteindre la base. La connexion est ouverte en lecture seule.
ActionCe que la page Rapports peut faire des lignes sélectionnées : aucune action, ou Integrate BIP jobs.

Dans les modes de comparaison, Connector, Key columns et SQL deviennent Source connector, Source key columns et Source SQL, et d'autres champs apparaissent :

ChampDescription
Target connectorConnecteur de base de données de la requête cible — il peut différer de celui de la source.
Target key columnsColonnes du résultat cible qui correspondent aux colonnes clés de la source, dans le même ordre. Vide = mêmes noms.
Target SQLLa requête cible (par ex. SELECT TRIM(FEWDS1) AS JOBKEY FROM F564230 WHERE FEUPMJ >= {fromJde}). Les variables de date s'appliquent aux deux requêtes.
Compare columns (Mismatch)Paires de colonnes SOURCE=CIBLE séparées par des virgules (par ex. AMOUNT_HT=UHATXA, DOC_DATE=UHDIVJ). Une ligne est une anomalie dès qu'une paire diffère.
Tolerance (Mismatch)Deux valeurs numériques dont l'écart ne dépasse pas ce montant sont considérées comme égales. Par défaut 0.01.

En mode Mismatch, le résultat reprend les colonnes source, puis une colonne TARGET_<colonne> par paire comparée avec la valeur cible, et une colonne DIFFERENCE qui nomme les colonnes en écart.

Variables de date​

Le SQL peut reprendre la période choisie dans la page Rapports. Les variables sont remplacées avant l'exécution ; sans période, l'intervalle va du 1900-01-01 à aujourd'hui.

VariableFormatExemple
{from} / {to}yyyy-MM-dd2026-09-01
{fromJde} / {toJde}Date julienne JDE (CYYDDD)126244
{fromDMY} / {toDMY}dd-MM-yyyy01-09-2026

Le champ SQL propose la forme habituelle d'un contrôle — les enregistrements source de la période qui n'ont jamais atteint le journal NomaUBL (F564230) :

SELECT … FROM … WHERE JCSTDTIM > TO_DATE('{fromDMY}','dd-MM-yyyy')
AND … NOT IN (SELECT TRIM(FEWDS1) FROM PRODDTA.F564230 WHERE FEUPMJ > {fromJde})

Le sélecteur Insert placeholder, sous le libellé de chaque champ SQL, liste toutes les variables avec leur format et insère celle choisie à la position du curseur.

Variables BIP​

Spécifique à JDE

Ces variables lisent la liste des états des réglages de la file d'impression JDE (BIP).

Trois variables supplémentaires suivent le paramétrage BIP : un contrôle n'a ainsi jamais besoin d'une liste d'états et de versions tenue à la main.

VariableRemplacée par
{bipReports}Les noms d'états configurés, entre apostrophes, pour une liste IN : 'R42565','R03B505'.
{bipFilter:COLETAT,COLVERSION}Le prédicat utilisé par la recherche BIP, sur les colonnes indiquées : ((TRIM(COLETAT)='R42565' AND TRIM(COLVERSION)='XJDE0001') OR TRIM(COLETAT)='R03B505'). Une ligne réglée sur toutes les versions ne filtre que sur l'état.
{bipTemplate:COLETAT,COLVERSION}Une expression CASE qui donne le document de chaque ligne, d'après le document défini sur chaque ligne d'état.

Sans état configuré, le filtre devient 1=0 et la liste NULL : le contrôle ne renvoie rien plutôt que toutes les tâches.

Modèles de requête​

La liste Start from préremplit un contrôle — mode, connecteurs, colonnes clés, SQL et action — à partir d'une comparaison connue :

ModèleContrôle
BIP jobs not integrated (F986114 vs F564230)Les tâches d'impression BIP des états configurés jamais arrivées dans NomaUBL, avec l'action Integrate BIP jobs. Utilise {bipFilter} et {bipTemplate}.
Accounting invoices not in NomaUBL (F03B11 vs F564231)Les factures du compte client de la période absentes de NomaUBL.
Sales-order invoices not in NomaUBL (F4211/F42119 vs F564231)Les factures produites par la mise à jour des commandes clients, lignes ouvertes et historiques, absentes de NomaUBL.
Amounts JDE vs NomaUBL (F03B11 vs F564231, mismatch)Les factures présentes des deux côtés dont les montants diffèrent.

Sur un contrôle qui contient déjà du SQL, l'éditeur demande confirmation avant de le remplacer (Replace this check?). Les préfixes de schéma (PRODDTA, SVM920) et les codes de statut sont les valeurs usuelles : les adapter à l'environnement JD Edwards, puis enregistrer.

Action Integrate BIP jobs​

Spécifique à JDE

Cette action extrait des travaux JD Edwards BI Publisher. Les contrôles sans action fonctionnent avec tout système source.

Avec Action = Integrate BIP jobs, les lignes sélectionnées sont intégrées exactement comme par la commande fetch-single <template> bip <job> (voir Ligne de commande), via le lot Fetch Invoices. Cinq champs indiquent les colonnes du résultat à utiliser :

ChampDescription
Job columnColonne du résultat qui porte le numéro de travail JDE (RJJOBNBR). Obligatoire.
Template columnColonne du résultat qui porte le nom du document. À laisser vide pour utiliser le modèle fixe.
Fixed templateDocument utilisé quand la colonne modèle est vide ou absente.
Host columnColonne du résultat qui porte le serveur d'exécution JDE — uniquement sur les installations JD Edwards à plusieurs serveurs. Facultatif.
Processing typeAUTO (défaut), SINGLE, BURST, UBL ou BOTH.

Dans la page Rapports​

Contrôlemissing-pdf ▾📅 30 derniers jours▶ ExécuterVoir le SQL
Connecteur : db-jde · Colonnes clés : JCPID, JCVERS, JCJOBNBR · Action : fetch-single invoices bip {JCJOBNBR}
3 anomalie(s)Intégrer la sélection (2)
JCPIDJCVERSJCJOBNBRJCSTDTIM
☑R42565ZJDE000113533062026-10-08 06:12
☑R42565ZJDE000113534122026-10-09 06:10
☐R42565ZJDE000213535202026-10-10 06:11
  1. Choisir un contrôle et une période (30 derniers jours par défaut), puis Exécuter. Voir le SQL affiche la requête du contrôle.
  2. La ligne d'en-tête rappelle le connecteur, les colonnes clés et l'action configurée. Sur un contrôle de comparaison, une seconde ligne ajoute le mode, le connecteur cible et, en Mismatch, les colonnes comparées avec la tolérance ; Voir le SQL affiche alors les deux requêtes, et le décompte indique N source / N cible. Le résultat indique Aucune anomalie ou N anomalie(s) ; chaque ligne est une anomalie, dans la grille standard — recherche, filtres, choix des colonnes et export.
  3. Quand le contrôle porte une action, cocher les lignes puis cliquer sur Intégrer la sélection (N). Une confirmation rappelle que les travaux sont extraits et traités comme lors d'un traitement normal — validation, stockage et envoi selon le paramétrage du modèle.
  4. Après l'action, le contrôle est relancé : les lignes intégrées sortent du résultat, et un bandeau de synthèse affiche N intégré(s), N en échec sur N, avec le nom de chaque travail en échec.

API​

EndpointRôle
GET /api/reports/integrityListe les contrôles configurés (nom, description, connecteur, colonnes clés, SQL).
POST /api/reports/integrity/runExécute un contrôle — corps { "name", "dateFrom", "dateTo" } — et renvoie les colonnes et les lignes du résultat.
POST /api/reports/integrity/actionExécute l'action du contrôle sur les lignes sélectionnées — corps { "name", "jobs": [...], "templates": [...], "hosts": [...] } — et renvoie le résultat par travail et la synthèse.

Les schémas complets se trouvent dans la référence API.


Conseils & bonnes pratiques​

  • Une question par contrôle. Un contrôle qui répond à une seule question (travaux non intégrés, montants différents) donne un résultat exploitable ligne par ligne.
  • Renvoyer les colonnes clés. Même sans action, elles permettent de remonter facilement de chaque anomalie à l'enregistrement source.
  • Limiter la requête à la période. Les variables de date la cantonnent à la fenêtre choisie et la gardent bien en deçà du délai maximal.
  • Pointer l'action sur le numéro de travail. La colonne travail doit contenir le numéro de travail JDE ; les lignes qui n'en ont pas sont ignorées par Intégrer la sélection.