Dans le schéma on liste les colonnes dans la propriété Columns.

Catégories de colonne

Fonctionnellement, on va distinguer 3 catégories de colonnes que l’on va par convention ordonner comme suit.

Colonnes calculées

Il s’agit des colonnes qui n’existent pas dans la table du schéma.
Une convention pour les distinguer est de les préfixer du signe “_”.
Par exemple dans customercontact on aura la colonne _fullName qui permet de concaténer le prénom et le nom.

Translation

Il est nécessaire d’utiliser la propriété Translation pour fournir un nom à la colonne.
Si la traduction n’est pas trouvée, on verra le nom de la colonne.

FieldType

Si la donnée calculée correspond à un type boolean, number ou date, il faut le préciser, car par défaut le type est string.

Data.Relation

Le système fournit un mécanisme de relation de différents types.

zerotoone

Permet de créer une relation avec une entité d'extension. On peut avoir 0 ou 1 ligne dans l’entité d’extension.
Il faut renseigner les propriétés suivantes :

Schema : nom du schéma dans lequel on doit chercher la donnée
Note : ne fonctionne pas actuellement avec les sous-entités
ForeignKey : nom de la colonne de l’entité d'extension qui fait la jointure avec la clé primaire de l’entité courante
Column : nom de la colonne d'extension à récupérer
Note : on ne peut pas combiner avec ForeignEntity pour afficher une foreign

Exemple : pour l’entité customer, on veut afficher la colonne dataQualityIndicator de la table customerextension

"_qualityIndicator": {
  "Translation": "BO_DataQualityIndicator_Short",
  "Data": {
    "Relation": {
      "Type": "zerotoone",
      "Schema": "customerextension",
      "ForeignKey": "customer_ID",
      "Column": "dataQualityIndicator"
    }
  }
}

onetomany

Permet de créer une relation pour chercher une information à agréger à partir d’une entité annexe. On a aucune ou plusieurs lignes dans une entité annexe.
Il faut renseigner les propriétés suivantes :

Schema : nom du schéma qui contient 0 ou plusieurs lignes à agréger
ForeignKey : nom de la colonne de l’entité à agréger qui fait la jointure avec la clé primaire de l’entité courante
Aggregate
- Operation : type de l’opération d’agrégation
  - Average : moyenne des valeurs
  - Count : compteur de valeurs
  - Max : valeur maximum
  - Min : valeur minimum
  - Sum : somme des valeurs
- Column : nom de la colonne à agréger

Exemple 1 : pour l’entité customer, on veut afficher la dernière visite

"_lastVisit": {
  "Translation": "Gen_LastVisit",
  "Data": {
    "Relation": {
      "Type": "onetomany",
      "Schema": "visitreport",
      "ForeignKey": "customer_ID",
      "Aggregate": {
        "Operation": "Max",
        "Column": "visitDate"
      }
    },
    "Formatter": {
      "Type": "date",
      "Format": "d"
    }
  }
}

Exemple 2 : pour l’entité customer, on veut afficher le nombre de contacts

"_nbContact": {
      "Translation": "BO_NbContact",
      "FieldType": "number",
      "Data": {
        "Relation": {
          "Type": "onetomany",
          "Schema": "customercontact",
          "ForeignKey": "customer_ID",
          "Aggregate": {
            "Operation": "Count",
            "Column": "customercontact_ID"
          }
        }
      }
    }

manytoone

Permet de créer une relation pour chercher une information dans une entité annexe. On a toujours 1 ligne dans l’entité annexe.
Il faut renseigner les propriétés suivantes :

Schema : nom du schéma dans lequel on doit chercher la donnée
ForeignKey : nom de la colonne de l’entité courante qui fait la jointure avec la clé primaire de l’entité qui contient la donnée
c’est l’inverse de la relation zerotoone et onetomany
Column : nom de la colonne qui contient la donnée à récupérer
Cette colonne peut être une colonne calculée.

Exemple : pour l’entité customercontact, on veut afficher la colonne calculée _lastVisit de l’entité customer

exists

Permet de créer une relation d’existence. Retourne normalement un boolean.
On aimerait l’utiliser par exemple pour avoir un filtre d’affectation de collaborateurs aux tiers.

Son utilisation est prévue avec un filtre à déclarer dans une vue de liste d’entité (*.entity.json).

Data.SqlExpression

L’utilisation de la propriété SqlExpression va vous permettre de saisir une sous-requête.
Il est possible d’utiliser d’autres colonnes dans cette expression. La syntaxe est la suivante :

pour manipuler la donnée brute avec la valeur en base de donnée
Note : ne fonctionne pas avec une colonne calculée.
pour manipuler la donnée finale qui est affichée à l’utilisateur
Notes :
- la traduction et le formatage ont déjà été appliqués.
- la syntaxe {{<nom_de_colonne>}} a le même effet

Exemple 1 : pour l’entité customercontact, on veut afficher le nom complet du contact

Exemple 2 : pour l’entité customercontact, on veut afficher si le contact a un compte extranet

Colonnes réelles

Il s’agit des colonnes qui existent dans la table du schéma.
On les ordonne dans le même ordre qu’en base de données (ordre de création).
Cela va faciliter l’ajout de nouvelle colonne.

Translation

Il est possible de redéfinir le nom de la colonne avec la propriété Translation, mais il est préférable de revoir le nom directement dans les traductions en base de données,
car elles sont aussi utilisées à d’autres endroits de l’application Web :

segment / plan d’action / emailing
traduction de donnée avec datatranslation
champ de fusion pour la rédaction d’un email

Le seul cas où l’on a besoin d’utiliser Translation c’est lorsque le champ a un nom différent en fonction de la sous-entité.
Exemple : deal.probability correspond à la “Probabilité” d’une opportunité et à l’ “Avancement” d’une affaire.

Data.ForeignEntity

Une foreign doit avoir une entité définie que l’on va réutiliser pour son affichage.

On met donc le nom du schéma à utiliser pour récupérer les informations d’identification.
Note : ne pas hésiter à utiliser une sous-entité lorsque c’est nécessaire, car la liste proposée dans le filtre de cette colonne sera réduite à la sous-entité.
Par exemple, il faudrait utiliser une sous-entité différente pour chaque generictype.

Data.Relation.RelationStrength

Lorsque la colonne est une foreign, SFK va faire une jointure INNER JOIN ou LEFT JOIN.

Par défaut la jointure est LEFT JOIN.
Exemple : customer.generictype_ID_customerFamily (Famille de tiers).

Si la colonne a une contrainte required, la jointure sera alors INNER JOIN.
Exemple : customer.generictype_ID_customerType (Type de tiers).

Mais il est possible d’agir sur le type de jointure en utilisant la propriété Data.Relation.RelationStrength :

Strong : force l’utilisation d’un INNER JOIN
Weak : force l’utilisation d’un LEFT JOIN

Exemple : customercontact.customer_ID
Le tiers est obligatoire pour un contact.
Par contre il est possible d’accéder à un contact dont le tiers n’est pas accessible, dans le cas où ce contact a une relation avec un tiers auquel on a accès.
Il faut remplacer INNER JOIN par LEFT JOIN pour donner l’accès à ce contact.

Colonnes correspondant aux champs personnalisés

Ces colonnes ne sont pas à lister dans le schéma car elles sont totalement gérées par le système et l’interface de gestion des champs personnalisés.

Formatter

La propriété Data.Formatter permet d’appliquer le type et le format.
Note : il est parfois nécessaire d’alimenter le FieldType.

Traduire

Il existe 2 modes de traduction :

System : qui utilise une jointure avec sw_sys_languagetext
Data : qui utilise une jointure avec sw_data_translation

Pour appliquer un mode de traduction il faut renseigner la propriété Data.TranslationMode.

Règles:

lorsqu’on a Data.TranslationMode = “Data”, on doit aussi avoir la propriété Translatable = true
il faut toujours garder la valeur brute d’une colonne translationKey, car sinon la clé sera traduite, or dans ce cas précis l’utilisateur veut afficher la clé de traduction

Notes :

pour le moment il est impossible de traduire une colonne calculée
pour le moment il n’y a pas de solution pour traduire generictype comme avant

Badge

Il y a 2 cas de badges.

Badge à couleur statique

Pour définir une seule couleur pour un badge, vous pouvez directement utiliser la propriété BadgeColor.

Exemple :

Badge à couleur dynamique

Pour définir une couleur qui change en fonction de la valeur d’un champ, vous pouvez utiliser

une règle de mise en forme pour colorier une cellule ou une ligne entière (voir exemple de règle de mise en forme)
un badge à couleur dynamique

Pour faire un badge à couleur dynamique

Il ne faut pas changer le FieldType, car c’est obligatoirement une string pour le badge
Il faut créer une colonne calculée qui retourne la couleur.
Note : ne pas oublier de rendre inaccessible la colonne.
Utiliser la propriété BadgeColorField pour pointer vers la colonne calculée qui renvoie la couleur.

Exemple :

Rendre inaccessible

On veut rendre inaccessible une colonne pour diverses raisons :

la colonne contient des informations multiples
Exemple : customer.closedDays
la colonne contient des informations à ne pas partager
- gpsKeyDatas
- password
- colonne calculée pour obtenir la couleur d’un badge
la colonne n’est plus utilisée, elle est obsolète
la colonne n’est pas utilisée ou sans intérêt pour la sous-entité
Exemple : deal.isProject

Retirer le liens des foreign

Lorsque la colonne est une foreign, l'équipe système va par défaut activer le lien associé à la colonne.

Il faudra parfois désactiver les liens sur les foreign principalement pour deux raisons :

la foreign provient d’une sous-entité (par exemple : generictype[brand].schema.json).
il n’y a pas de page associée dans le BO.

Pour ce faire, utiliser :

06 CRM 6.2

Colonnes d’entité

Catégories de colonne

Colonnes calculées

Translation

FieldType

Data.Relation

zerotoone

onetomany

manytoone

exists

Data.SqlExpression

Colonnes réelles

Translation

Data.ForeignEntity

Data.Relation.RelationStrength

Colonnes correspondant aux champs personnalisés

Formatter

Traduire

Badge

Badge à couleur statique

Badge à couleur dynamique

Rendre inaccessible

Retirer le liens des foreign