Détermination du statut d'une transaction comportant plusieurs étapes..

Bonjour,

Ben me concernant, je ferais des fichier.txt avec pour chaque personne
une ligne contenant un n° unique suivit du nom + un état de 1 chiffre et de
sa valeur suivant les besoins, la position déterminant l'action à effectuer,
soit:

000123 Dupont

Puis dans le programme un select case sur l'état
case "04 0 20 1"...
------------------

Pour ma part toujours, je prendrais des fichiers txt et binaires, mais pas
de BDD, car on a toujours des problèmes avec, ça plante, faut la mettre à
jour, faut d'autres dll, voire applications pour la lire, tandis qu'un
fichier txt fait en 1982 est toujours exploitable en 2007, 25 ans après,
c'est fiable!

------------------

primo activité 2 chiffre + état 1 + autres, etc...
activité n° 01 P 02 P 03 P

P
0 = termine
1 = attente
2 = en cours
----------------

Ton exemple:

Pour illustrer, supposons une sollicitation; on a donc l'étape
d'invitation qui est ou non effectuée. Celle-ci est suivi soit d'une
réponse du candidat (acceptation/refus), soit d'un silence auquel cas
on enverra une lettre de rappel au bout de quelques jours (en attente).

dans ce cas il faut adjoindre une date:
n° + client + A + date
nom sur 16 caractères collés à gauche:

000123 dupont A1 DATE1 A2 DATE2

000123 dupont 1 070121

(le nom ne sert à rien, c'est juste pour un contrôle visuel)

A1
0 rien
1 envoyé = attente
2 réponse non
3 réponse oui
4 relancé = attente
5 ne plus relancer = non
6 relancer + 1 an...

date
070121 ou 20070121 (faut faire court si beaucoup d'activités)

Après ces quelques jours, cette lettre de rappel peut avoir été envoyée
ou non (statut en cours ou à faire). Si elle a été envoyée, alors
après X jours, si aucune réponse n'a été reçue, on considère que
l'invitation est refusée.

Ben dans ce cas, on recherche dans le fichier tous :

reponse1 = mid(ligneFichier, 25, 1)'état actuel activité 1
if reponse = 1 then ' relancé en attente
reponse2 = mid(ligneFichier, 27, 6)'date
compareDate entre repinse2 et dateJour
if compareDate => à X jours then
relance (état 1 asse à état 4 + date relance)
----

La relation entre les étapes n'est pas nécessairement linéaire; ainsi
une activité de source externe (une réponse du candidat) peut être
subséquente à n'importe quelle autre, puisqu'elle peut arriver à tout
moment.

Admettons qu'il réponde à l'invitation n°2, on fait pareil:
sa fiche, sur 1 ligne fichier txt
000123 dupont 4 070115 1 070110

la seconde activité 1 070110, il répond ok, ben on passe l'état à:
000123 dupont 4 070115 3 070121

Dupont n° 000123 a dit oui à la seconde activité le 21/01/07

----------------
multitude de IF impriqués

Non, on peut aiguiller par des if et ou des select case, puis des procédures
etc...
----------------

Exemple théorique et partiel, fichier f
f1 identité
f2 contacts (comme sus-cité)
f3 formule à imprimer complétées par f2

Au chargement du programme f2 est lu, et toutes les dates à relancer sortent
dans une liste:
On modifie, puis on valide les personnes à relancer de la liste restante
f1 change d'état suivant relance
f1 pointe ensuite sur f2 pour prendre l'identité
f2 passe à la procédure à f3, qui va avec l'identité faire un lettre sortie
imp
etc...


Ça semble simple à faire, mais ça peut être long, tout dépend des besoins et
des exigences (liste des dates à relancer simplement validée, voir qui édite
automatiquement avec confirmation), ou quelque chose de plus complexe,
permettant de modifier les date, de reporter, d'enlever, de confirmer avant
édition), etc...

Heu, selon taille, un seul fichier peut tout faire, dans ce cas on fera:
$# et #$ ' = mots réservés, début et fin de fiche

$# n° unique
état + date X autant de fois que besoin
identité pour contacter lato sensu
obs...
#$ n° unique

Le programme peut englober les textes des courriers, ou avoir des fichiers
correspondants...

:o)

--
Site de MES LOGICIELS
http://irolog.free.fr
Site éditeur de MES ROMANS édités
http://irolog.free.fr/romans
mon adresse EMail
http://irolog.free.fr/ecrire/index.htm
------------------------------------------------------------------------------------
"gibé" <gibe@gibe.jb> a écrit dans le message de news:
mn.a5437d71e93ed0c7.33676@gibe.jb...

Bonjour/Bonsoir,

J'ai une base de données contenant des données sur des événements qui
progressent à travers plusieurs états.

Pour chaque état, il y a des activités subséquentes qui peuvent ou non
être elles-mêmes en cours, en attente ou terminées.

Chacune de ces activités subséquentes, à son tour, a une ou des activités
subséquentes qui peuvent être en cours, en attente ou terminées.

Pour illustrer, supposons une sollicitation; on a donc l'étape
d'invitation qui est ou non effectuée. Celle-ci est suivi soit d'une
réponse du candidat (acceptation/refus), soit d'un silence auquel cas on
enverra une lettre de rappel au bout de quelques jours (en attente).

Après ces quelques jours, cette lettre de rappel peut avoir été envoyée ou
non (statut en cours ou à faire). Si elle a été envoyée, alors après X
jours, si aucune réponse n'a été reçue, on considère que l'invitation est
refusée.

La relation entre les étapes n'est pas nécessairement linéaire; ainsi une
activité de source externe (une réponse du candidat) peut être subséquente
à n'importe quelle autre, puisqu'elle peut arriver à tout moment.

Le but est de connaitre le statut de l'événement (à quelle étape il est
rendu) et l'état de cette étape (en attente, en cours ou terminée).

Sur papier, cela se conçoit bien; mais quand vient le temps de traduire ça
en code VB, ca devient un peu plus complexe. Je devine que cela peut se
faire en utilisant une multitude de IF impriqués, mais je présume aussi
que la récursivité pourait grandement simplifier la chose..

Est-ce que quelqu'un aurait un point de vue là dessus, un exemple de code
ou une source de laquelle je pourrais m'inspirer ?

Merci !

gibé wrote:

Bonjour/Bonsoir,

Bonjour,

J'ai une base de données contenant des données sur des événements qui
progressent à travers plusieurs états.

Typique d'une situation que l'on peut modéliser avec un automate
à états finis.

Pour chaque état, il y a des activités subséquentes qui peuvent ou non
être elles-mêmes en cours, en attente ou terminées.

Tout à fait : c'est quasimment la description canonique d'un automate.

Chacune de ces activités subséquentes, à son tour, a une ou des
activités subséquentes qui peuvent être en cours, en attente ou
terminées.

Idem, c'est un automate.

Pour illustrer, supposons une sollicitation; on a donc l'étape
d'invitation qui est ou non effectuée. Celle-ci est suivi soit d'une
réponse du candidat (acceptation/refus), soit d'un silence auquel cas
on enverra une lettre de rappel au bout de quelques jours (en
attente).
Après ces quelques jours, cette lettre de rappel peut avoir été
envoyée ou non (statut en cours ou à faire). Si elle a été envoyée,
alors après X jours, si aucune réponse n'a été reçue, on considère que
l'invitation est refusée.

L'illustration est parfaite.

La relation entre les étapes n'est pas nécessairement linéaire; ainsi
une activité de source externe (une réponse du candidat) peut être
subséquente à n'importe quelle autre, puisqu'elle peut arriver à tout
moment.

Oui et non : Une réponse de candidat ne peut pas survenir avant qu'il
ait reçu une sollicitation.

Le but est de connaitre le statut de l'événement (à quelle étape il
est rendu) et l'état de cette étape (en attente, en cours ou
terminée).

Si on modélise avec un automate, et si celui-ci est bien décrit,
c'est très simple. Il suffit de mémoriser l'état courant de l'automate.
C'est même plus simple que ce que tu décris car dans un bon automate,
l'étape définit en même temps son état.

Sur papier, cela se conçoit bien; mais quand vient le temps de
traduire ça en code VB, ca devient un peu plus complexe. Je devine
que cela peut se faire en utilisant une multitude de IF impriqués,
mais je présume aussi que la récursivité pourait grandement
simplifier la chose..

Non! La récursivité n'apportera rien du tout. Les If imbriqués non plus
d'ailleurs.

Est-ce que quelqu'un aurait un point de vue là dessus, un exemple de
code ou une source de laquelle je pourrais m'inspirer ?

Une source complète, ce sera dur à trouver car c'est très spécifique.
En revanche, tu as un exemple complet d'implémentation d'automate à états
finis
dans un article de la FAQ. Il sert à tout autre chose, mais ce n'est pas
l'important: il explique la démarche et le code est limpide à lire.
Voici la chose :
http://faq.vb.free.fr/index.php?question3


L'étape la plus importante, c'est la défnition des états et des transitions,
comme tu le verras dans l'article.

Prenons une simplification de ton cas :

Soit une sollicitation

Etat 1: Une sollicitation doit etre envoyée
Etat 2: La sollicitation a été envoyée
Etat 3: Attente d'une réponse
Etat 4: Reponse reçue
Etat 5: délai expiré
Etat 6: un rappel doit être envoyé
etc.

L'état initial est l'état 1.
Il n'y a qu'une seule façon de passer a l'état 2 (transition),
c'est d'effectivement envoyer un courrier. Ceci provoque le passage
dans l'état 2 (fictif) car correspondant à l'état 3.
Si une réponse est reçue on passe à l'état 4
Si après un temps t (à définir) on est encore dans l'atat 3, alors passage
dans l'état 5. Délai expiré.
etc..

Il faut donc parfaitement définir tes états, définir pour tes états
et transitions une structure de donnée adaptée, puis le reste est mécanique.

Le plus simple est certainement de créer un type utilisateur pour
représenter
le processus (infos diverse + état courant) puis créer une fonction à
laquelle
on passe le processus (avec son état bien sur) et la transition.

Il faut un peu réfléchir pour voir comment on peut modéliser le temps qui
passe
pour gérer le cas de la transition automatique de 3 vers 5 (qui ne dépend
pas
d'une action mais de l'écoulement du temps).

Il n'y a rien de compliqué, mais c'est un peu difficile à expliquer
simplement
dans un post tel que celui ci.

Bonne prog!

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
FAQ VB: http://faq.vb.free.fr/

Merci, c'est tout à fait ce dont j'avais besoin pour démarrer.

J'ignorais le nom que ça portait - ou du moins que c'est ce à quoi ça
servait (car je connaissais le nom).

J'ai pris l'exemple de la FAQ, que j'ai adapté à mes besoins en
utilisant deux variables : une pour l'état, l'autre pour l'action
requise.

Chaque état possible est analysé ainsi : ou les conditions d'un des
état suivants sont remplies et l'état prend alors la valeur de ce
nouvel état ou bien une action est requise pour l'état en cours (ex:
envoyer un rappel).

Pour modéliser le temps, j'ai défini une action "attendre" (ou: "ne
rien faire"). Comme la BD est balayée à intervalle régulier, il va
arriver un moment où "attendre" ne sera plus l'action appropriée au
dossier en question et l'action de suivi requise sera alors enclenchée.

Je boucle ainsi d'état en état dans le dossier d'événement jusqu'à ce
qu'une action requise (y compris "attendre") soit identifiée.

Je peux donc balayer la BD et obtenir pour chaque dossier son statut
actuel et la prochaine action requise en un clin d'oeil.


J'ai 16 états/18 actions possibles, le tout tient sur 3 pages de code
similaire à celui de la FAQ. L'utilisation des "Enum" rend le tout
très facile à lire... et à coder !

En fait, une fois codé, ça a fonctionné du.. 2e coup. ! ;-)

Merci encore !



Jean-marc a écrit :

gibé wrote:

Bonjour/Bonsoir,

Bonjour,

J'ai une base de données contenant des données sur des événements qui
progressent à travers plusieurs états.

Typique d'une situation que l'on peut modéliser avec un automate
à états finis.

Pour chaque état, il y a des activités subséquentes qui peuvent ou non
être elles-mêmes en cours, en attente ou terminées.

Tout à fait : c'est quasimment la description canonique d'un automate.

Chacune de ces activités subséquentes, à son tour, a une ou des
activités subséquentes qui peuvent être en cours, en attente ou
terminées.

Idem, c'est un automate.

Pour illustrer, supposons une sollicitation; on a donc l'étape
d'invitation qui est ou non effectuée. Celle-ci est suivi soit d'une
réponse du candidat (acceptation/refus), soit d'un silence auquel cas
on enverra une lettre de rappel au bout de quelques jours (en
attente).
Après ces quelques jours, cette lettre de rappel peut avoir été
envoyée ou non (statut en cours ou à faire). Si elle a été envoyée,
alors après X jours, si aucune réponse n'a été reçue, on considère que
l'invitation est refusée.

L'illustration est parfaite.

La relation entre les étapes n'est pas nécessairement linéaire; ainsi
une activité de source externe (une réponse du candidat) peut être
subséquente à n'importe quelle autre, puisqu'elle peut arriver à tout
moment.

Oui et non : Une réponse de candidat ne peut pas survenir avant qu'il
ait reçu une sollicitation.

Le but est de connaitre le statut de l'événement (à quelle étape il
est rendu) et l'état de cette étape (en attente, en cours ou
terminée).

Si on modélise avec un automate, et si celui-ci est bien décrit,
c'est très simple. Il suffit de mémoriser l'état courant de l'automate.
C'est même plus simple que ce que tu décris car dans un bon automate,
l'étape définit en même temps son état.

Sur papier, cela se conçoit bien; mais quand vient le temps de
traduire ça en code VB, ca devient un peu plus complexe. Je devine
que cela peut se faire en utilisant une multitude de IF impriqués,
mais je présume aussi que la récursivité pourait grandement
simplifier la chose..

Non! La récursivité n'apportera rien du tout. Les If imbriqués non plus
d'ailleurs.

Est-ce que quelqu'un aurait un point de vue là dessus, un exemple de
code ou une source de laquelle je pourrais m'inspirer ?

Une source complète, ce sera dur à trouver car c'est très spécifique.
En revanche, tu as un exemple complet d'implémentation d'automate à états
finis
dans un article de la FAQ. Il sert à tout autre chose, mais ce n'est pas
l'important: il explique la démarche et le code est limpide à lire.
Voici la chose :
http://faq.vb.free.fr/index.php?question3

L'étape la plus importante, c'est la défnition des états et des transitions,
comme tu le verras dans l'article.

Prenons une simplification de ton cas :

Soit une sollicitation

Etat 1: Une sollicitation doit etre envoyée
Etat 2: La sollicitation a été envoyée
Etat 3: Attente d'une réponse
Etat 4: Reponse reçue
Etat 5: délai expiré
Etat 6: un rappel doit être envoyé
etc.

L'état initial est l'état 1.
Il n'y a qu'une seule façon de passer a l'état 2 (transition),
c'est d'effectivement envoyer un courrier. Ceci provoque le passage
dans l'état 2 (fictif) car correspondant à l'état 3.
Si une réponse est reçue on passe à l'état 4
Si après un temps t (à définir) on est encore dans l'atat 3, alors passage
dans l'état 5. Délai expiré.
etc..

Il faut donc parfaitement définir tes états, définir pour tes états
et transitions une structure de donnée adaptée, puis le reste est mécanique.

Le plus simple est certainement de créer un type utilisateur pour représenter
le processus (infos diverse + état courant) puis créer une fonction à
laquelle
on passe le processus (avec son état bien sur) et la transition.

Il faut un peu réfléchir pour voir comment on peut modéliser le temps qui
passe
pour gérer le cas de la transition automatique de 3 vers 5 (qui ne dépend pas
d'une action mais de l'écoulement du temps).

Il n'y a rien de compliqué, mais c'est un peu difficile à expliquer
simplement
dans un post tel que celui ci.

Bonne prog!