Quem mudou esse preço: histórico de alterações de produtos no PrestaShop

Segunda-feira de manhã. Um cliente escreve porque comprou um produto a um preço que não faz sentido: metade do normal. Vai à página do produto e, de facto, o preço está errado. Quem o mudou? Quando? Quanto custava antes? Quantas encomendas entraram com esse preço?

Numa loja PrestaShop de origem, a resposta honesta é «não sabemos». E a conversa seguinte na equipa costuma ser desconfortável, porque toda a gente diz que não mexeu em nada.

Porque é que o PrestaShop não sabe

A base de dados do PrestaShop guarda o estado atual de cada produto: o preço, o stock, a descrição, se está ativo. Quando alguém guarda uma alteração, o valor novo substitui o anterior e o anterior desaparece.

O que guarda:

• A data da última alteração do produto (date_upd), sem dizer o que mudou nem quem.
• O registo do sistema (Parâmetros Avançados > Registos), que, conforme a versão, anota algumas ações de funcionários, mas sem o valor de antes e o de depois.
• Os movimentos de stock, quando a gestão avançada está ativa ou nas versões que os registam, que dizem quanto se moveu mas não contam o resto da página.

Para saber o que aconteceu precisa daquilo a que se chama um registo de auditoria: uma linha por alteração, com quem, quando, que campo, o valor anterior e o novo.

Que alterações convém registar

Nem todos os campos importam da mesma forma. Por ordem de dissabores:

1. Preço de venda e preço de custo. Um erro aqui transforma-se em dinheiro no mesmo dia.
2. Stock. Separando os ajustes manuais dos movimentos que vêm de encomendas e de sincronizações com o ERP.
3. Ativação. Um produto desativado desaparece do catálogo e dos feeds do Google Shopping ou dos marketplaces.
4. Categoria predefinida e associações. Afetam o URL, o caminho de navegação e o posicionamento.
5. Nome, descrição e URL amigável. Uma mudança de URL sem redirecionamento é uma página perdida no Google.
6. Referências e códigos (referência, EAN): deles dependem o armazém, o ERP e os marketplaces.
7. Peso e medidas. Mudam o que cobra de envio.

O que um bom histórico tem de ter

• O funcionário, com o seu nome, não só um número.
• Data e hora exatas.
• A origem: back office, importação CSV, webservice ou um módulo. Muitas surpresas não são feitas por uma pessoa, mas por uma integração.
• O antes e o depois de cada campo, na mesma linha.
• Filtros por produto, funcionário, campo e datas.
• Exportação para o cruzar com encomendas ou mostrá-lo a quem de direito.
• Retenção configurável: guardar tudo para sempre enche a base de dados; um prazo razoável e limpeza automática.

Casos em que se usa

O preço que ninguém mudou

Uma loja de alimentação encontra, de poucos em poucos dias, produtos com o preço a zero. Ninguém da equipa lhes tocou. O histórico mostra que a alteração chega pelo webservice, sempre à mesma hora: o conector do ERP envia o preço vazio quando um artigo não tem tabela de preços atribuída. Sem a origem anotada, teriam continuado a desconfiar da equipa.

O stock que não bate certo

Um distribuidor B2B faz o inventário e faltam unidades. Com a linha temporal do produto vê-se cada ajuste manual, cada movimento de encomenda e cada sincronização. A diferença aparece num ajuste manual que alguém fez na combinação errada.

A página que perdeu posições

Um produto que vendia bem desce no Google. O histórico diz que, há três semanas, se mudou o nome e o URL amigável e não se criou redirecionamento. Repõe-se o URL anterior ou cria-se o redirecionamento, e sabe-se exatamente que texto havia antes.

Quantas encomendas entraram com o preço errado

Com a hora exata da alteração e a da correção, filtra as encomendas desse intervalo com esse produto. Fica a saber a quem tem de escrever e quanto lhe custou.

Como organizar na equipa

• Um funcionário por pessoa. Se três pessoas partilham a mesma conta do back office, qualquer histórico dirá apenas «foi a conta da loja». Cada um com a sua e com o perfil de que precisa.
• Contas próprias para integrações. O ERP, o conector de fornecedores e o marketplace, cada um com a sua chave do webservice: assim a origem distingue-se.
• Revisão semanal. Uma vista de olhos ao resumo da semana: quem mudou mais, que campos e que produtos. O que é estranho salta à vista.
• Retenção acordada. Alguns meses costumam bastar para o dia a dia; se vende produtos com preços regulados ou por contrato, talvez precise de mais.

Também ajuda ao atualizar

Quando atualiza o PrestaShop ou um módulo, ou migra de versão, é comum algum processo começar a mexer em campos em que antes não mexia: um módulo que reescreve preços ao ser reinstalado, uma importação que agora interpreta as casas decimais de outra forma. Ter o histórico ativo antes da atualização permite-lhe ver, no dia seguinte, se alguma coisa alterou produtos sem ninguém o pedir.

Checklist

• Cada pessoa da equipa com a sua própria conta de funcionário.
• Cada integração com a sua própria chave de webservice.
• Histórico ativo pelo menos para preço, custo, stock, ativação, categoria, nome e URL.
• Prazo de retenção decidido e limpeza automática.
• Revisão periódica do resumo.
• Antes e depois de uma atualização, uma vista de olhos às alterações.

Como resolver no PrestaShop

O Full Product Log regista cada alteração dos seus produtos com o funcionário, a data e a hora, o endereço a partir do qual foi feita e o valor anterior junto ao novo, em até 84 campos que escolhe vigiar. Por cima da lista tem o resumo do período, com quem muda mais, que campos e que produtos, e cada nome é um atalho que filtra a lista. Cada produto tem a sua linha temporal, os movimentos de stock que chegam pelo webservice a partir do ERP ficam anotados, exporta para CSV o que está a ver e decide quanto tempo se conserva. Não altera os seus produtos nem acrescenta nada à montra, e funciona em multiloja, do PrestaShop 1.7.6 ao 9.