ISSUE: - Romaneio do Tipo 4 Não Confirma


Não Conformidade - No Zendesk usar o tipo de ISSUE igual a 'Manutenção'
01Erros / bugs em geral.
02Erros no tratamento de uma legislação no produto: a legislação cita uma coisa e o produto faz outra.
03O produto se propõe a fazer algo e faz diferente do que se propõe.
04Erros inseridos em projetos de inovação, que não sejam falhas grandes na concepção do projeto.
05Correção de erro que requer de alteração de dicionário.
06Problemas de Performance.
07Alteração de documentações de programas, bo’s e help on-line.
08Correções e melhorias de mensagens que podem gerar inconsistência na base de dados ou entendimento duvidoso ou conteúdo incompleto.
09Acerto de base quando tem a simulação do problema gerado pelo produto padrão.
Sugestão de Melhoria - No Zendesk usar o tipo de ISSUE igual a 'Melhoria'
30Melhorias do produto que não impedem a utilização do produto e não geram problemas na base de dados do cliente.
31Solicitação de implementação de algo que já existe no produto, porém o cliente deseja que seja de outra forma.
32GAPs de desenvolvimento. Ex: o projeto tratou as notas de saída, mas não tratou as devoluções dessas notas. Não  considerou alguma integração, ou alteração em um programa similar.
33Situações que não faziam parte do escopo (ex: uma integração, uma importação, etc. ) e o cliente solicita que deve ser considerado.
34Automatização de  algum processo.
35Mudança de conceito de produto.
36Criação de documentações de programas e bo’s e help on-line.
37Cliente Piloto
38

Solicitação de fontes não liberados (quando o cliente solicitar um fonte que não está liberado, o chamado deve ser encaminhado para Inovação avaliar em conjunto com a manutenção)

Solicitação de Legislação - No Zendesk usar o tipo de ISSUE igual a 'Legislação'
50Desenvolvimento de novas Legislações.
51Alterações em legislações vigentes.
52

Implementação de regras de negócio  que são oriundas de legislações, exemplo:

  • Tratamento de Impostos;
  • Obrigação fiscal / arquivo a entregar ao governo/fisco;
  • Um processo do produto que possui regra de legislação e esta regra foi alterada por meio de legislação, emenda constitucional, ato cotepe.
53Melhorias em desenvolvimentos de 'Legislação', utilizando o mesmo processo de 'Melhorias'. 
Equipe de ATENDIMENTO
80O atendimento deve deixar claro para o cliente que as melhorias e legislações serão feitas somente no último pacote. Versões/produtos descontinuados/expirados não serão considerados. (pode entrar em conflito com o discurso do atendimento onde é informado que alguns desenvolvimentos são liberados duas releases anteriores.)
81Quando o produto atende uma solicitação do cliente de uma outra forma, o suporte precisa enfatizar que o produto já trata a solicitação. Caso o cliente insista, categorizar como Melhoria. Ex.: Atende de forma manual mas o cliente quer algo automatizado.
82

Cliente parado . O suporte, se necessário, buscará apoio na squad de desenvolvimento para  restabelecer a operação do cliente. Posteriormente deverá ser ajustada a prioridade do ticket para um menor para que seja dada a solução definitiva. Caso não haja paliativos mesmo com o apoio do desenvolvimento, não poderá ser ajustada a prioridade do ticket.

83

O atendimento deve evidenciar a não conformidade do cliente, simulando o reportado internamente. Ou quando não for possivel evidenciar a ISSUE, a mesma deve encaminhada para a manutenção com o check-list de item não simulado preenchido e com os anexos necessários para analises.



TRANSFERÊNCIA PARA MANUTENÇÃO
Informe o código do item escolhido do check list:03



Informações Base
Versão Cliente:

12.1.17

Banco:

SQL


Versão Interna:12.1.17



Origem da situação

 


Situação

O problema inicial da abertura do ticket é o de que ao tentar "Confirmar" um Romaneio do tipo 4 - Saída por Venda, é gerado o Pedido de Venda, porém o Status do Romaneio permanece o mesmo.

Foi enviado pacote com a rotina OGA250 - Romaneio com Pesagem - atualizada, mas não funcionou.

Em seguida foi solicitado para que o cliente deixasse o parâmetro MV_OG250FE com o conteúdo falso e fizesse novos testes, primeiro atualizando o registro para depois realizar a tentativa de confirmação. Não resolveu.

Depois foi solicitado para que fosse realizada a atualização da LIB, DBACCESS e novamente do OGA250, pois foi verificado que a atualização não havia sido feita. Após a atualização de fato ser realizada, passou a ser exibida a mensagem abaixo:

Verifiquei então que a mensagem ocorria por causa de uma função que provavelmente não estava atualizada no ambiente do cliente. Após verificação dos fontes relacionados à função exibida na mensagem, foi enviado um pacote contendo as rotinas: AGRXFUN01 (28/11), AGRUTIL01 (28/11) e OGX010 (20/09). A mensagem deixou de ser exibida após a aplicação do pacote, porém o Romaneio ainda não estava confirmando.

Foram passados os dados para o acesso à base do Cliente para a realização de um Debugg a fim de descobrir o problema. O cliente é Cloud e enquanto a equipe do Cloud realizava os procedimentos no ambiente do clientes para que fosse disponibilizada a opção de Debugg, solicitei para que eles aplicassem o dicionário diferencial no ambinte e rodassem o UPDDISTR, pois a tabela NJ5 não existia no ambiente deles. Foi realizado o procedimento, mas ainda assim o Romaneio não era confirmado.

Na realização do Debugg, com o apoio da equipe de desenvolvimento foi verificado que o problema estava ocorrendo porque o campo do Código do Romaneio não estava sendo preenchido. Foi acessado então o APSDU do ambiente do cliente e realizad uma análise nos campos "CODROM" de todas as tabelas envolvidas. Os campos DXL_CODROM, DX0_CODROM, SD2_CODROM, DXK_CODROM e NPI_CODROM estavam com tamanho "6", sendo consequentemente alterados para o tamanho "10". Mesmo com essa alteração o Problema não foi solucionado.

Após isso, foi verificao que a tabela SC6 não estava assinalada como "usada" em todos os módulos. Foi então realizada essa alteração e a partir daí o romaneio passou a ser confirmado, porém, com a necessidade de clicar "2" vezes na ação relacioanda "Confirmar", e com isso passaram a ser gerados "2" Pedidos de Venda, um em cada vez que o "Confirmar" é executado. Algo impor

Solução
Ajustar a rotina OGA200 - Reservas, para que ao tentar gerar uma reserva, o sistema permita.
Medida Paliativa?NÃO
Patch Recomendável? *NÃO
* Quando marcar esta opção?
Por exemplo: produto liberado com erro que gera inconsistência na base do cliente, manutenções em rotinas críticas, situação que afeta um volume considerável de clientes, etc.  


Simulação
Cod ProgramaAção
OGA380

 → Cadastrar um Modelo de Contrato.

OGA250

→ Cadastrar um romaneio sem informar nenhum contrato.

Dessa forma será gerado automaticamente um contrato.

OGA200→ Gerar uma reserva para o contrato criado automaticamente. O sistema não irá permitir e exibirá um alerta informando que o saldo da reserva ultrapassa o saldo disponível do contrato.




Informações para Situações não Simulada


Informações Adicionais
Conforme alinhamento com o desenvolvimento, foi realizada uma análise no fonte e foi constatado que falta uma regra de negócio. Portanto, esse ticket será enviado para a manutenção conforme orientação da equipe de desenvolvimento.



Observações Manutenção
Espaço destinado para a manutenção adicionar complementos ao chamado.

Análise Cadastro Exceção

Foi necessário cadastro do chamado no GOLD para NÃO ser liberado ao término da FNC?

  • Sim
  • Não

Evidência da Manutenção

ANTES da alteração


DEPOIS da alteração


Log do White-Box


Diretório com o pacote compilado (apenas para o legado)

 

Log Compilação (apenas para o legado)