Regras do cadastro do participante

São as regras que decidem quem pode se inscrever numa campanha e o que o sistema exige em cada caminho de entrada. O ponto de partida que explica todo o resto: o cadastro é único por documento no cliente, e a participação é por campanha. Com duas campanhas no ar, o mesmo CPF se inscrevendo na segunda cai no caminho do "cadastro que já existe".

A senha na segunda inscrição

Quando o documento já existe no cliente, a senha é conferida antes de qualquer gravação. Senha errada, ou cadastro sem senha (criado por integração de parceiro), recusam a inscrição e nada é gravado. A mensagem leva ao login.

Quem veio de uma campanha migrada do sistema anterior entra com a senha que usava lá. As regras desse caso estão no artigo da senha do sistema anterior.

Idade

A campanha tem uma configuração que significa "permite menor de idade". A tradução dela para a exigência é esta:

• desligada (que é o padrão): mínima de 18 anos e data de nascimento obrigatória;
• ligada, com idade mínima configurada: a mínima configurada, e data de nascimento obrigatória;
• ligada, sem idade mínima: sem mínima, e data de nascimento opcional;
• documento CNPJ: a idade não se aplica, e a data de nascimento é opcional.

A referência é o dia de Brasília. Perto da meia-noite, o relógio universal já está no dia seguinte, e quem faz aniversário amanhã entraria hoje.

Razão social

É obrigatória em CNPJ. Em CPF o valor é descartado, não recusado — o campo não se aplica, e recusar obrigaria o hotsite a saber o tipo do documento antes de montar o pedido. Enviar o campo em branco não apaga a razão social já cadastrada, senão quem edita por uma tela que não tem o campo zeraria o dado por omissão.

Estado

Duas configurações da campanha tornam o estado obrigatório no cadastro, e não só na nota:

• a validação de estado, que exige que a nota seja do estado onde o participante mora. Recusar a nota de quem se inscreveu sem estado resolveria o sintoma e deixaria a causa — o erro apareceria só na primeira nota, longe de onde foi criado;
• a campanha restrita a alguns estados. Aqui, além de obrigatório, o estado do cadastro tem de ser um dos estados da campanha. Fora da lista, a recusa é "Esta promoção não é válida no estado onde você reside." Mudar a lista com a campanha no ar não mexe em quem já entrou: vale para as inscrições seguintes.

No hotsite, o seletor de estado do cadastro lista todos os estados, e a tela avisa no início quando a promoção vale só para alguns. Quem já tem cadastro com outro estado e se mudou tem uma saída própria, sem entrar na campanha: a tela "Mudei de estado", explicada em artigo próprio.

CEP e estado precisam combinar

Quando o CEP e o estado vêm os dois preenchidos e apontam para estados diferentes, o cadastro é recusado com a mensagem de que o CEP informado é de outro estado. Antes, o cadastro entrava com o CEP de um estado e a residência declarada em outro, e a campanha por estado acabava aceitando quem ela existe para excluir.

• O estado do CEP sai de uma tabela fixa das faixas de CEP dos Correios, conferida sem depender de serviço externo. Se o serviço de busca de endereço estiver fora do ar, a regra continua valendo igual.
• Sem um dos dois lados não há o que comparar: CEP vazio ou estado não informado não são recusados por esta regra. Se o CEP é obrigatório, quem exige é o formulário da campanha.
• Vale em todos os caminhos de gravação de endereço: cadastro novo pelo hotsite e pelo parceiro, segunda inscrição, edição do perfil, "Mudei de estado" e também a edição pelo painel — ao contrário da idade e da razão social, porque um par CEP e estado impossível é um endereço que não existe.
• São duas recusas diferentes: "o CEP não é deste estado" é uma; "este estado não participa da promoção" é outra. O CEP pode estar certo para o estado e a campanha ainda assim não aceitar aquele estado.

A porta única

Idade, razão social e estado são conferidos sobre o estado atual do cadastro, nunca sobre o que veio no pedido. Essa única decisão resolve dois casos de uma vez: o cadastro antigo sem data de nascimento se regulariza com o que a inscrição nova trouxer, e a edição do perfil não pode apagar a data ou o estado para escapar da regra.

A conferência vale nos quatro caminhos: participante novo, segunda inscrição, cadastro por parceiro e edição do perfil pelo hotsite. A regra é sobre quem participa, não sobre o canal da inscrição.

Não vale na edição pelo painel, e isso é intencional: o operador precisa conseguir corrigir um cadastro antigo que não atende à regra. O painel, porém, confere o formulário da campanha — obrigatoriedade e tipo de cada campo — e a coerência entre CEP e estado sobre o estado final, antes de gravar. A diferença é deliberada: idade e razão social são sobre quem pode participar, e o operador não deve ser impedido de arrumar o dado; o formulário é sobre quais dados o cliente exige, e o par CEP e estado é sobre o endereço existir.

Aceite do regulamento

Na campanha com aceite obrigatório, a inscrição sem o aceite dos termos é recusada, em todos os caminhos — inclusive no parceiro, que manda o aceite junto do cadastro. A data do aceite fica gravada na própria inscrição.

Quem se inscreveu antes de a campanha passar a exigir o termo, ou veio de uma campanha migrada, pode estar sem o aceite. Para esse caso:

• o hotsite mostra "Falta aceitar o regulamento" na área logada, e o participante aceita ali, sem refazer o cadastro;
• até aceitar, a nota e o story são recusados, com a mensagem pedindo que ele aceite o regulamento na área logada. Isso vale também para a nota enviada pelo parceiro: consentimento é dado pela própria pessoa;
• o aceite só liga. Repetir não muda a data do primeiro aceite, e não há como desligar um aceite pela tela — revogar consentimento é outro fluxo, que ainda não existe;
• participação cancelada não registra aceite.

Inscrições antigas aparecem com o aceite e sem data. Isso é o dado real de quem se inscreveu antes da data começar a ser gravada, não um erro.

Duplicidade

"Já existe" responde conflito pelos dois caminhos: a conferência normal e a colisão de duas requisições simultâneas (o duplo clique). Também cai aqui quem saiu da campanha e tenta se recadastrar nela. O remédio é ir ao login, não corrigir o formulário.

Campos personalizados

Os campos personalizados são definidos por campanha, mas gravados no cadastro global do participante — um conjunto por pessoa. A consequência prática: o que o participante já respondeu numa campanha anterior conta, porque o valor está no mesmo lugar, e pedi-lo de novo recusaria quem já informou.

O perfil só devolve ao hotsite os campos personalizados do formulário da campanha daquele acesso, nunca o conjunto inteiro — o que a tela lê é exatamente o que ela pode gravar.

Senha

Trocar a senha pede a senha atual. O token prova quem abriu a sessão, não quem está no teclado agora. Senha atual errada recusa e nada é gravado.

Não existe tela de trocar senha para o participante logado — só a redefinição pelo link de recuperação. Vale não prometer o que não existe.

O "esqueci a senha" é do cadastro, não da participação: ele acha o cadastro pelo documento ou pelo e-mail e não confere participação na campanha, porque a senha é do cadastro único e trocá-la não abre sessão nenhuma. É o login seguinte que aplica a regra da participação. O link de recuperação vai por e-mail: cadastro sem e-mail não recebe o link. O cadastro sem senha, criado por integração de parceiro, fica fora dos dois caminhos: quem é gerido pelo parceiro não entra por senha, e nem a segunda inscrição nem a recuperação devem criar um acesso que nunca existiu.

Segunda inscrição consultável

O hotsite consegue perguntar antes o que falta para o participante se inscrever numa campanha nova com o cadastro que ele já tem. O fluxo é: o login avisa que ele ainda não participa daquela campanha, ele clica em "Participar desta campanha", confirma a senha e o sistema devolve só o que falta. As guardas rodam todas, e antes de pedir qualquer campo — inclusive a do estado, e é nesse ponto que a tela oferece o link "Mudei de estado" para quem mora fora dos estados da campanha.

O cadastro é único por documento no cliente. Isso tem uma consequência boa e uma a avisar.

A boa: quem já participou de uma campanha do cliente se inscreve na seguinte sem preencher tudo de novo — o sistema pede só o que falta, e o que foi respondido antes conta.

A avisar: na segunda inscrição a senha é conferida. Participante que esqueceu a senha precisa usar o link de recuperação, não tentar se cadastrar de novo.

Sobre idade: campanha que não permite menor de idade exige data de nascimento e 18 anos completos, contados pelo dia de Brasília. É o padrão.

Sobre CNPJ: razão social é obrigatória, e a idade não se aplica.

Sobre estado: se o cliente ligar a validação de estado ou restringir a campanha a alguns estados, o estado passa a ser obrigatório na inscrição, inclusive na integração de parceiro. Antes de ligar numa campanha que já está no ar com integração, confirme que o parceiro manda o estado — senão o cadastro passa a ser recusado. E o CEP precisa ser do mesmo estado informado.

Sobre o aceite: se a campanha passar a exigir o aceite do regulamento depois de ter participantes, quem já estava inscrito aceita pela área logada antes de mandar a próxima nota.

E um ponto para não prometer: o participante logado não tem tela de trocar senha. A troca é pelo link de recuperação.

• Falha: o participante tenta se cadastrar numa campanha nova e recebe recusa de senha.
• Possivel causa: o documento dele já existe no cadastro do cliente, e a senha é conferida antes de abrir a participação nova.
• Como orientar: oriente a ir ao login e, se não lembrar a senha, usar o link de recuperação. Depois disso a inscrição na campanha nova segue normalmente.
• Quando escalar: se a senha estiver correta e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante que veio por integração de parceiro não consegue entrar nem recuperar a senha.
• Possivel causa: o cadastro criado pela integração de parceiro não tem senha, e nem a segunda inscrição nem a recuperação criam um acesso que nunca existiu.
• Como orientar: explique que quem é gerido pelo parceiro não entra por senha. O caminho é o parceiro, não o hotsite.
• Quando escalar: não é falha. Se o cliente precisar que esse participante passe a ter acesso próprio, abrir issue no Jira (projeto DEV) descrevendo o caso.

• Falha: o participante não consegue salvar o perfil e o sistema pede a data de nascimento.
• Possivel causa: a campanha exige a idade mínima e o cadastro antigo não tem a data. A conferência é sobre o estado final do cadastro, então a data passou a ser necessária.
• Como orientar: oriente a informar a data de nascimento. O operador também pode corrigir pela edição de cadastro no painel, que não aplica essa exigência.
• Quando escalar: se a data estiver preenchida e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o cadastro por integração de parceiro passou a ser recusado numa campanha que funcionava.
• Possivel causa: a validação de estado ou a restrição por estados foi ligada na campanha, e com ela o estado virou obrigatório na inscrição por todos os canais.
• Como orientar: confirme com o cliente o que foi ligado e alinhe com o parceiro o envio do estado. Essa é a mudança que mais quebra integração em campanha no ar.
• Quando escalar: se o parceiro estiver mandando o estado e a recusa continuar, acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o cadastro é recusado dizendo que o CEP é de outro estado.
• Possivel causa: o CEP e o estado informados apontam para estados diferentes. O sistema confere os dois quando os dois vêm preenchidos.
• Como orientar: oriente a conferir o CEP e escolher o estado do endereço onde a pessoa mora. A própria mensagem diz de qual estado é o CEP.
• Quando escalar: se o CEP for de fato do estado escolhido e a recusa continuar, abrir issue no Jira (projeto DEV) com o CEP, o estado e a mensagem.

• Falha: o participante recebe "Esta promoção não é válida no estado onde você reside".
• Possivel causa: a campanha é restrita a alguns estados e o estado do cadastro dele não está na lista.
• Como orientar: se ele de fato mora num estado que participa e o cadastro está com o estado antigo, oriente a usar o link "Mudei de estado" na tela de login. Se ele mora num estado fora da lista, a promoção não vale para ele.
• Quando escalar: se o estado do cadastro estiver na lista da campanha e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: a nota ou o story é recusado pedindo que o participante aceite o regulamento.
• Possivel causa: a campanha exige o aceite e a inscrição dele é de antes dessa exigência, ou veio de uma campanha migrada.
• Como orientar: oriente o participante a entrar na área logada e aceitar o regulamento. Depois disso a mesma nota pode ser enviada de novo.
• Quando escalar: se o participante já tiver aceitado e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante recebe mensagem de que o cadastro dele já existe e não consegue prosseguir.
• Possivel causa: há cadastro com aquele documento no cliente, ele saiu daquela campanha antes, ou o pedido chegou duas vezes por duplo clique.
• Como orientar: oriente a ir ao login. Se ele saiu daquela campanha, não volta a se inscrever nela, mas pode nas próximas campanhas do cliente.
• Quando escalar: se não houver cadastro com aquele documento e a mensagem continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o operador quer corrigir um cadastro antigo que não atende à regra de idade e não consegue.
• Possivel causa: a edição pelo painel não aplica as regras de idade, razão social e estado da campanha, de propósito. Se houve recusa, ela veio do formulário da campanha ou da coerência entre CEP e estado.
• Como orientar: leia a mensagem. Se ela nomeia um campo do formulário, preencha esse campo; se fala do CEP, ajuste o CEP ou o estado. A edição pelo painel é justamente o caminho para arrumar cadastro antigo.
• Quando escalar: se a recusa falar de idade ou razão social na edição pelo painel, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante quer trocar a senha estando logado e não acha a opção.
• Possivel causa: não existe tela de troca de senha para o participante logado. A troca é pelo link de recuperação.
• Como orientar: oriente a usar o "Esqueci minha senha", que envia o link para o e-mail do cadastro.
• Quando escalar: não é falha.