[Componentes] - Condições

Para que servem os componentes de "Condições":

Os componentes de condições tem como intuito definir os critérios que estão sendo analisadas pela regra, definir a ação que será executada caso o critério construído seja verdadeiro e também a ação que será executada caso o critério seja falso.

• Se/Portanto:

O componente "Se/Portanto" é o coração do motor de regras e é através dele em que define-se qual o critério está sendo avaliado e as ações que serão tomadas de acordo com o critério. O componente aceita dois ou três filhos (componentes abaixo da caixinha):

1. O primeiro filho do componente "Se/Portanto" será o critério que está sendo avaliado. O critério aplicado deve ter um valor booleano (verdadeiro ou falso);
2. O componente que constar como segundo filho é o componente que será acessado caso o critério contido no primeiro filho do "Se/Portanto" seja verdadeiro. Caso o segundo filho seja uma ação, a ação será executada quando o critério for verdadeiro;
3. O terceiro filho da caixinha "Se/Portanto" é opcional e, caso seja usado, será executado sempre que o critério contido no primeiro filho for falso.

Na figura abaixo é possível verificar um exemplo básico de uso uma caixinha "Se/Portanto" com os seus respectivos filhos:

No exemplo acima o critério que está sendo analisado é se a cidade do endereço do cliente foi verificada com o bureau, sendo este o critério. Caso o critério seja verdadeiro, a caixinha de decisão de aprovação será executada. Caso a cidade do cliente não seja verificada, o cliente será reprovado executando a caixinha de decisão configurada para reprovação;

Caminho percorrido dentro da caixinha "Se" até o primeiro filho, sendo este o critério avaliado.	Caminho percorrido dentro da caixinha "Se" até o segundo filho após entender que o critério avaliado é verdadeiro. Neste caso a análise seria aprovada.	Caminho percorrido dentro da caixinha "Se" até o terceiro filho após entender que o critério avaliado é falso. Neste caso a análise seria reprovada.

É importante ressaltar que o segundo e o terceiro filho não necessariamente precisam ser ações. É possível fazer validações sequenciais, como por exemplo:

No exemplo dado acima a primeira validação a ser feita será a validação da cidade do cliente. Caso a cidade do cliente seja verificada, a regra seguirá para a validação de CEP do cliente. Caso ambas sejam verdadeiras, o usuário será aprovado. Abaixo é possível verificar o passo a passo:

1 - A primeira validação a ser feita neste caso é a cidade do cliente.	2 - Caso a cidade do cliente seja verificada e o retorno da validação seja verdadeiro, a análise seguirá para o segundo filho da caixinha "Se", que será a segunda validação.
3 - Na segunda validação será feita a verificação do CEP do cliente.	4 - Se o CEP for aprovado, o cliente será aprovado no onboarding. Neste exemplo dado, a primeira verificação feita foi a da cidade do cliente. Caso aprovado, segue-se para segunda verificação, o CEP do cliente. Caso ambos aprovem, o cliente será aprovado.

• Ou:

O componente "Ou" é um operador lógico que recebe entradas booleanas e gera um output também booleano baseado nas entradas que receber, ou seja, ele aceita inúmeras entradas de "verdadeiro" ou "falso" e, caso pelo menos um desses inputs seja verdadeiro, a caixinha "Ou" retornará "verdadeiro", caso contrário retornará "falso". Ela é bastante útil quando deseja-se avaliar mais de um critério simultaneamente, por exemplo. Abaixo é possível verificar um exemplo aplicado às regras de onboarding e outro exemplo de uma regra transacional:

Exemplo em que deseja-se validar o status do documento do cliente que está realizando onboarding perante a Receita Federal. No exemplo acima serão executadas ambas as validações (documento com status falecido e documento inválido) e o retorno destas validações será direcionado para a caixinha "Ou". Caso pelo menos uma das duas validações seja verdadeira, o componente "Ou" assumirá o valor de "verdadeiro".

Para compreender o cenário acima iremos criar um cenário hipotético em que o titular de um CPF encontra-se falecido: Caso este CPF seja analisado em um fluxo de onboarding a análise será reprovada, já que apesar do documento ser válido o titular encontra-se de fato falecido. Neste cenário, uma das variáveis seria verdadeira (Titular falecido) e a outra seria falsa (Documento inválido). Como o componente "Ou" retorna verdadeiro sempre que pelo menos um dos seus filhos for verdadeiro, o retorno do "Ou" será verdadeiro e consequentemente o onboarding reprovado.

Exemplo em que deseja-se validar se o montante em uma transação é maior que R$500,00 ou então se o documento do titular da conta origem da transação transacionou mais de duas vezes no último dia.

Criando novamente um cenário hipotético para compreender a regra exemplificada acima, a regra avalia se o montante transacionado é maior que R$500,00 ou então se o titular da conta origem já transacionou mais de duas vezes no último dia. Caso o usuário faça uma transação de R$1000,00, mesmo que esta seja a primeira transação do dia pelo menos um dos critérios avaliados já será verdadeiro, fazendo com que o output do componente "Ou" seja verdadeiro também.

• E:

O componente "E" é um componente análogo ao componente "Ou", ou seja, aceita o retorno de vários componentes como "filhos" e gera um output baseado nisso. A diferença é que para o componente "E" assumir um valor verdadeiro é necessário que todos os seus filhos possuam o seu valor como verdadeiro. Replicando o exemplo acima é possível entender a diferença entre o "E" e o "Ou":

Exemplo em que deseja-se validar o status do documento do cliente que está realizando onboarding perante a Receita Federal. No exemplo acima serão executadas ambas as validações (documento com status falecido e documento inválido) e o retorno destas validações será direcionado para a caixinha "E". Caso ambas as validações sejam verdadeiras, o componente "E" assumirá o valor de "verdadeiro". No caso de uma delas ser "falso", o componente "E" será "falso" também.

Para compreender o cenário acima iremos novamente criar um cenário hipotético em que o titular de um dado CPF encontra-se falecido: Caso este CPF seja analisado em um fluxo de onboarding a análise será reprovada, já que apesar do documento ser válido o titular encontra-se de fato falecido. Neste cenário, uma das variáveis seria verdadeira (Titular falecido) e a outra seria falsa (Documento inválido). Como o componente "E" retorna verdadeiro somente quando todos os seus filhos tiverem o valor "verdadeiro", o retorno do "E" será "falso" e consequentemente o onboarding aprovado.

Exemplo em que deseja-se validar se o montante em uma transação é maior que R$500,00 e se o documento do titular da conta origem da transação transacionou mais de duas vezes no último dia.

Repetindo o caso transacional usado como exemplo na sessão do componente "Ou" porém agora usando a caixinha "E", a regra avalia se o montante transacionado é maior que R$500,00 e se o titular da conta origem já transacionou mais de duas vezes no último dia. No cenário hipotético de um cliente que faça sua primeira transação do dia no valor de R$1000,00, a primeira validação realizada (montante transferido) terá valor "verdadeiro" porém o segundo comparativo assumirá o valor de "falso", já que é somente a primeira transação do usuário em 24 horas. Dentro deste cenário a caixinha "E" assumiria o valor de "falso" já que pelo menos um dos seus filhos também é "falso" e consequentemente a transação seria aprovada.

• Não:

Por fim existe ainda o componente "Não", que aceita um filho e serve para inverter o sinal do booleano proveniente do filho, conforme exemplo abaixo:

Exemplo em que deseja-se validar o status do documento do cliente que está realizando onboarding perante a Receita Federal. No exemplo acima serão executadas ambas as validações (documento com status falecido e documento inválido) e o retorno destas validações será direcionado para a caixinha "E". A diferença entre o exemplo contido na sessão do componente "E" é que aqui existe o uso da caixinha "Não", que inverte o sinal de seu respectivo filho. Neste exemplo, caso haja o titular com status falecido na receita federal a caixinha de variáveis irá gerar o retorno "verdadeiro", e ao passar pelo componente "Não" o sinal será invertido, se tornando falso. Uma interpretação textual para a construção acima seria "Se o documento existe na receita feral e o o titular do documento não possui status "falecido", aprovar o onboarding. Caso não exista ou o titular esteja falecido, reprovar"