Salut ! J'ai un peu réfléchi à la mise en place de notes de frais sur Chorem. Je vois les notes de frais comme je les utilises actuellement: une liste de "frais". La particularité des frais, c'est qu'ils peuvent être imputé sur diverses entrées de compta. Dans le cas de Code Lutin, nous avons les variables comptables suivantes : - déplacement - ADSL - Téléphone - petit équipement - fourniture de bureau - frais postaux - divers receptions - autres On sait que chaque entrée de note de frais ne rentre que dans une de ses catégories (ou [exclusif] dans une nouvelle). Au premier jet, je m'étais basé sur la flexibilité des Wikitties (par les extensions), je me demandais s'il serait pertinent de représentater une ligne de note de frais comme constituée d'une extension principale (contenant les données immuables : date, num justif, description, mission, montant TVA, montant TTC) et ensuite, chaque type d'entrée de compta serait une extension propre (à un seul attribut : montant). Ca donnerait un modèle comme fournit en PJ : expenseAccount-extensions.png (il manque un attribut dans les extensions spécifique, qui serait le numero de compta ex: 625100 pour les frais km ou 626300 pour les frais postaux) Au final, j'ai l'impression que la souplesse que ça peut apporter (rajout d'un nouveau type d'entrée simplifiée) ne justifie pas la redondance de code/classes similaires. Je suis donc reparti sur une solution simple, qui est d'avoir une seule extension pour gérer une ligne de note de frais, dans laquelle on mettrait directement la somme et un type, correspondant à son entrée de compta, plutot que de les avoir sous forme d'extension. Ca rendrait l'utilisation plus "classique" et plus rigide. Au final, j'ai opté pour l'utilisation d'une énumération pour les types, avec pour chaque valeur un couple "Nom/NumCompta" pour distinguer le type d'entrée. Cela donne un modele comme celui en PJ: expenseAccount.png Par contre, je trouve ce système très rigide, et force à passer par le code pour ajouter un nouveau type d'entrée dans les notes de frais, et rend le tout très (trop) spécifique à notre mode de fonctionnement. -- Yannick Martel
Le Wed, 12 Mar 2014 16:20:28 +0100, Yannick Martel <martel@codelutin.com> a écrit :
Salut !
J'ai un peu réfléchi à la mise en place de notes de frais sur Chorem. Je vois les notes de frais comme je les utilises actuellement: une liste de "frais". La particularité des frais, c'est qu'ils peuvent être imputé sur diverses entrées de compta. Dans le cas de Code Lutin, nous avons les variables comptables suivantes : - déplacement - ADSL - Téléphone - petit équipement - fourniture de bureau - frais postaux - divers receptions - autres
On sait que chaque entrée de note de frais ne rentre que dans une de ses catégories (ou [exclusif] dans une nouvelle).
Au premier jet, je m'étais basé sur la flexibilité des Wikitties (par les extensions), je me demandais s'il serait pertinent de représentater une ligne de note de frais comme constituée d'une extension principale (contenant les données immuables : date, num justif, description, mission, montant TVA, montant TTC) et ensuite, chaque type d'entrée de compta serait une extension propre (à un seul attribut : montant). Ca donnerait un modèle comme fournit en PJ : expenseAccount-extensions.png (il manque un attribut dans les extensions spécifique, qui serait le numero de compta ex: 625100 pour les frais km ou 626300 pour les frais postaux)
Au final, j'ai l'impression que la souplesse que ça peut apporter (rajout d'un nouveau type d'entrée simplifiée) ne justifie pas la redondance de code/classes similaires.
Je suis donc reparti sur une solution simple, qui est d'avoir une seule extension pour gérer une ligne de note de frais, dans laquelle on mettrait directement la somme et un type, correspondant à son entrée de compta, plutot que de les avoir sous forme d'extension. Ca rendrait l'utilisation plus "classique" et plus rigide.
Au final, j'ai opté pour l'utilisation d'une énumération pour les types, avec pour chaque valeur un couple "Nom/NumCompta" pour distinguer le type d'entrée. Cela donne un modele comme celui en PJ: expenseAccount.png Par contre, je trouve ce système très rigide, et force à passer par le code pour ajouter un nouveau type d'entrée dans les notes de frais, et rend le tout très (trop) spécifique à notre mode de fonctionnement.
Salut, réponse rapide à l'arrache : - pour moi, ta string projet devrais être idéalement une quotation, au pire un projet -> rentre dans le calcul de rentabilité du projet ;) - pour le expenseAccountType, je crois qu'il faudrait plutot se replugguer sur le système de catégorie du module finance (il me semble que ça représente à peu près la même chose et que ça pourrait du coup se mutualiser, et permettre d'ajouter directement les ntoes de frais dans les tableaux de dépenses,...) - ensuite, je pense qu'on doit pouvoir mettre toutes les entrées d'une note de frais dans un truc genre le FinancialTransaction (je sais plus si c'est ça ou l'autre, mais c'est lié) pour tracer les dates de paiement). My 2 cents Jean
Le 12/03/2014 20:05, Jean Couteau a écrit :
Salut, réponse rapide à l'arrache :
Moi, ce qui me parait louche, c'est la TVA. Pour chaque dépense il faudrait le montant + la TVA or la TVA c'est pas juste une dépense comme une autre (sous forme de dépense pour un achat à l'état) ? -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le Thu, 13 Mar 2014 09:50:35 +0100, Brendan Le Ny <bleny@codelutin.com> a écrit :
Moi, ce qui me parait louche, c'est la TVA. Pour chaque dépense il faudrait le montant + la TVA or la TVA c'est pas juste une dépense comme une autre (sous forme de dépense pour un achat à l'état) ?
Hum, bonne question... J'ai toujours vu les dépenses comme une somme "Hors Taxe + Taxes". Avec quelquefois des dépenses non sujettes à la TVA. Je regarderai avec Estelle quel besoin elle a exactement de ces notes de frais, et comment elle les utilise (quel montant est répercuté où, et par la même, quid de la TVA qui entre sans doute dans des cases spéciales "l'état nous remboursera") -- Yannick Martel
Le Wed, 12 Mar 2014 20:05:38 +0100, Jean Couteau <couteau@codelutin.com> a écrit :
Salut, réponse rapide à l'arrache :
- pour moi, ta string projet devrais être idéalement une quotation, au pire un projet -> rentre dans le calcul de rentabilité du projet ;)
ça pourrait, mais je pense pas que ce soit obligatoirement le cas. Sauf si tu notes les projets pas obtenus du coup (ce qui peut avoir du sens : cela te permet de chiffrer la perte des projets avortés) Après, il me semble que dans nos modèles de notes de frais actuels, nous mettons dans la case "mission client" le nom des salons par exemple (ou alors faut juste basculer ce type d'info dans descirption)
- pour le expenseAccountType, je crois qu'il faudrait plutot se replugguer sur le système de catégorie du module finance (il me semble que ça représente à peu près la même chose et que ça pourrait du coup se mutualiser, et permettre d'ajouter directement les ntoes de frais dans les tableaux de dépenses,...)
C'est à étudier oui, j'ai pas vu cette éventualité.
- ensuite, je pense qu'on doit pouvoir mettre toutes les entrées d'une note de frais dans un truc genre le FinancialTransaction (je sais plus si c'est ça ou l'autre, mais c'est lié) pour tracer les dates de paiement).
Euh, je dirai à voir dans un second temps :p rendons pas le bouzin trop complexe des le début ! -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
Le Tue, 1 Apr 2014 14:51:54 +0200, Yannick Martel <martel@codelutin.com> a écrit :
- ensuite, je pense qu'on doit pouvoir mettre toutes les entrées d'une note de frais dans un truc genre le FinancialTransaction (je sais plus si c'est ça ou l'autre, mais c'est lié) pour tracer les dates de paiement).
Euh, je dirai à voir dans un second temps :p rendons pas le bouzin trop complexe des le début !
Il me semble que si tu prends ça + les catégories, tu as déjà plein de choses de déjà faites. Je veux pas complexifier hein, mais ça serait idiot de faire en double...
Le Tue, 1 Apr 2014 15:19:32 +0200, Jean Couteau <couteau@codelutin.com> a écrit :
Le Tue, 1 Apr 2014 14:51:54 +0200, Yannick Martel <martel@codelutin.com> a écrit :
- ensuite, je pense qu'on doit pouvoir mettre toutes les entrées d'une note de frais dans un truc genre le FinancialTransaction (je sais plus si c'est ça ou l'autre, mais c'est lié) pour tracer les dates de paiement).
Euh, je dirai à voir dans un second temps :p rendons pas le bouzin trop complexe des le début !
Il me semble que si tu prends ça + les catégories, tu as déjà plein de choses de déjà faites. Je veux pas complexifier hein, mais ça serait idiot de faire en double...
Oui c'est bien FinancialTransaction. Sauf quand dans l'état actuel, ça me parait embarqué trop de choses. Ou alors, faudra voir les entrées NdF comme des FinancialTransactions ... Ce que je veux éviter surtout, c'est de faire du "c'est un agrume orange, c'est une orange". Ca peut se ressembler sans etre la même chose, et j'aimerai au possible éviter de faire un truc hyper complexe à prendre en main juste parce que "si on enleve ça, ça et ça, et qu'on ajoute ceci et ceci, c'est pareil en fait"... Après, la grande solution, c'est revoir tout le modele Billy... -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
Hi ! Nouvelle version, incluse dans le modèle Billy. J'ai repris donc la proposition du Financial Transaction, brute. En effet, il y a moins de chose à écrire, mais je pense que ce modèle sera à revoir, pour alléger notamment car du coup, on porte des informations assez inutiles en passant par ce biais. Il faut que je regarde dans le code ou & comment sont exactement utilisées les FinancialTransaction, pour revoir le modèle et glisser sans doute des données un niveau plus bas (quit à devoir créer ce niveau entre FinancialTransaction et Invoice par exemple). Un tel modèle fera apparaître chaque lignes comme une "facture" dans l'écran de dashboard. Au niveau du dashboard "budget", chaque ligne de notes de frais sera visible dans le listing des entrées correspondant à la catégorie demandée. Concnernant le point TVA, il n'a aucune distinction : cela est fait dans le logiciel de compta. Le Wed, 12 Mar 2014 16:20:28 +0100, Yannick Martel <martel@codelutin.com> a écrit :
Salut !
J'ai un peu réfléchi à la mise en place de notes de frais sur Chorem. Je vois les notes de frais comme je les utilises actuellement: une liste de "frais". La particularité des frais, c'est qu'ils peuvent être imputé sur diverses entrées de compta. Dans le cas de Code Lutin, nous avons les variables comptables suivantes : - déplacement - ADSL - Téléphone - petit équipement - fourniture de bureau - frais postaux - divers receptions - autres
On sait que chaque entrée de note de frais ne rentre que dans une de ses catégories (ou [exclusif] dans une nouvelle).
Au premier jet, je m'étais basé sur la flexibilité des Wikitties (par les extensions), je me demandais s'il serait pertinent de représentater une ligne de note de frais comme constituée d'une extension principale (contenant les données immuables : date, num justif, description, mission, montant TVA, montant TTC) et ensuite, chaque type d'entrée de compta serait une extension propre (à un seul attribut : montant). Ca donnerait un modèle comme fournit en PJ : expenseAccount-extensions.png (il manque un attribut dans les extensions spécifique, qui serait le numero de compta ex: 625100 pour les frais km ou 626300 pour les frais postaux)
Au final, j'ai l'impression que la souplesse que ça peut apporter (rajout d'un nouveau type d'entrée simplifiée) ne justifie pas la redondance de code/classes similaires.
Je suis donc reparti sur une solution simple, qui est d'avoir une seule extension pour gérer une ligne de note de frais, dans laquelle on mettrait directement la somme et un type, correspondant à son entrée de compta, plutot que de les avoir sous forme d'extension. Ca rendrait l'utilisation plus "classique" et plus rigide.
Au final, j'ai opté pour l'utilisation d'une énumération pour les types, avec pour chaque valeur un couple "Nom/NumCompta" pour distinguer le type d'entrée. Cela donne un modele comme celui en PJ: expenseAccount.png Par contre, je trouve ce système très rigide, et force à passer par le code pour ajouter un nouveau type d'entrée dans les notes de frais, et rend le tout très (trop) spécifique à notre mode de fonctionnement.
-- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
On Thu, 3 Apr 2014 15:41:48 +0200 Yannick Martel <martel@codelutin.com> wrote:
Hi !
Salut,
Nouvelle version, incluse dans le modèle Billy.
Ca me parait pas mal
J'ai repris donc la proposition du Financial Transaction, brute. En effet, il y a moins de chose à écrire, mais je pense que ce modèle sera à revoir, pour alléger notamment car du coup, on porte des informations assez inutiles en passant par ce biais.
Il faut que je regarde dans le code ou & comment sont exactement utilisées les FinancialTransaction, pour revoir le modèle et glisser sans doute des données un niveau plus bas (quit à devoir créer ce niveau entre FinancialTransaction et Invoice par exemple).
Je ne vois pas ce que tu veux enlever à FinancialTransaction. On a besoin de tout pour une entré de note de frais. ExpenseAccount pour moi ne devrait pas etre month+year. Mais un interval entre deux dates. Car si une entreprise (ou nous même) voulons faire les notes de frais au trimestre ou à la semaine on ne peut pas. (Il ne faut pas confondre stockage et UI). Je ne suis pas sur que tu es besoins de justificationNumber et donc de ExepnseAccount (mais c pas mal d'avoir un Wikitty intermediaire entre FinancialTransaction et ExpenseAccount). Pour justificationNumber j'utiliserais simplement reference de FinancialTransaction (genre: nf-martel-201404-01) le 01 étant le numéro du justificatif, donc les suivants serait 02, 03, 04.) De plus il faut penser au attachment que l'on peut ajouter à tout Wikitty. Donc pour moi le justificatif est scanner et mis en attachment du FinancialTranscation dans le meilleur des cas. Ou alors sur chaque justificatif on a ecrit le numéro de la reference (les derniers chiffres) scanner tous les documents en meme temps et ajouter en attachment sur ExpenseAccount (est-ce bien d'avoir 2 façons de faire ? le 1er etant génial pour la traçabilité et le suivi, le deuxième étant mois gourmand en temps pour le salarié). Je ne vois pas du tout a quoi sert ExpenseClaim. J'ajouterais sur Category un champs String pour mettre le numéro de compte (pour la compta) Je pense qu'avec ca on a tout pour stocker les notes de frais. Il faut peut-être modifier ce qui est actuellement fait pour que FinancialTransaction ne soit jamais utilisé directement mais toujours avoir un Wikitty différenciant comme Invoice et ExpenseAccount pour simplifier la création de rapport.
Un tel modèle fera apparaître chaque lignes comme une "facture" dans l'écran de dashboard. Au niveau du dashboard "budget", chaque ligne de notes de frais sera visible dans le listing des entrées correspondant à la catégorie demandée.
Concnernant le point TVA, il n'a aucune distinction : cela est fait dans le logiciel de compta.
Pas vraiment mais c assez compliqué, car il y a de la TVA récupérable et non récupérable. Si tu manges tout seul c non récupérable, si tu manges avec un client c récupérable. Et on a un module TVA qui calcule la TVA a déclarer chaque mois dans Wikitty (en fonction des factures et dans le futur des notes de frais si possible). -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le Tue, 15 Apr 2014 11:03:02 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Thu, 3 Apr 2014 15:41:48 +0200 Yannick Martel <martel@codelutin.com> wrote:
Hi !
Salut,
Nouvelle version, incluse dans le modèle Billy.
Ca me parait pas mal
J'ai repris donc la proposition du Financial Transaction, brute. En effet, il y a moins de chose à écrire, mais je pense que ce modèle sera à revoir, pour alléger notamment car du coup, on porte des informations assez inutiles en passant par ce biais.
Il faut que je regarde dans le code ou & comment sont exactement utilisées les FinancialTransaction, pour revoir le modèle et glisser sans doute des données un niveau plus bas (quit à devoir créer ce niveau entre FinancialTransaction et Invoice par exemple).
Je ne vois pas ce que tu veux enlever à FinancialTransaction. On a besoin de tout pour une entré de note de frais.
Depuis j'ai mené des discussions sur l'utilisation des notes de frais, et tout est en effet utilisable :)
ExpenseAccount pour moi ne devrait pas etre month+year. Mais un interval entre deux dates. Car si une entreprise (ou nous même) voulons faire les notes de frais au trimestre ou à la semaine on ne peut pas. (Il ne faut pas confondre stockage et UI).
Pas de confusion entre les deux, c'est uniquement que je n'ai pas vu cette necessité, j'étais parti sur des notes de frais mensuelles, j'ai pas imaginé d'autres cas. Du coup, ExpenseAccount étendra Interval pour gérer la temporalité.
Je ne suis pas sur que tu es besoins de justificationNumber et donc de ExepnseAccount (mais c pas mal d'avoir un Wikitty intermediaire entre FinancialTransaction et ExpenseAccount). Pour justificationNumber j'utiliserais simplement reference de FinancialTransaction (genre: nf-martel-201404-01) le 01 étant le numéro du justificatif, donc les suivants serait 02, 03, 04.) De plus il faut penser au attachment que l'on peut ajouter à tout Wikitty. Donc pour moi le justificatif est scanner et mis en attachment du FinancialTranscation dans le meilleur des cas. Ou alors sur chaque justificatif on a ecrit le numéro de la reference (les derniers chiffres) scanner tous les documents en meme temps et ajouter en attachment sur ExpenseAccount (est-ce bien d'avoir 2 façons de faire ? le 1er etant génial pour la traçabilité et le suivi, le deuxième étant mois gourmand en temps pour le salarié).
Dans un premier temps, j'ai mis de coté l'aspect justificatif. Légalement, il me semble que l'entreprise doit posséder les originaux, donc les "sauvegarder" informatiquement n'est à mes yeux qu'un petit bonus. "justificationNumber" peut faire doublon avec "reference" déjà présent dans FinancialTransaction. Cela dépend de comment on utilise "reference" justement : est-ce une référence extérieure (comptable sur le paiement?) ou y a-t-il obligatoirement une harmonie avec le justificatif ? Je pense pas mal au final de garder les deux, si on utilise une référence comptable par exemple, elle peut être associé à plusieurs entrées de notes de frais (donc plusieurs justificatif).
Je ne vois pas du tout a quoi sert ExpenseClaim.
Honnetement, moi non plus. C'était présent, je pense ça inutilisé.
J'ajouterais sur Category un champs String pour mettre le numéro de compte (pour la compta)
C'est envisageable facilement oui.
Je pense qu'avec ca on a tout pour stocker les notes de frais. Il faut peut-être modifier ce qui est actuellement fait pour que FinancialTransaction ne soit jamais utilisé directement mais toujours avoir un Wikitty différenciant comme Invoice et ExpenseAccount pour simplifier la création de rapport.
Oui, c'est ce à quoi je songeais aussi : conserver une différenciation dans les objets pour faciliter les différents requetages. Après, au final, cela reste des factures également (frais de fonctionnement interne, frais liés au projet...). Il y a autre chose que je n'ai pas regardé, c'est la possibilité de faire le lien entre différents FinancialTransaction : en effet, il est possible d'avoir une note de frais qui est ensuite refacturée, dans ce cas là, faut-il avoir un liant entre les deux ? (la référence ?)
Concnernant le point TVA, il n'a aucune distinction : cela est fait dans le logiciel de compta.
Pas vraiment mais c assez compliqué, car il y a de la TVA récupérable et non récupérable. Si tu manges tout seul c non récupérable, si tu manges avec un client c récupérable. Et on a un module TVA qui calcule la TVA a déclarer chaque mois dans Wikitty (en fonction des factures et dans le futur des notes de frais si possible).
Je n'aurai pas cherché dans Wikitty un tel calcul :) Faudra y jeter un oeil du coup pour les TVA (je suppose que pour les factures, il se base sur FinancialTransaction#VAT ?) -- Yannick Martel
participants (4)
-
Benjamin POUSSIN -
Brendan Le Ny -
Jean Couteau -
Yannick Martel