ER_PCREQ-642_Impressão_dos_Relatórios_BIRT_a_partir_do_Portal

(Obrigatório)

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo

Permitir que a partir do CRM (HTML) o administrador do sistema consiga realizar o cadastro do relatório assim como seus parâmetros e a associação dos relatórios aos usuários que terão acesso.

De forma semelhante, deverá ser disponibilizado para os demais usuário uma central na qual seja possível acessar os relatórios cadastrados que ele possua acesso e realizar a impressão do relatório em PDF quando este acessar pelo portal ou abrir a exibição pelo BIRT Viewer quando acesso pelo menu-html.

(Obrigatório)

Definição da Regra de Negócio

Rotina

Pré-requisitos

• O BIRT Viewer deve estar disponibilizado sob o contexto /birt.
• O BIRT deve estar disponibilizado no mesmo servidor de aplicação do TOTVS 12. O WAR normalmente vai embarcado com o EAR do produto;
• Relatórios desenvolvidos e funcionais;
• Os relatórios deve estar disponíveis dentro do diretório: webviewer-4.3.1.war\report\crm\
• O arquivo com a configuração dos dados de acesso ao banco (config.properties) de dados devem estar disponíveis no diretório: webviewer-4.3.1.war\WEB-INF\
  

Cadastro de Relatório

O cadastro de relatórios se dará através de um CRUD semelhante ao que foi desenvolvido para o Controle de Acesso do CRM. O cadastro será acessado apenas pelo administrador do sistema. Para o cadastro em si utilizaremos a tabela crm_relat_web com os seguintes campos:

• nom_relat: Nome do relatório;
• nom_arq_relat: Nome do arquivo do relatório; Exemplo: imp_ocor.rptdesign;
• idi_modul_crm: Armazena o módulo do CRM ao qual o relatório faz parte (i01crm00366.i);
• log_hier_time: Flag informando se este relatório deve ou não considerar a regra de time de vendas.
  
  

Assim como os demais CRUDs este deverá possuir pesquisa avançada disponibilizando os seguintes campos para consulta:

• nom_relat: Nome do relatório; 
• nom_arq_relat: Nome do arquivo do relatório; Exemplo: imp_ocor.rptdesign;
• idi_modul_crm: Armazena o módulo do CRM ao qual o relatório faz parte;
• num_id_usuar: Usuário associado ao relatório. Para este caso consultar a tabela relacionada crm_usuar_relat_web.
  
  

Na listagem o filtro rápido deve realizar a consulta em cima dos campos nom_relat e nom_arq_relat. Para cada relatório, o campo nom_relat será considerado como título e os demais campo (idi_modul_crm, nom_arq_relat e log_hier_time) serão apresentados como complementares.

Ao solicitar a exclusão de um relatório, a exclusão deve ser realizada em cascata, eliminando todos os relacionamentos.

Durante o cadastro ou edição de um relatório os campos nom_relat, nom_arq_relat e idi_modul_crm serão obrigatórios.

Após finalizar o cadastro ou edição, o sistema deve direcionar o usuário para o detalhamento do registro.

Durante o detalhamento do relatório deve ser apresentado ao usuário, além dos dados do relatório, as abas de parâmetros e usuários.

Parâmetros do Relatório

Para o cadastro de parâmetros do relatório utilizaremos a tabela crm_param_relat_web.

Cada relatório pode conter vários parâmetros e estes estarão dispostos em forma de lista com a seguinte identificação visual: obrigatório (log_livre_1), parâmetro (nom_param) e tipo de dado do parâmetro (idi_tip_campo).

Cada parâmetro terá a opção de ser excluído ou editado.

Para adição e edição de um parâmetro iremos considerar os seguintes campos:

• num_id_relat_web: código do relatório;
• nom_param: nome do parâmetro, exatamente como é esperado pelo relatório do BIRT;
• nom_apel_campo: apelido para o parâmetro. Este apelido será utilizado na tela de execução do relatório;
• idi_tip_campo: tipo de dado do parâmetro: 1 String, 2 Numeric e 3 Zoom; (i01crm00367.i);
• num_id_propried: este campo será apresentado somente quando o idi_tip_campo for 3 (zoom); neste caso será apresentado um zoom para a tabela crm_propried para que o usuário informe qual zoom será renderizado para seleção do valor do parâmetro antes da execução do relatório;
• log_livre_1: Flag indicando se o parâmetro deve ser obrigatório.
  

Durante o cadastro ou edição de um parâmetro do relatório os campos idi_tip_campo, nom_apel_campo e nom_param serão obrigatórios. Entretanto, quando o idi_tip_campo for 3 (zoom) o campo num_id_propried passa a ser obrigatório.

Toda vez que o sistema realizar a busca dos parâmetros do relatório, independente se for no cadastro, edição ou execução, quando o idi_tip_campo for 3 (zoom) deverá retornar junto com o parâmetro os campos nom_tab_crm e nom_field_label provenientes do registro associado da tabela crm_propried.

Usuários do Relatório

Tendo em vista que a tabela é apenas relacional, na aba de usuários será apresentado todos os usuários associados com a opção de exclusão por usuário. Para adição de novos usuários ao relatório será disponibilizado um zoom de usuários de múltipla seleção; assim como foi realizado no controle de acesso.

Ao selecionar os usuários estes serão armazenados na tabela crm_usuar_relat_web da seguinte forma:

• num_id_relat_web: código do relatório;
• num_id_usuar: código do usuário;

Na listagem de usuários deve ser apresentado o nome do usuário.

Execução dos Relatórios

Para execução dos será desenvolvida uma tela na qual serão disponibilizados todos os relatórios que o usuário logado possui acesso. A identificação do acesso se dá pelo relacionamento crm_relat_web.num_id e crm_usuar_relat_web.num_id_relat_web.

Nesta tela iremos disponibilizar o filtro pelo nome do relatório. Quando a tela de relatórios for executada a partir de outra tela do produto como por exemplo a tela de consulta de ocorrências, apenas os relatórios do módulo de suporte devem ser apresentados. No caso de tarefas e históricos, os relatórios do módulo de relacionamento devem ser apresentados.

Quando a tela for aberta através da entrada de menu, todos os relatórios, indepêndente do módulo, que o usuário tiver acesso devem ser apresentados.

A apresentação dos relatórios será agrupada por módulo do CRM, e cada módulo irá conter uma lista de relatórios que o usuário possuir acesso.

Quando selecionado um relatório o sistema deverá expandir o painel para apresentar os parâmetros associados ao relatório. O sistema deverá obedecer as seguintes regras de acordo com cada tipo de parâmetro:

1. Caractere: Poderá ser informado qualquer valor. Se o parâmetro for requerido o mesmo não poderá ficar em branco;
2. Numérico: Somente aceitará números, será desconsiderada a utilização de máscaras e casas decimais;
3. Zoom: Será renderizado em tela um componente do tipo typeahead, que irá consumir um serviço genérico. Este serviço deverá retornar as informações de acordo com o registro da crm_propried associado ao parâmetro. A princípio será exibido somente o nom_field_label da tabela crm_propried.

A chamada para a tela de execução de relatórios deverá ser adicionada nas seguintes telas:

• Calendário;
• Consulta de Tarefas;
• Consulta de Histórico de Ação;
• Consulta de Contas;
• Consulta de Ocorrências;
• Consulta de Oportunidades;

A execução do relatório terá duas saidas diferentes. Quando executado através do contexto do portal será gerado um PDF para download. Quando executado pelo menu-html será aberto o próprio BIRT Viewer.

Ainda para execução dos relatórios, iremos utilizar os parâmetros do CRM:

• BIRT_DATABASE: Formato de data do banco de dados, que o relatório do CRM utilizará para fazer a conversão da data passada por parâmetro; (1. Progress, 2. Oracle e 3. MSSQL);
  
• BIRT_DATABASE_DATE: Formato de data do banco de dados, que o relatório do CRM utilizará para fazer a conversão da data passada por parâmetro.
  

Estas preferências são passadas como parâmetro, banco e data respectivamente, para todos os relatórios. Mesmo não sendo utilizados no relatório. 

Caso o relatório esteja parametrizado para utiliziar time de vendas, crm_relat_web.log_hier_time = true, na chamada do relatório será informado o parâmetro time=1.

Execução dos Relatórios - Portal 

Neste caso, será desenvolvido em JAVA uma camada que irá receber os parâmetros e o código do relatório a ser executado e irá retornar um PDF para download. Assim como é feito hoje com a impressão de ocorrência. Desta forma, a mesma arquitetura e infraestrutura deverá ser utilizada.

A geração do PDF se dá por questões de segurança uma vez que o contexto do portal estará disponível na internet. Sendo que o BIRT Viewer não está hoje em um contexto seguro e possui acesso direto as bases de dados via JDBC.

Execução dos Relatórios - Menu HTML

Diferentemente do contexto do portal, o contexto do menu-html é normalmente de uso na intranet. Desta forma ao solicitar a execução do relatório através do menu-html será gerada a URL para acesso ao BIRT Viewer, já provendo os parâmetros informado pelo usuário.

A URL para acesso ao BIRT Viewer deve seguir a seguinte estrutura apresentada como exemplo:

• /birt/frameset?__report=report/crm/<crm_relat_web.nom_arq_relat>&time=1&banco=1&data=dd/MM/yyyy&param=abc
  
  

Lembrando que, os parâmetros para a execução do relatório são passados através da própria URL e que os parâmetros time, banco e data são provenientes respectivamente das seguintes informações: crm_relat_web.log_hier_time, BIRT_DATABASE e BIRT_DATABASE_DATE.

Os parâmetros informados pelo usuário serão dispostos também na URL seguindo a conveção do W3C: &<crm_param_relat_web.nom_param>=<valor>.

Observações

1. Os relatórios desenvolvidos hoje no BIRT que utilizam da própria infraestrutura do Viewer para seleção dos parâmetros poderão ser cadastrados no CRM para serem chamados pelo produto. Entretanto, caso o relatório seja chamado pelo contexto do portal, o funcionamento ficará comprometido pois o usuário não terá acesso ao BIRT Viewer para informar os parâmetros;
2. Caso o relatório possua algum parâmetro que seja crucial para a execução do relatório não esteja cadastrado no CRM, a execução pode ficar comprometida;
3. No cadastro de parâmetros para o relatório a tipagem deve ser a mesma tipagem do parâmetro especificada no template do relatório;
4. O desenvolvimento dos relatórios é de responsabilidade do cliente, podendo a área de serviços da TOTVS ser contratada para o desenvolvimento dos relatórios.

Tabelas Utilizadas

• crm_relat_web - Cadastro de Relatório
• crm_usuar_relat_web - Cadastro de Usuários do Relatório
• crm_param_relat_web - Cadastro de Parametros do Relatório
  
  
•  crm_propried - Cadastro de Propriedades para Segmentação de Dados
  
  
• crm_acess_form_portal - Cadastro de Formulários e Campos do Formulário
• crm_acess_form_compon - Cadastro de Campos  
   
  
  

Opcional

Protótipo de Tela

Lista de Relatórios

Adição de Relatório

Detalhamento de Relatório - Parâmetros

Detalhamento de Relatório - Cadastro de Parâmetros

Detalhamento de Relatório - Usuários

Relatório Disponíveis

Relatório Disponíveis - Parâmetros

Relatório - Execução Portal

Relatório - Execução Menu HTML

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.