Version 10.16

A partir de cette version, les évènements automatiques sont intégrés aux processus et chaque fonction d’un évènement devient un traitement dans le processus.

Le fonctionnement #

Plusieurs changements ont été apportés au paramétrage de YellowBox CRM pour permettre l’intégration des évènements automatiques dans les processus, tout en conservant toutes leurs fonctionnalités initiales.

• Trois types de traitement ont été créés dans les processus pour permettre :

  • la création d’une fiche

  • l’envoi d’un mail

  • l’envoi d’un message

  Ces nouveaux traitements peuvent être utilisés en restriction ‘Fiche’ ou ‘Aucune’ et dans des processus de type ‘Fiche’ ou ‘Général’

• Intégration d’une nouvelle icône , à droite de ces trois nouveaux types afin d’accéder à leur paramétrage

• Possibilité d’associer une recherche à un traitement d’un des trois types créés lorsque le traitement est en Restriction=Aucune ou que le processus est de type ‘Général’.

• Deux opérateurs ont été créés dans les conditions afin de remplacer le critère ‘Modification d’un champ’ et les deux possibilités qui lui sont associées

  • est modifié

  • prend la valeur

  Cette évolution a permis de supprimer la notion ‘Evaluation avant sauvegarde’ dans les déclencheurs à validation de fiche.

  Ces opérateurs ne sont pas fonctionnels dans les conditions associées aux traitements eux-mêmes. Pour qu’ils soient bien pris en compte, la condition doit être associée aux déclencheurs de type ‘Validation de fiche’ ou ‘Validation de création de fiche’.

• ‘Utilisateur connecté’ est ajouté à la liste des champs de la table concernée, dans les conditions, pour remplacer les utilisateurs et groupes déclencheurs des évènements automatiques

  Il permet de limiter l’exécution du processus à certains utilisateurs et/ou groupes, comme le faisait la liste des utilisateurs déclencheurs.

La création d’une fiche #

Pour paramétrer la création automatique d’une fiche, dans un processus, ajouter un traitement, sélectionner le type ‘Création de fiche’ puis cliquer sur l’icône , à droite du type.

L’écran de paramétrage suivant s’ouvre

Sélectionner une table met à jour la liste de sélection des champs à affecter lors de la création de la fiche. Sélectionner un champ l’ajoute automatiquement dans l’écran, ils apparaissent alors l’un en dessous de l’autre en fur et à mesure de leur sélection.

Ces champs peuvent alors être affectées de façon différente :

• valeur fixe

  • par sélection d’une valeur pour les champs avec choix dans une énumération ou de type gestionnaire

  • par saisie d’une valeur pour les champs paramétrés en saisie libre

• valeur relative

  • reprise de la valeur d’un autre champ

    L’icône permet de sélectionner un champ de même type de la table sélectionnée dans le processus. Dans le cas d’un processus général, la table sera celle concernée par la recherche associée au traitement.

    Attention : toutes les tables sont aujourd’hui sélectionnables, mais seule cette table doit être sélectionnée car la récupération des valeurs des autres tables, même liées celle d’origine ne fonctionnera pas.

  • variable

    Pour un champ de type date, les valeurs acceptées sont :

    • date du jour

    • J+Nombre (0 pour date du jour d’exécution du processus, 1 pour jour suivant,… etc)

Voici un exemple de paramétrage pour la création d’une action lors de la validation d’une fiche offre :

Envoi de message ou de mail #

Pour paramétrer l’envoi d’un mail ou l’envoi d’un message, intégrer, dans un processus, un traitement du type correspondant à celui souhaité puis cliquer sur l’icône , à droite du type.

L’écran de paramétrage s’affiche alors, semblable à celui de la version précédente.

Spécificité sur Restriction=Aucune #

Lors de la validation de l’écran de paramétrage d’un des trois nouveaux types, si le traitement est sans restriction la liste de sélection d’une recherche et la zone de saisie d’une requête SQL s’affiche.

Il convient alors de sélectionner une des recherches existantes ou de saisir une requête.

Le traitement sera appliqué à chaque fiche concernée par la recherche lors de l’exécution du processus.

Nouveautés dans les conditions #

• Deux opérateurs ont été créés afin qu’il y ait une continuité de fonctionnement des évènements automatiques qui se déclenchaient lors de la modification d’un champ et/ou si ce champ prenait une valeur spécifique, mais ils peuvent également être utilisés à d’autres fins, toujours dans le cadre de l’utilisation des conditions.

  Ces opérateurs peuvent tout à fait être combinés aux autres.

  • Est modifié Permet de conditionner l’exécution du processus à la modification d’un champ, quelle que soit sa nouvelle valeur, la zone ‘Valeur’ disparait donc de la ligne lors de la sélection de cet opérateur

  • Prend la valeur

    Permet de conditionner l’exécution du processus à l’affectation d’une valeur spécifique dans un champ

  Si ‘Valeur’ est laissée vide, le processus ne s’exécutera que si le champ sélectionné est vidé.

  Note : si la valeur testé par ‘Prend la valeur’ est déjà présente à l’ouverture de la fiche, la condition renvoie 0. Si elle doit renvoyer 1 à l’ouverture comme lors la modification par saisie, alors l’opérateur choisi doit être ’est égal à’ et non ‘Prend la valeur’.

• Ajout de la notion d’utilisateur connecté dans les conditions

  Pour permettre de limiter l’exécution d’une condition à certains groupes ou utilisateur, en fonction de l’Utilisateur connecté, ‘Utilisateur connecté’ apparait dans la liste des champs de la table concernée.

  L’opérateur ‘Est égal à’ est le seul disponible et la liste des groupes et utilisateurs s’affiche dans la colonne ‘Valeur’.

  Des groupes et utilisateurs peuvent être sélectionnés et cumulés.

Suppression de la notion ‘Evaluation de la condition avant sauvegarde’ #

La case à cocher ‘Evaluation de la condition avant sauvegarde’ n’apparait plus dans l’écran de paramétrage des déclencheurs de type ‘Validation de fiche’.

Les conditions associées à un processus exécuté à validation de fiche étant évaluées dans les cas suivants, la case à cocher ‘Evaluation de la condition avant sauvegarde’ n’a, de facto, plus lieu d’être :

• si la condition contient une comparaison de valeurs entre celle présente en base et celle visible à l’écran, par le biais d’une requête SQL de type

   SELECT ID_ELEMENT 
   FROM C211AFFAIRES 
   WHERE C223ETATDELAFFAIRE<>'##223$$' 
   AND ID_ELEMENT='##reffiche$$';
  

• si un des critères de la condition utilise l’opérateur ‘Est modifié’ ou ‘Prend la valeur’

Pour rappel, dans le cadre des processus, ces opérateurs ne sont fonctionnels que si la condition est associée aux déclencheurs de type ‘Validation de fiche’ ou ‘Validation de création de fiche’, et non aux traitements eux-mêmes.

Exemples de cas d’utilisation des conditions avec combinaison d’opérateurs :

Pour

• Cas 1 : opérateurs ‘prend la valeur’ et ’est différent de vide’

  Création d’un processus pour l’envoi d’un message à validation de fiche Sociétés, si le champ ‘Type’ prend la valeur ‘Partenaire’ et si le champ Email est égal à vide. La condition à créer est celle-ci :

  Le fonctionnement sera alors celui-ci :

  • Validation d’une société avec modification champ ‘Type’ et sélection de ‘Partenaire’

    • Champ email vide à l’ouverture

      • saisi avant validation => message envoyé

      • vide à validation => message non envoyé

    • Champ email non vide à l’ouverture

      • toujours renseigné à validation => message envoyé

      • vidé avant validation => message non envoyé

  • Validation d’une société de type Partenaire à l’ouverture de fiche => message non envoyé

  • Validation d’une société avec une valeur autre que Partenaire => message non envoyé

• Cas 2 : opérateurs ’est modifié’ et ’est différent de vide’

  Création d’un processus pour l’envoi d’un message à validation de fiche Sociétés, si le champ ‘Type’ est modifié et si le champ Email est égal à vide. La condition à créer est celle-ci :

  

  Le fonctionnement sera alors celui-ci :

  • Validation d’une société avec modification du type

    • Champ email vide à l’ouverture

      • saisi avant validation => message envoyé

      • vide à validation => message non envoyé

    • Champ email non vide à l’ouverture

      • toujours renseigné à validation => message envoyé

      • vidé avant validation=> message non envoyé

  • Validation d’une société sans modification du champ ‘Type’ => message non envoyé

Exemple de cas de paramétrage pour l’utilisation des nouveaux types de traitements

Il est possible de créer une fiche, envoyer un mail ou un message sur une sélection de fiches d’une autre table.

Si vous souhaitez par exemple créer une fiche Action sur chaque Offre créée dans la journée, voici le paramétrage à effectuer

• créer un processus Général
• créer et paramétrer un traitement de type ‘Création de fiche’
• créer une recherche de ce type
• créer un déclencheur de type planification avec une périodicité chaque jour, dans la nuit

Lors de l’exécution du processus, une fiche action sera créée à la date définie et liée à chacune des offres créées le jour de l’exécution, reprenant dans son objet la référence de l’offre liée.

La migration des évènements automatiques #

La migration crée un processus de type fiche pour chaque évènement automatique, avec

• un traitement de type fiche pour chaque tâche exécutée par l’évènement (Création de fiche, Envoi de mail, Envoi de message)

• un ou plusieurs déclencheurs selon la valeur du paramètre ‘Critère’ de l’évènement

  • Validation sur création => Validation de création de fiches

  • Validation de fiche => Validation de fiche

  • Modification d’un champ => Validation de fiche

  • Validation sur suppression => Suppression de fiche

  • Validation sur condition

    => Validation de création de fiches

    => Validation de fiche

• une condition, associée au déclencheur, si

  • ‘Utilisateurs déclencheurs’ est différent de ‘Tous’.

    Dans ce cas, un des critères de la condtion est le champ ‘Utilisateur connecté’, l’opérateur est ’est égal à’ et les utilisateurs et/ou groupes présents dans la liste des utilisateurs déclencheurs de l’évènement s’affichent dans ‘Valeur’

  et/ou

  • ‘Critère’ est égal à ‘Modification d’un champ’ ou à ‘Validation sur condition’

• reprise de l’état actif ou inactif de l’évènement automatique

Comme lors des migrations précédentes, le nom de l’évènement automatique est conservé et est précédé de ‘Migration_evtauto_’.

Pour chaque évènement automatique planifié

• ajout d’un déclencheur de type ‘Planification’ dans le processus créé pour l’évènement automatique

• association de la recherche ou de la requête saisie initialement dans l’évènement automatique planifié,

• reprise des paramètres de définition de la périodicité

• reprise de l’état actif ou inactif de l’évènement automatique planifié

Evènement automatique déjà inclus dans un processus #

Lorsqu’un évènement automatique est utilisé dans un processus avant migration, un nouveau processus est créé pour l’évènement automatique comme décrit ci-dessus.

Le processus déjà existant est conservé et le traitement initialement de type évènement automatique est transformé en traitement de type processus.

Si l’évènement était de type ‘Validation sur condition’, la condition est associée au traitement de type Processus.

A titre d’exemple voici un processus avec évènement automatique

en v10.15 :

en v10.16 :