Formulário da campanha como fonte única do obrigatório

É a regra que torna o formulário da campanha a única fonte do que é obrigatório. O operador marca, na aba Formulário, quais campos o participante vê e quais ele é obrigado a responder — e essa marcação passa a valer em todos os caminhos de entrada, não só na tela.

Obrigatoriedade que vale só na tela é decoração, porque a API é por onde qualquer um entra — inclusive a integração de parceiro. Por isso o cadastro do participante e o envio da nota conferem o formulário, e não só o cadastro feito pelo painel.

A regra é montada a partir dos campos ativos do formulário. Campo desativado fica de fora mesmo marcado como obrigatório: desativar é como o operador remove um campo padrão, e as duas marcas juntas não podem exigir nada. É por isso que o caminho para tirar um campo da tela é desmarcar o "ativo", não tentar apagá-lo.

São duas listas independentes — os campos do cadastro do participante e os campos da nota fiscal — e cada uma vale no seu momento.

O que é conferido é o estado final do cadastro, não o que veio no envio. Isso resolve três situações de uma vez. As respostas do participante são guardadas por pessoa e não por campanha, então o que ele respondeu numa campanha anterior conta e não é pedido de novo; o cadastro antigo se regulariza com o que a inscrição nova trouxer; e uma edição parcial não vira caminho para apagar um campo obrigatório por omissão. O preço disso é que um valor antigo inválido bloqueia até ser corrigido — aceito de propósito, porque a alternativa deixava a exigência ser só uma formalidade do primeiro cadastro.

Os caminhos que passam pela conferência são: cadastro novo pelo hotsite, segunda inscrição de quem já tem cadastro, edição de perfil na área logada, cadastro pela integração de parceiro, envio de nota pelo hotsite, envio de nota pelo parceiro e a edição do cadastro feita pelo operador no painel.

A inclusão do painel é deliberada e tem uma diferença importante: a edição pelo painel continua fora das regras de idade e razão social, porque o operador precisa conseguir corrigir um cadastro antigo que não as atende, mas passou a conferir o formulário. A distinção é o que cada regra é — idade e razão social dizem quem pode participar, e o operador não deve ser impedido de arrumar o dado; o formulário diz quais dados o cliente exige, e é exatamente o que o operador está preenchendo. Na prática, salvar a edição de um cadastro antigo obriga a preencher o campo pendente na mesma chamada.

Há dois caminhos que não conferem o formulário, de propósito: a troca de idioma do participante e a tela "Mudei de estado". Nenhum dos dois inscreve ninguém, e travá-los por um campo pendente que nada tem a ver com o que está sendo alterado deixaria a pessoa sem saída.

A recusa lista todos os pendentes de uma vez, e em duas listas separadas, porque são problemas diferentes: uma de "Preencha" com os campos que faltaram e outra de "Corrija" com os que vieram em formato inválido. A mensagem leva o rótulo da tela e nunca o valor recebido: o que a pessoa respondeu é dado dela e não volta na resposta nem vai para o log.

Campo desconhecido é ignorado nos caminhos do participante e da nota, e recusado no painel. Quem preenche o hotsite não tem como corrigir o formulário que recebeu; quem monta um pedido pelo painel, sim.

A conferência de formato reusa as validações que já existem para documento, endereço eletrônico e link. Campos de texto livre não têm forma a conferir. E o "não" de um campo de caixa de seleção não é vazio — é uma resposta válida. Quem exige o "sim" do aceite dos termos é outra configuração da campanha, não o tipo do campo.

Dois campos têm comportamento próprio. A quantidade de produtos é conferida pela soma dos itens da nota, não pelo que veio no envio, porque é isso que a nota grava. E o campo sexo tem uma borda: "prefiro não informar" conta como vazio, então com o campo obrigatório essa opção é recusada.

O CEP e o estado não dependem só do formulário. Se o CEP é obrigatório, quem decide é o formulário. Mas, quando o CEP e o estado vêm os dois preenchidos, eles precisam ser do mesmo estado, em qualquer campanha e em qualquer caminho, inclusive na edição pelo painel. E a obrigatoriedade do estado também vem da validação de estado e da restrição por estados da campanha, que estão no artigo de cadastro do participante.

O anexo da nota segue o formulário. A foto da nota era ao mesmo tempo uma chave da campanha e um campo do formulário, e quem desligava a chave continuava com a nota recusada sem anexo. Hoje quem manda é o campo do formulário, e a chave antiga ficou inerte. O anexo obrigatório é cumprido pela foto ou, sem ela, pela leitura do QR Code da nota: só com os dois vazios a nota é recusada por anexo.

Toda campanha nasce com o anexo da nota e a data da compra marcados como obrigatórios. Campanha que não quer exigir o comprovante precisa desmarcar o campo do anexo na lista da nota fiscal, campanha por campanha. Já o aceite dos termos, a validação de CNPJ, a validação da chave da nota e a validação de estado seguem como chaves da campanha, fora do formulário.

O campo valor da nota tem uma segunda fonte: a regra de geração. Com uma regra ativa que gera chance pelo valor, a nota sem valor é recusada, e o hotsite precisa saber disso antes de o participante chegar ao fim do fluxo. Por isso o obrigatório efetivo do valor é "configurado como obrigatório ou existe regra ativa por valor", e é esse efetivo que o hotsite recebe. O painel não mostra o efetivo: o cadastro do operador continua exibindo e gravando o que o cliente configurou, para o operador não ler "obrigatório" sem saber se foi ele quem marcou.

O que o cliente marca na aba Formulário vale em todo lugar: no hotsite, na integração de parceiro, na edição de perfil do participante e também na edição de cadastro feita pela operação. Não existe mais "obrigatório só na tela".

Três avisos antes de o cliente mexer com a campanha no ar.

Marcar um campo novo como obrigatório no meio da campanha tem efeito retroativo na prática. Quem já se cadastrou não respondeu aquele campo, e o operador vai topar com a exigência na primeira vez que precisar editar um desses cadastros. Marcar no começo da campanha, ou deixar o campo opcional, evita retrabalho.

Se a campanha tem integração de parceiro, tornar um campo obrigatório passa a exigir o dado do parceiro também. Confirme com o cliente que o parceiro manda aquele dado antes de marcar, senão os cadastros passam a ser recusados.

Se o cliente quer o comprovante da nota obrigatório, o lugar é o campo do anexo na lista de dados da nota fiscal, não a chave antiga da campanha. Ler o QR Code da nota já cumpre a exigência. E vale conferir o contrário: campanha que não quer exigir o comprovante precisa desmarcar esse campo.

Para fechar: campo padrão não se apaga, só se desliga; e se o cliente pergunta por que o hotsite está exigindo o valor da nota mesmo com o campo opcional, a resposta é que a campanha tem uma regra de geração por valor ativa — sem o valor não há como calcular a chance.

• Falha: o operador não consegue salvar a edição de um cadastro antigo pelo painel.
• Possivel causa: o formulário da campanha tem um campo obrigatório que aquele cadastro nunca respondeu, ou o CEP e o estado do cadastro são de estados diferentes. A conferência é do estado final do cadastro e vale também para o painel.
• Como orientar: a mensagem lista todos os campos pendentes de uma vez em duas listas — o que preencher e o que corrigir. Preencha o pendente na mesma tela e salve. Se a mensagem falar do CEP, ajuste o CEP ou o estado.
• Quando escalar: não é falha. Só escalar se a mensagem citar um campo que está desativado no formulário.

• Falha: o participante diz que preencheu tudo e o cadastro continua sendo recusado.
• Possivel causa: um valor respondido numa campanha anterior está em formato inválido e é conferido de novo agora. A recusa aponta "Corrija" e não "Preencha".
• Como orientar: leia a lista de "Corrija" na mensagem e oriente o participante a arrumar aquele dado na área logada. A mensagem nunca mostra o valor recebido, por proteção do dado.
• Quando escalar: se a mensagem citar um campo que o formulário não pede, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o hotsite exige o valor da nota mesmo com o campo marcado como opcional no painel.
• Possivel causa: a campanha tem regra de geração ativa que gera chance pelo valor. O obrigatório efetivo é a soma das duas fontes, e é isso que o hotsite recebe.
• Como orientar: explique que sem o valor não há como calcular a chance. Se o cliente quer o campo realmente opcional, o caminho é rever a regra de geração e não o formulário.
• Quando escalar: não é falha. Só escalar se não houver regra ativa por valor na campanha.

• Falha: a campanha recusa nota sem foto e o cliente não queria exigir a foto.
• Possivel causa: o campo de anexo está marcado como obrigatório no formulário da nota, como em toda campanha nova. A chave antiga da campanha não manda mais nisso.
• Como orientar: desmarque o campo de anexo na lista de dados da nota fiscal daquela campanha. Lembre também que ler o QR Code da nota já cumpre o anexo. O ajuste é de configuração e é campanha por campanha.
• Quando escalar: se o campo de anexo estiver desmarcado e a nota continuar sendo recusada sem foto, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante leu o QR Code e a nota foi recusada por falta de anexo.
• Possivel causa: a leitura não chegou com o endereço de consulta da nota, e também não havia foto. O anexo é cumprido por um dos dois.
• Como orientar: oriente a repetir a leitura do QR Code ou anexar a foto.
• Quando escalar: se a leitura tiver sido concluída com sucesso e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante escolheu não informar o sexo e o cadastro foi recusado.
• Possivel causa: o campo sexo está marcado como obrigatório no formulário e a opção de não informar conta como vazio.
• Como orientar: explique que com o campo obrigatório a opção de não informar não é aceita. Se o cliente quer permitir essa escolha, o caminho é deixar o campo opcional.
• Quando escalar: não é falha.

• Falha: um campo que o cliente marcou como obrigatório não está sendo exigido em lugar nenhum.
• Possivel causa: o campo está desativado. Campo desativado fica fora do formulário mesmo marcado como obrigatório, e as duas marcas juntas não exigem nada.
• Como orientar: marque o campo como ativo na aba Formulário. Desativar é como o operador remove um campo da tela do participante.
• Quando escalar: se o campo estiver ativo e obrigatório e ainda assim não for exigido, abrir issue no Jira (projeto DEV) com as evidências.