«Abbiamo Mexal in azienda e un PrestaShop che va per conto suo. Ogni mattina qualcuno aggiorna i prezzi a mano e ricopia gli ordini nel gestionale.» È la frase con cui inizia quasi ogni progetto di integrazione Mexal–PrestaShop che ci arriva. Il gestionale Passepartout Mexal governa anagrafiche, listini, magazzino e fatturazione; PrestaShop vende online; e in mezzo c'è una persona che fa da ponte con il copia-incolla. Questo articolo racconta come costruiamo il connettore che elimina quella persona dal loop — con l'architettura che abbiamo messo in produzione sul progetto Sogeca.
Perché non collegare PrestaShop direttamente a Mexal
La tentazione, all'inizio, è sempre la stessa: far leggere e scrivere PrestaShop direttamente sul database di Mexal, o richiamare i suoi servizi da un modulo PHP. Funziona in demo. Poi arriva il primo aggiornamento di Mexal, cambia una tabella interna o un tracciato Sprix, e l'integrazione si rompe in silenzio — di solito ci si accorge dai clienti che ordinano prodotti esauriti.
La regola che non tradiamo: tra Mexal e PrestaShop c'è sempre un middleware. Un servizio dedicato che parla a Mexal con i protocolli ufficiali (Sprix, ShakerWS, file di scambio) ed espone a PrestaShop un'API REST stabile e versionata. Quando Mexal cambia, si aggiorna solo il middleware; PrestaShop non se ne accorge. È lo stesso principio di disaccoppiamento che descriviamo nell'articolo sull'integrazione Mexal con l'e-commerce, applicato al caso specifico di PrestaShop.
Cosa si sincronizza, e in che direzione
Un'integrazione Mexal–PrestaShop non è un unico flusso: sono quattro flussi distinti, ciascuno con la propria direzione e la propria frequenza.
- Catalogo prodotti (Mexal → PrestaShop). Codice articolo, descrizione, categoria, immagini, attributi. Mexal è la fonte di verità: i prodotti nascono nel gestionale e vengono pubblicati sullo shop.
- Listini e prezzi (Mexal → PrestaShop). Prezzo di listino, sconti, prezzi speciali per gruppo cliente. In contesto B2B, il prezzo dipende dal cliente loggato: il middleware calcola il prezzo finale applicando le regole Mexal.
- Giacenze (Mexal → PrestaShop). La disponibilità di magazzino, aggiornata con la frequenza giusta per evitare l'over-selling senza sovraccaricare Mexal.
- Ordini (PrestaShop → Mexal). L'ordine confermato online viene scritto in Mexal come ordine cliente, pronto per l'evasione e la fatturazione.
Il catalogo: mappare, non specchiare
L'errore classico è voler replicare in PrestaShop la struttura di Mexal così com'è. Ma le anagrafiche gestionali sono nate per la contabilità, non per la vendita online: codici tecnici, unità di misura, categorie merceologiche fiscali. Il middleware fa un lavoro di mappatura — non di specchio — trasformando l'articolo Mexal in un prodotto PrestaShop con categorie navigabili, attributi filtrabili (taglia, colore, formato) e combinazioni. Le varianti Mexal (articoli a taglia/colore) diventano combinazioni PrestaShop, non prodotti separati.
Giacenze: real-time o batch?
La domanda più frequente. Non c'è una risposta unica, dipende dal volume e da quanto è critico l'over-selling.
- Catalogo con pochi pezzi o prodotti unici: interrogazione real-time al checkout. Zero rischio di vendere ciò che non c'è.
- Volumi alti, prodotti a scorta: aggiornamento batch ogni 5–15 minuti con cache in PrestaShop. Riduce drasticamente il carico su Mexal.
- Vendita multi-canale (shop + punto vendita + B2B): modello a eventi. Ogni movimento di magazzino rilevante allinea la disponibilità sui canali, così lo stesso pezzo non viene venduto due volte.
Ordini verso Mexal: la parte dove i progetti falliscono
Leggere da Mexal è facile. Scrivere ordini è dove serve disciplina. Tre regole non negoziabili.
- Idempotenza. Ogni ordine porta un identificativo univoco lato PrestaShop. Se la scrittura su Mexal va in timeout e si riprova, non nasce un ordine doppio.
- Coda persistente. L'ordine non viene mai scritto su Mexal in modo sincrono durante il checkout. Finisce in una coda; un worker dedicato lo processa con retry progressivi. Il cliente conferma l'acquisto in millisecondi, l'ordine arriva in Mexal in modo affidabile poco dopo.
- Riconciliazione notturna. Un controllo che ogni notte confronta ordini PrestaShop e ordini Mexal e segnala le discrepanze. È la rete di sicurezza che intercetta i casi limite prima che diventino un problema amministrativo.
Il caso Sogeca
Sogeca è un'azienda di distribuzione che vende a rivenditori con listini personalizzati. Aveva Mexal come gestionale e la necessità di un portale B2B dove i clienti ordinassero online vedendo i propri prezzi. Abbiamo costruito il connettore Mexal–PrestaShop con middleware dedicato: catalogo e listini scendono da Mexal, il prezzo mostrato dipende dal cliente loggato, gli ordini risalgono in Mexal pronti per l'evasione. Il risultato: niente più inserimento manuale degli ordini, prezzi sempre allineati al gestionale, e una persona liberata dal copia-incolla quotidiano.
Errori che vediamo ricorrere
- Connessione diretta al database Mexal: si rompe a ogni aggiornamento.
- Sincronizzazione bidirezionale sullo stesso dato (es. anagrafica scritta da entrambi i lati): genera conflitti ingestibili. Per ogni dato, una sola fonte di verità.
- Cache di prezzi e giacenze senza invalidazione: lo shop mostra dati sbagliati per ore.
- Nessun monitoraggio: l'integrazione si ferma di notte e ce ne si accorge il giorno dopo dai clienti.
In sintesi
Integrare Mexal con PrestaShop non significa incollare due sistemi: significa costruire in mezzo un livello che parla a entrambi con le loro regole. Mexal resta il gestionale — governa anagrafiche, listini, magazzino, fatture. PrestaShop resta la vetrina. Il middleware fa in modo che l'uno rifletta l'altro senza intervento umano. È la formula con cui abbiamo messo in produzione integrazioni che girano ogni giorno, e Sogeca ne è la prova.