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

Riga 7:

== Cantieri attivi ==

=== finanze-classificazione ===

''Aggiornato 2026-08-10 09:41 UTC'' — dominio: contabilita / finance

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

; 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

; 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

; Prossimo passo :

* Popolare controparte_nome derivandolo da src_name/dst_name sulle 8.389 righe (UPDATE via bq CLI o force:true)

* Applicare le 678 regole esistenti: attesi 3.413 movimenti classificati

* Poi affrontare solo le controparti davvero scoperte: (da identificare) 46.088, To GBP 34.546, LIGHTNING SOURCE 24.965, Di Feo Gioacchino 22.700, GATTI FEDERICO 22.050, Moneynetint 21.236, IPCA 20.000

* DA_CHIARIRE e quasi tutta Hristova: riclassificare come STIPENDI dipendenti bulgari

=== oracolo-reindex ===

''Aggiornato 2026-08-09 09:02 UTC'' — dominio: Biblioteca Magnetica / Oracolo

@@ Riga 7: / Riga 7: @@
 == Cantieri attivi ==
+=== finanze-classificazione ===
+''Aggiornato 2026-08-10 09:41 UTC'' &mdash; dominio: contabilita / finance
+; Obiettivo : Chiudere il buco DA_CLASSIFICARE nel ledger senza rifare lavoro gia esistente
+; 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
+; 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
+; Prossimo passo :
+* Popolare controparte_nome derivandolo da src_name/dst_name sulle 8.389 righe (UPDATE via bq CLI o force:true)
+* Applicare le 678 regole esistenti: attesi 3.413 movimenti classificati
+* Poi affrontare solo le controparti davvero scoperte: (da identificare) 46.088, To GBP 34.546, LIGHTNING SOURCE 24.965, Di Feo Gioacchino 22.700, GATTI FEDERICO 22.050, Moneynetint 21.236, IPCA 20.000
+* DA_CHIARIRE e quasi tutta Hristova: riclassificare come STIPENDI dipendenti bulgari
 === oracolo-reindex ===
 ''Aggiornato 2026-08-09 09:02 UTC'' &mdash; dominio: Biblioteca Magnetica / Oracolo