Gestionale e-commerce Initpc: sincronizzare oltre 280.000 prodotti

Un e-commerce con oltre 280.000 prodotti a catalogo non nasce da un foglio di calcolo caricato una volta per tutte. Nasce da listini di fornitori diversi, da magazzini che aggiornano la disponibilità con ritmi propri e da un negozio che deve mostrare sempre un prezzo e una giacenza credibili. Il caso di Initpc è questo: un catalogo di materiale per ufficio, cancelleria, informatica, scuola e articoli regalo alimentato da più fonti, con un solo negozio in vetrina.

Il punto centrale del progetto non è WooCommerce, la piattaforma attuale, ma ciò che sta a monte: un gestionale proprietario, sviluppato da noi, che acquisisce i listini, li normalizza, decide cosa pubblicare e tiene allineati prezzi e disponibilità fra fornitori, magazzini e sito. Senza questo strato, un catalogo così non si governa.

Qui raccontiamo come funziona la pipeline, cosa può andare storto in ogni fase e come lo gestiamo. È un approfondimento del case study Initpc, dove trovate l'architettura complessiva e gli altri capitoli.

Perché non si fa a mano, e nemmeno con un plugin di import

La tentazione iniziale è sempre la stessa: un plugin di import CSV, una mappatura delle colonne, un caricamento programmato. Funziona con un fornitore solo e smette di funzionare appena entrano in gioco più listini, perché un plugin risponde a una domanda soltanto — "come porto queste righe dentro WooCommerce?" — mentre le domande vere sono altre. Chi decide quale fornitore vince quando lo stesso prodotto compare in più listini? Cosa succede al prezzo online quando il fornitore più conveniente esaurisce la merce? Dove finisce l'evidenza di ciò che è stato scartato?

Farlo a mano, su oltre 280.000 referenze, non è un'opzione: ogni intervento manuale è una decisione che non lascia traccia e non si può ripetere. Serviva un sistema con una logica propria, separato dal negozio, che trattasse WooCommerce come destinazione e non come il luogo dove i dati vengono messi in ordine.

Il gestionale proprietario: il cervello a monte del negozio

Il gestionale che abbiamo sviluppato per Initpc è un'applicazione autonoma, con il proprio database e i propri processi, collocata fra i fornitori e il sito. WooCommerce riceve da lì dati già puliti e decisi: non conosce i listini originali e non prende decisioni commerciali. Le regole di business — margini, priorità fra fornitori, esclusioni — vivono in un posto solo e si cambiano senza toccare il negozio; il sito può essere sostituito, com'è già accaduto nella storia di Initpc, senza rifare l'integrazione con i fornitori; gli errori si fermano a monte, dove si possono esaminare, invece di arrivare in vetrina.

È lo stesso approccio che seguiamo quando progettiamo software gestionali e CRM su misura: il dato di riferimento sta in un sistema che ne ha la responsabilità, tutto il resto ne è una proiezione.

Dai listini al formato interno

Acquisizione: formati diversi, una sola pipeline

Ogni fornitore consegna il listino come preferisce: file tabellari con colonne che cambiano nome da una versione all'altra, tracciati a larghezza fissa ereditati da gestionali di vecchia generazione, codifiche diverse, feed da scaricare, disponibilità pubblicate a parte. Il gestionale ha un connettore per ogni fonte, che preleva il file, lo interpreta, riconosce se è completo o troncato e produce sempre righe in un formato interno unico. Da lì in poi la pipeline è identica per tutti, e aggiungere un fornitore significa scrivere un connettore, non rifare il sistema.

Normalizzazione: rendere confrontabile ciò che non lo è

• Codici e identificatori. Il codice del fornitore resta come riferimento, ma la chiave che unisce i listini è l'EAN, quando esiste ed è valido; un EAN errato o riutilizzato per prodotti diversi viene segnalato e non usato come chiave.
• Unità di vendita e confezioni. Un fornitore vende il singolo pezzo, un altro la confezione, un altro il cartone: prezzo e disponibilità vengono ricondotti all'unità che il negozio vende davvero, altrimenti il confronto fra fonti non ha senso.
• Prezzi. Il prezzo di acquisto viene letto con le sue condizioni (sconti a scaglioni, promozioni, oneri accessori) e da lì si calcola il prezzo di vendita secondo le regole di margine per categoria.
• Attributi e categorie. Colore, formato, marca, compatibilità: ogni fornitore ha il proprio vocabolario. La normalizzazione lo traduce in quello del catalogo, e le categorie del negozio nascono da una mappatura nostra, non da quelle del fornitore.

Su questa fase interviene anche Hector AI, la nostra piattaforma di intelligenza artificiale: dove gli attributi arrivano mescolati nella descrizione, distillazione e controllo di coerenza sono il lavoro raccontato nella pagina sulle schede prodotto generate con Hector AI.

Regole di pubblicazione: cosa va online e da quale fonte

Prodotti doppi e scelta della fonte

Quando lo stesso EAN compare nei listini di più fornitori, il gestionale mantiene una sola scheda e più offerte collegate. La fonte attiva dipende dal prezzo di acquisto, dalla disponibilità effettiva e da una priorità per fornitore che possiamo impostare. Se il fornitore scelto va a zero, l'offerta passa al successivo e il prezzo online segue: il cliente vede sempre una scheda sola, con prezzo e disponibilità coerenti.

Esclusioni e requisiti minimi

Un prodotto senza descrizione, immagine o categoria non viene pubblicato finché non soddisfa i requisiti minimi. Lo stesso vale per le famiglie escluse per scelta commerciale, per gli articoli in esaurimento definitivo presso tutti i fornitori e per i prezzi anomali: meglio una scheda in meno che un prezzo sbagliato in vetrina.

Disponibilità e prezzi: un aggiornamento deve arrivare fino alla ricerca

Prezzi e disponibilità sono i dati che cambiano più spesso e costano di più quando sono sbagliati. Il gestionale li aggiorna verso WooCommerce con un flusso differenziale: solo ciò che è cambiato viene scritto, perché riscrivere ogni volta l'intero catalogo metterebbe in ginocchio il database. Un prezzo aggiornato nel database non è ancora aggiornato per chi visita il sito: la pagina può essere servita da Varnish, l'oggetto prodotto può stare in Redis e il risultato di ricerca arriva da Elasticsearch. Ogni aggiornamento deve propagarsi lungo tutta la catena — invalidazione mirata delle pagine, aggiornamento dell'object cache, reindicizzazione del prodotto — altrimenti la ricerca propone un prezzo che il carrello non riconosce. Come è organizzato l'indice, e perché abbiamo abbandonato le query native di WooCommerce, lo spieghiamo nella pagina su Elasticsearch per la ricerca dell'e-commerce.

Gestione degli errori: cosa succede quando qualcosa non torna

Con più fornitori e centinaia di migliaia di righe, qualcosa non torna a ogni ciclo. La domanda è dove viene fermato e come viene reso visibile.

Fase della pipeline	Cosa fa	Cosa può andare storto	Come lo gestiamo
Acquisizione	Preleva e legge il listino di ciascun fornitore	File assente, troncato, tracciato cambiato	Verifica di completezza; il listino non valido viene ignorato e resta in uso l'ultimo buono; ritentativo automatico e alert
Normalizzazione	Porta codici, unità, prezzi e attributi nel formato interno	EAN errati, unità ambigue, prezzi fuori scala	Riga scartata con motivo registrato; scostamenti anomali in quarantena in attesa di revisione
Pubblicazione	Applica le regole su cosa e da quale fonte pubblicare	Requisiti minimi mancanti, conflitto fra fonti	La scheda resta non pubblicata o mantiene l'ultima offerta valida; il caso finisce nel report
Sincronizzazione	Scrive le differenze in WooCommerce	Errori di scrittura, timeout, carico sul database	Lotti di dimensione controllata, ripresa dal punto di interruzione, log per ogni scrittura
Propagazione	Invalida Varnish e Redis, reindicizza in Elasticsearch	Cache non invalidata, indice non aggiornato	Coda di reindicizzazione con conferma; controllo di coerenza fra database e indice

La quarantena merita una parola in più. Un prezzo che si discosta in modo anomalo dal precedente può essere un errore del fornitore o una promozione vera; non lo decide il sistema da solo: la riga viene isolata, il prodotto mantiene l'ultimo dato valido e un operatore la esamina. Il log registra ogni decisione, così un prezzo strano segnalato da un cliente si ricostruisce fino alla fonte e al ciclo che lo ha prodotto.

Pianificazione, carico e marketplace

Le sincronizzazioni non girano tutte con lo stesso ritmo: le disponibilità cambiano molto più spesso dei dati descrittivi e ogni fornitore pubblica secondo il proprio calendario, quindi la pianificazione segue i tempi delle fonti. I cicli pesanti, come la rilettura completa di un listino, vanno nelle fasce di minor traffico e spezzati in lotti: l'infrastruttura regge i picchi solo se non li provochiamo noi.

Lo stesso gestionale alimenta anche i marketplace. La pubblicazione su Amazon parte dal catalogo normalizzato, con le regole di esclusione proprie del canale, e un repricer proprietario ricalcola il prezzo tenendo conto del margine desiderato, delle commissioni e della disponibilità reale presso i fornitori. Quando la fonte cambia o la merce si esaurisce, il prezzo sul marketplace segue, e un prodotto non disponibile viene ritirato prima di generare un ordine che non possiamo evadere. Questa parte del sistema è in produzione e la evolviamo nel nostro lavoro su AI per logistica e gestionali.