Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

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

importante que foi verificado, é que na primeira vez que clica em "Confirmar", o campo NJM_PEDIDO não é preenchido.

Solução
Descobrir o que está ocorrendo, para que o problema do cliente seja resolvidoAjustar a rotina OGA200 - Reservas, para que ao tentar gerar uma reserva, o sistema permita.
Medida Paliativa?NÃO
Patch Recomendável? *NÃO

...

→ 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
Simulação
Cod ProgramaAção
OGA380OGA250

 → Cadastrar um Modelo de Contrato.

OGA250

→ Cadastrar um romaneio sem informar nenhum contrato.

Dessa forma será gerado automaticamente um contrato.

Romaneio com Pesagem do tipo 4 - Saída por Venda. Atualizar o registro. Tentar a confirmação.

Informações
titleImportante:

O problema ocorre apenas no ambiente do cliente MASUTTI. Passarei, via e-mail, os dados para o acesso à base, ao desenvolvedor que ficará responsável pelo ajuste

OGA200

.



...


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

  •  

    Para Todas as Situações

    DocumentoArquivo
    Clientlogxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    Extrato de Versão12.1.17
    Simulação do cliente (sem específicos)

    View file
    nameVideo_1513341759.wmv
    height250
    Image Removed

  •  

    Performance

    DocumentoArqvivo
    ProfilerXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Equipe de BD já avaliou a integridade

    de índices e fragmentação das tabelas?

    Sim/Não



  •  

    Integração com outros Sistemas

    DocumentoArquivo
    Link do ticket

    https://totvssuporte.zendesk.com/agent/tickets/15008881723617



...


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 desenvolvimentoAs tentativas possíveis de serem realizadas pelo atendimento foram feitas, por isso esse ticket está sendo enviado para que o desenvolvimento realize uma análise mais minuciosa. Estou à disposição para quaisquer dúvidas.


...


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

...