# DPass 61I3 — Importazione parcometri: anomalie non bloccanti

Correzione locale del flusso 61G. Non è la 61J Telepass, che resta separata.
Base: servizi della 61G e traduzioni aggiornate almeno alla 61G2, verificati con hash.
Compatibile con il progetto ricevuto fino alla 61I2; non richiede i moduli ospiti o API aree.

## Modifiche
- Una conferma `partial` riuscita non interrompe più automaticamente un ciclo con ulteriori lotti da elaborare: segue `has_more` entro `--max-batches` e il tempo massimo configurato.
- I singoli errori di validazione non fanno più restituire al cron il codice di fallimento 1: il comando termina con 0 e scrive conteggi e avvisi. Errori HTTP, autenticazione, ACK, lock e database restano errori.
- Il record #212919 (esempio riportato dall’utente), con fine non successiva all’inizio, rimane rifiutato, tracciato nel registro e non genera un titolo o un importo fittizio. Nessuna data viene corretta automaticamente.
- I lotti restano `completed_with_errors` quando contengono scarti: questo descrive il lotto, non un blocco del collegamento.
- Il messaggio `PARTIAL_BATCH`, anche sui lotti storici, non richiede più la correzione preventiva per proseguire.
- Nuovi campi del riepilogo CLI: `has_more`, `stop_reason`. Nessun token o dato personale aggiunto al log.
- Un guasto imprevisto di persistenza/programmazione NON viene trattato come semplice anomalia di dati: il lotto rimane riprendibile senza ACK di successo fuorviante. I servizi già salvati vengono riconosciuti alla riconsegna.

## Cosa non cambia
Nessuna migration, SQL, .env, cron, credenziale, pagamento, tariffa o dato esistente modificato.
Nessuna chiamata di rete durante l’applicazione. I controlli effettuano solo richieste simulate.
ACK dei record validi dopo commit locale; scarti sempre in `rejected`, mai in `accepted_ids`.
Nessuna cancellazione e nessuna promozione a `completed` di un lotto parziale.
Il periodo errato non entra nelle soste né nei servizi venduti; rimane disponibile nel registro.

## Applicazione
Salvare lo ZIP in C:\Users\massi\Downloads ed eseguire da Ubuntu/WSL:

```bash
(
  set -e
  cd ~/progetti/dpass
  PATCH_DIR="$(mktemp -d /tmp/dpass_patch_61I3.XXXXXX)"
  unzip -q /mnt/c/Users/massi/Downloads/dpass_patch_61I3_importazioni_anomalie_non_bloccanti.zip -d "$PATCH_DIR"
  bash "$PATCH_DIR/apply_patch.sh" "$PWD"
)
```

Prima preflight hash, poi backup, copia atomica dei singoli file e test isolati.
Se un file non corrisponde, fermarsi: non forzare e non ripristinare una vecchia patch.
In caso di test fallito l’installer tenta il ripristino dei soli file modificati.
Nessun DB applicativo viene letto o scritto dall’installer o dalle suite di verifica.
I test SQL richiedono pdo_sqlite, usano soltanto SQLite :memory: e non il MySQL dell’applicativo.

## Cron e significato di “prosegue”
Il cron già configurato continua a funzionare. Con `--max-batches=1` elabora UN lotto ad ogni avvio: il seguente verrà richiesto al successivo avvio programmato. Non importa tutto nella stessa esecuzione.
Con un valore maggiore (massimo 10, già supportato), continua nello stesso ciclo dopo un parziale correttamente confermato, fino al limite/tempo massimo.
Non viene cambiata automaticamente né la frequenza né la dimensione del lotto.
Un collegamento già disabilitato per un vero errore di credenziale o di protocollo non viene riabilitato dalla patch: verificare e correggere il codice dell’errore, poi salvare dalla pagina amministrativa.

## Nessun salto arbitrario di record / limite del contratto remoto
Il WS 1.0 consegna le prime righe non trasferite in ordine di ID; i rifiutati rimangono riproponibili. DPass non dispone nel contratto di un cursore `after_id` o di una lista di esclusione.
Nel caso 99 validi + 1 errato, al successivo prelievo gli accettati non vengono più consegnati e lo scarto può arrivare insieme agli ulteriori record validi.
Se la sorgente ripropone SOLO gli stessi scarti, la patch evita un ciclo continuo: chiude quella esecuzione e lascia il collegamento abilitato per il cron successivo. Lo stesso vale per un lotto già confermato riproposto immutato.
Se il numero di scarti basta a riempire tutto il lotto remoto, non è possibile garantire l’accesso agli ID successivi tramite il solo contratto 1.0: serve una gestione degli scarti/una finestra di riprova sul WS Ditech Management (da sviluppare in quel progetto) o la correzione dei record sorgente. NON si marcano come accettati dei pagamenti non importati per aggirare questo limite.
Un record corretto in sorgente viene ritentato con lo stesso ID, senza duplicazioni.
Nessun cambiamento al WS è stato eseguito in questa patch.

## Ripristino locale (solo sorgenti)
```bash
bash "$PATCH_DIR/apply_patch.sh" "$PWD" --rollback
```
Il ripristino verifica che i file non siano stati cambiati da patch successive. Non annulla importazioni eseguite nel frattempo. Nella versione precedente le anomalie torneranno a produrre codice di uscita 1 e stop al primo parziale.