2021-11-12

#oodrive

Point "Vérification gestion des workspace dans BDD composant intermédiaire"

@mamalet.franck @breant.fabien

Rappel

Après la réunion du 2021-11-10, nous avions un doute par rapport au modèle que nous exposion

pour rappel notre modèle, qui va dans le sens de nos point fonctionnels et de la recette mené:

zuora_client

p_clientuuid unique z_accountnumber pas unique

Les deux premières lignes sont des cas ventes directe ou cosell, indistinctement. Les lignes 3 et 4 correspondent au cas resell. Ici le revendeur est seulement connu de Zuora (partie facturation) quand au client final et son ou ses subscription sont connus pour la facturation par Zuora et pour la partie technique par Plateforme.

C'est une vision bottom-up: les clients et leurs subscriptions définissent le revendeur. On définit un client et on l'attribut à un revendeur, le stockage de ce client est ajouté au stockage du revendeur;

=> l'ugrade auto est évident et en phase avec la vision sales & ADV exprimée (recette, points)

ce qui permettait de faire découler les élements suivants:

zuora_subscription

p_subscriptionuuid unique p_f_clientuuid pas unique z_subscriptionnumber unique

zuora_product

p_marketingproductid unique p_f_subscriptionuuid pas unique z_chargenumber unique

Conclusion de la réunion du 2021-11-10: il nous manque des éléments pour lier depuis Plateforme les clients finaux du revendeur resell avec ce qui est disponible dans Zuora

Le point de ce Jour

Le modèle exposé au dessus n'interesse pas Plateforme, la notion de Revendeur sera donc gardé dans Plateforme sous le terme Client(revendeur ou grossiste), à ne pas confondre avec le Client(client);

• des modifications profondes du modèles Plateforme ont été réalisé dernièrement
  • le revendeur / grossiste (revendeur resell) n'ont plus d'entités spécifiques et deviennent des clients
  • ces Clients (revendeur / grossiste) vont avoir N workspace correspondant aux N clients finaux Client(client)
  • dans l'état actuel, 1 workspace = 1 Client(client), à voir dans le futur
  • ces N workspace vont avoir 1 seule subscription
  • cette subscription va avoir 1 type de produit

C'est une vision top-down: un Client(revendeur/grossite) avec un type de subscription est défini, il possède un stockage et le redistribue à ces workspace(Client(client)).

A partir d'ici, pour simplifier:
- Client(revendeur/grossite) = Revendeur
- Client(client) = Client final

=> l'upgrade auto n'est pas évident et n'est pas en phase avec la vision sales & ADV exprimée (recette, points):

• contrôle du stockage du Workspace et upgrade de la facturation/technique du Revendeur (stratégie du magasin "épicerie")?
  • le Revendeur upgradé sur la facturation et techniquement pourra agir :
    • sur la facturation:
      • il upgrade la facturation du Client final
      • il choisit une autre politique
    • techniquement (stockage):
      • il upgrade techniquement le Client final
      • il choisit une autre politique
• contrôle du stockage du Workspace et upgrade technique du Client final (stratégie du magasin "épicerie") ?
  • le Client final (workspace) est upgradé techniquement (stockage) et le Revendeur upgradé sur sa facturation
    • le Revendeur upgradé sur la facturation pourra agir :
      • sur la facturation:
        • il upgrade la facturation du Client final
        • il choisit une autre politique
• contrôle du stockage du Revendeur (ensemble de ces stockages) et upgrade de la facturation/technique du Revendeur (stratégie du magasin "tout à 1€") ?
  • similaire premier cas pour la suite mais avec l'obligation d'avoir exactement le même type de produit (stockage et barème de prix) et donc avoir un compte Revendeur par type de produit

Ce qui nous donne la structure en table suivante:

zuora_client

les deux champs contiennent des valeurs uniques le champs clientuuid peux contenir soit un Client final soit un Revendeur Resell (le polymorphisme de la table public.Account de plateforme le permet)

zuora_workspace

les deux champs contiennent des valeurs uniques 1 workspace = 1 client

zuora_subscription

les trois champs contiennent des valeurs uniques 1 workspace = 1 subscription

zuora_product

le champs p_subscriptionuuid et z_chargenumber contiennent des valeurs uniques tout les produits (p_marketingproductid) des subscriptions d'un Revendeur Resell ont les même valeurs. Ex: les deux dernières lignes

Conclusion

Cette structure de base et les développements effectués ne vont pas dans les sens des modifications de Plateforme.

Le besoin fonctionnel doit être valider.

Des développement doivent être engagé pour modifier le composant intermédiaire