Toutes mes réponses sur les forums
-
Réponses
-
Le seul moyen vraiment blindé juridiquement d’avoir un recours contre la contestation de mauvaise foi c’est de faire signer la personne “en personne” et en présence d’au moins un témoin (de préférence 2).
Et c’est exactement ce que je suis tenu de faire, avec vérification de l’identité. J’imprime les bulletins (entre autres documents réglementaires et légaux) et le client signe en ma présence (je suis habilité et ma responsabilité peut être engagée). Les raisons : lutte anti-blanchiment et contre le financement du terrorisme.
Mais c’est en train de changer, sur certains contrats il peut signer, toujours en ma présence, mais numériquement.Mais promet moi de penser aux signatures numériques. :Smiley03:
Ah mais tu prêches un convaincu sur ce sujet. Mais je n’ai pas d’autres choix que d’aller au rythme de certaines institutions qui n’ont pas franchi le cap psychologique. En gros ce n’est pas moi qui décide si ces institutions acceptent les signatures électroniques ou pas, même si un certain lobbying est en cours.
Ceci étant dit, dans certains domaines, il existe certaines considérations juridiques, voire des vides juridiques qui ne sont pas encore tranchés. Parfois, il est nécessaire d’avoir la certitude absolue que c’est bien la personne en question qui a signé le document (avec conséquence de responsabilité pénale), et avec la signature numérique, actuellement le doute peut subsister sur les possibilités de fraude ou de se faire passer pour quelqu’un.Mais c’est en train de changer à toute vitesse.
Mais euuhhh… Ce n’était pas plus simple d’utiliser les “Bande de” ?
:Euuuh:En théorie oui, mais la réalité me rattrape parce que les changements que tu fais dans l’espacement de la trame (les cases prévues pour les chiffres) doivent s’intégrer dans le document complet et demandent de bouger les autres éléments à côté.
Au final, ça revient à adapter l’architecture du document aux contraintes de programmation, et ce n’était pas l’idée de départ.Mais laisse, j’ai mis un bouton invisible pour effectuer les conversions basées sur mon script, et du coup tant que je ne clique pas dessus à nouveau, la conversion reste conforme même si je clique sur les autres champs.
Oui, c’est du bricolage.
Les scripts de calcul se déclenchent à chaque action de l’utilisateur, contrairement aux scripts de validation.
Voir absolument L’ordre d’exécution des événements dans les champs de formulaire PDF enfin expliqué clairement :
http://abracadabrapdf.net/ressources-et-tutos/js-et-formulaires-ressources/lordre-dexecution-des-evenements-dans-les-champs-de-formulaire-pdf/Ok, je suis bien d’accord, mais le script ne fonctionne tout simplement pas quand il est placé en validation.
– Si tu comptais quand même l’utiliser, tu devrais placer ton script en script de validation, et non pas en script de calcul.
Le traitement du bulletin c’est impression papier pour signature des clients, donc aucun traitement numérique prévu derrière, d’où le fait que je me contente du bricolage.
ça ne fonctionne pas en script de validation. Aucun conversion n’est faite. Et en plus dans le formulaire complet, lorsque je coche une case par exemple, les scripts s’exécutent à nouveau (avec ou sans script en validation).
Ah ben non, fausse joie.
Dès qu’un autre champ du formulaire est activé, les scripts s’appliquent à nouveau et la mise en forme s’applique au format qui avait déjà été ajusté.Une idée?
Oui c’est pas mal, c’est une solution possible sans script.
Avant de voir ton dernier message, j’avais un peu bossé aussi dessus et j’ai réussi à le faire avec un script très “artisanal” qui fonctionne en simultané avec l’import. J’ai mis le script dans l’onglet Calcul des Propriétés de champ -> Script personnalisé, et j’ai mis les champs en lecture seule parce que si on s’amuse à cliquer dessus et à les désactiver ensuite je crois que le script s’applique de nouveau et ça change tout (voir modèle joint).
Voici la forme des scripts que j’ai mis :var A = this.getField(“mobile”).valueAsString;
var B = A.charAt(0) + ” ” + ” ” + A.charAt(1) + ” ” + ” ” + ” ” + ” ” + A.charAt(3) + ” ” + ” ” + A.charAt(4) + ” ” + ” ” + ” ” + ” ” + A.charAt(6) + ” ” + ” ” + A.charAt(7) + ” ” + ” ” + ” ” + ” ” + A.charAt(9) + ” ” + ” ” + A.charAt(10) + ” ” + ” ” + ” ” + A.charAt(12) + ” ” + ” ” + A.charAt(13);
event.target.value = B;Du coup, 2 solutions au même problème, c’est vraiment cool.
Je te remercie pour ton aide.
On va te trouver ça, mais d’abord il faudrait que tu postes une maquette avec les champs aux formats de départ (de base) et avec les champs aux formats d’arrivée bulletin).
Parce-que sans ça on ne peut rien faire.J’ai joint le formulaire de base, le fichier FDF (si nécessaire), et le bulletin (j’ai ajusté les chiffres à la main pour montrer ce que je veux obtenir, mais après l’import ils ont le même format que le fichier d’origine, et si je modifie le format d’arrivée dans les propriétés du bulletin, l’import ne se fait pas).
Que dirais tu d’une simple Action, à exécuter d’un clic depuis le panneau Actions d’Acrobat (ou depuis la barre d’icônes “Outils rapides”) ?
Oui ça me va parfaitement.
Merci pour ton aide.
Ou alors, dans le bulletin je crée un champ de formulaire par caractère (et bien positionné pour que ça corresponde à la trame de mon bulletin), et je mets un script qui va sélectionner et importer uniquement le 1er caractère de la chaine dans le 1er champ, le 2ème caractère de la chaine dans le 2ème champ, etc..
En gros il me faudrait un exemple de syntaxe, et surtout savoir où le mettre (dans l’onglet format personnalisé par exemple), et ensuite je pourrai peut-être adapter.
Mais peut-être que le faire au moment de l’import complexifie largement le travail, et dans ce cas, je peux importer dans le bulletin sous le mauvais format (comme ça, c’est fait). Ensuite j’ai des boutons (discrets, voire invisibles si on ne sait pas où les chercher), et quand je clique sur le bouton ça fait la manipulation sur les caractères comme j’ai expliqué avant.mais j’espère que le format d’arrivée est le même dans tous les bulletins…
Euh…lol…pas tous :jerisjaune:, mais je peux me contenter de ceux pour lesquels le format est identique et qui correspondent à la demande initiale.
Peut-être qu’une solution “simple” serait de séparer la chaine de caractère au niveau de chaque caractère, et de reconstruire le format final en alignant les caractères avec le bon format (le bon nombre d’espaces aux bons endroits). J’ai cru voir des scripts avec (de mémoire) chaque caractère de la chaine qui était identifiable avec un numéro.J’essaie d’illustrer mon propos :
J’ai la chaine de caractères “doremifasol” du champ “notes”, je sépare chaque caractère, donc notes(0), notes(1), notes(2), qui correspondrait à “d”, “o”, “r” etc.
Et ensuite, je les aligne (je ne connais pas la syntaxe) du genre notes(0)[espace espace]notes(1)[espace espace espace espace]notes(2) etc..– À partir de n’importe lequel des formulaires il faut faire un enregistrer-sous et nommer le nouveau formulaire : Ma-bibliotheque-de-champs.pdf (par exemple).
– Dans ce formulaire il faut formater tous les champs comme ils doivent l’être au final, en les paramétrant correctement dans l’onglet Format des Propriétés du champ.
Je dois mal me faire comprendre. J’ai un logiciel de CRM dans lequel j’ai entré tout un tas de données sur des clients, plusieurs dizaines de clients, et je ne peux pas modifier le formalisme dans ce logiciel.
J’ai la possibilité, pour chaque client, d’exporter depuis le logiciel toutes ses données dans un formulaire pdf modifiable, que j’appelle, le formulaire pdf de base et dont le texte des champs a le format des données du logiciel (donc numéro de tel sous la forme XX XX XX XX XX, et date de naissance sous la forme dd/mm/yyyy, etc.).Par ailleurs, j’ai des documents pdf différents (disons une dizaine), qui ne sont pas des formulaires (et que je n’ai pas le droit de recréer de toute pièce comme ça m’arrange), et que je devais, jusqu’à présent, imprimer et compléter au stylo (voir 1er fichier joint de mon message initial). Au lieu d’écrire à la main, j’ai mis, par dessus la trame existante, des champs de formulaire pour pouvoir entrer les données directement au clavier, mais c’est fastidieux (voir 2ème fichier joint dans mon message d’origine). Appelons ces formulaires des bulletins.
Donc j’ai pensé à importer directement les données du formulaire pdf de base, dans ces champs des bulletins. Je fais ça pour ne pas avoir à taper au clavier, pour chaque client et dans différents bulletins par client, alors que beaucoup d’informations (état civil, adresse, mobile,…) sont identiques.
Pour importer les données du formulaire de base vers le bulletin pour un client, j’ai nommé les champs du bulletin avec le même nom que les champs du formulaire de base. Pour importer les données, il faut le faire depuis un fichier FDF, d’où le fait, depuis le formulaire de base, d’exporter vers un fichier FDF.
Donc depuis le bulletin je fais “importer des données” et et je sélectionne le fichier FDF que j’ai créé à partir du formulaire de base.Le problème est que, les formats de certains champs (du formulaire de base, du fichier FDF) ne collent pas à la trame du bulletin (voir 3ème fichier joint).
Mais pour chaque client dans le logiciel, je vais exporter ses données dans un formulaire de base, mais qui n’est pas le même fichier que pour un autre client par définition (et je ne peux pas choisir le nom du fichier pour éventuellement écraser les anciennes données d’un autre client avec les nouvelles en conservant le format).
Donc ce que tu me demandes dans ton étape 2, ne me permet pas d’automatiser le process. En gros tu me dis, pour chacun de mes clients, je dois modifier à la main le format du champ pour que ça colle au bulletin. Dans ce cas, autant taper les données directement à la main dans le bulletin, dont le champ aura le bon format, et c’est ce que je veux éviter.
Ok. Et comment je fais pour modifier le format dans le formulaire d’origine? Par exemple pour le champ numéro de téléphone?
Les formulaires de base qui servent à générer les FDF ont tous le même format d’origine et la même configuration (juste pas le même contenu ni le même nom) et j’ai effectivement la main dessus pour faire ce que je veux de ce formulaire (du moment que c’est automatisé). Mais évidemment chaque formulaire PDF de base qui est généré (export automatique d’un logiciel) a le format de base.
Ce que je ne comprends pas c’est la différence entre modifier le format du formulaire PDF de base et modifier le format du formulaire final après l’import. En gros c’est comme si le formulaire final devenait un formulaire de base.
Mais je suis preneur, c’est ce qui m’intéresse, je veux modifier les formats des différents champs de façon automatique (même si cela demande plusieurs manipulations).
Merci pour ce retour.
Le fichier FDF est créé à partir d’un autre formulaire PDF (en faisant “exporter les données”).
Mais j’ai la sensation que modifier les formats dans le fichier FDF requiert les mêmes manipulations que celles qui m’intéressent, non?J’aurai à chaque fois un fichier PDF différent (même format) duquel je vais extraire les données dans un FDF (qui aura donc le même format), et duquel je vais importer les données dans différents autres formulaires PDF différents, dont celui que j’ai montré.
Une piste? Si trop complexe je ferai manuellement.
