Embed Size (px)
Citation preview
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
2012
2012/1-03
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
2012
2012/1-03
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: Prof. Marcel Hugo, Mestre, FURB
______________________________________________________
Membro: Prof. Everaldo Artur Grahl, Mestre – FURB
______________________________________________________
Membro: Prof. Wilson Pedro Carli, Mestre – FURB
Blumenau, 6 de julho de 2012.
Dedico este trabalho a minha família e minha
noiva, que sempre me deram muita força.
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.
Não sabendo que era impossível, foi lá e fez.
Jean Cocteau
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.
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.
LISTA DE FIGURAS
Figura 1: Exemplo de arquivo XML ........................................................................................ 18
Figura 2: Exemplo de código usando anotações no Hibernate ................................................. 20
Figura 3: Banco de dados suportados pelo Hibernate .............................................................. 21
Figura 4: Fluxo do processo atual............................................................................................. 22
Figura 5: Valor da receita corrente líquida no anexo III da RREO .......................................... 23
Figura 6: Valor da receita corrente líquida no anexo II da RGF .............................................. 23
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 ................................................. 25
Figura 8: Exemplo de parte de um arquivo no leiaute padrão do sistema e-Sfinge ................. 25
Figura 11: Relatório de inconsistências do Sistema e-Sfinge................................................... 26
Figura 10: Tela de verificação de inconsistências no sistema e-Sfinge ................................... 26
Figura 12: Leiaute do arquivo de lançamentos contábeis do sistema Audesp ......................... 27
Figura 13: Exemplo de arquivo de lançamentos contábeis no sistema Audesp ....................... 27
Figura 14: Importação do arquivo XML para envio ao sistema Audesp.................................. 28
Figura 15: Tela de inconsistências pendentes do sistema Audesp ........................................... 29
Figura 16: Tela de visualização dos arquivos de inconsistência do Sistema Audesp .............. 29
Figura 17: Exemplo de um relatório de inconsistências do sistema Audesp............................ 30
Figura 18: Fluxo de processo proposto pela ferramenta........................................................... 32
Figura 19: Diagrama de casos de uso ....................................................................................... 34
Figura 20: Diagrama de classes da ferramenta ......................................................................... 35
Figura 21: Modelo entidade-relacionamento da ferramenta ..................................................... 36
Figura 22: Consulta da tabela LinhaRelatorio usando API Criteria ......................................... 37
Figura 23: Consulta de validação de valores usando SQL ....................................................... 38
Figura 24: Código fonte da importação com JDOM ................................................................ 38
Figura 25: Código fonte da leitura do arquivo XML................................................................ 38
Figura 26: Código fonte da leitura dos relatórios ..................................................................... 39
Figura 27: Tela de login da ferramenta .................................................................................... 39
Figura 29: Tela do cadastro e permissões de usuários na ferramenta ...................................... 40
Figura 28: Tela principal do usuário supervisor da ferramenta ................................................ 40
Figura 30: Tela principal do usuário os menus de suas permissões na ferramenta .................. 41
Figura 31: Tela de consulta das entidades cadastradas............................................................. 41
Figura 33: Tela de consulta de leiautes da ferramenta ............................................................. 42
Figura 34: Tela de cadastro de leiaute da ferramenta ............................................................... 42
Figura 32: Tela de cadastro de entidade ................................................................................... 42
Figura 35: Tela de consulta das linhas do relatório e leiaute da ferramenta ............................ 43
Figura 36: Tela de cadastro de linhas do relatório e leiaute da ferramenta .............................. 43
Figura 37: Tela de consulta de relatórios da ferramenta .......................................................... 44
Figura 39: Tela de consulta de linhas cadastradas na ferramenta ............................................. 44
Figura 38: Tela de cadastro de relatórios da ferramenta .......................................................... 44
Figura 41: Tela de importação do arquivo XML da ferramenta............................................... 45
Figura 42: Tela da importação realizada com sucesso na ferramenta ...................................... 45
Figura 40: Tela de cadastro de linhas da ferramenta ................................................................ 45
Figura 43: Tela da importação com leiaute inválido na ferramenta ......................................... 46
Figura 44: Tela do log de importações do usuário testador ...................................................... 46
Figura 45: Tela do log de importações de todos usuários ........................................................ 47
Figura 46: Tela dos relatórios importados ................................................................................ 47
Figura 48: Tela dos valores das linhas importadas pela ferramenta ......................................... 48
Figura 47: Tela das linhas importadas de cada relatório .......................................................... 48
Figura 50: Tela de validação com o parâmetro ―Visualizar somente inconsistências‖ marcado
............................................................................................................................... 49
Figura 49: Tela de validação com o parâmetro ―Visualizar somente inconsistências‖
desmarcado ............................................................................................................ 49
Figura 51: Mensagem de inconsistência de valor da ferramenta .............................................. 50
Figura 52: Mensagem de inconsistência de valor com complemento dos relatórios ............... 50
Figura 53: Mensagem de inconsistência de relatório não importado ....................................... 50
Figura 54: Mensagem de inconsistência de linha não importada ............................................. 50
Figura 55: Mensagem de inconsistência de linha importada .................................................... 50
Figura 56: Leiaute de importação da ferramenta ...................................................................... 51
Figura 57: Valor total da Receita corrente líquida no relatório anexo III da RREO ................ 52
Figura 58:Valor total da Receita corrente líquida no relatório anexo II da RGF ..................... 52
Figura 59: Tela da inconsistência do valor entre os relatórios anexo III e II ........................... 53
LISTA DE QUADROS
Quadro 1: Requisitos funcionais............................................................................................... 33
Quadro 2: Requisitos não funcionais ........................................................................................ 33
Quadro 3: Caso de uso efetuar login ........................................................................................ 57
Quadro 4: Caso de uso alterar senha ........................................................................................ 57
Quadro 5: Caso de uso cadastrar leiaute ................................................................................... 58
Quadro 6: Caso de uso Cadastrar relatório ............................................................................... 58
Quadro 7: Caso de uso Cadastrar linha .................................................................................... 59
Quadro 8: Caso de uso vincular linha para um leiaute relatório .............................................. 59
Quadro 9: Caso de uso importar XML ..................................................................................... 60
Quadro 10: Caso de uso visualizar importações ....................................................................... 60
Quadro 11: Caso de uso visualizar inconsistências .................................................................. 61
Quadro 12: Caso de uso Visualizar todas importações ............................................................ 61
Quadro 13: Caso de uso Cadastrar usuários ............................................................................. 61
Quadro 14: Dicionário de dados da tabela entidade. ................................................................ 62
Quadro 15: Dicionário de dados da tabela usuário ................................................................... 63
Quadro 16: Dicionário de dados da tabela leiaute. ................................................................... 63
Quadro 17: Dicionário de dados da tabela relatório. ................................................................ 64
Quadro 18: Dicionário de dados da tabela linha....................................................................... 64
Quadro 19: Dicionário de dados da tabela de leiautes dos relatórios. ...................................... 64
Quadro 20: Dicionário de dados da tabela de linhas relatório. ................................................. 64
Quadro 21:Dicionário de dados da tabela importação.............................................................. 65
Quadro 22: Dicionário de dados da tabela de relatórios importados. ....................................... 65
Quadro 23: Dicionário de dados da tabela valor linha ............................................................. 65
Quadro 24: Dicionário de dados da tabela de valores das linhas por mês. ............................... 66
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
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 13
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 A LEI DE RESPONSABILIDADE FISCAL.................................................................... 15
2.2 TRANSPARÊNCIA DA GESTÃO FISCAL .................................................................... 16
2.3 CONTABILIDADE PÚBLICA ........................................................................................ 16
2.4 XML .................................................................................................................................. 17
2.5 HIBERNATE .................................................................................................................... 18
2.6 SISTEMA ATUAL ........................................................................................................... 21
2.7 TRABALHOS CORRELATOS ........................................................................................ 23
2.7.1 Sistema de Fiscalização Integrada de Gestão.................................................................. 24
2.7.2 Auditoria Eletrônica de Orgão Público ........................................................................... 26
3 DESENVOLVIMENTO DA FERRAMENTA ............................................................... 31
3.1 LEVANTAMENTO DE INFORMAÇÕES ...................................................................... 31
3.1.1 ESPECIFICAÇÃO ....................................................................................................... 32
3.1.1.1 Diagrama de caso de uso .............................................................................................. 34
3.1.1.2 Diagrama de classe ....................................................................................................... 35
3.1.1.3 Modelo de dados relacional .......................................................................................... 35
3.2 IMPLEMENTAÇÃO ........................................................................................................ 37
3.2.1 Técnicas e ferramentas utilizadas .................................................................................... 37
3.2.2 Operacionalidade da implementação ............................................................................... 39
3.3 RESULTADOS E DISCUSSÃO ...................................................................................... 51
4 CONCLUSÕES .................................................................................................................. 54
4.1 EXTENSÕES .................................................................................................................... 54
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 55
APÊNDICE A – Descrição dos Casos de Uso ...................................................................... 57
APÊNDICE B – Dicionário de dados .................................................................................... 62
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
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
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.
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
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
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/64.
2.4 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.
18
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:
Figura 1: Exemplo de arquivo XML
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 símbolo @ (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.
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:
a) @Entity: usado no início das classes persistentes;
b) @Table: indica as informações da tabela que será mapeada;
c) @Id: indica a chave primária;
d) @GeneretedValue: permite a definição automática para o valor do indentificador;
e) @Column: refere-se a coluna da tabela.
A Figura 3 apresenta os bancos de dados suportados atualmente pelo Hibernate.
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.
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).
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
24
dos dados verificando dados cadastrais, somatória de valores e arquivos não importados.
2.7.1 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
25
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.
Figura 8: Exemplo de parte de um arquivo no leiaute padrão do sistema e-Sfinge
26
A Figura 11 demonstra um exemplo de relatório de inconsistências apontadas pelo
sistema.
Figura 11: Relatório de inconsistências do Sistema e-Sfinge
2.7.2 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
Figura 10: Tela de verificação de inconsistências no sistema e-Sfinge
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.
A Figura 14 demonstra a importação do arquivo XML na ferramenta disponibilizada
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
28
para transmissão do arquivo via internet para o sistema Audesp.
A Figura 15 demonstra o sistema web Audesp apresentando uma mensagem de aviso
sobre inconsistências pendentes.
Figura 14: Importação do arquivo XML para envio ao sistema Audesp
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
A Figura 17 apresenta um exemplo de relatório de inconsistências apresentado pelo
sistema.
30
Figura 17: Exemplo de um relatório de inconsistências do sistema Audesp
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.
32
A Figura 18 apresenta o diagrama de atividades do fluxo principal sugerido pela
ferramenta.
Figura 18: Fluxo de processo proposto pela ferramenta
3.1.1 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.
33
Requisitos Funcionais Caso de Uso
RF01: A ferramenta deve permitir ao usuário cadastrado acessar sistema
através de um usuário e senha definida pelo mesmo.
UC01
RF02: A ferramenta deve permitir ao usuário alterar a sua senha de
acesso.
UC02
RF03: A ferramenta deve permitir ao usuário cadastrar novos leiautes
definidos pela STN.
UC03
RF04: A ferramenta deve permitir ao usuário cadastrar novos relatórios. UC04
RF05: A ferramenta deve permitir ao usuário cadastrar novas linhas. UC05
RF06: A ferramenta deve permitir ao usuário vincular uma linha
cadastrada a um relatório definido em um leiaute relatório.
UC06
RF07: A ferramenta deve permitir fazer a importação do arquivo XML
com os dados dos valores das linhas e relatórios.
UC07
RF08: A ferramenta deve permitir ao usuário visualizar um log de suas
importações de arquivo.
UC08
RF09: A ferramenta deve permitir ao usuário visualizar os relatórios
importados em cada importação de arquivo XML.
UC08
RF10: A ferramenta deve permitir ao usuário visualizar as linhas dos
relatórios importados em cada importação de arquivo XML.
UC08
RF11: A ferramenta deve permitir o usuário visualizar os valores das
linhas importadas em cada importação de arquivo XML.
UC08
RF12: A ferramenta deve permitir o usuário visualizar as críticas da
importação do arquivo selecionada, no período selecionado.
UC09
RF13: A ferramenta deve permitir o usuário supervisor visualizar as
importações de todos os usuários cadastrados.
UC10
RF14: A ferramenta deve permitir o usuário supervisor cadastrar novos
usuários e dar-lhes a permissão adequada.
UC11
Quadro 1: Requisitos funcionais
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
34
3.1.1.1 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
35
3.1.1.2 Diagrama de classe
A Figura 20 demonstra o diagrama de classes da ferramenta.
3.1.1.3 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.
Figura 20: Diagrama de classes da ferramenta
36
Figura 21: Modelo entidade-relacionamento da ferramenta
37
3.2 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
3.2.1 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 7.0.2.6, pela suas
vantagens.
―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
NetBeans 7.1.
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
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
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
3.2.2 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
40
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
Figura 28: Tela principal do usuário supervisor da ferramenta
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
42
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.
Figura 32: Tela de cadastro de entidade
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.
44
Figura 37: Tela de consulta 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
Figura 38: Tela de cadastro de relatórios da ferramenta
45
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
Figura 40: Tela de cadastro de linhas da ferramenta
46
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
Figura 43: Tela da importação com leiaute inválido na ferramenta
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
48
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.
Figura 47: Tela das linhas importadas de cada relatório
49
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
Figura 49: Tela de validação com o parâmetro ―Visualizar somente inconsistências‖ desmarcado
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.
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.
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
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.
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.
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.], 2002. Disponível em:
<http://www.ibict.br/cionline/include/getdoc.php?id=456&article=173&mode=pdf>. Acesso
em: 21 abr. 2012.
APACHE. The Apache Tomcat 5.5 Servlet. Los Angeles, [2011?]. Disponível em: <http
http://tomcat.apache.org/download-55.cgi >. Acesso em: 21 abr. 2012.
BAUER, Christian; KING, Gavian. Java Persistence com Hibernate. Rio de Janeiro:Editora
Ciência Moderna Ltda., 2007.
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, 2006.
BRASIL. Constituição da república federativa do Brasil, de 5 de outubro de 1988.
Brasília: Senado Federal, Subsecretaria de Edições Técnicas, 2002.
FERNANDES, Raphaela G.; LIMA, Gleydson de A. F. Hibernate com Anotações. Natal,
2007. Disponível em:
<http://wiki.futurepages.org/lib/exe/fetch.php?media=quickstart:hibernate_anotacoes.pdf>.
Acesso em: 16 abr. 2012.
GRAVES, Mark. Projeto de banco de dados com XML. Tradução Aldair José Coelho
Corrêa da Silva. São Paulo: Pearson, 2003.
HIBERNATE. Relational persistence for Java and .NET. [S.l.], 2006. Disponível em:
<http://www.hibernate.org/>. Acesso em: 12 maio 2012.
JDOM. JDOM and XML Parsing, Part 1. [S.1], 2002. Disponível em:
<http://www.jdom.org/docs/oracle/jdom-part1.pdf >. Acesso em: 21 abr. 2012.
KHAIR, Amir Antônio. Lei de responsabilidade fiscal: Guia de Orientação para as
Prefeituras. Brasília, 2000.
KOHAMA, Heilio. Contabilidade pública: Teoria e Prática. 8. ed. São Paulo: ATLAS S.A,
2001.
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, 2000.
MARCHAL, Benoit. XML: conceitos e aplicações. 1. ed. São Paulo: Berkeley, 2000.
56
TESOURO NACIONAL. Relatório resumido da execução orçamentária: Manual de
Elaboração. Brasília, 2003a. Disponível em:
<http://www.tesouro.fazenda.gov.br/legislacao/download/contabilidade/manualrreo3.pdf>.
Acesso em: 20 mar. 2012.
TESOURO NACIONAL. Relatório de gestão fiscal: Manual de Elaboração. Brasília, 2003b.
Disponível em:
<http://www.tesouro.fazenda.gov.br/legislacao/download/contabilidade/ManualRGF3.pdf>.
Acesso em: 20 mar. 2012.
THE JQUERY PROJECT, JQuery biblioteca JavaScript. Nova York, 2006. Disponível em:
<http://jquery.com/>. Acesso em: 28 mar. 2012.
TRIBUNAL DE CONTAS DE SANTA CATARINA. Guia da lei de responsabilidade
fiscal. 2. ed. Florianópolis: Tribunal de contas, 2002.
TRIBUNAL DE CONTAS DE SANTA CATARINA. E-Sfinge. Florianópolis, [2008?].
Disponível em: <http://www.tce.sc.gov.br/web/servicos/esfinge-informacoes>>. Acesso em:
21 abr. 2012.
TRIBUNAL DE CONTAS DE SÃO PAULO. Auditoria Eletrônica do Estado de São
Paulo: Manual Técnico - Operacional. São Paulo,[2003?]. Disponível em:
<http://www.tce.sp.gov.br/sites/default/files/Audesp_Manual_Tecnico_Operacional_v1a.pdf>
. Acesso em: 10 jul. 2012.
TRIBUNAL DE CONTAS DE SÃO PAULO. O que é o Audesp?. São Paulo,[2007?].
Disponível em: <http://www4.tce.sp.gov.br/content/audesp>. Acesso em: 21 abr. 2012.
57
APÊNDICE A – Descrição dos Casos de Uso
No Quadro 3 verifica-se o detalhamento do caso de uso Efetuar login.
UC01- Efetuar login
Ator: Usuário
Objetivo: Acessar o sistema.
Pós condições: Acesso ao menu principal do sistema.
Cenário principal: 1. Usuário informa seu nome de usuário e senha;
2. Ferramenta verifica se existe o usuário e se a senha é válida;
3. Ferramenta redireciona para menu principal.
Cenário Alternativo:
No passo 2, se o usuário não existir ou a senha não for a mesma cadastrada o sistema:
2.1 mostrar mensagem de usuário ou senha não cadastrados.
Quadro 3: Caso de uso efetuar login
No Quadro 4 verifica-se o detalhamento do caso de uso Alterar senha.
UC02- Alterar senha
Ator: Usuário
Objetivo: Alterar a senha do usuário.
Pré condições: O usuário deve estar conectado.
Pós condições: Senha alterada.
Cenário principal:
1. Usuário acessa cadastro de usuários;
2. Usuário informa a nova senha e a confirmação da senha;
3. Ferramenta compara a senha e a confirmação da senha;
4. Ferramenta grava a nova senha no banco de dados.
Cenário Alternativo:
No passo 3, se a senha e a confirmação da senha forem diferentes:
3.1 A ferramenta mostra mensagem avisando sobre a diferença.
3.2 Volta ao passo 2 do cenário principal.
Quadro 4: Caso de uso alterar senha
No Quadro 5 verifica-se o detalhamento do caso de uso Cadastrar leiaute.
58
UC03- Cadastrar leiaute
Ator: Usuário
Objetivo: Cadastrar um novo leiaute.
Pré condições: Usuário estar conectado e ter permissão ao menu de cadastro de leiaute ou
ser o usuário supervisor.
Pós condições: Cadastrado novo leiaute.
Cenário principal:
1. Usuário acessa o menu de cadastro de leiautes;
2. Usuário clica no botão para adicionar novo leiaute;
3. Usuário preenche os dados do ano e a portaria do leiaute;
4. Ferramenta valida se os dados foram preenchidos;
5. Ferramenta grava o novo leiaute na base de dados.
Cenário Alternativo:
No passo 4, se um dos campos não for preenchido:
4.1 Ferramenta mostra mensagem alertando que o campo deve ser preenchido;
4.2 Volta ao passo 3 do cenário principal.
Quadro 5: Caso de uso cadastrar leiaute
No Quadro 6 verifica-se o detalhamento do caso de uso Cadastrar relatório
UC04- Cadastrar relatório
Ator: Usuário.
Objetivo: Cadastrar um relatório.
Pré condições: Usuário estar conectado e ter permissão ao menu de cadastro de relatórios ou
ser o usuário supervisor.
Pós condições: Cadastrado novo relatório.
Cenário principal:
1. Usuário acessa o menu de cadastro de relatórios;
2. Usuário clica no botão para adicionar novo relatório;
3. Usuário preenche os dados do código e nome do relatório;
4. Ferramenta valida os dados se os dados foram preenchidos;
5. Ferramenta adiciona o novo relatório na base de dados.
Cenário Alternativo:
No passo 4, se o código ou o nome do relatório não foram preenchidos:
4.1 Se o código não for preenchido a ferramenta busca o próximo código válido;
4.2 Se o nome não foi preenchido a ferramenta mostra a mensagem que o nome do relatório
não foi preenchido;
4.3 Volta ao passo 3 do cenário principal.
Quadro 6: Caso de uso Cadastrar relatório
No Quadro 7 verifica-se o detalhamento do caso de uso Cadastrar linha.
59
UC05- Cadastrar linha
Ator: Usuário.
Objetivo: Cadastrar uma linha.
Pré condições: Usuário estar conectado e ter permissão ao menu de cadastro de linhas ou ser
o usuário supervisor.
Pós condições: Cadastrado nova linha.
Cenário principal:
1. Usuário acessa o menu de cadastro de linhas;
2. Usuário clica no botão para adicionar nova linha;
3. Usuário preenche os dados do código e nome da linha;
4. Ferramenta valida os dados se os dados foram preenchidos;
5. Ferramenta adiciona a nova linha na base de dados.
Cenário Alternativo:
No passo 4, se o código ou o nome da linha não foram preenchidos:
4.1 Se o código não for preenchido a ferramenta busca o próximo código válido;
4.2 Se o nome não foi preenchido a ferramenta mostra a mensagem que o nome da linha não
foi preenchido;
4.3 Volta ao passo 3 do cenário principal.
Quadro 7: Caso de uso Cadastrar linha
No Quadro 8 verifica-se o detalhamento do caso de uso Vincular linha para um leiaute
relatório.
UC06- Vincular linha em um leiaute relatório
Ator: Usuário
Objetivo: Vincular uma nova linha ao relatório do leiaute informado.
Pré condições: Usuário estar conectado e ter permissão ao menu de cadastro de leiaute
relatórios ou ser o usuário supervisor.
Pós condições: Nova linha vinculada a um determinado relatório de um leiaute.
Cenário principal:
1. Usuário acessa o menu de leiaute relatórios;
2. Usuário selecionar o leiaute e o relatório e clica em pesquisar;
3. Usuário clica no botão para adicionar nova linha;
4. Usuário seleciona a linha que deseja adicionar;
5. Ferramenta adiciona a nova linha para o leiaute e relatório na base de dados
Quadro 8: Caso de uso vincular linha para um leiaute relatório
No Quadro 9 verifica-se o detalhamento do caso Importar XML.
60
UC07- Importar XML
Ator: Usuário
Objetivo: Importar um novo arquivo XML para validação.
Pré condições: Usuário estar conectado e ter permissão ao menu de importação de XML
relatórios ou ser o usuário supervisor.
Pós condições: Valores das linhas do relatório adicionadas na base de dados.
Cenário principal:
1. Usuário acessa no menu Importar XML;
2. Usuário clica no botão para selecionar arquivo;
3. Usuário clica no botão importar;
4. Ferramenta carrega arquivo XML e importa os dados para a base de dados;
5. Ferramenta finaliza mostra mensagem de finalização da importação.
Cenário Alternativo:
No passo 3, se o leiaute informado no arquivo não estiver cadastrado:
3.1 Ferramenta vai mostrar uma mensagem dizendo que o leiaute é inválido;
3.2 Volta ao Cenário principal.
Quadro 9: Caso de uso importar XML
No Quadro 10 verifica-se o detalhamento do caso de uso Visualizar importações
UC08- Visualizar importações
Ator: Usuário
Objetivo: Visualizar todas as importações feitas pelo usuário.
Pré condições: Usuário estar conectado e ter permissão ao menu de Visualizar importações
ou ser o usuário supervisor.
Pós condições: Visualizar todas as importações feitas por ele e os detalhes dos dados
importados.
Cenário principal:
1. Usuário acessa menu Visualizar importações;
2. Ferramenta mostra todas as importações do usuário;
3. Usuário seleciona a importação;
4. Ferramenta mostra os relatórios importados;
5. Usuário seleciona o relatório;
6. Ferramenta mostra as linhas importadas;
7. Usuário seleciona a linha;
8. Ferramenta mostra os valores da linha por mês e ano.
Quadro 10: Caso de uso visualizar importações
No Quadro 11 verifica-se o detalhamento do caso de uso visualizar inconsistências.
61
UC09- Visualizar inconsistências
Ator: Usuário
Objetivo: Visualizar as inconsistências e informações de uma determinada importação.
Pré condições: Usuário estar conectado e ter permissão ao menu de Validar inconsistências
ou ser o usuário supervisor.
Pós condições: Visualizar as inconsistências.
Cenário principal:
1. Usuário acessa menu Validações de dados;
2. Usuário selecionar a importação que deseja visualizar;
3. Usuário clica no botão visualizar;
4. Ferramenta faz as validações que foram feitas e visualiza para o usuário.
Quadro 11: Caso de uso visualizar inconsistências
No Quadro 12 verifica-se o detalhamento do caso de uso Visualizar todas importações
UC10- Visualizar todas importações
Ator: Supervisor
Objetivo: Visualizar todas as importações feitas por todos usuários.
Pré condições: Supervisor estar conectado.
Pós condições: Visualizar todas as importações feitas por todos usuários.
Cenário principal:
1. Supervisor acessa menu Visualizar importações;
2. Ferramenta mostra todas as importações.
Quadro 12: Caso de uso Visualizar todas importações
No Quadro 13 verifica-se o detalhamento do caso de uso Cadastrar usuário.
UC11- Cadastrar usuários
Ator: Supervisor
Objetivo: Cadastrar um novo usuário.
Pré condições: Supervisor estar conectado.
Pós condições: Cadastrado novo usuário.
Cenário principal:
1. Supervisor acessa o menu de Cadastro de usuários;
2. Supervisor clica no botão para adicionar novo usuário;
3. Supervisor preenche os campos referentes aos dados do usuário e suas permissões;
4. Ferramenta valida as informações preenchidas;
5. Ferramenta adiciona novo usuário na base de dados.
Cenário Alternativo:
No passo 3, se algum campo não foi preenchido :
3.1 Mostrar mensagem do campo que falta ser preenchido.
3.2 Volta ao passo 3 do cenário principal.
Quadro 13: Caso de uso Cadastrar usuários
62
APÊNDICE B – Dicionário de dados
Este apêndice apresenta o dicionário de dados de tabelas do sistema, e visa fornecer
uma breve descrição das tabelas e seus respectivos campos.
O campo chave é nomeado como ―id‖ e sempre existirá em toda a entidade. Os tipos
de dados de cada campo são descritos a seguir:
a) varchar: representa uma sequência de letras ou números;
b) int: representa números inteiros;
c) date: representa uma data;
d) time: representa uma hora;
e) double: representa valores com decimal.
O Quadro 14 apresenta o dicionário de dados da tabela ―entidade‖.
Tabela: ENTIDADE
Tabela responsável por armazenar as informações relativas as entidades da ferramenta.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
Id int 11 Sim Chave primária representa o
id da entidade
codigo int 11 Sim Código da entidade no
sistema de contabilidade
pública
Nome varchar 80 Sim Nome da entidade Quadro 14: Dicionário de dados da tabela entidade.
O Quadro 15 apresenta o dicionário de dados da tabela ―usuario‖.
63
Tabela: USUARIO
Tabela responsável por armazenar as informações relativas ao usuário da ferramenta.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id do usuário
nome varchar 80 Sim Nome do usuário
usuario varchar 40 Sin Nome utilizado pelo usuário
para acessar a ferramenta
senha Varchar 20 Sim Senha do usuário
supervisor char 1 Sim Indica se o usuário é
supervisor
permentidade char 1 Sim Indica se o usuário tem acesso
ao menu de cadastro de
entidades.
permimportacao char 1 Sim Indica se o usuário tem acesso
ao log de importações
permimportarxml Char 1 Sim Indica se o usuário tem
acessao a tela de importação
de arquivo XML
permleiaute Char 1 Sim Indica se o usuário tem acesso
ao cadastro de leiautes
permleiauterelatorio Char 1 Sim Indica se o usuário tem acesso
ao menu de vincula de linhas
de leiautes relatorio
permlinha Char 1 Sim Indica se o usuário tem acesso
ao cadastro de linhas
permrelatorio Char 1 Sim Indica se o usuario tem acesso
ao cadastro de relatórios
permusuario Char 1 Sim Indica se o usuario tem acesso
ao cadastro de usuarios
permvalidarelatorio Char 1 Sim Indica se o usuairo tem acesso
a tela de validação de
inconsistências Quadro 15: Dicionário de dados da tabela usuário
O Quadro 16 apresenta o dicionário de dados da tabela ―usuario‖
Tabela: LEIAUTE
Tabela responsável por armazenar as informações relativas aos leiautes da ferramenta.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id do leiaute
ano Int 11 Sim Ano da portaria
Portaria Varchar 80 Sim Descrição da portaria Quadro 16: Dicionário de dados da tabela leiaute.
64
O Quadro 17 apresenta o dicionário de dados da tabela ―relatorio‖
Tabela: RELATORIO
Tabela responsável por armazenar as informações relativas aos relatórios da ferramenta.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id do leiaute
Codigo Int 11 Sim Código do relatório
Nome Varchar 255 Sim Nome do relatório Quadro 17: Dicionário de dados da tabela relatório.
O Quadro 18 apresenta o dicionário de dados da tabela ―linha‖
Tabela: LINHA
Tabela responsável por armazenar as informações relativas as linhas da ferramenta.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id do leiaute
Codigo Int 11 Sim Código da linha
Nome Varchar 255 Sim Nome da linha Quadro 18: Dicionário de dados da tabela linha.
O Quadro 19 apresenta o dicionário de dados da tabela ―LEIAUTE_RELATORIO‖
Tabela: LEIAUTE_RELATORIO
Tabela responsável por armazenar as informações relativas as linhas dos relatórios de cada
portaria.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id do leiaute_relatorio
Leiaute_id Int 11 Sim Id do leiaute
Relatorio_id Int 11 Sim Id do relatório Quadro 19: Dicionário de dados da tabela de leiautes dos relatórios.
O Quadro 20 apresenta o dicionário de dados da tabela ―linha_relatorio‖
Tabela: LINHA_RELATORIO
Tabela responsável por armazenar as informações relativas as linhas de cada relatório da
portaria.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id da linha_relatorio
Leiaute_relatorio_id Int 11 Sim Id do leiaute relatório
Linha_id Int 11 Sim Id da linha Quadro 20: Dicionário de dados da tabela de linhas relatório.
65
O Quadro 21 apresenta o dicionário de dados da tabela ―importacao‖
Tabela: IMPORTACAO
Tabela responsável por armazenar as informações relativas as importações da ferramenta.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id da importação
Data Date Sim Data da importação
Hora Time Sim Hora da importação
Versaosistema Varchar 10 Sim Versão do sistema que
exportou os dados
Entidade_id Int 11 Sim Id da entidade referente aos
dados.
Usuario_id Int 11 Sim Id do usuário que fez a
importação
mes Int 11 Sim Mês final que os dados foram
exportados. Quadro 21:Dicionário de dados da tabela importação.
O Quadro 22 apresenta o dicionário de dados da tabela ―leiaute_importado‖
Tabela: RELATORIO_IMPORTADO
Tabela responsável por armazenar as informações relativas aos relatórios importados
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id do relatório importado
Importacao_id Int 11 Sim Id da importação
Leiaute_relatorio_id Varchar 255 Sim Id do leiaute e seu relatório Quadro 22: Dicionário de dados da tabela de relatórios importados.
O Quadro 23 apresenta o dicionário de dados da tabela ―valor_linha‖
Tabela: VALOR_LINHA
Tabela responsável por armazenar as informações relativas as linhas importadas
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária
representa o id do valor
linha
Relatorio_importado_id Int 11 Sim Id do relatório
importado
Linha_id Int 11 Sim Id da linha Quadro 23: Dicionário de dados da tabela valor linha
O Quadro 24 apresenta o dicionário de dados da tabela ―valor_linha_mes‖
66
Tabela: VALOR_LINHA_MES
Tabela responsável por armazenar as informações relativas aos valores das linhas
importadas.
Colunas:
Nome Tipo Tamanho Obrigatório Descrição
id int 11 Sim Chave primária representa o
id da tabela
Ano Int 11 Sim Ano do valor
Mes Int 11 Sim Mes do valor
Valor_arrecadado Double 15,5 Não Valor arrecadado quando
receita
Valor fixado Double 15,5 Não Valor fixado quando despesa
Valor_Previsto Double 15,5 Não Valor previsto quando receita
Valor_movimentado Double 15,5 Não Valor do movimento contabil
Valor_atualizado Double 15,5 Não Valor atualizado da despesa Quadro 24: Dicionário de dados da tabela de valores das linhas por mês.
