Classe client - Contrôles

Vous devez définir diverses règles de gestion pour chaque division dans laquelle une classe client a des clients. Par exemple, si vous avez des activités en France et en Angleterre ET si vous avez des divisions SIC pour chaque pays ET si vous avez des clients résidentiels dans chaque pays, vous devez définir des contrôles de classe client pour chaque division SIC, par rapport à la classe client résidentiel. Pour tenir à jour ces informations, sélectionnez Administration > Client > Classe client > Rechercher et accédez à la page Contrôles.

Description de la page

La zone de défilement Contrôle de classe client contient les règles de gestion régissant les comptes qui appartiennent à une Division SIC et une classe client. Les champs suivants doivent être définis pour chaque division SIC :

Utilisez l'option Ech. facture (jours) pour définir le nombre de jours après la date de facturation au bout duquel la facture arrive à échéance. Si la date d'échéance correspond à un jour de fin de semaine ou à un jour férié, le système la reporte au jour ouvrable suivant (selon le calendrier des jours ouvrables défini pour la division SIC du compte).
Indiquez le plan de mensualisation facturée affecté par défaut aux nouveaux comptes appartenant à cette classe client. Notez que ce plan peut être modifié par la suite si le compte concerné a des besoins particuliers en matière de traitement des mensualités. Pour plus d'informations, voir Définir des plans de mensualisation facturée.
Dans le champ Fréquence minimum analyse par le processus R&C (jours), indiquez le nombre maximum de jours entre deux vérifications de la dette d'un compte par le moniteur de compte débiteur. La valeur zéro (0) signifie que les comptes de cette classe client doivent faire l'objet d'une vérification quotidienne.
Dans le champ Délai de grâce (jours) avant analyse par le processus R&C, indiquez le nombre de jours autorisés entre la date d'échéance de la facture et l'analyse du compte par le moniteur de compte débiteur.
Si des pénalités de retard peuvent être appliquées aux clients appartenant à cette combinaison classe/division, activez la bascule Pénalité de retard.
Dans le champ Délai de grâce PRP, indiquez le nombre de jours entre la date d'échéance d'une facture et la génération d'une pénalité de retard (si les différents algorithmes PRP le permettent - pour plus de détails, voir Calcul des pénalités de retard). Si la date limite du délai de grâce correspond à un jour de fin de semaine ou à un jour férié, le système la reporte au jour ouvrable suivant (selon le calendrier des jours ouvrables défini pour la division SIC du compte).
Indiquez un groupe d'accès qui sera utilisé par défaut sur un compte en fonction de sa classe client et de sa division SIC. Cette valeur remplacera la valeur par défaut provenant du groupe d'accès par défaut de l'utilisateur. Remarque : Le groupe d'accès défini ici ne s'applique pas si un algorithme Classe de contrôle de client - Déterminer le groupe d'accès est défini et renvoie avec succès un groupe d'accès.

La grille suivante contient les algorithmes chargés de contrôler des fonctions importantes du système. Pour chaque algorithme, vous devez définir les informations suivantes :

Spécifiez l'événement système auquel l'algorithme est associé (voir la table suivante pour obtenir une description de tous les événements possibles).
Indiquez la Séquence et l'Algorithme pour chaque événement système. Vous pouvez attribuer la valeur 10 à la séquence, sauf si l'événement système que vous utilisez est associé à plusieurs algorithmes. Dans ce cas, vous devez indiquer au système la Séquence d'exécution de ces algorithmes.

Avertissement :

Ces algorithmes représentent généralement des processus système importants. L'absence d'un algorithme risque de perturber le bon fonctionnement du système.

Vous pouvez définir des algorithmes pour les événements système suivants :


Evénement système	Obligatoire/facultatif	Description
Le montant de paiement auto excède la limite	Facultatif	Cet algorithme est appelé pour gérer la situation dans laquelle un prélèvement automatique créé par le système dépasse la limite de retrait maximum spécifiée pour le client. Plus particulièrement cet algorithme est appelé dans les conditions suivantes : - Une limite de retrait maximum est spécifiée dans les options de prélèvement automatique du compte. - Le système tente de créer un prélèvement automatique dont le montant est supérieur à cette limite. - L'algorithme de prélèvement automatique rattaché à l'enregistrement d'installation possède une logique qui appelle cet algorithme lorsque les conditions ci-dessus sont réunies. Si la situation ci-dessus se produit alors que vous n'avez pas rattaché ce type d'algorithme, le système crée le prélèvement automatique sans générer d'erreur. Pour plus d'informations, voir Comment implémenter des limites de retrait maximum.
Finalisation de facture	Facultatif	Lors de la finalisation d'une facture pour un compte, le système appelle des algorithmes de finalisation pour exécuter des tâches supplémentaires. Pour savoir à quel stade du processus de finalisation cet algorithme est appelé, reportez-vous à la description du bouton Finaliser, à la section Cycle de vie d'une facture.
Admissibilité facture	Facultatif	Les algorithmes rattachés à cet emplacement de plug-in sont appelés lors de la génération d'une facture dans le cadre du processus de facturation en mode batch. Ils permettent de déterminer si un compte est admissible pour facturation, auquel cas il doit être exclu de tout autre traitement. En l'absence d'algorithme d'admissibilité, le système crée une facture pour tout compte inclus dans le cycle de facturation en cours. Par la suite, le processus de facturation supprime cette facture s'il détecte qu'aucune information n'y est associée.
Validation/Annulation de section de facture	Facultatif	Lors de la validation ou de l'annulation d'une section de facture associée à un compte appartenant à la combinaison classe client/division spécifiée, un algorithme de ce type peut être appelé pour exécuter des tâches supplémentaires. Pour plus d'informations sur la validation et l'annulation de sections de facture, voir Cycle de vie d'une section de facture.
Annuler la facture	Facultatif	Cet algorithme permet d'inclure une logique d'annulation supplémentaire en cas d'annulation en ligne. Les algorithmes de ce type peuvent être appelés dans deux modes : D (déterminer les boutons de la page Facture) et X (annuler la facture). Le mode D détermine si un bouton d'action permettant d'annuler la facture est affiché dans la page Facture. Le mode X exécute la logique d'annulation proprement dite.
Déterminer le groupe d'accès	Facultatif	Lors de l'ajout d'un compte ou de la modification de la division SIC ou de la classe client d'un compte, cet emplacement de plug-in peut être utilisé pour déterminer le groupe d'accès approprié. Cet emplacement de plug-in permet de définir une logique plus complexe, telle que la vérification du groupe d'accès dans les autres comptes de l'acteur principal. Si l'algorithme de détermination du groupe d'accès n'est pas utilisé, la valeur du groupe d'accès peut provenir par défaut du contrôle de la classe client ou de l'utilisateur.
Validation de transaction financière	Facultatif	Lors de la validation d'une transaction financière, cet algorithme est appelé pour exécuter des tâches supplémentaires. Par exemple, si vous pratiquez le lettrage, vous avez besoin d'un algorithme de ce type pour gérer l'annulation des événements de lettrage en cas d'annulation d'une transaction financière apparaissant sur un événement de lettrage. Pour plus d'informations, voir Comment les événements de lettrage sont-ils annulés ?
Admissibilité PRP	Obligatoire si des pénalités de retard peuvent être appliquées à la classe client/division.	Cet algorithme est appelé par le processus qui gère les pénalités de retard, afin de déterminer si des pénalités de retard peuvent être appliquées. Le fait qu'une classe client associée à un compte autorise le calcul de pénalités de retard ne signifie pas que les éléments de contrat impayés feront l'objet de pénalités de retard. Le type d'EdC affecté à un élément de contrat impayé doit en outre référencer un algorithme de création de pénalités de retard. Pour plus d'informations sur le rôle du type d'EdC dans la génération des pénalités de retard, voir Type d'EdC - Principal. Pour plus d'informations sur les pénalités de retard en général, voir Calcul des pénalités de retard. Remarque : Un seul algorithme. Vous ne pouvez définir qu'un seul algorithme d'admissibilité pour pénalité de retard pour une combinaison classe client/division SIC.
Appliquer un débit Insuffisance de provisions	Facultatif	Cet algorithme est appelé en cas d'annulation d'un paiement pour un motif indiquant une insuffisance de provisions. Pour plus d'informations sur ce qui se passe en cas d'annulation d'un paiement en raison d'une insuffisance de provisions, voir Annulations pour insuffisance de provisions. Remarque : Un seul algorithme. Vous ne pouvez définir qu'un seul algorithme chargé d'appliquer un débit Insuffisance de provisions pour une combinaison classe client/division SIC.
Finalisation de demande	Facultatif	Lors de la finalisation d'une commande pour un client appartenant à la classe client spécifiée, cet algorithme est appelé pour effectuer des tâches supplémentaires (créer un contact client, par exemple). Vous ne devez spécifier ce type d'algorithme que si des tâches supplémentaires sont requises lors de la finalisation d'une commande pour un client appartenant à la classe indiquée.
Ventilation de trop-perçu	Obligatoire	Lorsqu'un client effectue un paiement supérieur au montant dû, cet algorithme est appelé afin de déterminer de quelle façon le trop-perçu doit être traité. Pour une description de la configuration du système pour gérer les exigences en termes de trop-perçu, voir Segmentation des trop-perçus. Remarque : Un seul algorithme. Vous ne pouvez définir qu'un seul algorithme de ventilation de trop-perçu pour une combinaison classe client/division SIC.
Date d'échéance de substitution	Facultatif	Pour calculer la date d'échéance d'une facture, le système ajoute à la date de facture le nombre de jours avant échéance défini pour la classe client associée au compte concerné. S'il est nécessaire de faire appel à une méthode de substitution pour les comptes appartenant à une classe client spécifique, indiquez ici l'algorithme approprié. Remarque : Un seul algorithme. Vous ne pouvez définir qu'un seul algorithme de substitution de date d'échéance pour une combinaison classe client/division SIC.
Annulation de paiement	Facultatif	Les algorithmes de ce type sont appelés lorsqu'un paiement est annulé.
Ventilation de paiement	Obligatoire	Cet algorithme est appelé pour ventiler un paiement sur les comptes associés à un élément de contrat. Pour plus d'informations à ce sujet, voir Comment ventiler un paiement sur un élément de contrat spécifique. Remarque : Un seul algorithme. Vous ne pouvez définir qu'un seul algorithme de ventilation de paiement pour une combinaison classe client/division SIC.
Validation de paiement	Facultatif	Lors de la validation d'un paiement, cet algorithme est appelé pour effectuer des tâches supplémentaires. Si vous pratiquez le lettrage, vous avez besoin d'un algorithme de ce type pour lier les transactions financières relatives au paiement à l'événement de lettrage initialement créé lors de la ventilation du paiement. Pour plus d'informations, voir Paiements et événements de lettrage.
Post-finalisation de facture	Facultatif	Si des algorithmes de ce type sont associés à une classe client, ils sont appelés après la finalisation d'une facture pour un compte lié à cette classe client. Pour savoir à quel stade du processus de finalisation cet algorithme est appelé, reportez-vous à la description du bouton Finaliser, à la section Cycle de vie d'une facture.
Pré-finalisation de facturation	Facultatif	Si des algorithmes de ce type sont associés à une classe client, ils sont appelés immédiatement avant le démarrage de la finalisation pour un compte lié à cette classe client. Ces algorithmes peuvent effectuer les opérations suivantes : Supprimer une facture. Vous pouvez par exemple définir un algorithme de pré-finalisation chargé de supprimer une facture dans le cas où le système détecte une condition susceptible d'empêcher l'envoi de cette facture au client (par exemple, si la facture contient seulement des informations sur les paiements récents). Abandonner le processus de finalisation et créer une anomalie de facture. Si l'algorithme indique que cela est nécessaire, la facture reste en attente et le système génère une anomalie de facture précisant pour quel motif le processus de finalisation a été abandonné. Vous pouvez par exemple définir un algorithme de pré-finalisation chargé d'effectuer ces opérations si la vérification d'intégrité détecte un problème concernant le compte ou les éléments de contrat associés. En cas d'échec de la vérification d'intégrité, le système génère une anomalie indiquant pour quelle raison la facture est laissée en attente. Pour savoir à quel stade du processus de finalisation cet algorithme est appelé, reportez-vous à la description du bouton Finaliser, à la section Cycle de vie d'une facture.
Finalisation d'offre	Facultatif	Lors de la finalisation d'une offre pour un client appartenant à la classe client spécifiée, cet algorithme est appelé pour effectuer des tâches supplémentaires (créer un contact client, par exemple). Vous ne devez définir ce type d'algorithme que si des tâches supplémentaires doivent être effectuées lors de la finalisation d'une offre pour les clients appartenant à une classe client donnée.
Méthode de passage en pertes et profits	Obligatoire si vous autorisez les utilisateurs à passer des dettes en pertes et profits en temps réel à l'aide de la transaction P&P.	Lorsque l'utilisateur clique sur le bouton de création dans la page de la transaction P&P, cet algorithme est exécuté pour passer la dette sélectionnée en pertes et profits. Pour plus d'informations, voir Ramifications des passages en pertes et profits dans la comptabilité générale.