Il filtro coda istruttore escludeva le pratiche in stato SUBMITTED
gia assegnate all'istruttore stesso. Risultato: una pratica appena
inviata dal benef a un istruttore preferenziale (suggested_instructor
letto da gepafin_schema.assigned_applications) cadeva nel limbo:
- non 'pool unassigned' perche ha assigned_instructor_id != NULL
- non 'UNDER_REVIEW assegnata a me' perche era ancora SUBMITTED
Aggiunta clausola: SUBMITTED AND assigned_instructor_id == user.user_id
nell'elenco degli stati visibili.
Segnalazione Carlo: istruttore loggato vede 'Nessuna pratica in coda'
anche se T2 e stata assegnata a lui.
Il capo istruttore deve vedere anche pratiche in DRAFT (beneficiario le sta
compilando) e APPROVED/REJECTED (chiuse) per: monitorare carico istruttori,
riassegnare tranches successive prima del submit, verificare storici.
Prima il filtro era RemissionPractice.status.in_(SUBMITTED,UNDER_REVIEW,AWAITING_AMENDMENT)
ed escludeva drafts e closed. Ora nessun filtro su status — tutte le pratiche.
Segnalazione Carlo: capo istruttore vedeva 'Nessuna pratica in coda' anche
con 2 tranches NAPOLI SAS in DB.
Sostituisce il vecchio flusso 'initialize-restart' (unico template hardcoded)
con un picker unificato che offre 3 sorgenti di inizializzazione:
1. BLANK — schema scheletro v2 con sezioni vuote (categorie, documenti, custom_checks)
da popolare; ULA disabilitata di default; max_tranches=1.
2. TEMPLATE — parte da template predefinito nel registry TEMPLATES di app/templates.py.
Oggi: 'blank' + 'restart'. Struttura estendibile per nuovi template bandi.
3. CLONE — copia schema_json di un altro bando esistente (DRAFT o PUBLISHED).
Useful per bandi 'sorella'. upgrade_schema_to_v2 applicato on-copy per schemi v1 legacy.
app/templates.py: aggiunto BLANK_TEMPLATE, registry TEMPLATES, helper list_templates()
e get_template(id).
app/routers/schemas.py: riscritto con 3 nuovi endpoint:
- GET /templates -> lista metadati template disponibili
- GET /templates/{id} -> preview schema completo
- GET /clonable-calls -> bandi con schema (per dropdown clone)
- POST /{call_id}/initialize body {source, template_id?, source_call_id?} -> unificato
Endpoint /initialize-restart mantenuto come alias di /initialize con template=restart
per backward compat del vecchio FE.
Testato E2E via curl: blank OK, template restart OK, clone da call 1 OK, errori
(source invalido/template_id inesistente/clone senza source_call_id/schema gia esistente/
bando inesistente) tutti gestiti con HTTP corretto.
- models: colonne file inline (storage_path, mime, size_bytes, sha256, uploaded_by, uploaded_at)
su remission_invoice, remission_ula_employee, remission_document
- migrations: ALTER idempotente al lifespan per evolvere schema in sandbox
- storage: FS adapter /var/uploads con validazione MIME/size, dedup sha256, sanitize
- routers/files: POST upload / GET download (con ?inline=1) / DELETE
matrix autorizzazioni: beneficiary su DRAFT|AWAITING_AMENDMENT, istruttore read-only, superadmin full
- main: include router files, version bump 0.2.0
Testato E2E con admin JWT: upload 549B PDF -> DB coerente, storage 1/invoice/<uuid>/<sha12>-file.pdf,
download con magic bytes PDF corretti, delete chirurgico con cleanup FS e metadata.
Gate check (_compute_gate_check) esteso:
- amount_basis legge dal gate_rules dello schema bando:
'imponibile_always' | 'imponibile_only_ordinario' | 'totale_always'
- Backward compat con vecchio flag iva_ordinario_imponibile_only
- Totali retrocompatibili: grand_total resta dichiarato, aggiunti
grand_total_declared, grand_total_verified, per_category_verified,
any_verified, all_verified, amount_basis, use_taxable_only
Il FE ora riceve use_taxable_only e sceglie dinamicamente le label
delle colonne (Imponibile/Totale dichiarato/ammesso).
Parte del refactor istruttore a tabelle inline.
Replica il workflow del foglio Excel originale (REMISSIONE_DEL_DEBITO_5888.xlsm).
Istruttore ora verifica ogni fattura, ogni dipendente ULA, ogni documento singolarmente
invece di accettare/respingere la pratica intera.
Modello dati - nuove colonne su 3 tabelle:
- remission_invoice: taxable_verified, vat_verified, total_verified,
verification_status (PENDING/AMMESSA/PARZIALE/RESPINTA), verification_notes,
date_checks (JSONB con invoice_in_period/payment_in_period), verified_by, verified_at
- remission_ula_employee: fte_pct_verified, verification_status, verification_notes,
verified_by, verified_at
- remission_document: verification_status (PENDING/VALIDO/NON_VALIDO/SCADUTO),
verification_notes, verified_by, verified_at
- remission_practice: instructor_final_notes, instructor_checklist (JSONB 3 gate SI/NO),
verbale_date
Nuovi endpoint:
- PUT /instructor/{id}/invoices/{inv_id}/verify (status + rettifica importi + note)
- PUT /instructor/{id}/ula-employees/{emp_id}/verify (rettifica FTE + note)
- PUT /instructor/{id}/documents/{doc_code}/verify (VALIDO/NON_VALIDO/SCADUTO + note)
- PUT /instructor/{id}/final-notes (note sintetiche + checklist)
Ricalcolo gate_check dual track:
- grand_total_declared: sempre (importo richiesto dal beneficiario)
- grand_total_verified: somma solo fatture AMMESSA/PARZIALE (se PARZIALE usa verified)
- remission_due: usa verified se any_verified=True, altrimenti declared (backward compat)
- residuo_da_restituire: amount_erogato - remission_due
- flag any_verified e all_verified per gating decisione finale
_auto_check_dates: fattura in periodo? pagamento in periodo?
Legge period_start e period_end da schema.gate_rules (superadmin editor).
Template: aggiunto period_start/period_end_date come campi 'editable_by superadmin'
nella sezione general static_fields.
Schema editor FE (BandoRendicontazioneSchemaEdit): aggiunto Calendar period_start
accanto a period_end in section gate rules. period_start_rule dropdown per logica
(erogato_date|fixed) resta; period_start data fissa usata dal check.
- 4 nuove colonne su remission_practice: assigned_instructor_id, reviewed_at,
reviewed_by, rejection_reason, approved_remission
- Nuova tabella remission_amendment_request con cascade delete, scope JSONB,
stati AWAITING -> RESPONSE_RECEIVED -> CLOSED / EXPIRED / REJECTED
- Router instructor.py (287 righe) con 8 endpoint:
/queue, /{id}, /{id}/claim, /{id}/approve, /{id}/reject,
/{id}/amendment, /{id}/amendment/{aid}/close,
/{id}/amendment/{aid}/respond-beneficiary
- GET /{id} (router practices) ora include amendments nel payload
- Manager manager_view flag per ROLE_INSTRUCTOR_MANAGER + SUPER_ADMIN
(vede tutto il pool vs solo le proprie assegnazioni)
- Logica status transitions verificata:
SUBMITTED -> UNDER_REVIEW (claim)
UNDER_REVIEW <-> AWAITING_AMENDMENT (amendment open/close)
UNDER_REVIEW | AWAITING_AMENDMENT -> APPROVED | REJECTED
- _compute_gate_check riusato anche dal router istruttore per calcolo
remission_due in coda e nel dettaglio
Test end-to-end verde: ciclo completo benef -> istruttore -> soccorso ->
risposta -> chiusura -> approvazione funzionante su NAPOLI SAS.
- 4 nuove tabelle: remission_practice, remission_invoice, remission_ula_employee, remission_document
con cascade delete e FK
- 13 endpoint /api/remission-practices/*:
GET /mine (lista pratiche user + applications CONTRACT_SIGNED ready_to_start)
POST /start (avvia pratica da application_id, richiede schema PUBLISHED)
GET /{id}, PUT /{id} (regime IVA + note)
POST/DELETE /{id}/invoices
POST/DELETE /{id}/ula-employees
PUT/DELETE /{id}/documents/{doc_code}
GET /{id}/gate-check (valida gate rules contro pratica, ritorna totali + checks)
POST /{id}/submit (gate-check obbligatorio, status DRAFT -> SUBMITTED)
- 1 endpoint debug /api/debug/impersonate (sandbox-only, genera JWT per utente
- necessario perche' /v1/user/login del BE Spring esclude ROLE_BENEFICIARY)
- Gate check calcola: totali per categoria, grand_total, max_remission = min(cap_pct*erogato, cap_abs),
remission_due = min(grand_total, max_remission), applica iva_ordinario_imponibile_only
