Validação da nota fiscal e duplicidade

É o conjunto de conferências que a nota passa antes de gerar qualquer chance. Cada regra é um validador independente que decide sozinho se se aplica; a que falha recusa a nota com a mensagem correspondente, e nada é gravado. O fato mais contraintuitivo e o mais importante para o atendimento: a nota não passa por análise de rotina.

A nota gera na entrada

Toda nota gera na entrada — número da sorte, posição do participante, saldo e pontos. Não existe fila de análise de nota, não existe configuração de campanha para isso e a nota não tem situação. O que se confere é o prêmio, e só quando alguém ganha. Há três pontos de conferência:

• a nota que gerou a posição premiada aparece na apuração da posição, com número, valor e imagem, e a apuração tem aprovar e reprovar;
• a nota que formou o número premiado aparece na tela do ganhador, que é registrado e publicado à mão;
• a nota falsa é tratada pelo cancelamento de nota, com estorno de chance, saldo e pontos.

Se alguém do time ainda fala de "nota em análise", esse fluxo não existe: ele fazia a nota de uma campanha configurada não render nada.

A ordem das conferências

As primeiras conferências são sobre a pessoa, e falam antes de qualquer regra sobre a nota:

• participação cancelada: quem saiu da campanha não manda nota;
• bloqueio: o documento do participante na lista de bloqueio da campanha recusa a nota;
• aceite do regulamento pendente: na campanha com aceite obrigatório, quem ainda não aceitou recebe a mensagem pedindo para aceitar o regulamento na área logada. É a única das três que tem remédio: aceitou, a mesma nota passa.

Depois vêm a campanha ativa e no período, a data da compra, o valor, os campos do formulário, o CNPJ, a loja, o estado, os produtos, a chave, a duplicidade e, por último, os limites de notas por participante.

Bloqueio e participação cancelada

As duas são conferidas na nota, não só na inscrição. O bloqueio costuma entrar depois — importação de funcionários, fraude detectada — e sem conferir aqui quem já estava inscrito seguia participando. A checagem é pelo documento do participante, o mesmo critério do cadastro.

A participação cancelada é conferida duas vezes: no início e de novo logo antes de gravar. A janela era real — uma nota validada no instante anterior à saída da campanha gerava chance numa participação já cancelada. A mensagem das duas é a mesma, de propósito: para quem cadastrou, são o mesmo fato.

Loja

• Na campanha que pede a seleção de loja, a loja é obrigatória e precisa estar participando da campanha.
• Loja bloqueada na campanha recusa a nota, pelo CNPJ da nota ou pela loja escolhida, mesmo na campanha que não pede seleção de loja. O bloqueio vale só naquela campanha.
• Com a validação de CNPJ ligada, o CNPJ é obrigatório. Quando vem, ele precisa ser um CNPJ válido, com os dígitos verificadores conferidos.

Estado da nota

Duas configurações da campanha olham o estado da nota, e as duas o tornam obrigatório:

• validação de estado: o estado da nota tem de ser o mesmo do cadastro do participante. Participante sem estado no cadastro tem a nota recusada, com a mensagem pedindo para completar o cadastro;
• campanha restrita a alguns estados: o estado da nota tem de ser um dos estados da campanha.

O estado é declarado pelo participante, e isso é aceito de forma consciente: a regra barra o erro honesto e o abuso em escala, e a conferência do prêmio continua sendo o ponto em que a fraude é pega.

Produtos

Os produtos informados precisam participar da campanha e estar ativos, e o mesmo produto não pode aparecer duas vezes na mesma nota — antes, a linha repetida dobrava a geração em silêncio.

A quantidade vem dos itens quando há itens, ignorando o que veio no pedido. Há tetos fixos (999 por item, 9999 por nota) que são barreira contra entrada errada ou forjada, não alavanca de negócio.

A identidade da nota

A chave de acesso é a identidade; o número avulso não é. A chave da nota fiscal eletrônica tem 44 dígitos com dígito verificador, e já carrega dentro dela o CNPJ do emitente, a série e o número.

Com a campanha configurada para validar chave ou número, a nota precisa de chave ou número — não só chave. Quando a chave vem, a duplicidade é resolvida por ela.

Sem chave, há dois comportamentos, e a campanha escolhe o risco:

• com a configuração ligada, a duplicidade é por CNPJ e número, ignorando a série. A campanha prefere recusar a compra do segundo caixa a deixar a mesma nota entrar duas vezes e gerar números duas vezes;
• com a configuração desligada, é por CNPJ, série e número, e só quando a série vem. Sem chave e sem série não há bloqueio nenhum.

Por que a série importa: a nota de consumidor eletrônica numera por série dentro do mesmo CNPJ. Caixas diferentes da mesma loja emitem o mesmo número em séries diferentes. Então "CNPJ e número" sem série recusa nota legítima — e é essa a escolha que a configuração representa.

Nota sem CNPJ fica fora da regra de CNPJ e número: sem CNPJ não há par para comparar, e recusar só pelo número recusaria notas de lojas diferentes.

Nota de participação cancelada e nota cancelada pelo operador não contam na duplicidade: a nota cancelada pode ser recadastrada.

Dois envios simultâneos da mesma nota, como no duplo clique, não entram os dois: um deles recebe a recusa de nota já cadastrada.

O que é gravado é a forma normalizada

Não é o que veio no pedido: chave só com dígitos, número sem zeros à esquerda (000123 e 123 são a mesma nota), série sem zeros à esquerda, e CNPJ só com dígitos. Com máscara, a comparação de duplicidade nunca casaria.

Data da compra e valor

São obrigatórios conforme o formulário da campanha, como todo campo da nota, inclusive os personalizados.

O validador de data confere "não futura e dentro do período", e a data da compra é comparada por dia de calendário no fuso de Brasília — compra às 22h do último dia, que no relógio universal já é o dia seguinte, continua valendo. Ele é diferente da conferência do período da campanha, que olha a data do envio.

O valor passa a ser exigido quando alguma regra de geração ativa usa a base Valor: ela divide o valor da nota, e com zero a nota entraria e não geraria número nenhum, em silêncio.

O comprovante são dois campos

São dois, não um: o arquivo (a foto ou o PDF) e o endereço de consulta do cupom na Sefaz, que é o que o leitor de QR Code devolve no modo automático. Eles são independentes: a nota pode ter um, o outro, os dois ou nenhum.

A obrigatoriedade do anexo vem do campo correspondente do formulário, e ler o QR Code basta: o anexo é cumprido pela foto ou, na ausência dela, pelo endereço de consulta. Só com os dois vazios a nota é recusada por anexo. Isso vale para o cadastro pelo hotsite e para a integração de parceiro, que passam pelo mesmo caminho.

A leitura por QR Code é beta e ligada por configuração do hotsite da campanha.

Um ponto registrado: a foto da nota é pública, protegida apenas pelo nome aleatório do arquivo, sem login. O cupom pode conter CPF. Isso é decisão técnica em aberto e não deve ser oferecido como garantia de privacidade ao cliente.

A nota é conferida e gera na hora. Não existe fila de análise de nota — o que é analisado é o prêmio, quando alguém ganha. Se o cliente ou o participante espera uma "aprovação da nota", essa etapa não existe.

A conversa que mais aparece é a de nota recusada como repetida. Vale explicar o mecanismo: quando a nota traz a chave de acesso de 44 dígitos, ela é identificada por ela e o caso é limpo. Quando não traz, o sistema identifica pelo CNPJ e pelo número — e aí a configuração da campanha decide se a série entra ou não na comparação. Ignorando a série, duas compras feitas em caixas diferentes da mesma loja que tenham o mesmo número de nota colidem, e a segunda é recusada. É uma escolha de risco da campanha: evitar que a mesma nota entre duas vezes, ao custo de recusar essa compra legítima.

A saída recomendada para o participante nesse caso é cadastrar a nota com a chave de acesso, que resolve a identidade sem ambiguidade.

Dois avisos para quem configura: ligar o aceite obrigatório com a campanha no ar faz quem já estava inscrito precisar aceitar o regulamento antes da próxima nota; e bloquear uma loja na campanha passa a recusar as notas dela ali, mesmo sem seleção de loja.

E, sobre o comprovante: ler o QR Code basta. Quem usou o modo automático não precisa anexar a foto.

• Falha: o participante diz que a nota dele foi recusada como já cadastrada e ele nunca a cadastrou.
• Possivel causa: a campanha identifica a nota sem chave por CNPJ e número ignorando a série, e outra compra da mesma loja tem o mesmo número em outra série.
• Como orientar: oriente a cadastrar a nota informando a chave de acesso de 44 dígitos, que identifica a nota sem ambiguidade. Confira também se a nota não foi cadastrada por outra pessoa.
• Quando escalar: se a nota tiver chave e ainda assim for recusada como repetida, acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante pergunta quando a nota dele será aprovada.
• Possivel causa: não existe análise de nota. A nota gera na entrada, e o que passa por análise é o prêmio.
• Como orientar: explique que a nota já foi processada e mostre as chances que ela gerou. Se ele está aguardando um prêmio de posição premiada, é a posição que está em análise.
• Quando escalar: não é falha.

• Falha: a nota foi recusada 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 a entrar na área logada e aceitar o regulamento. Depois disso, a mesma nota pode ser enviada de novo.
• Quando escalar: se ele já tiver aceitado e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: a nota foi recusada por data da compra.
• Possivel causa: a data é futura ou está fora do período da campanha. A comparação é por dia de calendário no fuso de Brasília.
• Como orientar: confira a data da compra contra o período da campanha. Compra feita no último dia à noite continua valendo.
• Quando escalar: se a data estiver dentro do período e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: a nota foi recusada pedindo o valor e o participante diz que informou.
• Possivel causa: o valor foi informado como zero, ou não foi informado e alguma regra ativa da campanha usa a base Valor, que precisa dele.
• Como orientar: oriente a informar o valor total da nota. Sem ele a nota entraria e não geraria número nenhum.
• Quando escalar: se o valor estiver preenchido e maior que zero e a recusa continuar, 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: nem a foto nem o endereço de consulta chegaram. Ler o QR Code deveria bastar.
• Como orientar: oriente a repetir a leitura ou a anexar a foto como alternativa. A leitura por QR Code é um recurso beta e depende de a campanha ter o leitor ligado.
• Quando escalar: se o QR Code tiver sido lido com sucesso e a recusa por anexo continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: a nota foi recusada dizendo que a loja não participa.
• Possivel causa: a loja está bloqueada naquela campanha, ou a campanha pede a seleção de loja e a loja escolhida não está participando.
• Como orientar: confira a situação da loja nos vínculos da campanha. Se ela foi bloqueada por engano, ajuste o vínculo e oriente o participante a reenviar a nota.
• Quando escalar: se a loja estiver participando e não bloqueada e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: a nota foi recusada por estado.
• Possivel causa: a campanha valida o estado e o estado da nota é diferente do cadastro, o cadastro não tem estado, ou a campanha é restrita a alguns estados e o estado da nota não está na lista.
• Como orientar: leia a mensagem. Se ela pede para completar o cadastro, oriente a informar o estado no perfil. Se o estado da nota não confere, oriente a informar o estado correto da compra.
• Quando escalar: se o estado da nota for o mesmo do cadastro e estiver entre os da campanha e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: a nota foi recusada por bloqueio e o participante estava participando normalmente.
• Possivel causa: o documento dele entrou na lista de bloqueio depois da inscrição, por importação ou por decisão da operação. O bloqueio é conferido na nota também.
• Como orientar: confira a lista de bloqueios da campanha e do cliente. Se o bloqueio foi indevido, retire-o e oriente a recadastrar a nota.
• Quando escalar: não é falha. Só escalar se o documento não estiver em nenhuma lista de bloqueio.

• Falha: a nota foi recusada dizendo que a participação está cancelada.
• Possivel causa: a participação do participante naquela campanha foi cancelada, pelo painel ou pela saída dele no hotsite.
• Como orientar: confira a situação da participação no painel. Quem saiu pelo hotsite não volta a se inscrever naquela campanha, mas pode nas próximas do cliente.
• Quando escalar: não é falha. Só escalar se a participação estiver ativa e a recusa continuar.

• Falha: o participante informou o número com zeros à esquerda e a nota foi recusada como repetida.
• Possivel causa: o número é gravado sem zeros à esquerda, então 000123 e 123 são a mesma nota.
• Como orientar: explique que a nota já consta cadastrada. Confira no detalhe do participante.
• Quando escalar: não é falha.