Uma informação importante sobre um produto fica em uma planilha. Uma orientação para atender determinado cliente está em uma conversa antiga. Um dado necessário à conferência do pedido depende de alguém lembrar de consultá-lo. Quando a operação cresce, essas informações precisam de um lugar definido e de regras claras de uso.
O PrestaShop 9.2, lançado como versão estável em 30 de setembro de 2026, inclui o sistema de propriedades extras, chamado Extra Properties na documentação. Ele permite associar campos adicionais a entidades da plataforma. A utilidade para o negócio está em estruturar um dado que não encontrou lugar adequado no cadastro existente, sem transformar todo problema operacional em um campo novo.
1. Comece pela informação que falta, não pela configuração
Antes de criar um campo, descreva uma situação concreta: qual informação falta, quem a conhece, quando ela precisa ser registrada e quem vai consultá-la. Depois, confira se a plataforma ou um módulo já possui um recurso apropriado para essa necessidade.
Uma característica pública do produto pode pertencer à ficha técnica. Uma opção comprável, como tamanho ou cor, pode exigir uma combinação com SKU, estoque ou preço próprios. Uma observação interna não é necessariamente uma característica para o cliente. Já uma etapa de aprovação exige mais do que um espaço para digitar texto.
Criar outro campo para uma informação que já existe aumenta a chance de divergência. O melhor ponto de partida é um pequeno inventário dos dados usados pela equipe, com seus responsáveis e destinos. Isso ajuda a distinguir ausência de cadastro de um problema de processo ou integração.
2. Entenda o que as propriedades extras acrescentam
O recurso organiza a definição do campo, seu tipo e a associação com uma entidade, como produto, combinação, cliente ou pedido. Há possibilidades de integração com formulários e listagens do painel e com operações da Admin API, conforme a definição configurada e o suporte da instalação.
Isso oferece uma base comum para armazenar dados adicionais. Não significa que qualquer campo criado aparecerá automaticamente em todos os lugares da loja, será preenchido pelo cliente no checkout ou passará a existir no ERP. É necessário definir onde o dado é capturado, apresentado e utilizado.
Um ponto relevante para planejamento técnico: a documentação oficial marca o código de propriedades extras como @experimental no PrestaShop 9.2. A versão da plataforma é estável, mas essa classificação do componente admite mudanças de compatibilidade em situações excepcionais. Considere isso na manutenção de módulos e nas atualizações da loja.
3. Avalie exemplos ligados à rotina da operação
Os exemplos abaixo são propostas ilustrativas de modelagem, não funcionalidades de um módulo da AGTI já anunciado:
| Necessidade | Entidade a avaliar | Decisão necessária |
|---|---|---|
| Indicar que um produto precisa de embalagem reforçada | Produto | Quem define a informação e como a expedição a consulta |
| Registrar o código da filial do comprador em um processo B2B | Cliente | Quem mantém o código e qual sistema é sua origem oficial |
| Registrar uma indicação de conferência interna do pedido | Pedido | Quem pode atualizar o dado e quais ações dependem dele |
O primeiro caso pode ser um indicador simples, se a regra tiver apenas duas opções bem definidas. O segundo exige um formato consistente e uma forma de atualização. O terceiro precisa deixar claro se o campo apenas informa uma condição ou se existe uma rotina que realmente controla a conferência.
Em todos os casos, o valor só ajuda quando chega à pessoa ou ao sistema que deve agir. Uma indicação de embalagem que ninguém vê na expedição continua sendo uma informação isolada, mesmo estando dentro da plataforma.
4. Escolha tipo, escopo e validação com cuidado
O tipo deve refletir o significado do dado. Um indicador de sim ou não, uma data e uma referência textual têm necessidades distintas. Quando há um conjunto fechado de respostas, uma lista de opções pode evitar grafias diferentes para a mesma condição.
Defina também se o valor é compartilhado, traduzido ou específico de uma loja:
| Escopo | Uso a considerar |
|---|---|
common | Um valor compartilhado entre os contextos aplicáveis |
lang | Conteúdo cujo valor depende do idioma |
shop | Informação que pode variar por loja |
A disponibilidade dos escopos depende da entidade e de sua estrutura. Não presuma que qualquer combinação de entidade e escopo será aceita. Em uma operação com várias lojas, também é necessário separar o contexto dos valores das lojas em que a definição fica visível.
Escolha limites, valores permitidos e comportamento para dados vazios. Um valor padrão não deve afirmar que uma conferência ocorreu quando ninguém a realizou. A documentação também distingue marcar um campo como obrigatório no formulário de validar o valor no servidor: uma exigência efetiva de preenchimento precisa da restrição correspondente, como NotBlank quando aplicável.
5. Defina onde o campo aparece e quem é responsável
Um campo útil precisa de nome compreensível, orientação de preenchimento e localização coerente. Se aparece longe da rotina em que a informação é conhecida, a equipe pode deixá-lo vazio ou preenchê-lo com atraso. Decida se ele será usado no formulário, em uma listagem, por uma integração ou em mais de um desses pontos.
Propriedades criadas pelo painel e propriedades registradas por módulos têm responsabilidades diferentes. Um módulo deve continuar responsável pelas definições que administra. Alterar manualmente um dado cuja estrutura é controlada por código pode criar conflito na próxima instalação ou atualização.
Também defina se o valor pode ser exposto na loja pública. A configuração de exposição não substitui uma análise do que cada integração acessa nem deve ser tratada como uma autorização granular para cada funcionário. Informações internas precisam de um destino deliberado, não de uma publicação automática por conveniência.
6. Separe armazenamento, exibição e automação
Guardar uma informação, mostrar essa informação e executar uma ação com base nela são três trabalhos distintos. Criar uma propriedade para embalagem reforçada não altera por si só a seleção da embalagem, o cálculo de frete ou a emissão de um documento.
Da mesma forma, um campo extra não se transforma automaticamente em filtro de catálogo. Um dado de cliente não passa a ser solicitado no cadastro público sem o fluxo correspondente. E um valor disponível na Admin API não será consumido por um ERP cuja integração ainda não foi adaptada.
Desenhe o caminho completo: origem, validação, gravação, leitura e uso. Quando houver troca entre sistemas, defina qual mantém o valor oficial e como tratar atualizações incompatíveis. Essa decisão evita que um novo cadastro apenas transfira a divergência da planilha para a plataforma.
7. Teste com um processo pequeno e verificável
Comece em homologação com uma necessidade bem delimitada. Registre dados novos, confira registros existentes e valide os contextos de idioma e loja utilizados pela operação. Se houver integração, teste a leitura e a escrita no caminho real que ela utiliza, não apenas a presença do campo no painel.
Faça uma pessoa da operação executar a rotina. Ela deve entender o nome, saber quando preencher e encontrar a informação no momento de usá-la. Teste também o que acontece quando o campo fica vazio ou recebe um valor inválido.
Planeje mudanças na definição e eventual remoção. A documentação diferencia retirar uma definição de eliminar também sua coluna e seus valores; não são ações equivalentes. Por isso, alterações de estrutura e migração de dados precisam de planejamento próprio, sem tentativas destrutivas na loja em produção.
8. Use o campo para organizar um processo já compreendido
Uma decisão bem descrita pode caber em uma ficha simples: nome, entidade, finalidade, tipo, responsável, momento de preenchimento, locais de consulta, integrações envolvidas e critério de aceitação. Inclua o que não deve acontecer automaticamente.
Se a equipe ainda não sabe quem produz a informação ou como ela será utilizada, criar o campo não resolve essa indefinição. Quando essas respostas estão claras, as propriedades extras podem ser avaliadas como parte de uma solução consistente, com menos dados soltos e responsabilidades mais visíveis.
A AGTI pode ajudar a avaliar se a necessidade já é atendida pela plataforma, por um módulo existente ou por uma personalização. Converse com a AGTI sobre o processo da sua loja.
Referências técnicas
- Lançamento estável do PrestaShop 9.2.
- Visão geral das propriedades extras.
- Gerenciamento de propriedades extras pelo painel.
- Registro de propriedades extras por módulos.
Fontes verificadas em 19/10/2026. O artigo explica critérios de uso; não demonstra uma instalação específica nem pressupõe que integrações e temas já estejam adaptados.