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.

ProjetoProject2Condição de PagamentoPaymentCondition2WarehouseProcessos

Método	ID	Descrição	Origem	Destino	Mensagem Única	Versão da Mensagem	Observação
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	Condição de Pagamento	RM	Protheus	PaymentCondition	3.000
	10Obra	Local de Estoque	RM	Protheus	SubProjectWarehouse	21.000
	11	TarefaCargo	RM	Protheus	TaskProjectEmployeePosition	21.000
	12	EtapaFunção	RM	Protheus	StepProjectRole	21.000
	13	Turno/Horário	RM	Protheus	Shiftwork	1.000
	14	Local de EstoqueFuncionário	RM	Protheus	Employee	2.003
Processos	15	Situação do Funcionário	Protheus	RM	GetEmployeeSituation	1.000
	16	20	Solicitações (SA e SC)	Protheus	RM	Request	1.010
	2117	Cancelamento de SA/SC	Protheus	RM	CancelRequest	1.000
	2218	Ordem de Serviço	Protheus	RM	MaintenanceOrder	1.002
	2319	Finalizar OS	Protheus	RM	MaintenanceOrder	1.002
	2420	Faturar OS	RM	Protheus	MaintenanceOrder	1.002
	2521	Cancelamento de OS	Protheus	RM	CancelMaintenanceOrder	1.000
	2622	Baixa de estoque	Protheus	RM	StockTurnover	1.006
	2723	Baixa de Estoque	RM	Protheus	StockTurnover	1.006
	2824	Cancelar Baixa de Estoque	Protheus	RM	CancelRequest	1.000
	2925	Consulta Saldos e Custos	Protheus	RM	StockLevel	1.001
	30	Apropriação de Custos	Protheus	RM	AppointmentCost	1.000

	26	31	Ampliação Patrimonial	Protheus	RM	AssetsValuation	1.000
	3227	Análise técnica de pneus	Protheus	RM	StockTurnover	1.006
	3328	Controle de Abastecimento	Protheus	RM	StockLevel	1.001
	3429	Controle de Abastecimento	Protheus	RM	StockTurnover	1.006
	3530	Controle de Abastecimento	Protheus	RM	Order	4.010	A partir da versão da Biblioteca RM 12.1.2209.158 e superiores será configurado a versão 4.010. Versões anteriores continuam usando a versão 3.002
	3631	Gestão de Documentos	Protheus	RM	Order	4.010	A partir da versão da Biblioteca RM 12.1.2209.158 e superiores será configurado a versão 4.010. Versões anteriores continuam usando a versão 3.002
	3732	Informação de Parcelas	RM	Protheus	InfoOfParcelValues	1.000
	3833	Gestão de Multas	Protheus	RM	Order	34.002
	39	Honorários de Despachante	Protheus	RM	Order	3.002
	010	A partir da versão da Biblioteca RM 12.1.2209.158 e superiores será configurado a versão 4.010. Versões anteriores continuam usando a versão 3.002
34	Honorários de Despachante	Protheus	RM	Order	4.010	A partir da versão da Biblioteca RM 12.1.2209.158 e superiores será configurado a versão 4.010. Versões anteriores continuam usando a versão 3.002
3540	Ordem de Serviço de Pneus	Protheus	RM	MaintenanceOrder	1.002
4136	Transferência de Pneus	Protheus	RM	StockTurnover	1.006
4237	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

title	Clique aqui para expandir

Visto que a base Protheus possui carga de As unidades de medida padrões, que obrigatoriamente constam na base de dados, deve-se efetuar manualmente o cadastramento da relação “DE-PARA” nas tabelas referentes no RM e Protheus para viabilizar a integração de registros que utilizem estas como parâmetro.As unidades de medida referentes à Hora (H), Quilometragem (KM), referentes à Hora (H), Quilometragem (KM), Unidade (UN) e Litro (L) devem possuir o mesmo código tanto no RM quanto no PROTHEUS. Foi implementado no EAI 2.0 para que quando for enviado pelo RM uma das unidades que já existe no Protheus, o Protheus irá atualizar a unidade e criar o de-para, não sendo necessário criar o de-para das unidades padrão manualmente.

O campo Código da Unidade de Medida no PROTHEUS será gerado pelo Adapter, uma vez que este campo no RM tem tamanho de 5 caracteres, no PROTHEUS 2 caracteres e na mensagem única 6 caracteres.

...

Expandir

title	Clique aqui para expandir

Os Centros de Custo devem ser cadastrados somente no BackOffice RM e sincronizados automaticamente para o Protheus através de mensagem única CosCenter.

Para manter a compatibilidade entre os sistemas, os campos Centro de Custo e Código Reduzido do Centro de Custo no Protheus deve ser alterado para tamanho de 25 20 caracteres, uma vez que no RM estes campos permitem até 25 caracteres.

...

Identificador da Mensagem: PaymentCondition
Versão: 23.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/Sdj0E

...

Expandir

title	Clique aqui para expandir

As Condições de pagamento devem ser cadastradas somente no BackOffice RM e sincronizados automaticamente para o Protheus através de mensagem única PaymentCondition.

O cadastro de condições de pagamento deve ser compatibilizado com as limitações do Protheus quanto aos tipos de período, que são mais bem especificadas na seção de mapeamento da mensagem.Caso o Código da Condição de Pagamento no RM seja maior que 3 caracteres, o código da condição de pagamento no Protheus deve ser configurado como auto-incremento

Acessar o Configurador do Protheus (SIGACFG) e na tabela SE4 alterar o tamanho do campo E4_COND para 100 caracteres.

Cadastro de Produto/Serviço

...

Expandir

title	Clique aqui para expandir

Os Clientes e Fornecedores devem ser cadastrados no BackOffice RM e sincronizados automaticamente para o Protheus através da mensagem única CustomerVendor.

Ao iniciar uma base vazia (zerada) do Protheus, para incluir a tabela de Municípios no Protheus é necessário acessar o Protheus no sistema 09 - Livros Fiscais. Se não acessar o sistema Fiscal do Protheus antes de enviar o cadastro do RM irá apresentar mensagem de inconsistência informando que é valor inválido para o campo Município.

Uma vez que o Cliente e Fornecedor são tratados na mesma mensagem (CustomerVendor), ao cadastrar um registro do tipo Ambos no RM é gerado no Protheus um registro em cada tabela, SA1 (Clientes) e SA2 (Fornecedor).

Mesmo que a empresa não utilize Cliente/Fornecedor global no RM, Para utilizar esta integração é premissa que o cadastro de Cliente\Fornecedor esteja parametrizado como Global, obrigatoriamente deve-se compartilhar a tabela referente no Protheus por empresa.

Cadastro de Patrimônio (Ativo Fixo)

Identificador da Mensagem: Assets
Versão: 1.001
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/hYP6E

...

Expandir

title	Clique aqui para expandir

Serão integrados somente ativos do tipo Patrimônio. Assim sendo, qualquer ativo dos tipos Título ou Terceiros será desconsiderado e não disparará o gatilho de integração.

Não será integrado o histórico de valores do ativo fixo na seção “ListOfSalesAndValuesAssets” da mensagem, sendo o código de integração enviado sempre com o sufixo “1”. Estes dados do patrimônio serão enviados respeitando a seguinte regra:
* Inclusão: Serão enviados os dados informados na tela de inclusão.
* DepreciationStartDate: Valor calculado pela função PatPatrimonioService.RetornaDataInicioVigencia(CodColigada, DataAquisicao). Esta função considera a Data de Aquisição como Data Início Vigência. Há variações se os parâmetros abaixo estiverem marcado:

- DTINICIODEPRECPROXANO: Adiciona um ano com base no ano cálculo definido na parametrização e fixa o mês e o dia em 01;

- DTINICIODEPRECPROXANO e Dia da Data de Aquisição maior que 01: Adiciona um mês na Data Aquisição e fixa o dia em 01;

- DATASEMPRE1DIAMESAPOSAQUIS: Adiciona um mês na Data Aquisição e fixa o dia em 01.
* OriginalValueCurrency : IPatrimonio.AQUISICAO
* CurrencyCode e CurrencyInternalId: Código da moeda padrão do sistema (Definido em Ambientes | Parâmetros Globais | Gerais | Símbolo da Moeda);
* AnnualRateCurrencyDepreciation: IPatrimonio.VRTAXADEPRECIACAO
* BalanceDepreciation: Fixo 0.
* Alteração: Serão enviados os dados atuais do ativo em uma única linha, desconsiderando as movimentações anteriores não integradas.
* DepreciationStartDate: ICALCULOPATRIMONIO.DATAINICIOVIGENCIA para o IDCENARIOCALCULO = 1
* OriginalValueCurrency: ICALCULORAZAO.VALORBASECORRIGIDO (considera apenas o último valor calculado) ou ISALDOCALCULOPATRIMONIOMOEDA. VALORBASECORRIGIDO para o IDCENARIOCALCULO = 1
* CurrencyCode e CurrencyInternalId: ICALCULORAZAO.MOEDAINDICE ou ISALDOCALCULOPATRIMONIOMOEDA.MOEDAINDICE
* AnnualRateCurrencyDepreciation: ITAXADEPRECIACAO.VALOR
* BalanceDepreciation: ICALCULORAZAO. DEPRECIACAOACUMULADACORRIGIDA (considera apenas o último valor calculado) ou ISALDOCALCULOPATRIMONIOMOEDA. DEPRECIACAOACUMULADACORRIGIDA
* Exclusão: Serão enviados somente os dados da chave do Ativo, sendo desconsiderados todos os outros campos. Não será possível excluir mais de um registro integrado quando a entidade ASSETS estiver mapeada no cadastro de Rotas e a integração estiver ativa. Caso necessário, a exclusão deverá ser feita por registro.

Para integrar esta entidade, o PROTHEUS exige que seja cadastro um valor default para o Plano de Contas em sua base (para cada filial), com os seguintes parâmetros (No Módulo SigaADV| Cadastros | Planos de Contas):
* Código: 001
* Descrição: “Default Integração”
* Classe de conta: Analítica
* Condição normal: Credora

No processo de Ao realizar Transferência de Controle (filial e centro de custo) será atualizado o Bem e enviado a atualização para o SIGAMNT não será integrado a ocorrência de transferência Para que a integração seja realizada é necessário cadastrar no PROTHEUS cotação de moeda para a moeda utilizada na data de transferência. Caso não exista cotação de moeda na data de transferência, podem ser apresentadas as seguintes mensagens de erro: “HELP: AF010JABAI” ou “HELP: AF060NOTXA”.

O campo “N1_CHAPA” da tabela de Ativos do PROTHEUS deve ter seu tamanho alterado para 30 caracteres para ficar compatível com o RM.

...

Expandir

title	Clique aqui para expandir

Caso o código do Local de Estoque no RM seja maior que 6 (seis) caracteres, no Protheus o código do local de estoque deverá ser auto-incremento.

Por padrão, o tamanho máximo da descrição do local de estoque no Protheus é de 20 caracteres. Para compatibilizar com o RM, acesse SIGACFG e na tabela NNR altere o campo NNR_DESCRI para ter o tamanho = 40.

Cadastro de CargoCadastro de Projeto

Identificador da Mensagem: ProjectEmployeePosition
Versão: 21.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/ENf0E

Notas:

Expandir

title	Clique aqui para expandir

Os Projetos devem ser cadastrados somente no RM e sincronizados automaticamente para o Protheus através da mensagem única Project.

O código da filial do projeto será sempre obrigatório caso a integração esteja instalada. Caso ele não seja informado será exibida uma mensagem ao usuário e a mensagem não será enviada ao Protheus.

Algumas parametrizações são obrigatórias no Protheus para que a integração de projetos seja efetuada com sucesso. Para maiores detalhes acesse o link Integração de Projeto.

O campo Código do Projeto no Protheus está limitado a 10 caracteres. Caso o RM possua Código do Projeto com mais de 10 caracteres deve-se analisar se o Protheus deve ser configurado como auto-incremento.

Cadastro de Obra

04P6E

Cadastro de Função

Identificador da Mensagem: Role
Versão: 1.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/7IP6E

Cadastro de Turno

Identificador da Mensagem: ShiftWork
Versão: 1.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/AYT6E

Cadastro de Funcionário

Identificador da Mensagem: Employee
Versão: 2.003Identificador da Mensagem: SubProject
Versão: 2.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/Stf0E9Yv6E

Notas:

Expandir

title	Clique aqui para expandir

As Obras devem ser cadastradas somente no RM e sincronizados automaticamente para o Protheus através da mensagem única SubProject.

O campo Código da Obra no Protheus deve ser alterado para o tamanho de 60 caracteres, para manter compatibilidade com o RM.

Cadastro de Tarefa

Identificador da Mensagem: TaskProject
Versão: 2.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/fNf0E

Notas:

Expandir

title	Clique aqui para expandir

As Tarefas devem ser cadastradas somente no RM e sincronizados automaticamente para o Protheus através da mensagem única TaskProject.

O campo Código da Tarefa no Protheus deve ser alterado para o tamanho de 60 caracteres, para manter compatibilidade com o RM.

Cadastro de Etapa

A informação de centro de custo é obtida a partir da seção do funcionário. Sendo assim, é necessário atentar ao cadastramento das seções, pois esta entidade ocupa no RM o mesmo nível hierárquico do centro de custo no Protheus.

O cadastro de centros de custo do Labore (tabela PCCUSTO) deve trabalhar conforme o processo Sincronização Centro de Custo Global, que mantém o cadastro da tabela PCCUSTO espelhada com a tabela de centro de custo global (“GCCUSTO”).

Para integrar a entidade Funcionário, o PROTHEUS exige que sejam cadastrados valores default para Banco/Agência/Conta. Estes registro devem ser cadastrados com o seguintes códigos abaixo:
* Banco / Agência / Conta com códigos: 001 / 00000 / 0000000000

O rateio de funcionário por centro de custos não será integrado, pois o mesmo não é utilizado pelo sistema SigaMNT.

Caso a chapa do funcionário no RM seja maior que 6 caracteres, este campo no PROTHEUS deve ser configurado como autoincremento.

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.

Abaixo são listados os processos integrados.

Manutenção de Ativos

Solicitações de Armazém/Compra

Tipo de Fluxo: Protheus -> RM
Mensagem: Request
Versão: 1.010
Mapeamento de Campos: Identificador da Mensagem: StepProject
Versão: 2.000
Mandatário: BackOffice RM
Tipo de Envio: Síncrono
Mapeamento de Campos: http://tdn.totvs.com/x/udf0E-476E

Notas:

Expandir

title	Clique aqui para 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.

Abaixo são listados os processos integrados.

Manutenção de Ativos

Solicitações de Armazém/Compra

Tipo de Fluxo: Protheus -> RM
Mensagem: Request
Versão: 1.010
Mapeamento de Campos: http://tdn.totvs.com/x/-476E

Notas:

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:
A solicitação de compra segue o processo padrão definido pelo TOTVS Gestão de Estoque, Compras e Faturamento, podendo passar pelo processo de cotação ou não, sendo que a baixa de estoque referente aos produtos comprados deve ser inserida no BackOffice via cópia por referência para o movimento de OS com o tipo de relacionamento “Cópia Simples com Relacionamento somente de movimento”.

Solicitação de Armazém (Estoque):A solicitação de armazém segue o processo padrão definido

Expandir

title	Clique aqui para 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:
A solicitação de compra segue o processo padrão definido pelo TOTVS Gestão de Estoque, Compras e Faturamento, podendo passar pelo processo de cotação ou não, sendo que a baixa de estoque referente aos produtos comprados deve ser inserida no BackOffice via cópia por referência para o movimento de OS com o tipo de relacionamento “Cópia Simples com Relacionamento somente de movimento”.Solicitação de Armazém (Estoque):
A solicitação de armazém segue o processo padrão definido pelo TOTVS Gestão de Estoque, Compras e Faturamento, sendo que sendo que a baixa de estoque destas solicitações devem ser efetuadas através do processo de faturamento disponibilizado em tela e com o tipo de movimento parametrizado como sendo de Baixa de Estoque para o SigaMNT.
Caso o faturamento não seja feito por tela ou não utilize o tipo de movimento parametrizado como sendo de Baixa de Estoque para o SigaMNT não será acionado o gatilho de integração e assim o SigaMNT não será informado da mesma.

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:

Solicitação de Compra: TMVSolicitacaoCompra
Solicitação de Armazém: TMVSolicitacaoArmazem

Consulta Situação da SA/SC

Tipo de Fluxo: Protheus -> RM
Mensagem: TraceabilityRequest
Versão: 1.001
Especificações BackOffice RM: Consulta situação Solicitação de Armazém/Solicitação de Compras

Cancelar Solicitação de Armazém/Compra

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelRequest
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/apP6E

Notas:

Expandir

title	Clique aqui para expandir

O processo de Cancelamento de Solicitação de Armazém/Compra no Protheus é realizado ao Cancelar a Ordem de Serviço pela tela de Retorno MOD 2 no SigaMNT. Ao executar esse processo, é enviado a mensagem CancelRequest e logo em seguida a CancelMaintenanceOrder.

No caso de alteração de insumos, logo após este fluxo deve ser executado o de inclusão da nova solicitação no BackOffice, conforme definido no item Solicitações de Armazém/Compra.

A partir da versão da biblioteca 12.1.15.160 existe a mensagem TRANCEABILITYREQUEST onde o Protheus consulta o STATUS da SC/SA no RM, caso a mesma esteja em um Status que não é possível excluir o RM retorna ao Protheus a informação que não pode excluir esta SC/SA e caso seja apenas a inclusão de um novo item o ERP cria um novo movimento de SC/SA sem alterar o movimento antigo.

A partir da versão 12.1.26.124 se o tipo de movimento de SA estiver parametrizado com a opção "Baixar para Movimento Default" (Etapa Compra/Venda - Outras Características) e a SA for recebida/faturada para um tipo de movimento que não estiver definido no parâmetro "Movimento Gerado (Default)", ao cancelar uma Solicitação de Armazém (a partir do processo de Cancelar Ordem de Serviço no SigaMNT) é consistido a existência de relacionamento entre a SA e o movimento gerado, e não é permitido realizar o cancelamento da SA e da Ordem de Serviço.

Ordem de Serviço

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

O fluxo completo da ordem de serviço é descrito no anexo: Fluxo da ordem de serviço no SigaMNT.

Notas:

...

title	Clique aqui para expandir

RM -> Protheus
A mensagem de ordem de serviço será enviada ao SigaMNT pelo BackOffice RM somente quando o movimento for faturado, para informar a alteração do status da OS para “Faturado”.

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.

...

Ao cadastrar uma ordem de serviço com status “Liberada”.

Ao efetuar a liberação de uma ordem de serviço.
Ao finalizar uma ordem de serviço.
Na reabertura da ordem de serviço.

Cancelar Ordem de Serviço

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelMaintenanceOrder
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/bpT6E

Baixa de estoque

Tipo de Fluxo: RM -> Protheus e Protheus -> RM
Mensagem: StockTurnover
Versão: 1.006
Mapeamento de Campos: http://tdn.totvs.com/x/uJX6E

Notas:

...

title	Clique aqui para expandir

Existe a possibilidade da quebra de Solicitações de Armazém em Produtos Não Estocáveis e Produtos Estocáveis no BackOffice RM, conforme documento a seguir: DT EAI 2.0 Geração de SA/SC

Alteração de Solicitação com status pendente no BackOffice:

Ao realizar uma alteração de OS no SigaMNT onde na alteração é realizado a exclusão de todos os insumos previstos, caso o movimento de solicitação no BackOffice RM esteja com status Pendente, como o movimento ficará sem itens ele será excluído no BackOffice RM.

Alteração de Solicitação com status parcialmente recebido/faturado no BackOffice:

Ao realizar uma alteração de OS no SigaMNT onde na alteração é realizado a exclusão de insumos previstos, caso o movimento de solicitação no BackOffice RM esteja com status Parcialmente Recebido/Faturado serão aplicadas as seguintes regras:

Não será permitido excluir o insumo já faturado parcialmente;
Se ocorrer exclusão de insumos não faturados e ficar na solicitação somente o insumo já recebido totalmente, o status da solicitação será alterado para Recebido/Faturado.

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:

Solicitação de Compra: TMVSolicitacaoCompra
Solicitação de Armazém: TMVSolicitacaoArmazem

Disponibilizado a partir da versão 12.1.31 a possibilidade de separar os produtos não estocáveis em outro movimento. Para isso é necessário realizar configurações no BackOffice RM que podem ser consultadas no documento: Parâmetros Integração Manutenção de Ativos (Protheus)

Consulta Situação da SA/SC

Tipo de Fluxo: Protheus -> RM
Mensagem: TraceabilityRequest
Versão: 2.000
Especificações BackOffice RM: Consulta situação Solicitação de Armazém/Compras

Cancelar Solicitação de Armazém/Compra

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelRequest
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/apP6E

Notas:

Expandir

title	Clique aqui para expandir

O processo de Cancelamento de Solicitação de Armazém/Compra no Protheus é realizado ao Cancelar a Ordem de Serviço pela tela de Retorno MOD 2 no SigaMNT. Ao executar esse processo, é enviado a mensagem CancelRequest e logo em seguida a CancelMaintenanceOrder.

No caso de alteração de insumos, logo após este fluxo deve ser executado o de inclusão da nova solicitação no BackOffice, conforme definido no item Solicitações de Armazém/Compra.

A partir da versão da biblioteca 12.1.15.160 existe a mensagem TRANCEABILITYREQUEST onde o Protheus consulta o STATUS da SC/SA no RM, caso a mesma esteja em um Status que não é possível excluir o RM retorna ao Protheus a informação que não pode excluir esta SC/SA e caso seja apenas a inclusão de um novo item o ERP cria um novo movimento de SC/SA sem alterar o movimento antigo.

A partir da versão 12.1.26.124 se o tipo de movimento de SA estiver parametrizado com a opção "Baixar para Movimento Default" (Etapa Compra/Venda - Outras Características) e a SA for recebida/faturada para um tipo de movimento que não estiver definido no parâmetro "Movimento Gerado (Default)", ao cancelar uma Solicitação de Armazém (a partir do processo de Cancelar Ordem de Serviço no SigaMNT) é consistido a existência de relacionamento entre a SA e o movimento gerado, e não é permitido realizar o cancelamento da SA e da Ordem de Serviço.

Ordem de Serviço

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

O fluxo completo da ordem de serviço é descrito no anexo: Fluxo da ordem de serviço no SigaMNT.

Notas:

Expandir

title	Clique aqui para expandir

RM -> Protheus
A mensagem de ordem de serviço será enviada ao SigaMNT pelo BackOffice RM somente quando o movimento for faturado, para informar a alteração do status da OS para “Faturado”.

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.

Protheus -> RM
A mensagem de ordem de serviço será enviada ao BackOffice RM pelo SigaMNT nas seguintes circunstâncias:

Ao cadastrar uma ordem de serviço com status “Liberada”.

Ao efetuar a liberação de uma ordem de serviço.
Ao finalizar uma ordem de serviço.
Na reabertura da ordem de serviço.

Ao confirmar um plano de manutenção.

Cancelar Ordem de Serviço

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelMaintenanceOrder
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/bpT6E

Baixa de estoque

Tipo de Fluxo: RM -> Protheus e Protheus -> RM
Mensagem: StockTurnover
Versão: 1.006

RM -> Protheus

A integração da baixa de estoque para o SigaMNT ocorre ao efetuar a baixa de estoque no BackOffice informando a OS da mesma, utilizando tipo de movimento configurado para gerar integração com sistema de manutenção (parametrização do tipo de movimento Etapa Manutenção, opção "Integrado com SigaMNT" marcada e Etapa Integração Mensagem Única, opção "Mensagem de Integração = Baixa de Estoque").

...

A integração da baixa de estoque para o BackOffice ocorre na inserção de insumos realizados em uma OS no SigaMNT, tanto para a inclusão de insumos novos como na realização de insumos previstos.

Cancelar Baixa de Estoque

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelRequest
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/apP6EuJX6E

Notas:

Expandir

title	Clique aqui para expandir

RM -> Protheus

A integração da O cancelamento de baixa de estoque para o SigaMNT ocorre ao excluir ou alterar um insumo realizado no SigaMNT. No caso da alteração de insumos realizados a baixa original deverá ser cancelada e uma nova baixa gerada.

Consulta de Saldos e Custos

Tipo de Fluxo: Protheus -> RM
Mensagem: StockLevel
Versão: 1.001
Mapeamento de Campos: http://tdn.totvs.com/x/L5r6E

Notas:

Expandir

title	Clique aqui para expandir

O serviço de consulta de saldos e custos será utilizado pelo SigaMNT para fazer a validação de disponibilidade e custo de produtos inseridos como realizados.

Manutenção de Frotas

Análise técnica de pneus

Tipo de Fluxo: RM -> Protheus e Protheus -> RM
Mensagem: StockTurnover
Versão: 1.006
Mapeamento de Campos: http://tdn.totvs.com/x/uJX6E

Boletim Técnico: Processo de Análise Técnica de Pneus

efetuar a baixa de estoque no BackOffice informando a OS da mesma, utilizando tipo de movimento configurado para gerar integração com sistema de manutenção (parametrização do tipo de movimento Etapa Manutenção, opção "Integrado com SigaMNT" marcada e Etapa Integração Mensagem Única, opção "Mensagem de Integração = Baixa de Estoque").

O Movimento de baixa de estoque pode ser criado através de Copia por Referência da Nota Fiscal vinculada a Solicitação de SA/SC (Utilizando os Motivos de Referência 1, 25 ou 32) ou Faturamento. É necessário selecionar algum dos movimentos que esteja relacionado com a OS. Maiores informações consulte o documento Assistente de Cópia por Referência - Reporta Insumo MNT

Caso na etapa "Integração Mensagem Única" dos parâmetros do tipo do movimento de Baixa esteja preenchido a "Fórmula Valor Item', o resultado da fórmula será o Custo Total do Item enviado ao Protheus. Caso a fórmula não esteja preenchida, o sistema irá considerar o "Valor Liquido" do Item.

Image Added

Protheus -> RM

A integração da baixa de estoque para o BackOffice ocorre na inserção de insumos realizados em uma OS no SigaMNT, tanto para a inclusão de insumos novos como na realização de insumos previstos.

Cancelar Baixa de EstoqueControle de Abastecimento

Tipo de Fluxo: Protheus -> RM
Mensagem: StockTurnoverCancelRequest
Versão: 1.006000
Mapeamento de Campos: http://tdn.totvs.com/x/uJX6EapP6E

Notas:

Expandir

title	Clique aqui para expandir

O cancelamento de baixa de estoque ocorre ao excluir ou alterar um insumo realizado no SigaMNT. No caso da alteração de insumos realizados a baixa original deverá ser cancelada e uma nova baixa gerada.

Consulta de Saldos e Custos

Tipo de Fluxo: Protheus -> RM
Mensagem: Order StockLevel
Versão: 31.002001
Mapeamento de Campos: http://tdn.totvs.com/x/jJ76EL5r6E

Tipo de Fluxo: Protheus -> RM
Mensagem: StockLevel
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/L5r6E

Boletim Técnico: Controle de Abastecimento em Lote
Boletim Técnico: Processo de Abastecimento Manual
Boletim Técnico: Processo de Conciliação de Abastecimentos

Notas:

Expandir

title	Clique aqui para expandir

O serviço de consulta de saldos e custos será utilizado pelo SigaMNT para fazer a validação de disponibilidade e custo de produtos inseridos como realizados.

Ampliação PatrimonialGestão de Documentos

Tipo de Fluxo: Protheus -> RM
Mensagem: Order AssetsValuation
Versão: 31.002000
Mapeamento de Campos: http://tdn.totvs.com/x/jJ76EpZv6ETipo

A mensagem de ampliação patrimonial será enviada pelo SigaMNT para o BackOffice RM caso seja efetuada alguma manutenção que prolongue a vida útil do ativo ou que proporcione qualquer tipo de acréscimo no valor do mesmo.

Manutenção de Frotas

Análise técnica de pneus

Tipo de Fluxo de Fluxo: RM -> Protheus e Protheus -> RM
Mensagem: InfoOfParcelValuesStockTurnover
Versão: 1.000006
Mapeamento de Campos: http://tdn.totvs.com/x/op76EuJX6E

Boletim Técnico: Processo de Geração Análise Técnica de DocumentosPneus

Gestão Controle de MultasAbastecimento

Tipo de Fluxo: Protheus -> RM
Mensagem: OrderStockTurnover
Versão: 31.002006
Mapeamento de Campos: http://tdn.totvs.com/x/jJ76EuJX6E

Tipo de Fluxo: RM Protheus -> ProtheusRM
Mensagem: InfoOfParcelValues Order
Versão: 14.000010
Mapeamento de Campos: http://tdn.totvs.com/x/op76E

Boletim Técnico: Processo de Sinistros e Multas

Honorários de Despachante

jJ76E

Tipo de Fluxo: Protheus -> RM
Mensagem: Order StockLevel
Versão: 31.002000
Mapeamento de Campos: http://tdn.totvs.com/x/jJ76ETipo de Fluxo: RM -> Protheus
Mensagem: InfoOfParcelValues
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/op76E L5r6E

Boletim Técnico: Controle de Abastecimento em Lote
Boletim Técnico: Processo de Abastecimento Manual
Boletim Técnico: Processo de Geração Conciliação de Honorários de DespachanteAbastecimentos

Ordem Gestão de Serviço de PneusDocumentos

Tipo de Fluxo: Protheus -> RM
Mensagem:

...

Order
Versão:

...

4.

...

010
Mapeamento de Campos: http://tdn.totvs.com/x/

...

jJ76E

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

Boletim Técnico: Processo de Geração de Documentos

Gestão de Multas

Tipo de Fluxo: Protheus -> RM
Mensagem: Request Order
Versão: 14.010
Mapeamento de Campos: http://tdn.totvs.com/x/-476EjJ76E

Tipo de Fluxo: Protheus RM -> RMProtheus
Mensagem: CancelRequest InfoOfParcelValues
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/apP6Eop76E

Boletim Técnico: Processo de Sinistros e Multas

Honorários de Despachante

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelMaintenanceOrder Order
Versão: 14.000010
Mapeamento de Campos: http://tdn.totvs.com/x/bpT6EjJ76E

Tipo de Fluxo: Protheus RM -> RMProtheus
Mensagem: StockLevel InfoOfParcelValues
Versão: 1.001000
Mapeamento de Campos: http://tdn.totvs.com/x/L5r6Eop76E

Boletim Técnico: Processo de Geração de Honorários de Despachante

Ordem de Serviço de Pneus

Transferência de Pneu

Tipo de Fluxo: Protheus -> RM
Mensagem: StockTurnover
Versão: 1.006
Mapeamento de Campos: http://tdn.totvs.com/x/uJX6E

Tipo de Fluxo: RM -> Protheus e Protheus -> RM
Mensagem: StockLevelMaintenanceOrder
Versão: 1.001002
Mapeamento de Campos: http://tdn.totvs.com/x/L5r6E

Boletim Técnico: Processo de Transferência de Pneus

Ordem de Serviço Terceiros

25P6E

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

O fluxo completo da ordem de serviço é descrito no anexo Fluxo da ordem de serviço no SigaMNT.

RM -> Protheus
A mensagem de ordem de serviço será enviada ao SigaMNT pelo BackOffice RM somente quando o movimento for faturado, para informar a alteração do status da OS para “Faturado”.

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.

...

-476E

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelRequest
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/apP6E

Tipo de Fluxo: Protheus -> RM
Mensagem: CancelMaintenanceOrder
Versão: 1.000
Mapeamento de Campos: http://tdn.totvs.com/x/bpT6E

Tipo de Fluxo: Protheus -> RM
Mensagem: StockLevel
Versão: 1.001
Mapeamento de Campos: http://tdn.totvs.com/x/L5r6E

Boletim Técnico: Processo de Ordem de Serviço de Pneus

Transferência de Pneu

Tipo de Fluxo: Protheus -> RM
Mensagem: StockTurnover
Versão: 1.006
Mapeamento de Campos: http://tdn.totvs.com/x/uJX6E

Tipo de Fluxo: Protheus -> RM
Mensagem: StockLevel
Versão: 1.001
Mapeamento de Campos: http://tdn.totvs.com/x/L5r6E

Boletim Técnico: Processo de Transferência de Pneus

Ordem de Serviço Terceiros

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

O fluxo completo da ordem de serviço é descrito no anexo Fluxo da ordem de serviço no SigaMNT.

RM -> Protheus
A mensagem de ordem de serviço será enviada ao SigaMNT pelo BackOffice RM somente quando o movimento for faturado, para informar a alteração do status da OS para “Faturado”.

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.

Protheus -> RM
A mensagem de ordem de serviço será enviada ao BackOffice RM pelo SigaMNT nas seguintes circunstâncias:

Ao cadastrar uma ordem de serviço corretiva com status “Liberada”.

Ao efetuar a liberação de uma ordem de serviço corretiva.

Ao finalizar uma ordem de serviço.

Na reabertura da ordem de serviço.

Restrições e Pontos de Atenção

Expandir

title	Restrições e Pontos de Atenção (Clique aqui)

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.

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,

Ao cadastrar uma ordem de serviço corretiva com status “Liberada”.

Ao efetuar a liberação de uma ordem de serviço corretiva.

Ao finalizar uma ordem de serviço.

Na reabertura da ordem de serviço.

Como fazer

Videos com exemplo dos Processos:

Restrições e Pontos de Atenção

Expandir

title	Restrições e Pontos de Atenção (Clique aqui)

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.

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 Município, Estado e País
Não faz parte do escopo da integração efetuar carga de dados referentes ao Município, 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

GAPs Funcionais e Pontos de Atenção MNT x Officina

Expandir

title	GAPs 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:

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 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:

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.
Criar tabela para listar os equipamentos atendidos pelo contrato. Para isso se sugere os seguintes campos:

Filial
Número do Contrato
Bem (ST9)
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)

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.
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:

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:
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:

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.

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.
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.

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.

Check list de suporte da aplicação

Executar a ferramenta de Diagnósticos da integração

...

title	Cadastrar De-para das Unidades de Medida padrão

, 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.
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.

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.

Check list de suporte da aplicação

Executar a ferramenta de Diagnósticos da integração

...

Anexos

Segue abaixo como cadastrar o de-para das unidades de medida padrão.
Observação: No exemplo foi criado para a unidade de medida UN, é necessário fazer para as demais, conforme a cita nas informações da unidade de medida.

No RM Acessar o menu Integração | Mensagem Única | De-para:

...

Incluir um novo Registro de acordo com os dados abaixo:

Image Removed

...

Image Removed

...

Acessar o SIGACFG no Protheus em Ambiente | Schedule | De/Para Mensagem Única:

...

Incluir um novo Registro de acordo com os dados abaixo:

Image Removed

Exemplo:

Image Removed

Observação: Alguns dados podem alterar de acordo com o código da empresa, nível de gestão e etc.

...

title	Cadastrar os valores Default para Plano de Contas

Para integrar esta entidade, o PROTHEUS exige que sejam cadastrados valores default para Plano de Contas em sua base (para cada filial), com os seguintes parâmetros:

Código: 001

Descrição: “Default Integração”

Classe de conta: Analítica

...

Acessar o Protheus no Ambiente 1 - Ativo Fixo

Acessar Cadastros | Plano de Contas

...

Expandir
title Fluxo da ordem de serviço no SigaMNT (status e pontos de integração)
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 relacionamento das solicitações de compra/armazém e baixas de estoque com OS oriundas do SigaMNT serão feitos utilizando as tabelas de relacionamento de cópia por referência, inserido manualmente nos extensions.
Insumos inseridos no SigaMNT como realizados devem efetuar diretamente baixa de estoque no BackOffice. Fica a cargo do SigaMNT a consulta de saldo em estoque no BackOffice e, não havendo em estoque (e o parâmetro não permite estoque negativo), o mesmo não deverá possibilitar o cadastramento deste novo insumo.
Para o BackOffice o novo insumo “realizado” deverá significar uma baixa no estoque (movimento de baixa).
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.
Solicitações já finalizadas devem gerar uma solicitação/movimento de entrada (ou o inverso da solicitação original). Este processo não foi definido na versão inicial da integração.
Movimentos baixados podem ser revertidos somente se não existir contabilização (lançamento financeiro e contabilização) internamente ao BackOffice, caso contrário o mesmo retornará o respectivo erro.
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.
Ao confirmar a alteração, submetendo o formulário, deve-se sinalizar ao BackOffice para cancelar/estornar a solicitação anterior e efetuar uma nova baixa.
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:
Caso seja inserida alguma baixa de estoque endereçada a uma OS do SigaMNT, originada por uma solicitação de estoque ou não, deve-se informar o mesmo, via respectiva mensagem única, para que seja inserido o insumo realizado.
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.
Deve-se atentar para que sejam enviados somente os itens a serem considerados no custo da OS, visto que este movimento poderá ser faturado.
Caso não deseje especificar todos os custos da OS ao faturar deve-se enviar somente o item de serviço com o custo total.
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:
Cancelar no BackOffice a baixa de itens constantes como realizados na OS.
Enviar mensagem de Cancelamento da OS.
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
Mensagem de cadastro da ordem de serviço é enviada ao RM.
Movimento de OS é cadastrado com status “Em Andamento” (“E”).

Passo 3: OS é finalizada no SigaMNT
Mensagem de alteração de Ordem de Serviço é enviada ao RM com novo Status.
Movimento de OS é atualizado e status vai para “A Faturar” (“A”).

Passo 4 (Opcional): OS é reaberta no SigaMNT
Mensagem de alteração de Ordem de Serviço é enviada ao RM com novo Status.
Movimento de OS é atualizado e status vai para “Em Andamento” (“E”).
Movimento segue fluxo normal de uma OS em andamento.

Passo 5 (Opcional): OS é faturada no RM
Movimento de OS é faturado no RM.
Mensagem de alteração de Ordem de Serviço é enviada ao RM com novo Status (“Faturado”).
Diagrama de sequência da integração Protheus SigaMNT x BackOffice RM
...

Informação completa sobre processo de inclusão de ordens de serviço no link abaixo:
Backoffice RM x Protheus SigaMNT - Processo Incluir de Ordem de Serviço

Páginas filhas

Versões comparadas

Versão antiga 66

Nova versão 101

Chave

Manual da Integração Manutenção de Ativos/Gestão de Frotas x BackOffice RM - Mensagem Única EAI 2.0

Contexto de negócio

Sistemas Envolvidos

Integração

Pré-requisitos instalação/implantação/utilização

Controle de Versão

Suporte

Escopo

Transações/Entidades/Mensagens únicas

Cadastros

Processos

Processos

Restrições e Pontos de Atenção

Como fazer

Restrições e Pontos de Atenção

GAPs Funcionais e Pontos de Atenção MNT x Officina

Check list de suporte da aplicação

Check list de suporte da aplicação

Anexos

Páginas filhas

Histórico da Página

Versões comparadas

Versão antiga 66

Nova versão 101

Chave

Manual da Integração Manutenção de Ativos/Gestão de Frotas x BackOffice RM - Mensagem Única EAI 2.0

Contexto de negócio

Sistemas Envolvidos

Integração

Pré-requisitos instalação/implantação/utilização

Controle de Versão

Suporte

Escopo

Transações/Entidades/Mensagens únicas

Cadastros

Processos

Processos

Restrições e Pontos de Atenção

Como fazer

Restrições e Pontos de Atenção

GAPs Funcionais e Pontos de Atenção MNT x Officina

Check list de suporte da aplicação

Check list de suporte da aplicação

Anexos