Événements et décisions : le modèle

Comment les événements groupent les décisions, comment les décisions produisent les transactions et la règle qui en découle : si une position est fausse, une transaction est fausse.

Présentation

Événement → Décision → Transaction. Trois niveaux, et chaque autre leçon de ce cours est un type de décision placé dans cette structure.

Un événement regroupe des contenus juridiques liés, un moment de la vie de la société. Sa constitution, un closing initial, une wave. Il a un libellé et une période dérivée de ce qu'il contient.

Une décision se trouve dans un événement et groupe les transactions d'un seul type. Pensez-y comme à un acte corporate : cette émission, cette cession.

Une transaction se trouve dans une décision : un mouvement de titres entre parties, ou une création de titres.

Ce que vous allez apprendre

Les trois niveaux et ce que chacun représente
Pourquoi il y en a trois plutôt que deux
Les quatre types de décision que vous pouvez créer, et le cinquième qui existe
Pourquoi rien ici n'est figé une fois créé
La règle qui vaut pour tout le cours

Pourquoi trois niveaux plutôt que deux

Parce qu'un même moment de la vie d'une société implique souvent plus d'un type d'acte.

Une wave peut émettre de nouvelles actions de préférence au sponsor et céder des actions ordinaires depuis une réserve vers des participants entrants. Ce sont deux actes corporate différents, avec des contenus juridiques différents, au même moment, prouvés par des documents différents.

Un événement, deux décisions, de nombreuses transactions. La structure existe parce que c'est la forme de la réalité.

Les types de décision

Décision	Ce qu'elle fait
Émission de titres	Créer et attribuer de nouvelles actions ou d'autres titres
Cession de titres	Enregistrer un changement de détention entre parties
Division d'actions	Plus d'actions, valeur nominale plus faible, même capital
Regroupement d'actions	Moins d'actions, valeur nominale plus élevée, même capital

Un cinquième existe : une Décision de constitution, la constitution de la société. Il n'est pas proposé sur l'écran de création parce que vous ne le créez jamais : il est créé pour vous lorsque la société est créée (A3.1), donc chaque société commence avec un événement de constitution déjà présent dans sa chronologie, à compléter (A6.2).

Rien ici n'est figé une fois créé

Les deux écrans de création le disent explicitement, et il faut les prendre au mot. Le contenu d'un événement peut être mis à jour plus tard : décisions et documents ajoutés ou retirés. Une décision peut être déplacée vers un autre événement, et sa documentation attachée mise à jour.

Et les transactions dans une décision peuvent être corrigées.

Cette flexibilité est volontaire. Les décisions arrivent en masse, depuis la clôture d'une souscription et depuis l'import d'un LBO existant depuis ses dossiers juridiques, et la création en masse peut être fausse. La structure doit être corrigeable.

Où se place la table de capitalisation

Elle ne se trouve pas dans cette hiérarchie. Elle en est dérivée : chaque transaction, dans chaque décision, dans chaque événement, additionnée. Modifiez une transaction et la table de capitalisation se reconstruit automatiquement.

Ce qui donne la règle pour tout le cours :

Si une position est fausse, une transaction est fausse, et vous la corrigez dans la décision dont elle provient.

Deux façons dont les décisions apparaissent

Vous les créez, en enregistrant l'historique d'une société, qu'il soit antérieur à la plateforme ou intervenu parallèlement. C'est ce que couvre le reste de ce cours.

La plateforme les crée, lorsqu'un processus de souscription se clôture ou lorsqu'un LBO existant est importé depuis ses dossiers juridiques.

Mais cette distinction est plus petite qu'elle n'en a l'air, et il faut être précis. Même lorsque vous créez une décision vous-même, vous ne saisissez pas ses transactions. Vous déposez les documents juridiques et la plateforme en extrait les transactions, le même mécanisme d'analyse documentaire, piloté à la main plutôt qu'en masse.

Le modèle honnête est donc que toutes les transactions sont dérivées de documents par analyse, que cette analyse s'exécute dans un processus de souscription, un import global ou une décision que vous avez créée. Le travail est toujours le même : fournir les documents, puis vérifier ce qui a été extrait.

Lorsque les documents ne sont pas disponibles, des transactions peuvent quand même être ajoutées à une décision à la main. L'analyse est le chemin prévu plutôt que le seul possible : un mouvement que vous pouvez prouver mais pour lequel vous ne pouvez pas produire de fichier appartient quand même au registre.