Modello dati fattura GST: campi minimi per HSN e ordini

Cosa va storto di solito con le fatture GST

La maggior parte dei problemi con le fatture GST non sono problemi di “tassazione complessa”. Sono problemi di dati mancanti o incoerenti. Un audit fallisce quando la fattura non può essere collegata in modo chiaro a quello che è stato venduto, a chi, dove è stato fornito e come è stata calcolata la tassa.

Un punto critico comune è l’HSN assente, non aggiornato o applicato al livello sbagliato. I team possono memorizzare un HSN sul prodotto, ma la riga di fattura viene creata da un nome SKU o una variante diversa, quindi l’HSN non arriva mai sul documento finale. Un altro problema frequente è la divisione fiscale sbagliata: applicare IGST quando dovrebbe essere CGST+SGST (o il contrario) perché il “luogo di fornitura” è stato indovinato dall’indirizzo di spedizione senza conservare i codici stato usati per la decisione.

Le squadre finanziarie lo avvertono subito. La riconciliazione diventa un lavoro di pulizia quotidiano: i totali della fattura non corrispondono all’ordine, l’ordine non corrisponde al saldo del gateway di pagamento e i rimborsi diventano una catena di note manuali. Anche piccole differenze di arrotondamento tra le righe possono creare discrepanze tra il PDF della fattura, i report GST e il libro contabile.

Ecco i pattern che causano la maggior parte dei dolori da mismatch:

• Prodotto e righe di fattura non condividono lo stesso HSN, aliquota GST e campi di valore imponibile.
• La tassa viene calcolata in più posti (carrello vs fattura) e i risultati differiscono.
• I totali sono memorizzati solo come “totale lordo” senza scomposizione per valore imponibile e singoli componenti fiscali.
• La numerazione delle fatture è modificabile o duplicata tra serie diverse.
• I rimborsi sono registrati come ordini negativi invece di note di credito appropriate.

L’obiettivo di un modello dati per le fatture GST è semplice: memorizzare un insieme minimo di campi per ordine, prodotto, parti, tasse, fattura e note di credito così che ogni numero possa essere riprodotto e spiegato in seguito. Mantienilo snello, ma non omettere campi legalmente importanti che determinano il tipo di imposta, l’aliquota e la rendicontazione.

Il set di record più piccolo di cui hai bisogno

Se vuoi che le fatture GST siano facili da generare e semplici da riconciliare in seguito, parti da un piccolo insieme di oggetti e fai in modo che ciascuno svolga un solo compito. Un modello dati pulito per la fattura GST riguarda meno il numero di tabelle e più la stabilità dei fatti nel tempo.

Ecco i record core di cui la maggior parte dei team ha bisogno dal primo giorno:

• Cliente: chi ha comprato (nome, telefono/email, GSTIN se B2B)
• Indirizzo: spedizione e fatturazione, più segnali per stato e luogo di fornitura
• Prodotto (o Servizio): cosa è stato venduto, con unità, prezzo base e HSN/SAC di default
• Ordine: l’evento commerciale (carrello, sconti, spese di spedizione, stato)
• Pagamento: come si è mosso il denaro (riferimento gateway, metodo, importo catturato, data)

Una Fattura dovrebbe essere separata da un Ordine. Gli ordini possono cambiare (indirizzo modificato, articoli annullati, evasione parziale). Le fatture no. Hanno bisogno di numerazione stabile, date e totali che non “scivolino” perché qualcuno ha aggiornato un ordine in seguito.

L’ancora per la precisione fiscale sono le Righe. Ogni riga d’ordine (e successivamente ogni riga di fattura) dovrebbe contenere la quantità esatta, il prezzo unitario, lo sconto e la scomposizione fiscale per quell’articolo specifico. È lì che HSN/SAC e aliquote GST vengono effettivamente applicati.

Un dettaglio che salva i team finanziari: memorizza snapshot. Quando generi una fattura, copia la descrizione del prodotto, HSN/SAC, l’aliquota fiscale e i prezzi nelle righe di fattura. Non fare affidamento sul product master corrente, perché tariffe e nomi cambiano.

Opzionali ma spesso utili da aggiungere presto sono Resi, Rimborsi e Note di credito come record separati. Esempio: se un cliente restituisce un articolo da un ordine di due articoli, vuoi una nota di credito che faccia riferimento alla riga della fattura originale, mentre il record di rimborso punta alla transazione gateway. Tenere questi oggetti espliciti previene “correzioni manuali” a fine mese nei registri GST.

Se lo costruisci in Koder.ai, tratta ogni oggetto prima come una schermata semplice (crea, visualizza, modifica), poi aggiungi la generazione della fattura solo dopo che snapshot e campi a livello di riga sono al loro posto.

HSN e SAC: dove rientrano nel modello

HSN (per beni) e SAC (per servizi) non sono dettagli “solo fattura”. Partono dalla definizione del prodotto o servizio e vengono poi copiati su ogni riga di fattura al momento dell’emissione. Questo mantiene i carrelli misti corretti e facilita gli audit perché ogni riga è autonoma.

Un modello dati minimo pratico è:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (opzionale per righe manuali), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Mettere HSN/SAC sul Product aiuta l’admin a mantenerlo in un unico posto. Copiarlo su InvoiceLine è ciò che rende le fatture passate stabili. Anche se il prodotto cambia in seguito, la fattura mostra ciò che era vero al momento della vendita. Questo è il cuore di un modello dati per fatture GST che non si rompe durante la riconciliazione.

Per l’archiviazione dell’HSN, mantieni le cose semplici: code è obbligatorio, description è opzionale e una effective_from date è opzionale se vuoi una cronologia dei cambiamenti. La maggior parte dei team non ha bisogno della descrizione su ogni riga, ma può aiutare quando la finanza verifica le eccezioni.

I carrelli misti sono normali: una fattura può avere più righe e quindi più codici HSN/SAC. Non cercare di forzare un unico codice per fattura. I totali si aggregano a livello di fattura, mentre la classificazione resta a livello di riga.

La gestione delle modifiche è dove le persone sbagliano. Usa poche regole:

• Non sovrascrivere mai HSN/SAC sulle righe di fattura già emesse.
• Se l’HSN/SAC di un prodotto cambia, aggiorna il Product solo per gli ordini futuri.
• Se tracci la storia, aggiungi un nuovo record effective_from invece di modificare quello vecchio.

A livello di schermo admin, ti serve solo un posto per modificare i campi fiscali del Product, più una vista in sola lettura sulla riga di fattura per confermare ciò che è stato catturato al momento dell’emissione. Se stai costruendo queste schermate rapidamente, strumenti come Koder.ai possono generare le pagine CRUD di base e le tabelle dati dal modello con minimo sforzo.

Dati delle parti: GSTIN, indirizzi e luogo di fornitura

Un modello dati per fatture GST fallisce più spesso sui dettagli delle parti. Se l’identità del compratore o del venditore è anche leggermente errata, la tua fattura può essere valida sulla carta ma problematica nelle dichiarazioni e nella riconciliazione.

Inizia trattando “venditore”, “acquirente” e “ship-to” come parti separate, anche quando sono la stessa persona. Questo evita soluzioni improvvisate quando un cliente aggiunge un indirizzo di spedizione diverso o quando vendi da più registrazioni GST.

Campi minimi da memorizzare (compratore e venditore)

Mantieni i campi noiosi ed espliciti. Questi sono quelli che di solito servono sulla fattura e nei report:

• Ragione sociale (come deve apparire sulla fattura)
• Nome commerciale (opzionale, ma utile)
• GSTIN (venditore obbligatorio; compratore nullable)
• Telefono/email (non sempre obbligatorio, ma utile per il supporto)
• Linee indirizzo, città, stato, paese, PIN/codice postale

Memorizza lo stato sia come nome leggibile che come codice stato, perché la rendicontazione e le regole sul luogo di fornitura spesso si basano sul codice.

Fatturazione vs spedizione e luogo di fornitura

Cattura sia indirizzo di fatturazione che di spedizione sull’ordine, non solo nel profilo cliente. I profili cambiano; le fatture no.

Il luogo di fornitura dovrebbe essere memorizzato come un codice stato specifico sulla fattura (copiato dall’ordine al momento dell’emissione). Non “ricalcolarlo” dopo. Se la tua regola è “ship-to state”, memorizza quel risultato, più lo stato usato per decidere. Questo facilita audit e dispute.

B2B vs B2C: quando il GSTIN è obbligatorio

Per il B2B, il GSTIN del compratore è normalmente obbligatorio e dovrebbe essere validato per lunghezza e formato al momento dell’inserimento. Per il B2C, il GSTIN può rimanere vuoto, ma ti serve comunque un indirizzo completo e lo stato per determinare se si applica CGST/SGST o IGST.

Una regola semplice che funziona nella maggior parte dei sistemi: se il GSTIN del compratore è presente, tratta come B2B; se no, tratta come B2C. Se servono eccezioni, memorizza un campo esplicito customer_type.

Venditori multi-entità (più GSTIN)

Se hai filiali o unità di business con registrazioni GST diverse, modella la “Seller Entity” come un proprio record con GSTIN e indirizzo. Ogni ordine dovrebbe riferirsi esattamente a una seller entity, e ogni fattura dovrebbe copiare quei dettagli così le fatture storiche restano corrette anche se l’indirizzo del venditore cambia.

Strumenti come Koder.ai possono generare rapidamente i form admin per questi record, ma la chiave è la struttura: seller entity separata, snapshot al momento dell’ordine e un codice stato esplicito per il luogo di fornitura.

Campi di calcolo fiscale che devi memorizzare

La divisione più comune è semplice: se il luogo di fornitura è nello stesso stato del fornitore, la tassa è CGST + SGST. Se è in uno stato diverso, la tassa è IGST. Il tuo sistema non dovrebbe “ricomputare in seguito dai totali” perché piccole differenze (arrotondamento, sconti, spedizione) sono proprio ciò che causa i mismatch.

Al minimo, memorizza i valori fiscali a livello di riga di fattura, non solo nell’intestazione. In questo modo puoi spiegare ogni rupia sulla fattura e ricondurla a prodotto, HSN e ricavo.

Un minimo pratico per riga di fattura nel tuo modello dati GST somiglia a questo:

• taxable_value (dopo l’allocazione dello sconto a livello di riga)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (memorizza la divisione usata)
• cgst_amount, sgst_amount, igst_amount (memorizza gli importi calcolati)
• line_total (taxable_value + importi fiscali)

Gli sconti sono dove i sistemi si mettono nei guai. Decidi una regola e memorizzala chiaramente. Se gli sconti riducono il prezzo prima delle tasse (tipico per sconti su articoli e coupon), memorizza l’importo lordo originale, l’importo dello sconto e il valore imponibile risultante. Se hai un coupon a livello d’ordine, allocane l’importo sulle righe (di solito in proporzione al valore imponibile pre-sconto) e memorizza lo sconto allocato per ogni riga in modo che la matematica fiscale rimanga spiegabile.

L’arrotondamento dovrebbe essere coerente e registrato. Scegli se arrotondare a livello di riga o solo a livello di fattura, poi memorizza i risultati arrotondati che hai stampato. Molti team calcolano la tassa per riga, arrotondano a 2 decimali, sommano e poi applicano un campo invoice_rounding_adjustment per raggiungere l’importo pagabile esatto.

Spedizione e gestione non devono essere addizionali nascosti. Trattale come una riga di fattura separata con il proprio HSN/codice di servizio e regole di aliquota. Per esempio, un ordine con due prodotti e una spesa di spedizione diventa tre righe, ognuna con valore imponibile e componenti fiscali memorizzati, rendendo la riconciliazione molto più semplice.

Dati del documento fattura: numerazione, date, totali, stato

Una volta calcolata la tassa, la fattura ha comunque bisogno di campi “documentali” che la rendano valida, verificabile e facilmente riconciliabile in seguito. In un modello dati per fatture GST, tratta l’intestazione della fattura come un record legale: deve essere stabile anche se prodotto o dati cliente cambiano in futuro.

Inizia con le basi dell’intestazione: numero fattura, data di emissione (la data sulla fattura), tipo di fattura (tax invoice, export, B2B, B2C, ecc.) e valuta. Anche se fatturi principalmente in INR, memorizzare la valuta evita casi limite per esportazioni o marketplace multi-valuta.

La numerazione è dove i team si scottano. Mantieni una serie o un prefisso (per esempio “FY25-INV-”), memorizza l’anno finanziario e applica unicità a livello database. Memorizza anche controlli “next number” per serie in admin in modo che due amministratori non possano emettere lo stesso numero nello stesso momento.

I totali dovrebbero essere memorizzati esplicitamente, non solo derivati. Salva subtotale (valore imponibile), tassa totale e totale lordo, più un separato importo di arrotondamento. Se ricalcoli in seguito dalle righe, una piccola modifica di regola può far sì che fatture vecchie non combacino più con le dichiarazioni depositate.

Gli stati dovrebbero riflettere il ciclo reale e bloccare il record quando necessario:

• Draft (modificabile)
• Issued (numero assegnato, PDF generato)
• Cancelled (conservata per audit, non cancellata)
• Refunded (pagamento stornato, può richiedere nota di credito)
• Credit noted (nota di credito emessa e collegata)

Infine, memorizza i metadati dell’artifact generato: versione del template PDF, timestamp di generazione e un identificatore file. Un hash è opzionale, ma utile se devi dimostrare che il PDF non è stato alterato.

Esempio: se un agente di supporto rigenera un PDF dopo un aggiornamento del template, i totali e il numero della fattura devono rimanere identici, ma la versione del template memorizzata spiega perché il layout del PDF appare diverso.

Schermate admin per prodotti, tasse e dati cliente

Se vuoi fatture GST pulite, non partire dalla schermata fattura. Parti dalle pagine admin che la alimentano. Un buon modello dati resta piccolo quando questi input sono controllati e coerenti.

Product master (SKU a HSN/SAC)

Il product master è dove iniziano la maggior parte dei mismatch futuri, quindi mantienilo rigoroso. Ogni SKU dovrebbe avere esattamente un HSN di default (o SAC per servizi), più un’aliquota GST di default e eventuali eccezioni valide solo per certe date.

Una schermata prodotto pratica di solito richiede:

• SKU e nome prodotto (come vuoi che venga stampato)
• Codice HSN/SAC, aliquota GST e categoria fiscale (se la usi)
• Date active from/to (così i cambiamenti non riscrivono fatture vecchie)
• Override di prezzo (per MRP speciali o prezzi per canale)
• Stato (attivo/inattivo) con chiara motivazione per la disattivazione

Configurazione tasse (aliquote e input intra vs inter-state)

Evita una UI “calcolatrice”. Memorizza invece gli input che il tuo sistema può applicare in modo coerente: tabelle di aliquote, regole per il luogo di fornitura che segui e come decidi intra-state vs inter-state (di solito confrontando stato fornitore e stato ship-to).

Mantieni la schermata fiscale focalizzata su: aliquota per categoria/gruppo HSN, date di efficacia e cosa succede quando il compratore fornisce un GSTIN valido vs no.

Profilo cliente e azienda (chi è sulla fattura)

La schermata cliente dovrebbe catturare GSTIN e il suo stato di validazione, più indirizzi di fatturazione e spedizione predefiniti. Non lasciare che gli utenti scrivano stati libero; usa una lista controllata così “KA” e “Karnataka” non diventano due valori diversi.

La schermata profilo azienda è altrettanto importante: ragione sociale, GSTIN, indirizzo registrato e impostazioni della serie di fatture (prefisso, next number e confini anno finanziario). Blocca queste impostazioni con permessi perché le modifiche influenzano ogni documento futuro.

Basi del log di audit (fiducia e tracciabilità)

Non serve un sistema complesso, ma serve una traccia. Registra chi ha cambiato HSN/SAC, aliquote, impostazioni della serie di fatture o GSTIN aziendale, insieme al valore vecchio, nuovo, timestamp e motivo.

Se costruisci queste schermate in uno strumento come Koder.ai, tratta il logging di audit e le date di efficacia come campi di prima classe fin dal primo giorno. Costano poco da aggiungere all’inizio e risparmiano ore nelle revisioni finanziarie.

Passo passo: dall’ordine alla fattura conforme

Una fattura conforme riguarda meno la grafica e più il congelare i fatti giusti al momento giusto. Se progetti il modello dati intorno a questo flusso, il lavoro della finanza diventa una semplice corrispondenza, non un’investigazione settimanale.

1) Congela ciò che il cliente ha effettivamente comprato

Prima di calcolare la tassa, blocca uno snapshot dell’ordine: articoli, quantità, prezzi unitari, sconti, spese di spedizione/gestione, GSTIN cliente (se presente), indirizzi di fatturazione e spedizione, e segnali per il luogo di fornitura. Lo snapshot non deve cambiare anche se il prezzo del prodotto o la mappatura HSN cambia in seguito.

2) Trasforma lo snapshot in righe di fattura (con attributi fiscali copiati)

Calcola le tasse e genera le righe della fattura dallo snapshot. Ogni riga di fattura deve copiare HSN/SAC, aliquota(i) fiscale(i), valore imponibile e importi fiscali usati in quel momento, invece di cercarli live in seguito.

3) Emmetti la fattura e rendila immutabile

Assegna il numero fattura e la data di emissione, poi marca la fattura come emessa. Da questo punto, blocca le modifiche a prezzi, aliquote fiscali, codici HSN e indirizzi sul record fattura. Se devi consentire qualcosa, limitalo a note non finanziarie e tag interni.

4) Produci il documento finale e memorizza i totali

Genera il PDF/visualizzazione di stampa dalla fattura emessa, poi memorizza i totali finali che riporterai: totale imponibile, totali CGST/SGST/IGST, arrotondamento e totale lordo. Se vuoi maggiore sicurezza, memorizza una versione del documento o un checksum così puoi dimostrare che la stampa corrisponde ai numeri memorizzati.

5) Gestisci le modifiche in modo legale

Dopo l’emissione, le modifiche dovrebbero seguire regole, non modifiche libere:

• Il cliente vuole una correzione di prezzo: emetti una nota di credito (o nota di addebito) che faccia riferimento alla fattura originale.
• L’ordine viene cancellato dopo l’emissione: cancella la fattura se consentito, altrimenti emetti una nota di credito.
• Il cliente aggiorna l’indirizzo dopo l’emissione: non riscrivere la fattura; correggi tramite il documento appropriato e conserva la traccia di audit.
• Rimborso parziale: nota di credito solo per le righe/importi rimborsati.
• Spedizione di sostituzione: nuovo ordine/fattura, non una modifica silenziosa.

Se costruisci questo flusso nelle schermate admin (la modalità Planning Mode di Koder.ai è utile per mappare i passaggi prima di costruire), il tuo team può generare fatture rapidamente senza rompere la riconciliazione in seguito.

Rendi la riconciliazione indolore: pagamenti, rimborsi e registri

La riconciliazione si complica quando i pagamenti sono trattati come un singolo flag “pagato/non pagato” sull’ordine. Tieni pagamenti e rimborsi come record separati che puntano a ordine e fattura, così la finanza può abbinare gli incassi bancari senza riscrivere la storia.

Pagamenti e rimborsi separati (non modificare la fattura)

Una fattura conforme dovrebbe restare stabile dopo l’emissione. Se un cliente paga in più tranche, o rimborsi arrivano in seguito, registra quel movimento come voce di pagamento o rimborso, non come modifica dei totali della fattura.

Campi minimi che rendono la riconciliazione semplice:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (opzionale ma utile): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (se emessa), gateway_refund_id, amount, reason, refunded_at, status
• Chiavi di riconciliazione da non riutilizzare: order_id, invoice_id, payment_id, refund_id, credit_note_id

Se il cliente restituisce un articolo, non “ridurre la fattura”. Emetti una nota di credito e collegala alla fattura originale. Il registro delle fatture resta pulito e il rimborso si riconduce alla nota di credito.

Vista finanziaria ed esportazioni che risparmiano ore

Dai alla finanza una singola schermata che risponda: cosa è stato emesso, cosa è stato pagato, cosa è ancora aperto e cosa è stato stornato. Includi ageing (0-7, 8-30, 31-60, 60+ giorni) e drill-down alle voci di pagamento e rimborso correlate.

Esportazioni di cui la maggior parte dei team ha bisogno ogni mese:

• Registro fatture (emesse, cancellate, con nota di credito)
• Riepilogo tasse per aliquota e HSN/SAC (supporta il tuo modello dati GST)
• Riconciliazione pagamento vs fattura (invoice_id, totali pagamento, saldo)
• Registro rimborsi e note di credito
• Report di settlement gateway (payout_id a mapping invoice/payment)

Esempio: un ordine è Rs 10,000, pagato Rs 6,000 oggi e Rs 4,000 la settimana successiva. La fattura resta Rs 10,000. La vista finanziaria mostra saldo Rs 4,000 fino al secondo incasso, poi la segna come pagata senza alterare il documento emesso.

Trappole comuni che causano problemi di conformità e mismatch

La maggior parte dei problemi con le fatture GST non sono problemi di logica fiscale. Sono problemi di tenuta dei record: i numeri sul PDF non corrispondono a quelli esportati dalla finanza, o la fattura non può essere spiegata mesi dopo.

La prima trappola è calcolare la GST solo al momento della visualizzazione. Se calcoli CGST/SGST/IGST ogni volta che qualcuno apre una fattura, alla fine otterrai risultati diversi dopo un cambio di aliquota, una modifica di arrotondamento o una correzione di bug. Memorizza la scomposizione fiscale calcolata al momento dell’emissione, anche se memorizzi anche gli input.

Una seconda trappola è consentire modifiche a una fattura emessa. Una volta definitiva, le modifiche devono avvenire tramite nota di credito o flusso di sostituzione con traccia di audit. Altrimenti vedrai discussioni tipo “perché il PDF cliente differisce dai libri?”.

Ecco i pattern di mismatch che si presentano più spesso in un modello dati per fatture GST:

• Il luogo di fornitura manca o il codice stato è sbagliato, quindi viene applicato IGST quando avrebbe dovuto essere CGST+SGST (o viceversa).
• HSN/SAC del prodotto o aliquota fiscale viene aggiornata e gli ordini vecchi vengono ricalcolati con il nuovo valore.
• La tassa è memorizzata, ma le regole di arrotondamento differiscono tra UI, generazione PDF ed esportazioni CSV.
• Gli sconti sono applicati dopo le tasse in un posto e prima delle tasse in un altro.
• I rimborsi sono registrati come righe negative senza chiaro collegamento alla fattura originale.

Un esempio rapido: vendi a un cliente in Karnataka, ma l’indirizzo di spedizione è in Maharashtra. Se il sistema prende per errore lo stato di fatturazione per il luogo di fornitura, potresti applicare CGST+SGST invece di IGST. Se poi ricalcoli le tasse al volo, quell’errore può “aggiustarsi” silenziosamente in seguito, lasciando la finanza con numeri che non corrispondono al documento emesso.

Quando costruisci schermate admin (personalizzate o tramite una piattaforma come Koder.ai), aggiungi piccole barriere: blocca le fatture emesse, mostra gli input del luogo di fornitura accanto al tipo di tassa calcolato e conserva uno snapshot immutabile di HSN, aliquota e arrotondamento usati al momento dell’emissione.

Checklist rapida e prossimi passi

Prima di inviare una fattura al cliente o marcarla come “emessa”, esegui un rapido insieme di controlli. Qui è dove la maggior parte degli errori piccoli diventa un grande problema di riconciliazione in seguito. Se stai costruendo un modello dati per fatture GST, vale la pena integrare questi controlli sia nelle regole di validazione sia nella UI admin.

Controlli per fattura (prima di emettere)

• HSN/SAC è presente su ogni riga e corrisponde al prodotto o servizio effettivamente venduto.
• Le regole GSTIN sono applicate correttamente (B2B vs B2C) e i dettagli di fatturazione e spedizione non si contraddicono.
• Il luogo di fornitura è memorizzato e la divisione fiscale ha senso (CGST/SGST vs IGST).
• I totali corrispondono esattamente: valore imponibile, ogni componente fiscale, arrotondamento e totale lordo.
• Una volta emessa, la fattura è bloccata (niente modifiche silenziose). Le correzioni avvengono tramite nota di credito o flusso di cancellazione, non riscrivendo la storia.

Un esempio semplice: un cliente aggiorna l’indirizzo di spedizione dopo il pagamento e lo stato cambia. Se ri-emetti lo stesso numero fattura con nuova tassa, il registro e i record di pagamento non corrispondono più. L’approccio più sicuro è mantenere la fattura originale immutabile e creare un documento di rettifica.

Controlli dati + workflow (per mantenere pulita la finanza)

• La numerazione delle fatture è unica, sequenziale secondo la politica e generata solo al momento di “issue”.
• Memorizza gli importi fiscali calcolati che hai usato, non solo le aliquote, così i report rimangono stabili anche se le aliquote cambiano in seguito.
• Esistono passaggi di stato chiari: draft -> issued -> cancelled (e documenti separati per note di credito).
• I report riconciliano per periodo: i totali del registro fatture devono coincidere con i pagamenti catturati, i rimborsi elaborati e i crediti in sospeso.
• I campi di audit sono sempre presenti: creato da, issued at e una nota motivazione per cancellazioni o note di credito.

Prossimi passi: implementa prima le schermate e le validazioni, poi iterare. In Koder.ai, inizia con Planning Mode per abbozzare record e schermate (prodotti con mappatura HSN/SAC, dettagli cliente/GSTIN, regole fiscali e fatture). Genera l’app, testa qualche ordine reale end-to-end, poi usa snapshot e rollback per raffinare il workflow in sicurezza. Quando servono personalizzazioni più profonde o revisioni, esporta il codice sorgente e continua a sviluppare con il tuo processo abituale.