Tempo aproximado para leitura: 00:02:00 min
Ocorrência
Durante o processamento da jornada de fechamento, ocorre o HELP MA280DTFEC ja ultima etapa da jornada, a etapa que vai virar os saldos para SB9, oque fazer?
Documentação destinada ao time TECNICO (TI) do cliente.
Ambiente
Cross Segmento - TOTVS Backoffice (Linha Protheus) - Estoque/Custos - Apartir da Release 12.1.33.
Causa
Ja existe uma data gravada com a qual você esta tentando virar os saldos na tabela SB9, isso normalmente ocorre devido a manipulação indevida de registros na SB9 ou parametro MV_ULMES, Ou se o parametro MV_ULMES, esteja configurado de forma exclusiva para cada FILIAL, caso existe um parametro compartilhado, cujo a data estava diferente do ultimo fechamento gravado, isso pode ter gerado o impacto na ultima etapa, a sugestão aqui é 1 parametro para cada filial nesse contexto.
Solução
Requer uma analise tecnica.
Primeiro ponto, sempre certificar que esteja nas ultimas atualizações:
- Acumulado BackOffice conforme sua versão
- LIB Atual - Logo Guará | Harpia
- Appserver
- Smartclient - Lobo Guará | Harpia
- DBAccess
- Central de Atualizações
Aqui estamos representando o problema, cujo foi feita alteração indevida no parametro MV_ULMES de forma proposital, onde ja possuiamos o fechamento gravado em 20250731, e propositalmente, configuramos o parametro MV_ULMES com data de 20270701 ou seja, menor que a data de fechamento.
Ao iniciarmos o processamento, e chegarmos ao final da virada de saldos, sera apresentado o HELP em questão.
Abaixo do HELP tera o botão "Corrigir Fechamento".
Quando voce aciona esse botão sera apresentado a seguinte tela:
Ou seja, houve algum comportamento não esperado pelo sistema, e devera ser ajustado in loco, pois a validação desse HELP é verificar a gravação da SB9 com a data a qual você quer realizar o fechamento.
Dessa forma, certifique-se da existencia de registros na tabela SB9, para a filial em questão que aponta o erro, da existencia de dados ja gravados com a data do periodo cujo você esta tentando virar os saldos, e ajuste IN LOCO se necessario.
Observações:
Não foi efetuado manipulação no SB9 ou parametro MV_ULMES, mas mesmo assim o HELP ocorre?
Se acaso você tenha certeza de que não houve manipulação de dados, e o processo de fechamento por ventura, gravou os saldos na SB9 e atualizou o parametro MV_ULMES devidamente para esse periodo que esta efetuando o calculo, mas por algum motivo esteja apresentado a inconsistencia no final do processamento, e ja tenha gravado dados na SB9, sugerimos que seja abortado o fechamento com erro em tela.
Em BASE TESTE/HOMOLOGAÇÃO valide o seguinte:
- Certifique que o parametro MV_ULMES esteja devidamente com a data gravada da ultima SB9 da filial
- Consulte o arquivo D3Y/D3W do log de processamento, onde o log com o HELP vai estar da seguinte forma:
Não possuimos um time de TI para executar essa ação, e todo o processo foi feito no padrão:
Se acaso você tenha certeza de que não houve manipulação de dados, e o processo de fechamento por ventura, gravou os saldos na SB9 e atualizou o parametro MV_ULMES devidamente para esse periodo que esta efetuando o calculo, mas por algum motivo esteja apresentado a inconsistencia no final do processamento, ou esteja em aberto, e ja tenha gravado dados na SB9,
Sugerimos que seja contatado um ANALISTA IN LOCO para ajustes internos caso necessario.
QUANDO OS DADOS FORAM GRAVADOS NAS TABELAS SB9, SBJ e SBK MAS A ROTINA FICA EM PROCESSAMENTO:
Atualize o parametro MV_ULMES para DATA DO B9 dessa filial que foi fechada, caso ele não esteja atualizado com a ultima data da SB9, pois ja consta a SB9 pois se ja existe SB9 então o fechamento foi realizado
"No arquivo log D3Y, atualize os campos da ultima sessão em aberto desse fechamento para:
D3Y_POSITI para T
D3Y_DATAFN para a data do fechamento em questão que existe na SB9
D3Y_STATUS para FN
"
Reinicie os serviços (appserver)
Acesse novamente a rotina acompanha custos, e valide se foi gravado como concluido.
0 Comentários