Définition des prérogatives utilisateurs dans le logiciel
Un logiciel de payment factory possède une interface d’administration et une configuration des users qui autorise la caractérisation fine des autorisations d’action et de visibilité accordées à un utilisateur, comme :
- l’accès au logiciel
- la visualisation de certains menus
- le droit d’d’administrateur
- la signature numérique
- le transfert au partenaire bancaire
- l’autorisation de voir certaines transactions
- l’habilitation à voir des caractéristiques dans certains paiements (ex : nom d’un individu ou compte)
- la sévérité de son mot de passe
- l’expiration de son mot de passe
- l’impossibilité d’avoir accès à certaines datas (ex : si l’utilisateur Durand ne peut pas voir une entité X et si X se rapporte à un paiement que cet user est supposé avoir l’habilitation de visualiser, celui-ci s’en verra refuser la lecture)
- l’autorisation de certains genres de paiements ou de certaines évolutions
- l’appartenance à un collège d’users qui a des Droits et privilèges communs
- l’élaboration de macros
- l’obtention de messages bancaires
Flux de travail et concentration centrale des paiements
Selon les processes internes mis en place par l’entreprise, les phases à effectuer dans l’application de paiement en amont du passage au module de communication bancaire sont plus ou moins nombreuses. En la matière, nous pouvons lister notamment les phases suivantes :
A découvrir également : Les solutions pour optimiser l'achat d'espace publicitaire
- l’enregistrement ou encore l’import de paiements et factures dans l’outil (depuis un outil du SI) au sein d’une société fille
- la construction automatisée ou manuelle en lots de paiements selon des critères communs aux paiements
- envoi des paquets/lots envoyés à l’approbateur qui confirmera ou non la constitution de ces lots (selon le type et la complexité de la procédure d’approbation décidée, un paquet pouvant être rejeté si un seul des paiements incorporés est réprouvé, voire être validé malgré cela après l’élimination du paiement incriminé)
- ce premier décideur transmettra à son N+1 ces lots de paiements homologués ; ce dernier entérinera par voie numérique (via un jeton d’identification, un objet connecté, voire simplement par une action sur la souris) ces lots
- le cinquième intervenant sera alors avisé par le module que des paquets peuvent être envoyés à la centrale de trésorerie au sein de la maison-mère
- dans la holding, un nouveau workflow peut alors être mis en place au sein de l’application de paiement et répliqué tout ou partie des étapes indiquées plus haut
- enfin, le valideur final enverra à l’établissement bancaire le paquet ou les batches de paiements qui sont parvenus à réaliser avec succès les nombreuses étapes de l’approbation commentées ci-dessus, toujours par l’intermédiaire de l’application, si cette dernière intègre bel et bien un dispositif de communication aux banques. Dans le cas contraire, ils seront envoyés à l’application aval en charge de la relation banque-entreprise
Chaque user qui intervient dans le workflow d’autorisation doit être avisé par le système d’une action à exécuter, soit par email (envoi programmé par l’application), soit à la connexion par le biais d’un dashboard listant les opérations à effectuer.
Toutes les sociétés n’ayant pas la même vision du workflow à mettre en place dans une payment factory, le listing exhaustif de ces processes est impossible. Certaines ont en effet une vision diamétralement opposée à celle qui est présentée supra et privilégient a contrario une complète automatisation jusqu’à la l’ultime ou la pénultième étape du flux de travail, juste en amont de l’envoi aux partenaires bancaires. Elles laissent alors à l’outil le soin d’envoyer les paquets aux statuts suivants sans intervention humaine, grâce à la mise en place de routines automatisées (macros).
A lire en complément : Alimentation saine : 3 propositions
Batches de paiements ou paiements unitaires
Comme on vient de le voir, les payment factories les plus efficaces offrent la possibilité aux utilisateurs de procéder à l’envoi bancaire non seulement de paiements à l’unité, mais aussi de paiements par paquets. Effectivement, pour des raisons de productivité évidentes, lorsque de nombreuses transactions afférentes à des paiements et à des encaissements sont importées à l’intérieur de l’application, le traitement par batch permet de gagner un temps considérable. Les paiements sont donc centralisés avant d’être insérés dans des lots.
Le progiciel de paiement permet ainsi grâce à des macros d’indiquer les types de paiements qui seront inclus dans un lot. Il est donc possible de penser qu’un lot sera constitué :
- des paiements quotidiens à réaliser en direction d’un même compte en banque
- de tous les paiements effectués par une filiale donnée à destination d’une autre entité
- des virements de paie
- des paiements du mois relatifs à une société spécifique
- …
Le user autorisé à approuver ces lots peut être sélectionné en fonction des ces privilèges relatifs aux spécificités des paiements du lot.
Dans beaucoup de payment factories, on peut remarquer que le niveau de détail des flux financiers analysés et gérés est bien plus fin que les simples paiements et lots de paiements avec, notamment :
- des bordereaux attachés à un paiement
- des regroupements de paquets de paiements à envoyer à l’établissement bancaire
Transmission aux banques et paiements
La payment factory est chargée de regrouper et de communiquer les paiements et les lots de paiements aux banques inscrites dans le référentiel, de collecter les messages de ces établissements bancaires (acceptation, refus, demande d’informations…) et autres messages à destination des établissements bancaires, ensuite de les soumettre au destinateur, c’est-à-dire au user de la payment factory qui a engendré la réalisation de la communication bancaire.
Comme les protocoles Web – http, https, smtp… – il existe différents protocoles de communication à destination des partenaires bancaires. Les plus utilisés et sécures sont :
- SWIFTNet : protocole de communication bancaires au niveau mondial, dirigé par l’entreprise SWIFT (Society for Worldwide Interbank Financial Telecommunication)
- EBICS : protocole d’échange d’informations reposant sur la version sécurisée de http (https) choisi par le CFNOB pour remplacer les protocoles ETEBAC (ETEBAC 3 et ETEBAC 5), considérés trop lents et moins sécures, au début des années 2010
Ces standards sont, en 2016, employés en masse par la totalité des grands groupes internationaux dans le cadre de leurs paiements et de leurs encaissements.
Référentiel intégré à la payment factory
Pour obtenir une payment factory efficace, il est nécessaire de collecter tous les paiements pour les grouper. Toutefois, c’est insuffisant pour que le module soit taillé pour la route, et un nombre conséquent de datas doivent être versées à la BDD du progiciel. Ces données sont la plupart du temps importées depuis un outil déjà intégré au SI de la société, par le biais d’un moteur d’importation-exportation qui translate les données aux formats voulus par le module de paiements. On y trouve, entre autres, des :
- filiales
- pays
- paramètres FX
- banques
- structures IBAN et codes BIC
- comptes bancaires
- typologie de transactions
- limites de validation
- jours fériés bancaires
- types de paiements
Ce référentiel de données est ensuite utilisé pour les paiements ou dans le paramétrage des différentes phases du workflow spécifique de chaque catégorie de transactions.
Lire la 1ère partie « Payment factory : concept et définition »