Séparation de domaine et Financial Services Payment Operations

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 4 minutes de lecture

    • Financial Services Payment Operations prend en charge Séparation de domaine. Séparation de domaine vous permet de séparer les données, les processus et les tâches administratives en groupes logiques appelés domaines. Vous pouvez contrôler plusieurs aspects de cette séparation, notamment les utilisateurs qui peuvent voir les données et y accéder.

    Niveau de prise en charge : basique

    • Logique métier : garantit que les données parviennent au bon domaine pour les cas d'utilisation du fournisseur de service de l'application.
    • L'application prend en charge Séparation de domaine lors de l'exécution. Séparation de domaine inclut la séparation à partir de l'interface utilisateur, des clés de cache, du reporting, des déploiements et des agrégations.
    • Le propriétaire de l'instance doit configurer l'application de sorte qu'elle fonctionne sur plusieurs locataires.

    Exemple de cas d'utilisation : lorsqu'un fournisseur de service (SP) utilise la messagerie instantanée pour répondre au message d'un locataire-client, le client doit pouvoir afficher la réponse du SP.

    Pour en savoir plus sur les niveaux de prise en charge, consultez la rubrique Prise en charge de Séparation de domaine par les applications.

    Comment fonctionne Séparation de domaine dans Financial Services Payment Operations

    Toutes les Financial Services Operations (FSO, Opérations des services financiers) applications sont construites sur de Gestion du service client (CSM) nombreuses tables et en utilisent plusieurs CSM . Les tables de référence clés sont les tables client telles que Consommateur, Compte et Contact, et ces tables sont séparées par domaine.

    Tables

    Toutes les nouvelles tables ajoutées dans Payment Operations sont séparées par domaine :
    • sn_bom_payment_inquiry
    • sn_bom_payment_inquiry_task
    • sn_bom_payment_service
    • sn_bom_payment_claim
    • sn_bom_payment_claim_task
    • sn_bom_checking_account
    • sn_bom_saving_account

    Cas d'utilisation

    Demande de paiement
    Les clients ont la possibilité de créer une question de paiement via le portail pour les cas d’utilisation suivants :
    • Réclamation du bénéficiaire non reçue (BCNR) : le client a envoyé un paiement, mais le destinataire prétend n’avoir jamais reçu l’argent.
    • Paiement par erreur (PIE) – Le client fait une erreur lors de l’envoi d’un paiement et essaie de récupérer l’argent.
    Les employés des succursales et les agents de centres d’appels peuvent créer ces demandes au nom du client. Le personnel des opérations de paiement reçoit des demandes de leurs clients ainsi que de banques externes.
    • Les demandes internes proviennent des propres clients de la banque. Le client destinataire peut être interne ou externe à la banque. La distinction entre les destinataires internes et externes est importante car elle détermine la voie empruntée par Payment Operations pour résoudre la demande.
    • Les demandes externes proviennent de banques tierces, ce qui signifie que le destinataire du paiement est toujours interne.
      Remarque :
      Il ne peut jamais y avoir de cas où la demande est externe et le destinataire est externe.
    • Certaines enquêtes peuvent aboutir à la création d’une réclamation.
    Réclamation de paiement
    Les agents de demande peuvent créer une réclamation au nom d’un client lorsque la banque détermine que la réclamation est valide et que le client a droit à un remboursement.
    Le personnel des opérations de paiement reçoit les réclamations soit en interne, soit auprès d’une banque externe. Lorsqu’ils reçoivent la demande, ils commencent à déterminer où obtenir le remboursement.
    • Les réclamations internes proviennent de clients de la banque soit à la suite d’une demande, soit directement du personnel de la banque (succursale ou centre d’appels). Les agents peuvent résoudre la réclamation s’ils savent où obtenir le remboursement. Le remboursement peut être externe (paiement à un client bancaire tiers) ou interne (paiement au client de la banque). Si le remboursement est interne, une approbation de débit doit être créée (voir Approbation de débit ci-dessous).
    • Les réclamations externes proviennent de banques tierces. Le remboursement est toujours interne pour les réclamations externes. Les agents peuvent avoir besoin de créer une approbation de débit pour les remboursements internes (voir Approbation de débit ci-dessous).
    Approbation de débit
    Les agents de réclamations créent des approbations de débit pour que les clients approuvent un remboursement à partir d’une réclamation. Le client peut accepter le débit ou le contester ou le rejeter.
    Remarque :
    Parfois, une fonctionnalité ou une ServiceNow® application de plateforme peut être en mesure de prendre en charge efficacement les cas d’utilisation d’un fournisseur de service, même si le cadre de travail du domaine n’est pas utilisé. Dans ce cas, l’application peut se voir affecter Basic*, Standard* ou Enhanced* pour son niveau de prise en charge de domaine, et inclure des cas d’utilisation détaillés. Par exemple : avant la version New York, Catalogue de services n’avait pas de support de domaine. Toutefois, le propriétaire de l’instance a pu configurer des catalogues et des éléments distincts pour chaque client dans une instance séparée par domaine. Cela a permis d’utiliser Catalogue de services à un niveau de support standard . Pour en savoir plus, consultez Séparation de domaine Niveaux de prise en charge des applications.