Le Monde Sémantique
Base de connaissance
Extension Commerciale
La quantité de données non-structurées dans les entreprises augmente considérablement, de plus; utiliser un tableur Excel pour la comptabilité ou un logiciel mal-paramétré et non-connecté (hors-ligne) ne fait qu'accroître ce problème.
C'est pourquoi, l'ontologie comptable et financière intègre toutes les données ci-dessous structurées (mise-en-production) directement au modèle d'affaires de l'entreprise.
- Livier Guidat -
Directeur
Le Monde Sémantique
1. L'ONTOLOGIE COMPTABLE FINANCIÈRE
En préambule:
Dans le cadre de sa nouvelle politique commerciale, l'entrepriseXYZ (ici exemple.com) veut proposer à ses clients un point de vente innovant (en-ligne) qui fasse d'une pierre deux coups: 1) faire progresser son chiffre d'affaires en améliorant la satisfaction de ses clients par un suivi en temps-réel des commandes et 2) intégrer un système de coûts à la comptabilité financière de l'organisation.
1.1. Le modèle d'affaires de l'entreprise
1.1.1. Présentation générale
L'entreprise xyz fabrique et vend cinq produits finis. Son objectif est de vendre les différentes gammes de sa production en utilisant une base de données de type graphe. Sa décision s'appuie sur le fait qu'un graphe est beaucoup plus agile qu'une base de données relationnelle classique où l'information est organisée dans des tableaux (tables à deux dimensions).
En effet, un graphe est composé de plusieurs dimensions de relations qui incluent aussi les méta-données. C'est pourquoi, il peut s'intégrer beaucoup plus facilement au coeur de son métier et aux processus mêmes de l'organisation ainsi qu'à ses trois niveaux de prise de ses décisions; stratégique, tactique et opérationnelle.
1.2. Mise-en-production
Toutes les requêtes .com préliminaires sont en "open-source":
1.2.1. Requêtes commerciales préliminaires
- La première requête RDF "INSERT" (au format .ttl) crée le compte du client 001 :
# open-source: 1_2_1_A.ttl
@prefix compta: <https://data.exemple.com/comptabilité/> .
@prefix taxo: <https://taxonomies.exemple.com/commerce/> .
@prefix adresse: <https://ontologies.lemondesémantique.fr/base/adresse/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Accord> rdf:type owl:Class .
<https://data.exemple.com/comptabilité/CompteClient> rdfs:subClassOf base:Accord .
compta:_Client_URI_1 rdf:type compta:CompteClient;
compta:date_de_création "2020-10-26T21:47:22Z"^^xsd:dateTime ;
compta:dernière_visite "2020-10-26T21:51:04Z"^^xsd:dateTime ;
compta:identifiéPar compta:_Client_ID_001.
compta:_Client_ID_001 base:texteUnique "Le premier client en-ligne de l'entreprise xyz"^^xsd:string .
<https://ontologies.lemondesémantique.fr/base/Personne> rdf:type owl:Class .
<https://data.exemple.com/comptabilité/ClientPhysique> rdfs:subClassOf base:Personne .
compta:_Client_URI_1 rdf:type compta:ClientPhysique;
rdfs:label "La personne physique: Client 001";
base:possède compta:_Panier_client_1.
<https://ontologies.lemondesémantique.fr/base/Solde> rdf:type owl:Class .
<https://data.exemple.com/comptabilité/PanierClient> rdfs:subClassOf base:Solde .
compta:_Panier_client_1 rdf:type compta:PanierClient;
base:a_pour_Amplitude compta:Montant_PanierClient_ID_001.
compta:Montant_PanierClient_ID_001 base:valeurDécimale "0"^^xsd:décimal.
Quelques éclaircissements:
La classe "compta:CompteClient" est une sous-classe de "base:Accord". Un accord est (compris comme étant) passé entre l'entreprise xyz et la personne physique (Client1).
La classe "compta:ClientPhysique" est une sous-classe de "base:Personne".
Enfin une classe supplémentaire "compta:PanierClient" a été créée, comme sous-classe de "base:Solde".
Comme vous pouvez le lire, une instance appelée compta:_Panier_client_1 est associée a l'URI/instance compta:_Client_URI_1 par la propriété "base:possède".
Le montant initial du panier est nul: base:valeurDécimale "0"^^xsd:décimal.
Un identifiant unique est donné au client par les deux propriétés suivantes: "compta:identifiéPar" et "base:texteUnique".
Remarque:
La même instance compta:_Client_URI_1 est utilisée ici pour identifier: le compte client1 et la personne physique client1. Par la suite; un client sous la forme d'une personne morale sera également créé.
- La deuxième requête RDF "INSERT" (au format .ttl) crée une fiche-client minimaliste:
# open-source: 1_2_1_B.ttl
@prefix compta: <https://data.exemple.com/comptabilité/> .
@prefix taxo: <https://taxonomies.exemple.com/commerce/> .
@prefix adresse: <https://ontologies.lemondesémantique.fr/base/adresse/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Collection> rdf:type owl:Class .
<https://taxonomies.exemple.com/commerce/ClientEntrepriseXYZ> rdfs:subClassOf base:Collection .
compta:ClientPointDeVenteXYZ a taxo:ClientEntrepriseXYZ .
compta:_Client_ID_001 base:clientDe compta:ClientPointDeVenteXYZ .
compta:_Client_ID_001 taxo:a_pour_identité_et_pour_adresse
[ taxo:a_identité_et_adresse taxo:Nom_de_famille ; taxo:renseignement "HUTTON" ] ,
[ taxo:a_identité_et_adresse taxo:Prénom ; taxo:renseignement "Olivier" ] ,
[ taxo:a_identité_et_adresse taxo:Fonction ; taxo:renseignement "Directeur commercial" ] ,
[ taxo:a_identité_et_adresse taxo:Entreprise ; taxo:renseignement "gs1fr" ] ,
[ taxo:a_identité_et_adresse adresse:Télephone ; taxo:renseignement "0140221762" ] ,
[ taxo:a_identité_et_adresse adresse:Courriel ; taxo:renseignement "olivier.hutton@gs1fr.org" ] ,
[ taxo:a_identité_et_adresse adresse:Adresse ; taxo:renseignement "100 Allée de Chamblit" ] ,
[ taxo:a_identité_et_adresse adresse:CP ; taxo:renseignement "74160" ] ,
[ taxo:a_identité_et_adresse adresse::Ville ; taxo:renseignement "Vers" ] ,
[ taxo:a_identité_et_adresse adresse:Pays ; taxo:renseignement "France" ] .
Note:
L'identité du client1 est renseignée par cette fiche-client non-exhaustive. Son identifiant compta:_Client_ID_001 est utilisé pour lui associer la liste des renseignements souhaités.
- Afin d'interroger la liste des informations renseignées dans la fiche-client de chaque client identifié, voilà la requête "sparql SELECT" à exécuter:
# open-source: 1_2_1_C.rq
prefix compta: <https://data.exemple.com/comptabilité/>
prefix taxo: <https://taxonomies.exemple.com/commerce/>
prefix adresse: <https://ontologies.lemondesémantique.fr/base/adresse/>
prefix base: <https://ontologies.lemondesémantique.fr/base/>
SELECT ?client ?id ?renseignement {
?client base:clientDe compta:ClientPointDeVenteXYZ .
?client taxo:a_pour_identité_et_pour_adresse ?noeudvide .
?noeudvide taxo:a_identité_et_adresse ?id ;
taxo:renseignement ?renseignement .
}
| Identifiant du client | identité et adresse | Renseignement |
| compta:_Client_ID_001 | taxo:Nom_de_famille | "HUTTON" |
| compta:_Client_ID_001 | taxo:Prénom | "Olivier" |
| compta:_Client_ID_001 | taxo:Fonction | "Directeur commercial" |
| compta:_Client_ID_001 | taxo:Entreprise | "gs1fr" |
| compta:_Client_ID_001 | adresse:Télephone | "0140221769" |
| compta:_Client_ID_001 | adresse:Courriel | "olivier.hutton@gs1fr.org" |
| compta:_Client_ID_001 | adresse:Adresse | "100 Allée de Chamblit" |
| compta:_Client_ID_001 | adresse:CP | "74160" |
| compta:_Client_ID_001 | adresse:Ville | "Vers" |
| compta:_Client_ID_001 | adresse:Pays | "France" |
- La troisième requête RDF "INSERT" (au format .ttl) crée une fiche-produit en classant chaque produit dans une catégorie distincte:
# open-source: 1_2_1_D.ttl
@prefix compta: <https://data.exemple.com/comptabilité/> .
@prefix taxo: <https://taxonomies.exemple.com/commerce/> .
@prefix adresse: <https://ontologies.lemondesémantique.fr/base/adresse/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Catégorie> rdf:type owl:Class .
<https://ontologies.lemondesémantique.fr/base/Catégorie_de_Produit> rdfs:subClassOf base:Catégorie .
taxo:Catégorie_de_Produit1 a base:Catégorie_de_Produit .
taxo:Catégorie_de_Produit2 a base:Catégorie_de_Produit .
taxo:Catégorie_de_Produit3 a base:Catégorie_de_Produit .
taxo:Catégorie_de_Produit4 a base:Catégorie_de_Produit .
taxo:Catégorie_de_Produit5 a base:Catégorie_de_Produit .
taxo:Catégorie_de_Produit1 base:définiPar taxo:AdminEntrepriseXYZ .
taxo:Catégorie_de_Produit2 base:définiPar taxo:AdminEntrepriseXYZ .
taxo:Catégorie_de_Produit3 base:définiPar taxo:AdminEntrepriseXYZ .
taxo:Catégorie_de_Produit4 base:définiPar taxo:AdminEntrepriseXYZ .
taxo:Catégorie_de_Produit5 base:définiPar taxo:AdminEntrepriseXYZ .
compta:P1 base:catégoriséPar taxo:Catégorie_de_Produit1 .
compta:P2 base:catégoriséPar taxo:Catégorie_de_Produit2 .
compta:P3 base:catégoriséPar taxo:Catégorie_de_Produit3 .
compta:P4 base:catégoriséPar taxo:Catégorie_de_Produit4 .
compta:P5 base:catégoriséPar taxo:Catégorie_de_Produit5 .
Remarque:
Pour bien comprendre comment créer la catégorie du produit, veuillez-vous référer à la base de connaissance de l'ontologie.
- La quatrième requête RDF "INSERT" (au format .ttl) fixe un prix de vente unitaire à chacun des cinq produits finis:
# open-source: 1_2_1_E.ttl
@prefix compta: <https://data.exemple.com/comptabilité/> .
@prefix taxo: <https://taxonomies.exemple.com/commerce/> .
@prefix adresse: <https://ontologies.lemondesémantique.fr/base/adresse/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Amplitude/> rdf:type owl:Class .
<https://ontologies.lemondesémantique.fr/base/AmplitudeSource> rdfs:subClassOf base:Amplitude .
<https://data.exemple.com/comptabilité/Prix_Unitaire> rdfs:subClassOf base:AmplitudeSource .
<https://ontologies.lemondesémantique.fr/base/UnitéDeMesure> rdf:type owl:Class .
<https://taxonomies.exemple.com/commerce/UnitéMonétaire> rdfs:subClassOf base:UnitéDeMesure .
compta:_euro a taxo:UnitéMonétaire .
compta:P1 a compta:Prix_Unitaire ;
base:valeurDécimale "400"^^xsd:décimal ;
base:devise compta:_Euro .
compta:P2 a compta:Prix_Unitaire ;
base:valeurDécimale "325"^^xsd:décimal ;
base:devise compta:_Euro.
compta:P3 a compta:Prix_Unitaire ;
base:valeurDécimale "800"^^xsd:décimal ;
base:devise compta:_Euro.
compta:P4 a compta:Prix_Unitaire ;
base:valeurDécimale "320"^^xsd:décimal ;
base:devise compta:_Euro.
compta:_P5 a compta:Prix_Unitaire ;
base:valeurDécimale "530"^^xsd:décimal ;
base:devise compta:_Euro.
Note:
L'unité monétaire utilisée par l'entrepriseXYZ pour vendre ses cinq produits finis est l'€uro.
2. GRAPHE DE CONNAISSANCE
Un graphe modélise fidèlement un domaine particulier de connaissance. Plus la compréhension de ce domaine est exhaustive, et plus le graphe de connaissance correspond à la réalité du domaine modélisé.
Nous prendrons le symbole yin/yang comme point de départ (et synthèse) à la modélisation d'un rapport commercial:
Nous allons utiliser les classes et propriétés (ci-dessus) comme objets et concepts essentiels de l'ontologie "Base" en interaction avec les clients de l'entrepriseXYZ et son personnel actif pour gérer les flux de trésorerie de son portefeuille d'activités commerciales et pour rendre plus intelligible encore son coeur de métier.
2.1 Événement
2.1.1 Offre
Acte 1 (scène 1)
Avant de pouvoir vendre ses cinq produits finis, l'entrepriseXYZ doit composer une offre pour chacun d'eux. La requête suivante (rdf insert au format .ttl) inclue la référence du prix unitaire ainsi qu'une date de début et de fin. Ci-dessous seule la composition de l'offre du produit P1 est présentée:
# open-source: 2_1_1_A.ttl
@prefix compta: <https://data.exemple.com/comptabilité/> .
@prefix taxo: <https://taxonomies.exemple.com/commerce/> .
@prefix adresse: <https://ontologies.lemondesémantique.fr/base/adresse/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://data.exemple.com/comptabilité/Offre> rdf:type owl:Class ;
owl:equivalentClass [ rdf:type owl:Restriction ;
owl:onProperty base:concerne ;
owl:someValuesFrom [ rdf:type owl:Class ;
owl:unionOf ( compta:Exigence
compta:Ressource
)
]
] .
<https://data.exemple.com/comptabilité/Ressource> rdf:type owl:Class ;
rdfs:comment "Une source à partir de laquelle un bénéfice est produit"^^xsd:string .
<https://data.exemple.com/comptabilité/Exigence> rdf:type owl:Class ;
rdfs:comment "Une exigence à remplir"^^xsd:string .
compta:_URI_Offre_Du_Produit_P1 a compta:Offre ;
rdfs:label "L'offre de vente du Produit P1 par l'entrepriseXYZ" ;
base:concerne compta:_prix_unitaire_P1 .
compta:début_Offre_Du_Produit_P1 a base:InstantDeTemps ;
rdfs:label "Date de début de l'offre du produit P1" ;
base:heureLocale "2020-04-13T00:00:00Z"^^xsd:dateTime .
compta:fin_Offre_Du_Produit_P1 a base:InstantDeTemps ;
rdfs:label "Date de fin de l'offre du produit P1" ;
base:heureLocale "2023-04-13T00:00:00Z"^^xsd:dateTime .
compta:EntrepriseXYZ_Offre1_URI base:débutActuel compta:début_Offre_Du_Produit_P1 ;
base:finActuelle compta:fin_Offre_Du_Produit_P1 .
taxo:AdminEntrepriseXYZ taxo:compose compta:EntrepriseXYZ_Offre1_URI .
Note:
-
La propriété
base:concerneest employée pour lier l'offre à son prix unitaire:compta:_prix_unitaire_P1. -
La propriété
base:composerelie l'offre à son créateur:taxo:AdminEntrepriseXYZ.
Acte 1 (scène 2)
La requête sparql suivante nous permet de visualiser toutes les offres créées par l'entrepriseXYZ :
# open-source: 2_1_1_B.rq
SELECT distinct ?URI_Offre ?Prix_de_vente ?label ?date_de_début ?date_de_fin
WHERE { ?URI_Offre rdf:type compta:Offre;
rdfs:label ?label;
base:concerne ?Ressource.
?Ressource base:catégoriséPar ?Prix_Unitaire .
?Prix_Unitaire base:valeurDécimale ?Prix_de_vente .
?début rdf:type ?temps ;
base:heureLocale ?date_de_début .
?fin rdf:type ?temps ;
base:heureLocale ?date_de_fin .
?_URI_EntrepriseXYZ_Offre1 base:débutActuel ?début ;
base:finActuelle ?fin .
}
Le résultat:
| ?URI_Offre | ?Prix_de_vente | ?label | ?date_de_début | ?date_de_fin |
| compta:_URI_Offre_Du_Produit_P1 | "400.0" | P1... | "2020-04-13T00:00:00Z" | "2023-04-13T00:00:00Z" |
| compta:_URI_Offre_Du_Produit_P2 | "325.0" | P2... | "2020-04-13T00:00:00Z" | "2023-04-13T00:00:00Z" |
| compta:_URI_Offre_Du_Produit_P3 | "800.0" | P3... | "2020-04-13T00:00:00Z" | "2023-04-13T00:00:00Z" |
| compta:_URI_Offre_Du_Produit_P4 | "320.0" | P4... | "2020-04-13T00:00:00Z" | "2023-04-13T00:00:00Z" |
| compta:_URI_Offre_Du_Produit_P5 | "530.0" | P5... | "2020-04-13T00:00:00Z" | "2023-04-13T00:00:00Z" |
Acte 1 (scène 3)
Cette requête sparql permet à l'entrepriseXYZ de distinguer en temps-réel les offres "actuelles" (à savoir; celles dont la "date de fin" est postérieure à l'instant présent) des offres "inactuelles" (à savoir; celles dont la "date de fin" est antérieure au moment présent):
# open-source: 2_1_1_C.rq
SELECT ?_URI_EntrepriseXYZ_Offres ?date_de_fin
WHERE { ?fin rdf:type ?temps ;
base:heureLocale ?date_de_fin .
?_URI_EntrepriseXYZ_Offres base:débutActuel ?début ;
base:finActuelle ?fin .
BIND (now() as ?now)
FILTER (?now < ?date_de_fin)
}
Le résultat:
| URI des offres | Date de fin |
| compta:EntrepriseXYZ_Offre1_URI | "2023-04-13T00:00" |
| compta:EntrepriseXYZ_Offre2_URI | "2023-04-13T00:00" |
| compta:EntrepriseXYZ_Offre3_URI | "2023-04-13T00:00" |
| compta:EntrepriseXYZ_Offre4_URI | "2023-04-13T00:00" |
| compta:EntrepriseXYZ_Offre5_URI | "2023-04-13T00:00" |
2.1.2 Achat
Le premier client 001 souhaite achèter le produit P1 à l'entrepriseXYZ.
Acte 2 (scène 1)
Un achat se produit lorsqu'un client accepte une offre.
Cette acceptation n'est pas encore considérée comme une transaction réussie, néanmoins elle peut être considérée comme le point de départ "obligé" du processus d'un paiement effectif.
La prochaine requête "rdf insert" insére tous les triplets nécessaires et suffisants pour commencer le processus d'achat du produit P1 par le client 001 :
L'intégralité du graphe de connaissance
avec toutes les requêtes .com
est DISPONIBLE
ci-dessous:
Inférences
Acte 2 (scène 2,3)
Acte 2 (scène 4)
Acte 2 (scène 5)
Panier-client crédité
Acte 2 (scène 6)
2.1.3 Mouvement
Acte 3 (scène 1)
Acte 3 (scène 2)
La sous-classe commune: "Acquisition" :
2.1.4 Transfert
Acte 4 (scène 1)
Acte 4 (scène 2)
La sous-classe commune: "Acquisition" :
2.1.5 Allocation
Acte 5 (scène 1)
2.2 Responsabilité / Dette
2.2.1 Obligation de payer
Acte 6 (scène 1)
2.2.2 Obligation de livraison
Acte 6 (scène 2)
2.3 État de la transaction
2.3.1 Propriété
Acte 7 (scène 1)
2.3.2 Possession
Acte 7 (scène 2)
2.3.3 Acquisition
Acte 7 (scène 3)
2.4 Ressource
2.4.1 Un suivi en temps-réel des commandes passées
Acte 8 (scène 1)
2.4.2 Actif / Amplitude dérivée
Acte 8 (scène 2)
2.4.3 Transaction sourcée
Acte 8 (scène 3)
2.4.4 Purge du panier
Acte 8 (scène 4)
2.4.5 Historique des paiements
Acte 8 (scène 5)
Le Monde Sémantique
améliore la Vie des Entreprises.
Copyright © 2018-2024