Le XBRL, bâti comme une ontologie. D'où le où et le pourquoi.

Le problème

Le temps passe à chercher ce qui ne va pas.

Les validateurs XBRL savent très bien dire non. Ils disent rarement où, presque jamais pourquoi, et au lieu d'indiquer quoi changer, ils vous renvoient le travail.

• Un code d'erreur tombe, et rien n'indique de quel fichier ni de quelle ligne il provient.
• Comprendre ce qu'il signifie suppose un détour par la spécification.
• Et une fois le problème identifié, personne ne dit toujours pas quoi changer.
• Résultat : chaque question de l'équipe de dépôt remonte à vos développeurs.
• Et après une mise à jour, ce qui passait hier échoue aujourd'hui sans un mot.

Intégration

Vos écrans. Vos processus. MirrorMere reste invisible.

Un fichier dans votre build, et c'est fait. Chaque spécification est un module distinct : prenez seulement celles que vous traitez, et quelle que soit celle qui détecte un problème, la réponse revient sous la même forme.

// One result type, whichever specification produced it.
ValidationOutcome outcome = validator.validate(report);

if (!outcome.isValid()) {
    for (ValidationFinding f : outcome.errors()) {
        f.code();      // ixe:illegalMultipleUseOfId
        f.specRef();   // Inline XBRL 1.1, Section 4
        f.location();
    }
}