Histórico da Página
Âncora | ||||
---|---|---|---|---|
|
Índice | ||||||
---|---|---|---|---|---|---|
|
1. Contexto de Negócio (Introdução)
Com a crescente demanda por otimização nos processos logísticos de distribuição na busca por um melhor aproveitamento dos veículos, tanto na questão de carregamento quanto na roteirização das entregas, tornou-se necessário proporcionar aos cliente do TOTVS OMS uma solução para atender essas necessidades.
Visando esta solução foi realizada a integração entre o TOTVS OMS da linha Protheus com a funcionalidade TOTVS Otimização Logística por
INTEGRAÇÃO OMS Protheus X Cockpit Logístico Neolog
Contexto de negócio (Introdução)
Foi realizada a integração entre o módulo Gestão de Distribuição (SIGAOMS) com a funcionalidade Programação de Transportes do Cockpit Logístico da NEOLOG, porintermédio de arquivos no formato XML, utilizando os
Web Services já existentes do Cockpit LogísticoWebServices existentes no TOL, sem transformação de mensagens e sem
a utilizaçãoa utilização de
sistemasSistemas intermediários (TOTVS EAI, TOTVS ESB, entre outros).
ParaCom esta integração
foram consideradas as alterações necessárias,
para que o planejamento das montagens de cargas do módulo Gestão de Distribuição (SIGAOMS) da linha Microsiga Protheus utilize os recursos de Programação de Transportes do Cockpit Logístico. A Programação de Transportes fará a roteirizaçãoo TOTVS OMS passou a utilizar os recursos do TOTVS Otimização Logística, o qual efetuará a roteirização e o arranjo das cargas com base na demanda de transportes enviados pelo
módulo SIGAOMS considerandoTOTVS OMS, devolvendo para este as cargas montadas e roteirizadas.
Para a montagem de carga serão consideradas as configurações das restrições logísticas e as funções-objetivos de otimização registradas
no Cockpit Logístico.no TOTVS Otimização Logística.
São exemplos de funções-objetivo:
- Máxima ocupação dos veículos
- .
- Diminuição dos prazos de entrega
- .
- Redução da quantidade de viagens.
Para tanto, são utilizados os cadastros básicos já disponibilizados na integração entre o SIGATMS x Cockpit Logístico, sendo eles:
- Produto.
- Filial.
- Cliente.
- Tipo de veículo.
- Fornecedores.
Foi disponibilizado apenas um novo cadastro para a integração "Transportadoras". O cadastro de fornecedor foi ajustado permitindo que quando a integração OMS x CPL estiver habilitada, o mesmo seja enviado como uma "Localidade" para o Cockpit Logístico.
Além dos cadastros, foi realizada a integração dos pedidos de venda que utilizam as "Cargas". Os pedidos de venda são enviados para o Cockpit Logístico gerando "Pedidos de Transportes", para estes, o Cockpit Logístico realiza a análise e geração da viagem.
Após a geração da viagem no Cockpit Logístico, este se integra com o módulo SIGAOMS para a geração das Cargas.
2. Sistemas Envolvidos
2.1. TOTVS OMS
A sigla OMS significa Order Management System, ou seja, gerenciamento de Pedidos e serviços que compreende as fases de captação, validação, avaliação, formação de carga e geração de mapa de separação ou, como é também conhecido, lista de separação.
Para obter informações detalhadas, acesse a página TOTVS OMS. no TDN.
2.2. TOTVS OTIMIZAÇÃO LOGÍSTICA
É um 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.
Sistemas Envolvidos
Descrição dos sistemas envolvidos no contexto de negócio (e que serão envolvidos na integração).
A sigla OMS significa Order Management System, ou seja, gerenciamento de pedidos e serviços e compreende as fases de captação, validação, avaliação, formação de carga e geração de mapa de separação ou como é também conhecido, lista de separação.
Para saber mais sobre o OMS TOTVS, acesse o link: https://www.totvs.com/mktfiles/tdiportais/helponlineprotheus/portuguese/sigaoms.htm
O Cockpit Logístico é um 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.
Para saber mais sobre o Cockpit Logístico Neolog, acesse o link:
Para obter informações detalhadas, acesse o link
http://www.neolog.com.br/neolog-site/index.php/cockpit-logistico/.
3. Escopo
O
objetivo é integrar o módulo Gestão de Distribuição (SIGAOMS) com a funcionalidade Programação de Transportes do Cockpit Logístico da Neolog, por intermédio de arquivos no formato XML utilizando os Web Services já existentes do Cockpit Logístico, sem transformação de mensagens e sem a utilização de sistemas intermediários (TOTVS EAI, TOTVS ESB, entre outros).Escopo
O escopo desta integração permitirá o envio dos pedidos de vendaescopo desta integração permitirá o envio dos pedidos de venda liberados (crédito / estoque) no
módulo SIGAOMSTOTVS OMS para a formação das viagens no
Cockpit Logístico, eTOL e o recebimento
dessasdestas viagens geradas no
Cockpit LogísticoTOTVS Otimização Logística, por meio de um XML no
módulo SIGAOMSTOTVS OMS, para a geração das
CARGAScargas.
As entidades e os pontos de integração que farão parte do escopo dessa integração, são:
- Cadastro de Transportadoras.
- Edição Transportadoras.
- Cadastro de Fornecedores.
- Edição de Fornecedor.
- Cadastro de Tipo Veículo.
- Edição de Tipo Veículo.
- Cadastro de Cliente.
- Edição de Cliente.
- Cadastro de Empresas/Filiais.
- Edição de Empresas/Filiais.
- Cadastro de Produto.
- Edição de Produto.
Para complementar o escopo do envio dos pedidos será necessário enviar os cadastros envolvidos com as informações dos pedidos, como produtos, clientes, fornecedores, filiais, transportadoras e tipos de veículos.
Faz parte do processo de integração o recebimento das mensagens de publicação de viagens, reprogramação e cancelamento de viagens.
draw.io Diagram | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
¹ Para o cadastro de fornecedores existem particularidades que serão detalhadas nos próximos tópicos.
Para as entidades envolvidas na integração, estes são os pontos que farão parte do escopo desta integração:
Entidade | Pontos de Integração |
---|---|
Empresas/Filiais |
|
Cliente |
|
Fornecedor |
|
Transportadora |
|
Produto |
|
Tipo de Veículo |
|
Pedidos de Venda |
|
Viagens |
|
|
4. Pré-requisitos Instalação / Implantação / Utilização
4.1. TOTVS Otimização Logística
TOL na versão/
Pré-requisitos instalação/implantação/utilização
Cockpit Logístico
- Cockpit Logístico na versão\
release 5.6.1.
Parâmetros de aquisição ativos (acesso pelo menu em Administração
- Cockpit Logístico> TOTVS Otimização Logística).
Web Services ativos.
4.2. Protheus
Protheus
versão 11.8versão 12.1.17 ou superior.
- Parâmetro
Parâmetros de integração com
Cockpit Logístico ativo (MV_CPLINT == .T.). - Web Service de integração válido informado (MV_CPLURL).
Todos os parâmetros citados, encontram-se no programa Parâm Integração (OMSXCPL1), que pode ser acessado pelo menu Atualizações - Cockpit Logístico.
o TOL configurados (acesso pelo menu em Atualizações > TOTVS Otimização Logística > Parâmetros Integração).
Web Service Server para recebimento de mensagens do TOL.
Informações | ||
---|---|---|
| ||
| ||
Informações | ||
| ||
Não é escopo desse
|
É imprescindível a atualização do Protheus 11.8 por meio da execução do compatibilizador OMSP11R1.
Para visualizar o documento técnico referente a esta integração, acesse o link: LOGTMS01-69 DT Integração OMS x Neolog
Para que a integração possa funcionar corretamente, o ambiente deve conter o módulo SIGAOMS e o Cockpit Logístico devidamente configurados.
Parametrização SIGAOMS
Por meio do menu Atualizações > CockPit Logístico > Parâm Integração (OMSXCPL1), o Protheus deve ser parametrizado para o correto funcionamento da integração conforme abaixo:
Onde:
Titulo | Descrição | Parâmetro | Opções | Valor para Integração | Validação |
---|---|---|---|---|---|
Integração Cockpit Logístico? | Indica se a integração com o cockpit logístico está ativa. | MV_CPLINT | Sim / 1 | ||
Integração Suspensa? | Identifica se o Módulo SIGAOMS não esta integrado temporariamente aos outros módulos. | MV_CPLSTP | Não / 2 | ||
Integrar Clientes On line? | Salvar os dados dos clientes criados no Protheus automaticamente no Cockpit Logístico. | MV_CPLCLI | Sim / 1 | ||
Integrar Fornecedores On line? | Salvar os dados dos fornecedores criados no Protheus automaticamente no Cockpit Logístico (Localidades). | MV_CPLFOR | Sim / 1 | ||
Integrar Transportadora On line? | Salvar os dados das transportadoras criadas no Protheus automaticamente no Cockpit Logístico. | MV_CPLTRA | Sim / 1 | ||
Integrar Produtos On Line? | Salvar os dados dos produtos criados no Protheus automaticamente no Cockpit Logístico. | MV_CPLPRO | Sim / 1 | ||
Integrar Tipos de Veículos On Line? | Salvar os dados dos tipos de veículos criados no Protheus automaticamente no Cockpit Logístico. | MV_CPLTPV | Sim / 1 | ||
Endereço WebService | Endereço do webservice do Cockpit Logístico. | MV_CPLURL | Conforme cliente | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | |
Regional | Regional enviada para o Cockpit Logístico. | MV_CPLREG | Conforme cliente | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | |
Embarcador | Código de um Embarcador do Cockpit Logístico. Todos os Produtos integrados do módulo OMS para o Cokpit Logístico, serão relacionados a um mesmo Embarcador no Cockpit Logístico, pois no OMS a relação variável de produto x cliente é utilizada (opcionalmente), apenas na importação de Notas Fiscais de Cliente pelo EDI. | MV_CPLEMB | Conforme cliente | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | |
Categoria de Produto? | Para o Cockpit Logístico, categorias de Produto são agrupamentos relevantes de produtos com características logística semelhantes. Com esse parâmetro, pode-se determinar se a categoria dos produtos integrados do módulo OMS para o Cockpit Logístico (1=Grupo Produto), será o código do grupo do produto do OMS ou (2=Padrão Cockpit) será informada por alteração manual em cada produto no Cockpit Logístico. Com a opção, deve-se cadastrar as Categorias de Produtos no Cockpit Logístico com os mesmos códigos dos Grupos de Produtos do OMS, pois não há Web Serivce de integração para essa tabela. | MV_CPLCAT | 1=Grupo Produto; 2=Padrao Cockpit. | 2=Padrao Cockpit. | |
Invólucro Padrão | Código de um Invólucro (~ embalagem) do Cockpit Logístico. Todos os itens de Pedidos de Transporte recebidos do OMS no Cockpit Logístico, serão associados a esse invólucro pois não há uma entidade no OMS que corresponda exata e obrigatoriamente a esse dado do Cockpit Logístico. Recomenda-se informar um invólucro cujas medidas sejam obtidas do item do pedido (essa característica é parametrizada no Cockpit Logístico). | MV_CPLINV | Conforme cliente | ||
Origem dos Dados | Define o nome do ERP que da origem aos dados enviados ao Cockpit Logístico. | MV_CPLIDS | Protheus | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | |
E-mail do Administrador | E-mail do administrador para notificações de falha de conexão. | MV_CPLMAL | Conforme cliente | ||
Modo Debug? | Salva as mensagens enviadas e recebidas na pasta do log. | MV_CPLDBG | |||
Caminho da Pasta de Mensagens | Caminho do log de mensagens. Recomendado utilizar o caminho relativo a \system\ | MV_CPLLOG | \system\ | ||
Liberação automática da viagem? | O uso deste parâmetro ocorre somente para o módulo SIGAOMS, quando habilitado, ao realizar a geração das NF de Saída automaticamente, o sistema irá realizar o envio da liberação de viagens no Cockpit Logístico. | MV_CPLLVA | Sim / 1 | ||
Tipo Veículo Otimização? | Quando for 1 = Impedir: No vinculo do veículo na carga se o usuário informar um tipo de veículo diferente do que consta na viagem do CPL, não permitimos apresentando um Help. Se for 2 = Alertar: O sistema avisa que o tipo informado é diferente do tipo da viagem no CPL e o usuário define se permite o vinculo ou não. | MV_CPLTVO | 2 / Alertar | ||
Geração das cargas | Quando for 1 = Automático: Para as viagens vindas do CPL o SIGAOMS gera a carga automaticamente. Quando for 2 = Manual: Para as viagens deve ser gerada manualmente a carga. | MV_CPLAUT | 2 / Manual |
Parametrização appServer.ini
Para que seja possível receber as viagens do Cockpit Logístico, é necessário configurar um WebService no appserver.ini Protheus.
É recomendado criar um webservice com as seguintes configurações (modificando o arquivo appserver.ini):
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
;Serviço webserver HTTP
[HTTP]
ENABLE=1
PATH=<Caminho_Cache_imagens>;C:\TOTVS 11\Prottheus\Protheus_data\web
PORT=<porta>;8080
INSTANCES=<nInicio>,<nMaximo>;1,10
SESSIONTIMEOUT=60
INSTANCENAME=WS_HTTP
;URL de resposta
[<ip ou nome>:<porta>/neolog]
ENABLE=1
PATH=<Caminho_Cache_imagens>;C:\TOTVS 11\Prottheus\Protheus_data\web
ENVIRONMENT=<ambiente>
INSTANCENAME=WS_NEOLOG
RESPONSEJOB=JOB_WS_NEOLOG
DEFAULTPAGE=wsindex.apw
;JOB de resposta
[JOB_WS_NEOLOG]
TYPE=WEBEX
ENVIRONMENT=<ambiente>
INSTANCES=<nInicio>,<nMaximo>;1,10
INSTANCENAME=JOB_WS_NEOLOG
ONSTART=TMSXStart ;ponto de inicio obrigatório
ONCONNECT=TMSXConnect ;ponto de inicio obrigatório
TMSPREPAREIN=<empresa>,<filial>;obrigatório |
Para testar o serviço, basta iniciar um navegador e digitar: http://<ip ou nome>:<porta>/neolog/PublishReleasedTrip.APW?WSDL
Um WSDL (Descrição do serviço em xml) deve exibir no navegador.
Parametrização Cockpit Logístico
Para configurar o envio de viagens do cockpit ao webservice protheus, entre no Cockpit Logístico e acesse:
- Administração > Integração, selecione a pasta 'Fontes de Dados' e clique em 'Inserir'.
- Digite o Código, Descrição e Código da base.
Sugestão: PROTHEUS - Seção "Cancelamento de Viagem Liberada"
- No campo "URL" da seção, digite: http://<ip ou nome>:<porta>/neolog/CancelService.APW
- No campo "Tempo Máximo de Espera por Resposta", coloque o timeout do serviço.
Recomendado 30000.
4. Seção "Execução da Viagem"
- No campo "URL", digite: NA (Não Atribuído)
- No campo "Tempo Máximo de Espera por Resposta", coloque o timeout do serviço.
Recomendado 1000.
5. Seção "Solicitação de liberação de Viagem"
- No campo "URL", digite: http://<ip ou nome>:<porta>/neolog/PublishReleasedTrip.APW
- No campo "Tempo Máximo de Espera por Resposta", coloque o timeout do serviço.
Recomendado 30000.
6. Seção "Solicitação de Reprogramação de Viagem"
- No campo "URL", digite: http://<ip ou nome>:<porta>/neolog/ReprogramService.APW
- No campo "Tempo Máximo de Espera por Resposta", coloque o timeout do serviço.
Recomendado 30000.
7. Selecione a opção "Salvar".
Configuração para envio automático de pedidos de venda (Schedule)
Os pedidos de venda gerados no módulo SIGAOMS, podem ser enviados automaticamente ao Cockpit Logístico, para isso, deve ser configurada a execução automática (Schedule) da rotina Envio de Pedidos de Venda (OMSXCPL6), está configuração pode ser executada conforme descrito no link: http://tdn.totvs.com/display/framework/Schedule+Protheus.
No arquivo appserver.ini é necessário inserir a configuração abaixo:
Bloco de código | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[OnStart]
jobs=FWSCHDMANAG,FWSCHDQUEUE
RefreshRate=60
[FWSCHDMANAG]
Main=FWSCHDMANAG
Environment=<ambiente>
[FWSCHDQUEUE]
Main=FWSCHDQUEUE
Environment=<ambiente> |
Instalação/Atualização
Nota | ||
---|---|---|
| ||
Vide tópico Pré-requisitos instalação/implantação/utilização. |
Protheus
Nota | ||
---|---|---|
| ||
Vide tópico Pré-requisitos instalação/implantação/utilização. |
Controle de Versão
O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.
Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definidas pelo Comitê de Integração TOTVS.
Suporte
O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim, as equipes de suporte dos produtos Backoffice Protheus estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.
Informações | ||
---|---|---|
| ||
Este modelo de suporte está sendo revisado pela TOTVS. |
Transações/Entidades/Mensagens únicas
Método | ID | Descrição | Origem | Destino | XSD (versões podem variar) |
Cadastros | 01 | Transportadora | Protheus | Cockpit Logístico | updateCarriers |
02 | Fornecedor | Protheus | Cockpit Logístico | LocalityAcquisitionService | |
03 | Produtos | Protheus | Cockpit Logístico | ProductAcquisitionService | |
04 | Empresas/Filiais | Protheus | Cockpit Logístico | LocalityAcquisitionService | |
05 | Tipo de Veículo | SIGAOMS | Cockpit Logístico | VehicleAcquisitionService | |
06 | Cliente | Protheus | Cockpit Logístico | updateLocalities | |
Processos | 07 | Enviar viagens | Cockpit Logístico | SIGAOMS | ReleaseTripPublishRequestService |
08 | Liberar Viagens | SIGAOMS | Cockpit Logístico | UnblockReleasedTripAcquisition | |
09 | Montagem de Carga | SIGAOMS | Cockpit Logístico | UnblockReleasedTripAcquisitionService | |
10 | Pedido de Vendas | SIGAOMS | Cockpit Logístico | OrderAcquisitionService | |
11 | Cancelar Pedido de Vendas | SIGAOMS | Cockpit Logístico | OrderAcquisitionService |
Fluxo das Informações
Os cadastros devem ser realizados no módulo SIGAOMS Protheus 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 Protheus.
Apenas as operações de inclusão e alteração são consideradas na integração e são efetuadas sempre que ocorrerem. 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 Protheus.
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.
Entidade (s) Protheus | Código (Alías) | Web Service | Método | Entidade Cockpit | Observações |
---|---|---|---|---|---|
Fornecedor | SA2 | LocalityAcquisitionService | updateLocalities | Localidade | Os fornecedores são enviados ao CPL como localidades quando a integração partir do SIGAOMS, devido a geração de pedido de venda do tipo "Beneficiamento" e "Devolução". |
Transportadora | SA4 | CarrierAcquisitionService | updateCarriers | Transportador | |
Pedido de Venda | SC5 / SC6 / SC9 / SB1 / SB5 | OrderAcquisitionService | Create Orders | Pedidos de Transporte | |
Montagem de Carga | DAK / DAI | UnblockReleasedTripAcquisitionService | Desbloqueio da Viagem | Confirmação da inclusão da Carga no OMS, retorno ao CPL para o desbloqueio da viagem. | |
Produto | SB1 e SB5 | ProductAcquisitionService | updateProducts | Produto | |
Filial | SM0 | LocalityAcquisitionService | updateLocalities | Localidade | As filiais assumem o papel de localidade quando são locais de carga ou descarga. Quando MV_CPLEX == "2" não integrar filial, cuja unidade de federação não faça parte da lista de unidades de federação do Brasil. |
Cliente | SA1 | LocalityAcquisitionService | updateLocalities | Localidade | Quando MV_CPLEX == "2" não integrar cliente com país informado diferente de 105 (Brasil). |
Tipo de Veículo | DUT | VehicleAcquisitionService | updateVehicles | Veículo |
No próximo tópico são listadas as correspondências entre os campos de cada entidade e a respectiva tag XML da mensagem de integração.
Cadastros
Mensagem de integração dos registros do cadastro de "Tipo de Veículo"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Regional | |
DUT_TIPVEI | identifier | Código | |
DUT_DESCRI | name | Nome | |
DUT_DESCRI | description | Descrição | |
"0" | priority | Prioridade | |
"0" | similarity | Similaridade |
Mensagem de integração dos registros do cadastro de "Clientes"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Regional | |
"CLI-" + RTRIM(SA1->A1_COD) + "-" + RTRIM(SA1->A1_LOJA) | identifier | Código | |
A1_NREDUZ | name | Nome | |
A1_NOME | description | Descrição | |
A1_END | addressStreet | Endereço | |
addressNumber | Nº | Obter o conteúdo usando a função LjFiGetEnd sobre o campo A1_END | |
A1_COMPLEM | addressComplement | Complemento | |
A1_BAIRRO | addressDistrict | Bairro | |
A1_CEP | addressZipCode | CEP | |
A1_MUN | addressCity | Cidade | |
A1_EST | addressStateAcronym | UF | |
"BR" ou YA_SIGLA | addressCountryAcronym | País | Acessar a tabela SYA pelo campo A1_PAIS. Quando A1_PAIS estiver em branco ou igual a 105, atribuir "BR". |
"2" | logisticRoleId | Tipo | 2=Destino (por orientação da Neolog para gerar menos combinações de rota). |
Mensagem de integração dos registros do cadastro de "Filiais"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Regional | |
"FIL-" + FWCodFil(SM0->M0_CODFIL) | identifier | Código | |
M0_FILIAL | name | Nome | |
M0_NOMECOM | description | Descrição | |
M0_ENDENT | addressStreet | Endereço | |
addressNumber | Nº | Obter o conteúdo usando a função LjFiGetEnd sobre o campo M0_ENDENT | |
M0_COMPENT | addressComplement | Complemento | |
M0_BAIRENT | addressDistrict | Bairro | |
M0_CEPENT | addressZipCode | CEP | |
M0_CIDENT | addressCity | Cidade | |
M0_ESTENT | addressStateAcronym | UF | |
"BR" ou YA_SIGLA | addressCountryAcronym | País | Acessar a tabela SYA pelo campo M0_PAIS. Quando M0_PAIS estiver em branco ou igual a 105, atribuir "BR". |
"1" | logisticRoleId | Tipo | 1=Ambos |
Mensagem de integração dos registros do cadastro de "Produto"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Regional | |
MV_CPLEMB | shipperId | Embarcador | |
B1_COD | identifier | Código | |
B1_DESC | description | Descrição | |
B1_GRUPO | productCategoryId | Categoria | |
B5_ALTURA | height | Altura | |
B5_COMPR | length | Comprimento | |
B5_LARG | width | Largura | |
B1_PESBRU | weight | Peso | |
"1" | shape | Forma | 1=Caixa |
Mensagem de integração dos registros do cadastro de "Fornecedor"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Regional | |
"FOR-" + RTRIM(SA2->A2_COD) + "-" + RTRIM(SA2->A2_LOJA) | identifier | Código | Será adicionada a sigla "FOR" para composição do código para identificação que se trata de um fornecedor para uso como uma localidade, devido aos pedidos de beneficiamento do OMS. |
A2_NREDUZ | name | Nome | |
A2_NOME | description | Descrição | |
A2_END | addressStreet | Endereço | |
addressNumber | N° | Obtido por meio do campo A2_END | |
A2_COMPLEM | addressComplement | Complemento | |
A2_BAIRRO | addressDistrict | Bairro | |
A2_CEP | addressZipCode | CEP | |
A2_MUN | addressCity | Cidade | |
A2_EST | addressStateAcronym | UF | |
A2_PAIS / "BR" ou YA_SIGLA | addressCountryAcronym | País | Quando A2_PAIS estiver em branco ou igual a 105 atribuido "BR". |
"2" | logisticRoleId | Tipo | 2=Destino (por orientação da Neolog para gerar menos combinações de rota). |
Mensagem de integração dos registros do cadastro de "Transportadora"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Ident. Regional | |
A4_COD | identifier | ID da transportadora (Código) | |
A4_NREDUZ | name | Nome da Transportadora | |
A4_NOME | description | Descrição da Transportadora |
Mensagem de integração dos registros do cadastro de "Pedido de Venda"
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
MV_CPLREG | regionSourceId | Regional | |
MV_CPLIDS | integrationDataSource | Integração | |
"1" | orderTypeSourceId | Tipo do Pedido | |
RTRIM(SC5->C5_FILIAL) + "-" + RTRIM(SC5->C5_NUM) | identifier | SC5->(RECNO()) | |
RTRIM(SC5->C5_FILIAL) + "-" + RTRIM(SC5->C5_NUM) | code | Código do Ped. Transp. | |
"0" | priority | Prioridade | |
Date() | erpCreationDt | Data Corrente | Data de criação do pedido. |
Date() | pickupStart | Janela Embarque | |
Date() ou C5_FECENT | deliveryStart | Janela Entrega | Data corrente ou data informada no pedido de venda. |
Date() ou C6_ENTREG ou C9_DATENT | deliveryEnd | Janela Entrega | |
C9_PEDIDO | orderId | ID do Pedido de Transporte | |
RTRIM(SC5->C5_FILIAL)+"-"+RTRIM(SC5->C5_NUM) + C9_ITEM | sourceId | ||
C9_PRODUTO | productId | Produto | |
C9_QTDLIB | quantity | Quantidade total de unid. | |
C9_PRCVEN | price | Valor Total de unid. De prod. | |
"FIL-" + RTRIM(SC5->C5_FILIAL) | originId | Origem Inicial | |
"CLI-" + RTRIM(SC5->C5_CLIENT) + "-" + RTRIM(SC5->C5_LOJAENT) | destinationId | ID da Localidade de destino do Pedido | |
C9_QTDLIB | quantityInShipmentUnits | ||
B5_ALTURLC | height | Quando houver relacionamento com o B1_PRODUTO, quando vazio será enviado por default o contéudo = 0.001 | |
B5_LARGLC | width | Quando vazio, por default o contéudo enviado será = 0.001 | |
B5_COMPRLC | length | Quando vazio, por default o contéudo enviado será = 0.001 | |
B1_PESO ou B1_PESBRU | weight | De acordo com a configuração do parâmetro MV_PESOCAR, verificar o conteúdo do parâmetro por meio da função OsPesoProd e enviar os dados. Quando vazio, por default o contéudo enviado será = 0.001 | |
MV_CPLEMB | shipperId | ID do Embarcador | |
"1" | modal | ID do modal do pedido de transporte | Enviar valor fixo 1 - Rodoviário. |
C5_TPFRETE | incoterm | Sendo o conteúdo C = 1 e F = 0 para o CPL, quando o campo for vazio iremos passar sempre 1. | |
MV_CPLINV | shipmentUnitWrapperCode | Invólucro de embarque |
Mensagem de integração das viagens geradas no CPL para posterior geração das Cargas no módulo SIGAOMS, utilizando a operação publishReleasedTrip:
Campo Prothues | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
DK0_IDCESTA | basketSourceId | ID Cesta | |
DK0_REGID | regionSourceId | Identificador Regional | |
DK0_VIAGID | identifier | ID da Viagem | |
DK0_TRANSP | carrierId | ID Transportadora da Viagem | |
DK0_TIPVEI | vehicleId | ID do Tipo de Veículo da Viagem | |
DK0_DESTIP | vehicleDescription | Descrição do tipo de veículo da viagem | |
DK0_PLACA | truckLicensePlate | Placa do caminhão da viagem | |
DK0_ESTPLA | truckStateLicensePlate | Estado da placa do caminhão da viagem | |
DK0_QTDEIX | truckAxlesQuantity | Número de eixos do caminhão |
Mensagem dos itens (Pedidos) do CPL - deliveryUnit
Campo Protheus | Tag XML | Campo Cockpit Logístico | Observações |
---|---|---|---|
DK1_UNIDID | identifier | ||
DK1_REGID | RegionalSourceId | Regional | |
DK1_VIAGID | Viagem | Viagem CPL | |
DK1_PEDROT | orderSourceId | Pedido CPL | |
DK1_PRODUTO | productSourceId | Produto | |
DK1_QTD | quantity | Quantidade | |
DK1_PRECO | price | Preço | |
DK1_DATENT | deliveryDate | Dt/Hr Entrg | |
DK1_ORIGEM | integrationSource | ID da origem de dados |
Processos
Foi realizado tratamento na rotina Carga de Dados (OMSXCPL2), para a carga de dados do módulo SIGAOMS para o Cockpit Logístico, permitindo a sincronização dos Cadastros de Filiais, Clientes, Produtos, Tipos de Veículos, Fornecedores e Transportadora.
Além disso, foi disponibilizada uma nova rotina Envio de Pedidos de Venda (OMSXCPL6), que permite a seleção e envio de pedidos de vendas criados no módulo SIGAOMS para o CPL gerando pedidos de transporte, e uma nova rotina Monitor de Cargas (OMSXCPL7), que monitora e recebe as viagens geradas no CPL, para posterior geração de carga e liberação no Protheus.
Fluxo do Processo
Clientes
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: LocalityAcquisitionService
Versão: 1.000
Ao cadastrar um cliente no Protheus, quando a integração estiver ativa, os dados serão enviados ao Cockpit Logístico por meio do método updateLocalities, esses dados por sua vez serão salvos como localidade, e poderão ser visualizados no CPL em: CADASTRO > Localidades.
Filiais
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: LocalityAcquisitionService
Versão: 1.000
O envio de empresas/filiais não é automático, ou seja, ao cadastrar no Protheus uma nova empresa/filial, para que essas informações sejam replicadas para o Cockpit Logístico, é necessário executar a carga de dados disponível em: SIGAOMS > Atualizações > Cockpit Logístico > Carga de dados, marcando a opção SM0 - Cadastro de Filiais. Os dados serão enviados ao Cockpit Logístico por meio do método updateLocalities, esses dados por sua vez serão salvos como localidade, e poderão ser visualizados no CPL em: CADASTRO > Localidades.
Fornecedores
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: LocalityAcquisitionService
Versão: 1.000
Ao cadastrar um Fornecedor no Protheus, quando a integração estiver ativa, os dados serão enviados ao Cockpit Logístico por meio do método updateLocalities, esses dados por sua vez serão salvos como localidade, e poderão ser visualizados no CPL em: CADASTRO > Localidades.
Transportadores
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: CarrierAcquisitionService
Versão: 1.000
Ao cadastrar um Transportador no Protheus, quando a integração estiver ativa, os dados serão enviados ao Cockpit Logístico por meio do método CarrierAcquisitionService, esses dados por sua vez serão salvos como Transportadoras e poderão ser visualizados no CPL em: CADASTRO > Transportadoras.
Produtos
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: ProductAcquisitionService
Versão: 1.000
Ao cadastrar um Produto no Protheus, quando a integração estiver ativa, os dados serão enviados ao Cockpit Logístico por meio do método ProductAcquisitionService, esses dados por sua vez serão salvos como Produtos Simples e poderão ser visualizados no CPL em: CADASTRO > Produtos Simples.
Tipos de veículo
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: VehicleAcquisitionService
Versão: 1.000
Ao cadastrar um Tipo de veículo no Protheus, quando a integração estiver ativa, os dados serão enviados ao Cockpit Logístico por meio do método VehicleAcquisitionService, esses dados por sua vez serão salvos como Veículos e poderão ser visualizados no CPL em: CADASTRO > Veículos.
Pedidos de venda
Tipo de Fluxo: Protheus > Cockpit Logístico
Mensagem: OrderAcquisitionService
Versão: 1.000
Ao cadastrar um Pedido de venda no Protheus, quando a integração estiver ativa, os dados são enviados ao Cockpit Logístico por meio do método OrderAcquisitionService, esses dados por sua vez geram no CPL Pedidos de transporte e poderão ser visualizados em: PROGRAMAÇÃO > Analise, deve-se filtrar os dados da cesta geral.
No módulo SIGAOMS, foi disponibilizado um programa (OMSXCPL6) que permite selecionar uma lista com os pedidos de venda para envio ao Cockpit Logístico. Os pedidos deverão estar liberados por crédito e estoque e com o campo "Carga" igual a 1 = Utiliza.
O cancelamento do pedido no CPL, pode ser feito por meio de duas rotinas:
Cancelamento via rotina Preparação dos Documentos de Saída (MATA460A):
- Quando houver o cancelamento de uma liberação do pedido de venda por meio da rotina "Preparação dos Documentos de Saída", opção "Ações Relacionadas" / "Estor. Docs" na confirmação da exclusão do registro, é realizado o envio do cancelamento ao CockPit Logístico.
Cancelamento via rotina Pedido de Venda (MATA410):
- Alteração de um pedido de venda já liberado na rotina "Pedido de Venda" (MATA410):
- Ao confirmar a alteração, o sistema realiza a exclusão do registro liberado, assim é realizado o envio do cancelamento ao CockPit Logístico.
- Alteração de pedido de venda já liberado e com nova liberação na própria rotina (MATA410):
- Ao confirmar a alteração com nova liberação, o sistema exclui o registro anterior e recria um novo registro com as informações da alteração. Assim, é realizado o envio do cancelamento para o Cockpit Logístico e o envio de um novo pedido liberado.
- Alteração de um pedido de venda já liberado na rotina "Pedido de Venda" (MATA410):
Cargas
Tipo de Fluxo: Cockpit Logístico > Protheus
Mensagem: ReleaseTripPublishRequestService
Versão: 1.000
O Cockpit Logístico envia as viagens geradas para o módulo SIGAOMS para a formação das Cargas. O envio é realizado pela chamada do WebService ReleaseTripPublishRequestService, para isso foi disponibilizado um programa monitor para receber estas viagens (OMSXCPL7).
A rotina oferece a opção de marcação dos registros e um botão "Gera Carga", para geração das Cargas no OMS.
Uma vez recebida a viagem do Cockpit e gerada a Carga no módulo SIGAOMS, após a geração do documento fiscal da carga (NF de Saída) é enviada novamente ao Cockpit uma mensagem de retorno com a confirmação da gravação da Carga e documento de saída, assim o Cockpit confirma a viagem gerada, este retorno é realizado pelo WebService publishReleasedTripResponse, mensagem UnblockReleasedTripAcquisition. Esta chamada ocorre por meio da opção "Liberar Viagem".
|
5. Instalação / Configuração
5.1. Configuração Web Service AppServer Protheus
Para que seja possível receber as viagens do TOTVS Otimização Logística é necessário configurar um Web Service no servidor de aplicação Protheus.
Informações | ||
---|---|---|
| ||
A configuração do JOB do Web Service para ser utilizado nesta integração não utiliza os métodos padrão do Framework Protheus, sendo assim as rotinas ONSTART e ONCONNECT são específicas do módulo, portanto, os métodos disponíveis neste WS não são listados no WS do Protheus. |
É recomendado criar um Web Service com as seguintes configurações (modificando o arquivo Appserver.ini):
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
;Serviço webserver HTTP
[HTTP]
ENABLE=1
PATH=<Caminho_Cache_imagens>;C:\TOTVS\Prottheus\data\web
PORT=<porta>;8080
INSTANCES=<nInicio>,<nMaximo>;1,10
SESSIONTIMEOUT=60
INSTANCENAME=WS_HTTP
;URL de resposta
[<ip ou nome>:<porta>/neolog]
ENABLE=1
PATH=<Caminho_Cache_imagens>;C:\TOTVS\Prottheus\data\web
ENVIRONMENT=<ambiente>
INSTANCENAME=WS_NEOLOG
RESPONSEJOB=JOB_WS_NEOLOG
DEFAULTPAGE=wsindex.apw
;JOB de resposta
[JOB_WS_NEOLOG]
TYPE=WEBEX
ENVIRONMENT=<ambiente>
INSTANCES=<nInicio>,<nMaximo>;1,10
INSTANCENAME=JOB_WS_NEOLOG
ONSTART=OMSXStart
ONCONNECT=OMSXConnect |
Para testar o serviço, inicie um navegador e digite: http://<ip ou nome>:<porta>/neolog/PublishReleasedTrip.APW?WSDL.
Um WSDL (descrição do serviço em XML) será exibido no navegador..
Para que seja possível reprogramar/cancelar as viagens do TOTVS Otimização Logística é necessário configurar as informações de conexão com o DBAccess diretamente na seção [Environment] (modificando o arquivo Appserver.ini), conforme exemplo abaixo:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
;Nome do Ambiente acessado pelo Web Service
[Environment]
SourcePath=C:\Totvs\Protheus\Apo
RootPath=C:\Totvs\Protheus\Data
StartPath=\system\
. . . ; outras chaves
DBDatabase=MSSQL
DBAlias=PLS101
DBServer=192.168.1.20
DBPort=7890 |
Para evitar inconsistências do tipo Failed Handshake SSL recomenda-se incluir a seguinte configuração no Appserver.ini:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
[SSLConfigure]
TryProtocols=1
Verbose=1 |
5.2. Parametrização TOTVS Otimização Logística
Para configurar o envio de viagens do TOL para o Web Service Protheus, acesse o TOL e execute os seguintes passos:
- Administração > Integração, selecione a pasta Fontes de Dados e clique em Inserir.
- Digite o código, a descrição e o código da base (sugestão: PROTHEUS).
- Seção Cancelamento de Viagem Liberada
- No campo URL, digite http://<ip ou nome>:<porta>/neolog/CancelService.APW.
- No campo Tempo Máximo de Espera por Resposta, informe o timeout do serviço (recomendado 30000).
4. Seção Execução da Viagem
- No campo URL, digite: NA (Não Atribuído).
- No campo Tempo Máximo de Espera por Resposta, informe o timeout do serviço (recomendado 1000).
5. Seção Solicitação de liberação de Viagem
- No campo URL, digite http://<ip ou nome>:<porta>/neolog/PublishReleasedTrip.APW.
- No campo Tempo Máximo de Espera por Resposta, informe o timeout do serviço (recomendado 30000).
6. Seção Solicitação de Reprogramação de Viagem
- No campo URL, digite: http://<ip ou nome>:<porta>/neolog/ReprogramService.APW.
- No campo Tempo Máximo de Espera por Resposta, informe o timeout do serviço (recomendado 30000).
7. Clique em Salvar.
5.3. Parametrização TOTVS OMS
Acesse o menu Atualizações > TOTVS Otimização Logística > Parâmetros Integração (OMSXCPL1).
Para o correto funcionamento da integração, parametrize o Protheus da seguinte forma:
Campo | Descrição | Parâmetro | Opções | Valor para Integração | Validação | |||||
---|---|---|---|---|---|---|---|---|---|---|
Integração Planejamento Viagem? | Indica se a integração com o planejamento de viagens do TOL está ativa. | MV_CPLINT | 1 - Sim | 1 - Sim | ||||||
Integração Suspensa? | Indica se a integração com o TOL está temporariamente suspensa. | MV_CPLSTP | 1 - Sim 2 - Não | 2 - Não | ||||||
Integrar Clientes On line? | Indica se ao incluir ou alterar um cliente no Protheus será replicado automaticamente no TOL (Localidades). | MV_CPLCLI | 1 - Sim 2 - Não | 1 - Sim | ||||||
Integrar Fornecedores On line? | Indica se ao incluir ou alterar um fornecedor no Protheus será replicado automaticamente no TOL (Localidades). | MV_CPLFOR | 1 - Sim 2 - Não | 1 - Sim | ||||||
Integrar Transportadora On line? | Indica se ao incluir ou alterar um transportador no Protheus será replicado automaticamente no TOL. | MV_CPLTRA | 1 - Sim 2 - Não | 1 - Sim | ||||||
Integrar Produtos On Line? | Indica se ao incluir ou alterar um produto no Protheus será replicado automaticamente no TOL. | MV_CPLPRO | 1 - Sim 2 - Não | 1 - Sim | ||||||
Integrar Tipos de Veículos On line? | Indica se ao incluir ou alterar um tipo de veículo no Protheus será replicado automaticamente no TOL. | MV_CPLTPV | 1 - Sim | 1 - Sim | ||||||
Tipo Veículo Otimização? | Quando for : 1 - Impedir: no vínculo do veículo na carga, se for informado um tipo de veículo diferente do que consta na viagem do TOL, não será permitido, sendo apresentado um Help. 2 - Alertar: o sistema avisa que o tipo informado é diferente do tipo da viagem no TOL e o usuário define se permite o vínculo ou não.
| MV_CPLTVO | 1 - Impedir | 2 - Alertar (padrão) | ||||||
Endereço Web Service Planejamento Viagem | Endereço do Web Service do módulo de Planejamento do TOTVS Otimização Logística. | MV_CPLURL | Conforme cliente. Exemplo: | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | ||||||
Endereço Web Service de Autenticação | Endereço do Web Service de Autenticação do TOTVS Otimização Logística. Este endereço fornecerá um token de autenticação, que deverá ser utilizado nas requisições efetuadas ao TOL, quando este estiver parametrizado para solicitar autenticação. | MV_CPLUAUT | Conforme cliente. Exemplo: | |||||||
Usuário de Autenticação do Web Service | Usuário utilizado para efetuar login no TOTVS Otimização Logística, para obtenção do token. | MV_USRCPL | Conforme cliente | Deve ser obrigatoriamente preenchido quando possuir URL de autenticação. | ||||||
Senha de Autenticação do WebService | Senha do usuário utilizado para efetuar login no TOTVS Otimização Logística, para obtenção do token. | MV_PSWCPL | Conforme cliente | Deve ser obrigatoriamente preenchido quando possuir URL de autenticação. | ||||||
Quantidade de Horas para Considerar que o Token Expirou | Indica a quantidade de horas que devem ser consideradas para que um token esteja expirado. Enquanto este limite não for atingido, o mesmo token recebido na primeira solicitação será reutilizado para envio das próximas mensagens. | MV_EXPTOK | Conforme cliente | |||||||
Regional | Regional enviada para o TOTVS Otimização Logística. | MV_CPLREG | Conforme cliente | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | ||||||
Embarcador | Código de um Embarcador do TOL. Todos os produtos integrados do TOTVS OMS para o TOTVS Otimização Logística serão relacionados a um mesmo Embarcador no TOL, pois no TOTVS OMS a relação variável de produto x cliente é utilizada (opcionalmente) apenas na importação de Notas Fiscais de Cliente pelo EDI. | MV_CPLEMB | Conforme cliente | Deve ser obrigatoriamente preenchido quando MV_CPLINT == "1" | ||||||
Categoria de Produto? | Para o TOTVS Otimização Logística, categorias de produto são agrupamentos relevantes de produtos com características logísticas semelhantes. Com esse parâmetro é possível determinar se a categoria dos produtos integrados do TOTVS OMS para o TOTVS Otimização Logística, sendo que: 1 - Grupo Produto: será o código do grupo do produto do TOTVS OMS. 2 - Padrão Cockpit: será informada por alteração manual, em cada produto no TOL. Com essa opção é necessário cadastrar as Categorias de Produtos no TOTVS Otimização Logística. com os mesmos códigos dos Grupos de Produtos do TOTVS OMS, pois não há Web Service de integração para essa tabela. | MV_CPLCAT | 1 - Grupo Produto 2 - Padrão TOL | 2 - Padrão TOL | ||||||
Invólucro Padrão | Código de um Invólucro (embalagem) do TOTVS Otimização Logística. Todos os itens de Pedidos de Transporte recebidos do TOTVS OMS no TOL serão associados a esse invólucro, pois não há uma entidade no TOTVS OMS que corresponda exata e obrigatoriamente a esse dado do TOL. É recomendável informar um invólucro cujas medidas sejam obtidas do item do pedido (esta característica é parametrizada no TOTVS Otimização Logística. | MV_CPLINV | Conforme cliente | |||||||
Origem dos Dados | Define o nome do ERP que origina os dados enviados ao TOTVS Otimização Logística. | MV_CPLIDS | Deve ser informada a fonte de dados criada dentro do TOL. Exemplo: | Deve ser obrigatoriamente preenchido quando MV_CPLINT = "1" | ||||||
E-mail do Administrador | E-mail do administrador para notificações de falha de conexão. | MV_CPLMAL | Conforme cliente. | |||||||
UM a Considerar? | Este parâmetro permite indicar a unidade de medida a ser considerada na integração dos Itens dos Pedidos de Venda com o TOTVS Otimização Logística, onde:
| MV_CPLUMIT | 1 - 1ª UM 2 - 2ª UM | 1 - 1ª UM (padrão) | ||||||
Geração das Cargas | Quando for: 1 - Automático, para as viagens vindas do Cicjoutm; o OMS gera a carga automaticamente. 2 - Manual,: para as viagens deve ser gerada manualmente a carga.
| MV_CPLAUT | 1 - Automático 2 - Manual | 2 - Manual (padrão) | ||||||
Liberação automática da viagem? | O uso deste parâmetro ocorre somente para o TOTVS OMS. Quando habilitado, ao realizar a integração da viagem vinda do TOTVS Otimização Logística, o sistema realizará o envio da liberação de viagens de forma automática. | MV_CPLLVA | 1 - Sim | 2 - Não (padrão) | ||||||
Permite enviar quantidades não liberadas para o TOL? | Ao ativar esse parâmetro o Protheus permitirá a integração de pedidos sem liberação de estoque com o TOL. Com isso, todas as informações serão integradas com base na tabela SC6 (Itens do Pedido de Venda). | MV_CPLPELB | 1 - Sim | 2 - Não (padrão) | ||||||
Permite estorno automático da carga ao cancelar ou reprogramar viagem? | Indica se será permitido efetuar o estorno automático da carga ao cancelar ou reprogramar uma viagem, ou seja, quando o usuário do TOTVS Otimização Logística solicitar o cancelamento / reprogramação da viagem, caso exista carga montada no TOTVS OMS esta será estornada.
| MV_CPLESCG | 1 - Sim | 2 - Não (padrão) | ||||||
Atualiza viagem no TOL ao cancelar a integração do pedido? | Indica se será atualizada a viagem no TOL ao cancelar a integração no TOTVS OMS, ou seja, se esse parâmetro estiver definido como 1 - Sim, ao cancelar um item integrado que já encontra-se em uma viagem, será solicitada a alteração da viagem no TOL para que reflita os ajustes sofridos no TOTVS OMS. Caso esteja definido como 2 - Não, a viagem permanecerá intacta, sendo ajustada apenas a carga e os status no TOTVS OMS.
| MV_CPLATVG | 1 - Sim | 2 - Não (padrão) | ||||||
Tempo máximo (em segundos) de inatividade permitida para a recepção da resposta (Timeout). | Indica o tempo máximo que o TOTVS OMS aguardará por uma resposta do TOTVS Otimização Logística. Válido para todos as as mensagens. | MV_CPLTIME | 30 (padrão) | |||||||
Integração Monitoramento? | Indica se a integração com o monitoramento do TOL está ativa. Mais detalhes no documento: Integração TOTVS OMS x TOTVS Otimização Logística (Monitoramento) | MV_CPLMON | 1 - Sim | |||||||
Endereço WebService Monitoramento | Endereço do Web Service de Monitoramento do TOL. É necessário informar somente quando a integração com o monitoramento encontra-se ativa. Mais detalhes no documento: Integração TOTVS OMS x TOTVS Otimização Logística (Monitoramento) | MV_CPLURL | Conforme cliente. | |||||||
Redesp. Cli/Forn (Envio de dados do redespachante do pedido) | O parâmetro MV_CPLRED define se serão enviados os dados do cliente/fornecedor no destinationId e as informações de endereço ao TOL quando o campo C5_REDESP do pedido está preenchido. Seguem as opções: 1-Sim - Quando o campo C5_REDESP está preenchido serão enviados os dados do cliente/fornecedor no elemento destinationId e não serão enviadas as informações de endereço. 2-Não - Valor padrão - Quando o campo C5_REDESP está preenchido serão enviados os dados da transportadora e os elementos de endereço. O parâmetro pode ser acessado via menu Atualizações > Cockpit Logístico > Parâmetros da Integração. No programa de parâmetros, a opção foi inserida em Integração, campo Redesp. Cli/Forn (1-Sim, 2-Não). | MV_CPLRED | 1 - Sim 2 - Não | 2 - Não (padrão) |
5.4. Parametrização Adicional Integração
Algumas parametrizações da integração devem ser realizadas no arquivo de configuração do servidor Protheus (Appserver.ini), pois são utilizadas antes de iniciar qualquer processo de conexão com o SGDB.
As configurações abaixo devem ser incluídas no arquivo na seção [NEOLOG]:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
Configuração integração com o TOTVS Otimização Logística:
[NEOLOG]
DefaultCompany=<empresa>
Debug=1
DebugPath=<caminho relativo> ;logs\neolog |
Onde:
DefaultCompany
Empresa padrão para integração entre o TOTVS OMS e o TOTVS Otimização Logística.
Se não for informado não será considerado, sendo sempre enviada nas mensagens nos campos que identificam os códigos, além do próprio código, a concatenação da empresa e do campo Filial do respectivo cadastro/processo.
Caso esteja parametrizada será enviada apenas a concatenação do código com campo Filial do respectivo cadastro/processo. Clique aqui para obter mais detalhes.Informações title Dados da Filial Protheus Será verificado no cadastro de Filiais Protheus se utiliza o conceito de Gestão de Empresas, será enviado ao invés de Empresa/Filial o modelo Empresa/Unidade/Filial. Exemplo: M SP 01
- Debug
Indicador de que o processo de gravação dos arquivos XML das mensagens trocadas entre o TOTVS OMS e o TOL está ativo.
Caso esteja com o valor 1, será considerado ativo; caso contrário, será considerado inativo.
Caso esta configuração não exista será assumido, por padrão, que o Debug está ativo. DebugPath
Caminho onde serão gravados os arquivos de log do XML, o qual deve ser sempre relativo a pasta RootPath, pois o processo de integração pode rodar em modo JOB e, desta forma, não tem acesso a diretórios locais da máquina.
Caso não esteja parametrizado será considerado o caminho padrão system/neolog.
Informações | ||
---|---|---|
| ||
Deve ser parametrizado via algum processo do sistema operacional do servidor, uma rotina que efetue exclusão programada dos arquivos log da pasta definida no DebugPath, deixando apenas os mais atuais. |
6. Controle de Versão
O Grupo TOTVS, representado por suas marcas, administrará as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.
Todas as evoluções programadas devem 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.
7. Suporte
O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim, as equipes de suporte dos produtos BackOffice Protheus estarão aptas a efetuar a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.
Informações | ||
---|---|---|
| ||
Este modelo de suporte está sendo revisado pela TOTVS. |
8. Mensagens
Método | Descrição | Origem | Destino | XSD |
---|---|---|---|---|
Cadastros | Empresas/Filiais | Protheus | TOL | LocalityAcquisitionService |
Cliente | Protheus | TOL | LocalityAcquisitionService | |
Fornecedor | Protheus | TOL | LocalityAcquisitionService ou CarrierAcquisitionService | |
Transportadora | Protheus | TOL | CarrierAcquisitionService | |
Produtos | Protheus | TOL | ProductAcquisitionService | |
Tipo de Veículo | TOTVS OMS | TOL | VehicleAcquisitionService | |
Processos | Pedido de Vendas | TOTVS OMS | TOL | OrderAcquisitionService |
Cancelar Pedido de Vendas | TOTVS OMS | TOL | OrderAcquisitionService | |
Publicar Viagens | TOL | TOTVS OMS | PublishReleasedTrip | |
Liberar Viagens | TOTVS OMS | TOL | UnblockReleasedTripAcquisitionService | |
Cancelar Viagens | TOL | TOTVS OMS | CancelService | |
Reprogramar Viagens | TOL | TOTVS OMS | ReprogramService |
9. Fluxo das Informações
Os cadastros devem ser realizados no TOTVS OMS e integrados ao TOTVS Otimização Logística.
A ativação da integração, no entanto, não impede a inclusão, alteração e exclusão de registros no TOL, mas esse procedimento não é recomendado, pois as operações realizadas sobre os cadastros no TOL não são replicadas para os respectivos cadastros no Protheus.
Apenas as operações de inclusão e alteração são consideradas na integração e são efetuadas sempre que ocorrerem, desde que parametrizadas para serem on-line.
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 Protheus.
O sucesso das operações de inclusão e alteração de registros pode ser verificado acessando o programa de consulta no menu do TOL 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.
Entidade (s) Protheus | Código (Alías) | Web Service | Método | Entidade Cockpit | Observações |
---|---|---|---|---|---|
Filial | SM0 | LocalityAcquisitionService | updateLocalities | Localidade | As filiais assumem o papel de localidade quando são locais de carga ou descarga. Quando MV_CPLEX == "2" não integrar a filial cuja unidade de federação não faça parte da lista de unidades de federação do Brasil. |
Cliente | SA1 | LocalityAcquisitionService | updateLocalities | Localidade | Quando MV_CPLEX == "2" não integrar cliente com país informado diferente de 105 (Brasil). |
Fornecedor | SA2 | LocalityAcquisitionService ou CarrierAcquisitionService | updateLocalities ou updateCarriers | Localidade | Os fornecedores serão integrados como localidade quando atender os seguintes requisitos:
Caso contrário, o fornecedor será integrado como transportadora. |
Transportadora | SA4 | CarrierAcquisitionService | updateCarriers | Transportador | |
Produto | SB1 e SB5 | ProductAcquisitionService | updateProducts | Produto | |
Tipo de Veículo | DUT | VehicleAcquisitionService | updateVehicles | Veículo | |
Pedido de Venda | SC5 / SC6 / SC9 / SB1 / SB5 | OrderAcquisitionService | createOrders | Pedidos de Transporte | O pedido de venda deve possuir, obrigatoriamente, montagem de carga. |
9.1. Filiais
Tipo de Fluxo: Protheus > TOTVS Otimização Logística.
Mensagem: LocalityAcquisitionService
O envio de empresas/filiais ou empresas/unidade/filiais não é automático, ou seja, ao cadastrar no Protheus uma nova empresa/filial, para que essas informações sejam replicadas para o TOTVS Otimização Logística é necessário executar a carga de dados disponível em: SIGAOMS > Atualizações > TOTVS Otimização Logística > Carga de dados, assinalando a opção SM0 - Cadastro de Filiais.
Os dados serão enviados ao TOTVS Otimização Logística por meio do método updateLocalities.
Esses dados, por sua vez, serão salvos como localidade e poderão ser visualizados no CPL em: Cadastro > Localidades.
9.2. Clientes
Tipo de Fluxo: Protheus > TOTVS Otimização Logística.
Mensagem: LocalityAcquisitionService
Ao cadastrar um cliente no Protheus, quando a integração estiver ativa os dados serão enviados ao TOTVS Otimização Logística por meio do método updateLocalities.
Esses dados, por sua vez, serão salvos como localidade e poderão ser visualizados no TOL em: Cadastro > Localidades.
Fornecedores
Tipo de Fluxo: Protheus > TOTVS Otimização Logística.
Mensagem: LocalityAcquisitionService ou CarrierAcquisitionService
Ao cadastrar um fornecedor no Protheus, quando a integração estiver ativa os dados serão enviados ao TOTVS Otimização Logística por meio do método updateLocalities (conforme parametrização do cadastro SA2, de acordo com o comentado acima).
Esses dados, por sua vez, serão salvos como localidade e poderão ser visualizados no TOL em: Cadastro > Localidades.
9.3. Transportadores
Tipo de Fluxo: Protheus > TOTVS Otimização Logística.
Mensagem: CarrierAcquisitionService
Ao cadastrar um transportador no Protheus, quando a integração estiver ativa os dados serão enviados ao TOTVS Otimização Logística por meio do método CarrierAcquisitionService.
Esses dados, por sua vez, serão salvos como transportadoras e poderão ser visualizados no TOL em: Cadastro > Transportadoras.
9.4. Produtos
- Tipo de Fluxo: Protheus > TOTVS Otimização Logística.
- Mensagem: ProductAcquisitionService
- Ao cadastrar um produto no Protheus, quando a integração estiver ativa os dados serão enviados ao TOTVS Otimização Logística por meio do método ProductAcquisitionService.
- Esses dados, por sua vez, serão salvos como produtos simples e poderão ser visualizados no TOL em: Cadastro > Produtos Simples.
9.5. Tipos de Veículo
Tipo de Fluxo: TOTVS Otimização Logística
Mensagem: VehicleAcquisitionService
Ao cadastrar um tipo de veículono Protheus, quando a integração estiver ativa os dados serão enviados ao TOTVS Otimização Logística por meio do método VehicleAcquisitionService.
Esses dados, por sua vez, serão salvos como veículos e poderão ser visualizados no TOL em: Cadastro > Veículos.
9.6. Pedidos de Venda
- Tipo de Fluxo: Protheus > TOTVS Otimização Logística
- Mensagem: OrderAcquisitionService
9.6.1. Envio de Pedidos
Ao cadastrar um Pedido de venda no Protheus, quando a integração estiver ativa os dados são enviados ao TOTVS Otimização Logística por meio do método OrderAcquisitionService.
Esses dados, por sua vez, geram no TOTVS Otimização Logística o pedidos de transporte e poderão ser visualizados em: Programação > Análise; deve-se filtrar os dados da cesta geral.
No TOTVS OMS foi disponibilizada a rotina OMSXCPL6 (Envio de Pedido de Venda), que permite selecionar uma lista com os pedidos de venda para envio ao TOTVS Otimização Logística, sendo que estes pedidos são filtrados conforme as seguintes premissas:
- O pedido deve montar carga (C5_TPCARGA).
- O pedido não deve estar faturado (C9_NFISCAL).
- O pedido deve respeitar o range de dados dos filtros da rotina.
- Se o sistema estiver parametrizado para não permitir o envio de pedidos sem liberação (MV_CPLPELB = '2'), os pedidos retornados não devem possuir bloqueios de estoque (C9_BLEST) e crédito (C9_BLCRED).
- Se o sistema estiver parametrizado para permitir o envio de pedido sem liberação (MV_CPLPELB = '1'), será permitido o envio de toda a quantidade do pedido (C6_QTDVEN), mesmo que existam bloqueios.
Após os pedidos serem filtrados, a rotina OMSXCPL6 (Envio de Pedido de Venda) ainda permite alterar as quantidades para a integração pelo botão Alterar Quantidade da Integração - F10, sendo que, por seu intermédio é possível informar quais quantidades do pedido serão integradas, onde cada integração do pedido gera um sequência de integração diferente.
Exemplo
Empresa | Filial | Seq. Integração | Pedido | Item | Produto | Qtd. | Descrição |
---|---|---|---|---|---|---|---|
03 | 01 | 000001 | 000096 | 01 | 001 | 10 | Sequência de envio 01 |
03 | 02 | 000002 | 000096 | 01 | 001 | 5 | Sequência de envio 02 |
Sendo assim, a identificação do pedido será sempre a combinação da empresa+filial+sequência de integração+pedido.
Exemplo: 0301000001000096
Caso os dados da filial protheus seja do tipo Gestão de Empresas, será enviada a concatenação empresa+unidade de negócio+filial+sequência de integração+pedido.
Exemplo:MSP01000001000096
Ao efetivar o envio, as seguintes tabelas sofrem alterações/inclusões:
- DK3 - Tabela de Sequência de Integração do Pedido
Gravará a quantidade enviada ao TOL, incluindo as informações de pedido e a sequência de integração.
As sequências de integração que encontram-se efetivamente integradas com o TOL possuem o status (DK3_STATUS) 1 - Integrado. - SC6 - Itens do Pedido de Venda
Gravará o status (C6_INTROT) 2 - Integrado, para pedidos totalmente integrados e 4 - Integrado Parcial, para pedidos que ainda possuem quantidades a serem integradas.
9.6.2. Cancelamento de Pedidos
O cancelamento de pedidos ocorre apenas pela rotina OMSXCPL6 (Envio de Pedidos de Venda), na qual estão disponíveis as seguintes opções:
- Desatualizar Pedido Posicionado
Permite selecionar a sequência que terá a integração cancelada.
Também permite efetuar o cancelamento parcial de uma sequência de integração pela digitação da Qtd. Cancelamento. Desatualizar Pedido(s) Selecionado(s):
Permite efetuar o estorno de todas as sequências de integração, de todos os pedidos selecionados no browse.Informações title IMPORTANTE! Caso o parâmetro MV_CPLATVG (Atualiza viagem no TOL ao cancelar a integração do pedido?) estiver ativo em conjunto com as devidas parametrizações do TOTVS Otimização Logística, todas as viagens das sequências de integração selecionadas serão canceladas automaticamente.
Por este motivo, recomenda-se cautela ao utilizar a opção de cancelamento de todos os pedidos selecionados.
Ao efetivar o cancelamento, as seguintes tabelas sofrerão alterações/inclusões:
- DK3 - Tabela de Sequência de Integração do Pedido
Alterará o status da sequência de integração (DK3_STATUS) para 3 - Cancelado Parcial, quando apenas parte da sequência é estornada, ou então para 2 - Cancelado, quando toda a quantidade da sequência é cancelada do TOL. - SC6 - Itens do Pedido de Venda
Gravará o status (C6_INTROT) igual a 1 - Não Integrado, quando apenas parte do item teve a integração cancelada, ou então, gravará o status igual a 4 - Integrado Parcial, quando parte da quantidade do item permanecerá integrada.
9.7. Viagens
Tipo de Fluxo: TOTVS Otimização Logística > Protheus
Mensagem: ReleaseTripPublishRequestService
O TOL envia as viagens geradas para o TOTVS OMS, para a formação das cargas, sendo que o envio é realizado pela chamada do Web Service ReleaseTripPublishRequestService.
Para isso, foi disponibilizada a rotina OMSXCPL7 (Monitor de Cargas), que será responsável pelo gerenciamento das cargas em questão.Ao receber uma viagem com o campo Placa (DK0_PLACA) preenchido é realizada uma busca pela placa no cadastro de veículos (DA3).
Se encontrado algum registro, o veículo será associado a carga. Para que isso ocorra é essencial que a placa recebida do TOL seja idênticaa placa cadastrada no Protheus.Ao receber a viagem no TOTVS OMS serão gravadas as tabelas DK0 (Viagem CPL) e DK1(Itens da Viagem CPL) com suas respectivas quantidades recebidas do TOL. Além disso, é registrado o código da viagem na tabela auxiliar de Sequência de Integração TOL (DK3), quando esta existir, mais especificamente no campo DK3_VIAGID.
Já no processo de geração da carga, que pode ocorrer de forma automática no momento da geração da viagem ou posteriormente via rotina OMSXCPL7 (Monitor de Cargas) serão avaliadas as quantidades liberadas do Pedido (C9_QTDLIB) para a gravação do código da carga, visto que a rotina de OMSXCPL6 (Envio de Pedidos de Venda), permite a integração de quantidades não liberadas e a montagem da carga necessita, obrigatoriamente, de quantidades liberadas do Pedido.
No próximo tópico são listadas as correspondências entre os campos de cada entidade e a respectiva tag XML da mensagem de integração.
Informações | ||
---|---|---|
| ||
|
10. Detalhamento das Mensagens
10.1. Mensagem de Integração dos Registros do Cadastro de Filiais
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações | |||||
---|---|---|---|---|---|---|---|---|
regionSourceId | MV_CPLREG | Regional | ||||||
identifier | "FIL-" + FWCodFil() | Código | O envio da concatenação de empresa +unidade+ filial permanece condicionado ao fato de não existir uma empresa padrão para integração do TOTVS OMS com o TOL. Esta empresa padrão deve ser informada no arquivo de configuração do servidor Protheus (Appserver.ini) na seção [NEOLOG] na chave DefaultCompany.
| |||||
name | M0_FILIAL | Nome | ||||||
description | M0_NOMECOM | Descrição | ||||||
addressStreet | M0_ENDENT | Endereço | Obter o conteúdo utilizando a função LjFiGetEnd sobre o campo M0_ENDENT | |||||
addressNumber | Nº | Obter o conteúdo utilizando a função LjFiGetEnd sobre o campo M0_ENDENT | ||||||
addressComplement | M0_COMPENT | Complemento | ||||||
addressDistrict | M0_BAIRENT | Bairro | ||||||
addressZipCode | M0_CEPENT | CEP | ||||||
addressCity | M0_CIDENT | Cidade | ||||||
addressStateAcronym | M0_ESTENT | UF | Quando a UF pertencer a lista das UFs brasileiras será considerado a mesma; caso contrário "EX". | |||||
addressCountryAcronym | "BR" ou "EX" | País | Quando a UF pertencer a lista das UFs brasileiras, será considerado "BR"; caso contrário "EX". | |||||
logisticRoleId | "1" | Tipo | 1 - Ambos |
10.2. Mensagem de Integração dos Registros do Cadastro de Clientes
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações |
---|---|---|---|
regionSourceId | MV_CPLREG | Regional | |
identifier | "CLI-" + RTrim(SA1->A1_COD) + "-" + RTrim(SA1->A1_LOJA) + OMSXGETFIL("SA1") ² | Código | |
name | A1_NREDUZ | Nome | |
description | A1_NOME | Descrição | |
addressStreet | A1_END | Endereço | Obter o conteúdo usando a função LjFiGetEnd sobre o campo A1_END |
addressNumber | Nº | Obter o conteúdo usando a função LjFiGetEnd sobre o campo A1_END | |
addressComplement | A1_COMPLEM | Complemento | |
addressDistrict | A1_BAIRRO | Bairro | |
addressZipCode | A1_CEP | CEP | |
addressCity | CC2_MUN | Cidade | Acessa a tabela CC2 pelos campos A1_ESTE e A1_CODMUNE. |
addressStateAcronym | A1_EST | UF | Quando a UF pertencer a lista das UFs brasileiras será considerada a mesma; caso contrário EX. |
addressCountryAcronym | "BR" ou YA_SIGLA | País | Acessar a tabela SYA pelo campo A1_PAIS. Quando A1_PAIS estiver em branco ou igual a 105 será atribuído BR. |
logisticRoleId | "2" | Tipo | 2 - Destino (por orientação do TOL, para gerar menos combinações de rota). |
10.3. Mensagem de Integração dos Registros do Cadastro de Fornecedor Como Localidade
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações |
---|---|---|---|
regionSourceId | MV_CPLREG | Regional | |
identifier | FOR- + RTrim(SA2->A2_COD) + "-" + RTrim(SA2->A2_LOJA) + OMSXGETFIL("SA2") ² | Código | Será adicionada a sigla FOR para composição do código para identificação que se trata de um fornecedor para uso como uma localidade, devido aos pedidos de beneficiamento do TOTVS OMS. |
name | A2_NREDUZ | Nome | |
description | A2_NOME | Descrição | |
addressStreet | A2_END | Endereço | Obter o conteúdo usando a função LjFiGetEnd sobre o campo A2_END |
addressNumber | N° | Obter o conteúdo usando a função LjFiGetEnd sobre o campo A2_END | |
addressComplement | A2_COMPLEM | Complemento | |
addressDistrict | A2_BAIRRO | Bairro | |
addressZipCode | A2_CEP | CEP | |
addressCity | CC2_MUN | Cidade | Acessar a tabela CC2 pelo campo A2_MUN. |
addressStateAcronym | A2_EST | UF | Quando a UF pertencer a lista das UFs brasileiras será considerada a mesma; caso contrário EX. |
addressCountryAcronym | BR ou YA_SIGLA | País | Acessar a tabela SYA pelo campo A2_PAIS. Quando A2_PAIS estiver em branco ou igual a 105, atribuir BR. |
logisticRoleId | "2" | Tipo | 2 - Destino (por orientação do TOL, para gerar menos combinações de rota). |
10.4. Mensagem de Integração dos Registros do Cadastro de Fornecedor Como Transportadora
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações |
---|---|---|---|
regionSourceId | MV_CPLREG | Regional | |
identifier | A2_COD + OMSXGETFIL("SA2") ² | Código | |
name | A2_NREDUZ | Nome da Transportadora | |
description | A2_NOME | Descrição da Transportadora | |
A2_EMAIL | E-mail da Transportadora |
10.5. Mensagem de Integração dos Registros do Cadastro de Transportadora
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações |
---|---|---|---|
regionSourceId | MV_CPLREG | Regional | |
identifier | A4_COD + OMSXGETFIL("SA4") ² | Código | |
name | A4_NREDUZ | Nome da Transportadora | |
description | A4_NOME | Descrição da Transportadora | |
A4_EMAIL | E-mail da Transportadora |
10.6. Mensagem de Integração dos Registros do Cadastro de Tipos de Veículos
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações |
---|---|---|---|
identifier | DUT_TIPVEI+ OMSXGETFIL("DUT") ² | Código | |
name | DUT_DESCRI | Nome | |
description | DUT_DESCRI | Descrição | |
priority | 0 | Prioridade | Valor fixo |
similarity | 0 | Similaridade | Valor fixo |
10.7. Mensagem de Integração dos Registros do Cadastro de Produto
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações |
---|---|---|---|
regionSourceId | MV_CPLREG | Regional | |
shipperId | MV_CPLEMB | Embarcador | |
identifier | B1_COD + OMSXGETFIL("SB1") ² | Código | |
description | B1_DESC | Descrição | |
productCategoryId | B1_GRUPO | Categoria | |
height | B5_ALTURLC | Altura | Pasta Logística |
length | B5_LARGLC | Comprimento | Pasta Logística |
width | B5_COMPRLC | Largura | Pasta Logística |
weight | B1_PESO ou B1_PESBRU | Peso | 1. Quando o parâmetro MV_PESOCAR estiver como "L" será enviado o campo B1_PESO; caso contrário, B1_PESBRU. 2. Quando o parâmetro MV_CPLUMIT estiver informado para enviar a primeira unidade de medida, o peso enviado será: Peso → Campo de Peso Protheus * Fator de Conversão para KG. 3. Quando o parâmetro MV_CPLUMIT estiver informado para enviar a segunda unidade de medida, o peso enviado será: Se o tipo de conversão (B1_TIPCONV) for Divisor: Peso → (Campo de Peso Protheus * Fator de Conversão para KG) * Fator de Conversão (B1_CONV) Se o tipo de conversão (B1_TIPCONV) for Multiplicador: Peso → (Campo de Peso Protheus * Fator de Conversão para KG) / Fator de Conversão (B1_CONV) |
shape | "1" | Forma | 1 - Caixa |
10.8. Mensagem de Integração dos Registros do Cadastro de Pedido de Venda
Tag XML | Campo Protheus | Campo TOTVS Otimização Logística | Observações | |||||
---|---|---|---|---|---|---|---|---|
regionSourceId | MV_CPLREG | Regional | ||||||
integrationDataSource | MV_CPLIDS | Integração | ||||||
orderTypeSourceId | Nil | Tipo do Pedido | TAG não enviada | |||||
identifier | RTrim( OMSXGETFIL("SC5",.F.)² ) + "-" +RTrim(SC5->C5_NUM) | |||||||
code | RTrim( OMSXGETFIL("SC5",.F.)² ) + "-" +RTrim(SC5->C5_NUM) | Código do Ped. Transp. | ||||||
priority | "0" | Prioridade | ||||||
erpCreationDt | Date() | Data Corrente | Data de criação do pedido. | |||||
pickupStart | ( C6_DATAEMB ou Data Atual ) + hora fixa "00:01:00" para determinar o início do dia. | Janela Embarque | ||||||
deliveryEnd | ( C5_FECENT ou C6_ENTREG ou Data Atual ) + hora fixa "23:59:59" para determinar o fim do dia. | Janela Entrega | ||||||
orderId | RTrim( OMSXGETFIL("SC5",.F.)² ) + "-" +RTrim(SC5->C5_NUM) | ID do Pedido de Transporte | ||||||
sourceId | orderId + "-" + C6_ITEM | Código do Item Ped. Transp. | Concatenação do campo anterior com o item de sequência do pedido. | |||||
productId | C6_PRODUTO + OMSXGETFIL("SB1") ² | Produto | Conforme o código enviado na mensagem de produtos. | |||||
quantity | C9_QTDLIB ou C9_QTDLIB2 | Quantidade total de unid. | Se o produto possui controle a granel, ou seja, B5_TIPUNIT igual a 0 (zero), a quantidade enviada será fixada como 1 (um). Já para produtos com controle unitário a regra aplicada será: Quando estiver parametrizado para enviar na 2ª UM e o produto possui um fator de conversão (B1_CONV) maior que 0 (zero) será enviado o valor do campo C9_QTDLIB2. Caso contrário, será enviado sempre o campo C9_QTDLIB . | |||||
price | C6_VALOR | Valor Total de unid. de prod. | ||||||
originId | "FIL-" + FWCodFil() ou "FIL-" + FWGrpCompany() + "-" + FWCodFil() | Origem Inicial | Conforme o código enviado na mensagem de localidades para os registros de filiais. | |||||
destinationId | "FOR-" + RTrim(SC5->C5_CLIENT)+ "-" + RTrim(SC5->C5_LOJAENT) + OMSXGETFIL("SA2") ² ou "CLI-" + RTrim(SC5->C5_CLIENT)+ "-" + RTrim(SC5->C5_LOJAENT) + OMSXGETFIL("SA1") ² | ID da Localidade de destino do Pedido | Pode ser enviado o código do cliente ou do fornecedor conforme enviado na mensagem de localidades. Para pedidos do tipo B ou D (C5_TIPO) será enviado o código do fornecedor, para os demais será enviado o código do cliente. | |||||
quantityInShipmentUnits | C9_QTDLIB ou C9_QTDLIB2 | Se o produto possuir controle a granel, ou seja, B5_TIPUNIT igual a 0 (zero), a quantidade enviada será fixada como 1 (um). Já para produtos com controle unitário a regra aplicada será: Depende do parâmetro MV_CPLUMIT Quando estiver parametrizado para enviar na 2ª UM e o produto possui um fator de conversão (B1_CONV) maior que zero, será enviado o valor do campo C9_QTDLIB2. Caso contrário, será enviado sempre o campo C9_QTDLIB. | ||||||
height | B5_ALTURLC | Quando houver relacionamento com o B1_PRODUTO, quando vazio será enviado por padrão o conteúdo = 0.001 | ||||||
width | B5_LARGLC | Quando vazio, por padrão o conteúdo enviado será = 0.001 | ||||||
length | B5_COMPRLC | Quando vazio, por padrão o conteúdo enviado será = 0.001 | ||||||
weight | B1_PESO ou B1_PESBRU | Peso unitário ou, para produtos a granel, o peso total | 1. Quando o parâmetro MV_CPLUMIT estiver informado para enviar a primeira unidade de medida, o peso enviado será: Peso → Campo de Peso Protheus * Fator de Conversão para KG. 2. Quando o parâmetro MV_CPLUMIT estiver informado para enviar a segunda unidade de medida, o peso enviado será: Se o tipo de conversão (B1_TIPCONV) for Divisor: Peso → (Campo de Peso Protheus * Fator de Conversão para KG) * Fator de Conversão (B1_CONV) Se o tipo de conversão (B1_TIPCONV) for Multiplicador: Peso → (Campo de Peso Protheus * Fator de Conversão para KG) / Fator de Conversão (B1_CONV)
| |||||
shipperId | MV_CPLEMB | ID do Embarcador | ||||||
modal | "1" | ID do modal do pedido de transporte | Enviar valor fixo 1 - Rodoviário. | |||||
incoterm | C5_TPFRETE | Sendo o conteúdo C = 1 e F = 0 para o TOL. Quando o campo for vazio será passado sempre 1 (um). | ||||||
shipmentUnitWrapperCode | MV_CPLINV | Invólucro de embarque | - |
² Para o combinação da filial para os cadastros serão aplicadas as seguintes regras:
Utilizando a configuração de gestão de empresas e esta possua em sua máscara a empresa:
Será enviado apenas o retorno da função xFilial( <TAB> ), onde TAB representa a tabela do Protheus.
Utilizando a configuração de gestão de empresas, sem possuir a empresa na máscara, ou não utilizando a configuração de gestão de empresas:
Caso exista uma empresa padrão (DefaultCompany) configurada na seção [NEOLOG] do INI do servidor de aplicação será enviado apenas o retorno da função xFilial( <TAB> ), onde TAB representa a tabela do Protheus.
Não existindo a empresa padrão será enviada a concatenação da função FWGrpCompany() + xFilial( <TAB> ), onde TAB representa a tabela do Protheus.
- Sempre que o retorno não for branco, este será precedido por um "-" (hífen), caso a função não receba o valor .F. no segundo parâmetro.
* Poderá ocorrer deste valor permanecer em branco, em função de algumas parametrizações e configuração da tabela ser compartilhada.
11. Configurações Complementares
11.1. Configuração Para Envio Automático de Pedidos de Venda (Schedule)
Os pedidos de venda gerados no módulo TOTVS OMS podem ser enviados automaticamente ao TOTVS Otimização Logística.
Para isso, deve ser configurada a execução automática (Schedule) da rotina OMSXCPL6 (Envio de Pedidos de Venda).
Esta configuração pode ser executada conforme descrito em Schedule Protheus.
No arquivo Appserver.ini é necessário inserir a seguinte configuração:
Bloco de código | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[OnStart]
jobs=FWSCHDMANAG,FWSCHDQUEUE
RefreshRate=60
[FWSCHDMANAG]
Main=FWSCHDMANAG
Environment=<ambiente>
[FWSCHDQUEUE]
Main=FWSCHDQUEUE
Environment=<ambiente> |
11.2. Cadastro de Fator de Conversão Para KG
O TOL possuí como característica o tratamento de peso apenas em KG, portanto, para que o TOTVS OMS envie o valor convertido é necessário cadastrar as unidades de medidas utilizadas e associar seu valor em KG.
Para realizar esse cadastro acesse SIGAOMS > Atualizações > TOTVS Otimização Logística > Fator de Conversão (OMSA140), sendo necessário realizar esse cadastro para todas as unidades de medidas dos produtos que serão utilizadas na integração, cuja relação de peso não seja em KG.
Exemplo de cadastro:
Unidade de Medida (DK2_CODUM) → TL (tonelada), Peso em KG (DK2_PESOKG) → 1000. Isso significa que a cada uma tonelada são 1000 kg.
Informações | ||
---|---|---|
| ||
Uma explicação detalhada sobre o tipo e o fator de conversão pode ser obtida em: Explicação 1ª e 2ª UM.pdf |
11.3. Modo de Compartilhamento Tabelas Viagem x Carga
Para ambientes que utilizam diversas filiais e/ou empresas é necessário garantir que as tabelas de viagem DK0 e DK1 possuam a mesma configuração de modo de acesso das tabelas de carga DAK e DAI.
Exemplo:
Se as tabelas de carga estiverem configuradas com os modos de acesso Ac. Filial = 2-Exclusivo, Ac. Unidade = 2-Exclusivo, Ac. Empresa = 2-Exclusivo, logo, as tabelas de viagem deverão possuir configuração idêntica. Esse detalhe é imprescindível para garantir a adequada ligação entre a viagem do TOL e a carga gerada pelo TOTVS OMS.Este ajuste deve ser realizado por meio do configurador do Protheus (SIGACFG).
12. Funcionalidades Não Contempladas
Informações | ||
---|---|---|
| ||
A integração entre o TOTVS OMS e o TOTVS Otimização Logística apresenta as seguintes restrições:
|
¹ É possível que uma viagem no TOTVS Otimização Logística contenha pedidos de diferentes empresas/filiais, para que este processo seja refletido no lado Protheus, é necessário que o Protheus esteja configurado para ser utilizado no modelo de Gestão de Empresas, parametrizando o TOTVS OMS para trabalhar no conceito de Operador Logístico, onde uma empresa/filial permanece como centralizadora das informações.
Caso contrário poderá ocorrer de uma viagem que possuir pedidos de diferentes empresas/filiais seja quebrada em várias no Protheus, gravando cada parte da respectiva viagem, na empresa/filial dos pedidos, ou seja, uma viagem do TOL poderá gerar uma ou mais cargas no TOTVS OMS, não havendo nenhuma interface que permita ao usuário consultar este relacionamento.
13. Informações Complementares
Por uma questão técnica, em função de poderem ser enviadas informações de diversas empresas/filiais do TOTVS OMS para o TOTVS Otimização Logística, porém, este trata tudo como uma única origem de dados, dependendo de configurações poderá gerar viagens com dados de diferentes empresas/filiais.
Sendo assim foi necessário criar no Protheus, de forma fixa, uma tabela que grave este relacionamento das viagens do TOL com as empresas/filiais do TOTVS OMS.
Esta tabela será criada automaticamente na primeira integração de viagem recebida.
A estrutura desta tabela (VIAGEM_OMSxCPL) é apresentada a seguir:
Nome | Tipo | Tamanho | Observações |
---|---|---|---|
EMPRESA | Caractere | Len(FWGrpCompany()) | Padrão 2 |
FILIAL | Caractere | FwFilialSize() | |
CPLMSGID | Numérico | 10 | Identificador da Mensagem do TOTVS Otimização Logística |
VIAGEM | Caractere | TamSx3("DK0_VIAGID")[1] | Identificador da Viagem do TOTVS Otimização Logística |
RECNOVIAG | Numérico | 10 | Recno() da Viagem do Protheus DK0 > (Recno()) |
DATAINT | Caractere | 8 | Data da Integração - Date() |
HORAINT | Caractere | 8 | Hora da Integração - Time() |
Não existe uma interface de consulta para esta tabela.
Ela será utilizada em processos internos para busca da empresa/filial em que a viagem está gravada para as solicitações de reprogramação e cancelamento recebidas do TOTVS Otimização Logística.
14. Quebras de Pedidos
A integração encontra-se preparada para tratar a realização de quebras no pedido no TOTVS Otimização Logística, sendo que as quebras de pedidos no TOL ocorrem quando um pedido precisa ser dividido em mais de uma viagem e cada quebra gera um identificador único dentro do sistema.
O Protheus é informado dessas quebras no momento do recebimento da viagem, mais especificamente no XML de Publicação de Viagem (publishReleasedTrip) na tag orderBreakParts, conforme o exemplo:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<ns2:publishReleasedTrip xmlns:ns2="urn:neolog:cockpit:TripReleaseRequestPublishingService">
<messageId>10082</messageId>
<orderBreakParts>
<orderBreakPart>
<regionSourceId>DEFAULT</regionSourceId>
<orderBreakPartId>81</orderBreakPartId>
<orderSourceId>0101-000002-PED169</orderSourceId>
<orderTypeSourceId>Padrao</orderTypeSourceId>
<orderItemSourceId>0101-000002-PED169-01</orderItemSourceId>
<loadId>1097</loadId>
<shipmentUnitId>1</shipmentUnitId>
<quantShipmUnits>10.0</quantShipmUnits>
<quantProdUnits>10.0</quantProdUnits>
</orderBreakPart>
</orderBreakParts>
<tripReleaseRequests>
<tripReleaseRequest>
<regionSourceId>DEFAULT</regionSourceId>
<identifier>50316</identifier>
<freightValue>0.0</freightValue>
<carrierId>DEF</carrierId>
<vehicleId>Padrao</vehicleId>
<vehicleDescription>Veículo Padrão</vehicleDescription>
<loads>
<load>
<identifier>1097</identifier>
<serviceTypeId>1</serviceTypeId>
<serviceTypeDescription>FULL_TRUCK_LOAD</serviceTypeDescription>
<loadMode>2</loadMode>
<modal>1</modal>
<distance>460.92184</distance>
<freight>0.0</freight>
<stops>
<stop>
<identifier>1234</identifier>
<localitySourceId>FIL-01-01</localitySourceId>
<transportZoneId>Agrupador Padrão.ZT</transportZoneId>
<transportZoneDescription>Agrupador Padrão.ZT</transportZoneDescription>
<sequenceOnLoad>1</sequenceOnLoad>
<subStops>
<subStop>
<identifier>1288</identifier>
<arrivalTime>2019-07-15T00:01:00.000-03:00</arrivalTime>
<startServiceTime>2019-07-15T00:01:00.000-03:00</startServiceTime>
<endServiceTime>2019-07-15T00:16:00.000-03:00</endServiceTime>
<departureTime>2019-07-15T00:16:00.000-03:00</departureTime>
<loadedShipmentUnits>
<shipmentUnit>
<identifier>1494</identifier>
<shipmentUnitCategoryId>1</shipmentUnitCategoryId>
<shipmentUnitDescription>Fardo</shipmentUnitDescription>
<shipmentUnitQty>10.0</shipmentUnitQty>
<weight>10.0</weight>
<volume>0.3025</volume>
<length>0.55</length>
<width>0.25</width>
<height>0.22</height>
<palletHeightTotal>0.0</palletHeightTotal>
<deliveryUnitList>
<deliveryUnit>
<identifier>1494</identifier>
<orderSourceId>0101-000002-PED169</orderSourceId>
<orderTypeSourceId>Padrao</orderTypeSourceId>
<orderItemSourceId>0101-000002-PED169-01</orderItemSourceId>
<productSourceId>OMS001-0101</productSourceId>
<quantity>10.0</quantity>
<price>100.0</price>
<deliveryDate>2019-07-15T00:16:00.000-03:00</deliveryDate>
<integrationSource>DEFAULT</integrationSource>
</deliveryUnit>
</deliveryUnitList>
</shipmentUnit>
</loadedShipmentUnits>
</subStop>
</subStops>
</stop>
<stop>
<identifier>1235</identifier>
<localitySourceId>CLI-000001-01-01</localitySourceId>
<transportZoneId>Agrupador Padrão.ZT</transportZoneId>
<transportZoneDescription>Agrupador Padrão.ZT</transportZoneDescription>
<sequenceOnLoad>2</sequenceOnLoad>
<subStops>
<subStop>
<identifier>1289</identifier>
<arrivalTime>2019-07-15T00:16:00.000-03:00</arrivalTime>
<startServiceTime>2019-07-15T00:16:00.000-03:00</startServiceTime>
<endServiceTime>2019-07-15T00:31:00.000-03:00</endServiceTime>
<departureTime>2019-07-15T00:31:00.000-03:00</departureTime>
<unloadedShipmentUnits>
<shipmentUnit>
<identifier>1494</identifier>
<shipmentUnitCategoryId>1</shipmentUnitCategoryId>
<shipmentUnitDescription>Fardo</shipmentUnitDescription>
<shipmentUnitQty>10.0</shipmentUnitQty>
<weight>10.0</weight>
<volume>0.3025</volume>
<length>0.55</length>
<width>0.25</width>
<height>0.22</height>
<palletHeightTotal>0.0</palletHeightTotal>
<deliveryUnitList>
<deliveryUnit>
<identifier>1494</identifier>
<orderSourceId>0101-000002-PED169</orderSourceId>
<orderTypeSourceId>Padrao</orderTypeSourceId>
<orderItemSourceId>0101-000002-PED169-01</orderItemSourceId>
<productSourceId>OMS001-0101</productSourceId>
<quantity>10.0</quantity>
<price>100.0</price>
<deliveryDate>2019-07-15T00:16:00.000-03:00</deliveryDate>
<integrationSource>DEFAULT</integrationSource>
</deliveryUnit>
</deliveryUnitList>
</shipmentUnit>
</unloadedShipmentUnits>
</subStop>
</subStops>
</stop>
</stops>
</load>
</loads>
</tripReleaseRequest>
</tripReleaseRequests>
</ns2:publishReleasedTrip>
</soap:Body>
</soap:Envelope> |
O TOTVS Otimização Logística aguarda a aprovação destas quebras, por conta disso, ao enviar a mensagem de Desbloqueio de Viagem (doUnblockReleasedTrip), o TOTVS OMS envia a tag orderBreakResponses.
Observe que neste momento o identificador do pedido também é alterado para concatenar o ID da quebra, desta forma, o identificador que antes era 0101-000002-PED169 se torna 0101-000002-PED169-81. No Protheus, o ID da quebra é armazenado na tabela de Sequência de Integração no campo DK3_QUEBID e na tabela de Itens da Viagem, no campo DK1_QUEBID.
A divisão do Pedido de Venda (SC9), para refletir a quebra ocorrida no TOL, será realizada no momento da montagem da carga.
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<unb:doUnblockReleasedTrip xmlns:unb="http://www.neolog.com.br/cpl/acquisition/unblockRelTrip/" xmlns:erp="http://www.neolog.com.br/cpl/acquisition/eRPMessageResponse/" xmlns:ord="http://www.neolog.com.br/cpl/acquisition/orderBreakRemovalRequest/" xmlns:ord1="http://www.neolog.com.br/cpl/acquisition/orderBreakId/" xmlns:ord2="http://www.neolog.com.br/cpl/acquisition/orderBreakResponse/" xmlns:trip="http://www.neolog.com.br/cpl/acquisition/tripReleaseResponse/" xmlns:trip1="http://www.neolog.com.br/cpl/acquisition/tripLoadsSourceId/">
<unb:unblockReleasedTrips>
<unb:unblockReleasedTrips>
<unb:unblockReleasedTrip>
<unb:identifier>10082</unb:identifier>
<unb:regionSourceId>DEFAULT</unb:regionSourceId>
<unb:orderBreakResponses>
<ord2:orderBreakResponses>
<ord2:orderBreakResponse>
<ord2:breakId>81</ord2:breakId>
<ord2:orderId>0101-000002-PED169-81</ord2:orderId>
<ord2:orderItemId>0101-000002-PED169-81-01</ord2:orderItemId>
<ord2:regionSourceId>DEFAULT</ord2:regionSourceId>
<ord2:status>1</ord2:status>
</ord2:orderBreakResponse>
</ord2:orderBreakResponses>
</unb:orderBreakResponses>
<unb:tripReleaseResponses>
<trip:tripReleaseResponseList>
<trip:tripReleaseResponses>
<trip:tripReleaseResponse>
<trip:itemId>0101-000002-PED169-01 </trip:itemId>
<trip:orderSourceId>0101-000002-PED169 </trip:orderSourceId>
<trip:regionSourceId>DEFAULT</trip:regionSourceId>
<trip:status>1</trip:status>
<trip:tripCode>50316</trip:tripCode>
</trip:tripReleaseResponse>
</trip:tripReleaseResponses>
</trip:tripReleaseResponseList>
</unb:tripReleaseResponses>
</unb:unblockReleasedTrip>
</unb:unblockReleasedTrips>
</unb:unblockReleasedTrips>
</unb:doUnblockReleasedTrip>
</soapenv:Body>
</soapenv:Envelope> |
Informações | ||
---|---|---|
| ||
|
16. Teste de Conexão Fora do Protheus
Para verificar se o problema de conexão está no Protheus ou no TOTVS Otimização Logística, é possível realizar uma requisição para o servidor do TOL por uma ferramenta externa, exemplo: SoapUI, Postman, entre outras.
Para tanto, é possível utilizar a Endereço WebService de Autenticação, informado no parâmetro MV_CPLUAUT, junto com os usuário e senha de acesso,
Exemplo
- Tipo de requisição: POST
- URL: URL Informada no parâmetro MV_CPLUAUT
- Body da requisição:
Bloco de código | ||||
---|---|---|---|---|
| ||||
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:aut="http://www.neolog.com.br/cpl/gateway/authentication/">
<soapenv:Header/>
<soapenv:Body>
<aut:credentials>
<username>[email protected]</username>
<password>ABC123</password>
</aut:credentials>
</soapenv:Body>
</soapenv:Envelope> |
O TOTVS Otimização Logística retornará com a informação do token de acesso.
Exemplo
Bloco de código | ||||
---|---|---|---|---|
| ||||
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ns3:authenticationToken xmlns:ns3="http://www.neolog.com.br/cpl/gateway/authentication/">
<successful>true</successful>
<token>f28b0bc763d1481aaa7f714c43660196</token>
</ns3:authenticationToken>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> |
17. Validação de XMLS
Para impedir que ocorram inconsistência no Protheus por XMLS mal formatados, foi desenvolvida a funcionalidade de validar XMLS, baseadas em XSD.
Ao consumir o WebService do Protheus com as mensagens de Liberação de Viagem (publishReleasedTripService), Reprogramação de Viagem (publishReprogrammingService) e Cancelamento de Viagem (publishCancelService), os XMLS passarão por uma pré-validação de estrutura.
17.1. Estrutura Para Pré-validação
Inclua a pasta xsd dentro da system, com os seguintes arquivos:
17.1. Falhas de Estrutura
As falhas ocorridas durante o processo serão retornadas para o XML de Resposta e/ou Log Appserver:
XXXX-XX-XXT09:39:25.122000-03:00 10084|OMSXWS > OMSValXSD > Verificando as configurações de validação de XML baseada em Schema XSD.
XXXX-XX-XXT09:39:25.123000-03:00 10084|OMSXWS > OMSValXSD > Validação do XML de entrada através de XSD não executada por não existir o diretório \system\xsd com os xsds no servidor.
XXXX-XX-XXT09:39:25.123000-03:00 10084|OMSXWS > OMSValXSD > Análise das configurações de validação de baseada em Schema XSD concluída.
XXXX-XX-XXT09:39:43.890000-03:00 10084|OMSXWS > OMSXConnect > Conteúdo de cErro: Opening and ending tag mismatch: ns2:publishReprogrammingService line 1 and tagParaErro:
Opening and ending tag mismatch: soap:Body line 1 and ns2:publishReprogrammingService
Opening and ending tag mismatch: soap:Envelope line 1 and soap:Body
Extra content at the end of the document
17.2. Falha na Liberação da Viagem
Caso ocorra falha na liberação da viagem, será retornado "N" para a Neolog-TOL e a inconsistência de estrutura estará no log do Protheus:
17.3. Falha de Reprogramação ou Cancelamento
Se forem falhas de reprogramação ou cancelamento será retornada a inconsistência no XML de resposta e também para o log:
17.4. Se Não Estiver Habilitado
Estas mensagens serão exibidas no log e processo de validação será descartado:
- XXXX-XX-XXT10:42:29.347000-03:00 10292|OMSXWS > OMSValXSD > Verificando as configurações de validação de XML baseada em Schema XSD.
- XXXX-XX-XXT10:42:29.347000-03:00 10292|OMSXWS > OMSValXSD > Validação do XML de entrada através de XSD não executada por não existir o diretório \system\xsd com os XSDS no servidor.
- XXXX-XX-XXT10:42:29.347000-03:00 10292|OMSXWS > OMSValXSD > Análise das configurações de validação de baseada em Schema XSD concluída.
18. Geração de Logs
18.1. Função Para Gerar Mensagens Auxiliares Para o Log
Para auxiliar na análise de inconsistências foi desenvolvida uma função para gerar mensagens auxiliares para o log, sendo que ela insere informações como queries e conteúdos de variáveis.
Para habilitar são necessários três parâmetros em todos os ambientes:
Bloco de código | ||||
---|---|---|---|---|
| ||||
LOGCPLOMS=.T.
FWFRAME_TRACELOG=1
LOGTIPOMS=CONSOLE |
- O terceiro parâmetro, LOGTIPOMS, define a forma de saída das mensagens.
- Para separar as mensagens e salvar com o nome de omscpl.log dentro da pasta system, informe ARQUIVO.
- Para salvar no log do Appserver (console.log), não coloque o parâmetro LOGTIPOMS no Appserver.ini ou informe como LOGTIPOMS=CONSOLE
Como fazer (opcional)
Nota | ||
---|---|---|
| ||
Ver item "Procedimento para Utilização" no documento técnico DT_Integracao_OMS_Neolog |
Checklist de suporte da aplicação
Instalação/Configuração
- Pelo programa Parâm Integração (OMSXCPL1), informe e teste a URL do Web Service do Cockpit Logístico.
Checklist de Verificações:
- Configuração dos parâmetros de integração.