Chi ha cambiato quel prezzo: storico delle modifiche ai prodotti in PrestaShop

Lunedì mattina. Un cliente scrive perché ha comprato un prodotto a un prezzo senza senso: la metà del normale. Guardi la scheda e, in effetti, il prezzo è sbagliato. Chi l'ha cambiato? Quando? Quanto costava prima? Quanti ordini sono entrati con quel prezzo?

In un negozio PrestaShop standard, la risposta onesta è «non lo sappiamo». E la conversazione che segue nel team di solito è scomoda, perché tutti dicono di non aver toccato niente.

Perché PrestaShop non lo sa

Il database di PrestaShop salva lo stato attuale di ogni prodotto: prezzo, stock, descrizione, se è attivo. Quando qualcuno salva una modifica, il nuovo valore sostituisce il precedente e il precedente scompare.

Ciò che invece salva:

• La data dell'ultima modifica del prodotto (date_upd), senza dire cosa è cambiato né chi l'ha fatto.
• Il log di sistema (Parametri avanzati > Log), che a seconda della versione annota alcune azioni dei dipendenti, ma senza il valore prima e dopo.
• I movimenti di stock, quando la gestione avanzata è attiva o nelle versioni che li registrano, che dicono quanto si è mosso ma non raccontano il resto della scheda.

Per sapere cosa è successo ti serve quello che si chiama un registro di audit: una riga per modifica, con chi, quando, quale campo, il valore precedente e quello nuovo.

Quali modifiche conviene registrare

Non tutti i campi contano allo stesso modo. In ordine di quanti dispiaceri danno:

1. Prezzo di vendita e prezzo di costo. Un errore qui diventa denaro il giorno stesso.
2. Stock. Separando le rettifiche manuali dai movimenti che arrivano dagli ordini e dalle sincronizzazioni con l'ERP.
3. Attivazione. Un prodotto disattivato sparisce dal catalogo e dai feed di Google Shopping o dei marketplace.
4. Categoria predefinita e associazioni. Incidono sull'URL, sul breadcrumb e sul posizionamento.
5. Nome, descrizione e URL semplificato. Un cambio di URL senza redirect è una pagina persa su Google.
6. Riferimenti e codici (riferimento, EAN): da loro dipendono il magazzino, l'ERP e i marketplace.
7. Peso e dimensioni. Cambiano quanto fai pagare la spedizione.

Cosa deve avere un buono storico

• Il dipendente, con il suo nome, non solo un numero.
• Data e ora esatte.
• L'origine: back office, importazione CSV, webservice o un modulo. Molte sorprese non le fa una persona, ma un'integrazione.
• Il prima e il dopo di ogni campo, nella stessa riga.
• Filtri per prodotto, dipendente, campo e date.
• Esportazione per incrociarlo con gli ordini o mostrarlo a chi di dovere.
• Conservazione configurabile: tenere tutto per sempre riempie il database; meglio un periodo ragionevole e pulizia automatica.

Casi in cui si usa

Il prezzo che nessuno ha cambiato

Un negozio di alimentari trova ogni pochi giorni prodotti con il prezzo a zero. Nessuno del team li ha toccati. Lo storico mostra che la modifica arriva dal webservice, sempre alla stessa ora: il connettore dell'ERP invia il prezzo vuoto quando un articolo non ha un listino assegnato. Senza l'origine annotata, avrebbero continuato a sospettare del team.

Lo stock che non torna

Un distributore B2B fa l'inventario e mancano unità. Con la cronologia del prodotto si vede ogni rettifica manuale, ogni movimento da ordine e ogni sincronizzazione. La differenza compare in una rettifica manuale che qualcuno ha fatto sulla combinazione sbagliata.

La scheda che ha perso posizioni

Un prodotto che vendeva bene scende su Google. Lo storico dice che tre settimane fa sono stati cambiati il nome e l'URL semplificato, senza impostare un redirect. Si ripristina l'URL precedente o si crea il redirect, e si sa esattamente quale testo c'era prima.

Quanti ordini sono entrati con il prezzo sbagliato

Con l'ora esatta della modifica e quella della correzione, filtri gli ordini di quell'intervallo con quel prodotto. Sai già a chi devi scrivere e quanto ti è costato.

Come organizzarlo nel team

• Un dipendente per persona. Se tre persone condividono lo stesso account del back office, qualsiasi storico dirà solo «è stato l'account del negozio». Ognuno con il proprio e con il profilo di cui ha bisogno.
• Account propri per le integrazioni. L'ERP, il connettore dei fornitori e il marketplace, ciascuno con la sua chiave del webservice: così la loro origine si distingue.
• Revisione settimanale. Un'occhiata al riepilogo della settimana: chi ha cambiato di più, quali campi e quali prodotti. Ciò che è strano salta all'occhio.
• Conservazione concordata. Qualche mese di solito basta per il lavoro quotidiano; se vendi prodotti con prezzi regolamentati o da contratto, forse ti serve di più.

Aiuta anche quando aggiorni

Quando aggiorni PrestaShop o un modulo, o migri di versione, capita spesso che qualche processo inizi a toccare campi che prima non toccava: un modulo che riscrive i prezzi quando viene reinstallato, un'importazione che ora interpreta i decimali in modo diverso. Avere lo storico attivo prima dell'aggiornamento ti permette di vedere, il giorno dopo, se qualcosa ha modificato prodotti senza che nessuno l'abbia chiesto.

Checklist

• Ogni persona del team con il proprio account dipendente.
• Ogni integrazione con la propria chiave del webservice.
• Storico attivo almeno per prezzo, costo, stock, attivazione, categoria, nome e URL.
• Periodo di conservazione deciso e pulizia automatica.
• Revisione periodica del riepilogo.
• Prima e dopo un aggiornamento, un'occhiata alle modifiche.

Come risolverlo in PrestaShop

Full Product Log registra ogni modifica ai tuoi prodotti con il dipendente, la data e l'ora, l'indirizzo da cui è stata fatta e il valore precedente accanto al nuovo, su fino a 84 campi che scegli di monitorare. Sopra l'elenco hai il riepilogo del periodo, con chi modifica di più, quali campi e quali prodotti, e ogni nome è una scorciatoia che filtra l'elenco. Ogni prodotto ha la sua cronologia, i movimenti di stock che arrivano dal webservice dall'ERP vengono annotati, esporti in CSV ciò che stai guardando e decidi per quanto tempo conservarlo. Non modifica i tuoi prodotti né aggiunge nulla alla vetrina, e funziona in multinegozio, da PrestaShop 1.7.6 a 9.