Bonjour,

Je suis en train de galérer pour entrer dans la base OF 2.0 les données que nous avions dans notre ancien logiciel de gestion (Gestac) à l'AC Bertin (Chavenay).
J'ai beau retourner la configuration dans tous les sens, je ne peux attacher les qualifications qu'aux "Types de vols" et non aux "Avions".
Alors comment peut-on limiter un avion aux pilotes lâchés dessus lorsque le lâcher est requis (avions anciens par exemple...) ?
Idem pour les qualifications de type...
Faut-il passer par les profils ? En ce cas il faut multiplier ceux-ci...

Ai-je loupé une marche ?

Autre question :
Pour peupler la base j'écris des routines PHP qui passent les données de la base Gestac (dBase) vers la base OF via SQL.
Pour mettre ça au point j'ai installé un OF sur mon PC. Mon idée est de peupler la base sur celui-ci en construisant progressivement mon outil de conversion. Lorsqu'il sera jugé suffisant, je convertirai une dernière fois la base Gestac à jour en base OF et ferai un export complet SQL.
Comment pourrai-je alors importer cet export SQL dans le serveur hébergé ?

Merci par avance

Francis.

Bonjour,

Voici la réponse à la première question :
Dans Admin/Utilisateurs/Qualifications, tu crées une qualif appelée "Autorisé DC3"
Dans Admin/Flotte/Types d'avion, tu cliques sur l'icône loupe de la colonne Qualifications du type d'avion, et ça t'amène à la page
Flotte • Types d'avion • Qualification, où tu n'as plus qu'à valider la qualif nouvellement créée pour le type d'avion.
Répéter autant que de besoin. C'est tout, et ça marche.

Pour la 2ème question, je laisse la réponse à plus compétent !

Bienvenu chez les utilisateurs d'OF, tu verras qu'une fois paramétré, c'est le bonheur. Courage !

Sadoche
Beta testeur OF
Quiberon Air Club

Bonjour,

Le plus simple (en temps, en ressources intellectuels, en trépignements, etc.) pour convertir les données d'un logiciel quelconque vers OF, c'est de re-saisir les données à la main. En plus, cela offre un avantage énorme : vous pouvez déléguer ;-)

Vous pouvez même déléguer à plusieurs personnes !

Sinon, il n'est pas possible d'importer un dump SQL. (c'est aussi une bonne raison pour ne pas perdre de temps à faire la conversion ;-)

Christophe LARATTE
OpenFlyers manager

Bonjour,

Mort de rire ! Excellent poisson d'Avril !
Enfin j'espère ! Sinon je vais pleurer...
J'ai déjà mouliné les 300 et quelques adhérents, leurs qualifs, généré les mots de passe, les types d'avions et avions. L'idée est de reprendre plus tard une partie de l'historique des vols, disons 2 ou 3 ans (pas les 15 ans actuellement stockés en BD !)...

Il n'y a vraiment pas une possibilité ?
S'il vous plaît, dites moi que si :-))
Il semble que des exports SQL soient faits automatiquement sur votre serveur d'hébergement. Il y a bien un moyen de les restaurer je suppose !

Cordialement,

Francis

Francis GASCHET
Aéroclub Jean Bertin

Ma réponse d'utilisateur (je ne suis pas développeur OF) :

J'ai pris le parti de conserver et figer l'ancien programme (ACCM2000, sous DOS) avec toutes ses données au 31/12/07 et d'utiliser OF 2 à partir du 1er janvier, en transférant juste les "à nouveaux", c'est à dire les soldes de comptes pilotes au 1/01/08. J'ai donc une coupure franche : depuis le 1er janvier, c'est OF, avant, c'est ACCM2000. J'aurais préféré supprimer ce vieux programme (qui cependant a rendu de très bons services depuis 1997), mais je le conserve pour l'historique (et les éventuelles contestations sur les comptes passés).

La Bretagne vous envoie à tous un beau rayon de soleil printanier !

Sadoche
Beta testeur OF
Quiberon Air Club

Bonjour,

Merci.
J'ai trouvé en parallèle !
Bon, c'est un peu moins souple que ce que nous connaissions puisque tous les avions d'un même type sont soumis aux mêmes "qualifications". Et dans le cas du lâcher par exemple, ce n'est pas toujours le cas... Mais bon, ça devrait rouler !

Cordialement,

Francis GASCHET
Aéroclub Jean Bertin

Bonjour,

Cela m'étonnerait que ce soit "moins souple". Si vous voulez une gestion différente des qualifs pour chaque avion, il suffit de créer un type d'avion par avion.

Sinon, concernant le "poisson d'avril". Ce n'en n'est pas un : il n'y a pas d'import possible.

Je ne comprend pas pourquoi vous alimenter une base de données en locale. Vous pouvez très bien le faire directement sur la version en ligne. Si vous avez besoin de 2 versions en ligne, il suffit de le demander (ça c'est possible).

Christophe LARATTE
OpenFlyers manager

Bonlour,

Souplesse : peut-être le mot est-il mal choisi. En typant les qualifs (ex.: Lâcher sur tel type d'avion), je n'avais pas besoin de créer un type de qualif "Lâcher" pour chaque type. C'est la table "qualif pilotes" qui disait pour quel type le pilote est lâché ! Je duppliquais la donnée pilote et non la donnée de référence.
Chacun ses petites manies !!!

Je ne comprends pas l'intérêt de 2 versions en lignes, si le travail fait sur la version "de travail" n'est pas importable sur la version de prod.
Ce que je veux c'est importer le "tas" de données que j'ai sous dBase et pas seulement certains champs des tables "authentification" et "member" (on ne peut pas importer les dates de naissance ni d'adhésion, ni mettre à jour la date de "validité de cotisation", ni les mots de passe via l'import au format texte sdf....).
Or, je ne vois pas comment tourner du php directement sur votre serveur (ou sur ma machine en connexion avec votre BD...). Sans compter que ce php a besoin des fichiers dBase !...

Donc, si je ne peux pas importer le résultat de mes travaux et ainsi récupérer la plus grande partie de l'ancienne BD, je suis grave dans la cacaille.
D'autant que le choix d'OF s'est fait de haute lutte avec ceux qui auraient préféré un logiciel commercial... Ils ne vont pas me rater :-((

Cordialement,

Francis GASCHET
Aéroclub Jean Bertin

Bonjour,

Quel logiciel commercial ? Nous n'avons aucun concurrent qui propose ce que nous proposons (en tout cas, pas à notre connaissance). Donc je suis vraiment preneur de connaitre un logiciel du type d'OF...

Mais si le fait de ne pas être commercial inquiète, vous pouvez toujours dire à votre club, que pour utiliser OF c'est 50 € par mois ;-)

On peut même vous faire payer la TVA. D'ailleurs on va surement la faire payer à partir de 2009.

Les 2 versions en lignes c'est pour les clubs qui utilisent OF 2 en prod sur la partie résa et qui ont besoin de "murir" la mise en place des comptes etc. Une fois qu'ils sont "à point", on opère un simple basculement de base.

Je ne connais pas gestac, je ne sais pas s'il est beaucoup utilisé. Si c'est le cas, alors vous pouvez faire profiter à tout le monde de votre travail et effectivement travailler une moulinette PHP, nous fournir les sources (mais attention : il faut que ce soit du joli code bien propre !) pour les ajouter à OF. Concernant la conversion BD-Gestac vers OF, il doit y avoir possibilité d'exporter cette base dans un format texte et ensuite de l'importer via votre moulinette.

Mais je vois deux soucis :

- est-ce que la structure de la base de données de gestac est publique ? (sinon, je ne pense pas qu'on ait le droit de retraiter les données sans l'autorisation de son auteur)

- il va falloir faire coïncider les clés gestac avec les clés OF. Or nos clés sont dynamiques pour quasiment tout et notamment les qualifs. Donc le travail de coordination est énorme !

Mais franchement, je ne vois pas l'intérêt de la chose. D'accord vous aurez l'historique des vols, mais bon...

Sinon, pour les dates de naissance et la date de validité de cotisation qui ne sont dans l'import au format texte. Il suffit de demander et on fait.

Christophe LARATTE
OpenFlyers manager



Modifié 1 fois. Dernière modification le 02/04/08 20:00 par claratte.

Bonjour,

La disposition de 2 versions en ligne nous permettrait de remettre un peu d'ordre dans notre base de données ( qui a fait les frais de nos tâtonnements !).

N'y aurait-il pas une difficulté pour un basculement de base qui pourrait être lié à notre module de paiement en ligne ? si la réponse est négative, nous sommes preneurs d'une 2ème version.

Merci à vous

Bonjour,

Vous disposez déjà d'une 2ème version : acmp-2

Mais là, je ne vois pas l'intérêt : vous êtes déjà "en prod" sur les comptes pilotes (sur la base acmp). On ne peut pas synchroniser les bases : c'est soit l'une, soit l'autre.

En fait, on allait justement vous proposer de supprimer la deuxième version, car il n'y a plus d'intérêt à la garder. Cette deuxième version est là pour tester. Une fois qu'on a testé et qu'on est en prod, je ne vois pas ce qu'on peut faire avec une deuxième version...

Christophe LARATTE
OpenFlyers manager

Bonjour,

Je ne sais pas s'il y a un moyen de gérer les fils de discussion sur ce forum, et le cas échéant, comment...
Donc je fais comme je peux ! :

> Quel logiciel commercial ?
C'est Resaéro. Développé par une petite structure du sud. Un de nos membre en a fait la promotion chez nous. C'est vrai que du point de vue interface c'est très bien léché.
Mais c'est un logiciel très récent, qui arrive sur un marché dont plus de 50% a déjà opté pour OF.
Par ailleurs, la philosophie "Logiciel Libre" nous a paru plus proche de nos modes de fonctionnement à l'AC Bertin !
Quant à la TVA : je sais bien que c'est emm......, mais vous devriez la facturer pour être tranquille côté fisc.

> Les 2 versions en lignes c'est pour les clubs qui utilisent OF 2 en prod sur la partie résa et
> qui ont besoin de "murir" la mise en place des comptes etc. Une fois qu'ils sont "à point",
> on opère un simple basculement de base.
Un peu plus bas, vous dites :
> On ne peut pas synchroniser les bases : c'est soit l'une, soit l'autre.
Donc dans mon cas, ce n'est pas pertinent me semble-t-il... Et pour ce qui est des tests et de se faire la main : j'ai une version OF2 ici.

>Je ne connais pas gestac, je ne sais pas s'il est beaucoup utilisé
Il est utilisé à l'AC Bertin depuis 1985, année au cours de laquelle j'en ai terminé l'écriture.
Donc pas de problème d'autorisation de l'auteur !
Quand j'ai écrit ça (ce qui m'a pris un moment), je pensais le commercialiser... A l'époque, le concept de logiciel libre n'était pas encore connu ! Donc j'ai envoyé des disquettes de démo à tous les AC. Hé oui : les CDs étaient inconnus aussi. La pré-histoire quoi !
Il n'y en a que deux ou trois qui semblaient intéressés, parmi lesquels l'AC de Cherbourg !!!
Donc l'idée de commercialisation est tombée à l'eau et nous avons continué à l'utiliser à Bertin, avec une petite maintenance épisodique.
Mais c'est du Clipper (dBase compilé en mode DOS). Je n'ai plus assez de temps pour le ré-écrire dans un langage au goût du jour et sur une BD un peu moins archaïque; Et il y en a d'autres qui font ça très bien ! Il vaut mieux que je passe mon peu de temps disponible à les aider (si possible) plutôt qu'à faire en parallèle !
A part ça, et sans vouloir vous offusquer, je pense que Gestac à un peu d'avance concernant certains points de gestion, mais il n'incluait pas de réservation.
Sans prétention excessive,lorsque j'en aurai fini avec l'installation, je me pencherai sur la gestion technique. J'avais fait des trucs assez avancés et qui pourraient peut-être rendre service !
Il me semble en avoir parlé au téléphone avec un membre de votre équipe il y a quelques mois; peut-être Joël Tremblet...

> il doit y avoir possibilité d'exporter cette base dans un format texte et ensuite de
> l'importer via votre moulinette
Ma moulinette lit directement les tables (fichiers) dBase et peuple les tables mySQL.
Quant à la "propreté" du code, je suis tout à fait d'accord avec vous pour une moulinette "à diffuser". Dans mon cas, c'est one shot. Néanmoins, je pense écrire assez proprement !

> - il va falloir faire coïncider les clés gestac avec les clés OF. Or nos clés sont dynamiques
> pour quasiment tout et notamment les qualifs. Donc le travail de coordination est énorme !
Dynamiques : vous voulez dire que ce sont des "auto-increment" ?
Oui, j'ai vu ça. Il suffit d'enlever l'attribut "auto-increment" sur l'ID avant l'opération de conversion et de le rétablir après. Ainsi, je conserve les liens existants entre les diverses tables de Gestac (pour les nombreuses données communes entre les 2 systèmes -et donc récupérables-) lors de l'import dans mySQl. Ensuite l'auto-incrémentation continue lors des ajouts ultérieurs à partir de la dernière valeur utilisée.
Ce n'est pas énorme du tout. Quelques lignes de php par type de données et / ou tables. exemple : la table "adhérents" de Gestac peuple les tables "authentication" et "member".
Pour les qualifs c'est un peu plus coton car les vôtres ne sont pas typée et il faut donc faire une conversion des clefs. Ça concerne essentiellement les "Lâchers". Mais rien de très lourd !
Je passe plus de temps à analyser les corrélations existantes (en faisant un peu de reverse engeeniering sur la base OF) qu'à écrire le code !

Bon, en tout cas vous m'avez remis un peu de baume au coeur !

Cordialement,

Bonjour,

Résaéro n'est pas si récent que cela et il ne fait pas le quart des choses que fait OpenFlyers. De plus, il semblerait qu'il nécessite l'installation d'un client spécifique c'est à dire qu'on n'y accède pas depuis un navigateur mais depuis un logiciel installé sur chaque PC. C'est pour cela que l'interface (plutôt austère à mon goût) fait "léché". Derrière c'est un programme. Le seul truc qu'on ne fait pas : la borne tactile. Mais si cela intéresse des clubs et qu'ils sont prêts à financer son développement, alors on peut faire (c'est pas compliqué).

sinon, concernant les fonctionnalités gestac/of2, nous sommes preneur de toute idée, mais il faut bien comprendre que cela doit s'inscrire dans un contexte général de paramétrage pour chaque club. De plus, chaque développement nécessitant du temps, on préfère faire des choses qui conviennent au plus grand nombre plutôt que des "gadgets".

>Dynamiques : vous voulez dire que ce sont des "auto-increment" ?

Oui. C'est à dire qu'on ne peut pas dire à l'avance la qualif "DR400" c'est l'id 1. Cela dépend des qualifs mises en place dans chaque club et de leur ordre de création.

Cela nécessite donc une interface avant la migration qui permette à l'admin de faire le lien entre un id gestac et un id OF.

Mais vu que votre logiciel n'est pas diffusé, je ne pense pas que cela soit la peine de perdre du temps à faire une telle interface.

Si vous insistez dans votre voie (ce que je vous déconseille car vous perdez du temps (l'historique n'intéresse personne)), je peux vous faire une fleur (mais une seule) : le jour ou vous êtes prêt, vous m'envoyez votre base de données OF 2 et je l'implémente en lieu et place de la base actuelle de votre club. Mais attention : une seule fois ! Et vous vous débrouillez pour être sûr qu'il n'y ait pas de rupture d'intégrité dans la base. J'ai pas envie de passer des dizaines d'heures à débuguer des bugs qui n'existent que parce que les clés externes créées pointent dans le vide. De plus, on facturera au club cette migration spécifique au tarif de 50 € (HT).

Christophe LARATTE
OpenFlyers manager



Modifié 1 fois. Dernière modification le 04/04/08 09:49 par claratte.

Bonjour,

Je reviens tardivement sur mon dernier message ci-dessus.

Dans ce message je précisais que notre base de données avait fait les fais de nos tâtonnements, ce qui signifie que notre base de données comporte des erreurs, en l'occurence des champs "null" en lieu et place d'un cpte .

J'ai importé cette base de données et j'ai repéré les 5 ou 6 enregistrements qu'il faut corriger avec le bon ID à la place de "null".

Mais,
nous n'avons pas d'accès au serveur ( pas de coordonnées HTTP)
pas de possibilité d'exporter la BD corrigée sur le serveur

Que faut-il faire pour réparer cette base de données ?

Merci

Il faudrait me donner les enregistrements à modifier, je le ferai moi-même. J'en profiterais pour rajouter une détection permettant d'afficher une alerte dans l'interface admin permettant de faire ressortir ces enregistrements automatiquement (et ainsi d'en faire profiter d'autres clubs).

Christophe LARATTE
OpenFlyers manager

Bonjour,

Je vous ai adressé par courriel de ce jour, les enregistrements à corriger.

Merci

> Si vous insistez dans votre voie (ce que je vous déconseille car vous perdez du temps
> (l'historique n'intéresse personne)), je peux vous faire une fleur (mais une seule) : le jour ou
> vous êtes prêt, vous m'envoyez votre base de données OF 2 et je l'implémente en lieu et place
> de la base actuelle de votre club. Mais attention : une seule fois ! Et vous vous débrouillez
> pour être sûr qu'il n'y ait pas de rupture d'intégrité dans la base. J'ai pas envie de passer des
> dizaines d'heures à débuguer des bugs qui n'existent que parce que les clés externes créées
> pointent dans le vide. De plus, on facturera au club cette migration spécifique au tarif de 50
> € (HT).

Bonjour,

Je reviens vers vous car le moment approche où je serai prêt. Ça a été un peu long, because déplacements pro !
J'ai un peu galèré sur l'importation des comptes, mais ça roule.
Bon, passons sur le tar à 50 Euros ! Je suppose du moins qu'un tar de ma BD est suffisant...
Où bien dois-je faire un export SQL ? Si oui : sous OF ou sous phpmyadmin ?
Avant ça je chargerai la dernière version du repositary svn.
Ainsi, dans la mesure où OF fonctionne sans pb sur mon PC, vous ne devriez rien avoir à débuger.

Il y a des gens au club qui voudraient mettre en test pendant quelques temps pour quelques personnes (en gros, des membres du CA et quelques utilisateurs).
Ça me pose un problème, car pendant ce temps, on ne va pas saisir en double tous les vols (seules les données de ces membres seront doublées : résa sur cahier + OF et vols sur Gestac et OF). Résultat la base OF ne sera plus à jour. Il y a 2 solutions :
1- J'installe un OF sur un serveur temporaire et nous ferons l'import sur le vôtre suite au test. Pas de pb d'infrastructure : j'ai ce qu'il faut. Mais pas très cool car il me faut un serveur avec les bonnes versions (php, apache, pear...). Ça peut prendre du temps à mettre à jour.
2- Vous m'installez la BD une première fois pour le test. A la fin du test, je mouline à nouveau un import et vous me l'installez pour passer en prod.
Mais ça fait 2 fleurs !
Est-ce trop ?
Est-ce que ça monte la note à 100 Euros ? ;-)

Bonjour,

Il faut faire un export sous phpmyadmin (pas de tar direct de la base de données physique). Par contre, votre export peut être compressé en gzippé. Si votre base de données a eu beaucoup d'écritures et que les tables journal et logs sont lourdes, vous pouvez ne pas les transmettre.

Pour votre seconde demande, nous risquons d'avoir de gros problèmes de synchronisation. En effet, entre le moment où je vais vous exporter la base et le moment où vous allez me l'a ré-importer il va se passer un délai et pendant ce temps les résas auront évoluées (sans parler des données utilisateurs).

Moi, je veux bien vous le faire, mais votre solution ne me parait pas possible.

Et oui, cela monte la note à 100 euros.

Tous les clubs qui sont passés à OF 2 l'ont fait sans ces manips et cela c'est très bien passé...

Christophe LARATTE
OpenFlyers manager

Pour info lors de la toute première mise en prod de OF2.0 Beta cela c'est fait sur l'AC Granville et l'ACJP et j'ai pratiqué de la sorte :
- configuration de la base OF et teste pour validation de la config
- RAZ des bases OF et moulinette d'import pour initialisation des soldes
- les pilotes continue de saisir sur l'ancien logiciel et ceux qui voulaient pouvaient le faire sur le nouveau
- saisie sur OF des vols manquants par le responsable informatique (avec quelques volontaires, merci aux serveurs permettant le travail simultané) ainsi que des réglements et comparaison (soldes pilotes et heures de vol) pour valider la justesse du logiciel
- Une fois la stabilité obtenue arrêt programmé le jour J de l'ancien logiciel avec annonce à tous les membres
- la familiarisation a rapidement été obtenu parmi les membres

Ce travail a été réalisé durant 3 mois, mais nous avions choisi les mois de janvier, fevrier, mars moins volumineux
Vous pouvez agir de même sans faire 2 initialisations toujours risquées et un période de 15 jours à 1 mois me semble suffisante car la stabilité d'OF est maintenant acquise. Ce test ne servira qu'à familliariser (et rassurer) vos administrateurs ;-)

Joel

Bonjour,

Merci pour ces infos et idées.

Si ça ne tenait qu'à moi, on basculerait directement. J'ai assez confiance en vos travaux !

Si on procède en 2 temps : il n'y a pas de synchronisation à effectuer : les opérations continueront sur l'ancien logiciel. Donc la seconde BD serait un export complet et à jour. C'est "annule et remplace". Il y aura les résas à re-saisir et si entre temps on a démarré la gestion des potentiels, un recalage à faire pour tous les avions.

L'opération de chargement de mon export vous demande-t-elle du temps ?

Sinon, la méthode exposée par Joël semble pertinente. Mais nous ne sommes pas en Janvier !!!

Bon, on va réfléchir

OK pour l'export SQL. Je suppose que le partage de l'application entre N clubs sur votre serveur oblige à prendre quelques précautions !

Petite question technique : j'importe les montants des comptes pilotes dans la table "account_entry" avec la contrepartie dans le compte "banque" du club.
Lorsque je visualise ensuite les comptes pilotes dans OF, ça semble correct. Est-ce la bonne voie ?

Cordialement,

Francis GASCHET
Aéroclub Jean Bertin

> L'opération de chargement de mon export vous demande-t-elle du temps ?

Difficile à dire. Cela peut être rapide (15 minutes, si tout va bien) comme prendre une ou deux heures s'il y a des soucis. Ce qui nous demande surtout du temps pour le moment c'est de vous répondre ;-)

> j'importe les montants des comptes pilotes dans la table "account_entry" avec la contrepartie dans le compte "banque" du club.

account_entry, c'est des mouvements.

Les soldes sont dans balance.

Donc quand vous dites "contre-partie" vous voulez dire la deuxième partie du même mouvement (on est en partie double) ?

Quand vous dites "les montants des comptes pilotes", vous voulez dire le solde ? Dans ce cas, ce n'est pas un mouvement, mais une position, et c'est dans la table balance.

Christophe LARATTE
OpenFlyers manager

Désolé de vous faire perdre du temps.

> Les soldes sont dans balance.

J'avais d'abord essayé d'importer le montant dans le compte du membre. Il apparaissait toujours à zéro sous OF.
J'ai ensuite essayé dans balance : idem.
C'est alors que j'ai essayé dans account_entry, après avoir testé un "approvisionnement" manuel via OF. Un "approvisionnement" semblait ne jouer que sur cette table (compte membre toujours à 0 ainsi que balance après le mvt). Et miracle : les montants apparaîssent dans OF si j'importe les soldes dans cette table.

> Donc quand vous dites "contre-partie" vous voulez dire la deuxième partie du même mouvement (on est en partie double) ?
Oui, bien sûr. Et sous OF, le compte "banque" est bien débité du total des soldes.

> Quand vous dites "les montants des comptes pilotes", vous voulez dire le solde ? Dans ce cas, ce n'est pas un mouvement, mais une position, et c'est dans la table balance.
Ben je veux bien, mais d'après OF, le compte reste désespérément vide après l'import (petite poubelle à la place du montant). La table balance est bien peuplée....
Si j'effectue ensuite un "Approvisionner", seul le montant saisi apparaît. Il n'est pas ajouté à l'ancien solde. A contrario, si j'importe en partie double dans account_entry, ça marche.

Merci pour l'aide.
cdlt

Il faut que la date de la balance soit active pour que le solde ( je dirais plutot l'A nouveau) soit pris en compte.
Il n'y a pas de contre partie pour ce montant qui permet de synchroniser la compta avec OF

Pour vérifier si vos importations sont conformes à votre config d'Of laisser le flag validated à 0 et essayer de modifier un de vos enregistement par le logiciel. Si vous ni avez pas accès c'est que l'import est mal fait et si lors du ré-enregistrement les montants ne sont pas dans les mêmes comptes c'est que votre config d'OF ne correspond pas à vos importations

Rappel : cette manipulation est sensible

Joël

Bonjour,

Merci Joël.
J'avais oublié l'id de la date de balance !
En effet, je vois bien les soldes lorsque j'affiche les comptes sous OF, et si j'ajoute une somme avec "Approvisionner" le nouveau solde est bien incrémenté de cette somme. Parallèlement, le compte club correspondant est bien débité.

Par contre, avec cette méthode, je ne retrouve pas dans le compte club la contrepartie des soldes importés. Il reste à 0 jusqu'à ce que j'effectue un mouvement comme 'Approvisionner".
Est-ce que cet import sans contrepartie ne risque pas de nous poser un problème ultérieurement vis à vis de la compta ? Ne devrais-je pas débiter le compte club de la somme des soldes des comptes pilotes ?

D'autre part, pourriez-vous m'expliquer (ou m'indiquer où trouver les explications) au sujet de l'utilisation des colones "debit" et "credit" de la table account. Elles restent à 0 après un approvisionnement... Je m'attendais à ce que le compte pilote soit crédité !...
Et APPAREMMENT, le solde affiché par OF est basé sur la balance et les mouvements; pas sur le compte lui-même...

Je ne suis pas certain d'avoir compris la vérification que vous me demandez... Le seul flag "validated" que je vois est dans la table account-entry. Mais avec votre méthode, je ne touche plus cette table, et ce flag est à 0 par défaut lors de l'entrée d'un mouvement. Et comme indiqué ci-dessus, le montant du mouvement est bien ajouté au solde AFFICHÉ du bon compte pilote, mais la colonne "crédit" dudit compte n'est pas affectée.
Par "config d'OF" concernant les comptes, vous entendez "ventilation" ? Sinon, quel autre élément de config est-il concerné ?

Merci.

Cdlt

Francis GASCHET
Aéroclub Jean Bertin

Si vous avez des colonnes debit et credit dans la table acccount c'est que vos tables ne sont pas à jour car depuis la table balances elles ont disparu
Et depuis cette date de nombreuses modifs ont eu lieu

Joël

Je ne sais pas ce que vous appeler "compte club"
Dans une structure comptable il doit y avoir plusieurs "Comptes club"
Lorsque vous faite un reglement celui ci doit être debité d'un compte banque
(512XXX)
Pour les montants servant à la synchronisation (dans balance) il ne doit pas y avoir de contre partie dans OF. OF n'en a pas besoin et il ne faut pas les mettre.
OF n'est pas un logiciel de comptabilité, il gère les comptes, il automatise la facturation, simplifie la saisie, puis il permet le transfert en compta des données. Les valeurs dans OF ne sont qu'une image fidèle des comptes pilote mais la comptabilité reste dans votre logiciel spécialisé pour cela.

- Si votre compta existe ces valeurs sont déjà dedans sous la rubrique A nouveau, si vous les mettez dans OF vous aller les importer lors d'un tranfert et elle seront en double.
- Si votre compta n'existe pas et que vous en souhaitez une (voir http://www.associanet.com/docs/oblig-compta.html) il faut la créer dans un logiciel de compta et saisir le soldes de vos pilotes (mais ce n'est pas obligatoire pour OF).
Dans les deux cas la méthode la plus sur est d'éditer l'A nouveau et c'est ces valeurs qui doivent être chargées dans OF

Pour la colonne validated c'était si vous aviez rentré des mouvements en historique comme vous l'aviez exposé il y a un temps, et que nous vous avions dissuadé de faire
Donc si ce n'est pas le cas, oubliez cela et c'est mieux ainsi

Mais pour initialiser OF à partir d'une compta nous avons fait un module dispo dans Admin/Club/Import à base d'un fichier csv. En suivant cela vous n'avez pas a connaitre la structure des tables et le risque d'erreurs beaucoup plus faible

Joël

> Si vous avez des colonnes debit et credit dans la table acccount c'est que vos tables ne sont pas à jour car depuis la table balances elles ont disparu
Et depuis cette date de nombreuses modifs ont eu lieu

Bizarre. J'ai fait une mise à jour svn il y a peu. Je vais en faire une autre.
Si ces champs ne disparaîssent pas je vous en ferai part.

Cdlt,

Francis GASCHET
Aéroclub Jean Bertin

Attention avec les mises a jour SVN : nous ne faisons pas disparaitre (automatiquement) les champs. En effet, l'update est sense se faire depuis une 1.3 pas depuis une 2.0. Par contre, vous pouvez trouver la liste des modifications de champ a appliquer ici : http://wiki.openflyers.org/index.php/Table_rename_list#Here_are_the_queries_to_execute_to_update_correctly_database

Nous mettons dedans les requetes SQL a appliquer sur nos bases. Une fois ces requetes appliques, nous supprimons la requete dans la liste. C'est pourquoi, elle est presque tout le temps vide.

Par contre, si vous, vous voulez retrouver une requete, il suffit de regarder l'historique de cette page.

Christophe LARATTE
OpenFlyers manager

Merci et bon voyage !

Francis GASCHET
Aéroclub Jean Bertin

> Je ne sais pas ce que vous appeler "compte club"
> Dans une structure comptable il doit y avoir plusieurs "Comptes club"
> Lorsque vous faite un reglement celui ci doit être debité d'un compte banque
(512XXX)

Les comptes club sont bien des comptes banque (512xxxx). Pour le moment j'en ai créé 2 pour les paiements pilotes (liquide et chèque) et 2 pareils pour les passages (vente essence,..). Et les paiements les débitent bien.
Je vais relire les posts du forum "Responsable de club" : il y a des infos sur les saisies occasionnelles (bourses, etc...). Ça m'amènera peut-être à en créer d'autres.

Ma question était seulement motivée par le fait que ces colonnes ne changeaient jamais. Je craignais de mal utiliser les tables... Vos posts précédents me donnent la réponse !
Si je comprends bien, OF gère des soldes de comptes dans "balance". Ces soldes sont mis à jour au moment de l'enregistrement des mouvements en partie double dans "account-entry". Les champs dans "account" m'ont fait penser à une vraie compta, d'où ma confusion !

Quant à l'import, il provient de Gestac (fichiers dbf), qui gérait aussi les comptes pilotes, mais pas en partie double ! Ce n'est pas une compta.

Cdlt,

Francis GASCHET
Aéroclub Jean Bertin