1. - Le « workflow » des demandes#

../../_images/workflow_demandes.svg

1.1. - Campagne de recensement#

Une campagne de recensement représente en quelque sorte le point d’entrée pour une demande. Il existe trois types principaux de campagne :

  • Les campagnes annuelles,

  • Les campagnes exceptionnelles,

  • Les campagnes « virtuelles ».

Chaque campagne comporte les champs suivants :

code:

C’est un code qui pourra être utilisé par une future interface. Typiquement, il comporte l’année et le type de campagne. (obligatoire).

nom:

C’est le nom de la campagne qui sera affichée dans les menus et dans les formulaires. (obligatoire).

debut_recensement:

Date de lancement de la campagne. Il ne sera pas possible de saisir des demandes dans cette campagne avant cette date. (obligatoire)

fin_recensement:

Date de fin de la campagne. Il ne sera plus possible, sauf cas particulier, de saisir des demandes dans cette campagne après cette date. (obligatoire).

discipline:

Discipline de la campagne. Si cette valeur est définie, toutes les demandes saisies dans le cadre de la campagne auront leur champ discipline remplis avec cette valeur.

dispatcher:

Lien vers l’utilisateur qui sera chargé de répartir les demandes vers les différents experts et les différents programmes. Si celle valeur n’est pas définie (NULL), alors la campagne est dite virtuelle (cf. ci-dessous).

message:

Message qui sera affiché systématiquement (dans une boîte de dialogue puis en haut du formulaire) à chaque fois qu’un utilisateur commencera à remplir une demande. Pour les campagnes virtuelles, c’est le message qui est mis dans le commentaire de non validation de chaque demande pour expliquer la raison du rejet de la demande. (facultatif).

description:

Commentaire éventuel (n’est pour l’instant pas affiché pour les demandeurs). (facultatif).

1.1.1. - Les campagnes annuelles#

Une campagne annuelle est une campagne « normale ». Elle a un code, un titre, une discipline, un dispatcheur, une date de début et une date de fin.

Au moins un programme (cf. ci-dessous) doit y être rattaché. Ce sera au dispatcheur de choisir le programme à utiliser.

1.1.2. - Les campagnes exceptionnelles#

Une campagne exceptionnelle est quasiment identique à une campagne normale. La seule différence est qu’un message d’alerte peut être défini et sera présenté systématiquement à l’utilisateur avant la saisie de sa demande. Ce message peut par exemple comporter les règles particulières de traitement de la demande.

1.1.3. - Les campagnes « virtuelles »#

Une campagne virtuelle est une campagne utilisée uniquement pour réorienter une demande vers un circuit extérieur au logiciel. Il n’est pas possible de créer directement des demandes avec cette campagne et il ne faut pas y attacher de programme.

On créée une campagne virtuelle en n’y attachant pas de dispatcher.

Une commande Django, lancée périodiquement, se charge de refuser systématiquement toutes les demandes enregistrées dans ces campagnes et d’en expliquer la raison au demandeur.

À faire

Implémentation à finaliser dans la version 0.9 de BiomAid.

1.2. - Programmes#

Un programme représente une « enveloppe » à distribuer. Cela peut être, par exemple :

  • L’enveloppe d’investissement définie pour un plan annuel d’équipement,

  • L’enveloppe attribuée à un projet particulier au moment de sa validation,

  • Une subvention,

  • etc.

Un programme de BiomAid correspond sensiblement à un programme de la GEF magh2.

Chaque programme possède les champs suivants :

code:

Code utilisé en interne pour le programme. Idéalement, il faut utiliser le même système que pour la GEF, afin de faciliter les échanges (mais ce n’est pas toujours possible). (obligatoire).

nom:

Nom du programme, tel qu’affiché sur les écrans des utilisateurs. (obligatoire).

calendrier:

Lien vers le calendrier de recensement associé au programme. (facultatif).

enveloppe:

Montant de l’enveloppe dévolue à ce programme (en euros TTC). (obligatoire).

description:

Description textuelle du programme. Uniquement affiché, pour info, sur les pages de gestion. (facultatif).

discipline:

… doc à écrire … (obligatoire mais inutilisé ?).

arbitre:

Lien vers l’utilisateur qui sera chargée de valider (ou pas) les demandes associées à ce programme. C’est en quelque sorte la personne qui assurera le respect de l’enveloppe (au stade de la planification, donc avant l’exécution). (facultatif).

Note

Le programme est également utilisé par d’autres modules de BiomAid (et notamment DRACHAR). Il fait donc partie de l’application common et non de l’application dem.

1.3. - Nouvelle demande#

1.4. - Avis des cadres supérieurs#

1.5. - Approbation par le chef de pôle ou le directeur adjoint#

1.6. - Répartition par le « dispatcher »#

1.6.1. - La réorientation d’une demande#

Note

Description du process, mais non encore disponible.

Lorsqu’un dispatcher juge qu’une demande est inadaptée à la campagne dans laquelle elle a été faite, il peut choisir de la « rerouter » ou « rediriger ».

Dans ce cas, un message est adressé au demandeur pour l’informer de cette disposition.

Si la campagne de destination est une campagne réelle (annuelle ou exceptionnelle), c’est à dire avec un dispatcher de défini, elle est simplement transférée (son lien vers la campagne est changé).

Note

Dans ce cas, il faut voir si les champs remplis par le demandeur sont toujours adaptés… Notamment si on passe de travaux à équipement ou l’inverse…

Si la campagne de destination est une campagne virtuelle, la demande est dans ce cas directement arbitrée comme « invalide ».

Note

Comme les arbitrages sont définis par programme, cela pose un problème car il n’y a dans ce cas pas de programme… Ou alors on crée un programme unique par campagne ? Mais cela ne semble pas très cohérent…

1.7. - Analyse / vérification par l’expert métier#

1.8. - Arbitrage#

1.9. - Arbitrage définitif#

2. - Annexes#

2.1. - Calcul de l’état d’une demande en fonction des valeurs#

digraph { gel [shape=diamond, label="Définitif\n?"]; arb_val [shape=diamond, label="Valeur\narbitrage ?"]; prev_not_null [shape=diamond, label="Prévisionnel\nlié ?"]; prev_fini_3 [shape=diamond, label="Prévisionnel lié\nterminé +3 mois?"]; REFUSE [shape=rect, label="REFUSE\nArchivé refusé"]; ANNULE [shape=rect, label="ANNULE\nArchivé annulé"]; TRAITE [shape=rect, label="TRAITE\nArchivé validé"]; VALIDE [shape=rect, label="VALIDE\nSuivi validé"]; A_BASCULER [shape=rect]; gel -> arb_val [label="Oui"]; arb_val -> REFUSE [label="Pas\nOK"]; arb_val -> ANNULE [label="N/A"]; arb_val -> prev_not_null [label="OK"]; prev_not_null -> prev_fini_3 [label="Oui"]; prev_not_null -> A_BASCULER [label = "Non"]; prev_fini_3 -> VALIDE [label="Non"] prev_fini_3 -> TRAITE [label="Oui"] AAP_AREP [shape=box, label="AAP_AREP\nA répartir\n& à approuver"] AAP_AARB [shape=box, label="AAP_AARB\nA arbitrer\n& à approuver"] AAP_AEXP [shape=box, label="AAP_AEXP\nA expertiser\n& à approuver"] AREP_AEXP [shape=box, label="AREP_AEXP\nA répartir\n& à expertiser"] AAP_AREP_AEXP [shape=box, label="AAP_AREP_AEXP\nA répartir\n& à expertiser\n& à approuver"] AREP [shape=box, label="AREP\nA répartir"] AARB [shape=box, label="AARB\nA arbitrer"] AEXP [shape=box, label="AEXP\nA expertiser"] WAIT [shape=box, label="WAIT\nEn attente"] AAP [shape=box, label="AAP\nA approuver"] approbation_1 [shape=diamond, label="Approbation\nChef pôle ?"] approbation_2 [shape=diamond, label="Approbation\nChef pôle ?"] approbation_3 [shape=diamond, label="Approbation\nChef pôle ?"] expert_1 [shape=diamond, label="Expert\nnommé ?"]; expert_2 [shape=diamond, label="Expert\nnommé ?"]; expert_3 [shape=diamond, label="Expert\nnommé ?"]; montant_arb_and_avis_defined [shape=diamond, label="Montant arbitrage\n** ET **\nProgramme sélectionné\n** ET **\nAvis expert donné ?"] gel -> montant_arb_and_avis_defined [label="Non"]; montant_arb_and_avis_defined -> expert_1 [label="Non"]; montant_arb_and_avis_defined -> approbation_1 [label = "Oui"] expert_1 -> approbation_2 [label="Non"]; expert_1 -> approbation_3 [label="Oui"]; arbitre_1 [shape=diamond, label="Programme\navec arbitre\n?"]; arbitre_2 [shape=diamond, label="Programme\navec arbitre\n?"]; approbation_1 -> expert_2 [label="Défini"]; expert_2 -> arbitre_1 [label="Oui"]; arbitre_1 -> AARB [label="Oui"]; arbitre_1 -> WAIT [label="Non"]; expert_2 -> AREP [label="Non"]; approbation_1 -> expert_3 [label="N/A"]; expert_3 -> arbitre_2 [label="Oui"]; arbitre_2 -> AAP_AARB [label="Oui"]; arbitre_2 -> AAP [label="Non"]; expert_3 -> AAP_AREP [label="Non"]; approbation_2 -> AREP [label="Défini"]; approbation_2 -> AAP_AREP [label="N/A"]; prgm_set_1 [shape=diamond, label="Programme\ndéfini ?"]; prgm_set_2 [shape=diamond, label="Programme\ndéfini ?"]; approbation_3 -> prgm_set_1 [label="Défini"]; approbation_3 -> prgm_set_2 [label="N/A"]; prgm_set_1 -> AEXP [label="Défini"]; prgm_set_1 -> AREP_AEXP [label="N/A"]; prgm_set_2 -> AAP_AEXP [label="Défini"]; prgm_set_2 -> AAP_AREP_AEXP [label="N/A"]; }

2.2. - Description et répartition des états#

Code ou sous-code

Nom

Description

Affichage demandeurs

Affichage experts

AAP

A approuver

Demande sans approbation du chef de pôle

A approuver (si cité)

En cours

AREP

A répartir

Demande à répartir : Programme et expert à sélectionner

A l’étude

En cours

AEXP

A expertiser

Demande à expertiser : L’expert doit vérifier (ou donner) un prix et donner un avis

A l’étude

En cours

AARB

A arbitrer

L’arbitre a tous les éléments pour arbitrer et rendre définitif

A l’étude

En cours

A_BASCULER

A basculer

Demande validée à basculer dans le plan d’équipements

A l’étude

En cours

WAIT

En attente

Demande complètement instruite mais le programme n’est pas encore actif (pas d’arbitre)

A l’étude

En cours

ANNULE

Annulée

Demande annulée

Archivée

Archivée

REFUSE

Refusée

Demande refusée

Archivée

Archivée

VALIDE

Validée

Demande validée et en cours de traitement (dans le plan d’acquisition) ou terminée depuis moins de 3 mois

Acceptée

Archivée

TRAITE

Traitée

Demande validée et traitée (terminée depuis plus de 3 mois)

Archivée

Archivée