Histórico da Página
Manual da Integração Manutenção de Ativos/Gestão de Frotas x BackOffice RM - Mensagem Única EAI 2.0
Contexto de negócio
O objetivo da integração do SIGAMNT x BackOffice RM é viabilizar que de forma automática os cadastros gerenciados pelo BackOffice sejam replicados no vertical e, de forma similar, que os processos geridos pelo Gestão de Ativos/Gestão de Frotas tenham suas informações levadas ao BackOffice. Desta forma as bases de dados se mantém espelhadas, atualizando estoque, permitindo emissão de notas fiscais e demais processos no BackOffice.
Sistemas Envolvidos
Descrição dos sistemas envolvidos no contexto de negócio (e que serão envolvidos na integração).
- Microsiga Protheus através dos seguintes módulos:
Protheus Framework (SIGACFG): Módulo responsável pelos WebServices e Framework de Integração.
Protheus Padrão NG (SIGAMNT): Módulo utilizado pelo cliente, sendo responsável pela manutenção do cadastro (Frotas, Pneus, Bens, Manutenção, Funcionário da Manutenção(mão de obra), Solicitações de Serviço, Ordens de Serviço, Retorno de OS, Movimentação), Controle de Pneus, Controle de Abastecimentos, Controle de Documentos, Controle de Riscos e demais processos da empresa.
Protheus Manufatura (SIGAPCP): Módulo utilizado pelo cliente, sendo responsável pela manutenção do cadastro (Calendário, Ordem de Produção, Recursos, Ferramentas) e demais processos da empresa.
Protheus Logística (SIGAOMS, SIGATMS): Módulo utilizado pelo cliente, sendo responsável pela manutenção do cadastro (Motorista, Veiculos) e demais processos da empresa.
- BackOffice RM através dos seguintes módulos:
- TOTVS Gestão de Estoque, Compras e Faturamento (RM Nucleus): Módulo utilizado pelo cliente, sendo responsável pela manutenção dos cadastros (Unidade de medida, Produto, Local de Estoque, Condição de Pagamento, Moeda, Movimentação), gestão de estoque, integrações fiscais, financeiras e demais processos da empresa.
- TOTVS Gestão Financeira (RM Fluxus): Módulo utilizado pelo cliente, sendo responsável pela manutenção dos cadastros (Cliente/Fornecedor), integrações financeiras e demais processos da empresa.
- TOTVS Gestão Contábil (RM Saldus): Módulo utilizado pelo cliente, sendo responsável pela manutenção dos cadastros (Centro de Custo) e demais processos da empresa.
- TOTVS Gestão Patrimonial (RM Bonum): Módulo utilizado pelo cliente, sendo responsável pela manutenção dos cadastros (Bem/Ativo) e demais processos da empresa.
- TOTVS Construção e Projetos (RM Solum): Módulo utilizado pelo cliente, sendo responsável pela manutenção dos cadastros (Obra, Projeto, Tarefa) e demais processos da empresa.
- TOTVS Folha de Pagamento (RM Labore): Módulo utilizado pelo cliente, sendo responsável pela manutenção dos cadastros (Funcionário, Cargo, Função, Horário) e demais processos da empresa.
- TOTVS Framework: Módulo responsável pelos WebServices e Framework de Integração.
Integração
Para atender a demanda de clientes que possuem o BackOffice RM e necessitam de uma solução para Manutenção de Ativos e Controle de Frotas foi desenvolvida esta integração, que possibilita a gestão das movimentações a partir do módulo correspondente do Protheus, sincronizando as informações entre os módulos a partir da integração por Mensagem Única TOTVS.
...
Além de questões referentes ao formato das mensagens, a mensagem única também torna uniforme o tratamento destas mensagens XML pelos aplicativos, principalmente no que diz respeito à capacidade de rastreamento.
Pré-requisitos instalação/implantação/utilização
O ambiente de integração necessita, além dos pré-requisitos de cada módulo individualmente, das seguintes características:
...
O compartilhamento de tabelas deve ser coerente com a forma como o BackOffice RM trabalha, conforme descrita no documento de configuração.
- Configurar os adapters utilizados na integração TOTVS Manutenção de Ativos x BackOffice RM, conforme detalhado em Configurações Adapter Protheus.
Controle de Versão
O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.
Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definida pelo Comitê de Integração TOTVS.
Suporte
O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim as equipes de suporte dos produtos BackOffice RM, Backoffice Protheus e SigaMNT estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.
Escopo
O escopo deste projeto se restringe aos processos de integração com o SigaMNT Protheus e os cadastros utilizados por estes.
Todos os processamentos de BackOffice se manterão no RM, sendo eles a geração de escrituração, relatórios, emissão de notas fiscais e outros.
Transações/Entidades/Mensagens únicas
Segue abaixo tabela com informações sobre as entidades trafegadas na integração.
Método | ID | Descrição | Origem | Destino | Mensagem Única | Versão da Mensagem |
Cadastros | 01 | Cliente/Fornecedor | RM | Protheus | CustomerVendor | 2.002 |
02 | Moeda | RM | Protheus | Currency | 2.001 | |
03 | Unidade de Medida | RM | Protheus | UnitOfMeasure | 2.000 | |
04 | Produto | RM | Protheus | Item | 4.005 | |
05 | Centro de Custo | RM | Protheus | CostCenter | 2.000 | |
06 | Ativo Fixo | RM | Protheus | Assets | 1.001 | |
07 | Transferência de Ativo Fixo | RM | Protheus | Assets | 1.001 | |
08 | Exclusão de Ativo Fixo | RM | Protheus | Assets | 1.001 | |
09 | Projeto | RM | Protheus | Project | 2.000 | |
10 | Obra | RM | Protheus | SubProject | 2.000 | |
11 | Tarefa | RM | Protheus | TaskProject | 2.000 | |
12 | Etapa | RM | Protheus | StepProject | 2.000 | |
13 | Condição de Pagamento | RM | Protheus | PaymentCondition | 2.000 | |
14 | Local de Estoque | RM | Protheus | Warehouse | 1.000 | |
Processos | 20 | Solicitações (SA e SC) | Protheus | RM | Request | 1.010 |
21 | Cancelamento de SA/SC | Protheus | RM | CancelRequest | 1.000 | |
22 | Ordem de Serviço | Protheus | RM | MaintenanceOrder | 1.002 | |
23 | Finalizar OS | Protheus | RM | MaintenanceOrder | 1.002 | |
24 | Faturar OS | RM | Protheus | MaintenanceOrder | 1.002 | |
25 | Cancelamento de OS | Protheus | RM | CancelMaintenanceOrder | 1.000 | |
26 | Baixa de estoque | Protheus | RM | StockTurnover | 1.006 | |
27 | Baixa de Estoque | RM | Protheus | StockTurnover | 1.006 | |
28 | Cancelar Baixa de Estoque | Protheus | RM | CancelRequest | 1.000 | |
29 | Consulta Saldos e Custos | Protheus | RM | StockLevel | 1.001 | |
30 | Apropriação de Custos | Protheus | RM | AppointmentCost | 1.000 | |
31 | Ampliação Patrimonial | Protheus | RM | AssetsValuation | 1.000 | |
32 | Análise técnica de pneus | Protheus | RM | StockTurnover | 1.006 | |
33 | Controle de Abastecimento | Protheus | RM | StockLevel | 1.001 | |
34 | Controle de Abastecimento | Protheus | RM | StockTurnover | 1.006 | |
35 | Controle de Abastecimento | Protheus | RM | Order | 3.002 | |
36 | Gestão de Documentos | Protheus | RM | Order | 3.002 | |
37 | Informação de Parcelas | RM | Protheus | InfoOfParcelValues | 1.000 | |
38 | Gestão de Multas | Protheus | RM | Order | 3.002 | |
39 | Honorários de Despachante | Protheus | RM | Order | 3.002 | |
40 | Ordem de Serviço de Pneus | Protheus | RM | MaintenanceOrder | 1.002 | |
41 | Transferência de Pneus | Protheus | RM | StockTurnover | 1.006 | |
42 | Ordem de Serviço Terceiros | Protheus | RM | MaintenanceOrder | 1.002 |
Cadastros
Para esta integração todos os cadastros possuem sua origem no BackOffice RM, sendo enviados à retaguarda Protheus.
...
Expandir | ||
---|---|---|
| ||
As Etapas do projeto devem ser cadastradas somente no RM e sincronizados automaticamente para o Protheus através da mensagem única StepProject. O campo Código da Etapa no Protheus deve ser alterado para o tamanho de 60 caracteres, para manter compatibilidade com o RM. |
Processos
Conforme descrito na seção de apresentação do escopo, o escopo da integração se restringe aos processos relacionados a Gestão de Frotas e Manutenção de Ativos que sejam pertinentes de manipulação no BackOffice, como integrações fiscais, financeiras ou controle de estoque.
...
Expandir | ||
---|---|---|
| ||
As mensagens de solicitação de compra ou armazém enviadas ao BackOffice RM serão originadas no SigaMNT ao se cadastrar insumos como previstos, respeitando as devidas regras de negócio implementadas no SigaMNT. O fluxo das ordens de serviço, que inicia o fluxo das solicitações, é descrito no anexo Fluxo da ordem de serviço no SigaMNT. Ciclo de vida das solicitações: Solicitação de Compra: Solicitação de Armazém (Estoque): Parâmetros de Integração: Para que os tipos de movimentos de Solicitação de Compra e Solicitação de Armazém sejam recuperados é necessário que o Nome do Parâmetro esteja corretamente informado no cadastro de Parâmetros adapter. São eles:
|
...
O fluxo completo da ordem de serviço é descrito no anexo: Fluxo da ordem de serviço no SigaMNT.
Notas:
Expandir | ||
---|---|---|
| ||
RM -> Protheus A mensagem de envio NÃO deve ser considerada como de inclusão ou alteração de dados da OS além do status, pois desta forma seria requerido algumas informações que não são da alçada do BackOffice e o mesmo não detém. Na mensagem enviada consta somente os dados necessários para identificação da OS e o novo Status, não devendo assim alterar nenhuma outra informação, como custos ou insumos. Ao cadastrar uma ordem de serviço com status “Liberada”. Ao efetuar a liberação de uma ordem de serviço. |
...
Na reabertura da ordem de serviço.
Como fazer
Videos com exemplo dos Processos:
Abertura de O.S. liberada (Clique aqui para acessar o vídeo)
Processo aplicação de Insumo (Clique aqui para acessar o vídeo)
Finalização OS (Clique aqui para acessar o vídeo)
Cancelamento de O.S. (Clique aqui para acessar o vídeo)
Conciliação de Posto Externo (Clique aqui para acessar o vídeo)
Abastecimento Posto Interno (Clique aqui para acessar o vídeo)
Analise Técnica de Pneus (Clique aqui para acessar o vídeo)
Inclusão de O S em Lote Pneus (Clique aqui para acessar o vídeo)
Atendimento S.C. – O.S. Pneus em Lote (Clique aqui para acessar o vídeo)
Movimentação de Pneus (Clique aqui para acessar o vídeo)
Recebimento O.S. em Lote (Clique aqui para acessar o vídeo)
Inclusão de Multas Veículo (Clique aqui para acessar o vídeo)
Pagamento da Multa (Clique aqui para acessar o vídeo)
Inclusão de Documentos Veículos (Clique aqui para acessar o vídeo)
Pagamento do Documento (Faturamento) (Clique aqui para acessar o vídeo)
Inclusão de Honorários Despachantes (Clique aqui para acessar o vídeo)
Restrições e Pontos de Atenção
Expandir | ||
---|---|---|
| ||
Manutenção da sincronia das bases BackOffice RM e SigaMNT Configuração do comportamento do tipos de movimento O configurador da integração não faz atualizações Apropriação de custos não relacionados a OS Mapa de Alocação de Equipamentos Informações referentes aos cadastros de Município, Estado e País Integração com TOP Caracteres especiais na mensagem única |
GAPs Funcionais e Pontos de Atenção MNT x Officina
Expandir | ||
---|---|---|
| ||
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: 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”. 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. 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. 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. 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 que Falta Implementar: Atualizar a descrição da tabela TP3 para “contratos de manutenção” e adicionar os seguintes campos na tabela: Filial Filial Número do Contrato 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. 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. 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. a. Verificar se o bem da OS é um bem de prestação de serviço; Abertura de Atendimento[SIGAMMNT] Há alguns gaps relacionados a este item. Abaixo um texto do que teria que ser implementado. O que Falta Implementar: 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. 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. 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: 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: 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: Cliente (T9_CLIENTE) Loja Cliente (T9_LOJACLI) Data Instalação (T9_DTINSTA) 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. 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. 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 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. 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. |
Check list de suporte da aplicação
Executar a ferramenta de Diagnósticos da integração
...
Anexos
Expandir | ||
---|---|---|
| ||
Pendente Etapa responsável por orçamento, análise, aprovação, liberação, etc. Insumos pré-cadastrados na manutenção estarão listados como previstos. Aos cadastrar novos insumos, aos mesmos serão inseridos como insumos previstos. Etapa sem integração com BackOffice RM. Pendente -> Liberado Etapa em que a Ordem de Serviço (Manutenção) é aprovada e liberada para execução. Ponto de início da integração, onde é gerada a OS no BackOffice sem itens, a fim de relacionar as solicitações referentes à OS. Os produtos consumidos no desenvolvimento da OS serão inseridos no BackOffice somente ao finalizar a mesma. Caso haja insumos previstos, o SigaMNT deve gerar as respectivas solicitações de armazém/compra no BackOffice ao liberar a OS. Liberado Neste status podem-se executar os insumos previstos (que se tornarão realizados). A inclusão de novos insumos na OS segue o comportamento descrito abaixo: Insumos inseridos como previstos no SigaMNT devem gerar novas solicitações de armazém/compra. O cancelamento (exclusão) de insumo previsto ou realizado deve disparar mensagem de estorno ao BackOffice, para desfazer a ação equivalente que o gerou. Ao efetuar baixa de estoque (direta ou por baixa de solicitações) diretamente pelo BackOffice será enviada mensagem de integração ao SigaMNT, fazendo com que os insumos baixados sejam inseridos nos insumos realizados da OS.A partir de então o mesmo não deverá sofrer alterações no SigaMNT. Alteração de Insumos A alteração de insumos previstos ou realizados, quando possível, implica no cancelamento na solicitação anterior e a geração de novas solicitações. Ao alterar a quantidade ou incluir insumos no SigaMNT, o mesmo deve consultar o saldo em estoque do produto e verificar se será possível atender a nova quantidade solicitada, decidindo assim entre solicitação de armazém ou de compra. Quando o Manutenção de Ativos estiver configurado para aglutinar as Solicitações de Armazém para a mesma Ordem de Serviço (MV_NGMNTAS = 1), ao realizar alteração de insumos previstos ele irá aplicar esta alteração na mesma solicitação, ou seja, não irá excluir a solicitação e gerar uma nova. Ao alterar a quantidade do insumo previsto, será enviado ao BackOffice uma mensagem apagando o item alterado e outra mensagem contendo um novo item com a quantidade alterada. Caso seja incluído um novo insumo previsto ele enviará ao RM uma mensagem contendo todos os dados da Solicitação mais o item inserido. Observação: o Manutenção de Ativos deve consultar o BackOffice para verificar se será permitido a alteração do movimento. Quando não for permitido alterar o movimento, será criado um novo movimento de solicitação contendo as alterações realizadas na OS. Insumos de serviços de terceiros serão inseridos no BackOffice como solicitações e devem sofrer alterações somente no BackOffice. Quando a solicitação for baixada o SigaMNT deve ser informado para que o insumo seja inserido como realizado na OS. Quando o tipo de movimento de Solicitação de Armazém estiver configurado como Baixa Movimento Default e for faturado/recebido para um tipo de movimento diferente do default, o status da solicitação permanece como Pendente, mas é criado um vínculo com outro movimento. Neste cenário, caso seja realizada uma alteração de OS com exclusão do insumo previsto, ao salvar a alteração o BackOffice será consistido se o item excluído possui vinculo com outro movimento e caso possua será apresentando mensagem ao usuário, não for permitido esta ação. Insumos previstos -> Insumos realizados Existem duas formas de inserir insumos Realizados, sendo elas: Via BackOffice: Via SigaMNT: Ao adicionar um novo insumo como realizado o mesmo gerará uma baixa de estoque no BackOffice. Finalizado Ao finalizar uma OS, internamente ao BackOffice o status do movimento será alterado de “Em andamento” (E) para “A Faturar” (A). Não será permitida a inserção de novos insumos. É possível finalizar OS com Solicitações de Compras e Armazém em aberto. Este controle não será implementado em primeiro momento. Podem existir solicitações pendentes no BackOffice e estes poderão sofrer “baixa” no BackOffice e entrar na lista de realizados da OS. Atualizar o movimento da OS no BackOffice com os itens constantes como realizados e o status deste movimento. Cancelado Atualizar o movimento da OS no BackOffice com os itens constantes como realizados e o status deste movimento como cancelado. O processo deve ser executado internamente em duas partes, sendo elas: Finalizado -> Liberado (Reabertura de OS) Deve-se enviar mensagem de atualização da OS (movimento que representa a ordem de serviço) com o novo status e data de término, ficando a cargo do BackOffice efetuar a reabertura do movimento. Internamente ao BackOffice o status do movimento será alterado de “A Faturar” (A) para “Em andamento” (E). O processo de atualização do movimento da OS será realizado novamente ao finalizar ou cancelar a OS, fazendo com que o status, data de término e os itens sejam corretamente preenchidos (conforme processo padrão definido anteriormente). Faturamento O processo de faturamento da OS deve ocorrer no BackOffice, que fica responsável por enviar mensagem de atualização do status ao SigaMNT. OSs faturadas não podem receber alterações ou serem reabertas internamente ao SigaMNT. Somente podem ser faturadas movimentos de OS em sua totalidade, ou seja, não é permitido faturar parcialmente um movimento de OS. Se for realizado o faturamento com agrupamento de mais de um movimento de OS ao mesmo tempo, o faturamento deve conter a quantidade total de todos os itens das OS envolvidas no faturamento, isto é, se a quantidade total do(s) item(ns) no movimento de destino for inferior a soma das quantidades do(s) item(ns) dos movimentos de origem, o processo de faturamento é abortado e não é enviada nenhuma mensagem de atualização de status para a OS no SigaMNT Dica: No faturamento de OS, caso ocorra mensagem de consistência referente ao campo TJ_CUSTMAA ("Data width error - Field: TJ_CUSTMAA"), significa que o valor de faturamento enviado do RM para o SigaMNT está excedendo o tamanho do campo no Protheus. Nesse caso, recomenda-se verificar se o valor do faturamento está correto ou aumentar o tamanho do campo no Protheus através do módulo SigaCFG: Rotina: Base de Dados | Dicionário | Base de Dados. Buscar tabela STJ, editar campo "TJ_CUSTMAA" e aumentar o valor do campo "Tamanho" conforme necessidade. (Sugestão de tamanho: 16) Fluxo resumido Passo 1: OS é aberta no SigaMNT (sem integração) Passo 2: OS é liberada no SigaMNT Passo 3: OS é finalizada no SigaMNT Passo 4 (Opcional): OS é reaberta no SigaMNT Passo 5 (Opcional): OS é faturada no RM |