Páginas filhas
  • TOTVS Gestão de Ativos - BackofficeRM x ProtheusSigaMNT - EAI 1.0

Versões comparadas

Chave

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

...

Tipo de Fluxo: RM -> Protheus e Protheus -> RM
Mensagem: MaintenanceOrder
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/25P6E

 

 

...

Âncora
Restrições e Pontos de Atenção

...

Restrições e Pontos de Atenção

Expandir
titleRestrições e Pontos de Atenção (Clique aqui)

 

  • Carga Inicial de dados e migração de bases RM Officina para SigaMNT
    Não faz parte do escopo da integração efetuar carga Inicial de dados ou migração de bases RM Officina para SigaMNT, ficando a cargo da implantação efetuar este serviço.

  • Manutenção da sincronia das bases BackOffice RM e SigaMNT
    Caso sejam efetuadas alterações por meios diferentes dos objetos de negócio apresentados na seção de cadastros como gatilhos de integração, as mesmas não serão encaminhadas ao SigaMNT, gerando incoerência entre as bases de dados. Um exemplo de alterações que gerariam esta incoerência é sistemas terceiros que efetuem alteração diretamente na base de dados, sem passar pelos objetos de negócio da linha RM.

    Visando facilitar a manutenção da sincronia das bases de dados, está disponível na pasta de objetos de negócio (“../CorporeRM/Objetos Gerenciais/Formulas Visuais”) arquivo “MOVWKF0019 - Sincronizacao_Total_SigaMNT.TotvsWF” com fórmulas visuais responsáveis por manter a base SigaMNT atualizada, que podem ser agendadas com a recorrência demandada pelo cliente.
    Estas fórmulas visuais vêm com configuração padrão, mas podem ser customizadas da forma que melhor atender ao cliente. Um exemplo de customização seria a alteração das mesmas para sincronizar somente os registros da coligada corrente no momento do agendamento, ou somente enviar os registros que possuam um campo específico com um valor específico.

  • Criação de novos tipos de relacionamento (TMOVRELAC-TIPORELAC)
    Caso seja criado algum tipo de cópia por referência que não seja de relacionamento invertido, a constante “TiposRelacNaoInvertida” existente dentro da Extension da mensagem “StockTurnover” e da atividade de fórmula visual “MovInfoParcelaSigaMNT” deve ser alterada, adicionando o novo valor.
  • Configuração do comportamento do tipos de movimento
    Fica a cargo da equipe de implantação fazer a configuração dos tipos de movimento, devendo somente se ater aos requisitos mínimos descritos da sessão Parâmetros de Tipo de Movimento.
    Algumas configurações, como série do movimento e controle de estoque, são críticas para o perfeito funcionamento do gerenciamento de estoque.
  • O configurador da integração não faz atualizações
    Devido a restrições no configurador das integrações o mesmo funcionará somente para a primeira instalação ou para inserção de novas entidades, visto que o mesmo não faz atualização de registros, somente inserção.
  • Apropriação de custos não relacionados a OS
    Não faz parte do escopo inicial o envio da apropriação de custos externos a OS ou ao custo de utilização de material, como pagamento de IPVA, seguro, depreciação e outros, mesmo que a mensagem “AppointmentCost” contemple estes.
  • Mapa de Alocação de Equipamentos
    Não faz parte do escopo inicial o envio do planejamento do Solum quanto a alocação de Equipamentos.
  • Informações referentes aos cadastros de Municipio, Estado e País
    Não faz parte do escopo da integração efetuar carga de dados referentes ao Municipio, Estado e País, ficando a cargo da implantação sincronizar estes dados e seu respectivo De-Para.
  • Integração com TOP
    Pelo entendimento de que não era utilizada e pela nova estrutura do SigaMNT foi descontinuada a integração do TOP com o Officina.
  • Caracteres especiais na mensagem única
    O EAI de mensagem única utiliza o EncodeUTF8 no envio das mensagens. O Protheus não considera os seguintes códigos da tabela ASCII que são: ASCII 129, ASCII 141, ASCII 143 , ASCII 144 e ASCII 157. Maiores informações podem ser obtidas através do link: http://tdn.totvs.com.br/display/tec/EncodeUTF8
  • Cadastro de Cliente/Fornecedor (CustomerVendor)
    Uma vez que já foi feito consenso que Cliente e Fornecedor são tratados na mesma mensagem (CustomerVendor), é responsabilidade do destinatário processar a mensagem da melhor forma possível para garantir a consistência dos dados na origem e no destino. Se o destino implementa uma única tabela, terá que manipular apenas um registro. Se implementa mais de uma tabela, tem que manipular até 2 registros.
    Exemplo1: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Customer<Type>…
       Como não dá para saber se este Cliente (<Type>Customer) é uma inclusão ou uma alteração (<Event>upsert), tem que verificar no de/para.
           Se o EAI destino é capaz de cadastrar um único registro como ambos: deve verificar se já existe um registro com este ID, caso afirmativo fazer alteração deste registro para Cliente e alterar os demais campos, senão fazer inclusão.
           Se o EAI destino NÃO é capaz de cadastrar um único registro como ambos: primeiro deve verificar se já existe um Fornecedor com este ID, caso afirmativo deve tentar excluir este Fornecedor (não conseguindo gerar uma exceção semelhante a “o código xx já é          um fornecedor não pode ser excluído/alterado para tipo cliente.”). Segundo, deve verificar se já existe um registro de Cliente com este ID, caso afirmativo fazer alteração dos demais campos, senão fazer inclusão.
    Exemplo 2: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Both<Type>…
           Se o EAI destino é capaz de cadastrar um único registro como ambos, deve verificar se o ID já existe para definir se faz alteração ou inclusão.
           Se o EAI destino tem 2 tabelas distintas, deve incluir/alterar um Cliente. E ainda incluir/alterar um fornecedor.

 

 

...

Carga Inicial de dados e migração de bases RM Officina para SigaMNT
Não faz parte do escopo da integração efetuar carga Inicial de dados ou migração de bases RM Officina para SigaMNT, ficando a cargo da implantação efetuar este serviço.

...

  • .

...

Visando facilitar a manutenção da sincronia das bases de dados, está disponível na pasta de objetos de negócio (“../CorporeRM/Objetos Gerenciais/Formulas Visuais”) arquivo “MOVWKF0019 - Sincronizacao_Total_SigaMNT.TotvsWF” com fórmulas visuais responsáveis por manter a base SigaMNT atualizada, que podem ser agendadas com a recorrência demandada pelo cliente.
Estas fórmulas visuais vêm com configuração padrão, mas podem ser customizadas da forma que melhor atender ao cliente. Um exemplo de customização seria a alteração das mesmas para sincronizar somente os registros da coligada corrente no momento do agendamento, ou somente enviar os registros que possuam um campo específico com um valor específico.

...

Uma vez que já foi feito consenso que Cliente e Fornecedor são tratados na mesma mensagem (CustomerVendor), é responsabilidade do destinatário processar a mensagem da melhor forma possível para garantir a consistência dos dados na origem e no destino. Se o destino implementa uma única tabela, terá que manipular apenas um registro. Se implementa mais de uma tabela, tem que manipular até 2 registros.
Exemplo1: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Customer<Type>…
   Como não dá para saber se este Cliente (<Type>Customer) é uma inclusão ou uma alteração (<Event>upsert), tem que verificar no de/para.
       Se o EAI destino é capaz de cadastrar um único registro como ambos: deve verificar se já existe um registro com este ID, caso afirmativo fazer alteração deste registro para Cliente e alterar os demais campos, senão fazer inclusão.
       Se o EAI destino NÃO é capaz de cadastrar um único registro como ambos: primeiro deve verificar se já existe um Fornecedor com este ID, caso afirmativo deve tentar excluir este Fornecedor (não conseguindo gerar uma exceção semelhante a “o código xx já é          um fornecedor não pode ser excluído/alterado para tipo cliente.”). Segundo, deve verificar se já existe um registro de Cliente com este ID, caso afirmativo fazer alteração dos demais campos, senão fazer inclusão.
Exemplo 2: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Both<Type>…
       Se o EAI destino é capaz de cadastrar um único registro como ambos, deve verificar se o ID já existe para definir se faz alteração ou inclusão.
       Se o EAI destino tem 2 tabelas distintas, deve incluir/alterar um Cliente. E ainda incluir/alterar um fornecedor.

 

...

Expandir
titleGAPs Funcionais e Pontos de Atenção MNT x Officina (Clique aqui)

 

  • Ordem de Serviço para Terceiros

        O MNT já fornece recursos para a inclusão e controle de ordens de serviço de terceiros. Entretanto, a funcionalidade deve ser incrementada no MNT para que possa atender o processo da mesma forma que faz o RM Officina.

        O que Falta Implementar:

  1. Inclusão de dois campos na tabela de ordens de serviço: Fornecedor/Loja. Esses campos são utilizados no conceito de prestador de serviços. O campo de “fornecedor” serve para indicar que a OS está sendo executada em um terceiro. Para abrir esse campo, o campo “terceiro” deve estar como “sim”.
  2. O reporte de insumo “terceiro” via NF de entrada deve ser contemplada pelo BackOffice (estoque/compras) para que se apliquem insumos terceiros com custo no MNT. É o mesmo processo de aplicação direta como é feito para produtos.
  3. Incluir no cadastro de manutenção um campo “terceiro” -> sim/não e código/loja do fornecedor para quando esse campo for “sim”. Dessa forma podem ser geradas ordens de serviço preventivas para terceiros através do plano.
  4. No retorno de OS criar regra para impedir o reporte de insumos de mão-de-obra em ordens de serviço de terceiros. O RM não controla mão-de-obra em OS de terceiros.
  5. Para contemplar NF de Remessa, deve ser criada mensagem única de Pedido de Venda para integração com o financeiro do backoffice. O pedido de venda gera uma NF de Remessa. Criar campo NF terceiro para gravar o código do Pedido de Venda gerado.

 

  • Contrato de Manutenção de Terceiros

    O SIGAMNT possui cadastro de contratos e utiliza desse recurso para contratos de mão-de-obra. O objetivo é manter esta funcionalidade e aprimorá-la de modo a atender também contratos de prestação de serviço. Para isso algumas alterações serão necessárias tanto no Protheus quanto no RM.

         O que Falta Implementar:

  1. Atualizar a descrição da tabela TP3 para “contratos de manutenção” e adicionar os seguintes campos na tabela:
    Tipo de contrato (1=mao-de-obra;2=prestador)  - (No caso de contrato de mão-de-obra, abrem-se os campos de fornecedor/loja. Quando for contrato de prestador abrem-se os campos cliente/loja.)
    Cliente e Loja (F3 para a tabela de clientes)
    Data inclusão (preenchimento automático com a data atual, na inclusão)
    Dt. Vigência início
    Dt. Vigência fim (Para a versão atual o sistema não deve permitir informar a data de vigência fim em branco.)
    Valor Contrato
    Valor Consumido
    Contrato Compras/Faturamento: na versão atual o campo fica aberto para digitação. Fica pendente a criação de uma mensagem única para contratos e as adaptações necessárias entre o MNT Protheus e o RM.

  2. Criar tabela para listar os equipamentos atendidos pelo contrato. Para isso se sugere os seguintes campos:
    Filial
    Número do Contrato
    Bem (ST9)

  3. Criar tabela para listar os tipos de manutenção a serem atendidas pelo contrato. Para isso se sugere os seguintes campos:
    Filial
    Número do Contrato
    Tipo de Manutenção (STE)

  4. Incluir na tabela de ordens de serviço um campo chamado “contrato” em que seja possível vincular a OS com um contrato de manutenção.

  5. Desenvolver rotina para manutenção do cadastro de contratos baseado no layout sugerido. Esta rotina, no browse, deve conter uma opção de visualizar ordens de serviço do contrato. Ao clicar, o usuário terá uma consulta das ordens de serviço associadas ao contrato selecionado.

  6. Desenvolver opção de impressão de contrato e seus equipamentos, atendimentos, solicitações e ordens de serviço (vinculado ao item de agendamento). Permitir a impressão através da rotina de contratos (para o contrato selecionado) e também através do menu, caso plausível. Esse relatório deve ter um foco maior em custos.

  7. Na abertura de ordens de serviço, seja corretiva ou preventiva, o sistema deve realizar o seguinte procedimento:
    a. Verificar se o bem da OS é um bem de prestação de serviço;
    b. Procurar um contrato para o cliente/loja do bem e para a data de vigência atual e que atenda o bem e os tipos de serviço do contrato.
         i. Caso encontre mais de um contrato o sistema mostra uma tela e permite a seleção do contrato a ser relacionado.
         ii. Se houver apenas um contrato, o sistema então informa ao usuário e solicita se deseja que a OS seja contabilizada para esse contrato. Não é obrigatório que se utilize o contrato na OS.
    c. Na finalização de OS, os custos da ordem de serviço devem ser debitados do contrato, acrescidos no campo “valor consumido”. Um alerta deve indicar caso não haja saldo no contrato, solicitando se o usuário deseja realmente confirmar.


  • Abertura de Atendimento[SIGAMMNT]

Há alguns gaps relacionados a este item. Abaixo um texto do que teria que ser implementado.

O que Falta Implementar:

  1. Envio de e-mail para o Cliente com dados do atendimento. Este envio de e-mail deve ser enviado somente quando o atendimento for solucionado.
  2. Integração de Atendimento com ECM.

Para contrato de venda:

O MNT já fornece os recursos necessários para atender esse processo. Trata-se do cadastro do equipamento na rotina de bens e abertura de SS/OS informando serviço de instalação. Dependendo do processo da empresa o MNT também permite que se abra um atendimento e a partir dele se gere uma SS e ainda, se necessário, uma OS.

  1. Necessidade de relatório listando atendimentos por equipamento e por cliente/fornecedor, listando também SS’s e OS’s relacionadas.

 

  • Agendamento

O que Falta Implementar:

Conforme descrição do processo do RM tem-se que:
Realizar o tratamento referente ao parâmetro de sistema “Agendamento na abertura de OS Obrigatório”. Quando parametrizado desta forma é permitido gerar Ordem de Serviço (normal e terceiros) somente a partir de um agendamento.

 

 

  • Instalação (Alocação) de Objetos[SIGAMNT]

Tendo em vista que o conceito da regra de negócio do Officina consiste em registrar o local em que determinado equipamento foi instalado, seu rastreamento e controle de manutenções, entende-se que o cadastro de bens do MNT atenderia essa necessidade através da inclusão de alguns campos complementares.

O que Falta Implementar:

No cadastro de bens, para identificar um objeto de manutenção alocado devem ser preenchidos os seguintes campos:

  1. Centro de Custo (T9_CCUSTO) com uma formatação específica, de modo a considerar como parte do código o cliente e loja, por exemplo:
    XXXXXXYYZ[n]
    Sendo:
    XXXXXX o código do cliente (T9_CLIENTE)
    YY a loja do cliente (T9_LOJACLI)
    Z[n] o local de instalação, ou centro de custo.

  2. Cliente (T9_CLIENTE)
  3. Loja Cliente (T9_LOJACLI)
  4. Data Instalação (T9_DTINSTA)
  5. Instalação (T9_INSTALA)* (1=Local;2=Cliente) – informa se a instalação é própria ou se o equipamento é de cliente, considerado para prestação de serviço.
  6. Funcionário responsável (T9_FUNRESP)* – consulta na tabela de funcionários de manutenção. Trata-se de um funcionário próprio que fica responsável pela manutenção do equipamento no cliente.

Os relatórios que já possuem parâmetro de centro de custo não precisarão de alterações, basta pegar uma faixa de centro de custo para visualizar os bens de um mesmo cliente.
Obs: essa funcionalidade deve ser desenvolvida independentemente da utilização do parâmetro da integração por mensagem única.
Foram analisados também os seguintes itens e colocado pela equipe do SIGA-MNT que há equivalências entre os processos:

 

  • Abertura de Ordem de Serviço via TOP

Para compatibilizar com funcionalidade semelhante do RM Officina, deve-se disponibilizar no TOP a funcionalidade de abertura de Ordem de Serviço, a ser efetuada através da inclusão de uma Solicitação de Manutenção, onde o operador informa qual o recurso (ativo), projeto, tarefa e descreve quais os sintomas ou observações pertinentes à manutenção solicitada. Esta manutenção deve ser gerenciada pelo módulo de manutenção (MNT).
O custo será apropriado ao TOP no momento da atualização dos itens do movimento (BackOffice) da OS, caso o tipo de movimento esteja parametrizado para apropriar custos.

  1. O processo de finalização da OS no SigaMNT acarretará na atualização do movimento de OS correspondente no BackOffice e , caso parametrizado para tal, gerará apropriação dos custos para seu respectivo projeto/tarefa.
    Obs.: Esta implementação deve ser estuda para equipe do TOP, a ser desenvolvida internamente à integração TOP x SigaMNT, visto que não faz parte do escopo do BackOffice.


  • Liberação de Movimentos

O processo de liberação de movimentos é responsável pela exclusão de movimentos antigos da base de dados, mas não disparará mensagens de exclusão para o SigaMNT.
Deve-se implementar a exclusão dos “DE-PARAs” dos movimentos removidos da base no processo, para evitar problemas futuros.
Quanto à limpeza das solicitações, baixas de estoque e outras entidades que integram movimentos, fica a cargo do cliente efetua-la no SigaMNT com apoio da equipe de suporte ou equipe de consultores.

...