1. Sugestão

https://www.in.gov.br/en/web/dou/-/portaria-seprt/me-n-4.334-de-15-de-abril-de-2021-314637705

2. Ganhos

3. BIBLIOTECAS JAVASCRIPT

3.1. PDFMAKE 

3.1.1. Sobre (15/08/2022)

Image Removed

Home Page: http://pdfmake.org/#/

Documentação: https://pdfmake.github.io/docs/

Exemplo de uso: https://www.ngdevelop.tech/angular-8-export-to-pdf-using-pdfmake/

3.1.2.1. Prós

• Indicação do Danilo Salvez, sendo usada desde início de 2021 em Projetos do CRM & Faturamento;
• Depoimento do time do CRM & Faturamento de que biblioteca tem atendido a bem a necessidade deles desde a primeira utilização;
• Devido a utilização de matriz simples (similar ao uso de tabela, inclusive com propriedade 'colSpan') para posicionamento dos recursos na área de impressão, abstrai bastante a complexidade do posicionamento em tela;
• Abstração de complexidade de quebras de linhas para textos e quebras de páginas;
• Mínimo suficientemente necessário para atender a demanda com sucesso, similar a uma biblioteca fornecida pelo POUI se esta existisse.

3.1.2.2. Contras

• Números menores do que a biblioteca jsPDF em relação a comunidade, forks e projetos usados;
• Pouca flexibilidade em relação a disposição dos elementos em tela (verificação minuciosa da documentação talvez resolva os poucos casos em que isso acontece).

3.1.3. DEMO

3.1.3.1. MODELO USANDO BIBLIOTECA

Image Removed

Image Removed

https://www.dropbox.com/s/ivx1y3zekordria/example_table_makepdf.pdf?dl=0

3.1.3.2. DENTRO DO PROTHEUS

Integração da biblioteca com a API do Windows chamando a tela padrão de escolha de local para baixar os arquivos pdf.

Image Removed

Image Removed

Gerenciador de downloads em painel suspenso informando o usuário do progresso do download no local anteriormente selecionado.

Image Removed

Image Removed

3.2. JSPDF

3.2.1. Sobre (18/08/2022)

Image Removed

Home Page: https://parall.ax/products/jspdf

Documentação: http://raw.githack.com/MrRio/jsPDF/master/docs/index.html

GIT: https://github.com/parallax/jsPDF

Exemplo de uso: https://medium.com/ekode/gerando-pdf-no-angular-com-jspdf-99ab94df7870

3.2.2.1. Prós

• Indicação do Bruno Romero, do time de FrameWork;
• Melhor integração ao VS CODE, com autocomplete das funcionalidades da biblioteca, o que facilita o desenvolvimento;
• Devido a utilização de posicionamento por pixel dentro da área de impressão, consegue-se alta precisão no posicionamento de elementos, sendo necessário informar as coordenadas de cada item em tela, tanto dos retângulos quanto dos títulos e textos que abrigarão cada campo do formulário da CAT;
• Boa para elaboração de abstrações que disponibilize para o cliente funções que o atendam encapsulando a complexidade.

3.2.2.2. Contras

• O posicionamento por pixel onera o tempo de desenvolvimento e complexidade;
• Muita funcionalidade documentada, porém sem exemplo de uso;
• Quebra de textos e de páginas verbosa e a cargo do desenvolvedor, exigindo elaboração de cálculo e combinação de funções da biblioteca;

3.2.3. DEMO

3.2.3.1. MODELO USANDO BIBLIOTECA

Image Removed

Image Removed

Image Removed

https://www.dropbox.com/s/e0pxinz9dbxw2ag/example_jspdf.pdf?dl=0

3.2.3.2. DENTRO DO PROTHEUS

Integração da biblioteca com a API do Windows chamando a tela padrão de escolha de local para baixar os arquivos pdf.

Image Removed

Image Removed

Gerenciador de downloads em painel suspenso informando o usuário do progresso do download no local anteriormente selecionado.

Image Removed

Image Removed

4. REFINAMENTOS  A FAZER 

• O Modelo de Formulário atualmente no épico da issue da CAT é o presente nos anexos da instrução normativa do governo (https://www.in.gov.br/en/web/dou/-/portaria-seprt/me-n-4.334-de-15-de-abril-de-2021-314637705). É pra ser feita exatamente igual ao modelo ? 
  • MOTIVO DA PERGUNTA: A disposição dos campos nem sempre está adequada. ex.: Campos pequenos ocupando uma linha inteira (campos da seção DADOS DE IDENTIFICAÇÃO) e campos com grande conteúdo em espaços pequenos (campo 49 - NOME DO MÉDICO, CRM E UF);

• Mudar extensão de .PRW para .TLPP (assim conseguimos usar nomes maiores para funções e fontes)
• Dividir os eventos em fontes para cada layout ou Separar funções dentro do próprio fonte (Versões distintas)
• Dividir as automações para cada layout
• Aproveitar a refatoração para criar novos fontes de funções genéricas, onde iremos documentar todas as funções.
• Padronizar as telas dos eventos (Ficou definido que será com os botôes na lateral)
• TafRotinas colocar em uma tabela em vez de deixar no fonte um array (Ex: autocontida) ou Classe / Métodos para o TAFRotinas
• Fazer um exemplo do TLPP, verificar cobertura de teste
• Validar o schema que está integrando do ERP (Utilizando o método do TSS)
• Gerar o XML utilizando o schema de cada layout. (Criação de uma tabela com os eventos, versão e De/Para na estrutra do XML conforme schema)
• Adicionar o painel do trabalhador no cadastro de admissão (S-2200). (PO UI)
• Centralizar as informações de integração. (TAFXINTEG, TAFINTEGRAESOCIAL). Verificar a existência de uma função igual do TafRotinas e a possibilidade de eliminar a função xTafFunLay.
• Padronizar a forma de integração com o TAF (Hoje cada marca manda as informações de uma maneira) - (Esta sendo feito um levantamento junto as marcas para definir um padrão)
• Ao integrar eventos que contenham valores que serão importados para a V3N, mudar a forma de popular a V3N, hoje ele inclui como origem 1 e 2. Podemos mudar para incluir somente a origem 1 e quando tiver somente origem 1 na V3N, mostrar no relatório dados do GPE e TAF iguais.

• DEPOIS:
  • Analisar as transferências de funcionários
  • Ao criar os campos no dicionário, controlar a obrigatoriedade pelo fonte (MVC / PO UI). Levantar um tópico de obrigatoriedade do dicionário
  • Verificar a questão das pastas no dicionário e MVC
  • Criar a consulta específica em PO UI (F3) 

1.1. Sugestão de implantação das mudanças

• Fazer por evento (sugestão para fazer de acordo com os eventos que tiveram alterações no novo layout)
• Funções genéricas que estão sendo utilizadas no evento, colocar em novo fonte tlpp
• Verificar a questão das datas no cadastro e colocar em um padrão todos os campos data dos eventos (Ano - Mês - Dia) e período Ano-Mês-Dia no banco e na visualização Ano-Mês .

 Ex: TAFA253

 TAFA253_PR
 TAFA253_0205
 TAFA253_0100 

2. Prós

• Ao criar novos fontes para fazer a refatoração conseguiremos ganhar tempo e gerar menos problemas para os clientes com relação as mudanças.
• Minimiza os riscos de colaterais, pois estaremos alterando somente o fonte do layout corrente.
• Aumenta performance das rotinas devido a não ter que fazer leitura de linhas referentes aos outros layouts.
• Com alteração para usar um fonte para cada layout não terá necessidade de testar um alteração em todos os layouts.
• Diminui o tempo de rodar automação, pois teremos fontes especificos para cada layout. Hoje esta tudo em somente um fonte o que leva muito tempo para rodar o robô para um evento inteiro
• Quando tiver mais de 1 layout ativo devido ao período de convivência, pode sair ajustes para ambos os layouts, desta maneira podemos ter issues separadas por layout ou pessoas trabalhando com fontes de cada layouts em uma única issue.

3. Contras

• Quando tiver mais de 1 layout ativo devido ao período de convivência, pode sair ajustes para ambos os layouts o que aumenta o tempo e quantidade de alterações
• Dicionário não está preparado para Po UI (Ex: Validação de campo, Consulta padrão, etc) - A engenharia está estudando uma forma de liberar melhorias para o PO UI entender as informações do dicionário
• O MVC (Model-View-Controller) Protheus utiliza o recurso de "StaticCall", portanto as rotinas que possuem MVC não poderão migrar para .tlpp e acessar os novos recursos do TL++, nesse caso mantem esse fonte em .prw (ADVPL). (Está sendo solucionado pelo Frame)

4. Contatos

1. Renato Ito (Financeiro) - Fontes TLPP, benefícios com PO UI e Contras utilizando MVC
2. Nairan (FrameWork) - Sobre o MVC não funcionar com TLPP e a liberação de um lib que será disponibilizada na release 12.1.2310
3. Daniele (NFSE) - Entender o funcionamento do New NFSe e aplicar no eSocial, na questão de validar e gerar XML conforme o schema.

5. Documentações

• TLPP
• Padronização para nomenclaturas no uso do TLPPSerá criado método no backend que traga as informações que faltam para preenchimento do formulário da CAT ou será ajustado método atual ?MOTIVO DA PERGUNTA: Atualmente a API da CAT possui um método GET chamado catValues que traz 14 campos; o formulário da CAT segundo a Instrução Normativa dispõe de 50 campos;