Linha de Produto: | Microsiga Protheus | ||||||||||||
Segmento: | Manufatura / Distribuição e Logística | ||||||||||||
Módulo: | SIGAMNT - Manutenção de Ativos com Gestão de Frotas | ||||||||||||
Rotina: |
| ||||||||||||
Cadastros Iniciais: | Para validar a efetividade da presente melhoria, é necessário que o cliente possua em sua base de dados diversos registros de contador, presentes na tabela STP - Ordem de Serviço Acompanhamento.
| ||||||||||||
Chamados Relacionados |
| ||||||||||||
País(es): | Todos. | ||||||||||||
Banco(s) de Dados: | Todos. | ||||||||||||
Tabelas Utilizadas: | STP - Ordem de Serviço de Acompanhamento; STJ - Ordens de Serviço; ST9 - Bens; STZ - Movimentação de Bens; TPN - Utilização de Bens; TQ2 - Histórico de Transferência de Bem TQN - Entrada Manual de Abastecimento; TQB - Solicitações de Serviço | ||||||||||||
Sistema(s) Operacional(is): | Todos. |
Implementado no Manutenção de Ativos (SIGAMNT) a rotina de Acerto/Reprocessamento de Contadores (MNTA876). Esta nova rotina tem por objetivo apoiar os usuários na realização de acerto de contadores, permitindo ter uma visão de todos os registros de contador de Bens com contador próprio, presentes na tabela STP - Ordem de Serviço Acompanhamento.
A rotina permite aos usuários exportar os registros de histórico, sendo todos os registros ou "a partir de data" , também permitindo posteriormente a importação dessas informações no mesmo formato para ajuste e reprocessamento de todo o histórico. O reprocessamento de contador utilizado nesta rotina é destinado a bens de qualquer categoria, desde que tenham contador 1 próprio (T9_TEMCONT = ‘S’).
Os detalhes referente aos processos de exportação e importação do arquivo seguem abaixo:
O processo de exportação de histórico de contador é o primeiro passo para o reprocessamento de contador. Ao selecionar essa opção, é apresentado ao usuário uma lista com todos os bens cadastrados que possuam contador próprio.
A lista é apresentada no formato de markbrowse com os campos de Filial (T9_FILIAL), Código (T9_CODBEM), Nome (T9_NOME), Tipo Modelo (T9_TIPMOD) e sua descrição, Família (T9_CODFAM) e sua descrição. Desta forma é possível realizar a seleção dos Bens cuja a necessidade de realização do acerto de contador. Ao confirmar a tela de seleção, um arquivo .dbf ou .dtc (conforme o ambiente do cliente) é gerado com o histórico de contador dos bens selecionados com os seguintes campos: TP_FILIAL, TP_CODBEM, TP_DTLEITU, TP_HORA, TP_POSCONT, TP_ ACUMCON e TP_TIPOLAN, na ordem apresentada. Os registros são ordenados por TP_CODBEM + TP_DTLEITU + TP_HORA + TP_FILIAL, em ordem crescente e o arquivo é salvo em uma pasta específica no dicionário, no caminho ROOTPATH + STARTPATH + \NG, exemplo: "C:\NGAP118\Protheus_Data\DicP118\NG". Ao final da rotina, é apresentada uma tela para o usuário escolher o nome do arquivo, com o nome padrão no formato NG876STPYYYYMMDDHHMMSS.dtc.
Obs.: Importante ressaltar que o campo de variação dia não é exportado visto que seu valor é consequência do reporte de contador, assim não deve ser informado manualmente. Seu cálculo se baseia na fórmula Variação Dia = (Contador Acumulado Final – Contador Acumulado Inicial) / Diferença de Dias entre reportes) . Da mesma forma o contador acumulado é preenchido automaticamente. Além disso, a informação de contador acumulado só é alterável para o primeiro registro de inclusão do bem, os demais registros serão calculados com base na informação de posição do contador.
Na sequência do processo, o usuário deve realizar a importação do arquivo que foi exportado para adequação do histórico de todos os bens, através da mesma rotina MNTA876. O usuário tem a possibilidade de alterar ou excluir os registros existentes no histórico e também de incluir novos registros, através de uma interface em getdados, que é apresentada logo após a seleção do arquivo gerado na exportação. Após selecionar o arquivo para importação, finalizar a edição deste arquivo e confirmar no botão OK, é realizada a leitura dos registros alterados em tela, gravando-os em uma tabela temporária, no mesmo formato do arquivo exportado, de forma ordenada por TP_CODBEM + TP_DTLEITU + TP_HORA + TP_FILIAL. Além disso, é efetuado um backup da tabela STP, filtrando os bens contidos no arquivo importado. O backup é salvo no mesmo diretório ROOTPATH + STARTPATH + \NG + \backup, com o formato STPXX0_YYYYMMDDHHMMSS_backup.dbf, sendo YYYYMMDD e HHMMSS substituídos pela data e hora do processamento.
No processo de importação é possível ainda, determinar alguns parâmetros para validação, determinando assim o comportamento da rotina durante a validação de Variação Dia, de Contador do bem e referente ao Eixo Suspenso para veículos. Existem três comportamentos determinados para o caso de ser encontrado um registro com erro na Variação dia ou no seu contador:
Para os casos de validação verificando o Eixo Suspenso:
2.1 Validação inicial
A validação dos registros lidos consiste inicialmente na verificação da existência de um registro único e inicial do tipo “Inclusão” (TP_TIPOLAN = ‘I’), na base (tabela STP), para cada filial em que o bem esteve presente. A rotina então varre as tabelas relacionadas ao histórico de contador, buscando registros com a mesma chave de BEM + DATA + HORA na tabela STP. Caso não encontre algum registro, apresenta um log ao usuário (com opção de imprimir), permitindo retornar à tela de ajuste para inclusão dos novos registros, sem abortar o reprocessamento. Na sequência, cada registro do histórico é excluído, sem passar por validações de exclusão padrão, visto que os relacionamentos citados anteriormente iriam impedir o processo de exclusão.
2.2 Validação Secundária
Já estando ordenado por TP_CODBEM + TP_DTLEITU + TP_HORA, o reprocessamento consiste em executar as funções de validação padrão para cada registro individualmente. Após validar o registro, a rotina irá seguir com sua gravação.
Importante considerar que o primeiro registro do histórico, por ser do tipo de “inclusão” segue a regra existente na inclusão e na transferência do bem, já os demais registros do tipo “C - Contador”, “A- Abastecimento”, "Q - Quebra", "V - Virada" ou "P - seguem a regra de reporte pelo fluxo de funções:
O fluxo de validação é padrão e foi baseado na classe NGMovBem, onde as validações reaproveitam funções e fluxos já existentes no padrão, evitando a criação de novas funções.
Registros do tipo Quebra e Virada, seguem as respectivas validações de quebra e virada realizadas pela rotina MNTA840 (quebra) e MNTA835 (Ações Relacionadas / Virada). Em nenhum momento é realizada quebra ou virada de forma automática durante esse processamento, somente quando o registro for do tipo V ou Q (ou ainda quando do tipo P). Um registro de abastecimento, por exemplo, não realiza virada automática.
Havendo alguma inconformidade o processo é abortado. As informações são apresentadas no final, em um log.
Em situação de exceção, no caso de uma inconformidade resultante das validações realizadas, não somente o histórico da tabela STP é restaurado como também os valores das tabelas relacionadas que foram alteradas.
2.3 Observações gerais:
A gravação de cada registro de histórico ocorre de forma individual e após a conclusão da etapa de validação, utilizando a função que gera registro de histórico, padrão do sistema.
Na gravação do registro da STP os campos TP_DTORIGI, TP_DTREAL e TP_USULEI são alterados para a data em que a rotina está sendo executada e para o código do usuário que está logado.
Para cada registro gravado, havendo algum relacionamento com outras tabelas, o registro da outra tabela também tem seu valor atualizado, obedecendo a regra da respectiva tabela em que se vai realizar a posição do contador, e desde que, certamente, o valor atual tenha sofrido alguma alteração em relação ao histórico. Por exemplo, ao identificar um registro na STP para data X + hora Y, havendo o mesmo registro na TQN (abastecimento), essa tabela será atualizada.
As etapas de validação são realizadas bem a bem, inicialmente validando o bem e depois reprocessando seu histórico. Um próximo bem só pode ser validado e reprocessado quando o processamento do bem anterior for concluído. As validações então são feitas em duas etapas, apresentadas a seguir.
Antes de executar o compatibilizador UPDMNTC6 é imprescindível:
Atenção O procedimento a seguir deve ser realizado por um profissional qualificado como Administrador de Banco de Dados (DBA) ou equivalente! A ativação indevida da Integridade Referencial pode alterar drasticamente o relacionamento entre tabelas no banco de dados. Portanto, antes de utilizá-la, observe atentamente os procedimentos a seguir:
Contate o Help Desk Framework EM CASO DE DÚVIDAS! |
---|
Aplicar atualização dos programas: NGUTIL04.PRX, MNTA840.PRX, MNTA875.PRX, MNTA876.PRW, MNTA877.PRW e NGUTIL04.PRX.
Para viabilizar essa melhoria, é necessário aplicar o pacote de atualizações (Patch) deste chamado.
O sistema é atualizado logo após a aplicação do pacote de atualizações (Patch) deste chamado.
Nome da Variável | MV_NGPERCV |
Tipo | Caracter |
Descrição | Habilita ou Desabilita o Histórico dos Indicadores 0=Desabilita ; 1=Histórico Resumido; 2=Histórico Completo (oneroso) |
Valor Padrão | 1 |