1. Proposta

Realizar uma análise de custo (tempo de desenvolvimento e complexidade) da alteração das seguintes regras de inclusão / retificação de forma individual, ou seja, precisamos do custo de cada item em particular:

1 - Alteração do evento S-2230 para aceitar o indRetif igual a 1 quando o evento não estiver transmitido.

2 - Alteração de todos os eventos para aceitar o indRetif igual a 1 quando os eventos não estiverem transmitidos. (Aceitar indRetif igual a 2, apenas para eventos transmitidos).

3 - Alteração dos eventos de tabela para aceitarem a tag de inclusão somente se o evento não estiver transmitido para o governo, a partir da transmissão uma alteração de um evento sobre uma mesma chave deve ser utilizado a tag de alteração.

2. Descrição

Atualmente, as integrações via XML do TAF estão apresentando inconsistências nos padrões. Alguns eventos seguem as regras do indRetif corretamente, enquanto outros não estão em conformidade com essas regras. É importante garantir que todas as integrações estejam em conformidade com os padrões estabelecidos para evitar problemas futuros. Recomenda-se revisar e ajustar os eventos que não estão respeitando as regras do indRetif, garantindo consistência em todas as integrações via XML do TAF.

3. Novo padrão sugerido

Uma análise técnica foi realizada para abordar a questão dos eventos que estão fora do padrão em relação ao indRetif. A análise teve como objetivo identificar as alterações necessárias para adequar esses eventos aos padrões estabelecidos. Recomenda-se aplicar as alterações propostas para corrigir os eventos que não estão em conformidade e garantir que todos os eventos sigam corretamente as regras do indRetif. Isso ajudará a manter a consistência e a conformidade nas integrações via XML do TAF.

• Cenário atual para eventos Periódicos e Não Periódicos:

No TAF, quando temos um evento que ainda não foi transmitido e realizamos uma alteração via XML com indRetif igual a 2, isso é considerado um erro. O indRetif igual a 2 é utilizado para retificar eventos já transmitidos, ou seja, corrigir informações em eventos que já foram enviados anteriormente. Para eventos que ainda não foram transmitidos, a alteração deve ser feita diretamente no evento original, sem utilizar o indRetif igual a 2.

• Cenário esperado 

Quando um evento no TAF ainda não foi transmitido, o indRetif igual a 1 deve ser utilizado para realizar alterações via XML. O indRetif igual a 1 indica uma inclusão, permitindo adicionar novas informações ou corrigir dados no evento antes de sua transmissão.

Portanto, é importante respeitar essa regra e utilizar o indRetif igual a 1 ao realizar alterações em eventos que ainda não foram transmitidos. Isso garantirá a consistência e conformidade das informações no sistema.

• Cenário Atual para eventos de tabela

Quando se trata de um evento de tabela no TAF que ainda não foi transmitido, realizar a alteração via XML utilizando a tag <alteracao> é considerado um erro.

A tag <alteracao> é utilizada para realizar alterações em eventos já existentes, ou seja, quando se deseja modificar informações em eventos que foram previamente enviados. Para eventos de tabela que ainda não foram transmitidos, é necessário utilizar a tag <inclusao> para inserir as informações desejadas.

• Cenário esperado

Quando um evento de tabela ainda não foi transmitido, a tag correta a ser utilizada é <inclusao>. Essa tag permite a inserção de novas informações ou registros no evento, sem causar conflitos com eventos já existentes. Com a tag <inclusao>, é possível adicionar os dados necessários de forma segura e garantir a consistência dos registros.

Para eventos que já foram transmitidos, é necessário aceitar apenas a tag <alteracao>. Essa tag é utilizada para realizar modificações em eventos previamente enviados, permitindo a atualização de informações específicas. Ao utilizar a tag <alteracao>, garante-se a conformidade com o processo de alteração e evita-se a criação de novos eventos.

4. Especificação de Funcionamento Técnico Atual

• Eventos periódicos e não periódicos

  Dentro da rotina de integração (TAFIntregaEsocial.PRW), na função TafPrepInt, ocorre uma validação para determinar o valor do indRetif e realizar a alteração do valor de nOpc.

  

• Eventos de tabela

Para os eventos de tabela temos a seguinte validação:

5. Proposta de Implementação

• Alteração do evento S-2230 para aceitar o indRetif igual a 1 quando o evento não estiver transmitido. (Aceitar indRetif igual a 2, apenas para eventos transmitidos)

Para o evento S-2230 no cenário utilizando o tafkey como maneira de inclusão já temos um padrão em relação ao indRetif que é representado pela variável nOpc.

 Hoje no ambiente do taf quando realizamos a inclusão com indRetif com o valor '1' o nOpc tende a ser 3 e indRetif com o valor '2' ser nOpc tende a ser 4, logo se realizarmos uma inclusão para se comportar como alteração deveremos mudar o nOpc para 4.

 Para realizar a alteração podemos utilizar a função padrão FTafVlOpe, que valida se a operação pode ser realizada na integração.

Na função TAFregStat iremos realizar a mudança do nOpc de acordo com a regra que foi estabelecida.

Para a implementação da mudança do nOpc funcionar corretamente, deveremos antes da chamada da função FTafVldOpe.

• • • • Eliminar qualquer mudança de nOpc antes da chamada da função FTafVldOpe, assim como validações que impliquem na mudança do mesmo.
      • Consequentemente irá ocorrer alteração na montagem da chave do afastamento, sua busca hoje em alguns cenários está redundante
      •                    
    •            Antes : 
      •  
    •  
      • Depois:
    •          
    •  
      • Melhorar a busca de registros já na base.
      • Eliminar avisos de erro que não são necessários por conta de ser responsabilidade da FTafVldOpe.

Riscos e esforço da implementação

1. 1. 1. 1. Riscos

            1. Erros colaterais.
            2. Quebras no robô por conta do indRetif.
            3. Problemas com cenários já controlados.
            4. Teste de todos os cenários.

         2. Esforço para o evento S-2230:

            1. 2 Semanas de codificação equivalente a 80 horas.
            2. 2 semanas de teste com cenários envolvendo as linhas (geração da tag indRetif com todas as possibilidades do evento de afastamento) equivalente a 80 horas.

• Alteração de todos os eventos para aceitar o indRetif igual a 1 quando os eventos não estiverem transmitidos. (Aceitar indRetif igual a 2, apenas para eventos transmitidos).

Para os demais eventos como maneira de inclusão já temos um padrão em relação ao indRetif que é representado pela variável nOpc.

 Hoje no ambiente do taf quando realizamos a inclusão com indRetif com o valor '1' o nOpc tende a ser 3 e indRetif com o valor '2' ser nOpc tende a ser 4, logo se realizarmos uma inclusão para se comportar como alteração deveremos mudar o nOpc para 4.

 Para realizar a alteração podemos utilizar a função padrão FTafVlOpe, que valida se a operação pode ser realizada na integração.

Na função TAFregStat iremos realizar a mudança do nOpc de acordo com a regra que foi estabelecida.

Para a implementação da mudança do nOpc funcionar corretamente, deveremos antes da chamada da função FTafVldOpe.

• • • • Eliminar qualquer mudança de nOpc antes da chamada da função FTafVldOpe, assim como validações que impliquem na mudança do mesmo.
      • Eliminar avisos de erro que não são necessários por conta de ser responsabilidade da FTafVldOpe.

Riscos e esforço da implementação

1. 1. 1. 1. Riscos

            1. Erros colaterais.
            2. Quebras no robô por conta do indRetif.
            3. Problemas com cenários já controlados.
            4. Teste de todos os cenários.

         2. Esforço para os demais eventos :

            1. 1 Semana de codificação equivalente a 40 horas por evento em separado.
            2. 1 semana de teste com cenários envolvendo as linhas equivalente a 40 horas.

• Alteração dos eventos de tabela para aceitarem a tag de inclusão somente se o evento não estiver transmitido para o governo, a partir da transmissão uma alteração de um evento sobre uma mesma chave deve ser utilizado a tag de alteração. 

Utilizando o evento S-1010 como escopo de trabalho para alteração e levando em conta o comportamento do nOpc para eventos de tabela, quando utilizamos a tag de "<Inclusão>" o nOpc é igual a 3 e "Alteração" igual  a 4, terá que ser realizada as seguintes alterações.

Eliminação da função VldEvTab, hoje temos a validação da FTafVlOpe que pode ser usada de forma genérica eliminando a necessidade de duas funções na mesma rotina.

Utilizar a função padrão FTafVlOpe que valida se a operação pode ser realizada na integração.

Na função TAFregStat iremos realizar a mudança do nOpc de acordo com a regra que foi estabelecida.

 Riscos e esforço da implementação

1. 1. 1. Riscos

         1. Erros colaterais.
         2. Quebras no robô por conta do indRetif.
         3. Problemas com cenários já controlados.
         4. Teste de todos os cenários.

      2. Esforço para eventos de tabela :

         1. 3 dias por fonte equivalente a 24 horas.
         2. 4 dias de teste ( geração da tag de "inclusão e alteração") equivalente a 32 horas.