Séparation de domaine et Opérations de paiement services financiers

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 4 minutes de lecture

    • Opérations de paiement services financiers 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 Opérations de paiement services financiers

    Toutes les Intégrations FSO applications sont construites sur Gestion du service client (CSM) de nombreuses tables et les utilisent 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 demande 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évu prétend n’avoir jamais reçu l’argent.
    • Erreur de paiement (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 des centres d’appels peuvent créer ces demandes au nom du client. Le personnel des opérations de paiement reçoit des demandes de renseignements de la part de ses 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 l’itinéraire emprunté 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 question est externe et le destinataire est externe.
    • Certaines demandes peuvent donner lieu à 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 à l’interne, soit à partir d’une demande de renseignements ou d’une banque externe. Lorsqu’ils reçoivent la réclamation, ils commencent à déterminer où obtenir le remboursement.
    • Les réclamations internes proviennent des clients de la banque, soit d’une demande, soit directement du personnel de la banque (agence 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 de la banque tierce) 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 créances 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 suite à une réclamation. Le client peut soit accepter le débit, soit le contester, soit 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 du 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 De base*, Standard* ou Amélioré* 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 aucun domaine ne prenait en charge. 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 Service Catalog à un niveau de prise en charge standard . Pour en savoir plus, consultez Séparation de domaine Niveaux de prise en charge de l’application.