Re: [LibreAsso] Re: [LibreAsso] Re: [LibreAsso] Logiciel libre de gestion budgétaire

[ftourde AT april.org (François TOURDE)]

Salut.

Désolé d'insister, mais pourquoi t'évertuer à envoyer une copie en
privé et une à la liste de chacuns de tes messages ? C'est inutile, et
même gênant.

Le 14296ième jour après Epoch,
dabela écrivait:

> --- En date de : Sam 21.2.09, François TOURDE <ftourde AT april.org> a écrit :
>
>  
> Le 14296ième jour après Epoch,
>
> Question subsidiaire et qui a rien à voir : c'est qui Epoch ? (j'ai 
> peut-être pas 
> la culture qui faut !)

Epoch est la date de "naissance" de l'horloge d'un système Unix. Elle
a été fixée au 1er janvier 1970 (cf. http://fr.wikipedia.org/wiki/Epoch).

> Le problème que çà pose c'est qu'il y a un bien un moment disons "premier" 
> de production
> de l'info. Dans la réalité du travail de ce type de logiciels de gestion, 
> il y a bien un module
> dans lequel on crée l'info. Exemple tiré de l'expérience : dans les 
> associations d'aide à domicile
> on saisit le planning des intervenants, une fois validé (l'intervention a 
> bien eu lieu); cette 
> information passe à la fois au module facturation et à la compta (clients)
>
> Est-ce que celà veut dire qu'il faille structurer les données de
> telle ou telle façon, je ne saurais dire ?

Disons que d'après moi, il faut ouvrir le plus possible, c'est à dire
par exemple publier la structure "interne" des données, avec leurs
contraintes de modifications si nécessaire, publier les modèles
d'échanges de données, et aussi publier les modèles d'échanges de
services entre logiciels.

Si on hiérarchise d'une façon ou d'une autre les logiciels, alors on
va "fermer" leurs possibilités et l'usage qui peut en être fait.

> Est-ce que l'on peut voir des possibilité de transfert entre modules sur 
> commande ?
> Exemple : la paie est prête pour le mois m, on lance par une commande, le 
> transfert 
> des écritures de paie dans la compta. C'est classique mais çà marche très 
> bien.

Je ne comprends pas bien ce que tu entends par "est-ce qu'on peut
voir", mais si c'est "serait il possible que ça fonctionne comme ça",
alors ma réponse est "oui, mais pas que..."

Je préfèrerais que le logiciel de paye te dise directement: "Après
consultation de la base des payes, il semble que les données ne soient
pas encore prêtes", et plus tard: "Le module de paye m'a informé que
les données sont disponibles. Vous pouvez les intégrer".

C'est clair que ça évite le coup de fil de la compta à la paye "Dis
moi, tu peux m'envoyer par mail les données de la paye, que je puisse
les intégrer, mais pas dans le format de l'autre fois, ça marche pas."

> Je suis d'accord. Transférer "toutes" les écritures de l'année écoulée pour 
> réaliser un budget prévisionnel n'est peut-être pas pertinent mais être en 
> mesure 
> de se servir d'un état de synthèse que l'on pourrait nommer suivi 
> budget/réalisé
> pour établir le BP semble utile. En réalité, les dirigeants associatifs que 
> je connais
> procèdent grosso modo de cette manière.

Dans Budgest, tu as effectivement ce fonctionnement. L'écran de saisie
des budgets présente le réalisé Y-1, le budget Y-1, le réalisé Y2Date
et l'écart de ce dernier réalisé avec le budget précédent (réduit à la
date).

Mais cela nécessite de ma part l'importation de l'ensemble des
écritures comptables, ou au moins une "balance" Y-1 et une "balance"
Y2Date (je crois que c'est le terme consacré).

J'aurais préféré que le logiciel aille directement chercher
l'information, mais ce n'est que partie remise :)