Action Bouygues Anstel

Actions.txt

Existant Anstel :
===============

1 patrimoine = 1 agence (fictive)
1 provider associé à 1 agence
Tickets associés au patrimoine

PB: 1 provider peut être (dans le cas métier) associé à plusieurs agences(= patrimoines)
CSQ : Sur saisie de tickets, provider non accessible pour action (assignation, ect...)

Cible pour Bouygues : 
===================

1 seule agence (siège) pour la company Bouygues
Le role PatrimonyManager (gestionnaire de patrimoine) associé à 1..N Patrimony de Bouygues
Les Tickets associés à un Patrimoine
=> permet de flirter les tickets pour un user donné

Divergence entre Existant et le modèle cible => 2 scénario de résolution possible :

1] On développe le modèle cible pour la MEP
  - dev du role PatrimonyManager sur Perfimmo
  - pour Anstel utiliser `AssociateProviderContactToCompany`à la place de `AssociateProviderContactToAgency`
        => En fait il faudrait associer les provider aux Patrimoine plutot qu'à la companie
  
Commentaire :   
- Thierry : changer association vers la company plutot quer l'agence pour les ProviderContact c'est facile et rapide (1j)

Impacts : 
  - travail rapide Anstel
  - + de W côté perfimmo

2] Twick Anstel
  - Chez Anstel, 1 patrimoine = 1 agence
  - Mais, ANstel code un script qui permet d'associer sur Perfimmo chaque Provider à plusieurs Agences
  
Impacts :
 - Desynchronisé entre perfimmo et Anstel au niveau association des provider (vérité est chez Perfimmo)
 - Tout le W est chez Anstel et est sensiblement plus long que le W a faire pour la sotion 1]
 - Rien a faire côté Perfimmo

Perfimmo choisit + facilement ses priorisations
Le choix le plus judicieux est celui où Anstel a le moins de W à faire pour conclure. => 1]

La conclusion :

• anstel met une seule agence siège
• perfimmo dev la recherche de tickets par patrimoine