1. Sugestão

...

• 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.
 - DEPOIS: Analisar as transferências de funcionários- 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

 TAFA232

...

_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 TLPP

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);

• Será 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;