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 o processo de integração das transações de envio de pedidos, liberação de viagens e desbloqueio de viagens:
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 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, apos 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 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.
Lista de programas relacionados ao envio de pedidos ao Cockpit Logístico:
CÓDIGO PROGRAMA | DESCRIÇÃO | LOCALIZAÇÃO NO MENU | OPERAÇÕES INTEGRADAS |
---|
EQ0503 | Simulação de Embarque | Logística - Embarques - Tarefas | Inclusão e Alteração de Simulações |
EQ0506 | Preparação do Faturamento | Logí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 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.
Quando o parâmetro da integração estiver marcado para envio dos pedidos pela rotina de pre-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 esta 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:
campo | Descrição | Campo Datasul |
regionSourceId | Identificador da regional; | A regional é definida no Parâmetros da integração (cd0090). Campo Regional. |
identifier (order) | ID do pedido de transporte; | Numero ú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) |
code | Descriçã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 |
shipperId | ID do embarcador; | Parâmetros da integração de Integração (cd0090) campo Embarcador. |
priority | Prioridade do pedido de transporte; | É enviado o valor 0 (zero) como padrão para todos os pedidos. |
pickupStart | Data/hora de início da janela de embarque; | Dt de alocação do estoque da mercadoria; simul-emb.dt-embarque ou embarque.dt-embarque |
|
deliveryStart | Data/hora de início da janela de entrega; | O campo deliverystart é o inicio 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. |
deliveryEnd | Data/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". |
destinationId | ID 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. |
integrationDataSource | ID da origem de dados; | Definido nos parâmetros da integração no Neolog, (valor padrão "DATASUL") |
modal | ID 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. |
incoterm | Incoterm 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. |
erpCreationDt | Data 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 contem 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-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); |
orderId | ID 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) |
sourceId | ID 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) |
productId | ID do SKU; | Código do item da simulação ou do embarque (simul-ent.it-codigo ou it-pre-fat.it-codigo) |
originId | ID 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) |
proportionalityId | Indicador 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 ha controle dos filhos nas tabelas da simulação; Quando estiver parametrizado o envio de pedidos pelo pre-faturamento, para produtos compostos e configurados se a baixa do estoque é feita pelos filhos, neste campo sera 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. |
shipmentUnitWrapperCode | Có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. |
price | Valortotalde 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) |
quantity | Quantidade total de unidades de produtos em todas as unidades de embarque deste item; | simul-ent.qt-simulada ou it-pre-fat.qt-faturada |
quantityInShipmentUnits | Quantidade 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 numero 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 numero 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 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 | 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" na rotina de analise no modulo programação disponível no aplicativo CPL do Neolog.
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, ira depender do retorno que o CPL ira 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.
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 numero do embarque no qual o pedido de simulação foi incluso. Assim o controle do numero 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, apos 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 ira 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 numero 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 elaborados no modulo programação, na rotina analise, disponível no aplicativo CPL do Neolog, pela seleção dos pedidos e montagem da carga.
Apos a elaboração da viagem no Cockpit, esta 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.
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 irão gerar as informações para o embarque.
O relacionamento do numero do embarque gerado para a viagem poderá se 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) :
| | |
---|
basketSourceId | Numero da cesta que elaborou a viagem. | Informação nao será utilizada no Datasul. |
carrierId | ID da transportadora da viagem (x 255) | Será verificado se o código enviado no xml esta cadastrado na tabela de transporte , então será assumido o embarque.nome-transportador com o nome abreviado do transportador. Senão estiver cadastrado, ira assumir " " (branco) pois nao é uma informacao obrigatorio no cadastros 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 viagem | Nao 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. |
vehicleId | ID do tipo de veículo da viagem; | encontrado o tipo-carga correspondente no Datasul e atualizado o embarque.tipo-emb. Caso codigo nao esteja cadastrado no ERP, será gerado erro na integracao. |
Demais campos deste bloco não serão utilizados no Datasul:
- truckStatusId
- truckStatusDescription
- truckAxlesQuantity
Campos XML | Descrição | Campo Datasul |
---|
identifier (delivery unit) | ID da unidade de entrega; | Informa o local de entrega (ped-venda.cod-emitente) | (ped-venda.cod-entrega) |
orderSourceId | ID 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. |
orderItemSourceId | ID 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-sequencia é incluso um contador ao final para nao 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. |
price | Preço das unidades de entrega | nã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 unica 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 unica da tabela simul-ent enviada para o Neolog. Nr-simul | nr-pedcli | nome-abrev| nr –sequencia |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 XML | Descrição | Campo Datasul |
---|
regionSourceId | Será enviado um valor fixo definido na integração, parâmetros de integração. | Nao 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 numero 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 pedidos | se 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 ja foi atualizada no embarque pela criação da viagem. desta forma nao 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, 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.
A mensagem de desbloqueio fornece ao Neolog um retorno para cada item de cada pedido que foi enviado na viagem:
| | |
---|
regionSourceId | Identificador da regional; | Esta informacao é enviado conforme o que foi parametrizado para a integração (ver parâmetros da integração cd0090) |
tripCode | ID da viagem do CPL; | Esta informacao vem nao 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; | Codigos 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 emabrque no Datasul foram criados com sucesso será enviado para cada item da viagem o valor 1=Desbloqueia a viagem; Se nao, se algum item nao puder ser criado, é enviado o valor 0=Não desbloqueia a viagem; Nao ha desbloqueio parcial de uma viagem. |
msg | Resposta 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 CPL).
| | |
---|
regionSourceId | Identificador da regional; | Esta informação é enviado 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 realizada | se encontrar o it-pre-fat no simu-ent (da quebra), enviar 1- Quebra realizada, caso contrario 0- Quebra nao 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 ultimo 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 :
Caso a viagem nao possa ser desbloqueada por algum motivo, no ERP será indicado no Cockpit que houveram erros na integracao e podem ser consultados os erros no monitor da integracao (eq0515).
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 reestabelecer 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.
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
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).
Campo | Descricao | Campo Datasul |
---|
regionSourceId | Código da Regional | Informado nos parâmetros da integração |
tripId | Código da Viagem | Recebido 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:
| | | |
---|
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 autorizada | Não cancela/reprograma a viagem. | No cancelamento utilizar a mensagem 4. |
4 | Viagem não pode ser cancelada | Não cancela a viagem. | Utilizada apenas na ação de cancelamento |