Bonjour,
Je cherche une méthode simple pour importer un fichier csv organisé de la façon suivante:
Société, Adresse Facturation, Adresse Livraison, Nom contact, Prénom contact, Téléphone,Fax,....
Dans le fichier csv la société S a 2 adresses, et un ou 2 contacts par adresse:
S,AF1,AL1,N1,P1,T1,F1,...
S,AF2,AL2,N2,P2,T2,F2,...
S,AF2,AL2,N3,P3,T2,F2,...
Le résultat recherché est l'obtention dans la liste des sociétés de 2 fiches pour la société S avec une adresse différente par fiche, et un lien "emploie-salarié de" entre la première occurence S et le contact N1, et 2 liens "emploie-salarié de" entre la 2e occurence et les contacts N2 et N3.
En ignorant le mode mise à jour, l'import du fichier dans "sociétés" crée des doublons (3 lignes pour S), et génère des erreurs d'importation quand on cherche à créer des fiches contact grâce à une relation "emploie-salarié de". Je n'ai pas bien compris pourquoi.
En important avec mode mise à jour actif sur les champs nom,adresse facturation,adresse livraison, les 3 lignes société fusionnent en une seule, alors que les champs clés ont des valeurs différentes. A part le champs nom, on dirait que le CRM se fiche des autres clés cochées.
Dans une autre tentative, qui utilise l'import du fichier csv dans un contexte contacts, en ignorant le mode mise à jour, et après suppression des sociétés dans la base (corbeille vidée), avec la création de fiche activée et le lien "emploie-salarié de" documenté, on obtient bien les 3 contacts, mais une seule fiche société est créée, et les 3 liens "emploie-salarié de" pointent sur elle. J'enrage !
Ma question est comment arriver au résultat recherché sans modifier le fichier csv (en rendant le nom de la société unique, genre S1,S2), qui n'est pas très agréable pour l'exploitation du nom de la société dans le courrier ? D'autant plus qu'il y a 1700 lignes dans le csv, et plein de sociétés avec des succursales !
Bref! Comment ventiler des contacts sur plusieurs adresses d'un même nom de société?
Je pense que ce problème est habituel, avec des sociétés disposant d'une même enseigne, mais à des adresses différentes, et des contacts distincts liés aux adresses.
Merci d'avance pour toute aide sur le sujet.
Bonjour,
Il semble en effet y avoir un souci lorsque pour la clé de mise à jour on utilise des champs qui sont des liens vers d'autres tables (les adresses dans votre cas) ; je vais regarder ça afin de corriger ce problème. Cependant dans votre exemple le numéro de téléphone semble pouvoir être utilisé en tant que second champ en plus du nom (mais il faut qu'il soit renseigné évidemment).
Il n'est pas actuellement possible de créer à la volée des contacts avec leur nom & prénom lors d'un import d'organisations ; en effet on choisit un seul champ lorsqu'on recherche/créé la fiche reliée, donc si vous créez des contacts ils n'auront que leur nom (*). Donc plusieurs solutions possibles :
1. si vos contacts ont un nom unique, vous pouvez d'abord faire un import de contacts (avec leur nom & prénom évidemment) puis faire un import de sociétés en cherchant les contacts reliés par leur nom.
2.si toutes vos sociétés ont un champ unique toujours renseigné (numéro de téléphone, SIRET...), faites d'abord l'import de sociétés puis celui des contacts. Si le champ unique que vous avez est l'adresse, vous pouvez contourner le bug du début en stockant par exemple l'adresse aussi dans le champ "description" (et faire la recherche des sociétés via ce champ lorsque vous importez les contacts).
Si aucune de ces solutions ne fonctionne pour vous, restera soit l'amélioration du code de l'import, soit des changements dans le CSV, soit l'écriture d'une moulinette spécifique (il y a un squelette dans le fichier creme/creme_core/management/base.py)
Bonne soirée !
(*) il faudrait donc complexifier encore l'interface d'import pour les relations, et pouvoir gérer plusieurs champs, avec chacun un choix d'une colonne ; voire pouvoir chercher seulement sur certains champs et créer en utilisant d'autres champ en plus etc...
Merci beaucoup pour la réponse.
Il me semblait bien que quelque chose ne correspondait pas à l'idée qu'on se fait en lisant la documentation.
J'aurais dû poser la question sur le forum plus tôt, au lieu de rester dans mon coin à perdre du temps à faire plein d'essais, pensant que l'erreur venait de moi, et que j'étais incapable de lire une doc.
Maintenant que votre message me rassure sur mes capacités d'analyse, 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).
J'ai vite fait un essai pour confirmer. J'ai essayé la colonne SIREN avec des numéros bidon, ça marche !
Malheureusement, mon fichier csv ne contient pas de SIREN pour l'instant.
Je vais essayer de trouver une colonne intéressante, et déjà copieusement remplie dans le csv.
Vous avez dit numéro de téléphone ? C'est une excellente suggestion. Je vérifié ç demain.
Pourtant le tri par l'adresse aurait bougrement bien marché, vu les données dispo dans mon csv.
Sinon, je vais aussi mettre le nez sous le capot !
creme/creme_core/management/base.py avez-vous dit ?
Alea jacta est !
Y-a-t-il une section developpement dans le forum ?
Merci pour l'aide.
Bonne soirée !
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.
Bonjour,
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 !
|
