Páginas filhas
  • DI_Integração_Datasul_X_Cockpit_Logístico

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
INTEGRAÇÃO DATASUL X COCKPIT LOGÍSTICO

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. 

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. 

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 a partir do release 12.1.7)

Possibilitar as integrações dos processos de envio de pedidos de venda, através 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 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.

(ver configuração JBOSS para instalação dos serviços de recepção das informações do Cockpit)

Logix

Não se aplica.

Protheus

Não se aplica.

RM

 Não se aplica.


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.

Logix

Não se aplica.

Protheus

Não se aplica
.
RM

Não se aplica.

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 será é 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 

Método

ID

Descrição

Origem

Destino

Web Service

Cadastros

01

Locais de Entrega

Datasul

Neolog

LocalityAcquisitionService

 


02

Transportadores

Datasul

Neolog

CarrierAcquisitionService

 


03

Itens

Datasul

Neolog

ProductAcquisitionService

 


04

Tipos de Carga

Datasul

Neolog

VehicleAcquisitionService

Processos 06Liberação da ViagemNeologDatasulReleasedTripPublishRequestService  

06
05Envio de PedidosDatasulNeologOrderAquisitionService
Liberação da ViagemNeologDatasulReleasedTripPublishRequestService 

07Desbloqueio da ViagemDatasulNeologUnblockReleasedTripAcquisitionService 
 

08Reprogramação e cancelamento da ViagemNeologDatasul
PublishReprogramingService 
PublishReprogramingService 

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.

 

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:

CÓDIGO PROGRAMA

DESCRIÇÃOLOCALIZAÇÃO NO MENU OPERAÇÕES INTEGRADAS

CD0705

 Manutenção Embarque Vendas Endereço Entrega

Cadastros Gerais - Cadastros

 Inclusão e Alteração de Locais de Entrega
CD0704 Manutenção Clientes 

Cadastros Gerais - Cadastros

Inclusão e Alteração de Clientes que acarretam alteração de dados dos Locais de Entrega
CD0401  Manutenção Fornecedores Cadastros Gerais - CadastrosInclusão e Alteração de Fornecedores que sejam Clientes e acarretam alteração de dados dos Locais de Entrega 
CD1302 Tarefas Importação Cliente/Fornecedor Cadastros Gerais - TarefasInclusão e Alteração de Clientes que acarretam alteração de dados dos Locais de Entrega 
CDAPI366 API Manutenção Cliente/Fornecedor Não é executado pelo menu. Inclusão e Alteração de Clientes que acarretam alteração de dados dos Locais de Entrega 

Correspondência entre os campos:

CAMPO COCKPIT LOGÍSTICO
CAMPO DATASUL
OBSERVAÇÕES
RegionalCódigo da regional informado nos Parâmetros de Integração - CD0090
 

Local DestinoCódigo do Cliente do Local de Entrega + "|Padrão"
 

NomeNome Abreviado do Cliente do Local de Entrega + "|" + Código do Local de Entrega
 

Tipo1 - Ambos ou 2 - Destino

1 (Ambos) quando houver um estabelecimento cadastrado com o mesmo CNPJ do cliente/local de entrega
2 (Destino) nas demais situações

CódigoCódigo do Cliente do Local de Entrega + "|" + Código do Local de Entrega
 

DescriçãoNome do Cliente do Local de Entrega + "|" + Código do Local de Entrega 
CEPCEP
 

EndereçoEndereço
 

UFEstado
 

Número contido no EndereçoNúmero obtido pelo mesmo critério usado nas rotinas de impressão de DANFE
BairroBairro
 

PaísBR
 

CidadeCidade
 

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:

CÓDIGO PROGRAMA

DESCRIÇÃOLOCALIZAÇÃO NO MENU OPERAÇÕES INTEGRADAS

CD0402

Manutenção Cadastro Cotações Transportador

Logística - Embarques - Cadastros

 Inclusão e Alteração de Transportadores

 Correspondência entre os campos:

CAMPO COCKPIT LOGÍSTICO
CAMPO DATASUL
OBSERVAÇÃO
RegionalCódigo da regional informado nos Parâmetros de Integração - CD0090
 

NomeNome
 

CódigoCódigo
 

E-mail E-mail 
 

DescriçãoNome abreviado
 


ITENS

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

CÓDIGO PROGRAMA

DESCRIÇÃOLOCALIZAÇÃO NO MENU OPERAÇÕES INTEGRADAS

CD0204

Manutenção Cadastros Gerais Item

Cadastros Gerais - Cadastros

Inclusão e Alteração de Itens

CD0903 
CD0903Manutenção Informações Itens
Item
Faturamento
 
Cadastros Gerais - CadastrosAlteração
de Itens
de Itens

CD0205  

Item Cadastros Alteração Código/Unidade Medida 

Cadastros Gerais - Cadastros

Inclusão de Itens 

CD0209 

Importação Itens

Cadastros Gerais - Tarefas

Inclusão e Alteração de Itens 

BOIN172 

Business Object da tabela Item

Não é executado pelo menu. 

Inclusão e Alteração de Itens 


Correspondência entre os campos:

TAG
CAMPO
OBSERVAÇÃO
RegionalCódigo da regional informado nos Parâmetros de Integração - CD0090
 

EmbarcadorEmbarcador padrão informado nos Parâmetros de Integração - CD0090 
CódigoCódigo
 

DescriçãoDescrição
 

AlturaAlturaMultiplicar pelo fator de conversão de dimensões dos Parâmetros de Integração (CD0090) quando o fator for diferente de 0 (zero)
0,001 quando Altura igual a 0 (zero)
ComprimentoComprimentoMultiplicar pelo fator de conversão de dimensões dos Parâmetros de Integração (CD0090) quando o fator for diferente de 0 (zero)
0,001 quando Comprimento igual a 0 (zero)
LarguraLarguraMultiplicar pelo fator de conversão de dimensões dos Parâmetros de Integração (CD0090) quando o fator for diferente de 0 (zero)
0,001 quando Largura igual a 0 (zero)
PesoPeso BrutoMultiplicar pelo fator de conversão de peso dos Parâmetros de Integração (CD0090) quando o fator for diferente de 0 (zero)
0,001 quando Peso Bruto igual a 0 (zero)
 
Forma

0 - Caixa ou 2 - Cilindro ou 3 - Indefinido

0 (caixa) quando Altura, Comprimento e Largura maiores que 0 (zero)
2 (cilindro) quando Altura igual a 0 (zero) e Comprimento e Largura maiores que 0 (zero)
3 (indefinido) nas demais situações

compositeQuantityQuantidade compostaEm desuso 


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 devem ser informados todos os dados que são obrigatórios na operação de inclusão:

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

CÓDIGO PROGRAMA

DESCRIÇÃOLOCALIZAÇÃO NO MENU OPERAÇÕES INTEGRADAS

FT0307

 

Manutenção Informações Itens Tipo Carga

Logística - Embarques - Cadastros

 Inclusão e Alteração de Tipos de Carga

Correspondência entre os campos:

TAG
CAMPO
OBSERVAÇÃO
RegionalCódigo da regional informado nos Parâmetros de Integração - CD0090O código da regional é informado nos Parâmetros de Integração - CD0090.
NomeDescrição
 

CódigoCódigo
 

Descrição Descrição 
 

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

 

•A geração do pedido de transporte deve ser um numero único na base do Neolog.

•Somente deverá ser gerado um pedido de transporte que tenha quantidade para ser atendido. Para não otimizar o que não se tem para atender.
•Enquanto esta sendo feito o processo no Neolog, o processo no ERP deve estar bloqueado.
•Deverá haver um processo de contingencia, para a liberação do processo, caso falhe o retorno do Neolog.
•A opção de junta pedido, somente deverá ocorrer quando for retornado do Neolog com a otimização realizada.
•As quantidades que não puderem ser embarcadas no Neolog, serão consideradas como quebras e a chave única devera ser equalizadas pelo ERP.
•Fazer correspondência da viagem X embarque. Ex. Faturar uma viagem.

 

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

Processo de integração das transações de envio de pedidos, liberação de viagens e desbloqueio de viagens:

Image Removed

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

Versão: 1.000

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, apos a escolha dos pedidos, é realizado o envio dos pedidos da simulação para o Neolog.

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

Versão: 1.000

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 Quando a configuração é feita para ser realizada pelo embarque, ao clicar no check verde do embarque, apos 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 enviado 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 numero número de controle no Neolog formado pela composição da chave: numero número do pedido (nr-pedido) + nr simulação ou numero número do embarque.

 

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.

 

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

CÓDIGO PROGRAMA

DESCRIÇÃOLOCALIZAÇÃO NO MENU OPERAÇÕES INTEGRADAS

EQ0503

 Simulação de Embarque

Logística - Embarques - Tarefas

 Inclusão e Alteração de Simulações
EQ0506Preparação do FaturamentoLogística - Embarques - Tarefas Inclusão e Alteração de Embarques

EQ0505

Preparação automática

Logística - Embarques - Tarefas Inclusão de Embarques

 


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

CÓDIGO PROGRAMA

DESCRIÇÃOLOCALIZAÇÃO NO MENU OPERAÇÕES INTEGRADAS

EQ0503

 Simulação de Embarque

Logística - Embarques - Tarefas

 Inclusão e Alteração de Simulações
EQ0506Preparação do FaturamentoLogística - Embarques - Tarefas Inclusão e Alteração de Embarques

EQ0505

Preparação automática

Logística - Embarques - Tarefas Inclusão de Embarques


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 prepré-faturamento, o embarque , assumirá as seguintes situações:

Um embarque que for enviado para ser otimizado pela integração com o Neolog não poderá ser faturado ou alterado enquanto estiver no Neolog.

 

Quando o embarque for enviado para a Neolog, a situação do embarque é alterada para que possa haver um controle no Datasul, não permitindo alterar um embarque enquanto não seja retornado.

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

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

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

 


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

campoDescriçãoCampo Datasul regionSourceIdIdentificador da regional; A regional é definida no Parâmetros da integração (cd0090).
Campo Regional.identifier (order)ID do pedido de transporte; ID único gerado a partir da  composição de informações que serão enviadas:
nr-pedido(>>>,>>>,>>9) | Nr-simul >>>,>>9 (6)
ou
nr-pedido(>>>,>>>,>>9)  | cdd-Embarq >>>>>>>>>>>>>>>9 (16)codeDescrição do pedido de transporte;nr-pedcli (>>>,>>>,>>9)  | nome-abrev (x(12) |  Nr-simul >>>,>>9 (6)
ou
cdd-embarq |  nr-resumo | nome-abrev |  nr-pedcli shipperIdID do embarcador;Parâmetros da integração de Integracao (cd0090) campo Embarcador.priorityPrioridade do pedido de transporte;é enviado o valor 0 (zero) como padrão para todos os pedidos. pickupStartData/hora de início da janela de embarque;

Dt de alocação do estoque da mercadoria;

simul-emb.dt-embarque
ou
embarque.dt-embarque

 deliveryStartData/hora de início da janela de entrega;O campo deliverystart deve ser o prazo de entrega.  Data de entrega do pedido de venda (Ped-venda.dt-entrega) com o horário de 00:00.deliveryEndData/hora de término da janela de entrega;O campo deliveryend deve ser o prazo de entrega.  Data de entrega do pedido de venda (Ped-venda.dt-entrega) com o horário de "23:59".destinationIdID da localidade de destino do pedido de transporte (endereço principal de entrega);Neste campo será informado o destino de entrega do pedido  (Ped-venda.cod-emitente | ped-venda.cod-entrega)
OBS:quando operacao triangular (ped-venda.nome-brev-tri) será gerado o local de entrega do cliente da operação triangular.integrationDataSourceID da origem de dados;Definido nos parametros da integração no Neolog,  (valor padrão "DATASUL")modalID do modal do pedido de transporte;Enviado valor  fixo 1-Rodoviário.
Os demais modais ( 2=Aquaviário; 3=Ferroviário; 4=Aéreo) nao serão tratados neste momento.incotermIncoterm do pedido de transporte;Se informado a Cidade CIF no pedido de venda (ped-venda.cidade-cif <> “ “) será enviado  o valor 1 (CIF) ; senão 0 (FOB) .
Os demais tipos 2=FOBTe 3=OP, serão tratados apenas no CPL.erpCreationDtData de criação do pedido de transporte no sistema legado;Data de implantacao do pedido de venda no Datasul (ped-venda.dt-implant).reference (order)Campo texto livre;Este campo ira conter a chave primaria e única completa dos registro das tabelas do Datasul
Chave unica da tabela simul-ped:
Nr-simul | nr-pedcli | nome-abrev
Chave única da tabela embarque:
cdd-embarq | nr-resumo | nome-abrev | nr-pedcliorderItems (início)Entidade de agrupamento dos itens de um pedido de transporte;A lista de itens de pedido não pode ser vazia (deve ter pelo menos 1 item de pedido);orderIdID do pedido de transporte;Mesmo valor do campo identifier (order);
nr-pedido(>>>,>>>,>>9)  |  Nr-simul >>>,>>9 (6)
ou
nr-pedido(>>>,>>>,>>9)  | cdd-Embarq >>>>>>>>>>>>>>>9 (16)sourceIdID do item de pedido de transporte;Chave primaria e única do item da simulacao:
nr –sequencia (>>,>>9) (5)  | nr-pedido (>>>,>>>,>>9) (9) |  Nr-simul >>>,>>9 (6)  |  Nr-entrega >>>9 | contador (para os itens que repetem o nr-sequencia incluir um contador ao final)
ou
Chave primaria e unica do item do embarque:
nr –sequencia (>,>>9) (4) | nr-pedido (>>>,>>>,>>9) (9) | Nr-embarque (x13)  |
Nr-entrega >>9 | contador (para os itens que repetem o nr-sequencia incluir um contador ao final)productIdID do SKU;Codigo do item da simulacao ou do embarque (simul-ent.it-codigo ou it-pre-fat.it-codigo)originIdID da localidade de origem do item de pedido;Neste campo é indicado uma localidade de origem, de onde a mercadoria estará saindo.
A localidade de origem é considerado o cliente com o mesmo cnpj do estabelecimento do embarque (simul-emb.cod-estabel ou embarq.cod-estabel) e enviado o local de entrega deste cliente ( cod-emitente |cod-entrega)proportionalityIdIndicador de quais SKUs devem ser mantidos em uma mesma proporção dentro de uma carga (exemplo: 1 pote = 1 tampa + 1 envase); Para produtos compostos e configurados se pai não baixa estoque, enviar o código do item pai.shipmentUnitWrapperCodeCódigo da categoria de invólucro de embarque;Uma categoria de invólucro está associada a um tipo: 1=Pacote; 2=Granel não unitizável; 3=Pallet; 4=Granel unitizável; 5=Bobina; 6=Skid; 7=Tubo; 8=Feixe de tubos;
Esta categoria está informada nos parâmetros de integração.priceValortotalde unidades de produtos em todas as unidades de embarque deste item;Preco unitario do item do pedido (Ped-item.vl-pre-uni) X  campo de quantidade (quantity)quantityQuantidade total de unidades de produtos em todas as unidades de embarque deste item; quantityInShipmentUnitsQuantidade de unidades de embarque;ao campo quantityMIT"Merge in Transit";Para os pedidos com bonificação será enviado neste campo o numero do pedido do cliente do pedido original, se pedido original e pedido de bonificacao estiverem na mesma simulação/emabrque, senão não será enviada a tag.
Se o cliente nao permite faturamento parcial ( NOT ped-venda.ind-fat-par)
o numero do pedido (nr-pedido) também será atualizada neste campo dos itens , pois o cliente não aceita faturamento parcial, e o Neolog deverá realizar a otimização do pedido como um todo, não permitindo atendimento parcial.
campoDescriçãoCampo Datasul 
regionSourceIdIdentificador da regional; A regional é definida no Parâmetros da integração (cd0090).
Campo Regional.
identifier (order)ID do pedido de transporte; Número único gerado a partir da composição de informações que serão enviadas:
nr-pedido(>>>,>>>,>>9) | Nr-simul >>>,>>9 (6)
ou
nr-pedido(>>>,>>>,>>9)  | cdd-Embarq >>>>>>>>>>>>>>>9 (16)
codeDescrição do pedido de transporte;nr-pedcli (>>>,>>>,>>9)  | nome-abrev (x(12) |  Nr-simul >>>,>>9 (6)
ou
cdd-embarq |  nr-resumo | nome-abrev |  nr-pedcli 
shipperIdID do embarcador;Parâmetros da integração de Integração (cd0090) campo Embarcador.
priorityPrioridade do pedido de transporte;É enviado o valor 0 (zero) como padrão para todos os pedidos. 
pickupStartData/hora de início da janela de embarque;

Dt de alocação do estoque da mercadoria;

simul-emb.dt-embarque
ou
embarque.dt-embarque


deliveryStartData/hora de início da janela de entrega;O campo deliverystart é o início do prazo de entrega. O campo será preenchido com a data de entrega do pedido de venda (Ped-venda.dt-entrega) com o horário de 00:00.
deliveryEndData/hora de término da janela de entrega;O campo deliveryend é p fim do prazo de entrega.  O campo será preenchido com a data de entrega do pedido de venda (Ped-venda.dt-entrega) com o horário de "23:59".
destinationIdID da localidade de destino do pedido de transporte (endereço principal de entrega);Neste campo será informado o destino de entrega do pedido (Ped-venda.cod-emitente | ped-venda.cod-entrega)
OBS: quando operação triangular (ped-venda.nome-brev-tri) será gerado o local de entrega do cliente da operação triangular neste campo.
integrationDataSourceID da origem de dados;Definido nos parâmetros da integração no Neolog, (valor padrão "DATASUL")
modalID do modal do pedido de transporte;Enviado valor fixo 1-Rodoviário.
Os demais modais ( 2=Aquaviário; 3=Ferroviário; 4=Aéreo) não serão tratados neste momento.
incotermIncoterm do pedido de transporte;Se informado a Cidade CIF no pedido de venda (ped-venda.cidade-cif <> “ “) será enviado  o valor 1 (CIF) ; senão 0 (FOB) .
Os demais tipos 2=FOBTe 3=OP, serão tratados apenas no CPL.
erpCreationDtData de criação do pedido de transporte no sistema legado;Data de implantação do pedido de venda no Datasul (ped-venda.dt-implant).
reference (order)Campo texto livre;Este campo contém a chave primaria e única completa dos registros das tabelas do Datasul
Chave unica da tabela simul-ped: Nr-simul | nr-pedcli | nome-abrev
Chave única da tabela embarque: cdd-embarq | nr-resumo | nome-abrev | nr-pedcli
orderItems (início)Entidade de agrupamento dos itens de um pedido de transporte;A lista de itens de pedido não pode ser vazia (deve ter pelo menos 1 item de pedido);
orderIdID do pedido de transporte;Mesmo valor do campo identifier (order);
nr-pedido(>>>,>>>,>>9)  |  Nr-simul >>>,>>9 (6)
ou
nr-pedido(>>>,>>>,>>9)  | cdd-Embarq >>>>>>>>>>>>>>>9 (16)
sourceIdID do item de pedido de transporte;Chave primaria e única do item da simulação:
nr –sequencia (>>,>>9) (5)  | nr-pedido (>>>,>>>,>>9) (9) |  Nr-simul >>>,>>9 (6)  |  Nr-entrega >>>9 | contador (para os itens que repetem o nr-sequencia incluir um contador ao final)
ou
Chave primaria e unica do item do embarque:
nr –sequencia (>,>>9) (4) | nr-pedido (>>>,>>>,>>9) (9) | Nr-embarque (x13)  |
Nr-entrega >>9 | contador (para os itens que repetem o nr-sequencia incluir um contador ao final)
productIdID do SKU;Código do item da simulação ou do embarque (simul-ent.it-codigo ou it-pre-fat.it-codigo)
originIdID da localidade de origem do item de pedido;Neste campo é indicado uma localidade de origem, de onde a mercadoria estará saindo.
A localidade de origem é considerado o cliente com o mesmo CNPJ do estabelecimento do embarque (simul-emb.cod-estabel ou embarq.cod-estabel) e enviado o local de entrega deste cliente (cod-emitente |cod-entrega)
proportionalityIdIndicador de quais SKUs devem ser mantidos em uma mesma proporção dentro de uma carga (exemplo: 1 pote = 1 tampa + 1 envase);

Este campo no Cockpit mantem a relação do pai com os filhos para produtos compostos e configurados.

Quando estiver parametrizado o envio de pedidos pela simulação, para produtos compostos, mesmo que os filhos baixem estoque, será enviado o item pai pois não há controle dos filhos nas tabelas da simulação;

Quando estiver parametrizado o envio de pedidos pelo pré-faturamento, para produtos compostos e configurados se a baixa do estoque é feita pelos filhos, neste campo será enviado o código do item pai, para manter a relação do pai com os filhos no Cockpit.

Se o pai baixar estoque, não serão enviados os filhos ao Cockpit.

shipmentUnitWrapperCodeCódigo da categoria de invólucro de embarque;Uma categoria de invólucro está associada a um tipo: 1=Pacote; 2=Granel não unitizável; 3=Pallet; 4=Granel unitizável; 5=Bobina; 6=Skid; 7=Tubo; 8=Feixe de tubos;
Esta categoria é informada nos parâmetros de integração.
priceValortotalde unidades de produtos em todas as unidades de embarque deste item;Preço unitário do item do pedido (Ped-item.vl-pre-uni) X  campo de quantidade (quantity)
quantityQuantidade total de unidades de produtos em todas as unidades de embarque deste item;

simul-ent.qt-simulada

ou

it-pre-fat.qt-faturada

quantityInShipmentUnitsQuantidade de unidades de embarque;campo quantity
MIT"Merge in Transit";

Este campo no CPL serve para forçar o atendimento de forma conjunta.

Desta forma, para os pedidos com bonificação, será enviado neste campo o número do pedido do cliente do pedido original, se pedido original e pedido de bonificação estiverem na mesma simulação/embarque, senão não será enviada a tag.
Este campo também servira para controle de faturamento parcial. Se o cliente não permite faturamento parcial (NOT ped-venda.ind-fat-par) o número do pedido (nr-pedido) também será atualizada neste campo no envio dos itens do pedido, desta forma o Neolog deverá realizar a otimização do pedido como um todo, não permitindo atendimento parcial.

reference (order item)Campo texto livre;

Este campo

ira

irá conter a chave primaria e única completa dos registro das tabelas do Datasul
Chave unica da tabela simul-ent:
        Nr-simul | nr-pedcli | nome-abrev |

nr –sequencia 

nr–sequencia  | it-codigo | cod-refer X(8) | nr-entrega | ped-item.ind-componen
OU
Chave única da tabela it-pre-fat:
       cdd-embarq | nr-resumo | nome-abrev | nr-pedcli | nr-sequencia | it-codigo


| cod-refer | nr-entrega

 

Este campo é apenas atualizado no Neolog e devolvido para o Datasul quando da formação da viagem.


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



2) Liberação de viagem

Tipo de Fluxo: Cockpit-Neolog -> Datasul 

Mensagem: ReleasedTripPublishRequestService 

Versão: 1.000

 

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

Como a identificação do pedido de transporte no CPL, seguirá o mesmo código do pedido de venda no Datasul, o usuário poderá visualizar os pedidos que estão na viagem.

As viagens são elaborados no modulo programação, na rotina analise disponível no aplicativo CPL do Neolog, apos a seleção dos pedidos e montagem da carga a viagem é liberada.

Image Removed

Quando uma viagem é elaborada e liberada no CPL pelo webservice ReleaseTripPublishRequestService , este processo ocorre de forma assíncrona, ou seja, é enviada a mensagem do Neolog, porem o retorno que será aguardado será apenas se a mensagem chegou e pode ser lida. Este retorno deverá ser pelo webservice publishReleasedTripResponse. O processo é definido assim para evitar timeout pois a mensagem de embarque exige vários processamentos.

 

Apos 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 irao gerar as informações para o embarque.

Image Removed

 

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.

O relacionamento da geração do embarque para o viagem poderá se consultado no monitor da integração, assim como os erros que  

 

Processo de integração das transações de envio de pedidos, liberação de viagens e desbloqueio de viagens:

 

3) Desbloqueio de Viagem

Tipo de Fluxo: Datasul -> Cockpit-Neolog 

Mensagem: UnblockReleasedTripAcquisitionService 

Versão: 1.000

Quando o CPL envia uma viagem ao Datasul, a viagem ficará como bloqueada no Cockpit, até receber uma mensagem de UnblockReleasedTripAcquisition para a viagem.

Este processo de desbloqueio, com a geração da mensagem de unblock se dará de forma on-line, apos a criação do embarque.

A mensagem de retorno  será gerada para ambas as situações, se a criação do embarque foi com sucesso ou mesmo se ocorreram erros no processamento.

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.

A mensagem de desbloqueio fornece ao Neolog um retorno para cada item de cada pedido que foi enviado na viagem.

os campos desta mensagem sao:

 

Campo XML
Descrição
Campo Datasul
regionSourceIdenviar a regional o que foi parametrizado para a integração (ver parâmetros da integração)
tripCodeID da viagem do CPL; Este campo deve receber um ID de viagem válido; não se deve enviar IDs de viagens que já foram liberadas

este campo foi gravado no identifier (trip) da mensagem ReleaseTripPublishRequestService que veio do CPL

gravado no embarque (embarque.dec-1)

orderSourceId 

ID do pedido de transporte associado à viagem;

Este campo deve receber um ID de pedido válido para a viagem;

campos que vieram na viagem.

pre-fatur.char-1 Id Pedido da viagem. Posição inicial 4 – 30 posições

itemId

ID do item do pedido de transporte

Este campo deve receber um ID de item de pedido válido para o pedido da viagem; o sistema externo deverá dar um retorno para todos os itens de pedido existentes na viagem para que esta seja liberada;

 it-pre-fat.char-2 - neste campo foi gravado o IdItemSource o que veio na viagem.(posição inicial 1, 100 posições)
Status

Deverá ser enviado um Ok para todos os itens da viagem para que esta seja liberada no CPL.

0=Não desbloqueia a viagem; 
1=Desbloqueia a viagem; 
Se este campo não for preenchido, ele será considerado como 0;

Se o ttorder estiver no pre-fatur no novo embarque

1=Desbloqueia a viagem;

Se nao

0=Não desbloqueia a viagem;

 msgResposta do ERP se conseguiu gerar o item do pedido no embarque, caso não tenha sido possível, retornar o erro neste campo.

 Se retorno negativo o processo deverá ser liberado manualmente no CPL e no ERP.

Quando a viagem contiver atendimentos parciais nos pedidos enviados ao Neolog, estes são tratados como quebras pelo Cockpit. Este espera receber na mensagem de desbloqueio da viagem, o retorno se foi possível ou não a criação nos novo numero de simulações ou embarques para comportar estas quebras.

A parte do xml que conterá o retorno referente as quebras contem os seguintes campos. (só enviado o retorno com quebra se viagem teve atendimentos parciais no Neolog).

 

Campo XML
Descrição
Campo Datasul
regionSourceId- enviar a regionalo que foi parametrizado para a integração (ver parâmetros da integração.
breakId o ERP deverá dar um retorno para todos os breakIds gerados pelo CPL na interface de liberação de viagem para que esta seja liberada; este campo foi gravado no ERP na mensagem ReleaseTripPublishRequestService com o nome de orderBreakPartId.
orderId 

Novo código de pedido gerado no ERP devido a informação de quebra enviada pelo CPL.

Ped-venda.nr-pedido + "|" + simul-emb.nr-simul (simulação gerada na quebra)

orderItemId 

nr –sequencia (>>,>>9) (5) + "|" +nr-pedido (>>>,>>>,>>9) (9)+ “|” + Nr-simul >>>,>>9 (6) + "|" + Nr-entrega >>>9 + "|" contador

status 

Status de resposta do ERP sobre a quebra do CPL;

0=Quebra não realizada; 

1=Quebra realizada

se encontrar o it-pre-fat no simu-ent (da quebra), enviar 1- Quebra realizada, caso contrario 0- Quebra nao realizada.
msgquando quebra não realizada, informar o erro ou motivo da não quebra. Motivo da não quebra - segundo abaixo.

 

 

A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca

 

4) Reprogramação de Viagem

Tipo de Fluxo: Cockpit-Neolog - Datasul  

Mensagem: PublishReprogramingService 

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.

 

 

Processo de integração das transações de envio de pedidos, liberação de viagens e desbloqueio de viagens:

 

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

Mesmo se a paletização estiver desligada no CPL o envio para o WMS somente será realizado depois do retorno do Neolog.Limitações/Restrições

Produto configurado e produto composto

 

 

 

 

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

Limitações / Restrições Gerais

Integração de produto configurado/composto

Como fazer

Não se aplica. 

Situações comuns (opcional)

Não se aplica.

Checklist de suporte da aplicação

Não se aplica.

Instalação/Configuração

Não se aplica. 

Checklist de Verificações:

Não se aplica.

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

Campo XML
Descrição
Campo Datasul
basketSourceId Numero da cesta que elaborou a viagem.Informação não será utilizada no Datasul.
carrierId   ID da transportadora da viagem (x 255)

Será verificado se o código enviado no xml está cadastrado na tabela de transporte, então será assumido o embarque.nome-transportador com o nome abreviado do transportador.

Senão estiver cadastrado, irá assumir " " (branco) pois não é uma informação obrigatória no cadastro do embarque no ERP.

freightValue



O valor do frete utilizado no Neolog é apenas sugestivo para escolha da transportadora.

O frete correto será considerado na integração com o GFE, conforme integração padrão.

Valor não é armazenado nas tabelas do embarque.

identifier (trip)  - ID da viagem cuja liberação está sendo solicitada pelo CPL; 

Será armazenado no Datasul este identificador para enviar na solicitação de cancelamento ou reprogramação é enviado este código.Armazenado na tabela embarque.dec-1

truckLicensePlate Placa do caminhão da viagemNão sempre estará informado no CPL, mas quando vier conteúdo será gravado em embarque.placa 

truckLicensePlateState

Estado da placa do caminhão da viagem; nem sempre estará informado no CPL.  Mas quando vier conteúdo gravar em embarque.uf-placa

vehicleDescription 


Informação não será utilizada no Datasul.
vehicleIdID do tipo de veículo da viagem;Encontrado o tipo-carga correspondente no Datasul e atualizado o embarque.tipo-emb. Caso código não esteja cadastrado no ERP, será gerado erro na integração.


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

  • truckStatusId
  • truckStatusDescription
  • truckAxlesQuantity

Campos XMLDescriçãoCampo Datasul
identifier (delivery unit) ID da unidade de entrega;Informa o local de entrega (ped-venda.cod-emitente) | (ped-venda.cod-entrega)
orderSourceIdID do pedido de transporte da unidade de entrega;

Indica um pedido de uma simulação que foi utilizado na viagem

nr-pedido | Nr-simul

Este campo de ID foi gravado no simul-ped.char-1 quando do envio da simulação. (it-pre-fat.char-2,1,100)

orderTypeSourceId 

Código do tipo do pedido; 

Não será utilizado no ERP.
orderItemSourceIdID do item de pedido de transporte da unidade de entrega

Indica um item de um pedido de uma simulação que foi utilizado na viagem

nr –sequencia | nr-pedido | Nr-simul | nr-entrega | contador (para os itens que repetem o nr-sequência é incluso um contador ao final para não gerar chave duplicada no CPL.

Este campo foi gravado no campo simul-ent.char-1 quando do envio da simulação.

productSourceId ID do produto da unidade de entrega; Não será utilizado no ERP.
sequenceComposition Sequência da composição do SKU da unidade de entrega (apenas para SKUs que são multi-volume); Não será utilizado no ERP.
quantity Quantidade das unidades de entrega; Estas quantidades necessitam ser acumuladas pelas subparadas.
pricePreço das unidades de entregaNão será utilizado na geração do embarque.
deliveryDate Data planejada de entrega da unidade de entrega

Esta data é a nova data que deverá ser considerada para a geração do novo pedido de transporte indicado na bloco das quebras realizadas no CPL.

integrationSource ID da origem de dados;

atibute name

Totvs12_CPL_Order_Reference


Chave única da tabela simul-ped enviada para o Neolog.

Nr-simula | nr-pedcli | nome-abrev

Através do conteúdo deste campo é possível identificar qual pedido da simulação que esta sendo referenciado na viagem e que será utilizado para gerar o embarque-viagem,

atribute name

Totvs12_CPL_Order_Item_Reference


Chave única da tabela simul-ent enviada para o Neolog.

Nr-simul | nr-pedcli | nome-abrev| nr–sequência |item | cod-refer | nr-entrega | ped-item.ind-componen

Através do conteúdo deste campo é possível identificar qual o item da simulação que esta sendo referenciado na viagem e que será utilizado para gerar o os itens do embarque-viagem,

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 

Campo XMLDescriçãoCampo Datasul
regionSourceId   Será enviado um valor fixo definido na integração, parâmetros de integração.Não será utilizado.
orderBreakPartId 

Este é um número gerado pelo CPL que precisa ser armazenado no ERP porque na interface de liberação da viagem deverá ser enviado para o cpl.

A identificação do número da quebra será gravado na simulação que foi gerada com as quebras enviadas na mensagem releaseTrip.

orderSourceId Indica que este pedido de transporte sofreu uma quebra. Este campo é o identificador do pedido de transporte recebido na interface de pedidosSe um pedido de transporte está dentro da estrutura orderBreakParts significa que este sofreu quebra
orderTypeSourceId
Não sera utilizado
orderItemSourceId Indica que este item do pedido de transporte sofreu uma quebra. Este campo é o identificador do item do pedido de transporte recebido na interface de pedidos;

Se um item de pedido de transporte está dentro da estrutura orderBreakParts significa que este item (que está dentro do pedido orderSourceId) sofreu quebra;


loadId Código da carga aonde está o pedido que sofreu a quebra, esta carga está no mesmo XML, no bloco de informações da viagem.Este campo server para associar o pedido de transporte (campos orderSourceId e orderItemSourceId) com a carga gerada pelo CPL nesta interface; como cada viagem terá apenas uma carga, não será necessário gravar esta informação.
shipmentUnitId  
Não utilizar.
quantShipmUnits

Quantidade de produtos quebrado em relação ao total origina. Esta quantidade será a mesma que já foi atualizada no embarque pela criação da viagem. Desta forma não será necessário armazená-la.

Ex: foi enviado 50 unidades no pedido de transporte original, foi quebrado 15 e enviados os 15 na viagem. Neste campo vem os 15.



5) Desbloqueio de Viagem

Tipo de Fluxo: Datasul -> Cockpit-Neolog 

Mensagem: UnblockReleasedTripAcquisitionService 

Versão: 1.000

Quando o CPL envia uma viagem ao Datasul, a viagem ficará como bloqueada no Cockpit, até receber uma mensagem de UnblockReleasedTripAcquisition para a viagem.

Este processo de desbloqueio, com a geração da mensagem de unblock se dará de forma on-line, após a criação do embarque.

A mensagem de retorno será gerada para ambas as situações, se a criação do embarque foi com sucesso ou mesmo se ocorreram erros no processamento.

A mensagem de desbloqueio fornece ao Neolog um retorno para cada item de cada pedido que foi enviado na viagem:

Campo XML
Descrição
Campo Datasul
regionSourceIdIdentificador da regional;Esta informação é enviado conforme o que foi parametrizado para a integração (ver parâmetros da integração cd0090)
tripCodeID da viagem do CPL;

Esta informação vem não campo identifier (trip) da mensagem ReleaseTripPublishRequestService que veio do CPL e foi gravado no embarque (embarque.dec-1)

orderSourceId 

ID do pedido de transporte associado à viagem;

Números dos pedidos de transporte que vieram na viagem.

Informação gravada no campo : pre-fatur.char-1 (Id Pedido da viagem)

Posição inicial 4 – 30 posições

itemId

ID do item do pedido de transporte

Este campo deve receber um ID de item de pedido válido para o pedido da viagem; o sistema externo deverá dar um retorno para todos os itens de pedido existentes na viagem para que esta seja liberada;

Códigos dos itens dos pedidos de transporte que vieram na viagem.

 Informação gravada no it-pre-fat.char-2 - (IdItemSource)

Posição inicial 1, 100 posições

Status

Deverá ser enviado um Ok para todos os itens da viagem para que esta seja liberada no CPL.

0=Não desbloqueia a viagem; 
1=Desbloqueia a viagem; 
Se este campo não for preenchido, ele será considerado como 0;

Se a criação dos itens da viagem no embarque no Datasul foram criados com sucesso será enviado para cada item da viagem o valor 1=Desbloqueia a viagem;

Se não, se algum item não puder ser criado, é enviado o valor 0=Não desbloqueia a viagem;

Não há desbloqueio parcial de uma viagem.

 msgResposta do ERP se conseguiu gerar o item do pedido no embarque, caso não tenha sido possível, retornar o erro neste campo.

 Se retorno negativo o processo deverá ser liberado manualmente no CPL e no ERP.


Quando a viagem contiver atendimentos parciais nos pedidos enviados ao Neolog, estes são tratados como quebras pelo Cockpit. Este espera receber na mensagem de desbloqueio da viagem, o retorno se foi possível ou não a criação nos novos números de simulações ou embarques para comportar estas quebras.

A parte do xml que conterá o retorno referente as quebras contém os seguintes campos. (só enviado o retorno com quebra se viagem teve atendimentos parciais no CPL).


Campo XML
Descrição
Campo Datasul

regionSourceId

Identificador da regional; Esta informação é enviada conforme o que foi parametrizado para a integração (ver parâmetros da integração cd0090)

breakId

ID da quebra do CPL;O ERP deverá dar um retorno para todos os breakIds gerados pelo CPL na interface de liberação de viagem para que esta seja liberada; este campo é gravado no ERP na mensagem ReleaseTripPublishRequestService com o nome de orderBreakPartId.

orderId

ID do pedido de transporte associado à quebra;Novo código de pedido gerado no ERP devido a informação de quebra enviada pelo CPL.Ped-venda.nr-pedido + "|" + simul-emb.nr-simul (simulação gerada na quebra)

orderItemId

ID do item do pedido de transporte associado à quebra;nr –sequencia (>>,>>9) (5) + "|" +nr-pedido (>>>,>>>,>>9) (9)+ “|” + Nr-simul >>>,>>9 (6) + "|" + Nr-entrega >>>9 + "|" contador

status 

Status de resposta do ERP sobre a quebra do CPL;0=Quebra não realizada; 1=Quebra realizadaSe encontrar o it-pre-fat no simu-ent (da quebra), enviar 1- Quebra realizada, caso contrario 0- Quebra não realizada.

msg

Quando a quebra não for realizada, informar o erro ou motivo da não quebra.Motivo da não quebra - segundo abaixo.


IMPORTANTE: Este último bloco estará sendo retornado apenas se o embarque foi criado com sucesso, não haverá desbloqueio parcial de uma vigem, onde somente alguns itens ou pedidos ficariam liberados, pois não teríamos como reprocessar de forma parcial a viagem no ERP. Se ocorrer erro, deverá ser reenviada a viagem pelo CPL, para ser reprocessado no Datasul.

A viagem desbloqueada, terá sua situação alterada para processada no Cockpit :

Image Added

Caso a viagem não possa ser desbloqueada por algum motivo, no ERP será indicado no Cockpit que houveram erros na integração e podem ser consultados os erros no monitor da integração (eq0515).

Image Added


6) Reprogramação de Viagem

Tipo de Fluxo: Cockpit-Neolog - Datasul  

Mensagem: PublishReprogramingService

Versão: 1.000

Os processos de cancelamento e reprogramação de viagens executadas no Cockpit Logístico, também possui interface com o Datasul.  Essas ações demandam restabelecer os Embarques ou Simulações de Embarque em sua composição original antes da recepção das viagens geradas pelo Cockpit Logístico. Essas interfaces também devem responder ao Cockpit Logístico sobre a possibilidade de concluir as ações considerando as regras do ERP. E de acordo com a resposta o Cockpit Logístico concluirá as ações de cancelamento ou reprogramação ou informará ao usuário sobre a impossibilidade de realizá-las.

Image Added


Image Added


Image Added


Image Added

Image Added

Faz o cancelamento de viagens, cargas ou paradas. Uma tela de confirmação do cancelamento é exibida para que o usuário certifique-se de que realmente deseja cancelar a entidade selecionada.
Resultado do cancelamento com sucesso: a(s) viagem(ns) é(são) eliminada(s) do Cockpit Logístico e os pedidos selecionados voltam à cesta para nova otimização.

Reprogramação de Viagem

 Image Added

Possibilita que o usuário restaure uma carga na tela de Expedição fazendo-a aparecer na tela do seu domínio com o último status antes da liberação.
Resultado da reprogramação autorizada com sucesso: a(s) viagem(ns) não é(são) eliminada(s) do Cockpit Logístico, pode ser alterada e requer nova liberação (envio para o ERP) e desbloqueio (confirmação enviada pelo ERP).

WebService
URL
 Executa
PublishReprogrammingServiceRequest

http://server:port/WebService/publishReprogrammingServiceRequest?wsdl

 cancelService em eqp/eqapi200a.p
PublishCancelServiceRequest

http://server:port/WebService/publishCancelServiceRequest?wsdl

 reprogramService em eqp/eqapi200a.p
CampoDescricaoCampo Datasul
regionSourceIdCódigo da RegionalInformado nos parâmetros da integração
tripIdCódigo da ViagemRecebido código da viagem na mensagem PublishCancelServiceRequest ou pela mensagem PublishReprogrammingServiceRequest
status
conforme resultados possiveis abaixo listados


Os resultados (resposta do ERP) possíveis são: 

conteúdo
mensagem (cancelamento/reprogramação)
ação do Cockpit Logístico
 observação
 0 Viagem cancelada com sucesso/Reprogramação autorizada Procede com o cancelamento/reprogramação da viagem..
 1 Viagem já estava cancelada/Viagem cancelada
 Não ocorrerá.
 2 Viagem não encontrada/Viagem não encontrada Procede com o cancelamento/reprogramação da viagem.
 3 Viagem já despachada/Reprogramação não autorizadaNão cancela/reprograma a viagem.No cancelamento utilizar a mensagem 4. 
 4 Viagem não pode ser canceladaNão cancela a viagem. Utilizada apenas na ação de cancelamento 


7) Ambiente Neolog com múltiplas empresas no Datasul

Após o release 12.1.27 do Datasul, será possível utilizar a integração com múltiplas empresas parametrizadas no ERP. Para isso, basta que o usuário de integração parametrizado no arquivo datasul_framework.properties possua acesso nas empresas que estejam parametrizadas para integrar com a Neolog / Cockpit Logístico.


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

Anexos

Não há anexos
  • .