03-04-2019, 11:50
Bonjour,
Si le champ adresse est vraiment unique, alors importez le aussi dans le champs "description" comme je vous l'ai suggéré (lors de l'import la colonne adresse du CSV sera utilisé 2 fois, dans l'adresse et la description).
Il y a 2 problèmes. Le premier c'est le bug qui fait que les clés sur champs "externes" (comme les adresses) soient actuellement buggées (une version de correction arrivera dans le mois je pense) ; mais c'est contournable avec mon astuce du dessus. Mais le second & principal problème c'est que vous avez 2 types de fiches (Contact & Société) qui ont tous les 2 besoin de 2 champs pour être distingués de manière unique (nom+prénom et nom+?) et que vous voulez relier, alors que le champ de formulaire pour les relations n'utilise qu'un seul champ pour chercher une fiche.
Le second problème existera encore quand j'aurai corrigé le premier, et nécessite d'améliorer l'import (et c'est là qu'on voit bien qu'écrire une moulinette ad-hoc est assez trivial, tandis qu'une interface d'import suffisamment puissante pour gérer tous les cas rencontrés devient vite très difficile). Mais si vous trouvez un champ unique pour les Sociétés alors vous vous en sortez aussi (il vous faut faire 2 imports, d'abord les Sociétés puis les Contacts, comme expliqué dans mon 1er message).
Il y a une grosse section "Développeurs" à la base du forum. Si vous avez des questions sur du code que vous n'avez pas l'intention de rendre public (parce que c'est du code très spécifique qui n'intéressera personne par exemple), allez dans la sous-section "Développeurs > Général". Pour les contributions allez dans "Développeurs > Contributions" tout simplement.
Lorsque nous avons codé l'export PDF des factures il y a 10 ans, nous avons d'abord regardé les solutions qui utilisaient du HMTL. Mais elles ne géraient pas les sauts de pages correctement ; pour les factures sur plusieurs pages on a effet besoin de pouvoir répéter l'entête des tables lors des sauts. Aussi sommes nous partis sur Latex qui avait l'avantage de fonctionner pour nos besoins. Mais il est clair qu'installer Latex (et tous les modules Latex nécessaires) est une plaie en général, et que pouvoir écrire du HTML serait une bonne chose (car c'est une connaissance plus répandue). Depuis 10 ans les bibliothèques python permettant de faire HTML=>PDF ont bien évolué, et mes collègues ont eu l'occasion sur d'autres projets de tester xhtml2pdf & wkhtlm2pdf avec succès. Il est prévu à l'avenir de faire un système de backends d'export PDF ; on pourra choisir les backends disponibles dans la configuration de Creme (chacun ayant ses dépendances) et si un backend latex est gardé (Latex permet des choses intéressantes) il ne sera pas le backend par défaut. mais je ne peut pas dire quand tout ça arrivera, car il y d'autres chantiers plus prioritaires.
Bonne journée !
Citation :Je vais essayer de trouver une colonne intéressante, et déjà copieusement remplie dans le csv.
[...]
Pourtant le tri par l'adresse aurait bougrement bien marché, vu les données dispo dans mon csv.
Si le champ adresse est vraiment unique, alors importez le aussi dans le champs "description" comme je vous l'ai suggéré (lors de l'import la colonne adresse du CSV sera utilisé 2 fois, dans l'adresse et la description).
Citation :je vais essayer de contourner provisoirement le problème, en recherchant des colonnes sans lien avec d'autres tables (origine du problème si j'ai bien compris).
Il y a 2 problèmes. Le premier c'est le bug qui fait que les clés sur champs "externes" (comme les adresses) soient actuellement buggées (une version de correction arrivera dans le mois je pense) ; mais c'est contournable avec mon astuce du dessus. Mais le second & principal problème c'est que vous avez 2 types de fiches (Contact & Société) qui ont tous les 2 besoin de 2 champs pour être distingués de manière unique (nom+prénom et nom+?) et que vous voulez relier, alors que le champ de formulaire pour les relations n'utilise qu'un seul champ pour chercher une fiche.
Le second problème existera encore quand j'aurai corrigé le premier, et nécessite d'améliorer l'import (et c'est là qu'on voit bien qu'écrire une moulinette ad-hoc est assez trivial, tandis qu'une interface d'import suffisamment puissante pour gérer tous les cas rencontrés devient vite très difficile). Mais si vous trouvez un champ unique pour les Sociétés alors vous vous en sortez aussi (il vous faut faire 2 imports, d'abord les Sociétés puis les Contacts, comme expliqué dans mon 1er message).
Citation :Y-a-t-il une section developpement dans le forum ?
Il y a une grosse section "Développeurs" à la base du forum. Si vous avez des questions sur du code que vous n'avez pas l'intention de rendre public (parce que c'est du code très spécifique qui n'intéressera personne par exemple), allez dans la sous-section "Développeurs > Général". Pour les contributions allez dans "Développeurs > Contributions" tout simplement.
Citation :PS: Pour parler développement, Je n'ai pas reussi à installer correctement Latex sur ma Mageia. En désespoir de cause, j'ai modifié le code de creme/billing/views/export.py pour remplacer la génération originale de pdf avec pdflatex, par une génération avec weasyprint. Super résultat ! C'est plus simple que Latex, car on passe par un squelette en pur html. L'empreinte dur le disque dur est négligeable par rapport à Latex & co, et c'est aussi un logiciel libre, ce qui ne crée pas d'entorse à la philosophie de Crème. Si ça peut aider quelqu'un qui rencontre une mauvaise installation de Latex sur sa machine, je lui envoie le source en attendant de savoir où le poster dans le forum.
Lorsque nous avons codé l'export PDF des factures il y a 10 ans, nous avons d'abord regardé les solutions qui utilisaient du HMTL. Mais elles ne géraient pas les sauts de pages correctement ; pour les factures sur plusieurs pages on a effet besoin de pouvoir répéter l'entête des tables lors des sauts. Aussi sommes nous partis sur Latex qui avait l'avantage de fonctionner pour nos besoins. Mais il est clair qu'installer Latex (et tous les modules Latex nécessaires) est une plaie en général, et que pouvoir écrire du HTML serait une bonne chose (car c'est une connaissance plus répandue). Depuis 10 ans les bibliothèques python permettant de faire HTML=>PDF ont bien évolué, et mes collègues ont eu l'occasion sur d'autres projets de tester xhtml2pdf & wkhtlm2pdf avec succès. Il est prévu à l'avenir de faire un système de backends d'export PDF ; on pourra choisir les backends disponibles dans la configuration de Creme (chacun ayant ses dépendances) et si un backend latex est gardé (Latex permet des choses intéressantes) il ne sera pas le backend par défaut. mais je ne peut pas dire quand tout ça arrivera, car il y d'autres chantiers plus prioritaires.
Bonne journée !