Histórico da Página

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), Unidade (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.

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.

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.

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.

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

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