Histórico da Página
...
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 |
---|
...
Simulação | ||||||||
Cod Programa | Açã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.
| 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 |
---|
-
Para Todas as Situações
Documento Arquivo Clientlog xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Extrato de Versão 12.1.17 Simulação do cliente (sem específicos) View file name Video_1513341759.wmv height 250 -
Performance
Documento Arqvivo Profiler XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Equipe de BD já avaliou a integridade
de índices e fragmentação das tabelas?
Sim/Não -
Integração com outros Sistemas
Documento Arquivo 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. |
...