Difference between revisions of "Talk:Account Reporting"

Revision as of 23:30, 4 January 2006

J'ai juste un (ou plus) problème métaphysique :

• Si le pilote n'a pas le droit de saisir ses règlement, il a néanmoins la possibilité de saisir le montant à se faire rembourser pour un avitaillement lors de la fermeture de son vol. Si on ne lui permet pas la saisie du montant, tel que c'est fait ça pose une erreur : le pilote a dit qu'il avait mis de l'essence/de l'huile, avant/après le vol, qu'il avait payé de sa poche (compte pilote dans la combo, intitulé à changer d'ailleurs, mais nos traducteurs trouveront mieux :) ), mais le montant est nul. On peut toujours récupérer l'exception jetée pas le script php et enregistrer une ligne (deux pour la double écriture) dans account_entry avec un montant nul pour signifier le remboursement, dont le trésorier va ensuite modifier le montant, mais ça me gêne :p
• Si le trésorier constate une anomalie dans un approvisionnement, il a la possibilité de le modifier. D'accord. Mais si il remarque une anomalie dans un remboursement avitaillement, pour le modifier il faut soit le faire resaisir par le pilote, ce qui implique qu'il a le droit checkflight ou que l'avion n'a pas redécollé, ou bien le trésorier doit modifier le vol lui-même : il lui faut donc le droit checkflight, ou déléguer au gen qui va bien.

Ce dernier point va vous embêter, vous aller dire que le trésorier doit avoir à sa disposition une interface pour modifier les remboursements avitaillement. Je veux bien, mais il ne pourra que modifier le montant, et pas supprimer le remboursement : ça demande beacoup de vérification de cas, et de modifier la ligne qui va bien dans la table fuelling ou lubricant (car soit il n'y a pas eu avitaillement du tout, dans ce cas il faut carrément supprimer la ligne, soit le pilote n'a pas payé de sa poche, et dans ce cas il faut modifier le champ fuel/lubricant_pay_type). Or le trésorier peut ne pas avoir tous les éléments en main, et décider que non il n'y a pas eu avitaillement, alors que si.

Enfin, si j'envisage très bien la possibilité de modifier le montant d'un avitaillement, je n'envisage pas du tout la possibilité de le supprimer. Si la suppression est vraiment nécessaire, il faut qu'un utilisateur ayant le droit checkflight modifie le vol en conséquence.

--Zebuline 23:55, 19 December 2005 (CET)

Mes avis :

• Il ne faut pas saisir des choses fausses (donc pas de ligne contenant 0 €)
• Le droit de saisir une quantité d'essence n'est pas lié au droit de saisir le montant à se faire rembourser :
  • Un pilote (en fait quelqu'un qui a le droit "saisir un vol") doit pouvoir saisir une quantité d'essence ajoutée à l'avion. Il s'agit d'une écriture sur le même papier que pour les heures de vols : le carnet de route.
  • Saisir un remboursement est lié à un autre papier : la compta.

Donc :

• Il faut dissocier la possibilité de saisir un vol de la possibilité de saisir un remboursement. Ou plutot, on peut avoir le droit de saisir un vol sans pour autant avoir le droit de saisir un remboursement pour soi.
• Il faut créer un droit permettant de gérer les remboursements (et donc donnant le droit d'en ajouter et d'en supprimer). Il seront par la suite validés par le trésorier comme pour les paiements.
• Il faut donc une interface spécifique à la gestion des remboursements.
• Ces derniers doivent apparaitre en italique ou autre comme pour les paiements non validés (et jusqu'à temps de la validation).

Ainsi voici la gestion de différents scénarii :

• Si le pilote n'a pas le droit de saisir ses remboursements :
  • il saisit son vol et la quantité d'essence ajoutée.
  • il dépose dans la boite aux lettres prévue à cet effet la facture d'essence
  • le secrétaire disposant du droit permettant de gérer les remboursements saisie la facture d'essence en remboursement
  • le tresorier valide la saisie
• Si le pilote a le droit de saisir ses remboursements :
  • il saisit son vol et la quantité d'essence ajoutée.
  • OF lui propose d'où vient l'essence (il dit que sa vient de l'extérieur et que c'est à rembourser sur son compte)
  • il saisit le montant de la facture d'essence
  • le trésorier valide le montant

J'ai beau chercher mais je ne vois pas où on est obligé de coller une écriture en double avec un montant nul.

Si j'ai bien compris, ce qui te gène c'est que si le trésorier annule un remboursement il faudrait que t'ailles chercher la quantité d'essence ajoutée dans l'avion et que tu la supprimes. Alors là, je t'arrête tout de suite : on s'en fout ! Ce n'est pas lié. L'écriture sur le carnet de route, n'a rien à voir avec l'écriture sur la compta ;-) Ce que je viens de dire, c'est la réalité du moment. Mais nous, on est plus malin ;-)

Donc on va rajouter un petit 0 dans les possibilités du champ FUEL_PAY_TYPE dans la table fuelling qui vaudra "Inconnu" et qui ne sera pas proposable dans les combos. Il sera utilisé pour justement "supprimer" les paiements de type 3 (Pilot) refusés par le trésorier.

Après bien sûr, on fera un système qui affichera les "Unknown" pour les gérer et puis aussi des alertes par mails pour les pilotes qui se sont vus refusés leur remboursement.

--Christophe 23:41, 26 December 2005 (CET)

Ce qui me dérangeait, c'est le fait d'avoir des écritures dans account_entry en rapport avec un remboursement essence/huile, mais qui n'ait pas de lien avec un approvisionnement dans la table fuelling ou lubricant. Mais apparemment c'est pas grave :)

Si j'ai bien compris, ce dont je doute, ça doit se passer comme ceci :

• le pilote a le droit de saisir un remboursement. Le comptable, qui valide les remboursements, en trouve un dans les remboursements en attente de validation dont la somme ne correspond pas. En admettant qu'il ne se trompe pas, que ce qu'il croit ne pas correspondre est en effet une erreur de saisie de la part du pilote, et pas un autre approvisionnement à rembourser dont il n'a pas encore la facture, il peut modifier le montant de cet approvisionnement. Sont alors modifiés les champs credit et debit de la ligne account_entry correspondante. On a toujours la double_entry dans lubricant ou fuelling.
• le pilote n'a pas le droit de saisir un remboursement. Il va renseigner les champs qui sont à sa portée dans le formulaire de fermeture de vol. Que doit-il renseigner comme moyen de paiement ? (je suis dans le cas ou il veut un remboursement) compte pilote (numéro 3), sans écriture dans account_entry ? ou bien unknown (numéro 0), et on lui grise la possibilité 3 ?
• le comptable trouve une facture dans son tas de factures à rembourser, et ne voit pas de remboursement correspondant dans la liste des remboursements à valider (on est dans le cas où le pilote a oublié de saisir son approvisionnement, ou bien n'a pas le droit de saisir de remboursement). Il en saisit un nouveau. Ce remboursement (deux lignes dans account_entry), n'aura pas de lien avec la table fuelling ou lubricant.
• problème : le comptable est allé trop vite, il a ajouté un remboursement à la main en recopiant une facture, et le pilote se rappelle qu'il a approvisionné l'avion en essence ou en huile, modifie son vol et ajoute l'approvisionnement et le remboursement. Le comptable se retrouve avec 2 remboursements pour le même approvisionnement. Peut-il en supprimer un ? (je crois qu'on a dit qu'on ne supprimait rien, pour éviter des abus de pouvoirs et des trucs qui disparaissent comme par magie) Ou faut-il que le pilote, s'il en a le droit, ou un utilisateur avec le droit checkFlight modifie le vol et change le moyen de paiment en unknown ? (ça me plait la dernière solution)

--Zebuline 20:06, 29 December 2005 (CET)

• Je ne comprend pas "On a toujours la double_entry dans lubricant ou fuelling.". Y'a qu'une ligne dans lubricant ou fuelling ? || On a un champ dans la table fuelling et la table lubricant, qui pointe sur une éventuelle double entrée dans la table acount_entry.--Zebuline 14:19, 30 December 2005 (CET)
• Si le pilote n'a pas le droit de saisir un remboursement, alors il n'a comme moyen de paiement que la cuve du club ou unknown (qu'on appelera plutot "autre").
• "le comptable trouve une facture" : on a le choix. Soit on fait comme tu dis, soit on crée également une entrée dans fuelling ou lubricant. Je préfèrerais créer une entrée...
• "problème" : d'où l'intérêt de ma préférence pour le point précédent : si le comptable saisie le remboursement, alors le pilote verra que l'essence a été rajouté quand il voudra effectuer lui-même la correction de son erreur.

Sinon pour la partie "compta", y'a deux choses : soit l'écriture de remboursement est en italique dans les comptes (=non validée) et dans ce cas elle peut être supprimée, soit elle a été validée par le comptable et elle ne peut plus être supprimée et doit faire l'objet d'une écriture de correction.

Ce qu'il faut bien voir c'est que la secrétaire peut très bien avoir le droit de saisir les remboursements (et pas les pilotes) mais que la validation se fasse par le trésorier.

Donc :

• tout pendant qu'on est en italique, on peut ajouter/modifier/supprimer les remboursements et faire la modif correspondante sur la table lubricant/fuel.
• dès que l'écriture de remboursement est validée, on ne peut plus la supprimer et dans ce cas seule une écriture comptable de correction peut être faite. Dans ce cas, il n'y a plus de lien avec la table lubricant/fuel. On est en pure compta.

Si on veut néanmoins pouvoir modifier les tables lubricant/fuel, faudrait donner la possibilité de modifier ces éléments là pour n'importe quel vol et à tout moment. Ce n'est pas très sain. Mais je ne l'exclue pas. Faudra y refléchir plus tard.

Exemples d'oublis :

• le pilote saisi son vol, oublie l'essence.
  • Si l'avion a revolé, il ne peut plus modifier son vol, donc il ne peut plus saisir l'essence. (si je me trompe tu me corriges)
  • Si l'avion n'a pas revolé, il peut modifier son vol et saisir l'essence (avec ou sans le remboursement suivant ses droits).
• Le pilote saisi son vol, oublie l'essence, la secrétaire voit son remboursement le saisit et attribue l'essence sur le vol du pilote.
  • L'avion n'a toujours pas volé, et le pilote repense à son essence : il va pour modifier son vol, et là, voit que l'essence a été rajoutée. Il ne corrige donc pas.
• Le pilote saisi son vol, oublie l'essence, la secrétaire voit son remboursement le saisit et attribue l'essence sur un autre vol que celui du pilote concerné.
  • L'avion n'a toujours pas volé, et le pilote repense à son essence : il va pour modifier son vol, et là, comme il ne voit rien, il saisit l'essence pour son vol.
  • Option A: Lors de la validation le trésorier pointe les remboursements et voit apparaitre deux fois le même montant saisi alors qu'il n'a qu'une facture. Il en supprime une. L'honneur est sauf.
  • Option B: Lors de la validation le trésorier pointe les remboursements et voit apparaitre deux fois le même montant, il est distrait et valide deux fois. L'honneur n'est pas sauf. L'erreur ne pourra alors être détectée qu'au moment du calcul du compte de résultat en fin d'année. Il y aura un écart entre :
    • d'une part, le solde total des pilotes
    • d'autre part, la différence des paiements des pilotes et des factures remboursées aux pilotes

Pour isoler l'erreur faudra pointer !

Mais je te rassure pour isoler l'erreur faut déjà faire le total des factures essences, au vu des factures. Ce type de travail, seul les assesseurs peuvent se le permettre. En général, ils ne vont pas jusque là. Donc l'erreur ne sera pas détectée et un pilote aura profité d'un remboursement indue.

:D --Christophe 01:40, 30 December 2005 (CET)

Bon alors :)

• Si le comptable trouve une facture et ne voit pas de remboursement correspondant dans la liste des remboursements à valider, deux possibilités :
  • la première : il faut modifier le vol pour ajouter directement l'approvisionnement, comme ça tous les liens sont créés : dans la table fueliing si c'est un approvisionnement essence, ou dans la table lubricant si c'est un approvisionnement huile, l'id du vol correspondant à cet approvisionnement; dans le champ qui va bien on renseigne la double entrée vers account_entry.
  • la seconde, que je préfère : un formulaire de saisie des approvisionnements côté admin : on peut avoir une liste des vols les plus récents par avion (ou du moins les 30 derniers, ça devrait suffire, avec la possibilité d'afficher les 30 suivants, si le pilote a donné la facture 6 mois après, etc.), on clique sur le vol correspondant, et on saisit un approvisionnement. Comme ça on crée tous les liens qui vont bien, et le pilote, si d'un coup il se rappelle qu'il a oublié de saisir son approvisionnement et veut le faire, voit qu'il a déjà été rajouté par le secrétaire.

Il faut bien comprendre que le point qui me dérnage le plus, c'est l'édition des liens entre les tables. Ca me dérange d'écrire des trucs dans account_entry en rapport avec un remboursement, et ne pas trouver l'approvisionnement correspondant. Pareil, saisir un approvisionnement sans trouver le vol.

Sinon j'ai un autre problème : Tu as dit que quand le comptable a validé un approvisionnement, alors on ne peut plus y toucher. Je suis d'accord. (si on doit quand même rectifer qqch, le comptable fera un virement pour rétablir les choses, avec un commentaires explicatif, mais on ne touche plus à la ligne remboursement validée). Ce qui me dérange, c'est que tant que l'avion n'a pas volé, le pilote peut modifier son vol. Il faut, si la gestion des comptes est activée et qu'on trouve au moins un remoubrsement validé, lui masquer les sous-formulaires d'approvisionnement. L'ajout d'approvisionnements oubliés se fera côté admin (si on adopte ma seconde solution). Sinon, quand une personne ayant le droit checkFlight, de la même façon, si on trouve au moins un remboursement validé, il faut masquer les sous-formulaires. C'est la condition pour garantir l'intégrité des données comptables !

--Zebuline 14:19, 30 December 2005 (CET)

Si personne ne contredit je fais comme j'ai dit :p

--Zebuline 22:30, 4 January 2006 (CET)