-
Malfaçon signalée par l'OI vers l'OC
-
Malfaçon "Imputable" signalée par l'OI vers l'OC
-
Malfaçon "Non Imputable" ou "Critique" signalée par l'OI vers l'OC
-
Diagrammes de séquence de cas d'utilisation de Malfaçons signalée par l'OI vers l'OC
-
-
Malfaçon signalée par l'OC vers l'OI
Cette API permet la déclaration et le traitement d'une malfaçon grâce à des flux normalisés:
Une malfaçon est une non-conformité par rapport aux STAS (Spécification Technique d'Accès aux Services) ou règles de l'art, issue de travaux menés dans le cadre d'une prestation de production ou de SAV sur un accès (PM/PBO/PTO). Les malfaçons que l'on constate le plus souvent sont : un non-respect du cheminement de la jarretière, une non-conformité de la jarretière (couleur, diamètre, longueur…) mais aussi des déchets laissés sur place (sachet plastique, chute de jarretière…) ou des dégradations (serrure cassée…). La Malfaçon se distingue de la notion de dysfonctionnement dont est ici rappelée la définition Interop'Fibre : un dysfonctionnement est une problématique qui rend impossible l'adduction du réseau d'un OC au PM mis à disposition par un OI.
Les signalisations peuvent être:
- De l'OI vers l'OC :
Cas 1 : Malfaçon imputable de l'OI vers l'OC : reprise attendue de la part de l'OC
Il s'agit alors de Malfaçon non critique imputable à un seul OC : c'est alors une notification appelant action corrective de la part de l'OC destinataire. Si l'OC ne corrige pas dans les délais attendus, alors l'OI peut effectuer la correction lui-même.
Cas 2 : "Malfaçon Critique" ou "Malfaçon non imputable" à un seul OC : la reprise est effectuée par l'OI
Dans ces deux sous-cas ci-dessous, l'OI corrige la malfaçon lui-même :
Sous-Cas 2.1 : Malfaçon critique : il peut s'agir d'une signalisation imputable ou non imputable à un seul OC. C'est alors une notification à l'OC (ou aux OC) n'appelant pas action de sa/leur part car la reprise sera effectuée par l'OI compte-tenu de son aspect critique (c'est-à-dire pouvant présenter un danger grave et imminent pour les personnes et entrainer la responsabilité de l'OI à ce titre). L'aspect "Critique" de la malfaçon doit alors être conforme aux travaux Interop.
Sous-Cas 2.2 : Malfaçon non imputable à un seul OC et non critique : c'est alors une notification à l'ensemble des OC concernés n'appelant pas d'action de leur part car la reprise sera effectuée par l'OI
- De l'OC vers l'OI :
L'OC informe l'OI d’une malfaçon/ dégradation constatée sur le terrain responsable. L'OC a l'origine de la remontée initiale ne suit pas le cycle de vie de la malfaçon et ne sera pas informé de la reprise de la malfaçon qu'il a signalée. La signalisation de la malfaçon par un OC vers un OI est une remontée d'information qui n'implique pas d'engagement de l'OC sur son niveau de précision : cette signalisation constitue une information complémentaire pour l'OI dans le cadre de l'exploitation de son réseau.
- Un signalisation est créée par typologie de malfaçon à l'OC imputable, sans regroupement par élément d'infra
- et elle doit obligatoirement, sauf exception (cf ci-dessous), porter à la détection et à la résolution une photo au format JPEG ou PNG prouvant la malfaçon ainsi que sa résolution. Il sera possible de joindre plusieurs photos à une signalisation mais une et une seule devra porter la notion de "photo principale" à la détection, et à la "résolution". Si l'OI ou l'OC attache une photo comme "photo principale", de détection ou résolution, alors qu'il en existe déjà une, le système enlèvera automatiquement la notion de principale à la photo précédente qui portait cette mention.
Exception : Dans les cas ci-dessous, la photo n'est pas obligatoire mais l'OI doit fournir la route optique constatée (obligatoire) et la route optique théorique (facultatif) au sein d'un "attachment", à la détection, et il doit en être de même à la résolution :
- PBO / ROUTE OPTIQUE / Reprise sauvage Route Optique par casse soudure au PBO
- PBO / ROUTE OPTIQUE / Raccordement de site non déployé dans IPE
- PBO / ROUTE OPTIQUE / Non respect Route Optique communiquée
- PM / ROUTE OPTIQUE / Non respect Route Optique communiquée
Le swagger est disponible à l'adresse suivante: https://before-interop.github.io/malfacon/
Les différents types de malfaçons sont :
Une pièce jointe ne peut être ajoutée à une malfaçon que dans les états : CREATING, IN_PROGRESS, PENDING et RESOLVED Ces pièces jointes pourront être de type : csv, jpeg, jpg, png, svg, pdf, ods, odt, xlsx, docx
Le format Jpeg est attendu pour toutes les malfaçons analysables par IA via photo. Les autres formats ne sont autorisés que dans les cas d’exceptions cités au chapitre précédent.
Il est également possible d'ajouter un commentaire lors de chaque transition (changement de statut) au sein du champs statusChangeDetails (obligatoire dans le cas de certaines transitions).
Liste des différents compteurs utilisés dans le process malfaçons lors d'une signalisation OI vers OC
Le protocole Interop n'harmonise pas les délais car ils relèvent du domaine contractuel propre à chaque opérateur. Néanmoins, les opérateurs doivent mettre en place des compteurs pour les cas décrits ci-dessous. Les valeurs sont propres à chaque OC/OI et seront formalisées dans les contrats. Ces compteurs permettent de s'assurer du bon avancement du ticket, y compris en gérant de façon automatique des transitions en cas d'absence de réponses OI ou OC.
Compteur totalResolutionOcDuration qui démarre au passage du ticket à Acknowledged qui correspond à la transmission de la signalisation par l'OI. Ce délai correspond au temps maximum alloué à l'OC pour résoudre la malfaçon. Ce délai peut cependant s'allonger suite à l'application de « gels »:
- Quand l'OC demande des compléments d'informations à l'OI pour traiter la malfaçon, le compteur de reprise OC est gelé le temps que l'OI réponde à la sollicitation.
- Lorsque l'OC a effectué la reprise de la malfaçon (passage du ticket à Resolved), le compteur est gelé le temps que l'OI analyse la reprise OC. En cas de rejet de résolution, le compteur redémarrera là où il en était et l'OC pourra réitérer sa reprise dans les jours restants.
L'allongement de ce délai pourra être réalisé par l'OI aux états In Progress et Pending via le champs maxResolutionOcDuration (value/reason).
Cas particulier pour les "gestions de situations exceptionnelles": suite à une demande OC, l'OI peut accepter d'allonger ponctuellement ce délai de résolution OC sur une période. Dans ce cas la nouvelle valeur sera mise en en remplacement de l'ancienne avec une information expliquant qu'elle a été mise à jour au cours de son cycle de vie pour raison de situations exceptionnelles. Le filtrage des signalisations candidates à cette gestion de situations exceptionnelles pourra être effectuée à partir du code_insee (information obligatoire d'une signalisation).
Est calculé lors de la réception par l'OI de la résolution envoyée par l'OC (passage du ticket à Resolved) Ce délai correspond au temps maximum alloué à l'OI pour valider ou non, la résolution par l'OC. Ce délai de validation OI gèle le délai de reprise OC. Une fois ce délai dépassé, la résolution est considérée comme automatiquement validée par l'OI et le ticket doit être clôturé. L'OI devra alors ouvrir un nouveau ticket, patienter le délai de reprise OC et, si de nouveau la reprise OC ne lui convient pas, exprimer le refus de validation dans le délai imparti pour ensuite reprendre la malfaçon.
Est calculé lors d'une question posée par l'OC à l'OI (passage du ticket à Pending lorsque le porteur de résolution=OC) L'OI a alors un délai fixé (maxPendingDate) pour apporter la réponse à l'OC qui est en attente de celle-ci. Si cette date est dépassée, le ticket passe alors automatiquement en Canceled.
Est calculé lors d'une question posée par l'OI à l'OC (passage du ticket à Pending lorsque le porteur de résolution=OI) L'OC a alors un délai fixé pour apporter la réponse à l'OI qui est en attente de celle-ci. Si cette date est dépassée, le ticket passe alors automatiquement à Closed.
Délai max de dépôt entre les tickets auprès d'un même OC sur un même élément d'infra (Gestion des compléments de signalisations)
Il ne s'agit pas ici d'un compteur, mais plutôt d'une règle de gestion. Afin d'optimiser les interventions terrains, l'OI doit veiller à signaler l'ensemble des malfaçons auprès d'un même OC sur un « même élément d'infra* » dans la même journée, et donc au plus tard à 23h59».
Tout ticket au-delà pourra être rejeté par l'OC dès lors qu'il existe déjà un ticket en cours sur cet élément d'infra.
Remarque : Elément d'infra correspondant aux catégories du fichier référentiel malfaçon = PM / PB et CCF
Une signalisation est créée par l'OI et porte l'information ResolutionOwner = ‘OC'. A ce stade la signalisation est en cours de création.
L'OI doit renseigner les champs :
- resolutionOwner = OC
- attributable : yes
- type
- localisationDetails
- faultDetails
- quantity
- severity (ne peut pas être Critical puisque attributable=Yes)
- la/les références équipement de la Malfaçon (ref PM et/ou ref PB et/ou ref PTO)
- ocNumber = 1
- insee_code
Règle de gestion:
- une signalisation portant sur la "présence de cordons à zéro non retirés" ne peut avoir une quantité < 5 que si il existe une autre signalisation sur le même élément d'infra déposé dans le "délai max de dépôt entre les tickets auprès d'un même OC sur un même élément d'infra". Sinon l'OC sera en droit de la contester
- Toute signalisation à l'état creating depuis 24h doit être supprimée.
- Aucune notification ne doit être faite sur l'état creating.
Le champs statusChangeReason = Creating
La signalisation est alors complète et contient l'ensemble des informations pour l'analyse OC:
- une photo au format JPEG ou PNG est présente oligatoirement illustrant la malfaçon. Il est possible d'en joindre plusieurs mais dans tous les cas une, et une seule photo, doit porter une information spécifique indiquant que c'est la photo principale de détection de la signalisation (cf swagger: proofType (ISSUE/RESOLUTION) et primary (booleen)
- sauf dans les cas ci-dessous où l'OI devra fournir la route optique constatée (obligatoire) et la route optique théorique (facultatif) :
- PBO / ROUTE OPTIQUE / Reprise sauvage Route Optique par casse soudure au PBO
- PBO / ROUTE OPTIQUE / Raccordement de site non déployé dans IPE
- PBO / ROUTE OPTIQUE / Non respect Route Optique communiquée
- PM / ROUTE OPTIQUE / Non respect Route Optique communiquée
Le compteur de délai max de reprise démarre dès ce statut. Le champs statusChangeReason = Acknowledged
Ce changement ne peut être effectué que par l'OC et uniquement si le ticket est invalide syntaxiquement.
Le statusChangeReason est INVALID_FORMAT.
Ce changement est:
- soit effectué par l'OC. Le champ statusChangeReason doit être renseigné avec Attributable_Accepted
- soit par l'OI lorsque le délai de résolution OC est atteinte. Dans ce cas, le resolutionOwner est mis à OI et le champs statusChangeReason à OC_RESOLUTION_DELAY_EXPIRED.
L'OC peut renseigner l'identifiant du ticket au sein de son propre SI dans le champs External Id
Ce changement de status ne peut être effectué que par l'OI et que si le délai de résolution par l'OC est dépassé.
L'OI doit alors :
- modifier le champs resolutionOwner qui doit être renseigné à "OI"
- Le champ statusChangeReason doit être renseigné avec OC_RESOLUTION_DELAY_EXPIRED
Ce changement de statut peut être effectué
- par l'OC sur une malfaçon dont le ResolutionOwner='OC'
- par l'OI sur une malfaçon dont le ResolutionOwner='OI'
Lorsque cela est à l'initiative de l'OC : Cette transition a pour effet de geler le compteur de résolution OC. L'OI a alors un délai maximum pour apporter sa réponse. Le champ statusChangeReason doit être renseigné avec:
- INFORMATION_REQUEST: demande d'information
ou avec un motif de contestation. L'OC ne pourra contester que 2 fois maximum une signalisation auprès de l'OI. Les motifs de contestation sont :
- CONTESTATION_PHOTO_NOT_USABLE: Photo non exploitable/flou/mal cadré
- CONTESTATION_EQUIPMENT_ERROR: confusion sur l'équipement déclaré
- CONTESTATION_DUPLICATE: le ticket est en conflit avec un autre ticket (non respect du délai max de dépôt entre les tickets auprès d'un même OC sur un même élément d'infra ). Le champ statusChangeDetails est obligatoire avec la référence du ticket en conflit.
- CONTESTATION_ORDER_PUT_INTO_SERVICE_FOR_MORE_THAN_A_YEAR : la commande d'accès date d'il y a plus d'un an. Ne s'applique qu'à des signalisations CCF.
- CONTESTATION_OI_RESPONSABILITY: jugé comme sous responsabilité OI (ex: candidat à la REC, tambours....)
- CONTESTATION_OC_ERROR: OC non concerné
- CONTESTATION_NOT_ALLOWED : autre cas. Le détail doit être fourni obligatoirement dans le statusChangeDetails
Lorsque cela est à l'initiative de l'OI : L'OC a alors un délai maximum pour apporter sa réponse. Le champ statusChangeReason doit être renseigné avec:
- INFORMATION_REQUEST: demande d'information
PENDING → IN_PROGRESS: réponse OI/OC à une demande d'information ou réponse OI à une contestation OC
Ce changement de status peut être effectué par l'OI ou par l'OC.
Dans le cas de l'OI, cela fait suite à une demande d'information OC ou une contestation:
- Cette transition a pour effet de dégeler le compteur de résolution OC
- Le champ statusChangeReason doit être renseigné avec :
- INFORMATION_GIVEN : avec fourniture de la réponse dans le statusChangeDetails obligatoire
- CONTESTATION_REFUSED : rejet de la contestation (deux contestations maximum par l'OC)
Dans le cas de l'OC, cela fait suite à une demande d'information OI: Le champ statusChangeReason doit être renseigné avec INFORMATION_GIVEN avec fourniture de la réponse dans le statusChangeDetails obligatoire.
Ce changement de status ne peut être effectué que par l'OI:
- soit automatiquement lorsque le délai de réponse OI a été dépassé : le statusChangeReason est alors à OI_RESPONSE_DELAY_EXPIRED
- soit en cas de validation de la contestation OC : CONTESTATION_ACCEPTED
Sur un ticket dont le champs resolutionOwner='OI', ce changement de status ne peut être effectué que par l'OI. Le champ statusChangeReason doit être renseigné avec RESOLVED_OI_ATTRIBUTABLE.
Sur un ticket dont le champs resolutionOwner='OC', ce changement de status ne peut être effectué que par l'OC. Le champ statusChangeReason doit être renseigné avec RESOLVED_OC. Le compteur de délai de résolution OC se gèle et compteur de validation OI est alors calculé.
En complément:
- le champs resolutionDate doit être renseigné
- ainsi que le champs recoveryQuantity
- et une photo obligatoire au format JPEG ou PNG illustrant la résolution de la malfaçon, sauf pour les 4 cas route optique où un attachment est attendu (cf. status Acknowledged). Pour les photos, il est possible d'en joindre plusieurs mais dans tous les cas une, et une seule photo, doit porter une information spécifique indiquant que c'est la photo principale de résolution de la signalisation
Sur un ticket dont le champs resolutionOwner='OI', ce changement de status ne peut être effectué que par l'OI. Le champ statusChangeReason doit être renseigné avec OI_RESOLUTION_IMPOSSIBLE.
Ce changement de status ne peut être effectué que par l'OI. Le statusChangeReason est CANCELED.
Ce changement de status ne peut être effectué que par l'OI. Le statusChangeReason peut être:
- OI_DELAY_EXPIRED : lorsque l'OI n'a pas répondu dans les temps aux questions / contestations OC
- CANCELED: autre cas donnant lieu à l'annulation par l'OI
Ce changement de status est effectué par l'OI. Le statusChangeReason peut être:
- RESOLVED_OC_VALIDATED
- RESOLVED_OI_VALIDATED
- OI_VALIDATION_DELAY_EXPIRED : passage automatique suite au dépassement du délai de validation OI sur une résolution OC
- OI_RESOLUTION_RENUNCIATION : clôture sans reprise par l'OI
Ce changement de status ne peut être effectué que par l'OI sur un ticket dont le ResolutionOwner='OC'.
Cette transition a pour effet de dégeler le compteur de résolution OC.
Le champ statusChangeReason doit être renseigné avec:
- RESOLUTION_REFUSED_PARTIALLY_RESOLVED : résolution partielle
- RESOLUTION_REFUSED_PHOTO_NOT_USABLE: Photo non exploitable/flou/mal cadré
- RESOLUTION_REFUSED_EQUIPMENT_ERROR: confusion sur l'équipement déclaré
- RESOLUTION_REFUSED_NOT_REPAIRED: non résolu
Ce changement de status ne peut être effectué que par l'OI sur un ticket dont le ResolutionOwner='OI'. L'OI a questionné l'OC pour pouvoir réparer la signalisation. En absence de réponse OC dans les temps, cette signalisation est cloturée avec le statusChangeReason à OI_RESOLUTION_IMPOSSIBLE.
Une signalisation est créée par l'OI et porte l'information ResolutionOwner = ‘OI'. A ce stade la signalisation n'est pas complète puisqu'aucune pièce jointe n'a été ajoutée au ticket.
L'OI a renseigné les champs :
- resolutionOwner = OI
- type
- localisationDetails
- faultDetails
- quantity
- severity (doit être Critical si attributable=Yes car résolution portée par l'OI)
- la/les références équipement de la Malfaçon (ref PM et/ou ref PB et/ou ref PTO)
- attributable : yes or no
- nombre d'OC concerné
- insee_code
Le champs statusChangeReason = Creating
Règle de gestion:
- Toute signalisation à l'état creating depuis 24h doit être supprimée.
- Aucune notification ne doit être faite sur l'état creating.
A ce statut une photo au format JPEG ou PNG est présente oligatoirement illustrant la malfaçon. Il est possible d'en joindre plusieurs mais dans tous les cas une, et une seule photo, doit porter une information spécifique indiquant que c'est la photo principale de détection de la signalisation.
Le champs statusChangeReason = Acknowledged
Ce changement de statut est effectué par l'OI et le champ statusChangeReason doit être renseigné, suivant le cas, avec:
- statusChangeReason = "NON_ATTRIBUTABLE"
- statusChangeReason = "CRITICAL"
L'OC peut renseigner l'identifiant du ticket au sein de son propre SI dans le champs External Id
Ce changement de status est effectué par l'OI. Le champs statusChangeReason = Canceled
Ce changement de status est effectué par l'OI et correspond au dépassement du délai de reprise OI. Le statusChangeReason = "CANCELED"
Ce changement de status ne peut être effectué que par l'OI. Le champ statusChangeReason doit être renseigné avec:
- RESOLVED_OI_NON_ATTRIBUTABLE
- RESOLVED_OI_CRITICAL
En complément:
- le champs resolutionDate doit être renseigné
- ainsi que le champs recoveryQuantity
- et une photo obligatoire au format JPEG ou PNG illustrant la résolution de la malfaçon
Ce changement de status est effectué par l'OI suite à sa propre résolution sur un ticket dont le ResolutionOwner='OI'.
Le champ statusChangeReason doit alors être renseigné avec la valeur RESOLVED_OI_VALIDATED
Ces diagrammes se concentrent sur la signalisation et la correction des malfaçons. Les cas d'utilisation détaillés par la suite sont les suivants :
Cas 3 : Malfaçon imputable avec reprise par OI suite au dépassement du délai de reprise OC, résolue par l'OI
Cas 4 : Malfaçon imputable avec reprise par OI suite au dépassement du délai de reprise OC MAIS non résolue par l'OI
Cas 8 : Contestation de l'OC de sa responsabilité sur réception de la signalisation acceptée par l'OI
Déclaration d'une malfaçon par l'OI à l'OC imputable et reprise par l'OC dans le délai max. de reprise OC. Lorsqu'il a effectué la reprise, l'OC passe le ticket en résolu avec en PJ n photos. L'OI valide la résolution de l'OC et clôt le ticket.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = ACKNOWLEDGED, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OC->>OC: Regroupement tickets liés pour intervention (bonne pratique)
OC->>OC: Résolution de la malfaçon
OC->>OC: Ajout PJ obligatoire
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Contrôle métier (ex: consulter PJ, etc...)
OI->>OI: Cloture ticket (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
OI->>OC: Notif (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
Déclaration d'une malfaçon par l'OI à l'OC imputable et reprise par l'OC dans le délai max. de reprise OC. Lorsqu'il a effectué la reprise, l'OC passe le ticket en résolu avec en PJ n photos. L'OI valide la résolution de l'OC et clôt le ticket. L'OI ne valide pas la résolution de l'OC dans les temps. Le ticket est donc automatiquement clôturé.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OC->>OC: Regroupement tickets liés pour intervention (bonne pratique)
OC->>OC: Résolution de la malfaçon
OC->>OC: Ajout PJ obligatoire
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Délai max du compteur de validation OI atteint. Cloture du ticket (status=CLOSED, statusChangeReason = OI_VALIDATION_DELAY_EXPIRED
OI->>OC: Notif (status = « CLOSED », statusChangeReason = OI_VALIDATION_DELAY_EXPIRED
Cas 3 : Malfaçon imputable avec reprise par OI suite au dépassement du délai de reprise OC, résolue par l'OI
Déclaration d'une malfaçon par l'OI à l'OC imputable. L'OC ne reprend pas dans le délai max. de reprise OC. L'OI notifie l'OC qu'il reprend la main. Quand l'OI a effectué la reprise, il clôt le ticket avec en PJ n photos. L'OC ne valide pas la recevabilité du ticket ni sa résolution. Si litige ou contestation, cela sera traité hors du cycle de vie du ticket.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OI->>OI: Dépassement du compteur du délai de reprise OC
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason= Resolution_Date_Expired, ResolutionOwner=OI)
OI->>OI: Résolution de la malfaçon
OI->>OI: Ajout PJ obligatoire
OI->>OC: Notif (status = RESOLVED, statusChangeReason = Resolved_OI_attributable)
OI->>OI: Cloture du ticket ("CLOSED")
OI->>OC: Notif (status = CLOSED, statusChangeReason = Resolved_OI_attributable)
Cas 4 : Malfaçon imputable avec reprise par OI suite au dépassement du délai de reprise OC MAIS non résolue par l'OI
Déclaration d'une malfaçon par l'OI à l'OC imputable. L'OC ne reprend pas dans le délai max. de reprise OC. L'OI notifie l'OC qu'il reprend la main. L'OI n'effectue pas la reprise et clôture le ticket en non résolu.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OI->>OI: Dépassement du compteur du délai de reprise OC
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason= Resolution_Date_Expired, ResolutionOwner=OI)
OI->>OI: Annuler ticket (status = CANCELED, statusChangeReason = « Canceled »)
OI->>OC: Notif (état = CANCELED, statusChangeReason = « Canceled »)
Déclaration d'une malfaçon par l'OI à l'OC imputable. L'OC demande des informations complémentaires à l'OI pour pouvoir traiter la malfaçon. Une fois que l'OI a fourni ces informations, l'OC enchaîne sur le cas 1 (cas nominal). Suite à la réception du ticket, l'OC passe d'abord le ticket a « In Progress » puis demande ensuite des informations complémentaires à l'OI gelant par conséquent le délai max de reprise OC en attendant la réponse OI.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OC->>OI: Notif (status = PENDING, statusChangeReason=information_request)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de réponse OI MaxPendingDate
OI->>OI: Ajout d'une PJ
OI->>OC: Notif Attachment
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason=« Information_Given»)
OI->>OI: Dégel du compteur du délai de reprise OC
OC->>OC: Regroupement tickets liés pour intervention (bonne pratique)
OC->>OC: Résolution de la malfaçon
OC->>OC: Ajout PJ obligatoire
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Contrôle métier (ex: consulter PJ, etc...)
OI->>OI: Cloture ticket (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
OI->>OC: Notif (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
Déclaration d'une malfaçon par l'OI à l'OC imputable et reprise par l'OC dans le délai max. de reprise OC. Lorsqu'il a effectué la reprise, l'OC passe le ticket en résolu avec en PJ n photos. L'OI refuse la correction en demandant des informations complémentaires à l'OC. L'OC les fournit en repassant la signalisation à Resolved. L'OI valide la résolution de l'OC et clôt le ticket.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OC->>OC: Regroupement tickets liés pour intervention (bonne pratique)
OC->>OC: Résolution de la malfaçon
OC->>OC: Ajout PJ obligatoire
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Contrôle métier (ex: consulter PJ, etc...)
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason=RESOLUTION_REFUSED_EQUIPMENT_ERROR) + statusChangeDetail indiquant la raison/les attentes
OI->>OI: Fin compteur de validation OI
OI->>OI: Dégel du compteur du délai de reprise OC
OC->>OC: Ajout PJ précisant la correction
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Contrôle métier (ex: consulter PJ, etc...)
OI->>OI: Cloture ticket (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
OI->>OC: Notif (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
Déclaration d'une malfaçon par l'OI à l'OC imputable. Lorsqu'il a effectué la reprise, l'OC passe le ticket en résolu avec en PJ n photos. L'OI rejette la reprise de la malfaçon faite par l'OC car la reprise est partielle (ex : 4 cordons à zéro ont été repris sur 6). Comme il n'a pas dépassé le délai max. de reprise OC, l'OC retourne sur le terrain pour compléter sa reprise initiale. L'OI devra donc valider le retour OC à plusieurs reprises, à priori 2 fois.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OC->>OC: Regroupement tickets liés pour intervention (bonne pratique)
OC->>OC: Résolution de la malfaçon
OC->>OC: Ajout PJ obligatoire
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Contrôle métier (ex: consulter PJ, etc...)
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason=RESOLUTION_REFUSED_PARTIALLY_RESOLVED)
OI->>OI: Fin compteur de validation OI
OI->>OI: Dégel du compteur du délai de reprise OC
OC->>OC: Résolution totale de la malfaçon
OC->>OC: Ajout PJ obligatoire
OC->>OI: Notif (status = RESOLVED, statusChangeReason = Resolved_OC)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Démarrage du compteur de validation OI
OI->>OI: Contrôle de surface
OI->>OI: Contrôle métier (ex: consulter PJ, etc...)
OI->>OI: Cloture ticket (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
OI->>OC: Notif (status = CLOSED, statusChangeReason = RESOLVED_OC_VALIDATED)
Déclaration d'une malfaçon par l'OI à l'OC imputable. L'OC conteste sa responsabilité, en passant tout d'abord la malfaçon à In Progress puis en indiquant son motif de contestation lors d'un passage en Pending pour gel du compteur de reprise OC. L'OI analyse alors la contestation OC et peut décider d'annuler, ou de de refuser, la contestation OC. L'OC ne peut passer le statusChangeReason="Contestation" que deux fois vers l'OI.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OC->>OI: Notif (status = « IN PROGRESS », statusChangeReason= attributable_Accepted)
OC->>OI: Notif (status = PENDING, statusChangeReason=CONTESTATION_OC_ERROR)
OI->>OI: Gel du compteur du délai de reprise OC
OI->>OI: Analyse de la contestation OC
OI->>OI: Annuler ticket (status = CANCELED, statusChangeReason = CONTESTATION_ACCEPTED)
OI->>OC: Notif (état = CANCELED, statusChangeReason = CONTESTATION_ACCEPTED)
Seul l'OI peut annuler un ticket, et celui-ci doit alors être à l'état Acknowledged, Pending ou In Progress.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire)
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=Yes, ResolutionOwner=OC)
OI->>OI: Démarrage du compteur du délai de reprise OC
OC->>OC: Contrôle de surface
OC->>OC: Contrôle métier (ex: consulter PJ, délai entre tickets etc...)
OI->>OI: Annuler ticket (status = CANCELED, statusChangeReason = CANCELED)
OI->>OC: Notif (état = CANCELED, statusChangeReason = CANCELED)
L'OI signale la malfaçon à chaque OC présent sur l'infrastructure concernée pour information et le nombre d'OC présent afin que chacun connaisse sa quote-part. La malfaçon est reprise directement par l'OI qui clôt le ticket avec en PJ n photos. La résolution est portée par l'OI. L'OC ne valide pas la recevabilité du ticket ni sa résolution. Si litige ou contestation, cela sera traité hors du cycle de vie du ticket.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire) + information nombre d'OC
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Acknowledged, attributable=No, ResolutionOwner=OI)
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason= Non_Attributable)
OI->>OI: Regroupement tickets liés pour intervention (bonne pratique)
OI->>OI: Résolution de la malfaçon
OI->>OI: Ajout PJ obligatoire
OI->>OC: Notif (status = RESOLVED, statusChangeReason = Resolved_OI_Non_Attributable)
OI->>OI: Cloture du ticket ("CLOSED")
OI->>OC: Notif (status = CLOSED, statusChangeReason = Resolved_OI_Non_Attributable)
L'OI signale la malfaçon critique à l'OC pour information. La malfaçon est reprise directement par l'OI qui clôt le ticket avec en PJ n photos. La résolution est portée par l'OI. L'OC ne valide pas la recevabilité du ticket ni sa résolution. Si litige ou contestation, cela sera traité hors du cycle de vie du ticket. Pas de regroupement d'intervention OI car sévérité Critique nécessitant d'intervenir au plus tôt.
sequenceDiagram
participant OC
participant OI
OI->>OI: Création malfaçon respectant le délai max de dépôt entre les tickets (CREATING)
OI->>OI: Ajout d'une PJ (obligatoire) + information sévérité critique
OI->>OC: Transmission signalisation (status = ACKNOWLEDGED, statusChangeReason = Critical, attributable=No, severity=Critical, ResolutionOwner=OI)
OI->>OC: Notif (status = « IN PROGRESS », statusChangeReason= Critical)
OI->>OI: Résolution de la malfaçon critique
OI->>OI: Ajout PJ obligatoire
OI->>OC: Notif (status = RESOLVED, statusChangeReason = Resolved_OI_Critical)
OI->>OI: Cloture du ticket ("CLOSED")
OI->>OC: Notif (status = CLOSED, statusChangeReason = Resolved_OI_Critical)
Une signalisation est créée par l'OC qui souhaite porter l'information à l'OI d'une potentielle malfaçon. A ce stade la signalisation n'est pas complète puisqu'aucune pièce jointe n'a été ajoutée au ticket.
L'OC a renseigné les champs:
- type
- localisationDetails
- faultDetails
- quantity
- la/les références équipements de la Malfaçon (ref PM et/ou ref PB et/ou ref PTO)
Le champs statusChangeReason = Creating
Règle de gestion:
- Toute signalisation à l'état creating depuis 24h doit être supprimée.
- Aucune notification ne doit être faite sur l'état creating.
La signalisation porte obligatoirement une photo illustrant la malfaçon. Le champs statusChangeReason = Acknowledged
Ce changement de status ne peut être effectué que par l'OI.
Le champs statusChangeReason doit être renseigné avec CLOSED.
L'OI ne doit aucun retour à l'OC sur le traitement potentiel qui sera réalisé sur cette signalisation.
Signalisation par l'OC constituant un élément supplémentaire à prendre en compte par l'OI pour détecter des malfaçons. Les données fournies dans la signalisation OC ne sont pas les mêmes que dans le cas de la détection par l'OI. Suite à la signalisation par l'OC, l'OI ne partage pas de retour avec l'OC concernant la reprise de cette malfaçon. Il n'y a pas non plus d'engagement de traitement de la part de l'OI. Ce ticket constitue un input supplémentaire à prendre en compte par l'OI pour détecter des malfaçons.
sequenceDiagram
participant OC
participant OI
OC->>OI: Creation Malfaçon (état = CREATING)
OC->>OI: Ajout d'une PJ principale (obligatoire)
OC->>OI: Ajout d'une PJ (secondaire)
OC->>OI: Mise à jour status à Acknowledged
OI->>OI: Contrôle technique
OI->>OI: Cloture ticket (CLOSED)
OI->>OC: Notif (état = « CLOSED »)