Como resolvi meu 1º problema de negócio com PHP sem experiência
O quão suave é a curva de aprendizado para quem veio do mundo das planilhas?
Meu primeiro emprego foi numa empresa grande de um setor bem tradicional.
Apesar de todas as vantagens que uma empresa desse tipo tivesse, também carregava consigo todas as desvantagens colaterais de seu próprio tamanho: muitos processos eram desconexos, a comunicação entre áreas era difícil e os sistemas eram engessados.
Sobre esse último ponto, era bem comum que muitos dos funcionários não utilizassem de fato o principal sistema da companhia no dia-a-dia. Na realidade, ele era mais utilizado como um banco de dados do qual esses funcionários extraíam diariamente as informações e as passavam para suas próprias planilhas individuais, personalizadas para seus próprios fluxos de trabalho.
Ou seja, mesmo utilizando um sistema caríssimo e líder de mercado, eram nessas planilhas que o trabalho de verdade acontecia.
Foi nesse contexto que aprendi todas as vantagens que esse tipo de ferramenta proporciona: quando utilizadas corretamente, planilhas são ágeis, flexíveis e poderosas. No entanto, rapidamente aprendi seus maiores problemas também. Planilhas quebram, dependem de dados tratados, não incentivam a padronização de processos e, quando seus criadores originais vão embora, são quase sempre abandonadas, gerando custos para recriar um mesmo processo uma, duas, três vezes ou mais.
Novos setores, mesmos problemas
Anos depois, acabei por seguir caminhos totalmente diferentes daquele primeiro emprego. Abandonei a empresa grande por startups, a logística pela área financeira, e os grandes sistemas por novos players.
Foi surpreendente, então, perceber que vivia os mesmos problemas.
Os sistemas menores eram tão engessados quanto aquele grande sistema, ainda que por motivos diferentes. Geralmente, eles se propunham a resolver algum problema específico bem, e nada mais do que isso. Não era raro precisar de alguma gambiarra para fazer o que eu precisava.
Por exemplo, se precisasse colocar informações que não eram padrão do sistema, a solução comum era colocar essas informações no campo de observações separadas por ponto e vírgula, extrair um relatório e separar essas informações numa planilha.
Obviamente, essa solução era extremamente propensa a erros.
Quando comecei minha jornada no Jestor, fui atraído pela possibilidade de usar um sistema que se propunha a ser tão flexível quanto as planilhas que sempre utilizei, mas ainda assim trazendo todas as vantagens de usar um sistema.
De cara, as personalizações direto na interface me permitiram transpor as informações de algumas de minhas planilhas diretamente para o sistema. No entanto, fiquei curioso sobre uma possibilidade: se eu quisesse dar um passo além e melhorar meus processos com o Pro, o quão difícil seria dar esse passo?
Resolvi fazer um experimento rápido para responder essa pergunta.
O desafio
Definir o problema que eu gostaria de resolver foi bem fácil: decidi criar um módulo de transferências contábeis no Jestor. Ou seja, um módulo que criasse simultaneamente uma conta a pagar e uma conta a receber em contas contábeis diferentes.
Para quem não sabe, essas transferências são utilizadas quando você possui movimentação financeira dentro de sua própria empresa sem perda ou ganho de valores. Por exemplo, quando você realiza um saque no caixa eletrônico, você “perde” dinheiro na conta bancária e “ganha” no caixa da empresa, mas o saldo total da operação é zero.
Por que escolhi essa função? Em primeiro lugar, porque resolveria um problema real que eu tinha. Em segundo lugar, porque era um problema que parecia complexo o suficiente para não ser trivial, mas ao mesmo tempo simples o suficiente para ser resolvido por um principiante.
As condições iniciais
Para desenvolver essa nova solução, estes eram os recursos que eu possuía no primeiro dia com o Jestor Pro:
- Experiência com desenvolvimento de macros em VBA no Excel;
- Zero conhecimento de PHP;
- Acesso ao vídeo exemplo e documentação de desenvolvedor da Jestor.
Quão preparado eu estava? Diria que um analista com alguma experiência com planilhas teria acesso ao mesmo conhecimento que eu para este tipo de tarefa. Ou seja: alguém que entende lógica e sabe montar processos, mas sem conhecimento técnico de programação ou experiência real com desenvolvimento.
Passo 1: Definir o processo
A primeira coisa que fiz foi desenhar o processo. As regras que eu queria eram bem simples:
- Ao criar uma transferência, gerar uma conta a pagar e uma conta a receber correspondente;
- Ao atualizar a transferência, atualizar essas contas atreladas;
- Ao deletar a transferência, zerar essas contas atreladas.
Além do que eu queria que o módulo fizesse, defini algumas regras do que eu não queria que acontecesse:
- O usuário final não poderia deletar uma conta a pagar/receber originária de uma transferência (afinal, isso alteraria o saldo entre o que deveria ser um par de lançamentos gêmeos);
- O usuário final não poderia desatrelar as contas a pagar/receber geradas por uma transferência da própria transferência.
São regras que me pareceram suficientes para começar a construção da solução, então comecei criando o módulo de transferência da própria interface, com os campos necessários.
Passo 2: Facilite sua vida via interface
Como eu não sou programador, para mim foi mais fácil já criar os campos direto na tela do sistema:
Traduzindo estes campos:
- Nome: a descrição da transferência (ex: transferência entre contas bancárias).
- Valor da Transferência: o valor a ser transferido.
- Data da Transferência: data que a transferência ocorreu.
- Conta de Saída: de onde os valores saíram.
- Conta de Entrada: onde os valores entraram.
- Entrada e Saída: campos para atrelar as contas a pagar e receber criadas.
Passo 3: Hora de programar!
Feito isso, acessei a área de desenvolvimento do Jestor e procurei pelo módulo recém criado. Aqui está ele, já com as variáveis e como estão referenciadas no código:
Seguindo a documentação de desenvolvimento do Jestor, fui até o final da página para criar minha primeira automatização, que era:
- Ao criar uma transferência, gerar uma conta a pagar e uma conta a receber correspondente.
A primeira parte disso, obviamente, foi definir o gatilho para essa automatização. Ou seja, quando ela iria ocorrer. Neste caso, é simplesmente quando uma nova transferência é criada, então marquei a caixa correspondente:
Depois disso, chegou a hora de escrever o código.
Como disse anteriormente, minha experiência com PHP é zero. No entanto, consigo criar algumas macros simples para automatizar minhas tarefas financeiras com alguma facilidade. Assim, tentei enxergar a automatização como um processo a ser construído, e montei a etapas na minha cabeça:
- Quando criar a transferência, salvar as informações em algum lugar;
- Criar uma conta a receber com essas informações;
- Criar uma conta a pagar com essas informações;
- Atrelar essas contas criadas à transferência original.
Perfeito. Com o processo montado, consigo começar a buscar referências na documentação para me ajudar.
Quando digo salvar as informações em algum lugar, mesmo com meu pouco conhecimento de programação entendo que devo utilizar variáveis. Em VBA, era necessário declarar essa variável e o tipo dela (se é um texto ou número, por exemplo). Descobri que no PHP, basta identificar uma variável com um $ no início, e não parece importar muito a informação que você atribui à mesma.
Entendido isso, faltava entender como captar as informações que o usuário final insere no sistema. Lendo um pouco da seção de gatilhos (Web Triggers), descobri que quando o usuário clica em “Salvar” um registro, todas as informações que ele inseriu ficam dentro de uma variável chamada $objectNew, e que para pegar uma informação específica era necessário chamar o campo entre colchetes.
Dando um exemplo aqui, se quisesse pegar o nome da transferência criada, ela estaria contida em $objectNew[‘name’].
A primeira parte do meu código, então, foi o bloco abaixo:
Talvez você perceba que algumas variáveis não estão sendo alimentadas pelo input do usuário, mas foram definidas diretamente no código. Foram criadas dessa forma porque são variáveis de contas a pagar/receber que nunca serão diferentes. Assim, não haveria porque fazer o usuário final inserir essas opções.
Passo 4: Como criar uma conta a pagar/receber com essas informações?
Lendo um pouco mais da documentação (Web Métodos Nativos Jestor), descobri que o Jestor possui uma função nativa para isso, o Jestor.create. Para criar um registro via código, basta usar essa função passando qual o tipo de registro (ex: contas a pagar) e as informações por um vetor (array).
E foi aqui que esbarrei no meu primeiro problema: eu não sabia utilizar arrays. Tudo o que havia feito em VBA anteriormente era relativamente simples, alterando valores individuais de células ou variáveis.
Foi aqui que comecei a utilizar o vídeo exemplo de desenvolvimento (Criando aplicativo de tickets — Jestor) para ver na prática como um programador trabalha com esse tipo de informação. Com o vídeo, descobri duas coisas:
- Como criar arrays e referenciar as informações dentro deles;
- Que é uma boa prática começar o código verificando se o $objectNew está vazio. Afinal, não queremos que a automatização rode sem informações.
Então, expandi o código para trabalhar com esses dois pontos:
Um pouco mais a frente, utilizei o Jestor.create para criar as contas a pagar/receber correspondentes, e depois atrelá-las dentro dos campos entrada e saída da própria transferência.
Depois disso, foi só salvar o código e testar a solução. Testei uma transferência de R$1.000,00 da conta Bradesco para a conta Itaú.
E deu certo! ?
Foram criadas as contas correspondentes, como vocês podem ver no extrato abaixo. Ao entrar na visualização das contas em si, todas as informações que eu esperava estavam lá.
Assim, a criação em si foi bem fácil. Depois disso, comecei a criar as automatizações necessárias até completar as funcionalidades que defini lá no início, como edição ou deleção da transferências.
Cometendo erros
Essa história, no entanto, está bem simplificada. Obviamente cometi erros ao longo do processo, sejam erros clássicos de quem não está acostumado a programar (como esquecer o ponto e vírgula ao final de uma linha) ou até erros de lógica ao não entender todas as ramificações de alguma parte de código.
Vou exemplificar com um problema bem interessante que encontrei ao longo do caminho, e como ele foi resolvido depois de um bom tempo atacando de várias formas.
Um dos critérios que defini é que uma conta a receber/pagar não poderia ser editada caso estivesse vinculada a uma transferência. No bloco abaixo, que tem como gatilho a edição de uma conta a receber, a variável $transfpull só teria informações caso a conta a pagar/receber estivesse atrelada a alguma transferência.
A ideia mais simples, então, foi bloquear edições com a função Jestor.error quando $transfpull não fosse vazia. Isso pareceu funcionar muito bem, até que entrou em conflito com outra regra que eu havia criado: quando uma transferência é editada (por exemplo, o valor é alterado), as contas a pagar/receber são alteradas também.
Percebi que uma forma de resolver isso seria ter uma segunda validação: caso a contas a pagar/receber esteja atrelada a uma transferência, cancelar a edição a não ser que…
E travei novamente. A forma mais óbvia de resolver isso seria criar um campo em contas a pagar e a receber para indicar se esse lançamento veio de uma transferência (como um checkbox, por exemplo), mas:
- Eu não queria modificar o contas a pagar e receber padrão do sistema;
- Seria necessário criar uma trava via código para o usuário final não poder alterar esse checkbox.
Depois de muita tentativa e erro, encontrei uma solução que, embora talvez não seja a mais elegante, atendeu bem o problema proposto. Na automatização de editar transferência, passei o campo de observações com o valor -1. Não como um texto “-1”, mas como um número.
Por quê? Porque o usuário final nunca conseguiria passar esse valor direto pela interface. Mesmo que ele digitasse “-1” no campo de observações, esse -1 seria lido como texto.
Depois, na minha trava de edição no contas a pagar/receber, permiti a edição de lançamentos atrelados a transferências apenas se viessem com um campo de observações com valor -1 e tipo número. Para isso, utilizei o comparador de “===”, que valida valor e tipo.
E funcionou! Depois desse leve ajuste, essas contas a pagar/receber só poderiam ser editadas através da edição da transferência original.
Existiram alguns outros problemas ao longo do caminho (como criar loops eternos com gatilhos que se auto disparavam), mas por questões de brevidade, vou finalizar essa seção por aqui.
Finalizando
O saldo desse experimento foi uma funcionalidade completa, operando exatamente nas regras que eu escolhi, e com apenas duas noites de aprendizado e testes após o trabalho.
Ou seja, ainda que eu olhe pra trás e perceba que talvez um programador teria resolvido esses problemas de maneiras mais eficientes, o Jestor Pro consegue ser útil até mesmo para quem é de business, e com uma curva de aprendizado bem suave.
É claro que arranhei apenas a superfície do que a ferramenta é capaz de fazer. Não houve personalização da interface e não houve qualquer tipo de integração utilizando API, funções que abririam um mundo inteiro de possibilidades para customizar a plataforma. Um dia, talvez, eu faça um teste parecido para essas funcionalidades. No entanto, com um pouco de lógica e algumas horas de teste, já consigo me enxergar automatizando vários processos e fluxos de tarefas dentro do sistema.
E, quando penso no meu primeiro emprego, com aquela multidão de analistas extraindo dados do sistema para planilhas e criando suas macros para trabalhar as informações, penso também em como esses fluxos de trabalho poderiam ser facilmente transpostos para o Jestor, otimizando tempo e criando processos permanentes que fossem continuamente melhorados, ao invés de ondas de processos individuais.
Afinal, tão importante quanto ter um time competente, é ter uma gestão de informações eficiente.
