Histórico da Página
INTEGRAÇÃO TMS X Cockpit Logístico
Contexto de negócio (Introdução)
A integração entre o módulo TMS e o Cockpit Logístico tem como objetivo sincronizar os dados cadastrais do Protheus e as demandas de transporte, cuja execução é registrada e controlada pelas rotina do módulo TMS por empresas-usuárias prestadoras de serviço de transporte. Esses dados são utilizados pelo Cockpit Logístico para efetuar a programação de transporte montando viagens que atinjam parâmetros pré-estabelecidos, atendendo às restrições existentes e proporcionando a melhor composição de cargas visando a diminuição dos custos e o cumprimento dos níveis de serviço com os clientes.
A integração dos dados cadastrais também atende à integração do ERP Protheus quando utilizado por empresas-usuárias embarcadoras; nesse caso vide o documento de integração OMS X Cockpit Logístico .
Sistemas Envolvidos
Cockpit Logístico
Sistema vertical desenvolvido pela Neolog, empresa do ecossistema TOTVS, que dispõe de módulos para Planejamento da Malha de Distribuição, Programação de Transportes e Monitoramento de Cargas. A Programação de Transportes gera a roteirização e o arranjo das cargas, com base na demanda de transportes enviada pelo ERP, considerando as configurações das restrições logísticas e as funções-objetivos da otimização. São exemplos de funções-objetivo: máximo aproveitamento e máxima ocupação dos veículos, diminuição da quantidade de viagens e diminuição da despesa de frete total.
TMS - Transportation Management System
É um módulo integrante da linha Microsiga Protheus que está integrado ao BackOffice do ERP Microsiga Protheus. Tem como objetivo controlar os processos operacionais relacionados à prestação de serviços de transporte de cargas. É utilizado por empresas Transportadoras de Cargas e Operadores Logísticos.
Integração
A integração é realizada por intermédio de arquivo XML, utilizando os Web Services disponibilizados pelo Cockpit Logístico, sem transformação de mensagens e sem utilização de sistemas intermediários (TOTVS EAI, TOTVS ESB, etc.).
Escopo
Possibilitar a integração dos dados cadastrais do backoffice Microsiga Protheus e de demandas de transporte do TMS Protheus para o Cockpit Logístico da Neolog.
Pré-requisitos instalação/implantação/utilização
Cockpit Logístico na versão\release 5.6.1.
Parâmetros de aquisição ativos (acesso pelo menu em Administração - Integração).
Web Services ativos.
Datasul
Não se aplica.
Logix
Não se aplica.
Protheus
Protheus versão 11.5 ou superior.
Parâmetro de integração com Cockpit Logístico ativo (MV_CPLINT == .T.)
Web Service de integração válido informado (MV_CPLURL)
Todos os parâmetros citados encontram-se no programa Parâmetros de Integração Cockpit Logístico (OMSXCPL1) que pode ser acessado pelo menu Atualizações - Cockpit Logístico.
Documento de Transporte:
| Título | Parâmetro | Lista | Valor Inicial | Validação | Aplicação |
|---|---|---|---|---|---|
| Integração Cockpit Logístico? | MV_CPLINT | 1=Sim;2=Não | 2=Não | Indica se a integração está ativa | |
| Endereço WebService | MV_CPLURL | em branco | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | URL dos Web Services do Cockpit Logístico utilizadas pelo TMS para envio de dados | |
| Regional | MV_CPLREG | em branco | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | Código da Regional da instalação do Cockpit Logístico que está integrada ao TMS | |
| Embarcador | MV_CPLEMB | em branco | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | Código de um Embarcador do Cockpit Logístico. Todos os Produtos integrados integrados do TMS para o Cokpit Logístico serão relacionados a um mesmo Embarcador no Cockpit Logístico, pois no TMS a relação variável de produto x cliente é utilizada (opcionalmente) apenas na importação de Notas Fiscais de Cliente pelo EDI | |
| Integrar Localidades do Exterior | MV_CPLEX | 1=Sim;2=Não | 2=Não | Informar se devem ser integradas para o Cockpit Logístico as localidades (filiais, clientes e solicitantes) com endereço fora do Brasil | |
| Invólucro Padrão | MV_CPLINV | em branco | Código de um Invólucro (~ embalagem) do Cockpit Logístico. Todos os itens de Pedidos de Transporte recebidos do TMS no Cockpit Logístico serão associados a esse invólucro pois não há uma entidade no TMS que corresponda exata e obrigatoriamente a esse dado do Cockpit Logístico. Recomenda-se informar um invólucro cujas medidas sejam obtidas do item do pedido (essa característica é parametrizada no Cockpit Logístico). | ||
| Origem dos Dados | MV_CPLIDS | PROTHEUS | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | Código de origem de dados que é cadastrada no Cockpit Logístico. Esse código será relacionada a todos os pedidos de transporte gerados pelo TMS no Cockpit. É utilizado para segregar os pedidos no Cockpit e determinar qual a URL na qual as viagens dos pedidos devem ser transmitidas. | |
| Categoria de Produto | MV_CPLCAT | 1=Grupo Produto;2=Padrão Cockpit | 2=Padrão Cockpit | Para o Cockpit Logístico, categorias de Produto são agrupamentos relevantes de produtos com características logística semelhantes. Com esse parâmetro pode-se determinar se a categoria dos produtos integrados do TMS para o Cockpit Logístico: (1=Grupo Produto) será o código do grupo do produto do TMS ou (2=Padrão Cockpit) será informada por alteração manual em cada produto no Cockpit Logístico. Com a opção deve-se cadastrar as Categorias de Produtos no Cockpit Logístico com os mesmos códigos dos Grupos de Produtos do TMS pois não há Web Serivce de integração para essa tabela. | |
| Tipo Pedido Coleta | MV_CPLTP1 | em branco | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" e MV_INTTMS == .T. Habilitar apenas quando MV_INTTMS == .T. | Código de um Tipo de Pedido cadastrado no Cockpit Logístico. Esse parâmetro serve para diferenciar os pedidos de transporte enviados do TMS para o Cockpit conforme seu tipo de serviço no TMS: coleta, transporte e entrega. A diferenciação é opcional e pode ser usada para implementar diferentes condições na otimização do Cockpit Logístico de acordo com a necessidade de cada empresa-usuária. | |
| Tipo Pedido Transporte | MV_CPLTP2 | em branco | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" e MV_INTTMS == .T.. Habilitar apenas quando MV_INTTMS == .T. | Código de um Tipo de Pedido cadastrado no Cockpit Logístico. Esse parâmetro serve para diferenciar os pedidos de transporte enviados do TMS para o Cockpit conforme seu tipo de serviço no TMS: coleta, transporte e entrega. A diferenciação é opcional e pode ser usada para implementar diferentes condições na otimização do Cockpit Logístico de acordo com a necessidade de cada empresa-usuária. | |
| Tipo Pedido Entrega | MV_CPLTP3 | em branco | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" e MV_INTTMS == .T. Habilitar apenas quando MV_INTTMS == .T. | Código de um Tipo de Pedido cadastrado no Cockpit Logístico. Esse parâmetro serve para diferenciar os pedidos de transporte enviados do TMS para o Cockpit conforme seu tipo de serviço no TMS: coleta, transporte e entrega. A diferenciação é opcional e pode ser usada para implementar diferentes condições na otimização do Cockpit Logístico de acordo com a necessidade de cada empresa-usuária. | |
| Considerar entregar em vez de transferir | MV_CPLENT | 1=Sim;2=Não | 2=Não | Parâmetro que define se o tipo de serviço "Transferência" do documento de transporte admite ser alterado para "Entrega" no retorno da viagem otimizada gerada pelo Cockpit Logístico. Com a opção "1=Sim" o destinatário dos pedidos de transporte gerados com base em documentos de transferência será o cliente (destinatário final) e não a filial de destino, ficando a cargo do Cockpit Logístico determinar qual a melhor opção de transporte a ser efetuada (transferir para outra filial e entregar ou entregar direto). |
| Título | Parâmetro | Lista | Valor Inicial | Consulta Padrão | Validação |
|---|---|---|---|---|---|
| Modo Debug | MV_CPLDBG | 1=Sim;2=Não | "2" | ||
| Caminho da pasta de mensagens | MV_CPLLOG | Preenchimento obrigatório quando MV_CPLDBG == "1" e MV_CPLINT == "1" | |||
| Tipo Pedido Coleta | MV_CPLTP1 | ||||
| Tipo Pedido Transporte | MV_CPLTP2 | ||||
| Tipo Pedido Entrega | MV_CPLTP3 | ||||
| Modo Geração Viagens | MV_CPLAUT | 1=Automático;2=Manual | "2" | ||
| Rota Viagem Coleta | MV_CPLROT1 | DA8 | |||
| Rota Viagem Transporte | MV_CPLROT2 | DA8 | |||
| Rota Viagem Entrega | MV_CPLROT3 | DA8 |
RM
Não se aplica.
Instalação/Atualização
Vide tópico Pré-requisitos instalação/implantação/utilização.
Datasul
Não se aplica.
Logix
Não se aplica.
Protheus
Vide tópico Pré-requisitos instalação/implantação/utilização.
RM
Não se aplica.
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 definidas 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 RM Conector e Backoffice Protheus estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.
Observação: Este modelo de suporte está sendo revisado pela TOTVS.
Transações/Entidades/Mensagens únicas
| Entidade(s) Protheus | Tipo | Código | Web Service | Método | Entidade Cockpit | Observações |
|---|---|---|---|---|---|---|
| Produto | Cadastro | SB1 e SB5 | ProductAcquisitionService | updateProducts | Produto | |
| Filial | Cadastro | SM0 | LocalityAcquisitionService | updateLocalities | Localidade | As filiais assumem o papel de localidade quando são locais de carga ou descarga. Quando MV_CPLEX == "2" não integrar filial cuja unidade de federação não faça parte da lista de unidades de federação do Brasil. |
| Cliente | Cadastro | SA1 | LocalityAcquisitionService | updateLocalities | Localidade | Quando MV_CPLEX == "2" não integrar cliente com país informado diferente de 105 (Brasil). |
| Solicitante | Cadastro | DUE | LocalityAcquisitionService | updateLocalities | Localidade | Quando MV_CPLEX == "2" não integrar solicitante cuja unidade de federação não faça parte da lista de unidades de federação do Brasil. |
| Endereço de Solicitante | Cadastro | DUL | LocalityAcquisitionService | updateLocalities | Localidade | Quando MV_CPLEX == "2" não integrar endereço de solicitante cuja unidade de federação não faça parte da lista de unidades de federação do Brasil. |
| Tipo de Veículo | Cadastro | DUT | VehicleAcquisitionService | updateVehicles | Veículo | |
| Fornecedores | Cadastro | SA2 | CarrierAcquisitionService | updateCarriers | Transportador | Serão integrados somente os fornecedores com RNTRC informado. A correspondência entre as entidades Fornecedor (SA2) e Transportador é válida apenas nas instalações do Protheus utilizadas por empresas Transportadoras (MV_INTTMS == .T.) |
| Documento de Transporte | Processo | DUD, DT6, DTC, DYD e DTE | OrderAquisitionService | createOrders | Pedido de Transporte | |
| Viagens | Processo | DJY e DJZ | ReleasedTripPublishRequestService | releaseTrip | Viagem |
A integração da operação de eliminação de registros não está disponível para todos os cadastros, por isso somente haverá integração nas ações de alteração e inclusão.
em andamento...
Fluxo das Informações
Cadastros
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Entidade>
Identificador da Mensagem: <mensagem>
Versão: <versão>
Módulo <marca 1>: <BackOffice – Gestão xxxxxxx>
Módulo <marca 2>: <SIGAXXX>
Tipo de Envio: <Assíncrona/Síncrona>
Mensagem Padrão | PROTHEUS | RM | ||
Tabela | Campo | Tabela | Campo | |
Code | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO * |
Description | CTO990 | CTO_DESC | GMOEDA | DESCRICAO |
Symbol | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO |
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
A seguir descrever as variações, particularidades da mensagem e processos (integração) de acordo com cada marca
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Processos
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Processo>
Tipo de Fluxo: Protheus -> RM
Mensagem: Request_1_000
Versão: 1.000
Descrição de todo o comportamento e funcionamento do processo. Breve contexto, origem, regras, integração (geração da mensagem, envio, recebimento no destino), o quê supostamente irá ocorrer no destino, retorno, impacto, consequências, o que foi afetado, como conferir, validar, etc o retorno.
Acrescentar um diagrama do processo.
A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Limitações / Restrições Gerais
Descreva limitações e restrições para cada fluxo descrito no tópico anterior. Exemplo:
- ERP1 envia ITEM cadastrado para o ERP2
ERP1 somente enviará o ITEM se este estiver em uma das famílias cadastradas no parâmetro FAMILIA_INTEGRACAO.
Se o tipo de valorização do estoque for FIFO.
- ERP2 envia PEDIDO cadastrado para o ERP1
O pedido recebido no ERP1 vindo do ERP2 estará bloqueado para alteração.
Como fazer (opcional)
Descreva os passos que viabilizem a integração.
Exemplo:
Os passos para viabilizar a integração são:
- No Logix ou no Protheus efetue o cadastro das seguintes informações: Clientes, fornecedores, transportadores, cidades, cotação de moeda e unidades de medida.
- No Logix cadastrar um novo depositante e efetuar toda a parametrização necessária para a operação de WMS.
- No Logix cadastrar um novo produto que seja controlado pelo WMS, para o depositante cadastrado anteriormente.
- No Logix efetuar um processo de recebimento para o produto cadastrado anteriormente, utilizando uma nota fiscal provisória (tipo “A”).
- No Protheus consultar a nota fiscal de recebimento que foi registrada no Logix, validando as informações recebidas.
- No Logix efetuar um processamento de regularização fiscal, efetuando a cobertura dos produtos recebidos anteriormente.
- No Protheus verificar se foi efetuado corretamente o relacionamento entre os dois documentos.
- No Logix efetuar um processo de expedição para o novo produto cadastrado, até o momento do envio da mensagem de integração de pedido de venda.
- No Protheus efetuar o faturamento do pedido de venda recebido.
- No Protheus verificar se a nota fiscal gerada contém todas as informações necessárias para o segmento de operador logístico (armazém geral).
- No Protheus efetuar a escrituração fiscal das notas fiscais, verificando se as regras da legislação deste segmento foram respeitadas.
- No Logix é possível consultar o número do pedido de venda gerado para as notas fiscais de retorno simbólico e conta/ordem no programa WMS6333 (Consulta de Documentos). Para os processos de faturamento de serviço o número do pedido está disponível no programa WMS6411 (Movimentos a Faturar).
Situações comuns (opcional)
Descreva situações problemáticas comuns que podem ocorrer durante o funcionamento da integração e como solucioná-los. Neste ponto também é importante dar instruções de como reconhecer e investigar problemas que podem vir a ocorrer durante a integração. Se houver, apresente tabelas de códigos e descrições de erros que a integração poderá apresentar.
Este tópico possivelmente será alimentado com as experiências durante o desenvolvimento da integração e poderá ser realimentado durante o uso da integração no cliente.
Exemplo 1:
Tratamento de erros de integração (Produto A)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Tratamento de erros de integração (Produto B)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Exemplo 2:
Quando uma mensagem é enviada do Logix para o Protheus, podem ocorrer situações em que o WebService não estará totalmente funcional. Nestes casos uma mensagem de erro genérica irá aparecer na tela:
Exemplo:
Erro ao enviar a mensagem de Cidade via Integração
Se o arquivo de log for analisado, poderemos ver a falha na comunicação com o sistema destino:
-------------------------------------------------------------------------------
WSCERR044 / Não foi possível POST : URL http://172.16.31.57:8011/ws/FWWSEAI.apw
ADVPL WSDL Client 1.080707 / tst on 20120315 08:49:51
-------------------------------------------------------------------------------
Para resolver este problema, verifique as configurações do sistema de destino, analisando o funcionamento do servidor utilizado para esta comunicação e a habilitação do endereço do WebService.
Checklist de suporte da aplicação
Crie um check-list de verificação de alguns pontos importantes para o funcionamento e atendimento da integração.
Instalação/Configuração
Relacione itens de verificação para garantir que a integração está corretamente instalada e configurada. Isto não pode ser uma cópia do procedimento de instalação/configuração, mas verificações pontuais que podem remeter aos itens da instalação.
Checklist de Verificações:
Relacione itens de verificações para que o atendente possa:
- Identificar o funcionamento da integração;
- Identificar a ocorrências de problemas;
- Coletar evidências do mau funcionamento relatado pelo cliente;
- Realizar possíveis ajustes na integração quanto à configuração ou negócio.
Anexos
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas