FERRAMENTA WEB PARA APOIAR O SETOR DE QUALIDADE NOS TESTES DOS RELATÓRIOS DA LEI DE RESPONSABILIDADE FISCAL

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO FERRAMENTA WEB PARA APOIAR O SETOR DE QUALIDADE NOS TESTES DOS RELATÓRIOS DA LEI DE RESPONSABILIDADE FISCAL DANIEL FELIPE LENZI BLUMENAU /1-03

2 DANIEL FELIPE LENZI FERRAMENTA WEB PARA APOIAR O SETOR DE QUALIDADE NOS TESTES DOS RELATÓRIOS DA LEI DE RESPONSABILIDADE FISCAL Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação Bacharelado. Prof. Marcel Hugo, Mestre - Orientador BLUMENAU /1-03

3 FERRAMENTA WEB PARA APOIAR O SETOR DE QUALIDADE NOS TESTES DOS RELATÓRIOS DA LEI DE RESPONSABILIDADE FISCAL Por DANIEL FELIPE LENZI Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Marcel Hugo, Mestre, FURB Prof. Everaldo Artur Grahl, Mestre FURB Prof. Wilson Pedro Carli, Mestre FURB Blumenau, 6 de julho de 2012.

4 Dedico este trabalho a minha família e minha noiva, que sempre me deram muita força.

5 AGRADECIMENTOS A Deus pela saúde. A meu pai e mãe, que sempre me incentivaram a estudar. À minha noiva por me encorajar e me dar forças a voltar a estudar. Ao meu orientador, Marcel Hugo, por ter acreditado e ajudado de forma única a produção desse trabalho. A todos os professores que colaboraram para o aprendizado e crescimento de minha carreira profissional.

6 Não sabendo que era impossível, foi lá e fez. Jean Cocteau

7 RESUMO Este trabalho apresenta o desenvolvimento de uma ferramenta para auxiliar os setores de qualidade e desenvolvimento da empresa Pública Informática nos testes das alterações dos relatórios da Lei de Responsabilidade Fiscal, assim garantindo a integridade entre valores comuns que devem ser iguais entre estes relatórios. Com a utilização do Java Server Page (JSP), torna-se possível a disponibilização da ferramenta na web para que os testes possam ser feitos diretamente nos clientes, aumentando a garantia da integridade entre os valores para que os relatórios possam ser publicados. Para o desenvolvimento da ferramenta utilizou-se o framework Hibernate, em conjunto com algumas outras interfaces de programação de aplicação (API) utilizadas para aplicações web, como o JQUERY e o JavaScript, e outros recursos como a utilização do Cascading Style Sheets (CSS). Palavras-chave: Relatórios fiscais. Lei de Responsabilidade Fiscal. Teste de valores. Ferramenta Web.

8 ABSTRACT This paper presents the development of a tool to assist the sectors of quality and development in the Pública Informática company tests of changes in reports of the Fiscal Responsibility Law, thereby ensuring the integrity of common values that must match between these reports. Using the Java Server Page (JSP), it becomes possible to release the tool on the web so that tests can be made directly to customers, increasing the assurance of the integrity of the values so that reports can be published. For the development tool used the Hibernate framework, together with some other Application Programming Interfaces (API) used for web applications, such as jquery and JavaScript, and other features such as the use of Cascading Style Sheets (CSS). Key-words: Fiscal report. Fiscal Responsibility Law. Values test. Web tools.

9 LISTA DE FIGURAS Figura 1: Exemplo de arquivo XML Figura 2: Exemplo de código usando anotações no Hibernate Figura 3: Banco de dados suportados pelo Hibernate Figura 4: Fluxo do processo atual Figura 5: Valor da receita corrente líquida no anexo III da RREO Figura 6: Valor da receita corrente líquida no anexo II da RGF Figura 7: Leiaute do arquivo de lançamentos contábeis diponibilizado pelo sistema e-sfinge24 Figura 9: Tela de importação do arquivo no sistema e-sfinge Figura 8: Exemplo de parte de um arquivo no leiaute padrão do sistema e-sfinge Figura 11: Relatório de inconsistências do Sistema e-sfinge Figura 10: Tela de verificação de inconsistências no sistema e-sfinge Figura 12: Leiaute do arquivo de lançamentos contábeis do sistema Audesp Figura 13: Exemplo de arquivo de lançamentos contábeis no sistema Audesp Figura 14: Importação do arquivo XML para envio ao sistema Audesp Figura 15: Tela de inconsistências pendentes do sistema Audesp Figura 16: Tela de visualização dos arquivos de inconsistência do Sistema Audesp Figura 17: Exemplo de um relatório de inconsistências do sistema Audesp Figura 18: Fluxo de processo proposto pela ferramenta Figura 19: Diagrama de casos de uso Figura 20: Diagrama de classes da ferramenta Figura 21: Modelo entidade-relacionamento da ferramenta Figura 22: Consulta da tabela LinhaRelatorio usando API Criteria Figura 23: Consulta de validação de valores usando SQL Figura 24: Código fonte da importação com JDOM Figura 25: Código fonte da leitura do arquivo XML Figura 26: Código fonte da leitura dos relatórios Figura 27: Tela de login da ferramenta Figura 29: Tela do cadastro e permissões de usuários na ferramenta Figura 28: Tela principal do usuário supervisor da ferramenta Figura 30: Tela principal do usuário os menus de suas permissões na ferramenta Figura 31: Tela de consulta das entidades cadastradas... 41

10 Figura 33: Tela de consulta de leiautes da ferramenta Figura 34: Tela de cadastro de leiaute da ferramenta Figura 32: Tela de cadastro de entidade Figura 35: Tela de consulta das linhas do relatório e leiaute da ferramenta Figura 36: Tela de cadastro de linhas do relatório e leiaute da ferramenta Figura 37: Tela de consulta de relatórios da ferramenta Figura 39: Tela de consulta de linhas cadastradas na ferramenta Figura 38: Tela de cadastro de relatórios da ferramenta Figura 41: Tela de importação do arquivo XML da ferramenta Figura 42: Tela da importação realizada com sucesso na ferramenta Figura 40: Tela de cadastro de linhas da ferramenta Figura 43: Tela da importação com leiaute inválido na ferramenta Figura 44: Tela do log de importações do usuário testador Figura 45: Tela do log de importações de todos usuários Figura 46: Tela dos relatórios importados Figura 48: Tela dos valores das linhas importadas pela ferramenta Figura 47: Tela das linhas importadas de cada relatório Figura 50: Tela de validação com o parâmetro Visualizar somente inconsistências marcado Figura 49: Tela de validação com o parâmetro Visualizar somente inconsistências desmarcado Figura 51: Mensagem de inconsistência de valor da ferramenta Figura 52: Mensagem de inconsistência de valor com complemento dos relatórios Figura 53: Mensagem de inconsistência de relatório não importado Figura 54: Mensagem de inconsistência de linha não importada Figura 55: Mensagem de inconsistência de linha importada Figura 56: Leiaute de importação da ferramenta Figura 57: Valor total da Receita corrente líquida no relatório anexo III da RREO Figura 58:Valor total da Receita corrente líquida no relatório anexo II da RGF Figura 59: Tela da inconsistência do valor entre os relatórios anexo III e II... 53

11 LISTA DE QUADROS Quadro 1: Requisitos funcionais Quadro 2: Requisitos não funcionais Quadro 3: Caso de uso efetuar login Quadro 4: Caso de uso alterar senha Quadro 5: Caso de uso cadastrar leiaute Quadro 6: Caso de uso Cadastrar relatório Quadro 7: Caso de uso Cadastrar linha Quadro 8: Caso de uso vincular linha para um leiaute relatório Quadro 9: Caso de uso importar XML Quadro 10: Caso de uso visualizar importações Quadro 11: Caso de uso visualizar inconsistências Quadro 12: Caso de uso Visualizar todas importações Quadro 13: Caso de uso Cadastrar usuários Quadro 14: Dicionário de dados da tabela entidade Quadro 15: Dicionário de dados da tabela usuário Quadro 16: Dicionário de dados da tabela leiaute Quadro 17: Dicionário de dados da tabela relatório Quadro 18: Dicionário de dados da tabela linha Quadro 19: Dicionário de dados da tabela de leiautes dos relatórios Quadro 20: Dicionário de dados da tabela de linhas relatório Quadro 21:Dicionário de dados da tabela importação Quadro 22: Dicionário de dados da tabela de relatórios importados Quadro 23: Dicionário de dados da tabela valor linha Quadro 24: Dicionário de dados da tabela de valores das linhas por mês

12 LISTA DE SIGLAS API Application Programming Interface CSS Cascading Style Sheets HQL Hibernate Query Language IDE Integrated Development Environment JDBC Java Database Connectivity JSP Java Server Pages LRF Lei de Responsabilidade Fiscal RCL Receita Corrente Líquida RGF Relatório de Gestão Fiscal RREO Relatório Resumido da Execução Orçamentária SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language STN Secretaria do Tesouro Nacional TCE Tribunal de Contas do Estado UML Unified Modeling Language W3C World Wide Web Consortium XML - extensible Markup Language

13 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA A LEI DE RESPONSABILIDADE FISCAL TRANSPARÊNCIA DA GESTÃO FISCAL CONTABILIDADE PÚBLICA XML HIBERNATE SISTEMA ATUAL TRABALHOS CORRELATOS Sistema de Fiscalização Integrada de Gestão Auditoria Eletrônica de Orgão Público DESENVOLVIMENTO DA FERRAMENTA LEVANTAMENTO DE INFORMAÇÕES ESPECIFICAÇÃO Diagrama de caso de uso Diagrama de classe Modelo de dados relacional IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Operacionalidade da implementação RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Descrição dos Casos de Uso APÊNDICE B Dicionário de dados... 62

14 12 1 INTRODUÇÃO A Lei de Responsabilidade Fiscal (LRF), Lei de número 101/2000, é uma lei complementar federal que, regulamentando o artigo 163 da Constituição Federal, estabelece as normas orientadoras das finanças públicas no país. Ela objetiva aprimorar a responsabilidade na gestão fiscal dos recursos públicos, por meio de ação planejada e transparente que possibilite prevenir riscos e corrigir desvios capazes de afetar o equilíbrio das contas públicas (KHAIR, 2000). Segundo Bezerra Filho (2006, p. 132) o objetivo da contabilidade pública é o de fornecer informações atualizadas e exatas à administração, para subsidiar as decisões dos gestores aos órgãos de controle interno e externo, para cumprimento da legislação e às instituições governamentais e particulares, para fins estatísticos ou de interesse dessas instituições. A empresa Pública Informática é responsável pelo desenvolvimento de um sistema de contabilidade pública, que, conforme exigência em licitações, deve emitir os relatórios da Lei de Responsabilidade Fiscal no formato definido pela Secretaria do Tesouro Nacional (STN) e fiscalizado pelo Tribunal de Contas do Estado de Santa Catarina (TCE-SC). Tais relatórios devem ser impressos e publicados online periodicamente sendo os Relatórios de Resumo da Execução Orçamentária (RREO) bimestralmente e os Relatórios da Gestão Fiscal (RGF) quadrimestralmente. Como se tratam de relatórios envolvendo dados oriundos de diversas fontes, sínteses e totalizações, deve-se garantir que os valores comuns entre esses relatórios não tenham inconformidades. O Setor de Qualidade da empresa deve assegurar relatórios mais íntegros e confiáveis para seus clientes, os contadores responsáveis pela emissão e disponibilização dos relatórios da Lei de Responsabilidade Fiscal. Esses relatórios possuem um leiaute definido pelos manuais da Lei de Responsabilidade Fiscal, que são as linhas que compõem os relatórios. Cada linha corresponde a um nível de receita, despesa ou contábil e apresenta seus respectivos valores de forma analítica ou a totalização de vários níveis na forma sintética. A quantidade de valores e de relatórios pode acabar dificultando o programador na conferência de seus valores e esse liberando o relatório com diferença de valores. Esta é a realidade da Pública Informática, pois os módulos que geram os relatórios solicitados pela LRF já existem há vários anos, e foram feitas várias alterações por diferentes programadores que hoje não fazem mais parte do quadro

15 13 de colaboradores, ou estes módulos sofreram alguma alteração em seus cálculos de valores por força de mudanças nas leis. Por exemplo, o esquecimento de usar uma rotina de arredondamento de valores pelo desenvolvedor responsável pode ocasionar a diferença entre os valores dos relatórios da Lei de Responsabilidade Fiscal gerados pelo sistema de Contabilidade da Pública Informática e com isso gerar reclamações se o mesmo for visto por um cliente final. Não tendo um processo de desenvolvimento descrito, resta ao setor de qualidade conferir e validar os relatórios, tendo grande responsabilidade e pressão para a liberação aos clientes. Face ao relatado optou-se por desenvolver uma ferramenta para auxiliar a conferência dos principais valores desses relatórios. 1.1 OBJETIVOS DO TRABALHO O objetivo do trabalho é apresentar uma ferramenta que automatize a conferência de valores totais que são comuns entre os anexos dos Relatórios da Execução Orçamentária e da Gestão Fiscal, da Lei de Responsabilidade Fiscal. Os objetivos específicos do trabalho são: a) analisar e apontar divergência entre os valores dos anexos dos Relatórios do Resumo da Execução Orçamentária e Relatório da Gestão Fiscal através de relatórios; b) padronizar um leiaute de importação com os valores de cada anexo da LRF deixando a possibilidade de outros sistemas exportarem valores da LRF em formato XML e importarem na ferramenta; c) disponibilizar a ferramenta na web a partir de liberação de um usuário e senha para que o suporte, que se encontra em campo, possa realizar os testes diretamente no cliente antes de publicar os relatórios. 1.2 ESTRUTURA DO TRABALHO Este trabalho está disposto em quatro capítulos. No primeiro capítulo, é apresentada a introdução do assunto, os objetivos a serem alcançados com o desenvolvimento e a estrutura do trabalho. O segundo capítulo apresenta a fundamentação teórica sobre conceitos de lei de

16 14 responsabilidade fiscal, transparência da gestão fiscal, contabilidade pública, framework Hibernate e XML, sistema atual e os trabalhos correlatos. No terceiro capítulo têm-se a descrição do ciclo de desenvolvimento do sistema, detalhes sobre a especificação e modelagem, técnicas e ferramentas utilizadas e a operacionalidade do sistema com os resultados e discussões. No quarto capítulo apresenta-se a conclusão sobre os objetivos alcançados e sugestões para trabalhos futuros.

17 15 2 FUNDAMENTAÇÃO TEÓRICA Esse capítulo apresenta a fundamentação teórica necessária para compreensão deste trabalho. São abordados assuntos relacionados com a Lei de Responsabilidade Fiscal, a transparência da gestão fiscal, a contabilidade pública. Também são abordados temas sobre as tecnologias utilizadas como o framework Hibernate e o XML, sistema atual e os trabalhos correlatos. 2.1 A LEI DE RESPONSABILIDADE FISCAL A Lei de Responsabilidade Fiscal (LRF), Lei Complementar n º 101, de 4 de maio de 2000, estabelece normas de finanças públicas voltadas para a responsabilidade na gestão fiscal. É um código de conduta para os administradores públicos que passarão a obedecer a normas e limites para administrar finanças, prestando contas de quanto e como gastam os recursos da sociedade. Para alcançar este objetivo a lei dispõe de meios, dentre os quais se destaca a ação planejada e transparente na busca do equilíbrio das contas públicas, cujas metas de resultados entre receitas e despesas devem ser cumpridas, assim como os limites e condições para a renúncia de receitas, despesa com pessoal, seguridade social, dívidas consolidadas e mobiliárias, operações de crédito, concessão de garantia e inscrição de restos a pagar. Em síntese, a LRF objetiva disciplinar a gestão dos recursos públicos atrelando maior responsabilidade aos seus gestores (TRIBUNAL DE CONTAS DE SANTA CATARINA, 2002, p 13). A LRF é uma lei complementar que, regulamentando o artigo 163 da Constituição Federal, estabelece as normas orientadoras das finanças públicas no País. Ela objetiva aprimorar a responsabilidade na gestão fiscal dos recursos públicos, por meio de ação planejada e transparente que possibilite prevenir riscos e corrigir desvios capazes de afetar o equilíbrio das contas públicas (KHAIR, 2000). Segundo o artigo 165 da Constituição Federal (BRASIL, 2002), a Lei de Responsabilidade Fiscal deve ser detalhada em dois grupos de relatórios: a) Relatório Resumido da Execução Orçamentária (RREO) que segundo Khair (2000, p. 46), o RREO incluirá todos os poderes e o Ministério Público e será publicado até 30 dias após o encerramento de cada bimestre. O descumprimento do prazo

18 16 pelo executivo ou legislativo municipal sujeita a prefeitura a não receber transferências voluntárias e a não contratar operações de créditos; b) Relatório da Gestão Fiscal (RGF) que, segundo KHAIR (2000, p. 47), ao final de cada quadrimestre será emitido pelos titulares dos Poderes e órgãos. O RGF será assinado, dentro de suas competências, pelo prefeito, pelo presidente de mesa Diretora do Legislativo, pelas autoridades responsáveis pela administração financeira, pelo controle interno e por outras autoridades definidas por ato próprio de cada poder ou órgão. O Relatório será publicado até 30 dias após o encerramento do período a que corresponder, com amplo acesso ao público, inclusive pela internet. O descumprimento do prazo pelo executivo ou pelo legislativo municipal sujeita a prefeitura a não receber transferências voluntárias e a não contratar operações de créditos. 2.2 TRANSPARÊNCIA DA GESTÃO FISCAL Uma importante contribuição da Lei de Responsabilidade Fiscal é a transparência da gestão fiscal, ao estabelecer que todos os principais relatórios fiscais devam ser amplamente divulgados, ao mesmo tempo em que assegura a participação da sociedade na discussão da Lei de Diretrizes Orçamentárias e da Lei Orçamentária Anual do Município (KHAIR, 2000). Será dada ampla divulgação, inclusive na Internet, para a Lei Orçamentária Anual, a Lei de Diretrizes Orçamentárias, as prestações de contas e seu parecer prévio, o Relatório da Execução Orçamentária, o Relatório da Gestão Fiscal e as versões simplificadas desses documentos. A transparência será assegurada também mediante incentivo à participação popular e a realização de audiência pública, tanto pelo executivo quanto pela Câmara Municipal, durante os processos de elaboração e de discussão da Lei Orçamentária Anual e da Lei de Diretrizes Orçamentárias (KHAIR, 2000). 2.3 CONTABILIDADE PÚBLICA Segundo Kohama (2001, p. 49), entende-se, nos tempos atuais, a Contabilidade como uma técnica capaz de produzir, com oportunidade e fidedignidade, relatórios que sirvam à administração no processo de tomada de decisões e de controle de seus atos, demonstrando, por fim, os efeitos produzidos por esses atos de gestão no patrimônio da entidade. Contabilidade pública é o ramo da contabilidade que tem por objetivo aplicar os conceitos, princípios e normas contábeis na gestão orçamentária, financeira e patrimonial dos

19 17 Órgãos e Entidades da Administração Pública, e, como ramo da contabilidade, oferecer à sociedade, de maneira transparente e acessível, o conhecimento amplo sobre a gestão da coisa pública (LIMA; CASTRO, 2000). No Brasil a contabilidade pública é regida pela Lei 4.320/ XML EXtensible Markup Language (XML) é uma recomendação da World Wide Web Consortium (W3C) para gerar linguagens de marcação para necessidades especiais. As linguagens de marcação são um conjunto de convenções utilizadas para a codificação de textos, que devem especificar que marcas são permitidas, quais são exigidas, como fazer distinção entre as marcas e o texto e qual seu significado da marcação (ALMEIDA, 2002). De acordo com Marchal (2000, p. 9), a XML pode ser útil em áreas como: a) manutenção de grandes sites; b) troca de informação entre organizações; c) carga e descarga de bancos de dados; d) aplicações de comércio eletrônico. A XML é aplicável a qualquer nível de complexidade, sendo autodescritiva. Suas marcações personalizadas podem ser criadas para qualquer necessidade, além da facilidade de manutenção, já que possui marcações tendo os links e folhas de estilos em separado, podendo ser alterado cada um separadamente, facilitando as modificações. Um dos pontos fortes da XML é a portabilidade, já que sua sintaxe universal de estrutura de dados permite troca de dados independente da plataforma (GRAVES, 2003, p.02). Na Figura 1 é apresentando um exemplo de XML onde são identificados os dados de matrícula e nome de dois alunos, as matérias que cada aluno irá cursar, e o cadastro do código e nome das matérias de um determinado curso.

20 18 Figura 1: Exemplo de arquivo XML 2.5 HIBERNATE O Hibernate é um framework que visa solucionar problemas gerados com persistência manual de dados em Java. O objetivo do framework é fazer o mapeamento entre classes e tabelas de um banco de dados, deixando o programador livre para desenvolver as regras de negócio (BAUER; KING, 2007, p.4). O Hibernate é um poderoso serviço de consultas e persistência objeto-relacional. Ele permite desenvolver classes persistentes seguindo o idioma orientado a objetos, incluindo associação, herança, polimorfismo, composição e coleções. Hibernate permite expressar consultas em sua própria extensão Structed Query Laguage (SQL), nomeada como Hibernate Query Language (HQL), bem como em SQL nativo, ou com critérios orientados a objetos (HIBERNATE, 2006). Fernandes e Lima (2007, p.9), definem que a arquitetura do Hibernate é formado por um conjunto de interfaces, sendo as principais:

21 19 a) Session: possibilita a comunicação entre a aplicação e a persistência, através de uma conexão JDBC. É ele que possibilita criar, remover, atualizar e recuperar objetos persistentes; b) Session factory: mantém o mapeamento objeto relacional em memória; c) Configuration: utilizado para realizar configurações de inicialização do Hibernate. Exemplo: driver do banco de dados, usuário e senha do banco de dados; d) Transaction: utilizada para representar uma unidade indivisível de uma operação de manipulação de dados; e) Criteria e Query: utilizadas para realizar consultas ao banco de dados. Segundo Fernandes e Lima (2007, p.19), no início o Hibernate carregava e armazenava objetos de classes persistentes utilizando arquivos XML. Todo o mapeamento era feito neste arquivo, cujo objetivo era efetuar a ligação entre um atributo e um campo do banco de dados e sua respectiva classe/tabela. Ainda segundo Fernandes e Lima (2007, p.19), com o surgimento das anotações no Java 5.0, tornou-se possível substituir os arquivos XML para o mapeamento objeto relacional. Fernandes e Lima (2007, p.16) explicam que as anotações são definidas no código fonte da entidade a ser persistida, e começam com um (arroba) seguido do nome da anotação. Essa anotação é ignorada pelo compilador. Com as anotações é possível anotar um atributo ou uma classe, dando-lhe algumas características para o mapeamento, conforme a Figura 2.

22 20 Fonte: Fernandes e Lima (2007, p.16). Figura 2: Exemplo de código usando anotações no Hibernate Algumas das anotações utilizadas pelo Hibernate segundo Fernandes e Lima (2007, p.21) são: usado no início das classes persistentes; indica as informações da tabela que será mapeada; indica a chave primária; permite a definição automática para o valor do indentificador; refere-se a coluna da tabela. A Figura 3 apresenta os bancos de dados suportados atualmente pelo Hibernate.

23 21 Fonte: Hibernate(2012). Figura 3: Banco de dados suportados pelo Hibernate 2.6 SISTEMA ATUAL Atualmente não há sistema automatizado para testes referentes a relatórios na Pública Informática. O responsável pelo teste gera os relatórios em formato PDF, ou até mesmo impressos em papel, e compara manualmente se os valores estão de acordo em cada um dos anexos da LRF. Se houver alguma diferença, esse deve repassar a inconsistência ao programador para que possa identificar o motivo ou o problema da diferença. Muitas vezes devido à quantidade de testes e à necessidade de rapidez de tais testes, pode passar despercebida uma inconsistência nos valores de algum dos relatórios.

24 22 A Figura 4 apresenta o fluxo atual do processo de teste de relatório, apesar de não existir um procedimento normatizado de testes na empresa. Figura 4: Fluxo do processo atual As Figuras 5 e 6 apresentam um exemplo do valor total de Receitas Correntes, denominado de Receita Corrente Líquida, que é comum entre o Anexo III da RREO (TESOURO NACIONAL, 2003a) e o Anexo II da RGF (TESOURO NACIONAL, 2003b).

25 23 Figura 5: Valor da receita corrente líquida no anexo III da RREO Figura 6: Valor da receita corrente líquida no anexo II da RGF 2.7 TRABALHOS CORRELATOS Pode se citar como trabalhos correlatos o sistema de auditoria de contabilidade pública de Santa Catarina, nomeado e-sfinge, e o sistema de auditoria contábil pública de São Paulo, chamado Audesp. Ambos possuem a finalidade de importar valores de receitas, despesas e contábeis das prefeituras, fundos e outros. Esses sistemas disponibilizam leiautes padrões aos quais os sistemas de contabilidade exportam em arquivo(s) para importar nesses sistemas. Ambos sistemas, antes de iniciar a auditoria sobre esses arquivos importados, fazem uma validação

26 24 dos dados verificando dados cadastrais, somatória de valores e arquivos não importados Sistema de Fiscalização Integrada de Gestão O Sistema de Fiscalização Integrada de Gestão (e-sfinge) corresponde a uma família de aplicativos altamente integrados e diretamente relacionados à atividade-fim do TCE-SC. O sistema foi desenvolvido com base em tecnologias modernas utilizando-se ao máximo os recursos da internet (TRIBUNAL DE CONTAS DE SANTA CATARINA, 2008?). Ainda segundo o Tribunal de Contas de Santa Catarina (2008?), o sistema representa a integração de todos os aplicativos de controle já constituídos pelo Tribunal. Também introduz novos conceitos para a consolidação dos dados de gestão em remessas unificadas, emissão de relatórios automáticos de avaliação, análise da gestão de cada município e do Estado e ampla publicidade das informações. A Figura 7 demonstra o leiaute do arquivo com os dados de lançamentos contábeis disponibilizados pelo sistema e-sfinge e a Figura 8 apresenta um exemplo de um arquivo gerado pelo sistema de contabilidade pública no leiaute definido. Figura 7: Leiaute do arquivo de lançamentos contábeis diponibilizado pelo sistema e-sfinge

27 25 Figura 8: Exemplo de parte de um arquivo no leiaute padrão do sistema e-sfinge A Figura 9 apresenta a tela responsável pela leitura dos arquivos. Esses arquivos devem ser salvos no diretório do próprio sistema para que o mesmo possa fazer a importação. Figura 9: Tela de importação do arquivo no sistema e-sfinge Na Figura 10 é apresentada a opção para verificar as inconsistências. O sistema sempre faz a verificação da última importação feita.

28 26 Figura 10: Tela de verificação de inconsistências no sistema e-sfinge sistema. A Figura 11 demonstra um exemplo de relatório de inconsistências apontadas pelo Figura 11: Relatório de inconsistências do Sistema e-sfinge Auditoria Eletrônica de Orgão Público Segundo o Tribunal de Contas do Estado de São Paulo (2003?) o projeto Auditoria Eletrônica de Órgãos Públicos é uma iniciativa do Tribunal de Contas do Estado de São Paulo no aperfeiçoamento do controle de gestão governamental. O principal objetivo é com a

29 27 utilização da tecnologia da informação, aprimorar os procedimentos de coleta de dados e informações dos órgãos fiscalizados, buscando maior agilidade nos trabalhos, aumento da qualidade dos dados e como conseqüência natural, o cumprimento da missão constitucional de fiscalizar e controlar as contas públicas paulistas com o máximo grau de eficiência e eficácia, em benefício da sociedade. Na Figura 12 pode-se verificar o leiaute do arquivo referente a dados contábeis do sistema e na Figura 13 um exemplo de um arquivo no leiaute definido. Figura 12: Leiaute do arquivo de lançamentos contábeis do sistema Audesp Figura 13: Exemplo de arquivo de lançamentos contábeis no sistema Audesp A Figura 14 demonstra a importação do arquivo XML na ferramenta disponibilizada

30 28 para transmissão do arquivo via internet para o sistema Audesp. Figura 14: Importação do arquivo XML para envio ao sistema Audesp A Figura 15 demonstra o sistema web Audesp apresentando uma mensagem de aviso sobre inconsistências pendentes.

31 29 Fonte: Tribunal de Contas de São Paulo (2007?). Figura 15: Tela de inconsistências pendentes do sistema Audesp A Figura 16 apresenta todos os arquivos que possuem inconsistências existentes nos envios dos arquivos. Fonte: Tribunal de Contas de São Paulo (2007?). Figura 16: Tela de visualização dos arquivos de inconsistência do Sistema Audesp sistema. A Figura 17 apresenta um exemplo de relatório de inconsistências apresentado pelo

32 Figura 17: Exemplo de um relatório de inconsistências do sistema Audesp 30

33 31 3 DESENVOLVIMENTO DA FERRAMENTA Neste capítulo serão abordados os tópicos sobre o levantamento das informações, as especificações, a implementação e a operacionalidade da ferramenta. 3.1 LEVANTAMENTO DE INFORMAÇÕES O setor de qualidade da empresa Pública Informática utiliza testes manuais para conferir valores dos relatórios da Lei de Responsabilidade Fiscal. Assim surgiu a necessidade de automatizar a conferência dos valores dos totais dos Relatórios da Lei, com o desenvolvimento de uma ferramenta para auxiliar e garantir que os valores totais dos níveis de receitas, despesas e contábeis sejam iguais nos relatórios onde aparecem. Com isto, garante-se ao usuário final relatórios mais íntegros e evita-se problemas com reclamações ou até mesmo com o Tribunal de Contas do Estado de Santa Catarina. Para uma melhor mobilidade e mais fácil acesso, foi escolhido desenvolver a ferramenta em plataforma web utilizando a tecnologia Java Server Pages (JSP). Através da disponibilização de um leiaute padrão dos valores de cada relatório da Lei de Responsabilidade Fiscal no formato XML é possível centralizar todos os relatórios e seus valores em um único arquivo. Como no sistema de contabilidade da Pública os relatórios da lei são gerados em tabela de memória antes de serem visualizados, torna-se possível a exportação dos valores para um arquivo conforme o leiaute proposto pela ferramenta. Em uma continuação desse trabalho outras empresas que tenham a necessidade de testar seus relatórios da Lei de Responsabilidade Fiscal poderão exportar para a ferramenta e validá-los também. A ferramenta possui relatórios com os valores e críticas a respeito de inconsistências encontradas entre os valores dos Anexos da LRF gerados pelo sistema de Contabilidade Pública. Esse relatório irá conter o nome do relatório, a linha com divergência e os valores discrepantes. O controle de acesso permite vários usuários utilizarem a ferramenta, gerenciados através de um cadastro de usuários, para o qual um administrador tem o privilégio de manutenção. Para integridade dos dados e futuras consultas, a ferramenta registra no banco de dados todas as transmissões dos arquivos XML contendo os valores enviados pelos usuários.

34 32 ferramenta. A Figura 18 apresenta o diagrama de atividades do fluxo principal sugerido pela Figura 18: Fluxo de processo proposto pela ferramenta ESPECIFICAÇÃO Nesta subseção serão apresentados os principais requisitos funcionais (RF), requisitos não funcionais (RNF), suas rastreabilidades com casos de uso, o diagrama de classes e o modelo entidade-relacionamento (MER) da ferramenta. A descrição dos casos de uso pode ser visualizada no Apêndice A. No Quadro 1 são apresentados os requisitos funcionais da ferramenta com vínculo aos casos de uso.

35 33 Requisitos Funcionais RF01: A ferramenta deve permitir ao usuário cadastrado acessar sistema através de um usuário e senha definida pelo mesmo. RF02: A ferramenta deve permitir ao usuário alterar a sua senha de acesso. RF03: A ferramenta deve permitir ao usuário cadastrar novos leiautes definidos pela STN. RF04: A ferramenta deve permitir ao usuário cadastrar novos relatórios. RF05: A ferramenta deve permitir ao usuário cadastrar novas linhas. RF06: A ferramenta deve permitir ao usuário vincular uma linha cadastrada a um relatório definido em um leiaute relatório. RF07: A ferramenta deve permitir fazer a importação do arquivo XML com os dados dos valores das linhas e relatórios. RF08: A ferramenta deve permitir ao usuário visualizar um log de suas importações de arquivo. RF09: A ferramenta deve permitir ao usuário visualizar os relatórios importados em cada importação de arquivo XML. RF10: A ferramenta deve permitir ao usuário visualizar as linhas dos relatórios importados em cada importação de arquivo XML. RF11: A ferramenta deve permitir o usuário visualizar os valores das linhas importadas em cada importação de arquivo XML. RF12: A ferramenta deve permitir o usuário visualizar as críticas da importação do arquivo selecionada, no período selecionado. RF13: A ferramenta deve permitir o usuário supervisor visualizar as importações de todos os usuários cadastrados. RF14: A ferramenta deve permitir o usuário supervisor cadastrar novos usuários e dar-lhes a permissão adequada. Quadro 1: Requisitos funcionais Caso de Uso UC01 UC02 UC03 UC04 UC05 UC06 UC07 UC08 UC08 UC08 UC08 UC09 UC10 UC11 O Quadro 2 apresenta os requisitos não funcionais da ferramenta. Requisitos Não Funcionais RNF01: A ferramenta deve possuir controle de sessão, considerando que é um sistema web online. RNF02: A ferramenta deve poder ser executada nos navegadores Firefox 3.6 ou superiores e Internet Explorer 8 ou superiores. RNF03: A ferramenta deve ser desenvolvida em JSP e utilizar banco de dados MySQL. RNF04: A ferramenta deve demonstrar as visualizações em forma de tabela. RNF05: A ferramenta deve ter controle de acesso e privilégios atráves de um login solicitando informações de nome e senha de login. Quadro 2: Requisitos não funcionais

36 Diagrama de caso de uso A Figura 19 mostra o cenário com as funcionalidades do sistema que o usuário testador e supervisor podem realizar. O supervisor tem acesso a todas as funcionalidades do sistema e o usuário possui apenas acesso a algumas telas conforme permissão no cadastro de usuários definida pelo usuário supervisor. Figura 19: Diagrama de casos de uso

37 Diagrama de classe A Figura 20 demonstra o diagrama de classes da ferramenta. Figura 20: Diagrama de classes da ferramenta Modelo de dados relacional A Figura 21 mostra o Modelo de dados Relacional, com base nas tabelas da ferramenta e seus relacionamentos. O dicionário de dados desenvolvido para especificar o sistema é apresentado no Apêndice B.

38 Figura 21: Modelo entidade-relacionamento da ferramenta 36

39 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da implementação Técnicas e ferramentas utilizadas A ferramenta desenvolvida consiste em uma aplicação web, a qual foi concebida utilizando-se a linguagem Java e JSP, funções JavaScript, framework JQuery e estilo de página CSS. Como servidor do JSP, foi utilizado o Apache Tomcat , pela suas vantagens. NetBeans 7.1. O Tomcat é um servidor de aplicações Java para web. É software livre e de código aberto, surgido dentro do conceituado projeto Apache Jakarta e que teve apoio e endosso oficial da Sun Microsystems como Implementação de Referência (RI) para as tecnologias Java Servlet e JavaServer Pages (JSP). Atualmente, o Tomcat tem seu próprio projeto de desenvolvimento independente, dentro da Apache Software Foundation. O Tomcat é robusto e eficiente o suficiente para ser utilizado mesmo em um ambiente de produção. (APACHE, 2011?). A implementação das classes e páginas do sistema foram feitas através da IDE O MySQL 5.5 foi utilizado como gerenciador de banco de dados da ferramenta, e o HeidiSQL foi utilizado para manipular e visualizar os dados das tabelas. O framework Hibernate foi utilizado para fazer a persistência entre o objeto da classe e a tabela do banco de dados, conjuntamente com a API Hibernate Criteria para as consultas mais simples. A Figura 22 demonstra a busca das linhas dos relatórios da ferramenta. Para as buscas mais complexas foi utilizada a linguagem SQL, conforme a Figura 23. Figura 22: Consulta da tabela LinhaRelatorio usando API Criteria

40 38 Figura 23: Consulta de validação de valores usando SQL Para a leitura do arquivo XML foi utilizado a JDOM, que segundo Jdom (2002) é uma API com código aberto desenvolvida em Java, com o intuito de facilitar a criação, leitura e manipulação de documentos XML. A Figura 24 apresenta uma parte da rotina de importação do XML da ferramenta. Figura 24: Código fonte da importação com JDOM Na Figura 25 é demonstrada a parte de código onde é feito o carregamento do arquivo XML e a leitura do cabeçalho do arquivo que contém informações necessárias para a ferramenta. Figura 25: Código fonte da leitura do arquivo XML

41 39 A Figura 26 apresenta o trecho do código fonte na qual é feita a leitura do leiaute que será utilizado para os leiautes dos relatórios que estão informados no arquivo XML. Figura 26: Código fonte da leitura dos relatórios Operacionalidade da implementação Nesta subseção será apresentada a sequência de telas e operações para correta utilização da ferramenta. Ao abrir o sistema é apresentada a tela de login conforme a Figura 27. O login terá a função de diferenciar o usuário supervisor dos demais usuários testadores e suas permissões. O usuário supervisor tem permissão de acesso para toda a ferramenta, conforme a Figura 28. Figura 27: Tela de login da ferramenta

42 40 Figura 28: Tela principal do usuário supervisor da ferramenta O cadastro de usuário é necessário para que se tenha um controle de quem está fazendo as importações dos arquivos e validando-os. O controle de permissões torna-se necessário para que o usuário responsável pelo teste não altere dados que não são de sua responsabilidade, conforme mostra a Figura 29. Na Figura 30 é demonstrado a tela principal do usuário testador cadastrado, com apenas o acesso às funcionalidades definidas em seu cadastro. Figura 29: Tela do cadastro e permissões de usuários na ferramenta

43 41 Figura 30: Tela principal do usuário os menus de suas permissões na ferramenta O cadastro de entidades refere-se ao cadastro da prefeitura, fundo, autarquia, fundação, secretaria que será testado. Nessa tela são visualizadas todas as entidades cadastradas no banco de dados como demonstrado na Figura 31. Esses dados podem ser cadastrados manualmente, como demonstrado na Figura 32, ou então a própria importação do arquivo XML fica responsável em adicionar essa entidade, caso ela ainda não exista no cadastro. Figura 31: Tela de consulta das entidades cadastradas

44 42 Figura 32: Tela de cadastro de entidade O cadastro de leiaute refere-se a qual portaria normativa da STN será montado a estrutura do relatório e suas linhas. A Figura 33 mostra tela de consulta dos leiautes cadastrados na ferramenta e a Figura 34 apresenta a tela de cadastro de leiautes. Figura 33: Tela de consulta de leiautes da ferramenta Figura 34: Tela de cadastro de leiaute da ferramenta O cadastro de leiaute relatórios refere-se a estrutura do relatório e suas linhas que farão parte do leiaute definido. A Figura 35 apresenta a tela de consulta das linhas do leiaute e seus relatórios vinculados. A Figura 36 apresenta a tela de cadastro de um novo leiaute para um novo relatório e linha para um leiaute.

45 43 Figura 35: Tela de consulta das linhas do relatório e leiaute da ferramenta Figura 36: Tela de cadastro de linhas do relatório e leiaute da ferramenta O cadastro de relatórios refere-se aos relatórios/anexos que foram apresentados na portaria publicada pela STN e serão validados pela ferramenta. A Figura 37 demonstra a tela de consulta dos relatórios cadastrados e a Figura 38 apresenta a tela de cadastro de relatórios.

46 44 Figura 37: Tela de consulta de relatórios da ferramenta Figura 38: Tela de cadastro de relatórios da ferramenta O cadastro de linhas representa as linhas existentes nos relatórios que serão testados. A Figura 39 apresenta a tela de consulta de linhas e a Figura 40 demonstra a tela de cadastro de linhas. Figura 39: Tela de consulta de linhas cadastradas na ferramenta

47 45 Figura 40: Tela de cadastro de linhas da ferramenta A importação do arquivo XML, exportado pelo sistema de contabilidade pública, é demonstrada na Figura 41. Se a importação dos dados foi concluída com sucesso, a ferramenta irá apresentar uma mensagem (Figura 42). Caso o leiaute informado no arquivo não esteja cadastrado na base de dados, a ferramenta irá apresentar a mensagem indicada (Figura 43). Figura 41: Tela de importação do arquivo XML da ferramenta Figura 42: Tela da importação realizada com sucesso na ferramenta

48 46 Figura 43: Tela da importação com leiaute inválido na ferramenta Todas as importações feitas são gravadas em um log e todos os usuários têm acesso às suas importações, conforme Figura 44. O usuário supervisor tem acesso a todas as importações feitas, como apresentado na Figura 45. Figura 44: Tela do log de importações do usuário testador

49 47 Figura 45: Tela do log de importações de todos usuários Em todas as importações é possível verificar quais relatórios foram importados (Figura 46), as linhas importadas desses relatórios (Figura 47) e os seus respectivos valores (Figura 48). Figura 46: Tela dos relatórios importados

50 48 Figura 47: Tela das linhas importadas de cada relatório Figura 48: Tela dos valores das linhas importadas pela ferramenta A validação dos dados possui duas opções de visualização, a primeira é com as inconsistências e com confirmação dos dados que foram importados (Figura 49) e a segunda é somente as inconsistências, quando parâmetro Visualizar somente inconsistências estiver marcado, como pode ser visto na Figura 50.

51 49 Figura 49: Tela de validação com o parâmetro Visualizar somente inconsistências desmarcado Figura 50: Tela de validação com o parâmetro Visualizar somente inconsistências marcado A ferramenta dispõe inicialmente de quatro validações de inconsistências: a) a inconsistência de linhas com valores diferentes entre relatórios pode ser visto na Figura 51. Na Figura 52 é demonstrada a mesma inconsistência de valor, porém ao

52 50 posicionar o cursor do mouse sobre a linha é apresentado um complemento de quais os relatórios estão utilizando a linha inconsistente; b) a inconsistência de relatórios não importados (Figura 53); c) a validação de linhas não importadas (Figura 54); d) a validação de linhas importadas mas não existentes no leiaute informado no XML (Figura 55). Figura 51: Mensagem de inconsistência de valor da ferramenta Figura 52: Mensagem de inconsistência de valor com complemento dos relatórios Figura 53: Mensagem de inconsistência de relatório não importado Figura 54: Mensagem de inconsistência de linha não importada Figura 55: Mensagem de inconsistência de linha importada O sistema de contabilidade pública deve exportar os dados dos seus relatórios conforme o leiaute disponibilizado pela ferramenta (Figura 56). Caso o sistema de contabilidade pública exporte um código de relatório que não exista no cadastro de relatórios, automaticamente a ferramenta o adicionará em seu cadastro. O mesmo irá acontecer caso seja importada uma linha que não está definida no leiaute relatório.

53 51 Figura 56: Leiaute de importação da ferramenta 3.3 RESULTADOS E DISCUSSÃO Após a implementação desse trabalho foram feitos vários testes em bases de dados diferentes. Na maioria dos testes realizados não houve a ocorrência de nenhum tipo de inconsistência. Foi realizado um teste no sistema da Pública em 21/05/2012, a qual foi encontrada inconsistência referente ao valor total da receita corrente líquida entre o anexo III RREO e o anexo II da GF. A Figura 57 demonstra o valor da RCL que estava sendo apresentando no anexo III RREO, que conforme a Figura 58 estavam divergentes.

54 52 Figura 57: Valor total da Receita corrente líquida no relatório anexo III da RREO Figura 58:Valor total da Receita corrente líquida no relatório anexo II da RGF

55 53 A Figura 59 apresenta a inconsistência apontada pela ferramenta referente a divergência entre os dois relatórios. Figura 59: Tela da inconsistência do valor entre os relatórios anexo III e II Em conversa informal com o diretor da empresa Pública Informática, junto com o responsável pelo setor de qualidade, chegou-se aos seguintes benefícios que a ferramenta proporciona: a) um grande diferencial, pois é de grande importância esse tipo de ferramenta de apoio interno para a empresa; b) criar um leiaute padrão para esses relatórios, sendo que os mesmos podem ser usado para outras ferramentas ou aplicativos com outras finalidades; c) por ser web a possibilidade de funcionários externos estarem validando os relatórios diretamente nos clientes; d) agilidade e maior produtividade para o setor de qualidade e desenvolvimento. Em relação aos trabalhos correlatos pode-se verificar que a ferramenta possui um leiaute padrão com os dados que serão importados, e a mesma faz validações de inconsistências, que assim como os sistemas e-sfinge e Audesp, objetiva a integridades dos dados que serão gravados antes de serem auditados. A partir do estudo desses sistemas, foi possível conceber a ferramenta desenvolvida.

56 54 4 CONCLUSÕES Neste trabalho foi proposto o desenvolvimento de uma ferramenta para auxiliar o setor de qualidade nos testes dos relatórios da lei de responsabilidade fiscal da empresa Pública Informática. Os objetivos gerais e específicos foram cumpridos, sendo que a ferramenta está validando os valores e dados importados, foi criado um leiaute padrão para a ferramenta e disponibilizada em um web hosting para acesso externo. Foram utilizados diversos frameworks e APIs para o desenvolvimento dessa ferramenta, sendo que todos tiveram grande importância para a maior agilidade no desenvolvimento. O CSS foi utilizado para criar estilos para as páginas da internet, já o JQuery foi útil para padronizar as tabelas das consultas e criar funcionalidades de ordenação nas colunas da mesma. O Jdom, foi responsável pela leitura e escrita no arquivo XML. Esse trabalho também demonstra uma ferramenta de apoio com a finalidade de testar valores que tenham importância entre vários relatórios. Conclui-se com a realização deste o aumento do conhecimento sobre as aplicações desenvolvidas para o ambiente web, desde o desenvolvimento utilizando JSP até as integrações que são possíveis de serem realizadas, como a integração do framework Hibernate em um projeto Java utilizando anotações nos atributos das classes. Também pode se destacar a grande importância para a empresa Pública Informática o desenvolvimento e utilização desse tipo de ferramenta. Assim dando mais agilidade, produtividade e automatização em processos que ainda são manuais. 4.1 EXTENSÕES Como extensão dessa ferramenta, pode ser feita a implementação de uma validação entre importações, onde o usuário deverá informar duas importações que deverão ser comparadas. A ferramenta então irá validar e mostrar ao usuário testador a diferença encontrada entre a importação A e B. Outra implementação que pode ser feita é a validação dos valores por mês - por exemplo, o sistema de contabilidade pública exporta os valores até o mês de dezembro, a ferramenta então valida os valores de cada mês entre os relatórios, assim informando qualquer inconsistência de valor em algum mês.

57 55 REFERÊNCIAS BIBLIOGRÁFICAS ALMEIDA, Maurício Barcellos. Uma introdução ao xml, sua utilização na internet e alguns conceitos complementares. [S.l.], Disponível em: < Acesso em: 21 abr APACHE. The Apache Tomcat 5.5 Servlet. Los Angeles, [2011?]. Disponível em: <http >. Acesso em: 21 abr BAUER, Christian; KING, Gavian. Java Persistence com Hibernate. Rio de Janeiro:Editora Ciência Moderna Ltda., BEZERRA FILHO, João Eudes. Contabilidade pública: teoria, técnica de elaboração de balanços e 500 questões. 2. ed. Rio de Janeiro: ELSEVIER, BRASIL. Constituição da república federativa do Brasil, de 5 de outubro de Brasília: Senado Federal, Subsecretaria de Edições Técnicas, FERNANDES, Raphaela G.; LIMA, Gleydson de A. F. Hibernate com Anotações. Natal, Disponível em: < Acesso em: 16 abr GRAVES, Mark. Projeto de banco de dados com XML. Tradução Aldair José Coelho Corrêa da Silva. São Paulo: Pearson, HIBERNATE. Relational persistence for Java and.net. [S.l.], Disponível em: < Acesso em: 12 maio JDOM. JDOM and XML Parsing, Part 1. [S.1], Disponível em: < >. Acesso em: 21 abr KHAIR, Amir Antônio. Lei de responsabilidade fiscal: Guia de Orientação para as Prefeituras. Brasília, KOHAMA, Heilio. Contabilidade pública: Teoria e Prática. 8. ed. São Paulo: ATLAS S.A, LIMA, Diana Vaz; CASTRO, Róbison Gonçalves. Contabilidade pública: Integrando União, Estados e Municípios (Siafi e Siafem). São Paulo: ATLAS S.A, MARCHAL, Benoit. XML: conceitos e aplicações. 1. ed. São Paulo: Berkeley, 2000.