Solution Modèle de partie et carnet d’adresses global

Effectué

La solution Modèle de partie et carnet d’adresses global est une fonctionnalité dédiée à la double écriture qui couvre principalement trois scénarios différents.

Scénario 1

Dans ce scénario, une personne ou organisation peut jouer plusieurs rôles dans une entreprise et doit changer de rôle en fonction du contexte.

Par exemple, un collaborateur de Contoso US dispose de ses informations d’identification personnelles et comme il est basé aux États-Unis, il peut se connecter à un portail d’e-commerce et acheter des produits. Comme il peut être un consommateur de ces produits, il est donc un client. Cependant, il peut également se connecter au portail d’e-commerce et créer et développer des applications, puis les vendre au moyen du portail sur les marchés américain et canadien. Dans ce scénario, cet utilisateur est un client, mais il est également un fournisseur.

Les principales difficultés de ce scénario comprennent la capacité à :

  • représenter une personne en tant que contact, client, fournisseur ou toutes ces options ;

  • représenter une organisation en tant que client, fournisseur ou les deux ;

  • permettre à chaque personne ou organisation d’effectuer des transactions sur plusieurs marchés, puis de les suivre sur chaque marché, de bout en bout.

    Schéma montrant qu’un utilisateur peut jouer plusieurs rôles.

Scénario 2

Ce scénario est lié aux transactions que l’utilisateur peut effectuer. Un utilisateur ou une société peut avoir besoin de plusieurs profils différents pour les adresses, les taxes et les règles et réglementations de chaque pays pour effectuer des transactions dans chacun d’entre eux. Il est essentiel de disposer d’un profil générique et de plusieurs profils financiers pour chaque pays ou ensemble de besoins transactionnels. Chaque profil financier est considéré comme le client dans le cadre d’une transaction, et non comme le profil générique. Cependant, si une modification est apportée au profil générique, comme un changement de nom ou d’adresse, il devient disponible pour tous les profils financiers de ce client.

Par exemple, le client peut effectuer des transactions dans de nombreux pays, mais le statut de citoyenneté et l’identification personnelle demeurent inchangés. Cependant, en fonction du pays/de la région dans lequel/laquelle l’utilisateur effectue des transactions, différentes règles et réglementations peuvent être établies pour les taxes propres à chaque pays/région. Les États-Unis disposent de règles et réglementations différentes de celles des autres pays/régions et ce client doit effectuer des transactions dans plusieurs pays.

Les principales difficultés de ce scénario comprennent la capacité à :

  • séparer un profil générique des informations de profil spécifiques ;

  • stocker et récupérer autant d’adresses que possible de chaque type ;

  • faire en sorte que les modifications des propriétés communes deviennent disponibles pour chaque client sans duplication des données.

    Schéma illustrant plusieurs profils financiers.

Scénario 3

Ce scénario traite d’un client devenant une organisation, si l’organisation a plusieurs sites, si des clients spécifiques de l’organisation se trouvent sur différents sites et la possibilité de gérer chaque option. Prenons l’exemple d’un scénario hospitalier avec un médecin et des patients. Un médecin traite un ou plusieurs patients simultanément. Chaque patient est également référencé en fonction du médecin auquel il est affecté. Le médecin peut se connecter au site web d’un hôpital, suivre les dossiers des patients et leur donner des instructions pour les prescriptions et les traitements répondant à leurs besoins individuels. Le médecin peut pratiquer sur plusieurs sites et chaque hôpital comporte plusieurs départements qui fonctionnent sur chacun de ces sites. Le médecin peut aussi tomber malade et devenir un patient.

Cette situation présente plusieurs difficultés clés, notamment la capacité à :

  • associer le contact à un ou plusieurs clients sans données dupliquées, puis suivre les dossiers des clients en fonction du contact ;

  • convertir le contact en client ;

  • permettre au contact de se connecter à plusieurs Power Pages et d’accéder à tous les dossiers client sur l’ensemble des sites.

    Schéma montrant quand un client devient une organisation.

Résumé

Tous les scénarios mentionnés dans la solution Modèle de partie et carnet d’adresses global se trouvent dans Power Platform et les données pour Dataverse. Dans l’ensemble, un client peut être représenté comme une personne ou une organisation. Le contact peut disposer de plusieurs adresses et profils financiers et d’un profil générique. Le client peut être associé à un ou plusieurs contacts et à plusieurs informations telles qu’un groupe de clients, des conditions de paiement, un mode de paiement, un échéancier de paiement, etc. Ce facteur n’affecte pas uniquement les clients : les fournisseurs disposent également de ces capacités. Chaque société est une société et des difficultés clés ont été établies pour classer les clients, embellir les clients et leur donner plus de détails tels que les conditions de paiement et les modes de paiement.

Un chemin de mise à niveau est disponible depuis la solution Modèle de partie préalable d’origine vers la solution Modèle de partie et carnet d’adresses global. Des modèles distincts sont disponibles pour la migration des données de partie et des données contractuelles, et des modèles distincts sont également disponibles pour les adresses postales et électroniques. Tous les modèles et le chemin de mise à niveau sont basés sur les modèles Microsoft Azure Data Factory et vous pouvez les utiliser pour le scénario de mise à jour.

Pour en savoir plus, consultez Partie et carnet d’adresses global.