Caro @jenkin eccolo qui https://github.com/ondata/appaltipop/blob/master/data/download.jsonl

Per te è ok??

Lo considero un bug, perché se non ci sono redflags associate a un appalto mi sembra più giusto che ci sia un array vuoto, non un valore null.

L'attributo startDate è richiesto dallo schema, se non presente o se valorizzato a null viene scartato e non indicizzato in ES.

In questo momento la pagina dei download mostra il contenuto dell'indice dei download (quasi) come da mockup.

Mi sono però reso conto di una serie di problemi dell'implementazione attuale e ne propongo un'altra in #56 .

Caro Ale,
per Milano, nel file source hai la gara di sotto, associata al nome "COMUNE DI MILANO - AREA POLITICHE PER L'AFFITTO E VALORIZZAZIONE SOCIALE SPAZI".

Nel rendering salta l'apostrofo in L'AFFITTO.

Di base è un nome sbagliato, perché sarà Comune di Milano, ma probabilmente ci sono da gestire nomi di comune con apostrofo.

{"ocds:releases\/0\/id":"Z6C2702E9C","ocds:releases\/0\/tender\/title":"RICOVERO DI PERSONE RIMASTE SENZA TETTO - AUTORIZZAZIONI P.G. 0468011\/18-0485443\/18-0517874\/18","ocds:releases\/0\/tender\/procurementMethodDetails":"23-AFFIDAMENTO DIRETTO","ocds:releases\/0\/tender\/contractPeriod\/startDate":"2018-10-18T09:30:00.000Z","ocds:releases\/0\/tender\/contractPeriod\/endDate":"2018-11-24T09:30:00.000Z","ocds:releases\/0\/awards\/0\/value\/amount":2100.12,"ocds:releases\/0\/contracts\/0\/implementation\/transactions\/0\/value\/amount":2100.0,"appaltipop:releases\/0\/tender\/participants\/total":1,"appaltipop:releases\/0\/participants\/total":6526,"appaltipop:releases\/0\/participants\/mean":2.13,"appaltipop:releases\/0\/suppliers":[{"ocds:releases\/0\/parties\/0\/id":"S-IT-CF-07005650960","ocds:releases\/0\/parties\/0\/name":"HOTEL VIRGILIO S.R.L.","appaltipop:releases\/0\/supplier\/amountByBuyers\/total":6778.24,"appaltipop:releases\/0\/supplier\/tendersByBuyers\/total":8}],"appaltipop:releases\/0\/redflags":[{"appaltipop:releases\/0\/redflag\/code":"03","appaltipop:releases\/0\/redflag\/description":"Questa gara presenta un solo offerente"}],"appaltipop:releases\/0\/buyers":[{"ocds:releases\/0\/buyer\/id":"IT-CF-01199250158","ocds:releases\/0\/buyer\/name":"COMUNE DI MILANO - AREA POLITICHE PER L'AFFITTO E VALORIZZAZIONE SOCIALE SPAZI"}]}

@patrunomeister giusto per essere sicuro che te ne accorgi, ho spostato i tuoi file json/report_*.json nella sotto-cartella json/tenders/ perché a breve ci sarà anche una cartella json/buyers/

Ecco un esempio di appalto che presenta più volte lo stesso aggiudicatario: https://dev.appaltipop.it/it/tender/Z3F2A2D3F7 (4 volte la "SPAZIO APERTO SERVIZI Società Cooperativa onlus").

Il problema è nei dati, stesso supplier ripetuto 4 volte con cifre sempre diverse.

Rilasciata il 18 giugno: https://www.elastic.co/guide/en/elasticsearch/reference/7.8/release-notes-7.8.0.html

A volte capitano casi come questo. Ad esempio su file aggiudicatari.csv (Prato)

Al momento li tolgo io, ma intanto segnalo la cosa a @aborruso

Tra i buyer risulta esserci solo il "COMUNE DI MILANO - AREA AMBIENTE ED ENERGIA": https://dev.appaltipop.it/it/buyers.

In realtà nei tender risultano molti uffici del comune di milano, con nomi sempre diversi, ma sempre lo stesso codice fiscale, quindi lo stesso codice univoco.

Due opzioni:

• si tratta effettivamente dello stesso ente, ma per qualche motivo ogni volta ha un nome diverso;
• tutti gli uffici del comune di milano hanno per sbaglio lo stesso codice fiscale.

Mi riferisco alla PR #11 , nel csv c'è una colonna licencePlateCode senza namespace come invece per tutte le altre. L'ho sostituita (aggiornando anche lo schema) con unice:licencePlateCode (https://en.wikipedia.org/wiki/United_Nations_Economic_Commission_for_Europe).

caro @patrunomeister ,
guardando ai CF in banca dati https://es.appaltipop.it/appaltipop-buyers/_search, vedo che il CF del comune di Trento è IT-CF-355870221, mentre quello corretto è IT-CF-00355870221.

Probabilmente è una conversione automatica, perché è gestito come integer, mentre è una stringa. Se troncato, non è possibile fare join con altre fonte (come iPA).

Credo che la cosa avvenga dal lato "tuo". Puoi verificare?

Grazie

Buongiorno a tutti,
le gare con CIG non sono poche (alle volte 1/5 del totale) e come detto più volte, non dovremmo perderle.

Quello che farò, inizierò non prima di domani, è generare dei file di input per @patrunomeister in cui la colonna n, già presente nei file di input, faccia da chiave tra lotti, partecipanti e aggiudicatari.

In questo modo si ha by default un identificativo univoco per le gare "0000000000" ed è possibile associarle a partecipanti e aggiudicatari.

Spero di riuscire a farlo presto.

Ecco un esempio: 7796222DE8. Nei nuovi dati ha 2 redflag uguali, entrambe con codice 04.

{
   "ocds:releases\/0\/id":"7796222DE8",
   "appaltipop:releases\/0\/suppliers":[
      {
         "ocds:releases\/0\/parties\/0\/id":"S-IT-CF-04876970486",
         "ocds:releases\/0\/parties\/0\/name":"CoeSo",
         "appaltipop:releases\/0\/supplier\/amountByBuyers\/total":9218284.6899999976,
         "appaltipop:releases\/0\/supplier\/tendersByBuyers\/total":19
      },
      {
         "ocds:releases\/0\/parties\/0\/id":"S-IT-CF-05339120486",
         "ocds:releases\/0\/parties\/0\/name":"Metropoli",
         "appaltipop:releases\/0\/supplier\/amountByBuyers\/total":1829951.9100000001,
         "appaltipop:releases\/0\/supplier\/tendersByBuyers\/total":5
      }
   ],
   "appaltipop:releases\/0\/buyers":[
      {
         "ocds:releases\/0\/buyer\/id":"IT-CF-84006890481",
         "ocds:releases\/0\/buyer\/name":"COMUNE DI PRATO"
      }
   ],
   "appaltipop:releases\/0\/redflags":[
      {
         "appaltipop:releases\/0\/redflag\/code":"04",
         "appaltipop:releases\/0\/redflag\/description":"Il partecipante che non ha mai fatto un'offerta in precedenza vince la gara"
      },
      {
         "appaltipop:releases\/0\/redflag\/code":"04",
         "appaltipop:releases\/0\/redflag\/description":"Il partecipante che non ha mai fatto un'offerta in precedenza vince la gara"
      }
   ],
   "ocds:releases\/0\/tender\/title":"Affidamento di servizi di accoglienza residenziale temporanea per uomini presso la struttura in Prato, via Fiorentina n. 106\/C, 106\/D e 106\/E - determinazione a contrattare",
   "ocds:releases\/0\/tender\/procurementMethodDetails":"01-PROCEDURA APERTA",
   "ocds:releases\/0\/tender\/contractPeriod\/startDate":"2020-06-01T09:30:00.000Z",
   "ocds:releases\/0\/tender\/contractPeriod\/endDate":"2023-05-31T09:30:00.000Z",
   "ocds:releases\/0\/awards\/0\/value\/amount":529831.8,
   "ocds:releases\/0\/contracts\/0\/implementation\/transactions\/0\/value\/amount":0.0,
   "appaltipop:releases\/0\/tender\/participants\/total":2,
   "appaltipop:releases\/0\/participants\/total":2977,
   "appaltipop:releases\/0\/participants\/mean":1.85
}

Non serve più da tempo, visto che il dominio non punta su questo repo...

Al momento il sistema espone i dati su questi CF:

• 01199250158
• 00355870221
• 84006890481
• 01386030488
• 00337360978

Gli ultimi due non sono da considerare: il primo è REGIONE TOSCANA, che appare come stazione appaltante in una gara del comune di Prato del 2019, il secondo è la PIVA (e non il CF) del comune di Prato. Il primo non è un errore, il secondo sì.
Vi scriverò una issue a tema.

I numeri per i 3 CF "giusti" sono quelli di sotto (@jenkin per ora li metto qui, poi mi dirai dove metterli).

• tenders > il numero di gare
• tenderers > il numero di partecipanti (non distinct, se utile aggiungo anche il distinct)
• suppliers > il numero di aggiudicatari (non distinct, se utile aggiungo anche il distinct)
• tendersZero > il numero di gare con CIG=="0000000000"

{ "tenders": "3345", "tenderers": "6818", "suppliers": "3439", "tendersZero": "226", "ID": "01199250158" }
{ "tenders": "2528", "tenderers": "5701", "suppliers": "2576", "tendersZero": "480", "ID": "00355870221" }
{ "tenders": "1826", "tenderers": "3432", "suppliers": "1843", "tendersZero": "106", "ID": "84006890481" }

Nell'ultima release dei dati manca il namespace ocds: all'attributo releases/0/contracts/0/implementation/transactions/0/value/amount.

Caro @patrunomeister ,
come ci dicevamo ieri, sono da creare nella root.

La mia proposta è di creare una struttura gerarchica di cartelle come quella di sotto, che ho inserito anche nel repo

data
└── IT-CF-80016350821
    ├── csv
    │   └── input.csv
    ├── ocds
    │   └── input.json
    └── xlsx
        └── input.xlsx

È soltanto una proposta. Come nome cartella ho scelto IT-CF-80016350821 e non 80016350821 in modo da poter gestire file anche non "italiani".

Se vuoi essere più light, visto che tu crei file OCDS validi, posso creare io lo script che in batch crea gli altri file di download.

Nell'ultima release di dati degli appalti ci sono molti startDate e endDate a null, ma lo schema si aspetta una stringa. Quindi i campi a null non dovrebbero proprio comparire.

Nota: per endDate non ci sono problemi perché è un campo opzionale, mentre startDate è richiesto, quindi deve esserci sempre e deve essere una data valida.

Appalti che iniziano dopo essere finiti, come il CIG Z5A2AE4CE2... :(

{
   "ocds:releases/0/id":"Z5A2AE4CE2",
   "appaltipop:releases/0/suppliers":[
      {
         "ocds:releases/0/parties/0/id":"S-IT-CF-02319900714",
         "ocds:releases/0/parties/0/name":"EUROMEDITERRANEA srl",
         "appaltipop:releases/0/supplier/amountByBuyers/total":4011.84,
         "appaltipop:releases/0/supplier/tendersByBuyers/total":2
      }
   ],
   "appaltipop:releases/0/buyers":[
      {
         "ocds:releases/0/buyer/id":"IT-CF-81001210723",
         "ocds:releases/0/buyer/name":"COMUNE DI ANDRIA"
      }
   ],
   "appaltipop:releases/0/redflags":[
      {
         "appaltipop:releases/0/redflag/code":"03",
         "appaltipop:releases/0/redflag/description":"Questa gara presenta un solo offerente"
      }
   ],
   "ocds:releases/0/tender/title":"RENDICONTAZIONE ED ASS. TECNICA SUL MIRWEB A SUPPORTO DEL R.U.P",
   "ocds:releases/0/tender/procurementMethodDetails":"23-AFFIDAMENTO DIRETTO",
   "ocds:releases/0/tender/contractPeriod/startDate":"2019-12-09T09:30:00.000Z",
   "ocds:releases/0/tender/contractPeriod/endDate":"2019-01-31T09:30:00.000Z",
   "ocds:releases/0/awards/0/value/amount":1002.96,
   "ocds:releases/0/contracts/0/implementation/transactions/0/value/amount":0.0,
   "appaltipop:releases/0/tender/participants/total":1,
   "appaltipop:releases/0/participants/total":300,
   "appaltipop:releases/0/participants/mean":1.6
}

Qui se vai a vedere il file lotti.csv mancano i titoli degli appalti. Nel file partecipanti poi le ragioni sociali sono il 90% null. Io direi di togliere Monza dalla lista

sono dati che andrebbero un minimo citati e documentati nel sito

questa una fonte http://www.governo.it/sites/governo.it/files/AIR_CODICE_APPALTI.pdf

dashboard eu https://ec.europa.eu/internal_market/scoreboard/performance_per_policy_area/public_procurement/index_en.htm

Nella pagina del sito dedicata ai download ci sono due pulsanti per "scaricare l'intero dataset". Dove sono questi file?

Il comune è 00304260409 e nel file aggiudicatari il CF è a xxxxxxxxx...

che nomi usiamo per gli url? Parlo dei valori di [name] che compaiono sotto, devono valere per tutte le lingue, al momento non sono in grado di localizzare gli url...

• appalto -> ??? (path: /[lang]/[name]/[cig])
• pubblica amministrazione proponente -> ??? (path: /[lang]/[name]/[slug])
• aggiudicatorio -> ??? (path: /[lang]/[name]/[cf])

Vedi https://ondatateam.slack.com/archives/C011N5C9R45/p1589365149004000

Nel json degli appalti la chiave pubblica amministrazione proponente è rimasta al singolare, ma ora è un array, quindi sarebbe più corretto fosse al plurale: pubbliche amministrazioni proponenti.

In riferimento alla PR #23 propongo questa soluzione al problema:

• gli id univoci che identificano le nostre entità (tender, supplier, buyer) devono essere required
• gli attributi required devono esistere e devono essere valorizzati opportunamente e non possono essere null
• se un attributo è opzionale e non è disponibile, non deve essere presente nei dati

Corollario: nessun attributo può essere null. Se un dato non passa la validazione, viene scartato.

Scusate, sarò lungo.

Nei file sorgente si fa riferimento in termini di descrizione di livello gerarchico di primo livello al cosiddetto "ente pubblicatore", che nella grandissima parte dei casi coincide con la cosiddetta "struttura proponente".
La prima è la PA, che pubblica i file XML e una PA potrebbe pubblicare l'XML di un'altro ente che per varie ragioni non ha dove pubblicarlo. Dell'"ente pubblicatore" non viene pubblicato né un CF, né altro codice previsto per identificare una PA, ma soltanto una stringa come "Comune di Prato"
La "struttura proponente" è quella di cui mappiamo i Codici Fiscali, quella che formalmente e sostanzialmente si occupa delle gare.

Questa è una delle ragioni per cui in un unico file sorgente, possiamo avere più "strutture proponenti" e quindi più CF.

Le altre sono più di "processo", più formali e ne trovate qualche cenno nelle FAQ.

Ma ci sono casi odiosi, come il Comune di Prato, che è "ente pubblicatore" e "struttura proponente", che nel suo file sorgente ha i valori distinti sottostanti di CF (e descrizione).

Alcune note:

• 84006890481 non ci dà dubbi, perché è il CF presente nell'indice delle PA (iPA) e lo possiamo validare e filtrare;
• 00337360978 è un errore, perché non è un CF (nell'XML è obbligatorio il CF), ma una PIVA. E lo potremmo scartare perché non presente nei CF dell'iPA;
• su 05040110487 e 01386030488 scrivo dopo la tabella.

05040110487 è il CF di Publiacqua S.p.A, la "società affidataria, dal 1° Gennaio 2002, della gestione del servizio idrico integrato dall'Ambito Territoriale Ottimale n.3 Medio Valdarno, un territorio, asse portante della Toscana, che interessa 4 province, Firenze Prato, Pistoia e Arezzo.". Credo che sia nell'elenco perché è un bando la cui sostanza (anche se gestito da una S.p.A) è tutta nella "cosa pubblica".
Questo CF non è ovviamente in iPA.

01386030488 è il CF di Regione Toscana, che gestirà un appalto su qualcosa con effetti su Prato. Il/i lotto/i relativi andrebbero pubblicati su una scheda PA differente.
Questo CF è su iPA.

Ma c'è di peggio. Il comune di Piacenza ha come CF 00229080338. Nel suo file sorgente ci sono però un mucchio di altri CF di cui non c'è traccia in alcun indice pubblico centralizzato. Il 95% delle gare ha il CF ufficiale, controllabile mappabile.

Il CF di un'azienda/ente è fatto da 11 caratteri:

• i primi sette numeri: corrispondono al numero di matricola che viene assegnato dall’ufficio provinciale di competenza per territorio;
• i numeri dall'ottavo al decimo: corrispondono al codice dell’ufficio Iva provinciale che ha rilasciato il numero di matricola, di solito equivalente al codice Istat della provincia. Ad esempio, 058 per Roma, 015 per Milano, 001 per Torino, 037 per Bologna, 063 per Napoli, 082 per Palermo, ecc.;
• l’undicesima ed ultima cifra, come per il codice fiscale delle persone fisiche, è il codice di controllo per la verifica della correttezza dei numeri precedenti.

Vi chiedo aiuto su questo. Io la leggo così, quello che identifica la mappatura di un ente sono i primi 7 caratteri, quindi 0022908, poi c'è un codice che mappa non l'ente a cui si assegna il CF, ma l'ente che assegna il CF (i numeri dall'ottavo al decimo) e poi l'ultimo è un carattere di controllo.

Quindi potremmo creare una regola che estrae le prime 7, le confronta con iPA, e assegna in questo caso tutto al Comune di Piacenza.

Che fare allora?

Al momento è la prima proposta, mi aspetto e vi chiedo per favore un confronto su questo.

Si potrebbe di base fare così:

• di base si tiene tutto e si divide per CF di assegnazione finale;
  • se c'è un CF in iPA è ok, e la gara si assegna a quell'ente
  • si verifica la faccenda dei primi 7 caratteri e si usa per mappare il CF al nome corretto della PA, e lo si associa al CF mappato su iPA;
  • le gare per le quali non c'è un corrispondente in iPA si associano al CF dell'"ente pubblicatore".

Quindi, sperando che la cosa dei sette caratteri sia sensata:

• non perdiamo nulla di Piacenza;
• la toscana avrebbe il suo spazio sul sito (ma noi potremmo decidere di non pubblicare info di PA con meno di 10 gare, perché sono quelle prodotte automaticamente e per casi speciali, come questo);
• la gara di Publiacqua verrebbe associata al comune di Prato.

Ne vogliamo parlare oggi intorno alle 12:30??

Mi sa che nell'ultima revisione c'è un problema, nell'oggetto che rappresenta il supplier appare il campo ocds:releases/0/tender/title valorizzato con il nome dell'appalto e non dell'aggiudicatario.

{
    "ocds:releases/0/id": "612B15162E",
    "ocds:releases/0/tender/title": "Fornitura di materiale e attrezzature per le pulizie di servizi e scuole comunali. Proroga tecnica per il periodo 01/01/2019 - 31/03/2019. Impegni di spesa.",
    "ocds:releases/0/tender/procurementMethodDetails": "01-PROCEDURA APERTA",
    "ocds:releases/0/tender/contractPeriod/startDate": "2019-01-01T09:30:00.000Z",
    "ocds:releases/0/tender/contractPeriod/endDate": "2019-03-31T09:30:00.000Z",
    "ocds:releases/0/awards/0/value/amount": 5555.5,
    "ocds:releases/0/contracts/0/implementation/transactions/0/value/amount": 736.1,
    "appaltipop:tenderpartecipants": 1.0,
    "appaltipop:totalpartecipants": 3290.0,
    "appaltipop:meanpartecipants": 1.93,
    "appaltipop:suppliers": Array[1][
      {
        "ocds:releases/0/parties/0/id": "S-IT-CF-03960230377",
        "ocds:releases/0/tender/title": "Fornitura di materiale e attrezzature per le pulizie di servizi e scuole comunali. Proroga tecnica per il periodo 01/01/2019 - 31/03/2019. Impegni di spesa.",
        "appaltipop:totamountbysinglebuyer": 5635.46,
        "appaltipop:totcontractsbysupplier": 2.0
      }
    ],
    "appaltipop:redflags": Array[1][
      {
        "appaltipop:redflagcode": "01",
        "appaltipop:redflagdescription": "Low number of mean bidders per tender for competitive processes"
      }
    ],
    "appaltipop:buyers": Array[1][
      {
        "ocds:releases/0/buyer/id": "IT-CF-84006890481",
        "ocds:releases/0/buyer/name": "COMUNE DI PRATO"
      }
    ]
  }

Scelta la strada dello Static-Site Generator (es. Hugo) bisogna capire che limiti noti ha nel gestire un gran numero di file sorgente.

• Hugo: "a good rule of thumb is that each piece of content renders in around 1 millisecond."

A partire https://es.appaltipop.it/appaltipop-buyers/_search estrarre CF e creare report del numero dei dati di input

Sono da definire i dati inclusi dei file sorgente dello SSG:

• frontmatter e contenuto dei file .md
• data templates di supporto (es. con Hugo)
• json statici per caricamento nel browser (via ajax)

La validazione dei json fallisce, bisogna correggere tutti gli errori prima di procedere con l'ingestion in Elasticsearch.

Caro @patrunomeister in questo tuo commento esce fuori che il campo CF sembra forzato a intero, in quanto la stringa che in origine è 00337360978, in output di diventa 337360978.

Io lo lascerei come stringa, perché credo che possano esserci delle troncature forzando a intero (questo è una caso che deriva da un probabile errore, ma ha fatto emergere un elemento che mi sembra da attenzionare).

Grazie

Buongiorno,
al momento si chiamano report_NomeComune.json.

Vi propongo di inserire in questa cartella un nome file che sia sempre l'ID della PA di cui vengono mappate le gare, secondo la classificazione org-id (per l'Italia), e quindi qualcosa come IT-CF-00355870221.

Questi nomi possono servire a creare delle liste "certificate" di ID, ed escludere id di buyers non corretti, come la PIVA inserita al posto del CF (vedi uno dei casi di #31).

@patrunomeister mi basta un tuo ok, ci penso io...

Mi riferisco alla PR #11 , ho rinominato due campi, sia nel csv che nello schema:

• ipa:cod in ipa:cod_amm
• ipa:Comune (nel csv) e ipa:COMUNE (nello schema) in ipa:comune

Mi sono adeguato a questo documento di iPA.

Al momento c'è un "Data inizio" e un "Data di fine", quel "di" che c'è e non c'è pare brutto... :)

Caro Vinc,
faccio un esempio sur Milano (01199250158).

Il mio input XML, contiene tra i partecipanti

    <partecipanti>
      <partecipante>
        <codiceFiscale>09864610150</codiceFiscale>
        <ragioneSociale>CLASS PUBBLICITA' S.R.L. - VIA BURIGOZZO 5 - 20122 MILANO</ragioneSociale>
      </partecipante>
    </partecipanti>

che nel CSV (encoding UTF-8) è

12,ZF9258AC42,09864610150,SOCIETA’ CLASS PUBBLICITA’ SPA,,,,idm244

Nel JSON OCDS di output i maledetti apici di tutti i tipi diventano

                    "suppliers": [
                        {
                            "name": "CLASS PUBBLICITA�  SPA",
                            "id": "S-IT-CF-09864610150"
                        }
                    ]

Non so dove si rompe la cosa. Magari devi soltanto fissare l'encoding all'import del CSV su pandas.

Grazie

I nomi attuali degli attributi hanno delle criticità:

• sono in italiano
• contengono spazi
• non seguono alcuno standard

Tenendo anche conto che non sono nascosti, ma si vedranno in una eventuale API.

Da dove viene questa maglietta?

Qui https://dev.appaltipop.it/it/tender/Z6C2702E9C c'è un nome con "Laffitto", capire dove è il problema

Su Milano ci sono casi come questo

Il campo ocds:releases/0/tender/procurementMethodDetails dei tender dovrebbe contenere un vocabolario controllato delle modalità di messa a bando, ma ci sono dei valori problematici: PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE DEL BANDO, AFFIDAMENTO DIRETTO e 04-PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE. Di seguito tutti i valori presenti con relativo conteggio (numero di appalti per metodo).

[
  {
    "key": "23-AFFIDAMENTO DIRETTO",
    "doc_count": 38826
  },
  {
    "key": "04-PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE",
    "doc_count": 6837
  },
  {
    "key": "08-AFFIDAMENTO IN ECONOMIA - COTTIMO FIDUCIARIO",
    "doc_count": 4334
  },
  {
    "key": "01-PROCEDURA APERTA",
    "doc_count": 3298
  },
  {
    "key": "26-AFFIDAMENTO DIRETTO IN ADESIONE AD ACCORDO QUADRO/CONVENZIONE",
    "doc_count": 2275
  },
  {
    "key": "03-PROCEDURA NEGOZIATA PREVIA PUBBLICAZIONE",
    "doc_count": 1261
  },
  {
    "key": "23-AFFIDAMENTO IN ECONOMIA - AFFIDAMENTO DIRETTO",
    "doc_count": 782
  },
  {
    "key": "PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE DEL BANDO",
    "doc_count": 710
  },
  {
    "key": "AFFIDAMENTO DIRETTO",
    "doc_count": 674
  },
  {
    "key": "04-PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE DEL BANDO",
    "doc_count": 543
  }
]

Accertarsi che il campo sia sempre presente in aggiudicatari.csv e partecipanti.csv

(nel comune 00339370272 manca)

Questo è l'appalto di cui abbiamo parlato oggi nella call.
Problema: risulta 1 solo partecipante e non viene segnalata la bandiera rossa

Sono andato a controllare e questo è quello che trovo nel json...

I partecipanti sono effettivamente 5, ho controllato anche sui csv di partenza....