Processus de souscription : vérifier avant de valider

Contrôler les transactions et les marquer comme prêtes : le verrou dont dépendent toutes les étapes suivantes, et les deux contrôles qui méritent de ralentir.

Présentation

Les transactions arrivent dans un processus en Brouillon. En marquer une comme Prêt est un acte délibéré, et c'est le verrou dont dépend tout ce qui suit : les documents, les paiements et la signature s'appuient tous sur les données de transaction. Tant que les transactions ne sont pas prêtes, la table des paiements vous l'indique clairement : « Aucune transaction n'est encore prête à être traitée (pour les paiements) ».

Être prêt signifie que l'équipe deal affirme : cette transaction est correcte. Une erreur repérée ici coûte une minute ; la même erreur repérée après génération des documents impose de reconstruire.

Ce que vous allez apprendre

Ce que la table des transactions vous montre
Les deux contrôles qui ont de vraies conséquences
Comment travailler sur un tour volumineux
Ce qui devient disponible une fois les transactions prêtes

Étapes

Depuis le Tableau de bord du projet, ouvrez le processus dans Opérations en cours. Sur le Tableau de bord de la souscription, ouvrez Configuration des transactions.
Vérifiez chaque transaction par rapport à vos termes source : le fichier que vous avez importé ou les termes qui vous ont été communiqués.
Corrigez tout ce qui est erroné pendant que la transaction est encore en Brouillon.
Passez chaque transaction correcte au statut Prêt.
Répétez jusqu'à ce que chaque transaction soit Prêt.
Les autres étapes ont maintenant des données avec lesquelles travailler : les documents (A8.6) et les paiements (A8.13) deviennent disponibles.

Ce qu'il faut vérifier

La table affiche, pour chaque transaction : Type de mouvement, Société, Émetteur / Cédant, Bénéficiaire / Acquéreur, Type de titre et Valeur nominale, avec le montant et le statut.

Type de mouvement : émission, transfert, apport, actions gratuites. Le type détermine quel modèle s'applique et comment la table de capitalisation évolue.
Société : sur une souscription couvrant plusieurs ManCos, la bonne personne dans la mauvaise société est une erreur plausible et coûteuse.
Les deux parties : vendeur et acheteur dans le bon sens.
Type de titre : ordinaire ou de préférence, et quelle catégorie.
Quantité et valeur nominale : les chiffres qui atteindront la table de capitalisation.

Deux de ces contrôles méritent de ralentir. Le sens des parties, car s'il est inversé, la table de capitalisation évolue dans le mauvais sens sans que rien ne paraisse étrange. Et l'affectation de société sur une souscription couvrant plusieurs ManCos : un participant qui souscrit dans trois ManCos doit apparaître une fois par ManCo, pas trois fois dans une seule.

Sur un tour volumineux, filtrez plutôt que de faire défiler : vous pouvez limiter à Réserve, Problèmes ou Différé seulement.

À quoi ressemble un bon résultat

Chaque transaction indique Prêt, et chacune a été vérifiée par une personne par rapport aux termes, pas simplement importée et supposée correcte. Les étapes Paiements et Documents affichent maintenant du travail à faire plutôt qu'une table vide.

Problèmes fréquents

« Aucune transaction trouvée ou ajoutée pour le moment. » Rien n'a été créé. Dans le parcours en masse, cela suggère que l'import n'a pas été enregistré ; dans le parcours manuel, les transactions se configurent ici et vous ne les avez pas encore ajoutées.

Une transaction est erronée et déjà Prêt. Corrigez-la avant de générer les documents. Une fois qu'un document existe avec des données erronées, vous avez deux problèmes au lieu d'un (A8.6).

Acheteur et vendeur inversés. C'est facile à faire dans un fichier importé et lourd de conséquences. C'est le contrôle le plus important à ralentir.

La mauvaise société sur une souscription couvrant plusieurs ManCos. Filtrez par société et relisez chaque groupe.