Non conformité avec le standard scdl -Délibération

[spelhate]

En procédant à une extration des délibérations sur l'année 2022 et en testant la validation de l'extraction avec les outils fournis par Etalab et Opendatafrance validata.fr, on obtient de nombreuses erreurs sur deux champs :

• Code SIRET de la collectivité COLL_SIRET -> le code n'est pas composé de 14 charactères
• Nom de matière DELIB_MATIERE_NOM -> Incohérence entre le code DELIB_MATIERE_CODE et le libellé présent dans ce champ. Exemple, au lieu d'avoir Finances locales/Suvbentions, on a Subventions

Le schéma est dispo ici: https://schema.data.gouv.fr/schemas/scdl/deliberations/2.1.3/schema.json

[clemoigno]

@spelhate

Problème 1 En effet y a un petit bug sur les code siret. En fait le siret c'est siren + nic. Et parfois (souvent) le nic commence par '000'. Et comme on traite nic en number, lorsque l'on fait concat siren+nic avec les valeurs 213501166 et 00010, on se retrouve non pas avec 21350116600010 (14 char) mais avec 21350116610 (11 char).

Problème 2 Les données DELIB_MATIERE_NOM et DELIB_MATIERE_CODE viennent directement de la configuration de Pastell en amont. A voir donc s'il faut modifier de la nomenclature conf Pastell (et si c'est possible) ou s'il faut mettre en place un mapping.

[clemoigno]

 "name": "DELIB_MATIERE_CODE",
  "type": "string",
  "title": "Code de matière issu de la nomenclature ACTES",
  "description": "Ce code correspond à celui de l'indexation de niveau 2 dans la structure arborescente de classement en matières et sous-matières (5 niveaux de profondeur) de la nomenclature ACTES (Aide au Contrôle de légaliTé dématErialiSé). Les codes de matière peuvent contenir les valeurs suivantes : '1.1' à '1.7',  '2.1' à '2.3', '3.1' à '3.6', '4.1' à '4.5', '5.1' à '5.8', '6.1' à '6.5', '7.1' à '7.10', '8.1' à 8.9', '9.1' à '9.4'. Si le champ est renseigné, sa valeur doit correspondre au nom de matière de `DELIB_MATIERE_NOM`.",
  "example": "8.4",
  "constraints": {
    "required": true,
    "pattern": "^\\d\\.\\d{1,2}$"
  }
},
{
  "name": "DELIB_MATIERE_NOM",
  "type": "string",
  "title": "Nom de matière",
  "description": "Ce nom peut être issu de la nomenclature ACTES ou d'un référentiel propre à la collectivité. S'il est issu de la nomenclature ACTES, le champ `DELIB_MATIERE_CODE` doit être renseigné avec une valeur qui représente effectivement la matière définie. Le nom est alors composé de l'intitulé de matière de niveau 1 suivi de l'intitulé de sous-matière de niveau 2 présents dans la [structure arborescente de classement de la nomenclature ACTES](http://www.moselle.gouv.fr/content/download/1107/7994/file/nomenclature.pdf) (Aide au Contrôle de légaliTé dématErialiSé). Les deux intitulés sont exprimés en minuscules accentuées, sans virgule ni parenthèse, et séparés par une barre oblique. S'il est issu d'un référentiel de thèmes propre à la collectivité, le nom de matière est alors une chaîne de caractères libre et sans contrainte particulière.",
  "example": "'domaines de compétences par thèmes/aménagement du territoire' pour un nom de matière issu de ACTES ou 'URBANISME' pour un nom de matière issu d'un référentiel propre à la collectivité",
  "constraints": {
    "required": true
  }

[yguenneugues]

Problème 1 corrigé en preprod : taille COLL_SIRET corrigé en preprod, il sera nécessaire de mettre la même version d'apache SOLR en prod que en preprod sinon nous avons un comportement différent

Probleme 2 non corrigé

[spelhate]

Merci @yguenneugues

[clemoigno]

Vu avec @ElodieTessier et @fredericlerochais on a également un souci avec ces champs lorsque la donnée vient de Webdelib. Dans ce cas, le code est présent mais le libellé est vide, ce qui pose problème. L'intégration de la table 'officielle' des libellé directement dans l'outil devrait permettre de traiter également ce problème (sous réserve qu'a minima le code passé soit correct).