Aller au contenu

charled

Membres
  • Compteur de contenus

    316
  • Inscription

  • Dernière visite

À propos de charled

  • Rang
    200
  • Date de naissance 13/09/1971

Profil général

  • Genre
    Homme
  • Lieu
    Vaucluse (84), France

Profil FileMaker

  • FM
    FMPA 11
  • OS
    OSX 10.6.5
  • Certification
  • FBA
    --Non membre--
  1. Préparer document .docx pour Scribe

    Désolé, je ne savais pas que c'était quelque chose d'aussi douloureux pour toi. Je respecte ta pudeur ;-))
  2. Préparer document .docx pour Scribe

    Merci de ta réponse. Qui entraîne bien sûr d'autres questions. 1. Pourquoi tu dis que la fonction n'est pas agréable à utiliser dans Word ? 2. Il me semble que les Content controls sont nécessaires pour ScribeDocWriteValue. Si j'ai bien compris, ScribeDocSubstitute se contente de rechercher du texte et de le remplacer. Ça serait plus simple et je pense suffisant. Ex : j'ai écrit Nom dans mon .docx et je veux le faire remplacer par la valeur de table::nom_personne. Mais je n'arrive pas à le faire fonctionner. Il me dit qu'il ne trouve pas le texte demandé. Qu'est-ce que je fais pas bien ?
  3. Préparer document .docx pour Scribe

    Bonjour à tous, Je suis sous Mac (OS X Maverick) et je dois modifier une base sous FMP 11 (.fmp7) à laquelle je viens d'ajouter le plugin Scribe 1.451. Mais pour l'instant, mes tests avec Scribe ne fonctionnent pas. Quand j'essaie avec ScribeDocWriteValue, il m'annonce qu'il ne trouve pas le tag. Il faut placer des content control fields mais il semble que ça ne soit pas possible depuis une version Mac (c'est ce que précise la doc, époque Word 2007 pour PC). Quand j'essaie avec ScribeDocSubstitute, il m'indique qu'il ne trouve pas le texte demandé, en l'occurence "Nom". Quelqu'un peut-il m'expliquer comment préparer mon document Word pour que ça fonctionne ? Merci d'avance.
  4. charled

  5. Ne t'inquiète pas du mini débat, tout le monde a raison. La réponse a ta question peut être multiple : table externe, liste de valeurs, avec ou sans script… Bref, pour qu'on réponde plus clairement à ta question, il faudrait que tu sois plus précis : quelles sont les tables et les rubriques concernées par ces paires code/montants ? Pour obtenir quoi en partant de quoi. Mais avant toute chose puisque tu te définis comme débutant, connais-tu le principes de liens 1 à 1, 1 à n et n à n ? Inutile d'essayer d'aller plus loin si tu ne maîtrise pas un minimum ces concepts.
  6. En l'espèce, je plussoie…
  7. Je dirais que ça dépend. Si le code est autogénéré et ne peut être modifié, oui. Mais les système de code article peuvent être amenés à être modifiés, notamment s'ils permettent par exemple un catégorisation et qu'on veut modifier cette catégorisation. C'est pourquoi je préfère séparer. L'ID, c'est l'ID, le code article c'est autre chose.
  8. Ah, on ne peut pas te laisser continuer comme ça ;-)) Si je comprend bien ta demande, il te faut une table spécifique "produits" dans la laquelle chaque enregistrement comprend a minima un identifiant unique, un code si nécessaire, un produit ou service et le prix correspondant (ce qu'on pourrait appeler ton catalogue ou ta grille de tarifs). Bien sûr, tu créeras un modèle spécifique pour ajouter, modifier ce catalogue. Pour ce qui est de la suppression, il est souvent conseillé d'utiliser un champs actif/inactif plutôt que de supprimer des données. Ça te permet de gérer un historique et puis ça évite les problèmes de données manquantes lorsque les données sont affichées à travers un lien. Au niveau du reste de ta base, il te faut : - Table Clients - Table Factures - Table Lignes factures - et ta table Catalogue. Et tu vas relier tout ça : Clients:IdClient = Factures::RefIdClients Factures::IdFacture = Lignes facture::refIdFacture Lignes Factures::refidCatalogue = Cataogue::IdCatalogue Point important : lignes factures est essentielle. Si tu relies directement Facture à Catalogue, tu auras deux problèmes : - d'une part tu ne peux relier qu'un produit à une facture. Or, il y en a souvent plusieurs. - d'autre part, lorsque tu changes un prix dans le catalogue, il est changé dans toutes les factures y compris les anciennes. Donc, les totaux changent ce qu'il faut éviter. Lignes Factures, te permet d'avoir un enregistrement par ligne de chaque facture, reliés à la bonne facture par le num dela facture dans RefIdFacture. De plus, tu copies les données du produit choisi (intitulé, prix, code, tva…) dans la ligne de facture correspondante. Si tu changes ensuite des données dans le catalogue, les lignes de facture existantes ne sont pas modifiées. Pour cela, lorsque tu sélectionnes le produit à ajouter, tu copie chaque donnée dans une variable ($code, $intitulé, $prix…) puis tu crées la ligne de facture et tu transfères la donnée de chaque variable dans la rubrique correspondante de Ligne facture. En espérant avoir été clair… bon courage.
  9. Bonjour Et bienvenue sur ce forum. Ça, ça n'est pas forcément un soucis ;-)) J'ai cherché également ce genre de livres. Malheureusement, tous (en tous cas tous ceux que j'ai pu approcher) n'abordent jamais ou effleurent à peine cet aspect important des choses. La doc intégrée de Filemaker liste toutes les fonctions mais les exemples et explications sont souvent indigents et ne permettent pas forcément de comprendre les subtilités de certaines fonctions. Ta chance, c'est que le langage de scripting de FMP a été pensé utilisateur et est donc relativement simple à aborder. Chaque fonction généralement a un comportement par défaut qui prend en compte de manière globale un comportement. Pour en apprendre plus, il te faut te tourner vers les sites internet comme ce forum, - http://astucieux-filemaker.com/ qui propose de nombreux tutoriels et fiches astuces, - le programme officiel technet de Filemaker http://www.filemaker.fr/technet/, - http://www.1-more-thing.com/Bienvenue.html, - http://www.leblogfm.fr . Tu peux trouver au moins une base de facturation dans les exemples fournis avec FMP. Commence par l'étudier et essaye de l'adapter à ton besoin. Filemaker est "simple" mais ça ne signifie pas qu'il ne faut pas un minimum d'investissement dans son apprentissage. Bon courage.
  10. @Bruno. S Et bien justement, la base doit servir à… tout ça ! Évidemment. D'où la nécessité de pouvoir bien qualifier les contacts pour ne pas retrouver le deuxième numéro de tél dans le champs commentaires (au mieux) ou fonction "parce qu'il n'y avait pas la place ailleurs".
  11. @fabriceN J'ai envisagé aussi ce type de structure. Est-ce que ça veut dire que tous les champs (structure, nom, prénom, adresse, type de tél, tél etc) sont dans la table tiers ? Ou as-tu des tables complémentaires comme adresse, tél ?
  12. Merci pour vos réponses. C'est bien la solution de niktalop que je dois envisager car justement la plupart des infos du contact ne sont justement pas hierarchisables mais plutôt transversales. On peut avoir une personne adhérente à titre individuel et en même temps contact pour une asso amie. Ses coordonnées ne sont alors pas forcément les mêmes. On peut aussi avoir plusieurs contacts au sein d'un même service d'une grosse structure. Je suis donc sur la bonne piste. Reste effectivement à bien définir les différents contextes.
  13. Bonsoir, Une association travaillant dans le spectacle souhaite pouvoir gérer sa base de contacts. Dit comme ça, ça a l'air simple mais voilà : - il y a quatre catégories de contacts : les diffuseurs (de spectacles) les financeurs, les adhérents (de l'asso) et les partenaires (en général des assos amies). - tous peuvent être des personnes, des structures ou des personnes au sein de structures ; - les grosses structures peuvent avoir des services différents, avec éventuellement des adresses différentes, des numéros de tél attachés au service (fixe, standard) ou a des personnes, des emails attachés au service ou à des personnes… - les personnes peuvent être liées à titre perso (ex : adhérents) donc adresse, tél et email persos ou rattachés à une structure… - et bien sûr il faut pouvoir suivre l'historique des échanges (tél, email, réunions, mailing…) avec tout ce petit monde. Sachant qu'au coup par coup on doit pouvoir décider d'envoyer par ex. la newsletter à la personne ou au service, etc… - ainsi Bref, le dénominateur commun est le fait d'être un contact de l'asso mais avec quasiment autant de cas possibles qu'il y a de contacts. Donc le schéma Structures / Personnes / Liées par une Table intermédiaire Contact est un peu court. Plus ça va, plus j'imagine devoir "éclater" chaque paramètre : table structure, table personnes, table service, table adresse, table téléphone… et la table contact (qui fait le lien entre toutes) avec les liens qui vont bien entre toutes ces tables… Mais avant de monter une usine à gaz, j'aimerai avoir votre avis et vos retours d'expérience. Y-a-t'il une solution plus simple à laquelle je n'aurai pas pensé ? Comment traitez-vous ce genre de "contexte" habituellement ? D'avance merci.
  14. Lien Par Rubrique Calcul Globale : Fausse Bonne Idée ?

    Je reviens sur ce point. Vu que je n'essaie pas de faire varier mes globales mais, au contraire, que je les utilise comme constantes (Missions::g_demandeur="demandeur", Misions::g_defendeur="défendeur") la question est pourquoi elles ne prennent pas la valeur du calcul au chargement de mon enregistrement Missions ? Fabrice dit qu'il faut qu'un élément du calcul change sur la fiche courante mais le chargement de la fiche ne devrait-il pas suffire ?
  15. Lien Par Rubrique Calcul Globale : Fausse Bonne Idée ?

    Bonjour Gilles, Je répète que je n'ai jamais cherché à faire varier mes deux globales. Je les ai utilisées comme des constantes, l'une contenant "demandeur", l'autre "défendeur". J'ai juste pensé qu'en utilisant des rubriques calcul, elles garderaient automatiquement leur valeur. Ça n'est visiblement pas vrai lorsque ce sont des globales en client-serveur.
×