

PORTAL DE DOCUMENTOS FISCAIS - TABELAS EXTERNAS
Quando pensamos em construir um BANCO DE DADOS DE DOCUMENTOS FISCAIS, temos de lançar nele, todas as informações que sejam relevantes para futura consulta, a fim de atender aos nossos vários clientes.
Nem sempre as informações solicitadas por eles existem nos documentos fiscais, por vezes vamos ter de agregar esses dados utilizando como origem TABELAS EXTERNAS para completar o que foi colocado nas determinações desses clientes, seja para construir o SPED, seja para construir os relatórios dos ÓRGÃO REGULADORES ou mesmo para atender uma SOLICITAÇÃO INTERNA e GERENCIAL da empresa.
No gráfico acima, colocamos uma lista de algumas possíveis tabelas que são utilizadas no mercado, mas vamos ser realistas, EXISTEM EXIGÊNCIAS LEGAIS, REGULATÓRIAS OU MESMO INTERNAS que NÂO SERVEM PARA ABSOLUTAMENTE NADA, mas são solicitações oficiais e não temos como não fornecer essas informações.
Como exemplo temos o fato de que quando você fala em tabela de localidades para uma empresa privada, fala apenas de alguns endereços uma vez que normalmente não existem muitas plantas, mas quando você fala na mesma tabela para o Setor Elétrico ou Setor de Telefonia, podemos estar trabalhando com umas 200.000 localidades.
E o CEP que a ANATEL exige nas relações de Bens Reversíveis, nunca na história da construção dos CNL´s (Cadastros de Localidades) existiram em sua composição, então para não descumprir a necessidade, muitas empresas usam CEP´s Genéricos para o Município, já que o levantamento e ajuste das tabelas de localidade demanda um custo relativamente alto a fim de gerar uma informação que deve servir para alguma coisa, mas eu não consigo ver sua aplicabilidade.
Muitos de vocês devem estranhar meus questionamentos, mas vamos lembrar que os fazedores de normas e leis são profissionais de bancada e nem sempre conhecem a realidade do chão de fábrica, sendo assim tem de ser questionados e suas leis em alguns casos remodeladas.
O BANCO DE DADOS DE DOCUMENTOS FISCAIS seria o PORTAL mais importante de entrada de dados para na empresa, a partir das informações imputadas nesse banco, todas as formatações necessárias para SISTEMAS FISCAIS e OUTROS seriam migradas a partir de FILTROS e relacionamento com TABELAS EXTERNAS exigidas pelo SISTEMA FIM.
O grande problema para o pessoal de desenvolvimento na área de TECNOLOGIA DA INFORMAÇÃO é a construção dos relacionamentos de TABELAS, que pensando em ACESS 2003, exigem chaves de relacionamento perfeitas, como por exemplo quando queremos levantar o CÓDIGO DO MUNICIPIO DO IBGE, precisamos construir uma chave que tenha NOME DO MUNCIPIO DO DOCUMENTO FISCAL (+) ESTADO DA FEDERAÇÃO, já que podemos ter municipios com o mesmo nome em estados diferentes.
Essa informação pode passar batido para muitos de vocês, mas quem conhece um pouco de estrutura de sistemas, vai entender a demanda e vai saber que para cada tabela vai existir uma CHAVE ESPECIFICA para que seu relacionamento exista.
Vamos lembrar que não estamos tratando nessa exposição, da veracidade das informações, nessa fase estamos apurando as entradas de dados no sistema com base documental, subentendendo que todas as aprovações orçamentárias, que todos os aceites de conformidade, toda verificação fiscal já foi efetuada, alguns processos antes da efetivação da compra e outros momentos antes do documento ser remetido ao portal.
Usar as experiências de onde passamos para agregar é uma coisa importante e em uma das empresas onde passei, durante esse processo tínhamos um profissional, cuja função era analisar todos os documentos de entrada, lógico que em função da demanda ele fazia a seleção seguindo critérios nascidos de sua experiência, nessa fase eram conferidos impostos, material e sua conformidade com os contratos, possíveis compras não conforme com o projeto, possíveis aprovações não conforme com as normas de delegação e outras, seria uma auditoria antes da auditoria, acho que todas as empresas deveriam ter um AUBENI no seu quadro, odiado por muitos, mas era o primeiro ponto a favor da utilização da SOX pela empresa.
Como falamos o PORTAL DE DOCUMENTOS FISCAIS, seria a porta de entrada de dados para todos os sistemas em uso na empresa, incluindo o ERP ESCOLHIDO para seus trabalhos do dia a dia, contando inclusive com o escaneamento do documento de origem para viabilizar o DRILL DRAW posterior.
Para cada destino, seriam feitos filtros com as informações necessárias para interface com o sistema fim, sendo migrado apenas aquilo que fosse necessário para seu processamento, dessa forma o CEP não seria migrado para os ERP´s, que até tem tabelas de localidade em seus registros, mas não necessitam dessa informação, a menos que depois deles essa informação fosse exigida, mas nesse caso a concatenação poderia ser feita no sistema que vem depois sem poluição do ERP com dados desnecessários e que podem impactar na sua performance.
A área de TECNOLOGIA DA INFORMAÇÃO teria de criar um processo de integridade entre o PORTAL e os ERP´s / SPED / REGULATÓRIOS e outros, entendo que esse processo seria fácil, utilizando FLAG´s como indexadores e chaves sistêmicas para amarração.
No próximo post, vamos falar um pouco sobre LANÇAMENTOS CONTÁBEIS, nós falamos em sistemas, em arquivos, em necessidades fiscais em tudo, mas não falamos sobre lançamentos contábeis e ai vem a pergunta: SOMOS CONTADORES OU ANALISTAS DE SISTEMAS ?
Abraços




