Conditions d'utilisation

Aperçu

Certaines tables de référence sont assorties d'une condition ou d'une règle USE-WHEN. Exemples : EMPRNO, PAYGRP, DATERULE, WATCH

Dans la colonne Use-when , vous spécifiez une règle simple (condition) selon laquelle l'entrée de la table s'applique par défaut à tel ou tel employé.

Comment cela fonctionne-t-il ?

Pour tout type de table avec une colonne USE-WHEN

Pour chaque entrée de la table , vous saisissez une condition spécifiant à quels employés (sous-ensemble) cette entrée de table s'applique. Voici un exemple de la manière dont vous pourriez construire votre table PAYGRP

Paygrp	Description	Condition d'utilisation
BLUE	Col bleu, rémunération hebdomadaire	pers.E_UNION='FTQ'
MGMT	Col blanc, salaire bihebdomadaire	pers.E_UNION=' '

Lorsque Umana a besoin de pour savoir quelle entrée doit appliquer à un employé, il parcourt les entrées de la table (dans l'ordre TBLSORT + TBLID). Lorsqu'il trouve une entrée dont la condition est vraie pour cet employé, il utilise cette entrée (et arrête le balayage).

Conditions

Les conditions sont des expressions qui sont vraies pour certains employés et fausses pour d'autres.

Pour certaines tables, les conditions d'utilisation sont saisies à l'aide de la fonction Générateur d'expressions.
Pour d'autres tables, les conditions sont saisies en remplissant le formulaire de sélection / filtre de l'employé ! formulaire de sélection / filtre

Toujours faux, toujours vrai

Une condition vide est toujours fausse. Vous pouvez avoir des entrées dans votre table sans conditions, pour des valeurs que vous voulez assigner manuellement.
Pour une condition toujours vraie, utilisez l'expression 1=1.
Cette expression peut servir de fourre-tout "sinon" - il suffit de s'assurer que la valeur SORT de la table est correcte. assurez-vous simplement que la valeur SORT de la table est plus élevée que les autres entrées.

Le bon, le mauvais et le mathématique

Ce qui est bien à propos de cette approche, c'est qu'elle est facile à _TOOLS____urer.

Ce qui est mauvais dans cette approche, c'est qu'il est facile de faire des erreurs (sans s'en rendre compte).

Comme une déclaration *CASE

Si vous comprenez la programmation, vous reconnaîtrez qu'il s'agit simplement d'une grande séquence de une grande séquence d'instructions IF / ELSE IF / ... (ou DO CASE).

Chaque condition de votre tableau est un autre cas à tester.
Les entrées du tableau dont l'ordre de tri est le plus bas sont testées en premier. Pour les entrées ayant les mêmes valeurs SORT, Umana va dans l'ordre du CODE.

Les pièges

Il y a deux gotchas dont il faut se méfier. <img src="images/coVenn.png" class="pull-right"

L'employé ne remplit aucune des conditions
Dans le diagramme de droite, nous pourrions couvrir les cas A et B. Mais qu'en est-il du cas C ?
Dans l'exemple PAYGRP ci-dessus, qu'en est-il des employés avec E_UNION='CSN' ?

**Solution ??* Créez un cas OTHERWISE catch-all. Vous pouvez le faire en créant une entrée dans votre table à la fin (valeur SORT la plus élevée) et la condition 1=1.

L'employé remplit plus d'une condition
Dans l'exemple PAYGRP, cela ne peut pas se produire, mais vous pouvez certainement créer des conditions pour que cela se produise. mais vous pouvez certainement créer des conditions dans lesquelles cela se produit. C'est là que A et B se croisent (se chevauchent) dans le diagramme ci-dessus.

**Solution ??* Vérifiez soigneusement vos conditions et placez celles qui sont prédominantes en premier (valeur TRIE la plus basse).