Integração Datasul X Cockpit Logístico

A integração entre o ERP Datasul e o Cockpit Logístico tem como objetivo automatizar e otimizar a programação e a roteirização das entregas de mercadorias e materiais.

INTEGRAÇÃO DATASUL X COCKPIT LOGÍSTICO

Sistemas Envolvidos

Cockpit Logístico

ERP Datasul

Integração

O que levou a criação da integração / o porquê da integração (Finalidade/Objetivo), de forma macro, o que será integrado do, por exemplo, Vertical com o ERP (BackOffice)

Explique o contexto de negócio ou do problema na qual esta integração estará inserida. Isto inclui o funcionamento da(s) ponta(s) envolvida(s).

Apresentar a integração como uma melhoria para o cenário ou como uma solução para o problema.

• Premissas
  Gerais, do Vertical, do BackOffice e dos demais artefatos/sistemas envolvidos
  Premissas Gerais
  Premissas A
  Premissas B

• Arquitetura (Tecnologia)

Escopo

Descreva, dado o contexto, qual o escopo de atuação da integração. Cite as áreas/perfis de usuários e funções impactadas. Se existe uma parte do contexto de negócio que a integração não tenta resolver, deixe explícito.

Defina exatamente o que a integração FAZ, o que ela NÃO FAZ e a sua finalidade.

[O conteúdo poderá estar disponível na ferramenta PMS – Painel de Gestão de Projetos, opção Plano do Projeto]

Como são os processos os que serão integrados, mas com uma visão geral e não só o ponto de integração caso contrário a homologação [ou outro que pegar o documento] não saberá do que se trata no sistema vertical, de forma sucinta, como funciona e o(s) ponto(s) de integração.

Citar a responsabilidade de cada produto.

Descrever com mais detalhes sobre o que será integrado (mas não ser especialista nas entidades/processos, pois suas particularidades serão descritas posteriormente) incluindo diagramas, prints, imagens, etc o que for interessante para auxiliar o entendimento.

Interessante aqui a inclusão de diagramas, imagens, lógicas, fluxo(s) do(s) processo(s) o que considerar interessante e agregador ao documento e ao escopo.

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

Relacione quais são os pré-requisitos (técnicos ou de negócio) para a integração. Este tópico não deve incluir informações da implantação normal do módulo, mas apenas informações específicas da integração. É como se este tópico já partisse do princípio que o módulo que será integrado já está normalmente instalado.

Entre os tópicos deste tópico podemos citar:

• Versões mínimas de produtos.
• Módulos ou programas que geram informações necessárias a integração. Muitas vezes a integração partirá de informações que somente são trabalhadas em um determinado programa ou processo, que deverá estar em uso no cliente.
• Ferramentas que são necessárias a integração, como: EAI, ESB, servidor de WebService etc.
• Aspectos legais nos quais as partes envolvidas na integração devem estar inseridas, caso as informações envolvidas sejam utilizadas para o cumprimento de alguma lei específica.
• Requisitos de hardware ou Software, como servidores, link de internet, capacidade de armazenamento e memória, sistema operacional.

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

Instalação/Atualização

Este tópico tem por objetivo orientar a instalação da integração, visando o seu funcionamento completo. Instalação de produtos ou ferramentas necessárias podem referenciar outros documentos existentes, desde que estejam disponíveis no repositório de documentação da TOTVS ou sejam enviados junto com o documento da integração em si. As informações mínimas necessárias para teste tópico são:

• Procedimentos que devem ser observados quando um dos produtos for atualizado.
• Configuração necessária que deve ser realizada em arquivos de configuração ou programas de parâmetros etc.
• Arquivos diversos que devem ser mantidos em determinados locais para o funcionamento da integração, exemplo: xml, xsd.
• Atualizações necessárias em banco de dados ou instruções para que elas sejam feitas.
• Processos, módulos ou programas que precisam ser instalados ou atualizados. Deve ser definida a versão mínima necessária dos programas envolvidos.
• Ferramentas, servidores ou serviços que precisam ser disponibilizados e configurados, o que pode gerar necessidade de novo hardware ou aumento de capacidade. Exemplo: serviço de WebService.
• Instruções para habilitar a comunicação da ferramenta EAI entre as partes, quais rotas devem ser definidas ou como as transações devem ser habilitadas.

Observação: evite o uso de Prints de telas, facilitando, assim, o trabalho de tradução e versionamento deste documento.

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

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

Apresente quais as transações/entidades que são trocadas e quem envia a informação para quem. Pode (e recomenda-se) ter um diagrama, uma tabela ou afins que apresente este fluxo.

Relacione quais são as mensagem únicas (TOTVSMessage) utilizadas e qual o seu relacionamento com as entidades já existentes do ERPs envolvidos.

Exemplos:

 Image Removed

Image Removed

Fluxo das Informações

Para cada fluxo de informação descreva, se necessário, alterações de comportamento que o respectivo produto irá sofrer. Por exemplo: quando o Logix recebe o PEDIDO de OUTRO ERP, este pedido não poderá ser alterado no Logix.

Liste quais as entidades integradas e como é o mapeamento entre as diferentes estruturas. Por exemplo: Classe no sistema A vira categoria no sistema B, o campo X é refletido no campo Y etc.

Liste quais transações/operações a integração fará com as entidades relacionadas. Exemplo: Insert de PEDIDO, Insert, update de ITEM, buscar saldo em estoque do ITEM no dia X ou buscar dados do FUNCIONÁRIO.

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. 

ERP Datasul

Sistema de BackOffice para gestão de empresas com ênfase no segmento de Manufatura. Disponibiliza módulos de gestão e controle da distribuição com foco nos requisitos comerciais, fiscais e tributários, entre eles: Pedidos de Venda, Faturamento e Embarques.

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 Cadastros de Transportadores, Locais de Entrega, Itens e Tipos de Carga do Datasul para o Cockpit Logístico da Neolog (a partir do release 12.1.7)

Possibilitar as integrações dos processos de envio de pedidos de venda, por intermédio das simulações ou embarques-remessa ao Cockpit e gerar os embarques no Datasul com o resultado as viagens planejadas no Cockpit (a partir do release 12.1.8).

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

Versão\release 12.1.7/12.1.8

Parâmetro de integração via Web Service ativo.

Parâmetros de integração com Cockpit Logístico ativo.

Parâmetros de integração de cada cadastro ativo.

Todos os parâmetros citados encontram-se no programa Parâmetros de Integração Cockpit Logístico (CD0090) que pode ser acessado pelo menu Logística - Embarques - Cadastros.

Instalação/Atualização

 Vide tópico Pré-requisitos instalação/implantação/utilização.

Datasul

 Vide tópico Pré-requisitos instalação/implantação/utilização.

Controle de Versão

O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução das mensagens de integração 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 é de responsabilidade de todas as linhas, sendo assim as equipes de suporte dos produtos Cockpit Logístico (Neolog) e Backoffice Datasul (Vendas e CRM) estarão aptas a fazer a primeira análise e quando necessário, repassar para a equipe mais adequada em cada caso.

Observação: Esse modelo de suporte está sendo revisado pela TOTVS.

Transações/Entidades/Mensagens únicas 

Fluxo das Informações

Os cadastros devem ser realizados no Datasul e integrados para o Cockpit Logístico, a ativação da integração, no entanto, não impede a inclusão, alteração e exclusão de registros no Cockpit Logístico, mas esse procedimento não é recomendado pois as operações realizadas sobre os cadastros no Cockpit Logístico não são replicadas para os respectivos cadastros no Datasul.

Apenas as operações de inclusão e alteração são consideradas na integração e são efetuadas sempre que ocorrerem, mesmo que apenas campos que não são integrados sejam alterados no Datasul. A operação de eliminação sobre os registros de cadastros não é integrada pois não é possível verificar a integridade referencial no sistema de destino para considerá-la como restrição de eliminação dos registros no Datasul.

O sucesso das operações de inclusão e alteração de registros pode ser verificado acessando o programa de consulta no menu do Cockpit Logístico em: Interface - Log. O sistema de origem dos dados não recebe o status do processamento dos registros enviados, por isso considera integrado com base apenas na confirmação de recepção da mensagem de integração.

Os cadastros possuem um programa (CD9190 - Integração Batch Cockpit Logístico) que possibilita a carga/atualização dos registros em lote, ele pode ser acessado pelo menu do Datasul em: Logística - Embarques - Cadastros.

As falhas de comunicação entre os sistemas e o registro das integração que não obtiveram sucesso na transmissão dos dados de cadastros poderão ser consultados pelo programa Parâmetros de Integração Cockpit Logístico (CD0090) que dá acesso aos programas CD0082 (Histórico de Falhas de Conexão) e CD0092 (Reprocessar Integração Cockpit Logístico), responsáveis por listar essas informações, respectivamente. O programa CD0092 (no menu em: Logística - Embarques - Cadastros) também possibilita o reenvio dos registros com falha de transmissão, manualmente ou por intermédio de agendamento RPW (CD0092RP).  

Para as ocorrências de falha de comunicação também é possível configurar o envio de aviso eletrônico por intermédio de parâmetros disponíveis no programa CD0090.

Nas ocasiões em que o sistema destino precisar ficar indisponível para integração é possível informar no Datasul que a integração está temporariamente suspensa (CD0090) evitando perda de desempenho com tentativas de transmissão de dados sem sucesso. Nesse caso os registros incluídos ou alterados serão registrados como pendentes de envio na lista de falhas de integração e poderão ser reenviados pelo programa CD0092.

Cadastros

A seguir o diagrama de fluxo de informações relacionando os cadastros integrados entre Datasul e Cockpit Logístico. Após o diagrama serão descritos os detalhes da integração de cada cadastro.

Image Added 

LOCAIS DE ENTREGA DE CLIENTES

Para que a integração do cadastro de Localidades seja realizada é obrigatório marcar os seguintes parâmetros (no menu do Cockpit Logístico em: Administração - Integração):

• Aquisição ligada
• Atualização permite inserir
• Aquisição ativa para localidades

 Lista de programas relacionados aos Locais de Entrega de Cliente do Datasul que integram com o Cockpit Logístico:

Correspondência entre os campos:

TRANSPORTADORES

Para que a integração do cadastro de Transportadores seja realizada é obrigatório marcar os seguintes parâmetros (no menu do Cockpit Logístico em: Administração - Integração):

•     Aquisição ligada

•     Atualização permite inserir

•     Aquisição ativa para transportadora

Além disso é necessário cadastrar um Transportador default no Cockpit Logístico e informá-lo como Transportador Piso, Padrão e Teto na configuração de Entidades Padrões. No cadastro do Transportador default devem ser informados todos os dados que são obrigatórios na operação de inclusão:

•     Calculador de Tipo de Serviço

•     Agrupador

•     Máxima Distância de Dead-head

•     Máxima Distância Total de Dead-head

•     Horizonte de Abertura

•     Calculador de Frete para Viagem

•     Justificativa de Auto-rejeite

Lista de programas relacionados aos Transportadores do Datasul que integram com o Cockpit Logístico:

 Correspondência entre os campos:

ITENS

Lista de programas relacionados aos Itens do Datasul que integram com o Cockpit Logístico:

Correspondência entre os campos:

Para que a integração do cadastro de Produtos seja realizada é obrigatório marcar os seguintes parâmetros (no menu do Cockpit Logístico em: Administração - Integração):

• Aquisição ligada
• Atualização permite inserir
• Aquisição ativa para produtos

Além disso é necessário cadastrar Produtos defaults no Cockpit Logístico e informá-los como Veículo Piso, Padrão e Teto na configuração de Entidades Padrões para cada formato (caixa, cilindro, etc.). No cadastro do Produto padrão

Cadastros

...

Image Removed 

LOCAIS DE ENTREGA DE CLIENTES

TRANSPORTADORES

Para que a integração do cadastro de Transportadores seja realizada é obrigatório marcar os seguintes parâmetros (menu Administração/Integração) do Cockpit Logístico:
    Aquisição ligada
    Atualização permite inserir
    Aquisição ativa para transportadora

Além disso é necessário cadastrar um Transportador default no Cockpit Logístico e informá-lo como Transportador Piso, Padrão e Teto na configuração de Entidades Padrões. No cadastro do Transportador default devem ser informados todos os dados que são obrigatórios na operação de inclusão, entre eles aqueles que não são disponibilizados no XML de integração:    Calculador de Tipo de Serviço
    Agrupador
    Máxima Distância de Dead-head
    Máxima Distância Total de Dead-head
    Horizonte de Abertura
    Calculador de Frete para Viagem
    Justificativa de Auto-rejeite

• Categoria de Produto

Sugere-se no cadastro dos Produtos que serão utilizados como "piso" informar o menor valor possível para peso, altura, largura e comprimento; e no cadastro dos Produtos que serão utilizados como "teto" informar o maior valor possível para peso, altura, largura e comprimento. É necessário haver um produto piso exclusivo para cilindro, pois nesse formato a altura deve ser igual a zero.

TIPOS DE CARGA 

Lista de programas relacionados aos Tipos de Carga (também chamados de Tipos de Embarque) do Datasul que integram com o Cockpit Logístico:

 Correspondência Correspondência entre os campos:

ITENS

TIPOS DE CARGA 

Limitações/Restrições

Descreva limitações e restrições para a integração que está sendo descrita.

Para que a integração do cadastro de Veículos seja realizada é obrigatório marcar os seguintes parâmetros (no menu do Cockpit Logístico em: Administração - Integração):

• Aquisição ligada
• Atualização permite inserir
• Aquisição ativa para veículos

Além disso é necessário cadastrar um Veículo default no Cockpit Logístico e informá-lo como Veículo Piso, Padrão e Teto na configuração de Entidades Padrões. No cadastro do Transportador default devem ser informados todos os dados que são obrigatórios na operação de inclusão:

• Similaridade (Veículo similar)
• Prioridade
• Baú
• Modal

Processos

A Solução de Programação do Neolog automatiza a inteligência logística da empresa. É ela a responsável por receber as demandas de transporte, olhar todas as possibilidades da malha logística da empresa e encontrar a melhor e mais rentável opção para entrega de todos os pedidos. 

O diagrama abaixo demonstra o processo de integração das transações de envio de pedidos, liberação de viagens e desbloqueio de viagens:

Image Added

Fluxos de processos que contemplam a solução de integração:

1) Envio de pedidos de venda

Tipo de Fluxo: Datasul -> Cockpit-Neolog 

Mensagem: OrderAquisitionService

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
Image Removed

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)

Tratamento de erros de integração (Produto B)

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.

O envio de pedido de venda poderá ocorrer através das simulações (sem empenho do estoque) ou através dos embarques (com empenho do estoque), deverá ser parametrizado no programa de configuração da integração (cd0090) se o envio dos pedidos será a partir do programa de geração de simulações (eq0503) ou se será a partir da preparação de embarque (eq0506).

Quando a configuração é feita para ser realizada pela simulação, ao clicar no check verde da simulação, após a escolha dos pedidos, é realizado o envio dos pedidos da simulação para o Neolog.

Quando a configuração é feita para ser realizada pelo embarque, ao clicar no check verde do embarque, após a escolha dos pedidos, é realizado o envio dos pedidos do embarque para o Neolog. Também será realizado o envio dos pedidos do embarque pela rotina de geração batch de embarques. Estes embarques são chamados de embarque-remessa, e não poderão ser enviados ao WMS, nem faturados, pois servirão apenas para envio dos pedidos ao Neolog com a reserva do estoque.

Todos os pedidos escolhidos em uma simulação ou embarque-remessa, terão seu número de controle no Neolog formado pela composição da chave: número do pedido (nr-pedido) + nr simulação ou número do embarque.

Lista de programas relacionados ao envio de pedidos ao Cockpit Logístico:

Quando o parâmetro da integração estiver marcado para envio dos pedidos pela simulação de embarque, as simulações assumirão as seguintes situações:

int-2 = 0 - Não Otimiza - no momento da geração da simulação, se o tipo de embarque/carga não estiver marcando, não serão enviados os pedidos da simulação para o Cockpit Logístico.
Int-2 = 1 - Envio OK - O sistema realizou o envio da mensagem para o Neolog sem erros no envio.(estrutura)
int-2 = 2 - Erro Envio - deveria integrar (função  parametrizada e tipo de carga para integrar com Neolog ) mas ocorreu algum erro na hora de envio para o Neolog. Ex: Erro chamada ao web service.
Int-2 = 3 - Em Otimização - Quando a simulação está em alguma otimização no Neolog.(parâmetro previsto, mas não atualizado pelo CPL).
Int-2 = 4 - Desbloqueado –  usuário desbloqueou manualmente poderá ser alterado a simulação ou gerado o embarque manualmente.

Quando o parâmetro da integração estiver marcado para envio dos pedidos pela rotina de pré-faturamento, o embarque assumirá as seguintes situações:

int-2 = 0 - Não Otimiza - no momento da geração do embarque, se o tipo de embarque/carga nao estiver marcando, não serão enviados os pedidos do embarque para o Cockpit Logístico.
Int-2 = 1 - Envio OK - O sistema realizou o envio da mensagem para o Neolog sem erros no envio.(estrutura)
int-2 = 2 - Erro Envio - deveria integrar (função  parametrizada e tipo de carga para integrar com Neolog ) mas ocorreu algum erro na hora de envio para o Neolog. Ex: Erro chamada ao web service.
Int-2 = 3 - Em Otimização - Quando o embarque está em alguma otimização no Neolog  (parâmetro previsto, mas não atualizado pelo CPL).
Int-2 = 4 - Desbloqueado –  usuário desbloqueou manualmente o embarque, para alterá-lo ou fatura-lo sem aguardar a viagem do Cockpit Logístico. 

A mensagem de envio de pedidos de venda ao Cockpit Logístico é composta pelos seguintes campos:

Os pedidos gerados na integração poderão consultados na "cesta" na rotina de análise no modulo programação disponível no aplicativo CPL do Neolog.

Image Added

2) Manutenções da simulação/embarque-remessa no Datasul 

Quando uma simulação ou embarque-remessa for enviado ao Neolog, eles não poderão ser alterados, a não ser que a mesma seja desbloqueada no monitor da integração(eq0515);

Se a simulação ou embarque-remessa necessitem ser desbloqueados e alterados, as alterações poderão ser realizadas no Datasul, caso os pedidos não estiverem sido alocados em uma viagem no CPL. 

Se pedido estiver em uma viagem, irá depender do retorno que o CPL irá retornar para o Datasul, na solicitação de alteração, onde para cada estado da viagem poderá ser retornado um comportamento distinto.

Ao tentar realizar um operação, como retirar um pedido de uma simulação, é enviado uma consulta ao CPL via webservice, para verificar se a alteração é permitida pelo CPL.

Se o retorno for negativo, a alteração deverá ser realizada no CPL, retirando o pedido da viagem e posteriormente realizar a alteração desejada no Datasul.

Image Added

Image Added

3) Eliminação Simulação.

O processo de eliminação de simulação (eq0503) quando parametrizado para integrar os pedidos pela simulação, foi alterado para não eliminar os pedidos da simulação que possuem  um numero de embarque relacionado. É emitido um alerta informando que não serão eliminados os pedidos devido a integração com o Cockpit (Neolog). Os demais pedidos que não estiverem relacionados a algum embarque poderão ser eliminados.

No produto padrão, sem integração com o Cockpit Logístico, uma simulação poderá estar em um único embarque. Mas com a integração com o Cockpit Logístico, os pedidos da simulação, poderão ser alocados em diferentes viagens, se tornando diferentes embarques no Datasul. Para este controle, foi incluso um campo no pedido da simulação (simul-ped.char-1,122,16)) que conterá o número do embarque no qual o pedido de simulação foi incluso. Assim o controle do número do embarque na simulação (simul-emb) deixa de ter efeito quando da integração com o Neolog.

O processo de eliminação é síncrono, ou seja, após a validação acima, é verificado no Cockpit Logístico se o pedido da simulação pode ser eliminar ou não, antes de eliminar o registro físico no Datasul.

Este tratamento é necessário pois uma viagem pode assumir a  situação de distribuída no CPL(que necessita de confirmação pelo cliente para poder ser liberada e enviada ao Datasul). Os pedidos nesta situação, não podem ser eliminados da simulação, pois assim que o clientes aceitar, a viagem é liberada para o Datasul e gerado o embarque. Ao clicar na lixeira no eq0503, é disparado o webservie e se o parâmetro no CPL estiver parametrizado para bloquear alterações em viagens distribuídas , o Datasul não irá eliminar o pedido.

4) Liberação de viagem

Tipo de Fluxo: Cockpit-Neolog -> Datasul 

Mensagem: ReleasedTripPublishRequestService 

Versão: 1.000

Uma viagem é elaborada no CPL, a partir de pedidos de transporte, que podem ter sido enviados por várias simulações ou vários embarques-remessas  enviados do Datasul.

Para a identificação do pedido de transporte no CPL, foi utilizado o mesmo código do pedido de venda do Datasul acrescentando o número da simulação ou do embarque que o enviou o pedido, para que o usuário possa rastrear quais pedidos comporão a viagem.

As viagens são elaboradas no modulo programação, na rotina analise, disponível no aplicativo CPL do Neolog, pela seleção dos pedidos e montagem da carga. 

Image Added

Após a elaboração da viagem no Cockpit, está deverá ser liberada para o Datasul, selecionado a viagem e executando o botão liberar conforme acima.

O envio ao Datasul será realizado pela chamada ao webservice ReleaseTripPublishRequestService. Este processo ocorre de forma assíncrona, ou seja, é enviada a mensagem do Neolog, porem o retorno aguardado será apenas se a mensagem chegou ao Datasul e pode ser lida. Este retorno é feito pelo webservice publishReleasedTripResponse. O processo é definido desta forma para evitar timeout pois a mensagem de geração do embarque exige vários processamentos.

Após a geração da pendência de processamento no ERP, pelo pedido de execução gerado para o RPW, o processo segue sem a  intervenção do usuário com o processamento da viagem, ou seja , a geração do embarque.

As informações que foram captadas na recepção do XML, serão repassadas para as tabelas que irão gerar as informações para o embarque.

Image Added

O relacionamento do número do embarque gerado para a viagem poderá ser consultado no monitor da integração, assim como os erros que foram encontrados neste processamento.

As informações que serão recebidas na mensagem tripReleaseRequests (ttTripReleaseRequest) :

Demais campos deste bloco não serão utilizados no Datasul:

• truckStatusId
• truckStatusDescription
• truckAxlesQuantity
  
  

Os embarques criados pela integração terão o campo de identificador com o valor Neolog (embarque.identific).

simul-ped.char-1,122,16) = TRIM(STRING(de-cdd-embarq))

QUEBRAS: ttorderBreakPart

Um pedido de transporte enviado para o CPL, poderá ser colocado em uma viagem com todos as quantidades dos itens que foram enviadas, ou poderá ser realizado de forma parcial. Quando por alguma razão um item de um pedido não irá ser enviado totalmente em uma viagem, este atendimento parcial do pedido de transporte é considerado uma quebra.

Exemplo: Foi enviado ao CPL um pedido de transporte para o item A com 50 unidades.

Após a programação, foi criada uma viagem com apenas 15 unidades das 50 que foram enviadas no pedido de transporte.

No XML na parte da quebra ira ser indicado na parte orderBreakPart, os itens que tiveram uma programação parcial ou seja as 15 unidades.

orderBreakPart 

Limitações / Restrições Gerais

• Integração de produto configurado/composto 
• Quando ocorre o processo de quebra, após a mensagem de desbloqueio, é enviado uma mensagem de update do Orderquisition para o CPL, para poder atualizar os campos do pedido e dos itens dos pedidos criados na nova simulação ou embarque. 
• Como a premissa de desenvolvimento desta integração era não alterar dicionário, foram utilizadas as tabelas de uso geral no sistema , como tab-generica e ped-curva, com a devida indicação de utilização.

• Quando um mensagem é enviada ao CPL, o retorno é somente referente a formação da mensagem e não do processamento em si da mensagem.

• Quando uma mensagem releasetrib sai do Neolog e não chega no Datasul, no Neolog fica como enviado, porem para consultar porque não chegou, somente verificando no log do JBoos para saber se o xml foi ou não gerado.

• A Chave Única de pedido e item de pedido no CPL, força a criação de novas simulações para comportar as quebras, pois a chave do pedido de transporte não permite que um pedido, esteja em partes na cesta e em parte sendo atendido em uma viagem.