Carga Inicial de dados e migração de bases RM Officina para SigaMNT
Não faz parte do escopo da integração efetuar carga Inicial de dados ou migração de bases RM Officina para SigaMNT, ficando a cargo da implantação efetuar este serviço. Manutenção da sincronia das bases BackOffice RM e SigaMNT
Caso sejam efetuadas alterações por meios diferentes dos objetos de negócio apresentados na seção de cadastros como gatilhos de integração, as mesmas não serão encaminhadas ao SigaMNT, gerando incoerência entre as bases de dados. Um exemplo de alterações que gerariam esta incoerência é sistemas terceiros que efetuem alteração diretamente na base de dados, sem passar pelos objetos de negócio da linha RM. Visando facilitar a manutenção da sincronia das bases de dados, está disponível na pasta de objetos de negócio (“../CorporeRM/Objetos Gerenciais/Formulas Visuais”) arquivo “MOVWKF0019 - Sincronizacao_Total_SigaMNT.TotvsWF” com fórmulas visuais responsáveis por manter a base SigaMNT atualizada, que podem ser agendadas com a recorrência demandada pelo cliente.
Estas fórmulas visuais vêm com configuração padrão, mas podem ser customizadas da forma que melhor atender ao cliente. Um exemplo de customização seria a alteração das mesmas para sincronizar somente os registros da coligada corrente no momento do agendamento, ou somente enviar os registros que possuam um campo específico com um valor específico. Criação de novos tipos de relacionamento (TMOVRELAC-TIPORELAC)
Caso seja criado algum tipo de cópia por referência que não seja de relacionamento invertido, a constante “TiposRelacNaoInvertida” existente dentro da Extension da mensagem “StockTurnover” e da atividade de fórmula visual “MovInfoParcelaSigaMNT” deve ser alterada, adicionando o novo valor. Configuração do comportamento do tipos de movimento
Fica a cargo da equipe de implantação fazer a configuração dos tipos de movimento, devendo somente se ater aos requisitos mínimos descritos da sessão Parâmetros de Tipo de Movimento.
Algumas configurações, como série do movimento e controle de estoque, são críticas para o perfeito funcionamento do gerenciamento de estoque. O configurador da integração não faz atualizações
Devido a restrições no configurador das integrações o mesmo funcionará somente para a primeira instalação ou para inserção de novas entidades, visto que o mesmo não faz atualização de registros, somente inserção. Apropriação de custos não relacionados a OS
Não faz parte do escopo inicial o envio da apropriação de custos externos a OS ou ao custo de utilização de material, como pagamento de IPVA, seguro, depreciação e outros, mesmo que a mensagem “AppointmentCost” contemple estes. Mapa de Alocação de Equipamentos
Não faz parte do escopo inicial o envio do planejamento do Solum quanto a alocação de Equipamentos. Informações referentes aos cadastros de Municipio, Estado e País
Não faz parte do escopo da integração efetuar carga de dados referentes ao Municipio, Estado e País, ficando a cargo da implantação sincronizar estes dados e seu respectivo De-Para. Integração com TOP
Pelo entendimento de que não era utilizada e pela nova estrutura do SigaMNT foi descontinuada a integração do TOP com o Officina. Caracteres especiais na mensagem única
O EAI de mensagem única utiliza o EncodeUTF8 no envio das mensagens. O Protheus não considera os seguintes códigos da tabela ASCII que são: ASCII 129, ASCII 141, ASCII 143 , ASCII 144 e ASCII 157. Maiores informações podem ser obtidas através do link: http://tdn.totvs.com.br/display/tec/EncodeUTF8Cadastro de Cliente/Fornecedor (CustomerVendor)
Uma vez que já foi feito consenso que Cliente e Fornecedor são tratados na mesma mensagem (CustomerVendor), é responsabilidade do destinatário processar a mensagem da melhor forma possível para garantir a consistência dos dados na origem e no destino. Se o destino implementa uma única tabela, terá que manipular apenas um registro. Se implementa mais de uma tabela, tem que manipular até 2 registros.
Exemplo1: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Customer<Type>…
Como não dá para saber se este Cliente (<Type>Customer) é uma inclusão ou uma alteração (<Event>upsert), tem que verificar no de/para.
Se o EAI destino é capaz de cadastrar um único registro como ambos: deve verificar se já existe um registro com este ID, caso afirmativo fazer alteração deste registro para Cliente e alterar os demais campos, senão fazer inclusão.
Se o EAI destino NÃO é capaz de cadastrar um único registro como ambos: primeiro deve verificar se já existe um Fornecedor com este ID, caso afirmativo deve tentar excluir este Fornecedor (não conseguindo gerar uma exceção semelhante a “o código xx já é um fornecedor não pode ser excluído/alterado para tipo cliente.”). Segundo, deve verificar se já existe um registro de Cliente com este ID, caso afirmativo fazer alteração dos demais campos, senão fazer inclusão.
Exemplo 2: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Both<Type>…
Se o EAI destino é capaz de cadastrar um único registro como ambos, deve verificar se o ID já existe para definir se faz alteração ou inclusão.
Se o EAI destino tem 2 tabelas distintas, deve incluir/alterar um Cliente. E ainda incluir/alterar um fornecedor. | 