data minig e sintegra
TRANSCRIPT
CENTRO UNIVERSITRIO FEEVALE INSTITUTO DE CINCIAS EXATAS E TECNOLOGICAS CURSO DE BACHARELADO EM CINCIA DA COMPUTAO
UM MODELO DE FERRAMENTA PARA A GERAO DO ARQUIVO SINTEGRA
por
Jaques Metz
Professor orientador: Prof. Ms. Ricardo Ferreira de Oliveira
Novo Hamburgo, novembro de 2006.
CENTRO UNIVERSITRIO FEEVALE INSTITUTO DE CINCIAS EXATAS E TECNOLOGICAS CURSO DE BACHARELADO EM CINCIA DA COMPUTAO
UM MODELO DE FERRAMENTA PARA A GERAO DO ARQUIVO SINTEGRA
por
Jaques Metz
Trabalho de Concluso submetido avaliao, como requisito parcial para a obteno do grau de Bacharel em Cincia da Computao
Professor orientador: Prof. Ms. Ricardo Ferreira de Oliveira
Novo Hamburgo, novembro de 2006.
AGRADECIMENTOS
Agradeo e dedico esta conquista a meus pais, que proveram meus estudos e me incentivaram nas horas difceis. Sem eles, esta etapa de minha vida no teria se completado. Aos meus colegas de servio, principalmente ao scio e grande amigo Luciano pelas sugestes e incentivos, que foram muito importantes. Aos amigos, pela compreenso nas horas de ausncia. Ao professor orientador, pela confiana e troca de experincias. Obrigado.
RESUMO
Atualmente, as organizaes tm utilizado a tecnologia EDI Electronic Data Interchange (intercmbio eletrnico de dados) para trocar informaes, no que diz respeito s transaes de compra e venda efetuada entre as mesmas. Da mesma forma, as organizaes devem enviar Secretaria Estadual da Fazenda (SEFAZ) de seu estado de origem o chamado arquivo SIntegra Sistema Integrado de Informaes sobre Operaes Interestaduais com Mercadorias e Servios que um arquivo EDI contendo informaes sobre operaes de compra e venda de mercadorias e servios. Desenvolvedores de software na rea de comrcio necessitam grande conhecimento da legislao vigente para implementar em seus sistemas a rotina de gerao do arquivo SIntegra. O problema surge justamente no fato de que os desenvolvedores de software devem conhecer a legislao para criar sua rotina de gerao do arquivo SIntegra, ou adquirir alguma biblioteca de vnculo dinmico (DLL) existente no mercado que gere o mesmo. Contudo, estas bibliotecas, apesar de gerarem o arquivo formatado e validado, exigem do desenvolvedor muitas linhas de programao. Utilizando a tecnologia ETL Extract, Transform & Load (extrair, transformar e carregar) aliada aos conceitos de Programao Orientada a Objetos (POO), possvel desenvolver uma rotina de gerao do arquivo SIntegra que exija do desenvolvedor pouco ou nenhum conhecimento sobre a legislao do SIntegra. Alm disso, o desenvolvedor vai necessitar de apenas algumas linhas de cdigo para chamar a rotina principal de gerao do arquivo, ao contrrio das solues j existentes, onde a criao do arquivo exige a chamada de vrios mtodos.
5
Assim sendo, este trabalho tem por objetivo levantar e relacionar os diversos aspectos legais e funcionais da legislao concernente ao SIntegra, alm de modelar e implementar uma DLL que disponha de toda a funcionalidade necessria gerao do arquivo SIntegra. Procurar-se- focar nos aspectos de fcil utilizao e configurao por parte dos desenvolvedores. Para tanto, pretende-se fazer uso das tecnologias ETL e EDI, implementando e utilizando os conceitos da POO. Palavras-chave: SIntegra, ETL e Desenvolvimento de componentes Delphi.
ABSTRACT
Title: A TOOL PROTOTYPE FOR THE SINTEGRA FILE GENERATION
Actually, companies have made use from EDI Electronic Data Interchange technology to interchange information about buy and sell transactions between themselves. By the same way, this companies need to send to their State Treasury Bureau the SIntegra file, which is a EDI file with information about buy and sell transactions. Software developers need a great know-how about legislation to develop in their computer systems the SIntegra file generation routine. The problem appears right here, when software developers need to know the legislation to implement the SIntegra file generation routine, or acquire some third-party library that will do the job. However, despite this libraries generate the formatted and validated file, they demand many lines of code. Making use of the ETL Extract, Transform & Load technology, joint by the concepts of Object Oriented Programming (OOP), is possible to develop a routine to generate the SIntegra file that demand from developer none or a minimum know-how about SIntegra legislation. Moreover, the software developer will need a few lines of code to call the main routine, in opposite of the third-party solutions, which need to call many methods to generate the SIntegra file. In this way, this project is intended to lift and list the many legal and functional aspects of legislation about SIntegra, and also modeling and implementing a library in Delphi programming language that has all the functionality necessary to generate the
7
SIntegra file. It will focus on ease of use and configuration on developers side. For this, it will made use of ETL and EDI technologies, implementing and using the OOP concepts. Keywords: SIntegra, ETL and Delphi component development.
LISTA DE FIGURAS
Figura 1.1 Processo ETL (KIMBALL e CASERTA, 2004). ................................................. 19 Figura 1.2 Mapa Lgico dos Dados parte 1 (KIMBALL e CASERTA, 2004).................... 23 Figura 1.3 Mapa Lgico dos Dados parte 2 (KIMBALL e CASERTA, 2004).................... 24 Figura 1.4 Processo de checagem de erros (KIMBALL e CASERTA, 2004)........................ 27 Figura 2.1 Fluxo dos dados EDI. .......................................................................................... 30 Figura 2.2 (EANBRASIL, 2006).......................................................................................... 34 Figura 2.3 (EANBRASIL, 2006).......................................................................................... 35 Figura 3.1 Aplicativo de Demonstrao da Sintegra32Dll. ................................................... 47 Figura 3.2 Aplicativo de Demonstrao do Componente SIntegra Projeto Sultan. ............. 49 Figura 4.1 Diagrama de Classes. .......................................................................................... 55 Figura 4.2 Diagrama de Atividades. ..................................................................................... 56 Figura 4.3 Definio do mapa lgico para a Entidade Produto.............................................. 59 Figura 5.1 Aplicativo de Teste. ............................................................................................ 68 Figura 5.2 Estrutura ETL do Componente SWSintegra ........................................................ 71
LISTA DE TABELAS
Tabela 2.1 Modelos de Documentos Fiscais. (ICMS76/03, 2003)......................................... 38 Tabela 3.1 Formulrio de Avaliao de Software. ................................................................ 44
LISTA DE ABREVIATURAS
EDI SEFAZ DLL ETL POO OOP VIES VAT UE
Electronic Data Interchang Secretaria Estadual da Fazenda Dynamic Link Library Extract, Transform & Load Programao Orientada a Objetos Object Oriented Programming VAT Information Exchange System Value Added Tax Unio Europia
SINTEGRA Sistema Integrado de Informaes sobre Operaes Interestaduais com Mercadorias e Servios XML SQL UML SGDB PNAFE Brasileiros ICMS Imposto sobre Circulao de Mercadorias e Prestao de Servios Extended Markup Language Structured Query Language Unified Modeling Language Sistema de Gerenciamento de Banco de Dados Programa Nacional de Apoio Administrao Fiscal para os Estados
11
CNPJ CFOP IPI PDV ABNT UF ONU
Cadastro Nacional de Pessoa Jurdica Cdigo Fiscal de Operao Imposto sobre Produtos Industrializados Ponto de Venda Associao Brasileira de Normas Tcnicas Unidade de Federao Organizao das Naes Unidas
SUMRIO
INTRODUO................................................................................................................... 14 1 SISTEMAS ETL.......................................................................................................... 19 1.1 1.2 1.3 2 2.1 2.2 2.3 2.4 Extract a extrao dos dados .............................................................................. 20 Transform a transformao dos dados................................................................ 24 Load a carga dos dados...................................................................................... 28 Conceito de EDI ................................................................................................... 30 Benefcios do EDI ................................................................................................ 32 Padronizao ........................................................................................................ 35 Convnio ICMS 76/03.......................................................................................... 37 Registro 10 ................................................................................................... 37 Registro 11 ................................................................................................... 37 Registro 50 ................................................................................................... 37 Registro 51 ................................................................................................... 38 Registro 53 ................................................................................................... 39 Registro 54 ................................................................................................... 39 Registro 55 ................................................................................................... 39 Registro 56 ................................................................................................... 39 Registro 60 ................................................................................................... 40 Registro 61 ................................................................................................... 40 Registro 70 ................................................................................................... 40 Registro 71 ................................................................................................... 40 Registro 74 ................................................................................................... 41
O ARQUIVO SINTEGRA ........................................................................................... 29
2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.4.9 2.4.10 2.4.11 2.4.12 2.4.13
13
2.4.14 2.4.15 2.4.16 2.4.17 3 3.1 3.2 3.3 3.4 4 4.1 4.2
Registro 75 ................................................................................................... 41 Registro 76 ................................................................................................... 41 Registro 77 ................................................................................................... 41 Registro 90 ................................................................................................... 41
SISTEMAS DISPONVEIS NO MERCADO............................................................... 43 Mtodo de Avaliao............................................................................................ 43 Biblioteca Sintegra32Dll....................................................................................... 45 DLLs ........................................................................................................... 45 Componente SIntegra - Projeto Sultan .................................................................. 47 Resultados ............................................................................................................ 49 Modelagem do Componente ................................................................................. 53 Implementao do Componente............................................................................ 57 TSWSintegra ................................................................................................. 57 TETL ............................................................................................................ 58 TEntidades.................................................................................................... 58 TExtracao ..................................................................................................... 60 TCarga ......................................................................................................... 61
3.2.1
PROPOSTA PARA UM NOVO COMPONENTE ....................................................... 51
4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 5 5.1 5.2
AVALIAO DO COMPONENTE ............................................................................ 65 Caso de Teste ....................................................................................................... 66 Resultados do Caso de Teste................................................................................. 67 Sintegra32dll................................................................................................. 68 Projeto Sultan ............................................................................................... 69 Componente SWSIntegra.............................................................................. 70
5.2.1 5.2.2 5.2.3
CONCLUSO..................................................................................................................... 73 REFERNCIAS BIBLIOGRFICAS.................................................................................. 75 ANEXOS............................................................................................................................. 77 ANEXO A FORMULRIO DE AVALIAO DE SOFTWARE .................................... 78
INTRODUO
Tema
Este trabalho trata do uso dos conceitos da tecnologia ETL Extract, Transform & Load (Extrair, Transformar e Carregar), alm da avaliao de solues j existentes no mercado, para a modelagem e implementao de uma ferramenta para a gerao do arquivo Sintegra focada na facilidade de uso e configurao por parte dos desenvolvedores de software.
Motivao
Atualmente as organizaes tm trocado informaes a respeito de suas transaes de compra e venda eletronicamente, atravs de arquivos EDI Electronic Data Interchange (troca eletrnica de dados), a fim de diminuir o volume de insero de dados manuais em seus sistemas de controle (UNI5, 2006). Freqentemente, essas organizaes no tm o mesmo fornecedor de software, o que dificulta a troca de informaes num padro comum. Para tanto, empresas de software especializaram-se na tecnologia EDI, e criaram um servio que possibilita a troca de arquivos por meio eletrnico sem que os fornecedores de software tenham que desenvolver os layouts de importao e exportao de arquivos de seus concorrentes: as organizaes interessadas em trocar informaes de compra e venda com seus clientes e/ou fornecedores contratam os servios das empresas especializadas em EDI.
15
Esta, por sua vez, recebe de seus clientes o layout dos arquivos gerados nos sistemas de controle destes e, com o auxlio de ferramentas de ETL Extract, Transform & Load, desenvolve as ferramentas que faro o trabalho de transformar os arquivos que esto num layout A, para arquivo no formato do layout B, e vice-versa (HENRY et al., 2005). J com o arquivo SIntegra um pouco diferente. O SIntegra teve seu incio em 1997, e foi baseado no VIES VAT Information Exchange System (Sistema de troca de Informaes sobre VAT1), sistema este implantado na Unio Europia (UE) em 1992. Atravs do VIES, foi abolido o controle fsico de mercadorias nas fronteiras dos pases membros da UE (SINTEGRA, 2006). O arquivo SIntegra deve ser enviado eletronicamente assim sendo, ele um arquivo EDI por organizaes que efetuam compra e/ou venda de bens e servios. Este arquivo deve ser enviado Secretaria Estadual da Fazenda (SEFAZ) do estado origem da organizao, e esta, por sua vez, cruza as informaes obtidas com as outras secretarias estaduais. O layout dos arquivos, no importando o estado em que se encontra a organizao, nico, ou seja, se uma empresa desenvolvedora de software atende mais de um estado brasileiro, no precisa se preocupar com a legislao estadual, pois o layout do arquivo SIntegra obedece legislao federal. A problemtica surge justamente neste ponto: a legislao. Pelo fato do arquivo SIntegra ser o instrumento de um sistema integrado SIntegra o acrnimo de Sistema Integrado de Informaes sobre Operaes Interestaduais com Mercadorias e Servios que visa controlar se as organizaes esto fornecendo s secretarias estaduais da fazenda as informaes relativas s operaes de compra e venda de bens e servio. Assim sendo, o desenvolvedor que desejar implementar a rotina de gerao do arquivo SIntegra deve ter conhecimento bastante avanado da legislao, principalmente no que diz respeito a modelos de documentos fiscais, operaes fiscais, entre outros. O objetivo deste trabalho levantar as caractersticas e funcionalidades relacionadas gerao do arquivo SIntegra alm de elaborar uma biblioteca em forma de componente Delphi que possa eximir o desenvolvedor da necessidade de conhecer a legislao que permeia o arquivo SIntegra, ou mesmo a estrutura interna do mesmo. Como se sabe, j existe no mercado solues sob a forma de bibliotecas de vnculo dinmico (DLLs), ou at mesmo classes de objetos Delphi que sero analisadas durante o trabalho que geram o arquivo, mas estas solues exigem que o desenvolvedor tenha conhecimento da estrutura interna do arquivo, e implementar a rotina pode desprender muito tempo do desenvolvedor.1
VAT - VALUE ADDED TAX (Imposto sobre Valor Agregado corresponde ao ICMS (Imposto sobre Circulao de Mercadorias e Servios)).
16
A estrutura interna do arquivo SIntegra bastante complexa, pois ele pode ser formado por vrios tipos de registro, dependendo das informaes relacionadas s operaes de compra e venda de mercadorias e servios da organizao que for gerar o arquivo. Com o uso de alguns conceitos da tecnologia ETL esta tecnologia a base para a implementao de repositrios de dados (data warehouses) (KIMBALL e CASERTA, 2004) possvel extrair dados relevantes dos sistemas de origem, transform-los, corrigir os possveis erros, para finalmente disponibilizar a informao no formato necessrio.
Um sistema ETL bem modelado extrai as informaes dos sistemas de origem, refora a qualidade dos dados e os padres de consistncia, padronizando os dados, assim diferentes fontes de dados podem ser usadas em conjunto, e finalmente disponibiliza os dados em um formato pronto para ser utilizado, do modo que desenvolvedores podem desenvolver seus sistemas utilizando estes dados, assim como usurios finais podem tomar decises. (KIMBALL e CASERTA, 2004).
Deste modo, a biblioteca a ser desenvolvida vai extrair as informaes necessrias, e a partir destas vai gerar o arquivo SIntegra com seus devidos registros. As informaes necessrias podem ser extradas e/ou alocadas de modos diferentes por essa razo os sistemas ETL so muitas vezes nomeados de staging areas, ou reas de alocao temporria (KIMBALL e CASERTA, 2004). Pensando nisso, o prottipo deve comportar mais de um tipo de entrada de dados neste caso, prope-se o suporte a arquivos estruturados XML Extended Markup Language, bem como o acesso direto a bancos de dados atravs de consultas no padro SQL Structured Query Language. A adaptabilidade da qual dispor esta biblioteca um principais agentes motivadores deste trabalho, visto que o mercado de software necessita de uma soluo de fcil adaptao aos sistemas em desenvolvimento, bem como aos sistemas j desenvolvidos. Visto que a legislao brasileira freqentemente sofre alteraes, conveniente que os desenvolvedores no tenham que se preocupar se sua rotina de gerao do arquivo SIntegra est de acordo com a legislao vigente. Assim sendo, uma soluo para o problema da gerao do arquivo SIntegra em forma de prottipo desejvel.
17
Objetivos
Este trabalho tem como objetivo geral modelar e implementar um componente na linguagem Delphi para a gerao do arquivo SIntegra, de fcil configurao e utilizao pelos desenvolvedores de software, visando contribuir para simplificar e documentar as transaes de informaes sobre operaes de compra e venda de mercadorias e servios.
Como objetivos especficos, podem ser destacados: Avaliar as solues para a gerao do arquivo SIntegra j existentes no mercado: fazer um estudo sobre o funcionamento e estrutura dos prottipos j existentes no mercado, a fim de identificar pontos positivos e negativos na sua implementao e utilizao, para posterior utilizao, quando da modelagem e implementao da soluo a ser proposta neste trabalho; Estudar a tecnologia ETL e casos de uso: para utilizar os conceitos da tecnologia ETL na modelagem e implementao da biblioteca de gerao do arquivo SIntegra proposta neste trabalho, necessrio o estudo da mesma. Como a implementao de sistemas ETL se divide em milhares de subcasos, que dependem do tipo de fonte de dados, regras de negcio, sistemas de software pr-existentes, entre outros (KIMBALL e CASERTA, 2004), deve ser feito um estudo sobre qual metodologia ETL melhor se aplica proposta do trabalho; Caracterizar a estrutura do arquivo SIntegra: Por se tratar de um arquivo estruturado, o arquivo SIntegra possui vrios tipos de registros diferentes. Para compreender a complexidade que envolve a gerao do arquivo SIntegra, deve-se caracterizar cada tipo de registro; Modelar e Implementar o prottipo para gerao do arquivo SIntegra: aps avaliar as solues existentes no mercado, definir a melhor metodologia de uso do ETL a ser aplicada e caracterizar os tipos de registro do arquivo SIntegra, criar os modelos e diagramas UML do componente Delphi a ser desenvolvido, e aps validao dos modelos, implementar a soluo. Aps a implementao
18
do componente, o mesmo ser testado em um sistema de controle real, para posterior avaliao dos resultados.
Estrutura do Texto
O captulo 1 apresenta o funcionamento de sistemas ETL, que vo servir de base para a implementao do componente para a gerao do arquivo SIntegra. O captulo 2 apresenta o arquivo SIntegra, sua estrutura interna e quem obrigado a envi-lo s Secretarias Estaduais da Fazenda. Ao explicar a estrutura interna do mesmo, possvel diagnosticar pontos crticos na implementao da rotina de gerao deste, principalmente no que diz respeito legislao concernente ao SIntegra. O captulo 3 apresenta as solues para a gerao do arquivo SIntegra j existentes no mercado. Estas sero avaliadas atravs de um formulrio de mtricas de software, para apontar pontos positivos e negativos na implementao e utilizao das mesmas. A partir destes resultados, ser possvel apresentar a proposta de um novo componente para gerar o arquivo SIntegra. justamente sobre a proposta do novo componente que o captulo 4 vai falar. Neste captulo ser explanado qual ser a proposta de funcionamento do componente, e qual ou quais vantagens este vai apresentar em relao s solues j existentes no mercado. Alm disso, sero apresentados os modelos UML do novo componente a ser implementado, de forma a facilitar o entendimento do mesmo. A ltima seo do captulo explana sobre a implementao do componente modelado, tratando mais especificamente do seu funcionamento interno e de como foram usados os conceitos de ETL para a implementao do mesmo. Finalmente, o captulo 5 faz uma avaliao do componente proposto e agora implementado neste trabalho, fazendo um comparativo entre as solues existentes no mercado e o componente desenvolvido neste trabalho.
1
SISTEMAS ETL
Sistemas ETL so muito importantes quando necessrio reunir uma grande quantidade de informaes, e destas extrair dados que auxiliem na tomada de deciso nas organizaes. Nos sistemas de controle das organizaes existe uma enorme quantidade de dados, mas muitas vezes estes dados so dispostos em relatrios separados, no feito o vnculo adequado entre estes, no sendo possvel demonstrar ao nvel estratgico da organizao a real situao da mesma. Desta forma, no possvel tomar decises a respeito ou mesmo traar uma estratgia para o futuro da organizao. Este o objetivo dos sistemas ETL: extrair, limpar, padronizar e entregar uma ou mais fontes de dados em uma fonte de armazenamento de dados relacional (banco de dados) que suporte e implemente a consulta e anlise destes dados com o propsito da tomada de deciso (KIMBALL e CASERTA, 2004).
Figura 1.1 Processo ETL (KIMBALL e CASERTA, 2004). Vale lembrar que sistemas ETL so diferentes de sistemas de data mining: enquanto que em sistemas ETL os dados so extrados de arquivos estruturados (arquivos XML,
20
arquivos de texto com valores separados por vrgula etc.) ou diretamente de tabelas de bancos de dados relacionais, em sistemas de data mining os dados so extrados de textos ou documentos no estruturados, ou seja, os dados so extrados com ferramentas especficas que identificam nestes textos ou documentos padres, para ento extrair os dados desejados. A extrao dos dados feita baseada na anlise do contexto, diferentemente dos sistemas ETL, onde primeiramente feito um estudo aprofundado de todas as fontes de dados, em busca dos dados realmente necessrios extrao. Este trabalho no far uso de sistemas ETL, apenas usar os conceitos deste tipo de ferramenta para desenvolver o componente para a gerao do arquivo SIntegra. Assim sendo, necessrio explanar sobre as etapas de um sistema ETL que sero utilizadas na modelagem e implementao do mesmo, que so: Extract (extrao) - Transform (transformao) Load (carga).
1.1
Extract a extrao dos dados
Em sistemas ETL a fase de extrao dos dados a mais complexa e demorada. Isto porque nesta fase que se define quais sero os dados que se deseja extrair das diversas fontes de dados, bem como o modo como estes dados sero extrados. Quando projetos de repositrios de dados data warehouses - so iniciados em organizaes, notvel que um dos primeiros desafios encontrados pelos programadores o de integrar os dados dos diversos sistemas existentes na mesma, para que estes possam produzir resultados. Sem dvida, um data warehouse sem dados coerentes e estruturados no tem utilidade nenhuma. Assim, o primeiro passo da integrao deve ser a correta extrao dos dados dos sistemas de origem (KIMBALL e CASERTA, 2004). Cada fonte de dados tem um conjunto especfico de caractersticas, que precisam ser mensuradas e controladas, de modo que ocorra a extrao dos dados no processo de ETL. comum que existam vrios tipos de sistemas de controle nas organizaes, tais como: controle de vendas, controle de estoques, controle de produo entre outros. Como se no bastasse que estes sistemas no fossem integrados, eles geralmente so incompatveis, tanto fsica quanto logicamente. Desta forma, o processo de ETL deve integrar sistemas que possuem: Sistemas Gerenciadores de Bancos de Dados (SGBD) diferentes;
21
Sistemas Operacionais diferentes; Hardware diferenciado; Protocolos de comunicao diferentes.
Antes de iniciar o processo de extrao dos dados, deve-se primeiramente planejar o mesmo. Para tanto, necessrio fazer um mapa lgico dos dados, que documentar a relao entre os atributos originais dos sistemas de origem, e os atributos de destino que recebero os dados no processo de carga (Load). O mapa lgico de dados deve conter informaes referentes s tabelas e atributos de origem, bem como as tabelas e atributos de destino, que recebero os dados aps a extrao e transformao dos dados originais. A definio do mapa lgico dos dados imprescindvel em sistemas ETL, partir diretamente para a implementao acarretaria em perda de tempo integrar dados de diversas fontes de dados sem nenhuma anlise prvia inevitavelmente produziria erros de implementao e, sucessivamente o retrabalho; alm disso, formar-se-ia uma lacuna na documentao do sistema, tornando sua manuteno mais difcil (KIMBALL e CASERTA, 2004). O mapa lgico dos dados geralmente apresentado sob a forma de uma tabela ou planilha (figuras 1.2 e 1.3), contendo os seguintes componentes (KIMBALL e CASERTA, 2004): Nome da tabela destino: o nome atribudo tabela destino no repositrio de dados; Nome do atributo destino: nome do atributo que receber os valores no repositrio de dados; Tipo de tabela: indica o tipo de tabela destino. A tabela pode ser do tipo factual - contm apenas um evento ou registro, ou uma dimenso - contm uma srie de eventos ou registros; Tipo de SCD (slowly changing dimension, ou "dimenso alterada lentamente"): Para dimenses, este componente indica o tipo alterao que pode ser feita em cada dimenso. Os tipos podem ser 1 - Overwrite (Sobrescrita), 2 Partitioning History (as alteraes so guardadas em um histrico) e 3 Alternate Realities (houve uma alterao, mas o registro original vlido em algumas circunstncias). O tipo SCD pode variar nos diversos atributos de uma dimenso;
22
Base de dados de origem: nome da base de dados onde os dados de origem residem. Este componente geralmente define a string de conexo ao banco de dados, bem como pode ser o nome do arquivo tal qual est definido no sistema de arquivos;
Nome da tabela de origem: nome da tabela de onde os dados so provenientes. Em alguns casos sero necessrias mais de uma tabela. Nestes casos, sero listadas todas as tabelas necessrias para popular a respectiva tabela destino no repositrio de dados;
Nome do atributo de origem: o atributo ou os atributos necessrios para popular o atributo destino. Sero listados todos os atributos necessrios para carregar o atributo destino. As associaes dos atributos de origem sero documentadas no componente Transformao;
Transformao: especifica a manipulao necessria aos dados de origem para chegarem ao formato esperado ao final do processo ETL. Este componente geralmente descrito em SQL ou pseudocdigo.
Com a definio do mapa lgico dos dados, o desenvolvedor tem em mos tudo o que precisa para iniciar a implementao de seu sistema ETL, pois j foi definido de onde os dados sero extrados (base de dados de origem), quais dados sero extrados (tabelas e atributos de origem), como os dados sero extrados (transformao), e finalmente onde os dados sero alocados (tabelas e atributos destino).
23
Figura 1.2 Mapa Lgico dos Dados parte 1 (KIMBALL e CASERTA, 2004).
24
Figura 1.3 Mapa Lgico dos Dados parte 2 (KIMBALL e CASERTA, 2004).
1.2
Transform a transformao dos dados
A fase de transformao dos dados considerada a principal etapa de um processo ETL, pois nesta etapa que os dados agregam valor. As outras fases de extrao e carga dos dados so obviamente necessrias, mas elas apenas movem e reformatam os dados. J nesta fase de transformao, os dados recebem o tratamento necessrio e se pode ter uma noo de
25
onde os mesmos sero utilizados. Nesta fase desejvel que se obtenham trs resultados: um relatrio de definio dos dados, um relatrio com os eventos de erro, e o relatrio de auditoria. Para elaborar o relatrio de definio dos dados, deve ser feita uma minuciosa anlise das fontes de dados. O resultado desta anlise geralmente apresentado sob a forma de um repositrio de meta-dados, descrevendo: Definies em geral; Objetos de Negcio; Domnios; Fontes de dados; Definies de entidades; Sinnimos; Regras para os dados; Regras para os valores; Questes relevantes que devem ser levadas em conta.
Esta anlise da definio dos dados no apenas gera uma boa avaliao quantitativa das fontes de dados originais, como tambm influencia o contedo do relatrio de eventos de erro e do relatrio de auditoria. O relatrio de eventos de erro reporta todo e qualquer erro de qualidade dos dados. Isto quer dizer que, na etapa de transformao de um sistema ETL verificado se os dados originais possuem qualidade suficiente para serem utilizados. Assim, cada erro gerado gravado em uma tabela, para posterior utilizao no relatrio. Mas afinal, o que qualidade nos dados? Para Kimball e Caserta (2004), dados com qualidade devem ter as seguintes caractersticas: Corretude. Os valores e a descrio dos dados devem descrever verdadeira e fielmente os objetos associados a estes; No-ambigidade. Os valores e a descrio dos dados devem ter apenas um significado, ou seja, no podem ser ambguos; Consistncia. Os valores nos dados devem utilizar uma notao constante para
26
compreender seu significado. conveniente que se estabelea um padro e que este seja obedecido, por exemplo, com siglas de estado (RS Rio Grande do Sul, SP So Paulo etc.); Dados Completos. Dois aspectos devem ser observados: 1. O primeiro garantir que os valores individuais nos dados estejam atribudos (no nulos) para cada registro;2. O segundo aspecto deve garantir que o conjunto de registros esteja
completo, ou seja, garantir que no houve perda de dados no fluxo da informao. Desse modo, o processo de transformao de um sistema ETL tem por objetivo melhorar a qualidade dos dados extrados. Esse processo de melhoria na qualidade dos dados obtm-se atravs de uma srie de checagens de erro (screens), feitas com base em regras prestabelecidas. Ao encontrar um erro de qualidade de dados, o erro gravado na tabela de eventos de erro, e feito seu diagnstico. Conforme as regras pr-estabelecidas, o erro pode ser diagnosticado como grave, mdio ou leve. Ao passar para o prximo estgio de checagem de erros, o sistema ETL verifica se no h erros graves. Caso eles existam, o processo ETL abortado e necessria interveno do administrador do sistema para sanar o problema. A figura 1.4 ilustra o processo de checagem de erros.
27
Figura 1.4 Processo de checagem de erros (KIMBALL e CASERTA, 2004). Finalmente, tem-se o relatrio de auditoria. Este relatrio gerado a partir dos eventos de erro obtidos no processo anterior, onde se verificou a qualidade dos dados. Deve-se observar que os eventos de erro gerados so erros de registro, individuais, e no podem ser apresentados no relatrio de auditoria, sem que antes haja uma anlise destes, para a sim gerar um relatrio que descreva todo o contexto, sempre baseado no conceito de qualidade dos dados. Este relatrio, que gerado ao final do processo de transformao dos dados, deve conter as aes de reparo e/ou mudanas que foram efetuadas nos registros para que estes pudessem ser aproveitados.
28
1.3
Load a carga dos dados
A carga dos dados a etapa final de um processo de ETL. nesta etapa que os dados sero carregados para sua tabela de destino, e ali estaro disponveis para o uso. Como existem inmeras estruturas de dados e tcnicas de modelagem de dados existentes, esta etapa do processo deve ser muito bem conduzida, para que o sistema ETL tenha as seguintes caractersticas: replicabilidade, usabilidade, escalabilidade e manutenibilidade (KIMBALL e CASERTA, 2004). Nesta etapa do processo ETL, os dados geralmente so carregados em dois tipos de estrutura de dados: as tabelas dimensionais e as tabelas factuais. As tabelas dimensionais contm a descrio das diversas entidades utilizadas para gerar a tabela factual, ou seja, a tabela dos dados. Assim, possvel saber de qual fonte de dados um determinado registro proveniente, pois cada registro na tabela factual faz referncia a um registro na tabela dimensional (KIMBALL e CASERTA, 2004). Neste trabalho far-se- uso dos conceitos de ETL extrao, transformao e carga para a implementao de um componente Delphi que facilite o processo de gerao do arquivo SIntegra. Desta forma, pretende-se automatizar ao mximo o processo de gerao deste arquivo, que exige um amplo conhecimento da legislao brasileira.
2
O ARQUIVO SINTEGRA
SIntegra o acrnimo de Sistema Integrado de Informaes sobre Operaes Interestaduais com Mercadorias e Servios. O principal objetivo desse sistema por parte dos contribuintes o de simplificar o fornecimento de informaes relativas s operaes de compra, venda e prestao de servios. Do lado dos fiscos estaduais, o objetivo o de propiciar maior agilidade e confiabilidade ao tratamento das informaes recebidas dos contribuintes e troca de dados entre as diversas unidades de federao (SINTEGRA2, 2006). O SIntegra foi concebido com a inteno de dar consistncia a diversas iniciativas de modernizao dos sistemas tributrios estaduais que constituem o PNAFE Programa Nacional de Apoio Administrao Fiscal para os Estados Brasileiros. Este programa visa contribuir para o equilbrio financeiro das unidades federadas atravs de medidas de aperfeioamento de suas mquinas arrecadadoras e de seus mecanismos de controle das despesas. Dadas as necessidades locais diferenciadas, os projetos variam de uma UF (Unidade de Federao) para outra. Contudo, o fato de que todas as Ufs dependem fortemente da arrecadao do ICMS, que tem caractersticas semelhantes de uma UF para outra, e de que uma parcela significativa do mesmo provem de operaes de compra e venda interestaduais que caem num terreno de jurisdio conjunta caracterizou a necessidade de promover iniciativas conjuntas no que diz respeito ao controle exercido sobre as operaes interestaduais de compra e venda, nascendo assim no ano de 1997, o SIntegra (SINTEGRA2, 2006). O arquivo SIntegra um arquivo EDI. A seguir, descrever-se- mais detalhadamente o que um arquivo EDI.
30
2.1
Conceito de EDI
A sigla EDI abrevia Electronic Data Interchange ou, em portugus, Intercmbio Eletrnico de Dados, no uma norma, mas sim uma filosofia de relacionamento entre organizaes, aproveitando as facilidades de comunicao e da informtica. A ONU Organizao das Naes Unidas - define EDI como um "processo de transferncia eletrnica entre organizaes parceiras de negcios, computador-a-computador, de transaes comerciais ou administrativas, usando um formato padro pr-estabelecido" (ONU, 2006). Toda essa transferncia de informaes poder ser feita automaticamente atravs dos computadores das organizaes, independente da plataforma de Hardware e Software utilizada. Mais formalmente, pode-se descrever o EDI como a troca de dados estruturados, baseados em formatos de mensagens normalizadas entre sistemas computacionais por meios eletrnicos. Dados estruturados significam um mtodo no ambguo de representar dados existentes num documento, seja ele uma fatura, uma encomenda ou qualquer outro tipo de documento. O mtodo para assegurar a correta interpretao da informao recebida pelo sistema computacional definido pela padronizao. Quanto ao conceito, importante ressaltar que a transferncia eletrnica de dados sem a interveno humana (COL et al, 1996). O EDI difere de outros sistemas de informao, pois integra sistemas de informaes de organizaes parceiras comerciais, envolvendo transaes de negcios em formatos padronizados e utilizando servios de comunicao de dados. O EDI uma deciso de negcios e uma nova forma de fazer negcios. Para que seja executado um processo de EDI entre dois parceiros, necessrio que sejam executadas as seguintes tarefas exibidas no fluxo abaixo:
Figura 2.1 Fluxo dos dados EDI.
31
1. criao da transao pela aplicao de origem; 2. traduo da transao para o formato padronizado, de forma a que possa ser reconhecido pelo outro parceiro. 3. transmisso, atravs das facilidades de comunicaes, para a aplicao destinatria do documento. Visando diminuir os custos de transmisso envolvidos, alguns softwares de traduo realizam a compactao e a posterior descompactao dos dados. Alm disso, alguns softwares possuem funes adicionais como gerao de senhas, criptografia dos dados, compactao, comprovao de recebimento, gerao de log, etc. 4. traduo da transao recebida no formato padronizado para o formato da aplicao de destino; 5. processamento da transao pela aplicao destinatria. Atualmente alguns sistemas referidos como usando a tecnologia EDI no implementam todos os tpicos acima mencionados e, dessa forma no podem ser considerados verdadeiramente como EDI. O EDI uma ferramenta que permite s organizaes estabelecer as comunicaes com os seus parceiros comerciais de uma forma mais efetiva, mas tambm totalmente diferente dos mtodos normais. EDI a troca de dados de forma padronizada entre aplicaes de sistemas de informtica de organizaes com negcios em comum com uma interveno mnima manual. EDI uma evoluo natural que combina a potncia computacional com servios de telecomunicaes, tudo isso processado de maneira padronizada, uma vez que os sistemas e organizaes envolvidos so de portes variados e com equipamentos diferentes. Muitas organizaes optaram pelo EDI como um mtodo rpido, econmico e seguro para o envio de ordens de compra, faturas, notificaes de transporte e outros documentos utilizados freqentemente em transaes comerciais. O EDI diferencia-se do simples envio de mensagens eletrnicas ou compartilhamento de arquivos por rede ou modem. A transferncia dos arquivos requer que as aplicaes, tanto do lado do emissor como do receptor do documento, sejam compatveis com o formato do documento enviado. O emissor deve utilizar uma determinada aplicao para criar um formato de arquivo idntico sua aplicao comercial. Mas no h a necessidade do emissor e
32
do receptor possuir sistemas idnticos de processamento de documentos. necessrio reforar o conceito de que o EDI uma ferramenta que, alm do componente tecnolgico de mudana, considerado um processo organizacional e uma forma inevitvel de, no presente e futuro, estabelecerem as relaes entre os parceiros comerciais, definindo-se como a transferncia eletrnica de informaes estruturadas entre os sistemas de computadores de diferentes organizaes de acordo com normas pr-estabelecidas. O limite do EDI est na criatividade de cada instituio, na viso de como usar os recursos da teleinformtica com qualidade e eficincia em benefcio do atendimento ao cliente.
2.2
Benefcios do EDI
Quando necessria a troca de informaes entre parceiros comercias, essa troca comumentemente feita atravs de relatrios, e-mails etc., principalmente quando estes parceiros no possuem um sistema de controle integrado. Todas essas informaes so redigitadas e posteriormente processadas por uma outra aplicao no parceiro comercial, sendo este um processo lento, caro e no merecedor de confiana. Atravs da aplicao de padres de mensagens EDI, as organizaes podem at mesmo se comunicar com sistema de computadores diferentes e incompatveis, gerando, assim, rapidez, eficincia e preciso. Com uma implantao bem sucedida do EDI nas organizaes, proporcionam-se grandes benefcios, distribudos em dois grandes focos, apresentados a seguir: Foco Estratgico: 1. agilidade: A comunicao de grandes volumes de dados comerciais entre os computadores reduz notavelmente os tempos previstos. Considerando que a varivel tempo um aspecto fundamental no funcionamento e na evoluo dentro de uma organizao, o mesmo dever ser aproveitado ao mximo, evitando que a organizao tenha dispndios desnecessrios e maior retorno do seu investimento, garantindo assim, maior satisfao por parte dos usurios do sistema; 2. aumento de produtividade: Nas organizaes dirigidas pelo EDI que so
33
caracterizadas por um rgido e eficiente controle de estoque das suas entradas e sadas, ir existir um maior controle das necessidades de produo, de compras e de entregas, resultando em significativas redues nos nveis de estoque, mantendo sua rotatividade no nvel ideal. Tudo isso, considerado num conjunto e em aplicao paralela com o uso do EDI, demonstra a eficincia e ganho de produtividade da organizao, evitando, dessa forma, gastos com pessoal desnecessrios no controle de seus estoques. O EDI, portanto, um componente chave nos elos de ligao entre cliente, fornecedor e transportador na fabricao just-in-time. Reduo dos tempos de resposta na cadeia de distribuio; 3. melhor servio a clientes e relacionamento com fornecedores: decorrente da execuo mais rpida e correta dos seus pedidos, colocando, assim, a organizao em uma posio de maior competitividade. Atravs de entregas a tempo, notificao prvia de envio, reduo ao mnimo dos tempos de transporte e alfndega, bem como nos pagamentos de bens ou servios. Foco Operacional: 1. eliminao de erros: Conforme a enorme quantidade de informaes necessrias ao funcionamento da organizao, no h garantia de que todas elas sero realmente informadas, ou sequer, corretamente processadas nos sistemas prprios da organizao. Caso esses erros venham a acontecer, geram-se problemas de ordem econmica e financeira que iro prejudicar a organizao ou at mesmo causar danos irreversveis. Portanto, com a utilizao do EDI, o mesmo elimina os inevitveis erros resultantes da entrada manual dos dados, tendo, assim, a qualidade no processamento devido preciso dos mesmos; 2. reduo de custos: Devido eliminao da re-digitao e da existncia de documentos eletrnicos, ocorre uma considervel reduo de custos operacionais, tais como, funcionrios, fax, correios, papis impressos. Isto uma redundncia administrativa e uma grande perda de tempo que resulta em gastos adicionais. Para as organizaes que j operam com o sistema de EDI, cabe s mesmas reordenarem e readaptarem os seus mtodos de trabalhos e tticas administrativas atravs de
34
anlises e estudos peridicos dentro da organizao para, ento, localizarem as suas falhas e servios desnecessrios ou improdutivos ou ainda repetitivos, atingindo, assim, o mximo dos benefcios propostos pela transferncia eletrnica de dados. Para aquelas organizaes que pretendem se estabelecer e pretendem utilizar o sistema de transferncia eletrnica de dados, podem e devem considerar o EDI no seu sistema de planejamento de constituio e no manuseio de gerenciamento de informaes, reduzindo a quantidade de investimentos em alguns setores que sero completamente absorvidos pela utilizao do EDI. Com base nos aspectos mencionados, elaborou-se uma pesquisa, realizada em 1993 na Inglaterra sobre as principais razes que levaram as organizaes a implementar o EDI e os seus benefcios diretos. Seguem abaixo os grficos, contendo os resultados encontrados:
Figura 2.2 (EANBRASIL, 2006).
35
Figura 2.3 (EANBRASIL, 2006). Os dados apresentados refletem, sem margem para dvidas, o enorme sucesso que o EDI pode introduzir nas organizaes que o pretendem implementar. necessrio salientar que, nesta pesquisa, as organizaes estavam apenas 10% conectadas via EDI com suas parceiras comerciais. Em tese, o uso do EDI extremamente promissor e atrativo, mas podem surgir alguns problemas para se atingir os resultados esperados. A idia geral de EDI baseia-se em ganho de velocidade nas transaes comercias, no entanto os documentos EDI so transmitidos em arquivos de lote e ficam armazenados nas caixas postais dos destinatrios, at que eles as retirem. Nesse momento h uma perda de tempo acentuada. Existe uma dificuldade de se realizar um estudo de custo x benefcio, pois os benefcios so dificilmente mensurveis, sendo mais um entrave para expanso do EDI. Em muitas organizaes, esse benefcio pode ser dimensionado, baseado exclusivamente na economia devido aos freqentes erros de digitao existente no modo convencional. No entanto, mesmo sendo difcil dimensionarem-se os benefcios, a no adoo de EDI, hoje, poder implicar na futura perda de clientes.
2.3
Padronizao
Para ocorrer a comunicao de dados estruturados, necessria que se adote a normalizao dos mesmos, criando-se, deste modo, uma interface entre os parceiros
36
interessados na comunicao que, no caso do EDI, so computadores pertencentes mesma organizao ou a diferentes organizaes que tm relaes comerciais. EDI no uma comunicao do tipo correio eletrnico com mensagem de formato livre, ou seja, a mensagem tem uma formatao rgida o que resulta na necessidade de padronizao a fim do emissor e receptor da mensagem se entenderem. Os padres para EDI, tal como uma linguagem, consistem numa gramtica (sintaxe, regras de estruturao de elementos de dados em segmentos e de segmentos numa mensagem) e um vocabulrio de palavras (lista de elementos de dados, lista de segmentos e lista de mensagens) (MHS, 1997). A comunicao sofreria uma ruptura caso os parceiros do intercmbio no seguissem normas previamente estabelecidas, passando-se de uma intolervel montanha de papel para um lixo eletrnico, especialmente no EDI internacional. Organizaes distintas tm necessidades, processos, formas, sistemas de
computadores, softwares e sofisticaes tcnicas diferentes. Para que estas informaes geradas e transmitidas de uma organizao para outra possam ser interpretadas automaticamente, essencial para o EDI a linguagem de comunicao. Ao implementar o EDI, muitas organizaes so tentadas a definir sua prpria linguagem EDI, impondo-a aos seus parceiros, esquecendo, assim, a necessidade de levar em conta questes como sua integrao com os processos internos da organizao e a maneira de trocar os dados de acordo com as necessidades dos parceiros. Para que os documentos eletrnicos e os dados fluam harmoniosamente entre as organizaes e sejam corretamente interpretados, preciso que sejam respeitadas certas regras, as quais definem o contedo de informao, isto , os dados dos documentos e a forma como eles so transmitidos. No caso do arquivo SIntegra, o padro EDI para o mesmo definido atravs de convnios distintos. Um convnio nada mais do que a especificao dos tipos de registros que o arquivo SIntegra pode conter, bem como sua formatao e regras especficas para a gerao do arquivo. O primeiro conjunto de regras (convnio) para o arquivo SIntegra foi o Convnio ICMS 57/95, de 30 de Junho de 1995. Desde l, j sofreu vrias alteraes. Atualmente, os contribuintes devem obedecer ao contedo do Convnio ICMS 76/03. Assim, este trabalho basear-se- neste convnio, e no seu respectivo manual de orientao para a gerao do arquivo SIntegra.
37
2.4
Convnio ICMS 76/03
O Convnio ICMS 76/03 foi publicado no Dirio Oficial da Unio em 16 de outubro de 2003, e descreve como os contribuintes devem entregar eletronicamente seus dados Secretaria Estadual da Fazenda, atravs do arquivo SIntegra. Este arquivo formado por vrios tipos de registro, que sero ligeiramente descritos a seguir. Este trabalho no descrever minuciosamente os tipos de registro constantes no arquivo SIntegra, por no ser este o foco do presente trabalho. Conforme o Manual de Orientao do Convnio ICMS 76/03 (2003), seguem os registros do arquivo SIntegra.
2.4.1 Registro 10
Este registro contm as informaes da empresa que est fornecendo o arquivo, ou seja, os dados de identificao razo social, CNPJ, cidade etc. do contribuinte. Este o primeiro registro do arquivo, e ele nico, ou seja, s pode haver um registro deste tipo no arquivo.
2.4.2 Registro 11
No registro 11 constam as informaes complementares, relativas ao Registro 10 endereo, bairro, telefone etc. Assim como o registro 10, s pode haver um registro tipo 11 no arquivo.
2.4.3 Registro 50
Este registro deve apresentar o total da Nota Fiscal emitidas nos modelos 1 e 1-A; Nota Fiscal de Produtor, modelo 4 (a critrio de cada unidade da Federao); Nota Fiscal/Conta de Energia Eltrica, modelo 6; Nota Fiscal de Servio de Comunicao, modelo 21; e Nota Fiscal de Servio de Telecomunicaes, modelo 22. Para fins de esclarecimento, os modelos fiscais citados anteriormente dizem respeito ao tipo de atividade que o contribuinte exerce. Segue abaixo uma tabela contendo todos os
38
possveis modelos de documento fiscal: Tabela 2.1 Modelos de Documentos Fiscais. (ICMS76/03, 2003). CDIGO 24 14 15 16 13 10 11 09 08 17 25 26 01 06 03 21 04 22 07 02 20 18 MODELO Autorizao de Carregamento e Transporte, modelo 24 Bilhete de Passagem Aquavirio, modelo 14 Bilhete de Passagem e Nota de Bagagem, modelo 15 Bilhete de Passagem Ferrovirio, modelo 16 Bilhete de Passagem Rodovirio, modelo 13 Conhecimento Areo, modelo 10 Conhecimento de Transporte Ferrovirio de Cargas, modelo 11 Conhecimento de Transporte Aquavirio de Cargas, modelo 9 Conhecimento de Transporte Rodovirio de Cargas, modelo 8 Despacho de Transporte, modelo 17 Manifesto de Carga, modelo 25 Conhecimento de Transporte Multimodal de Cargas, modelo 26 Nota Fiscal, modelo 1 Nota Fiscal/Conta de Energia Eltrica, modelo 6 Nota Fiscal de Entrada, modelo 3 Nota Fiscal de Servio de Comunicao, modelo 21 Nota Fiscal de Produtor, modelo 4 Nota Fiscal de Servio de Telecomunicaes, modelo 22 Nota Fiscal de Servio de Transporte, modelo 7 Nota Fiscal de Venda a Consumidor, modelo 02 Ordem de Coleta de Carga, modelo 20 Resumo Movimento Dirio, modelo 18
Assim, este registro deve especificar as informaes de totalizao do documento fiscal, relativamente ao ICMS Imposto sobre Circulao de Mercadorias e Servios. No caso de documentos com mais de uma alquota de ICMS e/ou mais de um Cdigo Fiscal de Operao CFOP, deve ser gerado para cada combinao de alquota e CFOP um registro tipo 50, com os valores correspondentes ao total da combinao alquota X CFOP, de tal forma que as somas dos valores dos registros que representam uma mesma nota fiscal, correspondero aos valores totais da mesma.
2.4.4 Registro 51
39
O registro 51 destina-se a registrar os totais de Notas Fiscais modelos 1 e 1-A relativas ao IPI Imposto sobre Produtos Industrializados. Como j foi dito, nem todas as organizaes vo gerar o arquivo SIntegra com todos os tipos de registro possveis. Por exemplo, o registro 51 s gerado por organizaes que importam ou produzem produtos industrializados.
2.4.5 Registro 53
O registro 53 contm informaes de total de documento fiscal, quanto substituio tributria. Entenda-se por substituio tributria quando a Lei Estadual atribui a contribuinte do imposto ou a depositrio a qualquer ttulo a responsabilidade pelo seu pagamento (PORTAL, 2006).
2.4.6 Registro 54
Neste registro temos os itens (produtos) da nota fiscal. Para cada registro 54 deve haver um registro 50 correspondente, tal qual em um sistema de controle de vendas, onde obrigatoriamente deve haver um registro na tabela de Notas Fiscais para um ou mais registros na tabela de Itens de Notas Fiscais.
2.4.7 Registro 55
Registro de Guia Nacional de Recolhimento, que diz respeito ao imposto devido por substituio tributria. Neste caso, todas as organizaes que gerarem em seu arquivo SIntegra o registro 54, tero de gerar no mnimo um registro 55.
2.4.8 Registro 56
Registro complementar relativo s operaes com veculos automotores novos realizadas por montadoras, concessionrias e importadoras.
40
2.4.9 Registro 60
Este registro destinado a informar as operaes e prestaes realizadas com os documentos fiscais emitidos por equipamento emissor de cupom fiscal, os quais so: Cupom Fiscal, Cupom Fiscal PDV, Bilhete de Passagem Rodovirio, modelo 13; Bilhete de Passagem Aquavirio, modelo 14; Bilhete de Passagem e Nota de Bagagem, modelo 15; Bilhete de Passagem Ferrovirio, modelo 16; e Nota Fiscal de Venda a Consumidor, modelo 2.
2.4.10 Registro 61
Registro dos documentos fiscais descritos a seguir, quando no emitidos por equipamento emissor de cupom fiscal: Bilhete de Passagem Rodovirio, modelo 13; Bilhete de Passagem Aquavirio, modelo 14; Bilhete de Passagem e Nota de Bagagem, modelo 15; Bilhete de Passagem Ferrovirio, modelo 16; Nota Fiscal de Venda a Consumidor, modelo 2; e Nota Fiscal de Produtor, modelo 4 (a critrio de cada unidade da Federao);
2.4.11 Registro 70
Registro de total de Nota Fiscal de Servio de Transporte, modelo 7; de Conhecimento de Transporte Rodovirio de Cargas, modelo 8; de Conhecimento de Transporte Aquavirio de Cargas, modelo 9; de Conhecimento Areo, modelo 10; e de Conhecimento de Transporte Ferrovirio de Cargas, modelo 11, destinado a especificar as informaes de totalizao do documento fiscal, relativamente ao ICMS.
2.4.12 Registro 71
Registro de Informaes da carga transportada referente a Conhecimento de Transporte Rodovirio de Cargas, modelo 8; Conhecimento de Transporte Aquavirio de Cargas, modelo 9; Conhecimento Areo, modelo 10; e Conhecimento de Transporte Ferrovirio de Cargas, modelo 11.
41
2.4.13 Registro 74
Registro de Inventrio (a critrio de cada Unidade Federada). O registro de inventrio trata da movimentao de estoque de cada produto constante no registro 54.
2.4.14 Registro 75
O registro de Cdigo de Produto e Servio apresenta os registros de produtos e servios constantes no arquivo SIntegra.
2.4.15 Registro 76
O registro 76 traz as informaes de Nota Fiscal de Servios de Comunicao, modelo 21, e Nota Fiscal de Servios de Telecomunicaes, modelo 22. Este registro gerado por organizaes prestadoras de servios de comunicao e telecomunicao operadoras de telefonia, etc.
2.4.16 Registro 77
Registro de servios de comunicao e telecomunicao. Este registro diz respeito ao registro 76, neste registro que sero especificados os servios prestados pelas organizaes deste ramo.
2.4.17 Registro 90
Registro de totalizao do arquivo, destinado a fornecer dados indicando a quantidade de registros. o registro finalizador do arquivo, tambm chamado de trailler. Assim como o registro 10, s pode haver um registro tipo 90. So estes os possveis tipos de registro em um arquivo SIntegra. Os registros gerados
42
vo depender da realidade em que a organizao se enquadra e do(s) tipo(s) de documento(s) fiscal(is) que ela emite, ou seja, uma organizao dificilmente vai gerar um arquivo SIntegra com todos os tipos de registro. Isto o que torna a implementao desta rotina difcil, pois os desenvolvedores devem prever todas as possibilidades possveis. A problemtica justamente esta: como prever todas as possibilidades sem o devido conhecimento da legislao? por isto que as solues disponveis no mercado apenas formatam e validam o formato e contedo dos registros, e no automatizam o processo da gerao do arquivo como um todo. Deste modo, para que seja possvel propor uma nova soluo para a rotina de gerao do arquivo SIntegra, a seguir sero avaliadas duas solues j existentes no mercado: a biblioteca Sintegra32Dll e o componente SIntegra Projeto Sultan.
3
SISTEMAS DISPONVEIS NO MERCADO
Para este trabalho optou-se por avaliar uma soluo proprietria a biblioteca Sintegra32Dll, desenvolvida pela TKS Software e uma soluo open source o componente SIntegra, desenvolvido pelo Projeto Sultan. Ambas as solues foram submetidas a um formulrio de avaliao, onde foram avaliadas questes gerais como portabilidade, desempenho, e outras questes pertinentes gerao do arquivo SIntegra, como automatizao do processo de gerao do arquivo at que ponto a soluo avaliada automatiza o processo de gerao do arquivo, ou o programador deve chamar sempre um rotina diferente para gerar os tipos de registro, etc. O formulrio de avaliao das duas solues encontra-se no Anexo A.
3.1
Mtodo de Avaliao
Para proceder a avaliao das solues para a gerao do arquivo SIntegra anteriormente citadas foi elaborado um formulrio baseado na NBRISO/IEC9126-1, que a norma brasileira para avaliao de produto de software, homologada pela ABNT Associao Brasileira de Normas Tcnicas (ABNTNET, 2006). Esta norma define seis caractersticas de qualidade de produto de software. So elas: Funcionalidade: conjunto de atributos que evidenciam a existncia de um conjunto de funes e suas propriedades especficas. Fazem parte deste quesito de qualidade outras sub-caractersticas, como adequao, acurcia, interoperabilidade, conformidade e segurana de acesso;
44
Confiabilidade: conjunto de atributos que evidenciam a capacidade do software de manter seu nvel de desempenho sob condies estabelecidas, durante um perodo de tempo estabelecido. So sub-caractersticas de confiabilidade: maturidade, tolerncia a falhas e recuperabilidade;
Usabilidade: conjunto de atributos que evidenciam o esforo necessrio para poder-se utilizar o software, bem como o julgamento individual deste uso, por um conjunto implcito ou explcito de usurios. Atrelada a esta caracterstica esto as sub-caractersticas de inteligibilidade, apreensibilidade e operacionalidade;
Eficincia: conjunto de atributos que evidenciam o relacionamento entre o nvel de desempenho do software e a quantidade de recursos usados, sob condies estabelecidas. So sub-caractersticas de eficincia: comportamento em relao ao tempo e comportamento em relao aos recursos;
Portabilidade: conjunto de atributos que evidenciam a capacidade do software em ser transferido de um ambiente para outro. Adaptabilidade, capacidade de ser instalado, conformidade, modificabilidade e analisabilidade so subcaractersticas de portabilidade;
Manutenibilidade: conjunto de atributos que evidenciam o esforo necessrio para fazer modificaes especificadas no software. Como sub-caractersticas de manutenibilidade, podem ser citadas a estabilidade e a testabilidade.
Assim, com base nestas seis caractersticas de qualidade de software, o formulrio foi elaborado com o seguinte contedo: Tabela 3.1 Formulrio de Avaliao de Software. N A soluo avaliada gera todos os possveis tipos de registro do arquivo SIntegra? A soluo avaliada faz algum tipo de crtica nos dados de entrada? O arquivo gerado pela soluo avaliada confivel? A soluo avaliada possui uma interface amigvel para com o desenvolvedor? O desempenho da soluo avaliada foi considerado: A soluo avaliada pode ser utilizada em mais de um ambiente de programao? Em caso de necessidade de manuteno do cdigo, P T
45
a necessidade de reescrita de cdigo foi: Em caso de erro, a soluo avaliada possui algum tipo de registro de erros? A soluo avaliada exige do desenvolvedor o conhecimento aprofundado da linguagem de programao? necessria a instalao da soluo avaliada no ambiente de programao? A soluo avaliada estvel, podendo ser utilizada em sistemas comerciais?
Os valores de avaliao do formulrio N, P e T foram escolhidos propositadamente, pois como as perguntas do formulrio so de tipos diferentes, este tipo de valor o que melhor expressa quantitativamente as respostas: N representa que o quesito no foi atendido; P, atendeu parcialmente o quesito; e T, atendeu plenamente o quesito. Alm do formulrio de avaliao, as solues existentes a biblioteca Sintegra32Dll e o componente Sintegra do Projeto Sultan foram testadas em um ambiente de programao. Ambas as solues tm em seu pacote de distribuio uma aplicao de demonstrao, que mostra como os desenvolvedores devem utilizar as mesmas. Assim sendo, estes aplicativos de demonstrao sero usados como parte da avaliao das solues. A seguir, sero apontados os mais importantes pontos, sejam eles positivos ou negativos, averiguados quando da avaliao das solues anteriormente citadas.
3.2
Biblioteca Sintegra32Dll
A biblioteca Sintegra32Dll, desenvolvida pela TKS Software, uma das solues disponveis no mercado mais utilizadas para a gerao do arquivo SIntegra. A Sintegra32dll foi implementada sob a forma de uma DLL Dynamic Link Library, ou Biblioteca de Vnculo Dinmico. Antes de prosseguir com a avaliao da mesma, explanar-se- sobre o que uma DLL, suas caractersticas, bem como as vantagens e desvantagens de seu uso.
3.2.1 DLLs
Uma DLL um arquivo executvel que atua como uma biblioteca de funes
46
compartilhvel. Atravs do vnculo dinmico possvel a chamada a uma funo que no faz parte do cdigo do programa executvel. O cdigo da funo est localizado na DLL, que pode conter uma ou mais funes compiladas e alocadas separadamente dos processos que fazem uso destas. Alm disso, o uso de DLL's facilita o compartilhamento de dados e recursos. Assim, mais de uma aplicao pode acessar simultaneamente o contedo de uma DLL em memria (MSDN, 2006). Existem duas maneiras de vincular uma DLL a um aplicativo. A primeira, chamada de vnculo dinmico, permite ao mdulo executvel incluir apenas a informao ou funo necessria em runtime. A segunda, chamada de vnculo esttico, retorna todas as funes referenciadas na DLL, disponibilizando as mesmas para o uso durante a execuo do aplicativo, mesmo que no sejam utilizadas todas as funes da DLL (MSDN, 2006). Conseqentemente, este tipo de vinculao entre o programa executvel e a DLL acarreta em alocao de memria desnecessria. O uso do vnculo dinmico ao invs do vnculo esttico oferece inmeras vantagens. So elas: Usa menos memria e reduz a troca de paginao: isto acontece porque vrios processos podem fazer uso de uma DLL simultaneamente, compartilhando a mesma. Em contrapartida, o vnculo esttico fora o sistema a carregar uma cpia da DLL em memria para cada aplicao que assim a utilizar; Reduz o espao em disco utilizado: ao compartilhar as funes de uma DLL, as aplicaes no necessitam ter uma cpia especfica da DLL para sua utilizao, basta uma cpia em disco, e esta ser utilizada por todos os aplicativos; Atualizaes facilitadas: quando as funes de uma DLL sofrem alteraes, os aplicativos que fazem uso desta no precisam ser necessariamente recompilados, desde que os argumentos e valores de retorno das funes no mudem. Desse modo, basta atualizar a DLL e o aplicativo estar atualizado. Voltando a Sintegra32dll, justamente por ser uma DLL ela pode ser usada por qualquer ferramenta de desenvolvimento que suporte esta tecnologia, por isso sua ampla utilizao. Alm de sua grande portabilidade, ela possui uma boa performance o fato de ser uma DLL poderia prejudic-la neste quesito, pois o programa que vai chamar os mtodos deve primeiramente carregar a biblioteca na memria do computador, antes de fazer uso de seus mtodos.
47
Pode-se facilmente notar que o ponto forte desta biblioteca a portabilidade como j foi dito, o fato de ser uma DLL faz com que seja possvel utilizar a Sintegra32Dll em qualquer ambiente de programao que tenha suporte a DLLs. Contudo, este fato faz com que seja necessrio passar todos os parmetros para a gerao de um registro do arquivo SIntegra. O mtodo vai receber todos estes parmetros, e como resultado vai retornar o registro (linha) do arquivo SIntegra formatado. Deste modo, o desenvolvedor que desejar utilizar a Sintegra32Dll dever criar uma rotina que chame estes mtodos, e posteriormente grave os registros gerados em um arquivo texto. Isto demanda uma grande quantidade de linhas de programao, o que um ponto negativo.
Figura 3.1 Aplicativo de Demonstrao da Sintegra32Dll.
3.3
Componente SIntegra - Projeto Sultan
O Componente Sintegra, desenvolvido pelo Projeto Sultan faz parte de um esforo da comunidade participante desse projeto, em desenvolver um componente open source para a
48
gerao do arquivo SIntegra. Como o componente open source, o seu desenvolvimento depende dos desenvolvedores que fazem parte do projeto, e colaboram para o progresso do projeto. O componente SIntegra do Projeto Sultan foi desenvolvido na linguagem Object Pascal, portanto, pode ser usado apenas no ambiente de programao Delphi. Isto lhe traz uma desvantagem em termos de portabilidade em comparao a DLL Sintegra32Dll. Em contrapartida, confere-lhe a possibilidade de usar todas as funes e mtodos disponveis na ferramenta de programao. Ao contrrio da Sintegra32Dll, o SIntegra Projeto Sultan tem uma rotina principal de gerao do arquivo, chamada GerarArquivo(). Contudo, a entrada dos dados anloga a DLL da TKS Software: todos os atributos devem ser atribudos pelo programador em tipos de dados (objetos). Cada tipo de registro registro tipo 10, 11, 50 etc. tem uma classe equivalente, que deve ser preenchida com os seus atributos. Aps a chamada do mtodo principal, o componente gera os tipos de registro de acordo com as informaes constantes nos objetos internos do componente. Assim como a Sintegra32Dll, esse tipo de implementao tambm demanda uma grande quantidade de linhas de programao. Outro ponto negativo do componente SIntegra Projeto Sultan que ainda no foram implementados todos os tipos de registro possveis no Convnio ICMS 76/03. Uma causa bem provvel o fato de o componente ser open source, e o seu desenvolvimento depender da boa vontade dos participantes do projeto.
49
Figura 3.2 Aplicativo de Demonstrao do Componente SIntegra Projeto Sultan.
3.4
Resultados
Baseado na avaliao dos aplicativos de demonstrao e no formulrio de avaliao da DLL Sintegra32Dll e do componente SIntegra Projeto Sultan, possvel chegar aos seguintes resultados: As duas solues avaliadas demandam muitas linhas de cdigo para implementar a rotina de gerao do arquivo SIntegra. Isto dificulta a manuteno do mesmo principalmente no caso de atualizaes; A biblioteca Sintegra32Dll exige do desenvolvedor um profundo conhecimento sobre os tipos de registro do arquivo SIntegra, pois seus mtodos geram diretamente os tipos de registro do arquivo SIntegra, e para tanto deve-se passar todos os atributos necessrios para a gerao do registro. Assim sendo, o
50
desenvolvedor deve necessariamente ter o conhecimento de quais atributos passar como parmetro para o mtodo; O componente Sintegra Projeto Sultan j trata os tipos de registro de uma forma mais familiar ao desenvolvedor: por exemplo, o registro 50 - que registra os totais de Notas Fiscais - o componente em questo instancia um objeto chamado NF, contendo todos os atributos necessrios para a gerao do seu devido registro no caso, o registro 50; Com base nos problemas apontados necessidade de muitas linhas de cdigo, necessidade de conhecimento da legislao do SIntegra possvel propor o modelo de um novo componente para a gerao do arquivo SIntegra, focado na facilidade de uso por parte dos desenvolvedores o componente a ser proposto deve ser de fcil implementao, exigindo assim um mnimo de linhas de programao e na transparncia de uso com o uso dos conceitos de ETL, a nica tarefa do desenvolvedor vai ser definir quais os atributos que sero extrados da fonte de dados, e o componente ento far uso destes para gerar o arquivo SIntegra.
4
PROPOSTA PARA UM NOVO COMPONENTE
Como j foi dito anteriormente, desenvolver a rotina de gerao do arquivo SIntegra requer um amplo conhecimento da legislao. Mesmo utilizando uma das solues avaliadas anteriormente, o desenvolvedor deve necessariamente conhecer a estrutura interna do arquivo SIntegra os tipos de registro que o compe pois tanto a biblioteca Sintegra32Dll quanto o componente do Projeto Sultan apenas geram as linhas do arquivo. Para isso, deve-se passar como parmetro todos os dados necessrios para a gerao de um registro do arquivo. Segue abaixo o trecho de cdigo para a gerao de um registro tipo 50, utilizando a biblioteca Sintegra32Dll:Registro50('34.261.131/0001-44', 'ISENTO', '01/01/2005', 'BA', '1A', '1', '1', '5111', 'P', '0', '0', '0', '', '0,00', '0', 'N' ); //CNPJ //Insc_Est //Data_Emissao_Recebimento //UF, //Modelo //Serie //Nro //CFOP //Emitente //Valor_Total //Base_ICMS //Valor_ICMS //Isenta //Outras //Aliquota //Situacao
Abaixo, outro trecho de cdigo para a gerao do mesmo registro tipo 50, utilizando componente do Projeto Sultan:with NF.New do begin { Dados da nota fiscal }
52
CNPJ InscEstadual Data UF Modelo Serie Numero Frete Seguro DespAcessoria
:= := := := := := := := := :=
Dados.Registro50CNPJCPF.Value; Dados.Registro50InscEstadual.Value; Dados.Registro50Data.Value; Dados.Registro50UF.Value; Dados.Registro50Modelo.Value; Dados.Registro50Serie.Value; Dados.Registro50Numero.Value; Dados.Registro50Frete.Value; Dados.Registro50Seguro.Value; Dados.Registro50DespAcessorias.Value;
case Dados.Registro50ModFrete.Value[1] of 'C': ModFrete := mdfCIF; 'F': ModFrete := mdfFOB; 'O': ModFrete := mdfOUTROS; end; case Dados.Registro50Emitente.Value[1] of 'P': TipoEmitente := tpeProprio; 'T': TipoEmitente := tpeTerceiros; end; case Dados.Registro50Situacao.Value[1] of 'N': Situacao := nfNormal; 'S': Situacao := nfCancelado; 'E': Situacao := nfExtNormal; 'X': Situacao := nfExtCancelado; end; end;
Como se pode notar atravs da anlise dos trechos de cdigo acima, ambas as solues passam como parmetro os atributos necessrios criao do tipo de registro. justamente isto que o novo componente visa: em momento algum o desenvolvedor estar implementando ou declarando alguma rotina que vai gerar um tipo de registro especfico; o desenvolvedor apenas chamar o mtodo principal, chamado Exportar. Isto ser possvel utilizando os conceitos de ETL. O componente aqui proposto reproduzir o comportamento de um sistema ETL, ou seja, vai extrair os dados necessrios a partir de uma fonte de dados, aps far a transformao destes, com base nas regras do Convnio ICMS 76/03, e finalmente far a carga dos valores transformados para o arquivo destino o arquivo SIntegra. Primeiramente, o desenvolvedor ter que definir uma consulta SQL que vai trazer como resultado os dados necessrios para a gerao do arquivo SIntegra, ou carregar um arquivo XML contendo os dados para o mesmo. O resultado da consulta SQL ou o arquivo XML atuaro como a fonte de dados do sistema ETL embutido no componente aqui proposto. Aps a definio da fonte de dados, o desenvolvedor ter que definir como os dados sero extrados desta. Isto corresponde ao processo de extrao. Este processo muito
53
importante, pois nesta etapa que sero definidos quais atributos sero extrados da fonte de dados para a gerao do arquivo SIntegra. Vale salientar que, diferentemente das solues anteriormente avaliadas, o desenvolvedor no ir atribuir diretamente os valores constantes na fonte de dados para a gerao do arquivo SIntegra, apenas ir definir quais atributos sero utilizados para a criao dos tipos de registro do arquivo. A rotina interna do componente ser a responsvel pela atribuio e utilizao destes valores. Os valores extrados da fonte de dados sero armazenados em estruturas internas, mais precisamente classes de objetos. Para cada registro extrado da fonte de dados instanciar-se- o objeto correspondente. Estes objetos por sua vez sero armazenados em listas de objetos, para posterior utilizao no processo de carga do arquivo SIntegra. Definidos os atributos a serem extrados da fonte de dados, o processo de gerao do arquivo SIntegra praticamente automatizado, pois o componente vai transformar aqui se inicia o processo de transformao dos dados os atributos originais definidos no processo de extrao, fazendo todas as rotinas internas necessrias (colocar os dados em conformidade com os tipos de registro do arquivo SIntegra), para finalmente gerar o arquivo SIntegra (a carga dos dados). A transformao dos dados acontece praticamente ao mesmo tempo que a carga dos dados no arquivo destino, pois os valores armazenados nos objetos internos esto no seu formato original, e precisam ser transformados, conforme as regras de formatao EDI constantes no Convnio ICMS 76/03. Para exemplificar melhor o funcionamento do componente, a seo 4.1 traz os diagramas UML do mesmo.
4.1
Modelagem do Componente
Na figura 4.1, o diagrama de Classes apresenta as principais classes do componente aqui proposto. A classe principal (TSWSintegra) tem apenas um mtodo pblico (Exportar), que ser o mtodo a ser chamado para a gerao do arquivo SIntegra. Como pode ser notado no diagrama de classes, o componente SIntegra proposto tem sua estrutura de classes sob a forma de uma rvore binria, com a classe TSWSintegra sendo a raiz da estrutura, ou classe-pai. Desta forma, ser possvel ao desenvolvedor acessar as
54
classes-filho do componente, para definio das entidades que sero responsveis pela extrao dos dados as propriedades constantes em TSWSintegra.ETL.Entidades. Alm disso, o mtodo Exportar, responsvel pela gerao do arquivo SIntegra ter de acessar as classes-filho durante a execuo deste mtodo, principalmente no que diz respeito ao acesso a classe TETL, que reproduz o comportamento de um sistema ETL em si. A classe TETL onde esto modelados os mtodos internos que faro a extrao dos valores da fonte de dados. Para cada tipo de registro existe um mtodo privado correspondente, que vai percorrer os registros da fonte de dados, instanciar um objeto interno que vai receber os valores extrados. Este objeto ser armazenado em sua lista de objetos correspondente. Estas listas sero utilizadas para a gerao do arquivo SIntegra.
55
Figura 4.1 Diagrama de Classes.
A figura 4.2 apresenta o diagrama de atividades, que mostra as atividades desenvolvidas para a gerao do componente.
56
Figura 4.2 Diagrama de Atividades.
No diagrama de atividades tem-se uma viso mais clara do que o componente aqui modelado vai implementar. Vale salientar que as nicas atividades que cabem ao desenvolvedor so aquelas relativas definio da fonte de dados, bem como a definio dos atributos a serem extrados desta. Assim como num sistema ETL onde os processos de extrao, transformao e carga dos dados so automatizados, o componente aqui modelado tambm pretende que estes processos tambm sero automatizados. Com isso, ter-se- um ganho em relao s solues j existentes no mercado, pois o desenvolvedor estar isento de implementar tanto a extrao dos dados, a transformao destes, bem como implementar a carga dos dados, ou seja, a criao e gravao dos tipos de registro no arquivo SIntegra. A atividade de validao dos atributos, feita pelo mtodo Criticar, tem por funo identificar valores inconsistentes nos atributos extrados da fonte de dados. Ao contrrio de um sistema ETL, que capaz de tornar um dado inconsistente vlido desde que o sistema tenha sido configurado previamente para isso o processo de validao do componente aqui modelado apenas identifica os atributos inconsistentes. Caber ao usurio fazer o ajuste no atributo, de modo a torn-lo vlido. Na seo 4.2 descrever-se- a implementao do componente aqui modelado. Com a descrio da implementao, ser possvel visualizar e compreender melhor como os
57
conceitos de ETL foram utilizados neste trabalho. Assim, ser possvel mensurar o ganho que o uso dos conceitos desta tecnologia trar aos usurios do componente aqui proposto.
4.2
Implementao do Componente
Aps a modelagem, partiu-se para a implementao do componente. O componente foi implementado utilizando o ambiente de programao Borland Delphi 7, que d suporte aos conceitos da POO utilizados para a implementao deste. As grande maioria das classes do componente so herdadas de TPersistent, que uma classe Delphi nativa usada para a implementao de classes de objetos. Este tipo de classe prprio para esta implementao, pois trata-se da classe base para implementar objetos no Delphi, tendo apenas mtodos construtores e destrutores implementados. Alm disso, foram utilizadas outras classes de objetos Dephi para o acesso a base de dados e para a manipulao de Strings. A seguir, explanar-se- sobre a implementao do componente ora modelado.
4.2.1 TSWSintegra
A TSWSintegra a super-classe do componente, que engloba todas as demais classes do mesmo. Esta classe herdada de TComponent, que a classe base para a implementao de componentes em Delphi. Por ser a super-classe, nesta classe que foi implementado o mtodo pblico Exportar, que o responsvel pela gerao do arquivo SIntegra em si. Este mtodo formata os campos conforme o layout e os grava no arquivo destino. Para criar os tipos de registro do arquivo o componente acessa a estrutura interna do mesmo, onde foram alocados os atributos extrados da base de dados. Esta estrutura ser melhor explicada na seo 4.2.3. A classe TSWSintegra possui tambm o mtodo privado Criticar. Este mtodo chamado pelo mtodo Exportar, para fazer a validao dos atributos constantes na propriedade Parametros, que da classe TParametros. A classe TParametros, por sua vez,
58
contm os atributos que vo formar os registros 10 e 11 do arquivo SIntegra. Estes atributos dizem respeito a organizao que est gerando o arquivo razo social, endereo, municpio etc. e tambm informaes especficas do arquivo, como perodo ao qual o arquivo se refere, cdigo do convnio etc. Se o mtodo Criticar citado anteriormente encontrar alguma inconsistncia nos atributos da classe TParametros, o componente gera um registro de erro e aborta o processo de gerao do arquivo, iniciado pelo mtodo Exportar. Deste modo, evitarse- a gerao de arquivos com incosistncias. Existe ainda a propriedade ETL na classe TSWSintegra. Esta propriedade pertence a classe TETL, a qual ser comentada a seguir.
4.2.2 TETL
Esta classe implementa o mecanismo ETL do componente. Como foi explanado no captulo 1, sistemas ETL dividem-se em trs principais etapas: a extrao dos dados de uma ou mais fontes de dados, seguido da transformao destes, e finalmente a carga dos dados para a apresentao dos resultados. Analogamente, o componente aqui implementado segue essa estrutura de funcionamento. Para que haja o entendimento do funcionamento do mecanismo ETL do componente aqui implementado, explanar-se- primeiramente sobre as propriedades que este possue: as propriedades Entidades (TEntidades), Extracao (TExtracao) e Carga (TCarga).
4.2.3 TEntidades
A classe TEntidades implementa o mapa lgico dos dados do mecanismo ETL do componente. A partir da definio do mapa lgico, o componente ser capaz de extrair da fonte de dados no caso desta implementao, uma consulta SQL ou um arquivo XML o valor do atributo definido no mapa lgico de dados. A classe TEntidades possui seis propriedades. So elas: NotaFiscal (TNotaFiscal), NotaFiscalItem (TNotaFiscalItem), Produto (TProduto), CupomFiscal (TCupomFiscal), Conhecimento (TConhecimento) e ConhecimentoNF (TConhecimentoNF). Estas propriedades por sua vez, possuem atributos onde sero definidos os respectivos nomes dos atributos da fonte de dados a serem extrados. A definio deste mapa lgico de dados de suma importncia, pois dele vai depender a
59
correta extrao dos dados da fonte de dados e a subseqente gerao do arquivo SIntegra. A figura 4.3 ilustra a definio do mapa lgico de dados para a extrao das informaes referentes aos produtos.
Figura 4.3 Definio do mapa lgico para a Entidade Produto. Ao serem extradas da fonte de dados, as informaes so armazenadas em objetos internos, e estes por sua vez, so armazenados em listas de objetos. Para cada mapa lgico de dados foi implementado uma classe de objeto respectiva, que vai receber e armazenar os valores extrados da fonte de dados. Estas classes foram implementadas seguindo os padres de desenvolvimento (Design Patterns). Nesse padro de desenvolvimento existem classes de objetos responsveis pelo armazenamento dos valores dos objetos, denominandas Value Objects, ou VOs (SUN, 2006). Por exemplo, para armazenar os dados extrados referentes aos produtos, foi implementada uma classe TProdutoVO, conforme trecho de cdigo abaixo:TProdutoVO private ... published property property property = class(TObject)
DataInicial: TDateTime; DataFinal: TDateTime; Codigo: String;
60
property property property property property property property end;
CodigoNCM: String; Descricao: String; UnidadeMedida: String; AliquotaIPI: Real; AliquotaICMS: Real; BaseReduzida: Real; BaseSubst: Real;
Estas classes de objetos VO sero utilizadas no processo de extrao dos dados, conforme descrito na seo 4.2.5.
4.2.4 TExtracao
A classe TExtracao a responsvel pela definio da fonte de dados. Assim como em sistemas ETL, que permitem a extrao de diversas fontes de dados, o componente aqui implementado tem suporte a dois tipos de fontes de dados: possvel extrair os dados de um arquivo XML ou diretamente de uma base de dados, atravs de uma consulta SQL. Para tanto, esta classe possui duas propriedades: a primeira, chamada ArquivoXML, deve ser utilizada quando pretende-se gerar o arquivo SIntegra a partir da extrao dos dados constantes em um arquivo XML; a segunda, chamada BD (TBDConexao), deve ser utilizada quando o arquivo SIntegra ser gerado com os dados obtidos atravs de uma consulta SQL a uma base de dados. Vale lembrar que a utilizao de uma das opes mutuamente exclusiva, ou seja, no possvel gerar o arquivo SIntegra a partir de um arquivo XML e uma consulta SQL, apenas uma das fontes ser utilizada. Para utilizar um arquivo XML, basta definir o nome do mesmo. J para utilizar consultas SQL, preciso configurar a propriedade BD, conforme descrito a seguir.
4.2.4.1 TBDConexao
Esta classe foi implementada visando o uso de consultas SQL para a obteno dos dados que geraro o arquivo SIntegra. Para uma maior flexibilidade, esta classe permite ao usurio utilizar diferentes classes de componentes de conexo a bancos de dados. possvel utilizar os componentes BDE, IBX ou dbExpress para a conexo ao banco de dados. Para tanto, basta definir o tipo apropriado na propriedade Tipo. Para a conexo ao banco de dados
61
propriamente dita, temos a propriedade Query. O usurio deve associar uma instncia de um componente que realiza consultas SQL a essa propriedade, que o componente se encarregar de executar a consulta e retornar os respectivos resultados da mesma. Para a definio da consulta SQL, houve uma mudana na modelagem do componente. No modelo original, havia apenas uma propriedade para a definio da consulta SQL, chamada SQL. Visando uma maior flexibilidade, foram includas mais trs propriedades para a definio de consultas SQL. Assim, as propriedades foram denominadas conforme sua utilizao: SQLEntradas: consulta SQL para as notas fiscais de entrada; SQLSaidas: consulta SQL para as notas fiscais de sada; SQLConhecimentos: consulta SQL para os conhecimentos de frete; SQLCupomFiscal: consulta SQL para as informaes relativas a cupom fiscal.
Cabe ao usurio do componente definir se ser necessrio utilizar uma ou mais consultas SQL para gerar o arquivo SIntegra. A seguir, descrever-se- a ltima propriedade da classe TETL: a propriedade Carga (TCarga).
4.2.5 TCarga
Como o prprio nome sugere, a classe TCarga representa a ltima etapa de um sistema ETL: a carga dos dados transformados para apresentao dos resultados. Neste caso, a apresentao dos resultados d-se atravs da gerao do arquivo SIntegra. Assim, nesta classe deve ser definido o nome do arquivo que ser gerado. Essa definio feita na propriedade ArquivoEDI. Esta propriedade recebeu este nome porque o arquivo SIntegra nada mais do que um arquivo EDI. Alm desta propriedade, a propriedade LogErro presente nesta classe, responsvel por armazenar todos os erros de validao gerados ao se chamar o mtodo Exportar na super-classe TSWSintegra. Todo e qualquer erro de validao armazenado nesta propriedade, e impede a gerao do arquivo SIntegra. Voltando classe TETL, explanar-se- agora sobre a implementao de seus mtodos pblicos e privados. O mtodo Extrair(Parametros) chamado pelo mtodo Exportar da
62
super-classe TSWSintegra, e faz a funo de extrao do mecanismo ETL. Ele responsvel por verificar quais consultas SQL foram definidas, e subseqentemente execut-las. Com os resultados das consultas SQL armazenados em memria, o mtodo Extrair inicia a extrao dos dados propriamente dita. A extrao dos dados efetuada por mtodos privados chamados ListaReg50, ListaReg54, ListaReg60, ListaReg70, ListaReg71 e ListaReg75. Cada um destes mtodos vai extrair os dados conforme o mapa lgico definido pelo usurio do componente, e sero armazenados em instncias de objetos VO. Estes objetos VO sero por sua vez armazenados em listas de objetos, para posterior gerao do arquivo. Por exemplo, o mtodo ListaReg75 responsvel pela extrao das informaes relativas aos produtos. Para isso, o mtodo vai buscar o mapeamento lgico para a extrao das informaes na propriedade Entidades.Produto. A seguir, instancia-se um objeto da classe TProdutoVO que vai receber os valores dos atributos extrados da seguinte forma:ProdutoVO := TProdutoVO.Create; ProdutoVO.AliquotaICMS := Query.FieldByName(Entidades.Produto.AliquotaICMS).AsFloat; ProdutoVO.AliquotaIPI := Query.FieldByName(Entidades.Produto.AliquotaIPI).AsFloat; ProdutoVO.BaseReduzida := Query.FieldByName(Entidades.Produto.BaseReduzida).AsFloat; ProdutoVO.BaseSubst := Query.FieldByName(Entidades.Produto.BaseSubst).AsFloat; ProdutoVO.Codigo := Query.FieldByName(Entidades.Produto.Codigo).AsString; ProdutoVO.CodigoNCM := Query.FieldByName(Entidades.Produto.CodigoNCM).AsString; ProdutoVO.Descricao := Query.FieldByName(Entidades.Produto.Descricao).AsString; ProdutoVO.UnidadeMedida := Query.FieldByName(Entidades.Produto.UnidadeMedida).AsString;
Aps a extrao dos valores e armazenamento no objeto VO, chamado o mtodo privado Criticar(VO), onde feita a validao dos valores dos atributos do objeto VO. Caso exista alguma inconsistncia no objeto VO, gerado um registro na propriedade Carga.LogErro. Mas, ao contrrio do mtodo Criticar chamado pelo mtodo Exportar da
63
super-classe TSWSintegra, a presena de incosistncias no aborta o processo de extrao, justamente com o intuito de extrair todos os registros retornados na consulta SQL e valid-los. Deste modo, o usurio ter o registro de todas as inconsistncias presentes nos seus dados, podendo corrigi-las de uma nica vez. Aps o mtodo Criticar(VO), o objeto VO adicionado a uma lista de objetos. Este processo semelhante em todos os demais mtodos privados menciados acima (ListaReg50, ListaReg54 etc.). importante salientar que o processo de extrao dos dados implementado no mtodo Extrair o grande diferencial proposto neste componente, em relao s solues existentes no mercado. Este mtodo exime o desenvolvedor de implementar a atribuio dos valores retornados na consulta SQL aos objetos que