Criando um pipe de aprovação de reembolso e outros pedidos

Como ter processos bem definidos e resistente a falhas com apenas algumas linhas de código.

Você pode já usar ele pronto como template também aqui: https://aprovacaodepedidos.template.jestor.com.br

Veja no vídeo como ele funciona:

Uma situação comum de muitas startups é uma transversalidade quase ilimitada de responsabilidades e permissões entre o time. Quando temos três, quatro pessoas no time, é comum que um mesmo indivíduo atue em várias áreas ao mesmo tempo. Não é raro, inclusive, que a mesma pessoa que sente a necessidade de um software específico tenha liberdade de comprá-lo, ou que a mesma pessoa que faz o relacionamento comercial com os clientes seja o próprio desenvolvedor que resolve os tickets de suporte desses clientes.

Isso, na verdade, é muitas vezes a força de uma startup em seu início. Afinal, as informações e controles estão sempre nas mãos das mesmas pessoas, o que garante que os problemas são resolvidos de forma rápida e da melhor forma possível.

No entanto, quando a empresa começa a escalar, essa transversalidade se torna uma fraqueza. A pessoa que faz uma compra pode não ser mais a que agenda o pagamento, ou ainda, a compra pode ser realizada de uma forma errada (sem exigir nota fiscal, por exemplo), o que leva a confusões operacionais que podem até causar perda financeira para a empresa. Dessa forma, talvez nem faça sentido que mais de uma pessoa tenha a autonomia para efetivamente gerar uma despesa.

É aqui que começa a ficar interessante ter um sistema de solicitações e aprovações centralizado com permissionamento.

Estruturas de aprovação

Apesar de estarmos exemplificando com a montagem de um sistema de pedidos de compra, esse exemplo serve para basicamente qualquer fluxo em etapas onde é necessário que uma pessoa específica possa aprovar ou não uma solicitação. Por exemplo, isso pode ser utilizado para que o time solicite melhorias ou features no produto, mas que apenas um Product Manager possa analisar e decidir se faz sentido seguir com o desenvolvimento dessa feature.

Dessa forma, temos duas necessidades específicas nesse tipo de fluxo:

1. Um campo que permita dividir essa solicitação em fases;
2. Uma estrutura de permissionamento que nos indique quem pode avançar uma solicitação para outras etapas.

Pensando um pouco mais a fundo, existem algumas coisas mais legais que conseguimos fazer com algumas funções padrão do jestor:

1. Transformar essas solicitações em um pipe, com comentários internos;
2. Permitir que solicitações sejam feitas fora do jestor;

Vamos começar a construir a estrutura necessária para essa solução, que eu entendo que é composta de duas partes: a lista com usuários e nível de permissão, e o fluxo em si.

Iniciando pela interface

Como vocês já devem ter percebido por outros textos, o primeiro passo após organizarmos nossas ideias é montar os cadastros com os campos necessários para começarmos o desenvolvimento via código. Podemos adicionar cadastros rapidamente com o botão + na interface.

Assim, criamos primeiramente um cadastro chamado Permissões de compra, onde criamos apenas dois campos adicionais:

• Usuário: este será um campo de referência que aponta para os usuários do sistema. Assim, qualquer pessoa que for incluída no time já constará neste campo;
• Permissão: este será um campo de lista com as opções de permissão. Como montaremos uma estrutura simples, deixaremos apenas duas opções (Solicitante e Aprovador”).

Depois, criamos um novo cadastro que será efetivamente nosso fluxo, que chamaremos de Pedidos de compra. Nele, teremos a seguinte estrutura de campos:

• Descrição: texto curto;
• Valor: número do tipo moeda;
• Status: lista com as fases Nova solicitação, Aprovado ou Recusado;

Poderíamos ter aqui uma série de outros campos relevantes (como justificativa, data máxima para a compra, anexo para orçamento, centro de custo e outros). No entanto, como não influenciarão no código, manteremos o fluxo bem simples, mas fique livre para testar o que faz mais sentido para você ;)

Com a estrutura criada, podemos começar a desenvolver.

Códigos simples para permissionamento

Primeiramente, acessaremos a área de desenvolvimento do jestor a partir do menu da lateral esquerda, clicando em Developer. Depois acessaremos o objeto Pedidos de compra, que é onde criaremos a primeira automatização.

Ela terá um formato muito simples, em que apenas bloquearemos a criação de solicitações em fases que não são Nova solicitação. Assim, nossa primeira automatização, que chamaremos de CriarPedido, terá como gatilho Antes de o registro ser criado.

Agora, qualquer usuário que crie uma solicitação em outra fase automaticamente terá essa solicitação alterada para a fase Nova solicitação.

Em seguida, criaremos nossa segunda automatização chamada AtualizarPedido, que se aproveitará do fato de que o jestor salva automaticamente qual o usuário que criou o registro originalmente, assim como quem está atualizando esse registro. Essa automatização terá como gatilho Antes de o registro ser atualizado.

Aqui, o código seguirá alguns passos:

• Verificará se a solicitação já está em Aprovado ou Recusado. Caso esteja, cancelar qualquer atualização (afinal, não queremos que alguém mude o valor da compra depois da aprovação, por exemplo)
• Verificará se a fase está sendo alterada para algo diferente de Nova solicitação;
• Verificará quem é o usuário atualizando o registro;
• Pesquisará qual o nível de permissão desse usuário no cadastro de Permissões de compra;
• Caso seja um Aprovador, seguirá normalmente;
• Caso seja um Solicitante ou alguém não cadastrado, voltará a solicitação à fase original.

Na prática, teremos algo como:

E agora criaremos nossa última automatização do fluxo, que chamaremos de DeletarPedido e será ativada com o gatilho Antes de o registro ser deletado. Aqui, apenas travaremos a deleção de registros que já foram aprovados ou recusados, mas ainda permitindo a exclusão de novas solicitações.

O resultado final é algo como o código a seguir:

Antes de testarmos, vamos criar uma última automatização no cadastro de Permissões de compra, onde verificaremos se ao salvar um permissionamento, o usuário já não possui algum outro tipo de permissionamento. Afinal, não queremos que um usuário tenha duas permissões diferentes, não é mesmo?

Faremos isso com os seguintes passos:

1. Ao editar ou criar um registro, verificar se uma busca no próprio módulo por lançamentos com o usuário a ser cadastrado retorna vazia (ou seja, se não existe outro lançamento com esse usuário);
2. Caso não volte vazia, cancelar a criação ou alteração (a não ser, é claro, que o usuário esteja tentando modificar justamente esse registro que já existe, o que descobriremos comparando os ids dos lançamentos).

Então, no módulo de Permissões de compra, criaremos uma automatização chamada VerificaUsuario que será ativada Antes de o registro ser criado e Antes de o registro ser atualizado. O código será algo como:

Com todos as partes de desenvolvimento prontas, podemos testar a solução, e vemos que tudo funciona como planejado.

Legal! Tudo funcionou como esperado, mas ainda não para por aqui. Como dissemos anteriormente, temos duas funcionalidades nativas do jestor que conseguem melhorar bastante esse processo.

Transformando um cadastro em um pipe

Agora, transformaremos o cadastro de Pedidos de compra em um fluxo, o que deixará o processo ainda mais intuitivo. Para isso, acessaremos a área de desenvolvimento e utilizaremos a função de criar pipe dentro do cadastro Pedidos de compra, localizada logo acima da criação de triggers.

Ativaremos a visão de pipe para este cadastro, selecionando o campo Status como divisão de colunas. O resultado final é que agora o cadastro pode ser visto, além da visão de lista original, em um fluxo de cards dividido por fases!

Além disso,internamente temos também uma seção de comentários, onde os usuários podem se comunicar diretamente ou deixar anotações relevantes. No caso, poderíamos ter uma fase de Revisão, onde o aprovador poderia explicar porque o pedido ainda não foi aprovado e solicitar correções ao solicitante.

Essa forma de visualização acaba sendo muito mais intuitiva, e muito mais fácil de atualizar, do que o formato de lista normal quando estamos trabalhando com algo que tem uma divisão cronológica (ou seja, que avança a um determinado fim).

Criando solicitações através dos forms

Para finalizar, vamos habilitar o formulário externo para criação de pedidos no jestor. Podemos fazer isso no botão de + Formulário do cadastro na visão de lista. Lá, daremos um título e explicação ao formulário, e escolheremos quais campos poderam ser preenchidos por quem enviará as informações. No caso, a Descrição e o Valor.

Assim, receberemos uma URL que pode ser compartilhada até para pessoas que não tem acesso ao seu jestor. Elas poderão preencher as informações e alimentar o cadastro automaticamente, o que é muito útil para quem está na rua ou precisa de uma forma rápida de registrar informações no sistema.

Com esse último toque, conseguimos criar um fluxo bem completo, onde as pessoas conseguem abrir solicitações de forma rápida, e o manuseio das informações é feito de forma controlada e fluida através do pipe de solicitações.

Processos para o futuro do negócio

Embora tenhamos criado aqui uma estrutura de solicitações simples, a realidade é que ela poderia ser tão complexa quanto você quiser. Inclusive, não tocamos em alguns pontos bem interessantes que são bem úteis para criar outras estruturas (como abas dentro do card no pipe).

No entanto, acredito que já seja possível ter uma boa ideia de como esse tipo de lógica e ferramentas podem ser utilizados para criar processos que vão escalando juntamente à sua empresa. Às vezes nos esquecemos que é importante a ferramenta utilizada ser tão simples ou complexa quanto seus processos. Afinal, não adianta utilizar uma pá quando precisamos de uma colher, nem ter a colher quando precisamos de uma escavadeira.

Utilize ferramentas que podem ser tão simples quanto seus processos são hoje, mas que tenham uma estrutura sólida o suficiente para escalar com você.