Difference between revisions of "Talk:Account Reporting"

Jump to: navigation, search
Line 41: Line 41:
  
 
--[[User:Claratte|Christophe]] 23:41, 26 December 2005 (CET)
 
--[[User:Claratte|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)

Revision as of 21:06, 29 December 2005

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)