Cantieri aperti: differenze tra le versioni - Wiki Progetto di Ricerca Metodo Paret

Riga 7:

== Cantieri attivi ==

=== finanze-classificazione ===

''Aggiornato 2026-08-11 14:14 UTC'' — dominio: contabilita / finance

; Obiettivo : Chiudere il buco DA_CLASSIFICARE e impedire che il lavoro venga azzerato ogni notte

; Fatto (con prova) :

* CREATO routing file FINANZE.md, su Drive id 176Tw19NgXPszcTEtPJEgbrjT00iD2a7i, verificato 4.696 byte

* CENSITO cosa esiste gia in isicnv_finance: 105 tabelle e 19 viste, fra cui v_costi_per_categoria, v_spese_azienda, v_spese_aziendali_da_conto_personale, v_finance_quinquennale, v_riconciliazione_allievi

* TROVATA la causa vera del blocco: classification_rules ha 678 regole agganciate al campo counterparty, ma controparte_nome e NULL su TUTTE le 8.389 righe DA_CLASSIFICARE. Le regole non possono agganciare nulla

* MISURATO: derivando la controparte con TRIM(IF(direction=OUT, dst_name, src_name)) si classificano subito 3.413 movimenti pari a 666.086 euro, il 38 per cento, senza scrivere una regola nuova

* Stato attuale: DA_CLASSIFICARE 8.389 mov / 1.743.096 eur, DA_CHIARIRE 98 mov / 200.025 eur

* ESEGUITO. Backup transactions_multianno_bak_20260809 (14.492 righe)

* controparte_nome popolato su tutte le 8.389 righe da src_name/dst_name secondo direction

* Applicate le 678 regole di classification_rules: 3.413 movimenti classificati, DA_CLASSIFICARE sceso da 8.389 a 4.976 movimenti e da 1.743.096 a 1.077.010 euro. Marcati con classifier_blob auto:classification_rules:20260810

* Categorie assegnate: INCOME_CORSI 1.116 mov 472.134 eur, PERSONAL 431, BIZ_FOR_UNIVERSITE 197, PERSONAL_GENUINE 404, MARKETING 96, CASH 57, ANNA_FAMILY 76, REVIEW 353, TRASPORTI 166, STAFF 33, TRAVEL 40, TECH 353, LEGAL 12, INTERCOMPANY 13

* INTEGRITA VERIFICATA: 14.492 righe prima e dopo, somma importi 4.351.207 identica

* REGOLE DI MARCO INSERITE in classification_rules e applicate: LIGHTNING SOURCE -> INCOME_LIBRI (royalties, e IN non OUT: sono ricavi non costi di stampa), Di Feo Gioacchino -> INCOME_CORSI VIP COURS, Alena Telezin -> INCOME_CORSI corso Svizzera, IPCA -> INTERCOMPANY collaborazione associazione italiana, To GBP e To EUR -> FX conversioni interne Wise

* Assegnati: FX 50 mov 51.572 eur, INCOME_CORSI 7 mov 41.750, INCOME_LIBRI 3 mov 24.965, INTERCOMPANY 9 mov 20.000

* RESIDUO ora 4.907 mov / 938.723 eur (partenza 8.389 / 1.743.096)

* INDAGINE sui 113 (da identificare): tutti IN su Universite apr-lug 2026, causali loan 15.050, vuota 8.374, Wages 7.094, bonus, rimborsi progetto, May Rent, fatture, Saldo corso Roma, quote iscrizione

* Gmail isicnv interrogabile via token-any-isicnv: le notifiche Wise Denaro ricevuto da X contengono il nome mancante. Estratte 12 mail con nome (TODARO STEFANIA, MORRONI CRISTIANA, Giuseppe Giudice, BERTON LINE SRL, Daniele Pacioni, D ALONZO ELISA, PRIVITERA ANTONINO, DONATI NAZZARENO...) in /home/claudeuser/wise_mail_match.json

* FALSO SUCCESSO SCOPERTO: tutto il lavoro di classificazione del 10 agosto (3.413 movimenti miei piu circa 1.700 di unaltra chat) era stato AZZERATO. DA_CLASSIFICARE era tornato a 8.389 mov / 1.743.096 euro, il numero esatto di partenza, mentre i marcatori in classifier_blob restavano a dire che il lavoro era stato fatto

* CAUSA TROVATA: finance_daily_sync.py alle 06:45 ha un passo chiamato classificazione che riscrive la colonna category da zero e riporta a DA_CLASSIFICARE tutto cio che le sue regole interne non riconoscono. Confermato da INFORMATION_SCHEMA.JOBS_BY_USER: catena di UPDATE alle 06:49-06:51 su category e perimetro, e ultima modifica tabella alle 06:50:29

* RIMEDIO: creato scripts/riapplica_regole.py, in cron alle 07:10 (dopo il sync). Ripopola controparte_nome e riapplica classification_rules

* 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

; 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

* Fidarsi dei nomi di colonna italiani: il ledger usa date amount_src category description NON data importo categoria

* Scrivere il marcatore nel campo note: e FLOAT64 non STRING, lUPDATE fallisce. Usare classifier_blob che e STRING

* Riclassificare a mano controparte per controparte prima di aver popolato controparte_nome

* Recuperare i nomi dai dati grezzi: recent_2026_raw ha sender valorizzato solo su 19 righe su 334 nel periodo, merchant zero. Il nome NON e nei grezzi

* Il campo note e FLOAT64: usare classifier_blob per i marcatori

* Solo 12 notifiche Wise nel periodo contro 113 movimenti: la posta copre una minoranza dei casi

* 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

; 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 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 ===

''Aggiornato 2026-08-11 08:37 UTC'' — dominio: architettura / knowledge base

Riga 175:

Riga 216:

* cercare flyer/foto per le mostre thangka a Nizza (oggi solo testimonianza orale)

* valutare pagina EN/IT bilingue

~~=== finanze-classificazione ===~~

~~''Aggiornato 2026-08-10 10:01 UTC'' — dominio: contabilita / finance~~

~~; Obiettivo : Chiudere il buco DA_CLASSIFICARE nel ledger senza rifare lavoro gia esistente~~

~~; Fatto (con prova) :~~