- Atlas Contabilidade precisava de uma aplicação que realizasse a importação de dados do banco legado (firebird questor) e disponibilizasse, por meio de uma pesquisa por nome ou codigo da empresa, informacoes como CNPJ, endereço, dados dos socios, senhas de acessos, faturamento, receitas, despesas, impostos pagos e responsaveis por setor. Além disso, o sistema contempla um dashboard interativo e o tratamento de informações derivadas de planilhas internas e externas(clientes), realizando automações para modificar e permitir a importação direta desses dados por meio da ferramenta Questor.
-
Importações ( Clientes, Despesas, Prefeituras, Receitas, Responsaveis, Socios, Faturamento, Impostos)
-
Dashboard (Receitas, Despesas)
-
Automações (Tratamento de planilha padrão cliente para modelo de importação Questor)
-
Consultas ( Consultas das informações dos clientes, dados, receitas, despesas, faturamentos)
- Adminstradores, Time Fiscal, Contábil, Pessoal, Financeiro, Estagiarios.
O Django foi utilizado como uma maneira robusta e escalável para uma aplicação web, permitindo automações e ferramentas necessárias para desempenhar uma boa aplicação interna.
A escolha do Django permitiu:
-
Centralizar regras de negócio relacionadas aos dados contábeis e fiscais.
-
Criar Management Commands para importação, consulta e manutenção de dados.
-
Facilitar a evolução do sistema sem dependência de interface gráfica.
O banco de dados Firebird é utilizado por ser o banco legado do Sistema Questor, que concentra todos dados importados, clientes, faturamentos, receitas, despesas e todas informações produzidas pelos analistas para cada empresa.
A integração com o Firebird foi necessária para:
-
Garantir a fidelidade dos dados originais.
-
Evitar dependência de informações manuais.
-
Permitir consultas e importações automatizadas por empresa.
Os management commands foram adotados como principal forma de execução da rotina de importação dos dados, bem como a consulta, exclusão e tratamento das informações. Permitindo controle explícito da execução, parametrizada via argumentos facilitando a manutenção.
As planilhas são utilizadas como fonte de dados internos, preenchidos pelos analistas, refletindo a realidade operacional do escritório onde nem sempre as informações estão disponíveis no sistema legado (Questor).
Foram criadas rotinas para tratamento, validação e importação dos dados para:
- Padronizar dados antes da importação
- Reduzir erros manuais
- Integrar informações externas e adicionais
O celery foi utilizado no sistema para execução das tarefas assíncronas, como tratamento e processamento de planilhas derivadas dos clientes.
A adoção do Celery permitiu:
- Executar rotinas longas sem bloquear a aplicação principal
- Controlar os estados das execuções (pendente, processando, concluído ou erro)
- Organizar as tarefas que podem ser executadas de forma independente
Essa abordagem foi necessária principalmente para tarefas que envolvem grande volume de dados, como o processamento fiscal/contabil.
O uso das tarefas assíncronas evita falhas por timeout, melhora a experiencia operacional e permite maior controle sobre erros e processamentos.
A aplicação app_variaveis foi criada para realizar o controle e administração das rotinas assíncronas, centralizando informações de estado, parâmetros e variáveis utilizadas pelas tarefas executadas via Celery.
Ela atua em conjunto com o Celery e Redis, permitindo o acompanhamento das execuções, controle de estado e apoio às rotinas.
Essa abordagem facilita o monitoramento, a rastreabilidade e a manutenção das rotinas automatizadas do sistema.
O Redis foi utilizado como broker de mensageria para o Celery, sendo responsável por intermediar a comunicação entre o disparo das tarefas e a execução assíncrona das rotinas do sistema
A adoção do Redis permitiu:
- Garantir o enfileiramento e a distribuição das tarefas assíncronas
- Evitar bloqueios na execução principal da aplicação
- Controlar o fluxo de execução das rotinas de importação e sincronização
- Manter a execução desacoplada do processamento pesado
Essa abordagem permitiu maior estabilidade, previsibilidade e escalabilidade das rotinas assíncronas do sistema.
O Waitress foi utilizado como servidor WSGI para a aplicação DJANGO, sendo responsável por atender as requisições da aplicação em ambiente Windows.
A escolha do Waitress se deu por:
- Compatibilidade com o sistema operacional (Windows)
- Simplicidade de configuração
- Estabilidade para uso interno
- Integração direta com DJANGO sem dependência adicionais
O Waitress é executado como serviço Windows por meio do NSSM, garantindo que a aplicação permanceça ativa de forma contínua.
O Whitenoise foi utilizado para o gerenciamento e a entrega dos arquivos estáticos da aplicação DJANGO, permitindo que esses recursos fossem servidos diretamente pela aplicação.
Essa escolha foi adotada considerando o uso interno do sistema em ambiente Windows, onde a utilização de um servidor web externo como Nginx não se mostrou necessária.
O NSSM foi utilizado para realizar a execução dos processos essenciais do sistema como serviço do Windows, mantendo as aplicações sempre ativas independente da variação do sistema operacional.
Foram registrados serviços como:
- Celery
- Redis
- Waitress
- Serviços relacionados ao DJANGO (incluindo Whitenoise no contexto de serving estático)
A utilização do NSSM contribuiu para:
- Executar serviços de forma automática junto à inicialização do sistema
- Evitar dependência de execução manual do sistema
- Garantir maior estabilidade operacional
- Facilitar o controle de Start, Stop e reinicialização dos serviços.
Essa abordagem foi adotada devido ao ambiente de execução em Windows, permitindo que o servidor Django e as rotinas assíncronas permaneçam ativas de forma confiável e controlada.
A execução das rotinas via terminal foi utilizada para permitir um maior controle, rastreabilidade e segurança das ações e execuções realizadas no sistema. Principalmente tarefas sensíveis e importantes como importações, correções e restauração de backups (Questor legado).
O sistema possui tratamento de erros e listagem em logs para maior confiabilidade da operação do sistema, trazendo mais clareza e visibilidade geral do sistema, bem como a identificação de falhas durante as rotinas de importação e sincronização dos dados. Permitindo uma correção rápida e segura.
--CNPJ > atualizar apenas 1 empresa buscando pelo parametro INSCRFEDERAL
--codigo_empresa > atualizar apenas 1 empresa buscando pelo parametro CODIGOEMPRESA
- Inclui no banco e atualiza clientes importando do banco legado Questor(firebird):
-
Filtra por meio de CNPJ e codigo de empresa e cria um SQL filtrando por esses parametros.
-
Faz o tratamento do CNPJ com a função normalize_cnpj, para retornar apenas numeros ex: 85.411.064.0001-38 > 85411064000138
-
Faz a modificação para identificar o tipo de registro da empresa: "codigo_filial_from_apelido": 1: junta comercial, 2: cartorio, 3: OAB.
-
Modificar_data > tratamento da data para DD/MM/AAAA, pois do sistema importa: dd-mm-aaaa.
-
APELIDOESTAB do SQL informa Matriz, Filial 2, Filial 3. codigo_filial_from_apelido: Pelo retorno do SQL trata essa informação e salva como 1, 2, 3. Sendo 1 Matriz, 2 Filial, 3 Filial(2).
-
- Nome
- Numero
- Filial
- Endereco
- Inicio_atividade
- CNPJ
- Inscricao_estadual
- Inscricao_municipal
- Contato
- Cnae
- Atividade_federal
- tipo_registro
- Faz a importação do plano de contas separando contas analíticas e sintéticas importando do banco legado Questor(Firebird):
- Faz a validação das contas encontradas para nao duplicar (Apenas atualiza contas novas)
- CONTACTB: Conta contabil no plano de contas da empresa
- TIPOCONTA: Informa 1 ou 2, sendo 1 sintetica e 2 analítica
- DESCRCONTA: Informa o nome da conta contabil
- INSCRFEDERAL: Informa o CNPJ da empresa
- NATURSALDO: Natureza da conta débito ou crédito
- CODIGOEMRPESA: Informa o codigo da empresa presente no banco
- Cliente
- Contactb
- Classifconta
- Tipoconta
- Descrconta
- Incrfederal
- Natursaldo
- Data_importacao
- Realiza a importação das despesas buscando pelas contas com classificação iniciando em "5.7" (despesas). Faz a validação pelo plano de contas importado para cada empresa, separando sempre por mês e ano.
- DATALCTOCTB: Data do lançamento contábil
- VALORLCTOCTB: Valor do lançamento contábil
- CODIGOESTAB: Codigo filial (1,2,3)
- cliente
- mes
- total_receitas
- total_despesas
- Realiza a importação das receitas buscando pelas contas com classificação iniciando em "4.0" (receitas). Faz a validação pelo plano de contas importado para cada empresa, separando sempre por mês e ano.
- DATALCTOCTB: Data do lançamento contábil
- VALORLCTOCTB: Valor do lançamento contábil
- CODIGOESTAB: Codigo filial (1,2,3)
- cliente
- mes
- total_despesas
-
Importa valores de faturamento por empresa e vincula a cada cliente existente no DJANGO:
-
Faz o tratamento do CNPJ com a função normalize_cnpj, para retornar apenas numeros ex: 85.411.064.0001-38 > 85411064000138
-
Importa as informações do MODULO FISCAL, dados e informações deriva de notas fiscais lançadas.
-
- INSCRFEDERAL: CNPJ do empresa
- DATALCTOFIS: Data do lançamento da nota fiscal (data NF)
- VALORCONTABILIMPOSTO: Valor deduzido para alcançar o valor correto de faturamento.
- LCTOFISSAICFOP: CFOP da nota fiscal de saída
- CODIGOESTAB: Codigo filial (1,2,3)
- CODIGOCFOP: CFOP do lançamento
- CFOPREGRA: Filtra pela regra de CFOP apra ignorar notas de devolução(exemplo)
- cliente
- mes
- valor
-
Importa valores do imposto Simples Nacional por empresa e vincula a cada cliente existente no DJANGO.
-
Faz o tratamento do CNPJ com a função normalize_cnpj, para retornar apenas numeros ex: 85.411.064.0001-38 > 85411064000138
-
Importa as informações do MODULO FISCAL, os dados derivam da tabela TOTALSSIMPLESFEDERAL, vinculando pelo CODIGOOPERACAOFIS, o padrão é (2601, 2603, 2609, 2652).
-
- INSCRFEDERAL: CNPJ da empresa
- CODIGOESTAB: Filial
- DATATOTAL: Mes do imposto
- TOTALSSIMPLESFEDERAL: Valores do imposto
- CODIGOOPERACAOFIS: Tipo do imposto apurado, derivado do CFOP de cada nota fiscal.
- faturamento
- tipo
- valor
-
Importa informações dos sócios de cada empresa e vincula por cada cliente existe no DJANGO.
-
Faz o tratamento de digitos do CPF com "normalize_digits", recebe do SQL exemplo: 123.456.789.10 > 12345678910.
-
Verifica instancia da data de nascimento e faz o tratamento dos dados, se vier como: 01-01-1900 transforma em 01/01/1900.
-
Para o endereço foi criado a função (montar_endereco) para juntar, pois o retorno do SQL para o endereço possui varios campos.
-
Criado função para verificar o socio ativo. Verifica se a data fim de DATAFIMSOCIO é inferior a data atual, caso sim retorna False, impedindo o socio de ser incluido no banco de dados (DJANGO)
-
- ENDERECOSOCIO: Retorna a Rua
- NUMENDERSOCIO: Retorna o numero
- COMPLENDERSOCOIO: Retorna o complemento
- BAIRROENDERSOCIO: Retorna o bairro
- SIGLAESTADO: Retorna a sigla do estado, exemplo: "SC"
- CEPENDERSOCIO: Retorna o CEP
- cliente
- nome
- cpf
- rg
- data_nascimento
- endereco
- contato
- responsavel_receita
-
Realiza a sincronização completa de todos os dados por meio dos management commands, caso algum comando ocorra erro irá ocorrer um erro: "Erro crítico na etapa "comando" e o erro mencionado".
-
Tratado erro para qualquer tipo de erro que possa acontecer.
- atualizar_clientes
- importar_planos
- atualizar_socios
- atualizar_receitas
- atualizar_despesas
- importar_faturamento
- importar_simples
- atualizar_dashboard
- Otimizado logica para importação dos dados, tempo de resposta entre 20 a 30 sec.
-
Realiza a importação dos dados de acesso a prefeitura de cada empresa advindo da planilha do setor fiscal.
-
Importação faz a vinculação pelo CNPJ da empresa que vem da planilha e retorna o cliente_id, fazendo assim o vinculo com o DJANGO.
-
Realizado funções para:
- Normalizar: Normaliza o valor sem espaços.
- Normalizar_cnpj: Retornao CNPJ sem espaços.
- Normalizar_prefeitura: Retira hífen em nome de prefeituras.
- cliente
- login_prefeitura
- senha_prefeitura
- prefeitura
- Atualiza os responsáveis de cada setor por empresa, importando os dados de uma planilha derivada do sistema Gestta (controle de tarefas), faz o vínculo pelo CNPJ incluído caso o cliente esteja presente no banco DJANGO.
--arquivo > seleciona o caminho completo para o arquivo excel contendo as informações dos responsáveis
- Retorna no terminal as informações de sócios, selecionando por empresa ou id do sócio cadastrado
--id > socio que deseja consultar
--cnpj > cnpj do cliente para consultar (123456789)
- Retorna no terminal as informações de clientes cadastros, selecionando por CNPJ ou código da empresa cadastrada.
--cnpj > CNPJ do cliente que deseja consultar
--codigo_empresa > Codigo da empresa que deseja consultar
- NOMEESTABCOMPLETO: Retorna o nome da empresa completo
- CODIGOEMPRESA: Retorna o codigo da empresa no Questor
- APELIDOESTAB: Retorna o nome fantasia da empresa
- EMAIL: Email cadastrado
- INSCRFEDERAL: Retorna o CNPJ
- DDDFONE: Retorna o DDD do telefone cadastrado
- NUMEROFONE: Retorna o numero de telefone cadastrado para empresa
- Exclui um cliente cadastrado no banco Django selecionando por CNPJ.
--cnpj > CNPJ do cliente que deseja excluir
- Exclui sócios do banco pelo CPF, CNPJ da empresa ou todos.
--cpf > CPF do cliente que deseja excluir
--cnpj > CNPJ do socio que deseja excluir
--todos > Remove todos socios do banco (warning!)
- Altera informações do banco pelo CNPJ da empresa.
--cnpj > CNPJ da empresa que deseja alterar
--set (tabela que deseja alterar), exemplo de uso:
--cnpj=123456789 --set inscricao_municipal=123456 filial=2
- Realiza um backup do banco de dados DJANGO salvando-o na pasta raiz do projeto.
- Realiza a restauração do backup, arquivo .fbk do banco legado Questor, utilizado para descompactação, retornando em um arquivo .fdb onde é realizado as consultas e importações de informações.
--fbk > caminho do arquivo .FBK
--destino > Caminho onde o banco para consulta irá ser criado (.fdb)
--usuario > Usuario do banco legado firebird.
--senha > Senha do banco legado firebird
--gbak > caminho para o gbak (gbak.exe) utilizado para descompactação.
- A descompactação deve ser realizada utilizando Firebird_2_5, com intuíto de minimizar erros e divergencias de versão.
- A aplicação Central Atlas foi estruturada em multiplos APPS do Django, organizados de acordo com suas responsabilidades e domínio de negócio.
- O app_clientes é responsavel pelo gerenciamento, armazenamento e execução das rotinas de tratamento e importação dos dados provenientes do sistema legado Questor (Firebird). Além disso, realiza a disponibilização dessas informações por meio da interface da aplicação, permitindo consultas em ambiente de rede interna.
A aplicação concentra regras e dados específicos de negócio, como cliente, faturamento, impostos e informações contábeis.
Os management commands estão presentes, mantendo a proximidade entre a regra de negócio e as rotinas de importação, consulta e manutenção dos dados.
- O app_variaveis é responsável pelo controle e apoio dos processos assíncronos do sistema, permitindo a utilização de processos em segundo plano sem impactar a aplicação principal.
Ele atua em conjunto com o Celery e o Redis centralizando informações de estado, parâmetros e controle das execuções assíncronas.
