Regole di Business - Retail & E-commerce

Questo documento elenca le regole di business fondamentali del dominio Retail & E-commerce, identificate con codice univoco BR-NNN. Le regole sono technology-independent e descrivono vincoli invarianti sul comportamento del sistema.

---

BR-001 - Disponibilità netta obbligatoria per BOPIS e omnicanale

Codice: BR-001 Nome: La disponibilità netta deve essere ≥ 1 per accettare un ordine BOPIS o e-commerce allocato su un punto vendita specifico Descrizione: Prima di accettare un ordine Click & Collect o BOPIS su un punto vendita, il sistema deve verificare che la disponibilità netta (quantitaOnhand − quantitaImpegnata) sia almeno pari alla quantità richiesta. Lo stock disponibile fisicamente ma già impegnato da altri ordini in attesa non può essere allocato a nuovi ordini. Motivazione: Evitare la delusione del cliente (ordine accettato ma non evaso) e garantire l'affidabilità del servizio omnicanale. Priorità: CRITICA Attori: OMS, Sistema di inventario, Cliente Violazione: Il sistema rifiuta l'ordine e propone alternative (altro negozio, spedizione da magazzino). Tracciabilità: workflow vendita-omnicanale.md; schema.sql inventario.quantita_impegnata.

---

BR-002 - Importi monetari come interi in centesimi

Codice: BR-002 Nome: Tutti gli importi monetari devono essere rappresentati come INTEGER in centesimi, mai come FLOAT Descrizione: Prezzi, totali, sconti, spese di spedizione e ogni altro importo monetario devono essere memorizzati e trasmessi come numeri interi rappresentanti i centesimi dell'unità monetaria (es. €49.99 = 4999). L'uso di tipi floating-point (float, double, decimal) per valori monetari è vietato. Motivazione: I tipi floating-point introducono errori di arrotondamento accumulabili che causano discrepanze contabili. Un errore di 1 centesimo per transazione su milioni di transazioni produce perdite rilevanti. Priorità: CRITICA Attori: Tutti i sistemi che gestiscono dati finanziari (POS, OMS, ERP, e-commerce) Violazione: Audit contabile produce discrepanze non riconciliabili. Tracciabilità: schema.sql (tutti i campi *_cent); schema.prisma.

---

BR-003 - Il riordino automatico si attiva al punto di riordino

Codice: BR-003 Nome: Il sistema genera automaticamente un ordine di acquisto quando la giacenza raggiunge il punto di riordino Descrizione: Per ogni coppia (Prodotto, PuntoVendita) con replenishment automatico attivo, il sistema monitora la giacenza netta (on-hand − impegnata + in transito) e genera un ordine di acquisto verso il fornitore quando la giacenza scende al di sotto del punto di riordino (ROP = domanda_prevista_lead_time + stock_sicurezza). L'ordine non viene generato se è già presente un ordine aperto per lo stesso prodotto e nodo. Motivazione: Garantire la disponibilità continua del prodotto sullo scaffale minimizzando gli stockout e l'eccesso di scorte. Priorità: ALTA Attori: Sistema di replenishment, ERP, Fornitore (via EDI) Tracciabilità: workflow gestione-inventario.md; schema.sql inventario.punto_riordino.

---

Codice: BR-004 Nome: Le comunicazioni di marketing diretto al cliente richiedono consenso GDPR esplicito e registrato Descrizione: Qualsiasi comunicazione di marketing verso un cliente (email promozionale, notifica push, SMS) deve essere preceduta dalla verifica del campo gdpr_consent = TRUE con gdpr_consent_at NOT NULL. Il sistema non deve inviare comunicazioni commerciali a clienti con consenso non fornito o revocato. La revoca del consenso deve bloccare immediatamente tutte le comunicazioni future e deve essere registrata con timestamp. Motivazione: Conformità al GDPR art. 6 (base giuridica del trattamento) e art. 7 (condizioni del consenso). Evitare sanzioni del Garante Privacy. Priorità: CRITICA Attori: Sistema CRM, Sistema di marketing automation, DPO Violazione: Sanzione GDPR (fino al 4% del fatturato globale annuo). Tracciabilità: schema.sql clienti.gdpr_consent, clienti.gdpr_consent_at; BR-004; GDPR art. 6, 7.

---

BR-005 - Il reso è accettabile solo entro la politica di reso attiva

Codice: BR-005 Nome: Un reso è accettabile solo se soddisfa le condizioni della politica di reso vigente al momento dell'acquisto Descrizione: Prima di accettare un reso, il sistema verifica: (1) l'ordine originale esiste nel sistema e appartiene al cliente richiedente; (2) il prodotto rientri nel periodo di reso (es. 30 giorni dalla consegna); (3) il prodotto non faccia parte delle categorie escluse dalla politica di reso (prodotti deperibili, contenuti digitali, prodotti personalizzati). La politica di reso applicabile è quella vigente al momento dell'acquisto originale. Motivazione: Proteggere il margine aziendale da abusi della politica di reso; garantire al cliente un trattamento equo e trasparente. Priorità: ALTA Attori: Addetto vendite, OMS, Sistema CRM Tracciabilità: workflow reso-prodotto.md; domain-faq.md.

---

BR-006 - Il prezzo promozionale non può essere inferiore al margine minimo configurato

Codice: BR-006 Nome: Nessuna promozione può portare il prezzo di vendita al di sotto del margine lordo minimo configurato per la categoria Descrizione: Prima di attivare un prezzo promozionale, il sistema verifica che il margine lordo risultante (prezzo_promo − prezzo_costo) / prezzo_promo sia superiore al margine minimo configurato per la categoria del prodotto. Se la verifica fallisce, l'attivazione della promozione è bloccata e richiede approvazione esplicita del responsabile acquisti o del controller. Motivazione: Evitare che promozioni o markdown riducano il margine al di sotto della soglia di sostenibilità. Un prezzo sotto costo è legalmente vietato in Italia per i prodotti FMCG (art. 62 D.L. 1/2012, prassi AGCM). Priorità: ALTA Attori: Sistema promozionale, Buyer, Controller Violazione: La promozione viene bloccata; alert al responsabile commerciale. Tracciabilità: schema.sql prezzi_promozionali; business-processes.md.

---

BR-007 - Il movimento di inventario deve avere una causale valida

Codice: BR-007 Nome: Ogni variazione dell'inventario fisico deve essere registrata con una causale valida nel log dei movimenti Descrizione: Nessuna modifica alla quantita_onhand di un prodotto può avvenire senza la creazione di un corrispondente record in movimenti_inventario con tipo valido (ricevimento, vendita, reso_cliente, reso_fornitore, trasferimento_in, trasferimento_out, rettifica_positiva, rettifica_negativa, shrinkage, donazione) e riferimento all'ordine o documento giustificativo. Le rettifiche manuali richiedono autorizzazione del responsabile di magazzino. Motivazione: Garantire la tracciabilità completa dell'inventario per audit, riconciliazione e analisi delle cause di shrinkage. Priorità: ALTA Attori: WMS, POS, Sistema di ricevimento merci Tracciabilità: schema.sql movimenti_inventario; workflow gestione-inventario.md.

---

BR-008 - Lo stato dell'ordine segue un ciclo di vita definito con transizioni valide

Codice: BR-008 Nome: Le transizioni di stato di un ordine devono seguire il ciclo di vita predefinito Descrizione: Un ordine può transitare solo tra stati adiacenti nel ciclo di vita definito: creato → confermato → in_preparazione → pronto_ritiro/spedito → consegnato; consegnato → reso_richiesto → reso_accettato; creato/confermato → annullato. Le transizioni non definite (es. da consegnato direttamente a creato, o da annullato a qualsiasi altro stato) devono essere rifiutate dal sistema. Motivazione: Garantire l'integrità del processo di gestione degli ordini; prevenire stati inconsistenti nel sistema che genererebbero errori nella logistica e nella contabilità. Priorità: CRITICA Attori: OMS Violazione: Il sistema rifiuta la transizione con messaggio di errore esplicito. Tracciabilità: state-machines/ordine-omnicanale-lifecycle.md; schema.sql ordini.stato.

---

BR-009 - La donazione di prodotti alimentari scadenti richiede documentazione fiscale

Codice: BR-009 Nome: La donazione di prodotti alimentari a organizzazioni non profit deve essere documentata per la deducibilità fiscale Descrizione: Quando un prodotto alimentare con BBD ravvicinata viene destinato alla donazione invece dello smaltimento, il sistema deve generare automaticamente il documento di donazione conforme alla Legge 166/2016 (Legge Gadda): descrizione dei prodotti donati, valore fiscale, organizzazione beneficiaria, data. Il movimento in movimenti_inventario deve usare causale DONAZIONE. Motivazione: Conformità alla L. 166/2016; deducibilità IVA; riduzione dei costi di smaltimento; impatto sostenibile positivo. Priorità: MEDIA Attori: Sistema WMS, Sistema ERP, Responsabile del negozio Tracciabilità: use-cases.md (Caso 6); L. 166/2016 (Legge Gadda).