search

etalab / rncs_worker_api_entreprise

API pour récupérer et mettre à disposition les données du Répertoire National du Commerce et des Société
https://entreprise.data.gouv.fr
MIT License
23 stars 13 forks source link

Decalage suite à valeur `null` dans certains champs ? #125

Closed Samuelfaure closed 4 years ago

Samuelfaure commented 5 years ago

Mail reçu le 5 juillet 2019 :

Sur la recherche suivante :

SIREN : 321969297

"dossier_entreprise_greffe_principal": { "id": "e05d6d13-bb57-4c02-9769-c16455c0411d",

Dans la partie représentant, il y a un décalage des valeurs des champs suite à un null pour un id_representant

                "id": "57fa0e67-281b-44ec-b4c1-fae600d55847",
                "denomination": "CABINET SALUSTRO REYDEL",
                "forme_juridique": "Société par actions simplifiée",
                "siren_pm": "652044371",
                "type_representant": "P. Morale",
                "qualite": null,
                "conjoint_collab_date_fin": null,
                "id_representant": null,
                "date_derniere_modification": "36",

Idem lorsque le code_commune est null (même enregistrement)

                "adresse_code_commune": null,
                "adresse_pays": "92026",
Haelle commented 5 years ago

J'ai détecté un problème similaire avec la lib SmarterCSV côté _sirene_asapi.

S'il manque une colonne dans les lignes ça crée un décalage à l'import. Et SmarterCSV ne lève pas d'erreur ; il ne lève d'erreur que si le nombre de colonnes du header est incorrect mais rien si une des lignes de données n'a pas le bon nombre de colonnes.

J'ai regardé rapidement les options disponibles dans SmarterCSV sans succès...

@brindu FYI

brindu commented 5 years ago

A voir en effet, l'idéal serait de trouver le fichier CSV en question pour s'assurer que c'est bien la source du problème... J'ai moi aussi regardé ça sans succès jusqu'ici.

Samuelfaure commented 5 years ago

J'ai un peu fouillé la question grâce à notre exemple ici : => ag 'CABINET SALUSTRO REYDEL' => Croiser les résultats avec un grep '36' (date dernière modification décalée ici) => Trouver ce genre de lignes : (exemple ici fichier IMR_Donnees_Saisies/tc/flux/2019/01/17/3102/436/3102_436_20190117_085826_6_rep_nouveau_modifie_EVT.csv:21:3102; )

Toulouse;1981B00419;321969297;P. Morale;;;;;"CABINET SALUSTRO REYDEL";652044371;"Société par actions simplifiée";;"2 Avenue Gambetta";"Tour Eqho Paris la Defense";92066;"Courbevoie Cedex ;";"92026";"France";;;;;"commissaire aux comptes suppléant";;;;;;;;;;;;;;;;;;;;;36;2018-04-19;Modifications relatives au(x) dirigeants

A regarder de plus près on voit ce champs : ;";

Je ne sais pas si on a pris ce cas en compte (en tout cas je ne l'ai pas trouvé dans le code).

Ceci expliquerait le décalage : de mes tests, le 2eme séparateur ; est ici entre double quotes... D'ou perte d'un header sur la ligne et décalage...

Le :force_simple_split permet de ne pas avoir d'erreur mais n'empeche pas ce décalage.

Samuelfaure commented 5 years ago

J'ai fouillé un peu plus loin pour vérifier la thèse de @Haelle :

Soit un fichier output_rncs.txt contenant le output de ag 'CABINET SALUSTRO REYDEL' | grep '36'

la commande awk -F\; '{print NF-1}' output_rncs.txt renvoie le nombre de ; par ligne :

47
46
46
47
47
47

Or les headers correspondants à ces fichiers n'ont que 46 ';'...

Fichiers avec 47 ';' :

IMR_Donnees_Saisies/tc/flux/2018/04/20/3102/245/3102_245_20180420_062836_6_rep_nouveau_modifie_EVT.csv
IMR_Donnees_Saisies/tc/flux/2018/05/26/3102/271/3102_271_20180526_065933_6_rep_nouveau_modifie_EVT.csv
IMR_Donnees_Saisies/tc/flux/2019/01/17/3102/436/3102_436_20190117_085826_6_rep_nouveau_modifie_EVT.csv
IMR_Donnees_Saisies/tc/flux/2019/02/06/3102/451/3102_451_20190206_102229_6_rep_nouveau_modifie_EVT.csv

Et si on compare les headers à la ligne correspondante dans les fichiers :

Headers => Code_Postal;Ville;Code_Commune;Pays Total 4 champs

Ligne => 92066;"Courbevoie Cedex ;";"92026";"France" Total 5 champs

Un ; en trop sur la ligne.... d'ou decalage... comme par hasard à l'endroit du fameux ;"; ...

Conclusion : on a des randoms champs en trop qui se baladent....

A priori on peut tenter de traiter ça plutot facilement avec un prétraitement (sed /;\";/;/) mais c'est rageant niveau qualité des données...

brindu commented 5 years ago

Je ne suis pas un grand fan du sed, le problème vient bien de la donnée au départ.

La qualité des CSV sources étant ce qu'elle est, on a fait le choix d'utiliser le caractère ";" pour délimiter les colonnes au parsing des fichiers CSV, et je ne vois pas comment nous pourrions faire autrement puisque les conventions d'utilisation des guillemets ne sont pas respectées. Pour les quatre valeurs 92066;"Courbevoie Cedex ;";"92026";"France" les guillemets sont bien présents. Seulement ce n'est pas le cas partout, le début de cette même ligne, par exemple, le voici : 3102;Toulouse;1981B00419;321969297;P. Morale;. Là, plus de guillemets et seul le point-virgule permet de faire la séparation entre les colonnes.

On va difficilement pouvoir parser des fichiers CSV en faisant varier les règles au sein d'une même ligne.

Je ne pense pas que le sed soit la solution car nous rencontrerons le problème à chaque fois qu'il y aura un point-virgule dans la valeur d'un champ. Ex : on peut imaginer une observation qui ressemblerait à ceci : "Liquidation judiciaire ; radiée du registre", et ceci passera au travers du sed.

Je ne vois pas encore de solution en l'état, j'ai demandé à l'INPI ce qu'il en est de leur côté :