Skip to main content
Skip table of contents

Gestion des documents

Rechercher des documents

Principe de classement des documents

Il est d’abord nécessaire d’appréhender le fonctionnement de la GED de Modulr, qui fonctionne pas association de documents à des fiches / entités. Un document pouvant être rattaché à plusieurs fiches / entités. La distinction entre fiches et entités est la suivante :

  • Les entités sont les partenaires du courtier. Il peut s’agir d'un prospect, d’un client, d’un apporteur d’affaires, d’une compagnie ou d’un contact.

  • Les fiches sont les éléments appartenant à une entité et sur lesquels nous pouvons classer des documents / emails. Dans le cas d’un client, ses fiches sont ses devis, projets, contrats, réclamations.

Chaque entité / fiche, dispose d’une étiquette. Il s’agit d’un simple libellé, pouvant s’apparenter à un nom de répertoire, auquel nous pouvons rattacher autant de documents que l’on souhaite.

Il existe également une entité “dossier”, sur laquelle des documents peuvent être classés.

Format des étiquettes de classement

Une étiquette de classement dans une entité / fiche aura le format type:id, ou type désigne la typologie d’entité / de fiche ciblée (ex. : client, compagnie, contrat, sinistres) et id indique l’identifiant de l’entité / la fiche ciblée.

Nom des types d’entités / de fiches

Nature

Libellé en français

Type à utiliser via l’API

Entité

Client

client

Entité

Apporteur d’affaires

producer

Entité

Compagnie

company

Entité

Contact

contact

Entité

Dossier

folder

Fiche

Devis

estimate

Fiche

Projet de contrat

policy

Fiche

Contrat

policy

Fiche

Sinistre

claim

Fiche

Réclamation

complaint

Récupérer les documents d’une entité / fiche

Chaque entité / fiche ayant une étiquette de classement, pour récupérer ses documents nous devons d’abord connaitre l’identifiant de son étiquette, et pour cela, nous devons donc connaitre la nature de la fiche et son identifiant afin d’obtenir le format du libellé de l'étiquette (typeEntité:idEntité).

Une fois cette information connue, on utilise la route route /api/1.0/tags/search pour connaitre l’identifiant de l'étiquette.

Voici quelques exemples :

JSON
# Récupérer l'étiquette du client identifiant 742 :
{
  "filters": {
    "label": {
      "equal": "client:742"
    }
  }
}

# Récupérer l'étiquette du contrat identifiant 1723 :
{
  "filters": {
    "label": {
      "equal": "policy:1723"
    }
  }
}

Dans le résultat, nous avons besoin du tag_id. Exemple de résultat :

JSON
{
  "status": "success",
  "data": {
    "found": 1,
    "current_page": 1,
    "number_of_pages": 1,
    "number_per_page": 100,
    "tags": {
      "172": {
        "tag_id": 236,
        "tag_id_parent": null,
        "label": "client:30",
        "category": "entity",
        "display_restriction": null,
        "tag_id_scope": null
      }
    }
  }
}

Maintenant que nous avons à disposition le tag_id 172, qui est l'étiquette de classement pour notre client identifiant 742, nous pouvons récupérer tous les documents qui y sont rattachés grâce à la route de recherche de document /api/1.0/documents/search et au filtre entity_tag_id_list.

Comme son nom l'évoque, entity_tag_id_list permet de filtrer sur plusieurs étiquettes. Nous pouvons donc en un seul appel API récupérer les documents de plusieurs clients, ou contrats, ou sinistres, etc. On séparera simplement les tag_id par des virgules.

Exemple d’appel API : 

JSON
# Récupérer les documents d'une entité / fiche grâce à son tag_id :
{
  "specific_filters": {
    "entity_tag_id_list": [236]
  }
}

# Récupérer les documents de plusieurs fiches :
{
  "specific_filters": {
    "entity_tag_id_list": [4372,4578,5896]
  }
}

En résultat, nous obtiendrons la liste des documents. Le contenu du document est accessible via un appel GET la route API /api/1.0/documents/id, en remplaçant id par l’identifiant du document.

Filtrer d’avantage les documents à récupérer

Il est tout à fait possible de combiner le filtre sur les tag_id avec des filtres plus génériques, sur des dates par exemples, afin de restreindre d’avantage la liste des documents à récupérer. Pour cela, il faut se référer au swagger afin de connaitre les champs à disposition sur les documents, et à la documentation de la recherche. Voici un exemple :

JSON
# Récupérer les documents d'un client grâce à son tag_id, mais uniquement ceux déposés après juillet 2024
{
  "specific_filters": {
    "entity_tag_id_list": [236]
  },
  creation_date": {
     "greater_equal":"2024-08-01"
  }
}

Récupérer uniquement les documents accessibles au client via son extranet

Modulr permet de rendre certains documents accessibles aux clients via un accès personnel à un extranet. Par défaut, les documents ne sont pas accessibles, mais un utilisateur Modulr peut décider de cliquer sur une icône représentant un œil qui, lorsqu’il est allumé en vert, signifie que le client peut consulter le document.

Sans titre.png

Aperçu d’un document visible (oeil vert) et d’un document non visible (oeil gris)

Pour récupérer uniquement les documents accessibles au client, il faut appliquer un filtre sur une étiquette nommée extranet. On peut récupérer son identifiant comme décrit plus haut, avec le filtre API ci-dessous sur la route api/1.0/tags/search en POST.

JSON
{
  "filters": {
    "label": {
      "equal": "extranet"
    },
    "category": {
      "equal": "system"
    }
  }
}

Dans le résultat, nous conservons le champ tag_id (exemple : 2) pour ensuite filtrer la route /api/1.0/documents/search avec le filtre system_tag_id_list comme ceci :

JSON
{
  "specific_filters": {
    "system_tag_id_list": [2]
  }
}

On pourra évidemment cumuler avec des filtres par date et/ou fiche client. Par exemple, pour obtenir les documents du client identifiant 742 dont l'étiquette a l’identifiant 236, visible dans son extranet et ajoutés après 2025, on appliquera les filtres suivants à la route /api/1.0/documents/search :

CODE
{
  "specific_filters": {
    "entity_tag_id_list": [236]
  },
  "specific_filters": {
    "system_tag_id_list": [2]
  }
  creation_date": {
     "greater_equal":"2025-01-01"
  }
}
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.