Filemaker Pro : trucs et astuces pour les nuls

[Anonyme]

Bon nombre d'entre nous sont ou vont passer, à Filemaker Pro (..)
Ce fil sert à poser les questions, pour recevoir l'aide attendue permettant de progresser.

Je remercie d'entrée, les volontaires qui répondront aux questions posées
Longue vie à ce fil technique.
_______________________________________________________

Pour commencer, je suis à la recherche d'une formule de calcul :

En partant d'une date, obtenir le solde réel du jour (cumulé en fonction de la date du jour) entre les entrées et sorties. Recalculé dès que l'on insère une nouvelle opération après coup.

Dans ma colonne Solde je devrais avoir comme résultat :

le 12 > 1'200.00
le 13 > 600.00
le 14 > 1'500.00

Le but recherché, est de me débarrasser de iCompta.

PS : j'étais plus à l'aise avec Access :love:

 

[iluro_64]

Bon nombre d'entre nous sont ou vont passer, à Filemaker Pro (..)
Ce fil sert à poser les questions, pour recevoir l'aide attendue permettant de progresser.

Je remercie d'entrée, les volontaires qui répondront aux questions posées
Longue vie à ce fil technique.
_______________________________________________________

Pour commencer, je suis à la recherche d'une formule de calcul :

En partant d'une date, obtenir le solde réel du jour (cumulé en fonction de la date du jour) entre les entrées et sorties. Recalculé dès que l'on insère une nouvelle opération après coup.

Dans ma colonne Solde je devrais avoir comme résultat :

le 12 > 1'200.00
le 13 > 600.00
le 14 > 1'500.00

Le but recherché, est de me débarrasser de iCompta.

PS : j'étais plus à l'aise avec Access :love:

C'est avec ce problème là que l'on mesure la différence entre un tableur et un SGBD.

Une façon de résoudre ce problème consiste à écrire un petit script qui sera exécuté automatiquement chaque fois qu'une entrée ou une sortie est saisie, et qui fera ce que l'on fait avec les formules inscrites dans les cellules d'un tableur.

Le problème est de trouver l'enregistrement du solde précédent. Pour être certain de l'atteindre, lui et pas un autre, il faut que les enregistrements soient triés par date.
Ceci étant acquis, l'enregistrement précédent contient l'ancien solde.
On sélectionne alors l'enregistrement précédent
On accède alors au solde précédent que l'on copie dans une variable globale de travail.
On sélectionne l'enregistrement courant par sélection de l'enregistrement suivant.
On copie dans le solde courant le résultat du calcul du nouveau solde effectué avec la rubrique entrée (ou sortie) et l'ancien solde contenue dans la variable globale.

Cette méthode reconstitue ce qu'on fait avec les cellules d'un tableur.

 

[Anonyme]

C'est avec ce problème là que l'on mesure la différence entre un tableur et un SGBD.

Cette méthode reconstitue ce qu'on fait avec les cellules d'un tableur.

Cette méthode comme tu le dis si bien, elle fonctionne sur Excel ...
Je m'y attellerais un de ces jours ... un vrai challenge quoi
Sur mon exemple, le tri se fait bien par date

 

[iluro_64]

Cette méthode comme tu le dis si bien, elle fonctionne sur Excel ...
Je m'y attellerai prochainement un de ces jours ... un vrai challenge quoi
Sur mon exemple, le tri se fait par date

C'est pour cette raison qu'il ne faut peut-être pas toujours raisonner en "Excel" lorsqu'on veut transposer en FM Pro. Par exemple, dans le cas de ton exemple, la question se pose de l'utilité d'un solde à chaque saisie d'opération. Un solde "global" n'est-il pas suffisant ? Dans ce cas, il n'y a plus besoin de script, mais simplement des rubriques "statistiques"(total des entrées, total des sorties) et une rubrique "calcul" (solde = total des entrées - total des sorties).

 

[Dos Jones]

J'ai épinglé la discussion en importante en en-tête de ce forum…

 

[Anonyme]

C'est pour cette raison qu'il ne faut peut-être pas toujours raisonner en "Excel" lorsqu'on veut transposer en FM Pro. Par exemple, dans le cas de ton exemple, la question se pose de l'utilité d'un solde à chaque saisie d'opération. Un solde "global" n'est-il pas suffisant ? Dans ce cas, il n'y a plus besoin de script, mais simplement des rubriques "statistiques"(total des entrées, total des sorties) et une rubrique "calcul" (solde = total des entrées - total des sorties).

Si c'est pour remplacer iCompta non, je dois pouvoir contrôler les écritures et les soldes en relation avec la date d'une écriture. Bon tu me diras que pour pointer, je peux utiliser une requête qui peut être largement suffisante. Dans mon exemple, j'ai bien les totaux pour "Entrées" "Sorties" "Solde"

Les autres opérations sont claires, du moins pour moi.

PS : merci mille fois @Dos Jones pour avoir épinglé la discussion en en-tête du forum

 

[Dos Jones]

PS : merci mille fois @Dos Jones pour avoir épinglé la discussion en en-tête du forum

De rien…

Par contre en tapant "tuto programmation FileMaker" sur google on trouve des informations souvent pertinentes…

Par contre gaffe y'a un site où c'est payant et pas donné… :mouais:

 

[Anonyme]

De rien…

Par contre en tapant "tuto programmation FileMaker" sur google on trouve des informations souvent pertinentes…

Par contre gaffe y'a un site où c'est payant et pas donné… :mouais:

Merci pour ces informations, je vais fouiller un peu plus à fonds sur notre ami à tous G....e

Je fréquente le forum de Filemaker : http://forums.filemaker.com/groups/ebd6445d19/summary?lang=fr_FR
Et celui de FM Source : http://www.fmsource.com/index.php?

Payer, ben je ne suis pas prêt de le faire, c'est pour cela que je fais appel aux membres du forum qui sont en mesure de nous aider

 

[iluro_64]

c'est à peu près ça, enfin graphiquement …

Oui, ça y ressemble beaucoup
Bien sûr, la présentation graphique peut différer à volonté.
Dans le cas précis d'une compta où il y a un nombre limité de rubriques, la présentation en colonne peut être plus pratique qu'une présentation en formulaire. C'est un peu une affaire de goût.

 

[Anonyme]

pour une présentation en colonne, y a le bouton Liste
j'avais choisi le mode Fiche

ah ben t'as raison de le souligner, très utile pour les novices

Pendant qu'on y est, FM Bento avait mis en place la prise en charge des contacts qui sont dans l'application "Contacts" , cette fonction n'a pas été reportée alors que FM voudrait que les gens fassent le pas vers FMP 12. À quand la mise en relation des contacts avec l'application de FMP 12 ?

Par contre la version de Contacts dans FMP 12 est meilleure, avec en prime la liaison géotaguée en fonction de l'adresse.

 

[iluro_64]

pour une présentation en colonne, y a le bouton Liste
j'avais choisi le mode Fiche

Oui, mais cette remarque n'est pas en accord avec ma pensée. Je voulais dire que pour certaines applications, la présentation en liste est plus appropriée que la présentation en formulaire, car toute une période est visualisée, et non pas le seul enregistrement courant. Avec les écrans dont on dispose aujourd'hui, la présentation en liste a des avantages certains sur la présentation en formulaire, surtout pour ceux qui viennent d'un tableur

 

[Aliboron]

Le problème est de trouver l'enregistrement du solde précédent. Pour être certain de l'atteindre, lui et pas un autre, il faut que les enregistrements soient triés par date.
Ceci étant acquis, l'enregistrement précédent contient l'ancien solde.
On sélectionne alors l'enregistrement précédent
On accède alors au solde précédent que l'on copie dans une variable globale de travail.
On sélectionne l'enregistrement courant par sélection de l'enregistrement suivant.
On copie dans le solde courant le résultat du calcul du nouveau solde effectué avec la rubrique entrée (ou sortie) et l'ancien solde contenue dans la variable globale.

Petit grain de sel : ce raisonnement ne correspond pas à la logique d'une base de données. Le solde ne doit pas être enregistré "en dur" car rien ne dit qu'il n'y aura pas une correction, une suppression ou un ajout à un moment ou un autre.

S'il doit y avoir un solde, il doit être dynamique et se calculer à chaque interrogation. Sinon, autant en revenir aux fiches cartonnées…

Cette méthode reconstitue ce qu'on fait avec les cellules d'un tableur.

Justement non : dans un tableur, le solde est dynamique.

Bon, je dis ça mais je ne suis pas en situation d'apporter vraiment de une aide concrète dans le cas présent, n'ayant pas FileMaker (ni vraiment le temps) pour chercher LA solution. Désolé. Mais bon, faute d'avoir un solde pour chaque ligne, tu peux assez facilement, à mon avis, avoir le total général, comme il a été suggéré ci-dessus, et le compléter en ajoutant sur chaque fiche une case à cocher, ce qui permet d'avoir un deuxième total qui ne prenne en compte que les fiches dont cette case est cochée (méthode classique de pointage de compte dans les logiciels de compta et autre suivis de banque).

 

[Anonyme]

il faut penser aussi aux mobiles (les solutions FileMaker sont compatible si l'interface est adaptée pour). mieux à mon avis, c'est d'avoir plusieurs choix, si possible.

justement dit, il faut penser penser aux mobiles, encore faut-il vouloir confier ses comptes à des iDevices, chose que peu de gens vont faire, à moins de ne posséder que des iDevices.

Je voulais dire que pour certaines applications, la présentation en liste est plus appropriée que la présentation en formulaire, car toute une période est visualisée, et non pas le seul enregistrement courant. Avec les écrans dont on dispose aujourd'hui, la présentation en liste a des avantages certains sur la présentation en formulaire, surtout pour ceux qui viennent d'un tableur

Exactement, certains ont un écran de 21,5, d'autres de 24, les mieux lotis un de 27 pouces, la présentation en liste à ma faveur, format qui est utilisé dans mon 1er exemple. Par contre remplir la base ouverte peut très bien se faire depuis le formulaire. A chacun sa façon de procéder.

pour le carnet d'adresse on peut le construire à part, avec le FileMaker (d'où à mon avis, l'absence de relation avec l'application Contact de Mac, mais aussi le Calendrier, avec FileMaker on peut faire un gestionnaire de taches complet) l'exemple n'a pas été fait avec FileMaker 12.

Bel exemple en effet, reste que j'aurai aimé que Filemaker reporte cette fonction à cette base là. Payer plus cher pour avoir des fonctions en moins, n'est pas du goût de tout le monde. Là je m'attendais à voir des exemples de mises en relation.

S'il doit y avoir un solde, il doit être dynamique et se calculer à chaque interrogation. Sinon, autant en revenir aux fiches cartonnées…

Mais bon, faute d'avoir un solde pour chaque ligne, tu peux assez facilement, à mon avis, avoir le total général, comme il a été suggéré ci-dessus, et le compléter en ajoutant sur chaque fiche une case à cocher, ce qui permet d'avoir un deuxième total qui ne prenne en compte que les fiches dont cette case est cochée (méthode classique de pointage de compte dans les logiciels de compta et autre suivis de banque).

Dans cet exemple retravaillé, j'ai encore un solde relatif à chaque enregistrement, avec en bas de Solde le calcul cumulé entre les Entrées et les Sorties. La case à cocher est une excellente solution à retenir.

Il est clair qu'on ne peut pas transposer (reproduire) une feuille Excel dans une base de donnée, a part si on part d'une présentation sur 12 mois, exemple d'un budget qui suivra.

Le but de ce fil, n'est pas d'étaler notre savoir, mais plutôt d'apporter des solutions le plus simplement possible aux questions posées. Pensez aux vrais novices qui je l'espère vont nous bombarder de questions

 

[pepeye66]

Mac ou PC ? Canon ou Nikon ?
moi pour choisir entre ces questions, j'ai été voir des exemples des deux côtés. j'ai choisi le Mac parce que il était plus beau dans tous les plans (design, interface, au moindre petit détails) et pour les appareils photo, celui qui faisait les plus belles photos et qui me paraissait l'appareil le plus ergonomique.
parce que quand on connait rien, comment on peut comprendre les inconvénients et les avantages (surtout techniques) sans en être dépassé ? et puis je pense, comme certains d'autres en fait, que celui qui arrive à faire des beaux trucs fait tout le reste. donc il est plus avancé que les autres partout.

....

Eh bien voilà une réponse nulle pour les nuls !...

 

[iluro_64]

Petit grain de sel : ce raisonnement ne correspond pas à la logique d'une base de données. Le solde ne doit pas être enregistré "en dur" car rien ne dit qu'il n'y aura pas une correction, une suppression ou un ajout à un moment ou un autre.

S'il doit y avoir un solde, il doit être dynamique et se calculer à chaque interrogation. Sinon, autant en revenir aux fiches cartonnées…


Justement non : dans un tableur, le solde est dynamique.

Bon, je dis ça mais je ne suis pas en situation d'apporter vraiment de une aide concrète dans le cas présent, n'ayant pas FileMaker (ni vraiment le temps) pour chercher LA solution. Désolé. Mais bon, faute d'avoir un solde pour chaque ligne, tu peux assez facilement, à mon avis, avoir le total général, comme il a été suggéré ci-dessus, et le compléter en ajoutant sur chaque fiche une case à cocher, ce qui permet d'avoir un deuxième total qui ne prenne en compte que les fiches dont cette case est cochée (méthode classique de pointage de compte dans les logiciels de compta et autre suivis de banque).

Bonjour Aliboron. Il y avait longtemps …

Je pense que tu ne m'as pas tout à fait compris.

Dans l'exemple que j'ai donné, volontairement simplifié pour la compréhension, j'ai simplement voulu montrer qu'avec un artifice de programmation, il était possible d'avoir une mise à jour dynamique du solde courant, issu de la dernière saisie, portant donc sur le dernier enregistrement. D'accord avec toi, si l'action de mise à jour est dynamique en apparence, elle ne l'est que fugitivement, et non pas en permanence. Bien entendu, il est aussi possible, par programmation, de faire une mise à jour à partir de n'importe quel enregistrement, dans le cadre d'une correction de saisie, par exemple. Là le problème se complique car, contrairement à EXCEL qui va faire la mise à jour automatiquement sur toute la colonne solde (propriété fondamentale d'un tableur), pour faire la même chose avec une apparence dynamique il faut étendre le processus à tous les enregistrements à partir de celui qui a été modifié. Si le nombre d'enregistrement est important, cela peut prendre beaucoup de temps, car la programmation étant faite à partir d'un script, il faut passer du temps à interpréter les instructions …

C'est en partant de cet exemple que j'ai insisté sur le fait qu'on ne doit pas penser les applications de la même façon selon que l'outil est une tableur ou un SGBD. Ainsi, en partant de l'exemple proposé par Albert-r, la question qu'il faut se poser est : faut-il détailler le solde à chaque opération d'entrée ou de sortie, ou faut-il en disposer de façon globale "au bas de la page", comme le propose généralement une banque sur les relevés mis à disposition de ses clients.

Pour mémoire, je n'ai pas encore réussi à transporter la compatibilité personnelle d'EXCEL à FM PRO. Tout cela parce que, justement, je suis très attaché au solde dynamique individuel

---------- Nouveau message ajouté à 18h54 ---------- Le message précédent a été envoyé à 18h46 ----------

…

Exactement, certains ont un écran de 21,5, d'autres de 24, les mieux lotis un de 27 pouces, la présentation en liste à ma faveur, format qui est utilisé dans mon 1er exemple. Par contre remplir la base ouverte peut très bien se faire depuis le formulaire. A chacun sa façon de procéder.

J'utilise les deux façons de procéder de façon précise :
Mode liste si toutes les rubriques tiennent sur l'écran sur une même ligne
Mode formulaire si toutes les rubriques ne tiennent pas sur l'écran sur une même ligne, où si l'une des rubriques est une rubrique dite "multiévaluée".

 

[Anonyme]

et si on fait plus d'opérations (les rubriques transactions, entrées et sorties ) pour le même jour ? ça a l'air en tout cas d'un compte en banque. pour ce genre d'opération moi j'ai un app iPhone, de ma banque, qui me permet de suivre tous les opérations.

L'exemple donné peut laisser croire cela ... il n'en est rien. Reste que certains qui vont passer à FP, voudront peut-être se passer d'un logiciel de compta à payer séparément. Une association peut également utiliser un tel schéma, plusieurs entrées et sorties le même jour, le même mois.

Pour mes besoins, cela fait passé 45 ans que j'utilise la plan comptable de mon pays, adapté à mes besoins. J'ai transposé le journal dans FP, avec des listes et des formulaires.

Cela fait belle lurette que je me suis affranchi des rapprochements proposés par les banques, car quand on change de machine, cela arrive quand même de temps en temps, ils ont le culot de te (re) facturer leur logiciel (copie de Quicken) alors que c'est toujours la même version qui est (ré) installée.

 

[Anonyme]

tu as pas dit le plus important, c'est ça que tu voulais faire ?

Non, je veux alimenter un fil, amener les gens qui ont des questions à les poser.
La seule question, posée au tout début est à ranger dans la rubrique "intérêt général", n'a pas reçue de réponse satisfaisante.
Elle fera transpirer plus d'un d'entre nous.

En partant d'une date, obtenir le solde réel du jour (cumulé en fonction de la date du jour) entre les entrées et sorties.
Recalculé dès que l'on insère une nouvelle opération après coup.

Ou je n'aie pas bien saisi, un jour viendra où j'aurai trouvé la solution tout seul.
J'aurai du demander pour plus de clarté, opération après opération enregistrée(s)

 

[Anonyme]

j'ai cru que t'avais un besoin précis. je me suis donc trompé. mais bon il faut changer le titre alors et appeler ce fil, discussions générale sur filemaker et pas trucs et astuces.

bon journée.

Pourquoi changer le titre, il est explicite.
En fonction des demandes, on pourra donner des trucs, voir des astuces.

Bonne journée

 

[Anonyme]

Après coup je suis en mesure de trouver le solde réel pour chaque jour, ou mieux après chaque enregistrement

Formule utilisée

 

[pepeye66]

Pour les pros (pas assez pédagogique et basique pour les nuls) quelques vidéos:
http://www.1-more-thing.com/Tables-externes-hierarchiques-avec.html
Mais vous les connaissiez certainement.