Erreur d'import tag produit

Bonjour,
j’essaye d’importer les catégories a mes produit avec un fichier CSV, mais j’obtiens ce message d’erreur pour chaque ligne.
Quelqu’un a déjà eu ce message? et quelle solution ?

Cannot add or update a child row: a foreign key constraint fails (dolibarr/llx_categorie_product, CONSTRAINT fk_categorie_product_product_rowid FOREIGN KEY (fk_product) REFERENCES llx_product (rowid))

Merci

rebonjour,

Après quelques test je me suis rendu compte que cette erreur se produisait sur les produits qui on une référence numérique ex: 1603
j’ai donc renommé les références de mes produits en _1603. j’ai importé mes catégories produit sans erreur.

j’aimerais quand même garder mes références produits d’origine. Si quelqu’un a une idée je suis preneur.

Merci

Bonjour,

J’ai la même erreur, alors que mes références fournisseurs sont bien parfois des numéros et que je ne souhaite pas non plus les modifier (c’est le principe des références de vouloir les conserver).

Quelqu’un a t’il une solution si cela est un bug ?

Merci,

Bonjour,
je rencontre le même problème sur la version 12.0.3.
Manifestement Dolibarr n’aime pas l’import de tags/catégories sur des produits à référence purement numérique.
Si quelqu’un a une solution autre que de changer les références, je suis preneur.
Merci.
PS : j’ai décrit le bug 15459

bonjour,

Avez-vous essayé en ajoutant le préfixe ref: ou id: dans l’import ?

@Zuiko dans votre cas : "PATRON 1";"ref:007"

1 « J'aime »

Bonjour,
merci pour l’astuce @RomainDeschamps, cela fonctionne très bien avec "PATRON 1";"ref:007".
Je ne comprends pas pourquoi mais ça dépanne, le problème subsiste mais est contournable par ce moyen.
Je vais faire un commentaire sur le bug que j’ai décrit dans github.

Ca laisse l’option de travailler soit avec des identifiants de base de données ou des références pour les humains :slight_smile:

Votre référence peut changer. L’identifiant en base de données ne changera pas.

C’est pas un bug, juste une astuce à connaitre.

C’est une façon de voir mais quand on importe tout un lot de produits où sont mélangées des références alphanumériques et des références purement numériques, cela fait tout de même bizarre d’avoir des erreurs mysql sur une partie des résultats si on n’emploie pas « ref: » sur les références, la raison en est d’autant moins limpide puisque ce n’est pas mentionné dans le fichier exemple.
Personnellement je ne trouve pas cette réaction du système très propre pour l’utilisateur et je maintiens mon bug :smile:

1 « J'aime »

Je vous rejoins sur le fait que ce n’est pas clairement expliqué pour l’utilisateur. mais est ce ma seule chose dans Dolibarr ? C’est d’ailleurs pour ça que…

Mais ce n’est pas un bug, ni même un croche-patte fait aux utilisateurs, mais une vraie fonctionnalité que de faire en sorte que le fichier d’import interprète une valeur par défaut comme un identifiant à moins qu’on lui indique qu’il s’agisse d’une référence !

Et je crois que, au moins sur une partie des imports, il est possible de mélanger dans les lignes d’import des références et des identifiants en préfixant à chaque fois avec ref: ou id:.

Merci pour les bouquins, le 2ème en particulier m’intéresse en général et si en plus il y a des précisions de ce genre là sur les imports cela peut m’être précieux.
En fait j’expérimente une migration à partir d’un système propriétaire sur PC local et je me lance dans la transformation-récupération des données vers Dolibarr.
ça se passe pas trop mal grâce aux outils d’import de Dolibarr mais il y a quelques petits accrochages comme celui-là.
Par exemple, autre point, Dolibarr a accepté mes codes fournisseurs en import sans broncher mais affiche maintenant (Code fournisseur incorrect) à côté de chacun des codes quand je rentre dans chacune des fiches fournisseurs importées. Cela semble n’avoir aucune conséquence sur le fonctionnement mais c’est curieux.

et tellement d’autres sur les presque 600 pages…

Parce que le code fournisseur que vous avez importé ne correspond pas au masque de numérotation indiqué dans la configuration du module. Il s’agit juste d’une alerte.

1 « J'aime »

Bien sûr ! ça me parait évident… une fois l’info connue :slightly_smiling_face:
Merci

PS : pour les autres débutants, le masque du code fournisseur se gère dans la configuration du module tiers (où se gère également le masque du code client).
On a le choix entre les logiques Monkey Leopard et Elephant.
Il est donc important de s’en préoccuper dans le cadre de migration en provenance de logiciels différents.