ISSUE: DAGROOGP-670 - Romaneio do Tipo 4 Não Confirma
TRANSFERÊNCIA PARA MANUTENÇÃO |
---|
Informe o código do item escolhido do check list: | 03 |
Situação Reproduzida Internamente?
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: Foi verificado 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 cliente para que fosse disponibilizada a opção de Debugg, foi solicitado para que eles aplicassem o dicionário diferencial no ambinte e rodassem o UPDDISTR, pois a tabela NJ5 não existia no ambiente do cliente. Foi realizado o procedimento, mas ainda assim o Romaneio não estava confirmando. 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 realizada 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 verificado 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 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 resolvido. |
Medida Paliativa? | NÃO |
---|
Patch Recomendável? * | NÃO |
---|
Simulação | ||
Cod Programa | Ação | |
OGA250 | → Cadastrar um Romaneio com Pesagem do tipo 4 - Saída por Venda. Atualizar o registro. Tentar a confirmação.
|
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) |
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 |
Informações Adicionais |
As 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. |
Análise Cadastro Exceção |
Foi necessário cadastro do chamado no GOLD para NÃO ser liberado ao término da FNC?
|
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) |
|