BANCO DE DADOS - SOLUÇÃO E NÃO PROBLEMAS

 

12/04/2013 16:13

 

Matar a cobra e mostrar o pau é fácil, dizer como não se deve fazer uma coisa é fácil, mostrar problemas é fácil, mas em uma das empresas onde trabalhei tinha um chefe japonês que costumava falar o seguinte:

 

“NÃO QUERO QUE VOCE ME TRAGA PROBLEMAS, QUERO QUE VOCE ME TRAGA SOLUÇÕES”

 

Vamos neste trabalho vamos abordar algumas sugestões de soluções, tudo em contabilidade, principalmente em controle de ativo fixo, depende da estruturação de um banco de dados e da manutenção ordenada e regrada das entradas, sejam, por movimentos mensais ou por cargas.

 

Não vou falar nesse item ainda de como os dados tem de ser agregados ao arquivo, vamos juntos analisar o que deve ter um arquivo, que informações importantes deve conter ele para atender nossas necessidades.

 

Cada empresa tem uma estrutura, sendo assim o desenho de um arquivo pode variar dependendo do fim ao qual se destina, no nosso caso seria o banco de dados dos Sistemas Sispro, SAP AM, FA Consist, Patrim e outros do mercado.

 

Esse banco de dados não serve para atender o Livro CIAP, porque ele vai conter os ativos fim, muito embora seja possível saber o que é produção e o que não é produção não podemos utilizar ele para compor o CIAP porque as exigências legais são montadas em cima de Documentos Fiscais individuais e aqui podemos ter um equipamento que em sua composição vamos ter 30 ou 40 documentos fiscais.

 

Para compor o CIAP, as melhores fontes seriam os livros de registros de entrada, os sistemas de controle de ordens de serviço como o SAP FI ou o próprio SPEED Fiscal, haveria sim links com nosso arquivo para prova de o equipamento ser produtivo, mas só isso.

 

Vamos a estruturação do arquivo:

 

• Levantar as necessidades da nossa empresa, contas, centros de custos, unidades de negócio, necessidades regulatórios (reversível ou não), necessidades de seguros, informações básicas para alimentar parte do CIAP

• Que sistema vamos usar e como ele funciona e que informações são possíveis de colocar dentro do mesmo - SAP AM, Sispro, FA Consist

• Quais são as origens das nossas informações, se temos um sistema de obras em andamento, se estamos em um ERP Oracle ou SAP.

 

Uma sugestão de banco de dados seria esta:

 

Este banco de dados (ARQUIVO PDF) foi desenvolvido ao se analisar uma empresa de telefonia, mas eu que já trabalhei com empresas dos ramos de transformação plástica de alumínio, fundição, garrafas plásticas, industriais, editoras, químicas inorgânicas acho que esse é o modelo mais complexo e que pode perfeitamente ser adaptado a qualquer ramo de negocio.

 

 

 

 

 

 

 

 

 

 

 

 

 

Entendo que ao analisar um banco de dados dessa natureza, já podemos pensar em implementar um sistema de controle de imobilizados, lógico que dependendo da empresa como em telefonia vamos precisar de varias tabelas como a relação de localidades do IBGE, tabelas de centros de custos da empresa, tabelas de CNL da Anatel enfim tem de ser construído um modelo de amarração, mas o arquivo básico teria de ser alguma coisa parecida com o que mostramos acima.

 

Para exemplificar segue um print da tela do ACESS utilizado em uma empresa onde temos os arquivo do Ativo Fixo ligado a algumas tabelas que vão traduzir os codigos de local e centro de custo lançados nesse arquivo:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A complexibilidade das integrações de tabelas depende das necessidades da empresa e o maior objetivo dessa migração para ACESS 2003, gosto mais dessa versão, é construir arquivos para clientes não contabeis com descrições de dados da contabilidade que não são amigaveis a esses clientes, um exemplo seria o Centro de Custo 25236, legal um numero, mas o Auditor, o analista do orgão Regulador e nem mesmo eu sei o que significa esse numero, mas se voce colocar que é o setor de Pintura todos vão ler e entender.

 

Nos sistemas de ativo lançados no mercado Sispro, SAP AM, FA Consist e outros, voce só ve o numero do centro de custo e não os dados desse centro de custo.

 

Nas empresas onde trabalhei sempre montei junto a area de Tecnologia da Informação um extrator de arquivos em TXT que eram migrados mensalmente para uma planilha de ACESS, mais facil de levantar, mais facil de verificar e com os campos que eu precisava.

 

Quando fazendo o curso na SAP São Paulo, os tecnicos me perguntaram porque eu queria essa migração, não conhecia ainda o SAP, disse que precisava porque era um modo de trabalhar, na verdade eles não gostam dessas migrações alegam que voce perde confiabilidade.

 

Só que o sistema SAP que custa uma fabula, não da suporte para a construção dos arquivos para atender a resolução 447 da Anatel que exige a remessa de arquivos do ativo em XML e nos padrões Anatel, mudando inclusive o Plano de Contas que para a empreesa é um e para a Anatel é outro, montamos esse DE/PARA com a utilização do arquivo migrado em TXT e adição de tabelas Anatel.