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 |
|
Entité | Apporteur d’affaires |
|
Entité | Compagnie |
|
Entité | Contact |
|
Entité | Dossier |
|
Fiche | Devis |
|
Fiche | Projet de contrat |
|
Fiche | Contrat |
|
Fiche | Sinistre |
|
Fiche | Réclamation |
|
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 :
# 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 :
{
"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 :
# 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 :
# 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.

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.
{
"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 :
{
"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
:
{
"specific_filters": {
"entity_tag_id_list": [236]
},
"specific_filters": {
"system_tag_id_list": [2]
}
creation_date": {
"greater_equal":"2025-01-01"
}
}