Convenções para a implementação de documentos impressos

Estabelecer as diretrizes básicas para a implementação de relatórios e outros documentos impressos pelo sistema.

O estilo e as definições desse documento devem ser adotadas, na medida do possível, em todos os documentos impressos pelo sistema. Em alguns casos bem específicos o estilo de impressão poderá ser modificado, como no caso de documentos específicos de cada município/estabelecimento de ensino. Entretanto, mesmo nesses documentos, os aspectos técnicos da implementação devem se manter fiéis aos padrões tanto quanto possível.

• Fonte: Arial;
• Tamanho padrão: 8pt;
• Letras maiúsculas;
• Cor de fundo da área externa à página: azul claro (#94ABCF);
• Cor de fundo da página: branco (#FFF);
• Borda da página: preta;
• Margem interna da página: 15px.

• Largura: toda a página (100%);
• Altura: 60px;
• Borda inferior: 1px sólida preta;
• Alinhamento vertical dos itens: centro;
• Alinhamento horizontal dos itens: de acordo com o modelo de timbre selecionado;
  • Lado a lado: Timbre dividido em duas partes. Em cada uma delas, a logo da entidade e seus dados são alinhados à esquerda;
  • Centralizado: Logo da entidade mantenedora à esquerda do texto, alinhado à esquerda. Textos ao centro, centralizados. Logo do estabelecimento de ensino à direita do texto, alinhado à direita;
• Tamanho das logos: 55 x 55px;
• Tamanho dos textos:
  • Nome da entidade/estabelecimento: 10pt;
  • Dados da entidade/estabelecimento: 6pt.

• Alinhamento: centralizado;
• Tamanho da fonte: 10pt;
• Estilo: negrito.

• Alinhamento: centralizado;
• Tamanho da fonte: 8pt;
• Estilo: negrito.

• Posicionamento: imediatamente abaixo do título;
• Formato: tabela (sem bordas visíveis);
• Uma linha para cada filtro/opção, na mesma ordem em que são exibidos na tela de parâmetros do relatório (exceto para os grids, onde todos os filtros devem vir em uma única linha);
• Duas colunas para cada filtro: uma com o identificador do filtro/opção e a outra com os dados definidos pelo usuário;
• Identificadores de filtros/opções em negrito (font-weight: 600).

• Formato de tabela;
• Linhas com borda cinza (#C0C0C0);
• Colunas sem borda visível;
• Cabeçalho das colunas em negrito;
• Fundo da linha de cabeçalho cinza claro (#DDD);
• Todas as letras em maiúsculas (inclusive o cabeçalho das colunas);
• Alinhamento do texto:
  • Valores inteiros e datas: centralizado;
  • Valores decimais: alinhados à direita;
  • Demais valores: alinhados à esquerda;
  • O cabeçalho das colunas e os totais, quando exibidos, devem seguir o mesmo alinhamento do texto da coluna;
• Subtotais e totais em negrito;

• Posicionamento: imediatamente abaixo dos registros;
• Alinhamento: centralizado;
• Conteúdo: Total de registros e data/hora da geração do relatório;
• Estilo: Total de registros em negrito, data/hora normal.

Em alguns casos, antes da impressão dos documentos, é necessário que o usuário defina alguns parâmetros de impressão, como filtros de dados e preferências de exibição. Nesses casos, uma tela deve ser exibida para que o usuário possa definir tais parâmetros. Essas telas devem seguir as seguintes convenções:

Quando o documento a ser impresso é específico de um módulo do sistema, o título do formulário deve trazer o nome do módulo ao qual ele pertence. Quando o documento for um relatório geral, ou puder ser impresso a partir de vários locais do sistema, o título do formulário deve ser definido com o nome do relatório ou documento que será impresso.

Opções de filtro de dados devem estar agrupadas de acordo com seu tipo ou finalidade. O nome desses grupos deve estar de acordo com os filtros e não devem ser usados nomes genéricos como “Filtros”, por exemplo. Os parâmetros que não envolvam a filtragem direta de dados ou não se enquadrem nos grupos de filtros definidos devem ser agrupados em um único grupo chamado “Opções”, que deve ser posicionado sempre no final do relatório.

Uma exceção a essa organização é quando alguma opção muda ou limita os filtros que podem ser aplicados. Nesse caso, essas opções devem ser posicionadas antes dos filtros, para que a ordem de preenchimento dos parâmetros seja mais lógica.

Os dados informados pelo usuário nas telas de parâmetros deverão ser validados apenas quando o usuário clicar no botão que efetivamente gera o relatório (exceto as exceções de data inválida em campos com máscara, que devem ser tratadas quando o foco deixar o campo).

Os estilos dos documentos impressos devem ser definidos através de arquivos .css, distribuídos junto com a instalação do sistema. A estrutura dos documentos (código html) deve estar livre de qualquer definição de estilo para facilitar a manutenção tanto do estilo quanto da estrutura do documento. Documentos com folhas de estilo incorporadas também devem ser evitados, salvo em casos muito específicos.

Por padrão, três arquivos devem ser disponibilizados pelo sistema e utilizados na composição dos documentos impressos:

• Reset.css: elimina as definições padrão dos navegadores para garantir que as demais folhas de estilo sejam processadas corretamente;
• Base.css: estabelece o estilo básico dos relatórios e documentos gerais do sistema;
• Baseprn.css: modifica o estilo dos relatórios e documentos para que eles se ajustem melhor à impressão (usado apenas quando a mídia for uma impressora).

Ao implementar um novo relatório ou documento as definições dessas três folhas de estilo devem ser usadas sempre que possível. Caso o documento precise de estilos específicos, deve-se criar uma nova folha de estilo apenas com o que não estiver contemplado pelas folhas de estilo padrão ou com os estilos que devem ser sobrescritos.

Ao definir uma folha de estilo, as seguintes diretrizes devem ser adotadas:

• Evitar repetições desnecessárias: utilizar seletores mais genéricos para definir propriedades comuns ao invés de repetir as mesmas propriedades em seletores mais específicos;
• Organizar os estilos de acordo com o documento: tentar manter a mesma ordem em que os seletores aparecem no documento e agrupar estilos que correspondam a uma parte específica do documento;
• Usar medidas de fonte absolutas: a não ser que o tamanho da fonte possa ser modificado pelo usuário em tempo de execução, o ideal é definir tamanhos absolutos para fontes, em pontos (pt) ao invés de medidas relativas, como ”%” ou “em”;
• Usar medidas em pixels para containers: definir o tamanho de containers em pixels (px) quando o tamanho for absoluto, ou porcentagem (%) quando o tamanho for relativo;
• Ser coerente: observar as folhas de estilo já definidas para manter o mesmo padrão de implementação em todas elas.

Todo documento impresso deve ser implementado através de uma classe que herda da classe base TDocumentoImpresso. Essa classe deve ser responsável por:

• Armazenar os parâmetros do documento;
• Validar as informações fornecidas pelo usuário para a geração do documento (filtros e opções);
• Gerar efetivamente o documento (montar o código html que será exibido para o usuário);
• Exibir o relatório para o usuário;
• Registrar a ação de visualização do documento no log de ações.

Caso o documento necessite de parâmetros definidos pelo usuário, deverá existir uma classe responsável pela interação com o usuário (formulário).

Os parâmetros do documento (sejam eles filtros ou outras opções) devem ser codificados como propriedades e campos da classe lógica do relatório. Quando esses parâmetros forem passados pelo próprio sistema, isso deve ser feito através do método Create() da classe específica do relatório. Já para os parâmetros que devem ser definidos pelo usuário, estes devem ser codificados como propriedades públicas da classe, para que a tela de parâmetros possa setar os dados antes da geração do documento.

A validação desses parâmetros deve ser feita no método da classe base (TDocumentoImpresso) ValidarParametros(), sobrescrito na classe específica do relatório. Esse método deve disparar exceções específicas para os erros encontrados, que devem ser tratadas na tela de parâmetros. A implementação do método ValidarParametros() da classe base dispara uma exceção quando invocado diretamente, e esse método é invocado sempre que o documento é gerado e visualizado (através do método VisualizarDocumento()). Portanto, mesmo que não haja validações a realizar no documento, esse método precisa ser sobrescrito.

O documento é gerado através da invocação do método VisualizarDocumento(), que irá invocar métodos específicos para cada uma de suas responsabilidades: validar os parâmetros (ValidarParametros()), gerar o documento (ToStr()), exibir o documento gerado (ExibirDocumento()) e registrar a ação de visualização do documento (RegistrarAcao()).

O código de geração do html do relatório deverá ser composto de ao menos um método, que sobrescreve o método ToStr() da classe base (TDocumentoImpresso). Esse método deve escrever a estrutura básica do relatório e incorporar o código html gerado pelos métodos específicos. É recomendável que cada região ou grupo de dados do relatório tenha um método que recupera e processa esses dados e retorna o html correspondente. É recomendável também que cada método específico retorne uma estrutura completa (tal como uma <div> ou uma <table>, por exemplo).

Os comandos SQL utilizados para recuperar os dados necessários, quando existentes, devem ser gerados por métodos específicos que, ao serem invocados, retornam o comando pronto para ser usado. Isso facilita a manutenção pois separa o código SQL do código html e identifica os comandos através do nome dos métodos.

Após a geração do documento, este será salvo em um arquivo html na pasta temporária do sistema ([caminho da aplicação]\temp\ExportFile.htm) e, logo após, exibido ao usuário utilizando a tela padrão de exibição de relatórios.

O registro da ação de geração/visualização de um documento é realizado através do método RegistrarVisualizacaoDocumento(), da classe base, invocado automaticamente após a exibição de um documento. Esse método não pode ser sobrescrito, mas a mensagem utilizada para registrar a ação pode ser redefinida através do campo FTextoLogAcoes. Quando esse campo estiver definido, seu conteúdo será gravado no log de ações da forma como foi definido. Se esse campo permanecer em branco, o texto padrão (Visualização do relatório <Título do relatório>) será gravado.

Documentos específicos de um usuário/município (Históricos, atas, etc) devem seguir as diretrizes técnicas desse documento, mas devem ter seus estilos definidos de acordo com as solicitações do cliente.