[Intégré 6.2.73.6119] frais + TTF - calcul automatique

[benji791]

Bonjour,

Je suis tout nouveau ici. Cela fait un mois que j'utilise Gesfine et j'en suis ravi (compte titre, assurance vie, compte courant, j'ai tout saisi). Voir une communeauté dynamique m'enchante encore plus.

Voilà, voilà, j'ai une idée d'amélioration qui m'éviterait de maintenir un fichier excel en parallèle de gesfine pour mes saisies.
En effet, je suis mon portefeuille boursier au quotidien avec Gesfine et tous les soirs, je saisi mes acquisition / vente de la journée. Seulement, à ce moment, mon courtier n'a pas encore publié les frais de courtage ainsi que le montant de la TTF s'il y a lieu. C'est pourtant tout bête car mon tarif est défini à l'avance et la liste des titres soumis à la TTF est également connue.
Il me faut donc systématiquement calculer cela en parallèle dans excel pour faire les saisies ce qui est assez laborieux.
Voici donc ce que je propose dans l'idéal:
- maintenir une liste de titre soumis à la TTF importable depuis un fichier excel ou plus simplement un attribut d'un titre avec une simple case à cocher "soumis à la TTF" oui/non avec un pourcentage par défaut à 0.2%
- créer à l'instar de ce qui existe dans Merops, une liste de règle pour calculer / proposer le montant des frais de courtage automatiquement. Ce module de mérops était particulièrement abouti et permettait de faire face à toutes les situations.

Benji

PS : Désolé, une demande pour un premier message sur le forum ce n'est vraiment pas courtois de ma part mais comme je sens que je suis parti pour vraiment longtemps avec Gesfine.

[Jacques Leblond]

Bonjour et bienvenue,

Je pense que ce que tu proposes pourrait être couvert par une idée que j'ai eu dans le cadre de la réflexion sur la fiscalité.
L'idée est au moment de saisir une opération (courante ou titre) d'appliquer une règle qui fractionnera le montant saisi en plusieurs catégories au niveau de l'opération courante.

On pourrait imaginer aussi modifier le montant saisi pour ne considérer que le résultat du calcul de la règle comme montant à enregistrer en base de données
Les règles pourraient s'appeler en cascade, la dernière propriété d'une règle étant d'en appeler éventuellement une autre.

Voilà ce n'est que des idées à ce stade. Je travaille actuellement sur un module commercial d'aide à la décision pour l'activité boursière. La fonctionnalité évoquée étant conséquente à mettre en oeuvre je ne l'envisagerai qu'après ce chantier.

Cela dit n'hésite pas à mettre des exemples concrets pour m'assurer que je comprend bien ton besoin et pour le moment venu en tenir compte dans la mesure du possible.

EDIT : après réflexion, pas sûr que cela couvre le besoin car le mécanisme décrit s'applique à la transaction, pas à un regroupement de transactions sur une journée comme il faut le faire pour la TTF.

[bf]

Bonsoir,

Si l'article de Wikipédia : http://fr.wikipedia.org/wiki/Taxe_sur_l ... 8France%29

est exact, ce que je ne conteste pas, la TTF me semble être une usine à gaz pour la mettre en forme, comme la fiscalité française en général.

Personnellement, boursicoteur peu actif, je me contente d'attendre le décompte de mon intermédiaire boursier pour l'intégrer dans les frais.

A noter aussi l'existence de frais de bourse à plusieurs niveaux pour le même tarif chez le même intermédiaire, cela ne simplifie pas non plus les choses (forfait sous un plafond, pourcentage dans une fourchette donnée et autre pourcentage au delà, par exemple).

A+

[benji791]

Bonjour,

Désolé de ne pas avoir donné de nouvelles plus tôt. L'alerte mail était arrivé dans mes spams .

J'ai regardé l'idée que vous aviez proposez sur la gestion de la fiscalité par opération. Effectivement je n'avais pas pensé à la problématique du regroupement des transactions à la journée. Encore une règle simple tiens
C'est d'autant plus complexe qu'il faut intégrer cette taxe dans le PRU et comme je vois que Gesfine gère le PRU au titre mais aussi à la transaction, ca risque de poser quelques soucis.
Il faudrait peut-être conserver une part manuelle avec une idée basique mais vraiment basique qui serait de faire abstraction des regroupements en laissant le contrôle à l'utilisateur. Je pars du principe que les cas où les regroupements d'opération influent sur le calcul doivent être rares car ils sous-entendent achat et vente dans la même journée. Ce type de day-trading est plus souvent mené au SRD. Or le SRD n'est pas concerné par cette taxe car l'élément déclencheur est le transfert de propriété)

Pour se faire, il faudrait un nouvel attribut au titre avec TTF? oui/non et le % (retenir le dernier %age saisi quand on le fait sur une nouvelle valeur).
Ensuite pour la fenêtre d'achat / vente, je verrais bien trois zones supplémentaires : une pour le PT brut, une pour les frais, une pour les taxes
Quand l'utilisateur a saisi qté/PU, le PT brut est affiché calculé = qté*PU. Si l'opération est au comptant et que le titre à une TTF
de déclaré, alors une taxe est proposée, les frais de courtage sont calculés (voir si module supplémentaire) possible et le montant total net est rafraichi.
Si l'utilisateur ne touche à rien, alors il peut valider.
S'il modifie les frais ou la TTF, alors le montant total net est recalculé.
S'il modifie le montant total, alors la TTF est mise à 0 et ce sont les frais qui sont calculés.

Pour la multitude de possibilité concernant les frais de courtage, il me semble possible de les gérer avec un nouvel objet fiche tarifaire associable au compte. Il comporterait au minima une liste de tarifs de courtage. Un tarif serait défini comme : une valeur basse, une valeur haute, un mode de gestion (% ou forfait)
Ex pour le tarif Optimum fortuneo.
0 - 500 - forfait -1.95
500 - 2000 - forfait - 3.9
2000 - ~ - pourcent - 0.2%

Benji.

[Jacques Leblond]

Bonsoir,

Tel que tu décris le besoin et dès lors qu'il n'y a pas nécessité de faire des regroupements d'opérations pour faire des calculs (les calculs sont fait à la transaction) alors l'idée exposée dans le sujet de la fiscalité devrait couvrir le besoin.

Par contre à ce jour je suis assez retissant à modifier les champs à saisir dans les formulaires des opérations sur titres.
Par exemple, on ne saisit jamais les frais de courtage car ils sont déductibles du montant net saisi. Je souhaite que les données à saisir soient minimales ; saisir les frais et le montant net, c'est saisir une information redondante, donc en partie inutile, et qu'il faut contrôler pour en assurer la cohérence.
Cela dit on peut afficher d'autres champs (informatifs) dès lors qu'ils sont définis par le calcul.

Pour revenir au besoin, dans l'esprit actuel le montant net saisi est "définitif", or dans ton cas ce n'est pas le cas puisque tu n'en disposes pas au moment de la saisie. Cependant rien ne m'interdit dans l'idée proposée de prévoir en plus des règles qui calculent la part des frais du montant saisi, une règle qui ajoute au montant saisi la taxe sur les opérations et donc calculer le "vrai" montant net au moment de la validation.

Ainsi dans ton scénario, on pourrait saisir un montant net de 100€ (frais de courtage inclus comme aujourd'hui),
Si tu as définit une règle qui ajoute une taxe de 2% au montant net, alors au moment de valider le montant net enregistré pour l'opération sera de 102€
Et si tu as une autre règle qui stipule que les frais de courtage sont de 1% (ou forfaitaire) du montant net saisi alors les 100€ seront décomposés en 99 € (part brute) + 1€ (Frais de courtage)

Tu auras donc :

• une opération sur titre d'un montant de 102€ dont 3€ seront considérés comme des frais/taxes en tout genre (on n'en fait pas la distinction dans les modules sur les titres) pour le calcul de la performance.
• une opération courante d'un montant de 102€ ventilée sur 3 catégories : 99 € (Achat) + 1€ (Frais de courtage) + 2€ (Taxes)

EDIT : Cela me parait être une solution assez souple, configurable à souhait par des règles qui devrait répondre à tous les besoins dès lors qu'ils s'expriment sur chaque opération.
Par contre la TTF avec de multiples achat/vente à la journée, même si c'est peu probable dans nos pratiques de trading au comptant, ne pourra pas être traitée correctement par cette solution.

[benji791]

Bonsoir Jacques,

Par contre à ce jour je suis assez retissant à modifier les champs à saisir dans les formulaires des opérations sur titres.
Par exemple, on ne saisit jamais les frais de courtage car ils sont déductibles du montant net saisi. Je souhaite que les données à saisir soient minimales ; saisir les frais et le montant net, c'est saisir une information redondante, donc en partie inutile, et qu'il faut contrôler pour en assurer la cohérence.
Cela dit on peut afficher d'autres champs (informatifs) dès lors qu'ils sont définis par le calcul.

Pour revenir au besoin, dans l'esprit actuel le montant net saisi est "définitif", or dans ton cas ce n'est pas le cas puisque tu n'en disposes pas au moment de la saisie. Cependant rien ne m'interdit dans l'idée proposée de prévoir en plus des règles qui calculent la part des frais du montant saisi, une règle qui ajoute au montant saisi la taxe sur les opérations et donc calculer le "vrai" montant net au moment de la validation.

Je suis bien d'accord, il faut limiter le nombre de données à saisir et la proposition que je faisais permettait de préserver le fonctionnement actuel. L'utilisateur ne saisit que PU et Qté ensuite le reste lui est proposé et s'il souhaite corriger le prix total frais inclus alors il le peut et les frais lui sont automatiquement affichés (dans ce cas, on ne considère qu'une inconnue et l'on met la taxe à 0). Si au contraire il voit que les frais ou les taxes ne sont pas corrects alors il les modifie dans la même fenêtre et le prix total frais inclus est actualisé.
Donc dans le cas nominal, il y aurait même une saisie de moins : celle du prix total frais inclus puisque calculé.

Ainsi dans ton scénario, on pourrait saisir un montant net de 100€ (frais de courtage inclus comme aujourd'hui),
Si tu as définit une règle qui ajoute une taxe de 2% au montant net, alors au moment de valider le montant net enregistré pour l'opération sera de 102€
Et si tu as une autre règle qui stipule que les frais de courtage sont de 1% (ou forfaitaire) du montant net saisi alors les 100€ seront décomposés en 99 € (part brute) + 1€ (Frais de courtage)

En fait tu considères que le montant net : PU*Qté + frais courtage.
Je ne suis pas sûr que ce soit le plus commode car cela contraint à toujours saisir sur cette base qui n'est pas forcément celle qui est communiquée en premier par le courtier. Pour ma part, chez fortuneo le jour même je n'ai comme information que le cours d'exécution et la quantité. Le lendemain ou surlendemain je reçois la taxe. En revanche, bizarrerie de leur plateforme, le PRU tient compte des frais de courtage dès le jour même mais ne tient compte de la taxe que le lendemain.
De plus de cette manière, tu considères les taxes en sus et les frais de courtage inclus. J'ai du mal à trouver cela intuitif.

Tu auras donc :

• une opération sur titre d'un montant de 102€ dont 3€ seront considérés comme des frais/taxes en tout genre (on n'en fait pas la distinction dans les modules sur les titres) pour le calcul de la performance.
• une opération courante d'un montant de 102€ ventilée sur 3 catégories : 99 € (Achat) + 1€ (Frais de courtage) + 2€ (Taxes)

Ca c'est top. Je n'avais pas réalisé qu'avec la souplesse de gesfine il était possible de ventiler une opération courante alors que l'opération sur titre incluait la totalité du montant. Là je dis bravo

EDIT : Cela me parait être une solution assez souple, configurable à souhait par des règles qui devrait répondre à tous les besoins dès lors qu'ils s'expriment sur chaque opération.
Par contre la TTF avec de multiples achat/vente à la journée, même si c'est peu probable dans nos pratiques de trading au comptant, ne pourra pas être traitée correctement par cette solution.

Benji.

[Jacques Leblond]

En fait tu considères que le montant net : PU*Qté + frais courtage.
Je ne suis pas sûr que ce soit le plus commode car cela contraint à toujours saisir sur cette base qui n'est pas forcément celle qui est communiquée en premier par le courtier.
...
De plus de cette manière, tu considères les taxes en sus et les frais de courtage inclus. J'ai du mal à trouver cela intuitif.

Je suis bien d'accord avec toi, dans ce cas ce n'est pas très intuitif mais c'est le scénario décrit qui en est la cause (connaissance partielle des données au moment de l'exécution de l'ordre), pas tant la solution actuelle ou future que j'ai évoquée.
J'ai fait le choix de la saisie du montant net et pas des frais (en complément du nb de part et du cours) car c'est en général ce qui est systématiquement fourni (enfin pour ce que je connais). Chaque banque doit avoir ses pratiques.
La TTF n'existait pas quand j'ai fait ce choix, mais demain on nous prépare peut être une TTF2 avec application différée en complément de la première (ou autre chose) ...
De plus la TTF est une taxe française, les utilisateurs de GesFine n'y sont pas tous soumis, c'est aussi la raison pour laquelle je ne veux pas multiplier les champs de saisie. Je préfère un système de règles, certes un peu moins intuitif que des champs pré-définis mais ô combien plus souple et plus évolutif pour s'adapter à différents pays et à l'évolution fiscale en général.

Si je pousse le raisonnement, même le montant net pourrait ne plus être à saisir, les frais, les taxes ou autres pourraient être ajoutés (calculés) par des règles pour venir définir le montant net final de l'opération.
Dans l'exemple évoqué, on pourrait considérer au moment de la saisie le "montant" comme le nb de parts x le cours d'achat et venir ajouter en sus les frais et la taxe par des règles. Ce serait plus intuitif que d'inclure les frais dans le montant et de rajouter la taxe par une règle.
Lorsque la fonctionnalité existera chaque utilisateur fera à sa guise selon les informations dont il dispose.
Idéalement il faudrait que je rajoute en plus du choix du profil de calcul (somme de règles à appliquer), un champ pour indiquer le montant net final qu'aura l'opération après sa validation.
Néanmoins je devrais conserver la saisie du montant, par compatibilité avec l'existant mais aussi pour ceux qui ne souhaiteraient pas définir de règles et continuer à fonctionner avec les frais/taxes inclus dans le montant net saisi.

Ca c'est top. Je n'avais pas réalisé qu'avec la souplesse de gesfine il était possible de ventiler une opération courante alors que l'opération sur titre incluait la totalité du montant. Là je dis bravo

Actuellement tu es obligé de reprendre l'opération courante pour la répartir, avec l'idée évoquée ce serait automatique.
C'est une fonctionnalité intéressante capable de couvrir plusieurs besoins en même temps, elle fera partie des priorités après le chantier en cours (module d'aide à la décision).

[benji791]

La TTF n'existait pas quand j'ai fait ce choix, mais demain rien nous dit que l'on ne va pas nous pondre une TTF2 en application différée en complément ou autre chose, de plus la TTF c'est une taxe française, les utilisateurs de GesFine n'y sont pas tous soumis, c'est aussi la raison pour laquelle je ne veux pas multiplier les champs de saisie. Je préfère un système de règles, certes un peu moins intuitif que des champs pré-définis mais ô combien plus souple et plus évolutif pour s'adapter à différents pays et à l'évolution fiscale en général.

Tout à fait d'accord avec un système de règle. Le paramétrage ne me rebute pas.
Concernant la spécificité française avec la TTF, il me semble que nos voisins grand-bretons ont la leur aussi. D'ici à ce que l'on retrouve la même chose dans d'autres états européens...

Si je pousse le raisonnement, même le montant net pourrait ne plus être à saisir, les frais, les taxes ou autres pourraient être ajoutés (calculés) par des règles pour venir définir le montant net final de l'opération.
Dans l'exemple évoqué, on pourrait considérer au moment de la saisie le "montant" comme le nb de parts x le cours d'achat et venir ajouter en sus les frais et la taxe par des règles. Ce serait plus intuitif que d'inclure les frais dans le montant et de rajouter la taxe par une règle.

Hihi en fait c'est ce que je disais, j'avais poussé le bouchon un peu loin directement :

L'utilisateur ne saisit que PU et Qté ensuite le reste lui est proposé et s'il souhaite corriger le prix total frais inclus alors il le peut et les frais lui sont automatiquement affichés (dans ce cas, on ne considère qu'une inconnue et l'on met la taxe à 0). Si au contraire il voit que les frais ou les taxes ne sont pas corrects alors il les modifie dans la même fenêtre et le prix total frais inclus est actualisé.
Donc dans le cas nominal, il y aurait même une saisie de moins : celle du prix total frais inclus puisque calculé.

Je me rends compte que ce n'était clair que dans ma tête. Mais c'est vrai qu'une fois les règles définies, la seule chose qui compte vraiment c'est combien et à quel prix. Le reste peut être calculé.

Lorsque la fonctionnalité existera chaque utilisateur fera à sa guise selon les informations dont il dispose.
Idéalement il faudrait que je rajoute en plus du choix du profil de calcul (somme de règles à appliquer), un champ pour indiquer le montant net final qu'aura l'opération après sa validation.
Néanmoins je devrais conserver la saisie du montant, par compatibilité avec l'existant mais aussi pour ceux qui ne souhaiteraient pas définir de règles et continuer à fonctionner avec les frais/taxes inclus dans le montant net saisi.
...
C'est une fonctionnalité intéressante capable de couvrir plusieurs besoins en même temps, elle fera parti des priorités après le chantier en cours (module d'aide à la décision).

Ca c'est une nouvelle qu'elle est bonne

[Jacques Leblond]

Je me rends compte que ce n'était clair que dans ma tête. Mais c'est vrai qu'une fois les règles définies, la seule chose qui compte vraiment c'est combien et à quel prix. Le reste peut être calculé.

Il y a 2 aspects de mise en oeuvre qui me gênait dans ta solution même si dans son principe, sa logique, elle est similaire à la mise en oeuvre des frais et taxes avec des règles qui viennent en complément du montant brut (Nb de parts x Cours).

• Le premier est que l'on reste avec des champs (Montant et taxe) dans le formulaire (ou alors je n'ai toujours pas compris les champs que tu imaginais), demain si une nouvelle taxe arrive en complément, je dois tout modifier (table de base de données, formulaires, contrôles).
• Le deuxième est que je n'aime pas qu'un champ puisse être calculé et/ou saisi selon des scénarios de saisie, par expérience c'est difficile à maîtriser au niveau de l'IHM et cela nécessite de faire le choix des variables "dominantes" (donc du code de conversion à faire) pour toujours considérer les mêmes variables dans les algorithmes de calcul de la performance (qui sont déjà bien complexes à gérer avec les différentes opérations sur titres existantes).

[benji791]

Tu as raison, ce sont bien des champs hybrides que j'imaginais : à la fois présentation du résultat des calculs des règles et possibilité de correction manuelle. Après je conçois que ce soit plus pénible à gérer dans le code mais je ne pense pas qu'il y ait nécessairement d'impact sur la structure des données. Je pense que seule la couche présentation devrait être impactée.
En fait cela reviendrait dans la fenêtre d'achat / vente de titres à afficher des propriétés de l'opération courante : le petit tableau de ventilation par sous-catégorie serait idéal (en plus ca serait dynamique si un jour une nouvelle taxe débarque). Au moment de valider l'opération, il faudrait juste faire la somme pour alimenter le champs frais de l'opération sur titre.
edit: en revanche, si l'on modifie le montant total de l'opération, il faut choisir sur quelle catégorie impacter

[Jacques Leblond]

Fonctionnalités ajoutées dans la version 6.2.73.6119 via la gestion des profils de calcul et de répartition.