Mérops

Pour la levée d'un achat SRD au jour de liquidation (livraison au comptant), je pense effectuer les modifications suivantes.

Prenons l'exemple d'une transaction "TA1" de type SRD, le 04/02/2008 j'achète une quantité "QA1" au prix d'achat "PA1", avec des frais d'achat "FA1.

Nous sommes le 25/02/2008 17H, jour de liquidation, je lève ma position. Mérops effectue les opérations suivantes.

a) Sur ma transaction "TA1" de type "SRD", je clique sur le bouton "Lever"
Sa date de vente est initialisée au jour de livraison (29/02/2008, dernier jour ouvré du mois). Dans Mérops elle sera topée "Levée au comptant", ainsi :
- Elle sera écartée des cessions.
- Elle est considérée comme soldée (pour la présentation dans l'écran "Transactions").
- Sa performance sera égale aux frais CRD (si saisis via l'écran "Opérations sur transactions") qui va de la date d'achat à la date de livraison. Les frais d'achat ne sont pas retenus dans cette performance.
- Son prix de vente et frais de vente sont nuls (ce n'est pas une vente), on pourrait même mettre comme prix de vente le prix d'achat "PA1" (pour la présentation dans l'écran "Transactions"), car ni le prix d'achat ni le prix de vente ne sont retenus dans la performance.

C'est juste une trace pour l'achat au SRD et y mettre les frais CRD via l'écran "Opérations sur transaction".


b) je créé une nouvelle transaction "TA2" de type comptant avec comme quantité "QA1" (comme que "TA1"), prix d'achat "PA1" (comme que "TA1"), les frais d'achat "PA1" (comme que "TA1"), une date d'achat au jour de livraison (29/02/2008, dernier jour ouvré du mois).
Elle est incluse dans les cessions.
Sa performance est calculée comme d'habitude.

Qu'en pensez vous ?

Mérops,

Bonjour,

Votre proposition me semble tout à fait pertinente, j'ai juste une interrogation sur l'imputation des frais CRD :
- L'imputation de ces frais sur la transaction SRD TA1 semble logique, mais de ce fait "faussera" la performance réelle lors de la vente sur la transaction TA2.

Qu'en pense les autres intervenants du forum ?

D'autre part, est il possible d'envisager qu'au moment de la levée, Merops pre-calcule et propose les frais CRD, afin qu'ils soient saisis en même temps ?

Cordialement

Jean

Re-bonjour, suite à votre courriel je mets ma réponse en ligne.
Elle est présentée en contrepoint de votre proposition.
Je mets ma partie en rouge.
J'espère que tout cela reste compréhensible !
Cordialement,
Pascal.


Bonjour,
Je viens d’adapter le post : viewtopic.php?p=4531#4531
Je pense tenir la solution (cf ci-dessous), une fois ces opérations SRD (vente, levée, report) validées, je pourrai démarrer sur le compte de liquidation.
Qu'en pensez vous ?
Merci pour votre aide et patience,

« Pour la levée d'un achat SRD au jour de liquidation (livraison au comptant), je pense effectuer les modifications suivantes.
Prenons l'exemple d'une transaction "TA1" de type SRD, le 04/02/2008 j'achète une quantité "QA1" au prix d'achat "PA1", avec des frais d'achat "FA1.

Nous sommes le 25/02/2008 17H, jour de liquidation, je lève ma position. Mérops effectue les opérations suivantes.

a) Sur ma transaction "TA1" de type "SRD", je clique sur le bouton "Lever" OK

Sa date de vente est initialisée au jour de livraison (29/02/2008, dernier jour ouvré du mois) OK je suis d’accord pour le dernier jour du mois (qu’il soit ouvré ou non), bien que, par la suite de ma réponse, cette option puisse vous paraître quelque peu incongrue. En tout cas, dernier jour du mois n’est pas le jour de livraison (je ne suis d’ailleurs pas sûr que cette notion ait encore grand sens aujourd’hui, à l’heure des transactions électroniques). Mais nous verrons cela plus loin.

Dans Mérops elle sera topée (je ne sais pas ce que vous voulez dire par « toper ».) "Levée au comptant" je trouve cette expression ni très juste ni très heureuse. Je ne vois pas où elle doit apparaître. Je pense que vous pourriez dire « SRD levé » ou « positions SRD (ou transactions SRD) levées », ou encore « achat ferme ». A voir !
, ainsi :
- Elle sera écartée des cessions. OK
- Elle est considérée comme soldée (pour la présentation dans l'écran "Transactions"). OK
- Sa performance sera égale aux frais CRD (si saisis via l'écran "Opérations sur transactions") qui va de la date d'achat à la date de livraison (au dernier jour du mois).

Les frais d'achat ne sont pas retenus dans cette performance. La performance qui s’affiche sur l’écran des transactions en cours permet de prendre une décision de vente bien informée. On souhaite qu’elle soit la plus précise possible. Donc, à mon avis, cette performance (même si ce n’est pas une notion pertinente quant à la comptabilité fiscale, car il convient de faire une différence entre les frais (achat/vente/report) et la CRD) devrait prendre en compte et les frais d’achat, ou de report, et les frais de vente estimés (comme c’est le cas actuellement) et, si possible, la CRD estimée. De même, la performance qui s’affiche sur l’écran des transactions soldées, devrait prendre en compte les frais d’achat (ou de report), les frais de vente, et la CRD estimée (réalisée, quand saisie).

- Son prix de vente et frais de vente sont nuls (ce n'est pas une vente) Là, ça demande plus ample réflexion.
Dans son état actuel, et malgré ses imperfections, le programme jouit d’une cohérence qui permet de s’y retrouver pour contrôler le détail de son compte à travers le journal des évènements.
Cette cohérence restera à vérifier, lorsque vous aurez créé un compte de liquidation (si telle est votre intention, que j’approuve !) qui risque de modifier quelque peu la façon dont sont pris en compte les opérations et les frais.
L’action de « Lever une position » peut recouvrir des réalités différentes selon qu’il s’agit d’un achat unique au SRD, d’une position reportée du mois précédent, les deux pouvant être suivis ou non d’un cumul d’opérations d’achat et de ventes, (voire de ventes à découvert…, mais laissons cela pour l’instant).
Pour rester dans la cohérence actuelle, le traitement appliqué à une transaction au SRD que l’on décide de lever doit pouvoir prendre en compte tous les cas de figure.
Au cours de nos échanges précédents, nous nous sommes accordés sur le fait que, dans un cas complexe (cumul de plusieurs opérations de report achats, ventes), et tels que les frais et plus/moins-values sont actuellement pris en compte, le Prix de revient Moyen Pondéré calculé hors frais et non arrondi [(PMP (hf) (na)] représente exactement la valeur du titre, objet de la transaction, au moment de la levée.
Je pense qu’il faut rester pour le moment dans cette cohérence.
Cela implique que la transaction levée (soldée) constate les frais d’achat et la CRD.
Que le prix de vente, de la transaction « levée », prix d’achat de la nouvelle transaction « comptant », soit le PMP (hf) (na).
Lorsqu’il s’agit d’une transaction issue d’une opération d’achat unique ou d’un report non suivi d’opérations d’achat, le prix de vente de la transaction levée (soldée) = PMP (hf) (na) = PA1.
Lorsqu’il s’agit d’une transaction issue d’un report non suivi d’opérations d’achat, PMP (hf) (na) = cours de compensation du mois précédent
,
on pourrait même mettre comme prix de vente le prix d'achat "PA1" (pour la présentation dans l'écran "Transactions"), ceci ne serait juste que dans les cas simples d’une seule opération d’achat. Il faut mettre le PMP (hf) (na)
car ni le prix d'achat ni le prix de vente ne sont retenus dans la performance. Voir plus haut.

C'est juste une trace pour l'achat au SRD et y mettre les frais CRD via l'écran "Opérations sur transaction". OK


b) Je créé une nouvelle transaction "TA2" OK
de type comptant OK
avec comme quantité "QA1" (comme que "TA1") OK
prix d'achat "PA1" (comme que "TA1"), Non pas d’accord, voir plus haut « PA2 = PMP (hf) (na) de « TA1 »

les frais d'achat "PA1" (comme que "TA1") Non , pas de frais d’achat.
une date d'achat au jour de livraison (29/02/2008, dernier jour ouvré du mois). Non. C’est là que ma position peut vous paraître incongrue, mais la date de livraison, de nos jours où les transactions sont électroniques, correspond à « J-liquidation +1 ». Il est possible de vendre la position levée dès le lendemain du jour de liquidation. Comment faites vous si elle n’est créée que le dernier jour du mois. Il ne s’agit pas d’une vente à découvert. Alors, d’accord il y a une incohérence entre le jour ou TA1 est levée (dernier jour du mois) et le jour où « TA2 » est créée (« J-liquidation +1 »). Cette incohérence peut être réduite si l’on peut solder « TA1 » à « J-liquidation +1 » et que l’on peut saisir des frais de CRD courant jusqu’au dernier jour du mois (ce qui actuellement est manuellement possible, ce que je fais. Le programme ne permettant pas de calculer la totalité de cette CRD automatiquement).

Elle est incluse dans les cessions. OK
Sa performance est calculée comme d'habitude. » OK

Bonjour,

Si j’ai bien compris, il faut pour une levée :

a) Vendre la transaction SRD avec :
- prix de vente : PMP sans frais et non arrondi
- pas de frais de vente
- date de vente au jour de liquidation + 1 jour ouvré
En interne Mérops détectera que la transaction a été levée, il l'écartera des cessions et prendra la date de livraison (dernier jour ouvré du mois civil) pour le calcul des CRD estimés.

b) Créer une transaction au comptant avec :
- même quntité que la transaction SRD
- prix d’achat : PMP sans frais et non arrondi
- pas de frais d’achat
- date d’achat au jour de liquidation + 1 jour ouvré

Merci Pascal et Jean,

Bonjour,
Juste une correction à faire : pour le calcul de la CRD sur la transaction levée, ce n'est pas "dernier jour ouvré du mois civil", mais "dernier jour du mois civil".
A part ça, tout est correct
Cordialement,
Pascal

La correction est dans la version 6.101.

Au fil des futures versions, nous aurons :
- amélioration de la saisie des frais CRD et de report
- ajout de l'estimation des frais CRD
- compte de liquidation.

Encore MERCI,