Limite de notas por participante

São dois limites da regra de geração que controlam quantas notas o participante consegue cadastrar: um por dia e um na campanha inteira. Eles contam notas, não números — apesar de os rótulos no painel falarem de chances ("Chances por CPF" é o limite por dia, e "Chances total de notas" é o da campanha). Essa ambiguidade é conhecida e a ajuda do painel foi corrigida; o comportamento é o de contar notas.

A diferença mais importante em relação aos tetos de chance: a nota excedente é recusada, não aceita-e-sem-gerar. É o oposto do limite de chances, e é de propósito — lá o teto é sobre o que a nota rende, então a nota entra e gera o que couber; aqui o teto é sobre a própria nota, e aceitar uma nota que não devia entrar guardaria um dado que a configuração diz não existir.

Os dois limites são conferidos no cadastro da nota, e a ordem deles não é arbitrária:

• os dois vêm depois da checagem de duplicidade. Senão a nota reenviada por duplo clique ouviria "limite atingido" em vez de "esta nota já foi cadastrada" — a mensagem pior para o mesmo caso;
• o limite da campanha vem antes do limite do dia. Com os dois estourados, "tente novamente amanhã" seria mentira: na campanha esgotada não há amanhã.

O que entra na contagem:

• só nota ativa. Nota cancelada não consome a cota de quem recadastra a mesma nota, que é fluxo normal;
• o escopo é a participação do participante naquela campanha;
• o limite por dia conta pela data do envio, não pela data da compra. O limite controla o ritmo de envio, que é o que uma fraude acelera. Pela data da compra ele seria contornável — bastaria espalhar as datas de compra entre as notas enviadas de uma vez — e travaria um dia para sempre, porque as notas de um mesmo dia de compra nunca sairiam da contagem.

O dia é o dia de Brasília, não o dia em horário universal. Isso é concreto: das 21h à meia-noite de Brasília, o relógio universal já está no dia seguinte, e a cota se renovaria três horas antes da virada do relógio de quem está cadastrando.

Envios simultâneos não furam mais o limite

Até a correção feita no fim de outubro de 2026, quem estava no limite conseguia passar dele mandando várias notas ao mesmo tempo: cada envio contava as notas antes de qualquer um deles ser gravado, todos achavam que cabia e todos entravam. Num teste, limite 1 e cinco envios simultâneos gravavam cinco notas.

Hoje os envios do mesmo participante na mesma campanha passam pela contagem um de cada vez. O segundo só conta depois que o primeiro terminou, enxerga a nota que acabou de entrar e recebe a recusa normal do limite. Isso só acontece quando a campanha tem limite de notas, e não afeta outros participantes: a campanha não passa a cadastrar nota em fila.

Notas que entraram acima do limite antes dessa correção continuam gravadas: a correção vale para os envios seguintes, nada é desfeito para trás.

Mais de uma regra, e a regra compartilhada

Com mais de uma regra ativa na campanha, vale o menor limite. Com duas regras, a campanha declara dois tetos, e o único que respeita os dois é o mais apertado. Pegar o da primeira deixaria a ordem da consulta decidir a regra de negócio.

Há um preço conhecido nessa configuração, e o atendimento precisa saber dele: "quantas notas o participante pode cadastrar" é regra da campanha, mas o campo mora na regra de geração, que é reutilizável. Duas campanhas que compartilham a mesma regra herdam o mesmo limite de notas sem ninguém ter decidido isso, e quem edita a regra num cadastro longe da campanha não vê quem depende dela. Mover o campo para o lugar certo é mudança de estrutura e está pendente; por isso o texto de ajuda do painel avisa em letras claras que o limite vale para toda campanha que usar a regra.

Em branco e zero são sem limite. O cadastro recusa zero, então essa salvaguarda serve ao dado que já estava gravado — tratar zero como teto recusaria a primeira nota de todo participante.

É o limite de quantas compras o participante pode cadastrar: um por dia e um no total da campanha. Quando ele estoura, a compra é recusada com mensagem explícita — diferente do limite de chances, em que a compra entra e apenas não rende.

O limite por dia renova à meia-noite de Brasília, e conta pela data do envio, não pela data da compra. Então o participante que cadastra cinco notas de compras antigas num dia consumiu a cota daquele dia, não a cota dos dias das compras.

O limite vale também para quem tenta mandar várias notas de uma vez: os envios simultâneos do mesmo participante são contados um a um, e o que passa do limite é recusado.

O ponto que mais merece atenção na conversa com o cliente: esse limite fica na regra de geração, e a regra é reutilizável. Se o cliente usa a mesma regra em mais de uma campanha, o limite vale em todas elas. Antes de alterar, confirme quais campanhas usam aquela regra.

E, se o cliente configurou duas regras com limites diferentes na mesma campanha, vale o menor dos dois.

• Falha: o participante diz que não consegue mais cadastrar notas hoje.
• Possivel causa: ele atingiu o limite de notas por dia da regra. A cota renova à meia-noite de Brasília.
• Como orientar: confira o limite por dia na regra da campanha e quantas notas ele enviou hoje. Oriente a tentar de novo depois da virada do dia. Em branco significa sem limite.
• Quando escalar: se o limite estiver em branco e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante não consegue cadastrar nota nenhuma e a mensagem não fala de amanhã.
• Possivel causa: ele atingiu o limite de notas da campanha inteira, não o do dia. Nesse caso não há renovação.
• Como orientar: confira o limite de notas na campanha inteira na regra. Explique que esse limite não renova. Se o cliente quiser elevar, a alteração vale só para frente.
• Quando escalar: se o limite estiver em branco e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante enviou várias notas ao mesmo tempo e só parte delas entrou.
• Possivel causa: os envios simultâneos do mesmo participante são contados um de cada vez, e os que passaram do limite foram recusados.
• Como orientar: explique que o limite vale para cada nota, mesmo enviadas juntas. As notas recusadas não foram registradas e podem ser enviadas quando houver cota.
• Quando escalar: não é falha.

• Falha: um participante tem mais notas do que o limite permite.
• Possivel causa: as notas podem ter entrado antes da correção do fim de outubro de 2026, quando envios simultâneos furavam o limite, ou o limite foi alterado depois que elas entraram.
• Como orientar: confira as datas de envio das notas e o histórico da regra. A correção e a alteração de limite valem só para frente.
• Quando escalar: se as notas acima do limite tiverem sido enviadas depois da correção sem alteração do limite, acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o cliente alterou o limite numa campanha e o limite mudou em outra campanha dele.
• Possivel causa: as duas campanhas usam a mesma regra de geração, e o limite acompanha a regra.
• Como orientar: confira em quais campanhas aquela regra está vinculada antes de alterar. Se o cliente precisa de limites diferentes, o caminho é cadastrar uma regra própria para cada campanha.
• Quando escalar: não é falha. Se o cliente precisar de limites independentes com a mesma regra, abrir issue no Jira (projeto DEV) descrevendo o caso.

• Falha: o cliente configurou dois limites diferentes em duas regras e está valendo o mais apertado.
• Possivel causa: com mais de uma regra ativa vale o menor limite, porque é o único que respeita as duas configurações.
• Como orientar: alinhe os limites das regras da campanha, ou deixe o limite só na regra que deve mandar.
• Quando escalar: não é falha.

• Falha: o participante cancelou e recadastrou uma nota e isso consumiu cota duas vezes.
• Possivel causa: só nota ativa conta. Se a cota foi consumida duas vezes, a nota antiga pode não ter sido efetivamente cancelada.
• Como orientar: confira no detalhe do participante se a nota antiga está cancelada.
• Quando escalar: se a nota antiga estiver cancelada e a cota seguir consumida, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante enviou a mesma nota duas vezes e ouviu limite atingido.
• Possivel causa: o esperado nesse caso é a mensagem de nota já cadastrada, porque a duplicidade é conferida antes dos limites.
• Como orientar: confira se a nota consta cadastrada. Se constar e a mensagem foi de limite, registre a evidência.
• Quando escalar: acionar o time de desenvolvimento e abrir issue no Jira (projeto DEV) com as evidências, porque a ordem das mensagens é proposital.