Cantieri aperti: differenze tra le versioni

[versione verificata][versione verificata]
WikiBot (discussione | contributi)
handoff automatico
WikiBot (discussione | contributi)
handoff automatico
Riga 8: Riga 8:
== Cantieri attivi ==
== Cantieri attivi ==
=== finanze-classificazione ===
=== finanze-classificazione ===
''Aggiornato 2026-08-11 14:14 UTC'' — dominio: contabilita / finance
''Aggiornato 2026-08-11 15:08 UTC'' — dominio: contabilita / finance


; Obiettivo : Chiudere il buco DA_CLASSIFICARE e impedire che il lavoro venga azzerato ogni notte
; Obiettivo : Chiudere il buco DA_CLASSIFICARE e impedire che il lavoro venga azzerato ogni notte
Riga 32: Riga 32:
* BUG TROVATO NEL RIMEDIO: dopo le 6 regole aggiunte ieri alcune controparti erano doppie e BigQuery rifiutava con UPDATE must match at most one source row. Aggiunta deduplica con ROW_NUMBER sulla piu recente
* BUG TROVATO NEL RIMEDIO: dopo le 6 regole aggiunte ieri alcune controparti erano doppie e BigQuery rifiutava con UPDATE must match at most one source row. Aggiunta deduplica con ROW_NUMBER sulla piu recente
* RIPRISTINO ESEGUITO: da 8.389 a 4.646 movimenti, da 1.743.096 a 702.043 euro
* RIPRISTINO ESEGUITO: da 8.389 a 4.646 movimenti, da 1.743.096 a 702.043 euro
* USATA la libreria google.cloud.bigquery al posto della CLI bq: la CLI perdeva le regex nei livelli di escaping e l UPDATE tornava False senza errore visibile
* la libreria restituisce num_dml_affected_rows
; Provato ed escluso :
; Provato ed escluso :
* Riclassificare a mano controparte per controparte come proponeva laltra chat: e lavoro gia fatto, 678 regole esistono. Il problema non erano le regole ma il campo vuoto
* Riclassificare a mano controparte per controparte come proponeva laltra chat: e lavoro gia fatto, 678 regole esistono. Il problema non erano le regole ma il campo vuoto
Riga 42: Riga 44:
* Modificare la logica interna del passo classificazione del sync: rischioso e non necessario. Meglio un passo additivo dopo, che riapplica la fonte di verita classification_rules
* Modificare la logica interna del passo classificazione del sync: rischioso e non necessario. Meglio un passo additivo dopo, che riapplica la fonte di verita classification_rules
* Fidarsi di un ESITO FATTO senza ricontrollare il giorno dopo: era vero quando scritto e falso dodici ore dopo
* Fidarsi di un ESITO FATTO senza ricontrollare il giorno dopo: era vero quando scritto e falso dodici ore dopo
* Stringhe SQL con apostrofo (Spese per l ufficio): usare ScalarQueryParameter
; Prossimo passo :
; Prossimo passo :
* Verificare domani mattina dopo le 07:10 che il cron abbia tenuto: se DA_CLASSIFICARE resta a 4.646 il rimedio funziona
* Aggiungere alla sentinella notturna il controllo che DA_CLASSIFICARE non risalga
* Aggiungere il controllo alla sentinella notturna: se il non classificato risale oltre il 10 per cento, avvisa (la regola ce gia in notte.py ma non aveva linea di base)
* Ripulire i doppioni in classification_rules
* Il residuo 4.646 e concentrato in ACT:CARD_PAYMENT e ACT:TRANSFER: usare wise_category di secondo livello


=== harness-standard ===
=== harness-standard ===