Se o SIGATMS estiver integrado com o ERP Datasul (MV_TMSERP == '1'), a rotina de pagamento Pagamento de saldo Saldo do carreteiro Carreteiro não poderá mais ser acessada pelo transportador. Já , já que o pagamento (baixa) dos títulos ocorrerão apenas no ERP Datasul. O ERP Datasul, por sua vez, terá a responsabilidade de enviar uma mensagem de baixa dos títulos para o SIGATMS, através do EAI. 

A rotina TMSI250ABP é responsável por montar e enviar a mensagem de integração DocumentTransport com o tipo 2-Contrato de Carreteiro e subtipo = 201-Contrato de Carreteiro - Frete Pagar. Essa será disparada no ato da inclusão do DTY e será enviado de forma síncrona, quando Síncrona. Quando houver o retorno positivo da integração, será efetivado efetivada a inclusão do DTY e atualizado com os impostos que o Datasul calculou.

Caso o SIGATMS estiver esteja integrado com o ERP Datasul (MV_TMSERP == '1') e a rotina de Liberação de Contratos estiver habilitada (MV_LIBCTC == .T.). Ao , ao gerar o contrato Contrato de carreteiro Carreteiro (TMSA250), não será gerada mensagem para o EAI, solicitando a geração de título.

Essa mensagem só será enviada na Liberação do Contrato de Carreteiro (TMSA251), o Datasul por sua vez retornará os impostos gerados para o contrato de carreteiro e os valores de cada imposto será atualizado no DTY.

Atualmente o adiantamento da viagem é realizado na inclusão da viagem, porém deverá ser permitido que o transportador gera gere o título de adiantamento, a partir do fechamento da viagem. Esta configuração será realizada na contrato do fornecedor, através por meio da criação do novo campo DUJ_TITADI (1=Viagem; 2=Fechamento Viagem).

Se o contrato do fornecedor estiver configurado para gerar adiantamento na Viagem (DUJ_TITADI == '1'), ao gerar uma viagem deverá ser verificado qual é o ERP que o SIGATMS está integrado.

Se o ERP for Protheus ou seja, se o parâmetro MV_TMSERP igual estiver configurado com a opção '0'  deverá , deverá ser respeitada a função A050ManSE2(). Caso o ERP for Datasul ou seja, se o parâmetro MV_TMSERP igual estiver configurado com a opção '1', deverá ser chamada a função de integração com o ERP Datasul a partir do EAI.

Image Modified

Rotina de Integração: 

A rotina utilizada na integração será a TMSI240ABP.PRW, por meio dela será montada a mensagem TransportDocument com tipo 1-VIAGEM e subtipo 101-ADIANTAMENTO, como a rotina A050ManSE2() é responsável por gerar o financeiro à Pagar para quando o parâmetro MV_TMSERP estivar , estiver com o valor igual '0', a rotina de integração será chamada somente chamada quando o parâmetro MV_TMSERP for igual a '1', nesta condição será realizado o desvio para a integração EAI. Está rotina está localizado no fonte TMSA240 .PRW e (Complemento de Viagem) e é disparado pela função A240AtuSDG().**

 ** O envio da mensagem de adiantamento e pedágio será enviado no momento do fechamento da viagem somente se no contrato do Fornecedor estiver configurado com essa regra.

Âncora
TMSA252 TMSA252

Geração do Contrato para Redespachante (TMSA252)

A rotina de Geração do contrato para redespachante, não deverá sofrer alteração, já que a geração do contrato será realizado realizada pela rotina Tmsa250Proc(), consequentemente os títulos a pagar deverão respeitar o parâmetro MV_TMSERP. 

Porém, é preciso garantir que o processo de geração do contrato de redespachante, funcionará na integração com o  ERP ERP Protheus (MV_TMSERP == 0), e na integração com o ERP Datasul (MV_TMSERP == 1).

Além do título de adiantamento, o título de pedágio pode ser configurado para ser gerado no momento do fechamento da viagem, campo (DUJ_TITPDG).

Se o contrato estiver configurado para gerar o título de pedágio no fechamento da viagem, ao efetuarmos a viagem, a partir do TMSA310da rotina Fechamento da Viagem (TMSA310), deverá ser enviada a mensagem ao ERP Datasul solicitando a geração de um título financeiro do tipo pedágio. Porém, a data de vencimento do título deverá ser a mesma data da geração.

O mesmo ocorrerá com o título de adiantamento, caso o mesmo esteja configurado para ser gerado no fechamento da viagem (DUJ_TITADI).

Rotina de Integração:

A rotina de integração TMSI310ABP.prw é responsável por fazer a integração no momento do fechamento da viagem, a integração é enviada com o tipo 1-VIAGEM e subtipo 101-VIAGEM/Adiantamento/Pedágio.

A integração ocorrerá na rotina Fechamento da Viagem (TMSA310), função TMSA310GRV(), neste ponto é verificado se o parâmetro MV_TMSERP é igual a “1”“1”, se sim, é chamada a rotina FwIntegDef que aponta para a rotina de integração TMSI310ABP(), as informações do título é e é enviado pelo objeto oDTClass() uma instância de TransportDocumentClass.prw e que deve ser declarado como Private antes da chamada do FwIntegDef para que a rotina de integração o enxergue.

Provisão de Frete:

Com objetivo de permitir que o transportador tenha um valor de frete previsto já no fechamento da viagem, foi criado o campo DTR_PRVFRE, este campo será alimentado mediante ao fechamento da viagem. 

No fechamento Fechamento da viagem Viagem se o campo DTR_PRVFRE existir será chamada a função que verifica o contrato do fornecedor Tmsa250Forn(), TmsTabPag() e TMSCalFrePag(). Após extrair o valor do frete a pagar, a informação será gravada no campo DTR_PRVFRE e possibilitará que este valor provisório seja enviado para o ERP Datasul, gerando assim um título provisório no módulo de FINANÇAS APB.

Este título será substituído posteriormente, quando for gerado o contrato de carreteiro ou Liberação do Contrato de Carreteiro dependente do parâmetro MV_LIBCTC.

Abaixo representação gráfica:.

Percentual de Adiantamento:

Com o objetivo de calcular adiantamento para o fornecedor com base no valor do frete previsto, foi criado um campo do contrato do fornecedor onde é possível informar o informar a % de adiantamento que será concedido concedida ao fornecedor ao fechar uma viagem, onde este fornecedor esteja inserido.

Ao fechar a viagem serão gravados os campos DTR_PERADI (% de adiantamento), com base no campo DUJ_PERADT e também o valor do adiantamento (DTR_ADIFRE), este valor será calculado da seguinte forma:

DTR_PRVFRE * DTR_PERADI / 100.

Com isso, além de obter o valor do adiantamento, será enviada a mensagem para o ERP Datasul, solicitando a criação de um título de adiantamento (PA), no módulo de Finanças APB, desde que o contrato do fornecedor indique que o título de adiantamento deve ser gerado no fechamento da viagem.

Na integração do SIGATMS x Datasul - Fiscal, foi criada uma rotina que permitirá ao transportador fazer o reenvio de mensagens para o ERP Datasul, assim, quando houver alguma falha na integração do CT-e entre o TMS e o Datasul, o mesmo registro poderá ser reenviado.

Essa mesma rotina será utilizada na Integração entre o SIGATMS x Datasul APB, inicialmente essa rotina contemplará apenas o reenvio de contrato Contrato de carreteiros Carreteiros já gerados (DTY). E foi disponibilizada neste momento para os transportadores que trabalharem com a Integração TMS x Datasul (MV_TMSERP = '1') e Integração com a Operadora de Frete Pedágio REPOM, (MV_ENREPOM $ '3;4').

Já que neste caso, ao gerar o contrato Contrato de carreteiro Carreteiro, o mesmo seria Integrado com a REPOM, posteriormente em caso de sucesso nesta Integração, seria enviada uma mensagem ao ERP Datasul, e havendo uma falha na Integração, o contrato será gerado da mesma forma, já que o mesmo existe na REPOM. Sendo assim, será possível ajustar as falhas na Integração com o Datasul e fazer o reenvio do mesmo contrato.

Rotinas que não serão Integradas neste Projeto

A tabela abaixo, representa as rotinas que não serão integradas com o ERP Datasul neste momento, porém sua utilização deve continuar da mesma maneira se o SIGATMS esteja estiver integrado com o Protheus (MV_TMSERP) == '0'. 

Já que não haverá os contratos de carreteiros gerados no SIGATMS, não gerarão pedidos de compras no ERP DATASUL, o campo Gera Ped. Co (DUJ_GERAPC), não poderá ter seu conteúdo alterado para SIM, quando o parâmetro MV_TMSERP estiver preenchido com ‘1’‘1’. E mesmo que o campo esteja preenchido com a opção 0=”Não Considera””Não Considera”, não será considerado o parâmetro MV_TMSGRPC.

O SIGATMS permite que seja utilizada sejam utilizadas utilizadas as rotinas FINA550 e FINA560, Manutenção de Caixinha(FINA550) e Movto.Caixinha (FINA560), respectivamente.

Como se tratam de rotinas financeiras, as rotinas Manutenção Caixinha (FINA550) e Movto.Caixinha (FINA560), não poderão ser utilizadas no SIGATMS quando o mesmo estiver integrado com o ERP Datasul (MV_TMSERP==’1’).

As rotinas de Geração e Impressão de Cheques (TMSA250GCH e TMSA144ICH), respectivamente. Não serão utilizadas quando o SIGATMS estiver integrado com o ERP Datasul (MV_TMSERP == '1'). 

Para isso, o MenuDef do TMSA250, não concederá acesso a estas rotinas quando o MV_TMSERP estiver igual à '1'.

Modelo da Mensagem Única:

Estrutura da Mensagem:

Constará na estrutura da mensagem os seguintes campos:

Para Envio:

Para Retorno:

A seguir o modelo que será utilizado para envio da mensagem de contas à pagar para a marca receptora.

A tabela 5.1.2 a seguir ilustra como o XML será montado e enviado.

Tabela 5.1.2

Tipos e Subtipos da mensagem de Documentos de Transportes (Contas à Pagar)

A mensagem será trafegada no sentido de ‘envio’ envio e ‘recebimento recebimento, por ela teremos uma visão de quais documentos o modulo financeiro módulo Financeiro da marca receptora deverá tratar e gerar os títulos e suas baixas.

Como será utilizada utilizado um único modelo de mensagem com uma única estrutura em formato (.XML) para a geração e controle dos títulos financeiros, esta poderá assumir alguns tipos conforme tabela demonstrada a seguir, tabela 5.1 e tabela 5.1.1:

Tabela 5.1

Tabela 5.1.1

Os códigos contidos nestas tabelas, serão utilizados nas tags <DocumentType> que receberá valores de acordo com a Tabela 5.1 e <DocumentSubType> que receberá valores de acordo com a Tabela 5.1.1.

Exemplo:

Supondo que seja enviado para o financeiroFinanceiro/Contas à Pagar uma mensagem do Tipo Viagem, a tag <DocumentType> estará preenchida com o valor um ‘1’. A mensagem será trafegada até a outra marca que se encarregará de tratar a mensagem e gerar o título referente a essa viagem. Supondo que por algum motivo foi solicitado o adiantamento para essa viagem. Será enviado , será enviada uma nova mensagem para essa mesma viagem, onde constará as tags preenchidas da seguinte forma:

<DocumentType>1</DocumentType> [refere-se a uma mensagem do tipo 1-Viagem] e <DocumentSubType>101</DocumentSubType> [refere-se ao adiantamento da viagem.]

Neste exemplo, foi solicitado para gerar um título de adiantamento para complementar o título de viagem, o qual será utilizado para pagar o frete do motorista. 

Classe de tratamento da Mensagem (TransportDocumentClass.prw)

Para melhor atender a integração foi desenvolvido desenvolvida uma classe auxiliar, responsável por tratar o envio e recebimento da mensagem única. Ela deve ser declarada como private antes da chamada da rotina FwIntegdef() ou do commit do modelo de dados(), o seu objetivo é montar uma pré-carga dos dados e descarregar do lado da rotina de integração. 

A seguir uma breve descrição das propriedades e métodos que compõe a classe. 

Cadastro de Rotas para o Adapter EAI:

Este cadastro se faz necessário para quando houver a necessidade de realizar a integração com mais de uma marca. A rota aponta para um endpoint, no caso uma URL que aponta para o servidor de webservice da marca receptora da mensagem que será trafegada.

Para realizar o cadastro acesse pelo configurador Configurador (SIGACFG) o menu: Ambiente/Schedule/Rotas Eai. 

Preencha o campo conforme tabela 5.5.1

Tabela 5.5.1

1.1  Preparo da Rotina de Integração

Para que a integração ocorra é necessário preparar a(s) rotina(s) de integração e para isso é necessário realizar algumas etapas apresentadas a seguir:

Etapas necessárias para a integração:1-     

1. Verifique se o Protheus possui a última lib aplicada ou em uma versão igual ou superior a ??????????;

1. acesse o canal de suport/downloads para baixar a ultima lib. 

1. Cadastrar as rotas de acesso as marcas que serão integradas pelo configurador

1. .

1. Cadastrar os Adapters E.A.I. para as rotinas que fazem integração com algum processo da marca receptora pelo configurador

1. .

1. Testar o envio e recebimento da integração, recomenda-se testar a integração utilizando um serviço Protheus para recebimento e outro para envio com base de dados diferentes

1. .

Cadastro do Adapter E.A.I.

Para que as mensagens trafeguem entre as marcas que fazem integração uma com a outra, é necessário cadastrar o Adapter EAI responsável por requisitar a abertura do canal de comunicação entre os produtos configurados pelo cadastro de Rotas EAI. Acesse pelo Configurador (SIGACFG) o cadastro pelo menu: Ambiente/Schedule/Adapter E.a.i.

Preencha os principais campos conforme descrição da tabela 5.5.2

Ainda no cadastro do Adapter na parte inferior da tela há um grid de onde poderá ser informado a(s) rota(s) de comunicação com a(s) marca(s).

Preencha os principais campos conforme descrição da tabela 5.5.33 

Tabela 5.5.3