Histórico da Página
...
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
e alteração de todos os eventos para aceitar o. (Aceitar indRetif igual a
1 quando os eventos não estiverem transmitidos.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.
...
- 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
Riscos
- Erros colaterais.
- Quebras no robô por conta do indRetif.
- Problemas com cenários já controlados.
- Teste de todos os cenários.
Esforço para o evento S-2230:
- 2 Semanas de codificação equivalente a 80 horas.
- 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
Riscos
- Erros colaterais.
- Quebras no robô por conta do indRetif.
- Problemas com cenários já controlados.
- Teste de todos os cenários.
Esforço para os demais eventos :
- 1 Semana de codificação equivalente a 40 horas por evento em separado.
- 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.
...
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
Riscos
- Erros colaterais.
- Quebras no robô por conta do indRetif.
- Problemas com cenários já controlados.
- Teste de todos os
cenários.- 2 Semanas de codificação. 2 semanas de teste com
- cenários
envolvendo as linhas (geração da tag indRetif com todas as possibilidades do evento de afastamento)- .
Esforço para eventos de tabela :
- 3 dias por fonte equivalente a 24 horas.
- 4 dias de teste ( geração da tag de "inclusão e alteração") equivalente a 32 horas.