# Simplificar o formulário de morada do PrestaShop para os clientes portugueses

> Numa loja portuguesa a vender a clientes portugueses, metade dos campos apresentados por omissão não serve para nada. O que é mesmo necessário, o ganho do código postal, o caso das ilhas e a medida mais rentável do formulário.

- Página: <https://www.datafirefly.com/pt/2026/10/08/simplificar-formulario-morada-prestashop-portugal/>
- Idioma: pt
- Publicado em: 2026-10-08
- Atualizado em: 2026-10-08
- Outros idiomas: [fr](https://www.datafirefly.com/2026/10/08/simplifier-formulaire-adresse-prestashop-france/index.md), [en](https://www.datafirefly.com/en/2026/10/08/simplify-address-form-prestashop/index.md), [es](https://www.datafirefly.com/es/2026/10/08/simplificar-formulario-direccion-prestashop-espana/index.md), [de](https://www.datafirefly.com/de/2026/10/08/adressformular-prestashop-vereinfachen-deutschland/index.md), [it](https://www.datafirefly.com/it/2026/10/08/semplificare-modulo-indirizzo-prestashop-italia/index.md), [pl](https://www.datafirefly.com/pl/2026/10/08/uproszczenie-formularza-adresowego-prestashop-polska/index.md), [nl](https://www.datafirefly.com/nl/2026/10/08/adresformulier-vereenvoudigen-prestashop-nederland/index.md)
- Índice: <https://www.datafirefly.com/pt/2026/llms.txt>

O formulário de morada é o mais longo do processo de compra e o que produz mais abandonos depois da escolha do modo de entrega. Numa loja portuguesa a vender a clientes portugueses, metade dos campos apresentados por omissão não serve para nada.

A análise geral do checkout no telemóvel foi tratada à parte. Este artigo trata do formulário de morada em si.

## O que é realmente necessário

Para entregar em Portugal, sete informações chegam.

Nome próprio, apelido, rua e número de porta, código postal, localidade, país, telemóvel.

Tudo o resto é facultativo ou depende da sua atividade. Vejamos os campos habitualmente apresentados e o que valem.

**A empresa** só serve em B2B. Numa loja de grande público, ocupa uma linha para nada. Numa loja mista, revela-se conforme o tipo de conta.

**O NIF** merece um tratamento próprio em Portugal, e é a diferença principal face a outros mercados. Muitos clientes particulares querem a fatura com o número de contribuinte, para despesas de saúde, educação ou dedução. O PrestaShop não tem campo NIF próprio: usa-se o campo de número de identificação fiscal previsto para o IVA. Mantenha-o visível e facultativo também em B2C, com a menção de que serve para a fatura.

**O complemento de morada** é útil, deve ficar facultativo e discreto. Muitas configurações apresentam dois campos de complemento, o que é excessivo. Em Portugal serve sobretudo para andar, fração e lote.

**O telefone fixo e o telemóvel** em dois campos distintos já não fazem sentido. Um campo chega, e o telemóvel é o que serve à transportadora.

**A etiqueta da morada**, «Casa» ou «Escritório», só interessa a um cliente que guarda várias moradas. Gere-a automaticamente e não a peça na primeira encomenda.

## O código postal e a localidade

É o ganho mais rápido do formulário.

Em Portugal, o código postal de sete dígitos identifica a localidade e, na maioria dos casos urbanos, a própria artéria. Um código introduzido pode portanto preencher a localidade e propor a rua, a partir da base de códigos postais dos CTT.

Três benefícios: um campo a menos para escrever, menos erros de digitação e um controlo de coerência gratuito entre os valores.

Quatro precauções técnicas.

**O campo tem de aceitar o formato 0000-000**, com e sem hífen, e chamar um teclado numérico no telemóvel.

**A localidade tem de continuar editável.** Há freguesias e lugares que o cliente prefere usar em vez do nome oficial da localidade postal.

**Os códigos de quatro dígitos antigos**, ainda escritos por alguns clientes, devem ser aceites e completados em vez de rejeitados.

**Os códigos das regiões autónomas**, que começam por 9, têm de ser reconhecidos, o que nem sempre acontece em bases de correspondência incompletas.

## O caso dos Açores e da Madeira

Assunto mal tratado por muitas lojas, e que produz encomendas impossíveis de honrar.

Três pontos a decidir explicitamente.

**Entrega?** Se não, a zona tem de ser excluída das opções, não deixada selecionável para dar erro no momento do pagamento.

**Os portes e os prazos são diferentes.** Um tarifário de continente aplicado a uma entrega insular faz-lhe perder dinheiro em cada encomenda. Uma dificuldade adicional: o PrestaShop não fornece estados ou regiões para Portugal, pelo que a separação se faz por prefixo de código postal ou por transportadoras distintas.

**A fiscalidade é diferente.** As regiões autónomas têm taxas de IVA próprias, mais baixas do que as do continente, o que tem consequências nos preços apresentados e nos seus documentos. É um ponto a validar com o contabilista em vez de improvisar.

A configuração mínima consiste em distinguir estes destinos nas suas zonas de entrega, com as suas próprias transportadoras e as suas próprias regras.

## O preenchimento automático

É a medida mais rentável do formulário, e só exige acrescentar atributos.

Os navegadores e os gestores de palavras-passe sabem preencher um formulário de morada completo num gesto, desde que cada campo declare o que espera: nome próprio, apelido, linha de morada 1, código postal, localidade, país, telefone.

Sem essas declarações, o navegador não reconhece nada e o cliente escreve tudo.

Dois pontos complementares. O **nome dos campos** também conta: nomes técnicos como «field_3» impedem qualquer reconhecimento heurístico. E a **estrutura** tem de se manter clássica: um formulário reconstruído dinamicamente com componentes exóticos perde essa compatibilidade.

Um teste simples: abra o seu checkout num navegador onde já exista uma morada guardada e clique no campo do nome. Se não for proposto nada, faltam-lhe os atributos.

## A autocompletar da morada

Nível seguinte, a implementar depois dos pontos anteriores.

O princípio: o cliente escreve os primeiros carateres da morada, aparece uma lista de propostas, ele seleciona e todos os campos se preenchem.

Três benefícios mensuráveis: tempo de escrita dividido, erros de digitação eliminados e moradas normalizadas, o que reduz as falhas de entrega.

Duas precauções. O **campo manual tem de continuar acessível**, para as moradas recentes ou atípicas que a base não conhece. E o uso de um serviço externo obriga a verificar o que é transmitido e a mencioná-lo na sua política de privacidade.

Ponto prático: não existe em Portugal uma base pública gratuita de moradas equivalente à que a França disponibiliza. As duas vias realistas são a base de códigos postais dos CTT, sob licença, e um serviço comercial como o Google Places.

## A validação

Quatro regras que reduzem os erros sem irritar.

**Valide ao longo da escrita**, campo a campo, em vez de mostrar cinco erros depois de submeter.

**Valide à saída do campo**, não a cada carater. Uma mensagem de erro que aparece logo na primeira letra é irritante.

**Seja tolerante no formato.** Um número de telefone escrito com espaços, pontos ou o indicativo +351 tem de ser aceite e normalizado, não rejeitado. Em Portugal, o telemóvel começa por 9 e o fixo por 2, e não existe prefixo interurbano a retirar.

**Formule o erro em ação.** «O código postal tem sete dígitos, no formato 1000-001» vale mais do que «Campo inválido».

## A morada de faturação

Questão a decidir, porque duplica o formulário.

Numa loja de grande público, a morada de faturação é igual à de entrega na grande maioria dos casos. O comportamento esperado é portanto uma caixa assinalada por omissão, com o segundo formulário recolhido.

Duas exceções. Em **B2B**, a dissociação é frequente e tem de continuar fácil de aceder. Nas **prendas**, também, em que quem paga e quem recebe são pessoas diferentes.

Ponto de conformidade: a fatura tem de levar a morada de faturação e o NIF indicado, e a guia de entrega a morada de entrega. Um único campo para as duas produz documentos incorretos assim que diferem, e a fatura sai do programa certificado com dados errados.

## O que não deve fazer

**Impor um formato de escrita.** Um cliente que escreve a morada em maiúsculas ou em minúsculas tem de ser aceite. A normalização faz-se do lado do servidor.

**Proibir carateres acentuados.** Os nomes de ruas e de localidades têm-nos, e rejeitá-los é um erro de conceção.

**Limitar demasiado o comprimento.** Há moradas longas, com nome de urbanização, lote, andar e fração.

**Pedir o e-mail duas vezes.** Esta prática duplica a escrita sem reduzir significativamente os erros, e impede o preenchimento automático.

## Medir

Três indicadores.

A **taxa de abandono na etapa da morada**, separadamente no telemóvel e no computador.

O **tempo médio de preenchimento**, que desce bastante com o preenchimento automático e a autocompletar.

A **taxa de falha de entrega** por morada incorreta, que mede a qualidade dos dados recolhidos e tem um custo direto.

O  retoma este formulário no PrestaShop 8 e 9: campos reduzidos ao necessário com revelação condicional dos campos profissionais, preenchimento da localidade pelo código postal, atributos de preenchimento automático corretamente colocados, validação ao longo da escrita e morada de faturação recolhida por omissão.