Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.                                                             

  

Informações Gerais

 

Especificação

Produto

Protheus

Módulo

SIGATMS

Segmento Executor

 

Projeto1

 

IRM1

 

Requisito1

 

Subtarefa1

 

Chamado2

 

País

( X ) Brasil  (  ) Argentina  (  ) Mexico  (  ) Chile  (  ) Paraguai  (  ) Equador

(  ) USA  (  ) Colombia   (  ) Outro _____________.

Outros

<Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>.

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Integrar as informações de contas a pagar geradas pelo módulo SIGATMS (Transportation Management System) da linha Microsiga Protheus  com o módulo FINANÇAS APB da linha Datasul.

O Protheus usará como ferramenta de Integração o EAI(Enterprise Application Integrator), o EAI por sua vez, terá a responsabilidade de trafegar mensagens de XML entre o Protheus e o Datasul, além de fazer o controle de filas das mensagens a serem integradas.

 

Definição da Regra de Negócio

Para cumprir o objetivo deste requisito será necessário retirar a amarração que o SIGATMS possui com tabelas e rotinas do SIGAFIN. Esta amarração só deverá ser retirada quando o transportador estiver trabalhando com integração com outro ERP que não seja Protheus. Para isto, será criado o parâmetro MV_TMSERP, este parâmetro definirá qual é o sistema que o TMS está integrado, onde: 0=Protheus;1=DATASUL, sendo assim, se houver outro ERP  a ser integrado pelo SIGATMS o mesmo poderá ser cadastrado como "2" e assim sucessivamente.

Quando o parâmetro MV_TMSERP estiver igual á "0" - PROTHEUS, o SIGATMS deverá se comportar como se comporta hoje, ou seja, chamando as rotinas do financeiro (050MANSE2, FINA050 e FINA080), para geração e baixa de títulos respectivamente, além de continuar analisando as tabelas SE2 e SE5.

Porém se o parâmetro MV_TMSERP estiver igual á "1" - DATASUL, o SIGATMS deverá enviar mensagens para o DATASUL, solicitando a criação de títulos e impostos e solicitando o retorno de forma síncrona em alguns casos.

Abaixo Mapa Mental com as rotinas que sofrerão alterações caso o parâmetro MV_TMSERP esteja igual à '1'.

 

                        

Seguem as rotinas que devem ser alteradas para que seja realizada a leitura do parâmetro: MV_TMSERP, e caso o conteúdo do parâmetro seja igual a '1', toda chamada às rotinas: A050ManSe2(), FINA050, FINA080, devem ser alteradas para chamar o EAI do Protheus para que o título/baixa seja realizada no DATASUL.


FonteTipo de OperaçãoAceso Menu
TMSA070 - Movimento Custo de TransporteAlteraçãoAtualizações/Transporte/Movto.custo Transp
TMSA370 - Ocorrência de IndenizaçãoAlteraçãoAtualizações/Seguro/Reg. de Indenizações
TMSA330 - Fechamento de SeguroAlteraçãoAtualizações/Seguro/Fechamento
TMSA250 - Contrato de CarreteiroAlteraçãoAtualizações/Terceiros/Contrato Carret.
TMSA240 - Complemento da ViagemAlteraçãoAtualizações/Viagens
TMSIABP - Integração TMS X ABP DatasulInclusão 
TMSA310 - Fechamento da ViagemAlteraçãoAtualizações/Viagens
TMSA251AlteraçãoAtualizações/Terceiros/Lib.Contratos

 

 

Abaixo exemplo do que deve ser alterado nos fontes citados, deve-se criar apenas um novo fonte (TMSINTABP) que será chamado pelas rotinas acima e pelos retornos enviados pelo APB do Datasul.


Âncora
TMSA70
TMSA70
TMSA070  - Movimentos de Custo de Transporte



Através da rotina de Movimentos de Custo de Transporte (TMSA070), é possível gerarmos um título de NDF no Contas a Pagar, desde o movimento de custo de transporte seja realizado para uma viagem, que possui contrato de carreteiro não baixado.

Se o parâmetro MV_TMSERP estiver configurado igual á "1", os títulos serão gerados no ERP Datasul a partir do envio de uma mensagem ao EAI Protheus para se comunicar com o Datasul e solicitar a geração deste título no ERP Datasul. O título será gerado de forma assíncrona, ou seja, o movimento custo será gerado no SIGATMS e a mensagem de inclusão do título no Datasul será incluída na fila do EAI.

Caso o parâmetro MV_TMSERP, estiver igual à "0", os títulos continuarão sendo gerados no Contas a Pagar do Protheus (SIGAFIN).

Bloco de código
titleExemplo
linenumberstrue
collapsetrue
Local lTmsERPDTS := SuperGetMV("MV_TMSERP",,'0') == '1'


If lTmsERPDTS
         //--Chama Rotina que fará a geração e envio do XML ao EAI (Essa rotina pode trabalhar de forma assíncrona)
                    //Integração via Mensagem Única
                    If cFilMsg == "1" .and. FWHasEAI('TMSIABP',.T.,,.T.)
                            FwIntegDef( 'TMSA070', , , , 'TMSA070' )
                   EndIf
Else 
         A050ManSE2(,DTY->DTY_VIAGEM,cPrefixo,cTipNDF,cParcela,SDG->DG_VALCOB,0,DTY->DTY_CODFOR,DTY->DTY_LOJFOR,;
         cNatuDeb,1,Nil, "SIGATMS", Date(), , Date(), , cFilAnt, {})
EndIf


Além de analisar as chamadas das funções 050ManSE2, deverá ser alterado os trechos onde são analisadas diretamente as tabelas do SIGAFIN. Exemplo: SE2 e SE5.
If !Empty(SDG->DG_FILORI) .And. !Empty(SDG->DG_VIAGEM) .And. DTY->(MsSeek(xFilial("DTY")+SDG->(DG_FILORI+DG_VIAGEM) )) .And.;
         (!lTMSOPdg .Or. lGerComp)
         If lTmsERPDTS
                //--Chama rotina que buscará os títulos no DATASUL ref. ao contrato de carreteiro já gerado. Essa rotina por se tratar de consulta deve trabalhar de forma síncrona.
                aRet := TMSIABP (2,DTY->DTY_VIAGEM, DTY_NUMCTC, SDG->DG_VALCOB, DTY_CODFOR, DTY_LOJFOR)
                 If Empty(aRet)
                            Aviso('Não foi encontrado título algum para o contrato de carreteiro informado')
                 EndIf   
      Else
         cOrigem := 'COM' //-- Complemento
         cParcela := StrZero(1, Len(SE2->E2_PARCELA)) 
         If lGerTit
                  cPrefixo := TMA250GerPrf(cFilAnt) 
                  cParc := StrZero(1, Len(SE2->E2_PARCELA)) 
                  SE2->(dbSetOrder(6))
                  If SE2->( MsSeek( cSeek := xFilial("SE2") + DTY->DTY_CODFOR + DTY->DTY_LOJFOR + cPrefixo + PadR(DTY->DTY_VIAGEM, Len(SE2->E2_NUM)) ) )
                           If SDG->(FieldPos("DG_PARC")) > 0
                                    Do While !SE2->(Eof()) .And. SE2->(E2_FILIAL+E2_FORNECE+E2_LOJA+E2_PREFIXO+E2_NUM) == cSeek
                                             cParc:=Soma1(SE2->E2_PARCELA)
                                             SE2->(dbSkip())
                                    EndDo
                           Else
                                    Aviso( STR0021 , STR0022 , { STR0024 } ) //"Atencao" ### "Foi encontrado na tabela SE2 um registro com a mesma chave primária, portanto não será possível efetuar a gravação." ### "OK" 
                                    Final( STR0023 ) // Execute o update UpdTMS32 
                           EndIf 
                  EndIf 
                  cParcela := cParc
         EndIf
      EndIf
EndIf

 

Âncora
TMSA370
TMSA370
TMSA370 - Registro de Indenizações

Através da rotina de Registro de Indenizações (TMSA370), é gerado um título no contas a pagar do Protheus. (TMSA370).

Porém se o parâmetro MV_TMSERP, estiver igual á "1", os títulos serão gerados no ERP Datasul a partir do envio de uma mensagem ao EAI Protheus para se comunicar com o Datasul e solicitar a geração deste título no ERP Datasul. O título será gerado de forma assíncrona, ou seja, o movimento custo será gerado no SIGATMS e a mensagem de inclusão do título no Datasul será incluída na fila do EAI.

Caso o parâmetro MV_TMSERP, estiver igual à "0", os títulos continuarão sendo gerados no Contas a Pagar do Protheus (SIGAFIN).

Rotina de Integração:

Sempre que o parâmetro MV_TMSERP for igual a  “1” , a rotina TMSA370 ao chamar a function TMSA370Grv fará o desvio e não vai cadastrar o título no contas à pagar pela rotina A050ManSe2(), será chamada a integração TMSI370ABP() que é responsável por enviar a mensagem com o tipo “3-Ocorrência” e subtipo “301-Indenização Seguro” contendo o valor que será ressarcido.

Importante: 

A indenização é registrada no momento do apontamento de ocorrência do tipo 9-Indenização, o qual deve constar no cadastro da tabela de ocorrências(DT2); O Serviço que está no documento de frete deve ter a tabela de seguro configurada pelo cadastro de Serviços X Tarefas (DC5) para que possa obter o valor da indenização pelo seguro, os campos a serem preenchidos são: DC5_TABSEG e DC5_TPTSEG.

 


Âncora
TMSA330
TMSA330
Tmsa330 - Fechamento de Seguro


Ao confirmar o fechamento de seguros no TMS, hoje é gerado um título financeiro considerando as informações das tabelas: DU3(Componentes de Seguro), DU8 (Fechamento de seguro) e DU9(Itens de Fechamento de Seguro).

Porém quando a integração com ERP Datasul estiver ligada, a rotina A050ManSe2, não deverá ser mais chamada e sim a rotina que enviará uma mensagem de geração de título ao EAI Protheus, o EAI por sua vez enviará a mensagem de geração de título ao WebService do EAI Datasul.

Vale ressaltar que deve ser gerado um título para cada componente de seguro de acordo com os componentes definidos na tabela DU3(Componentes de Seguro).

Importante observar que hoje os títulos gerados pelo fechamento do seguro podem ter seus lançamentos contábeis demonstrados no SIGATMS, com o ERP Datasul essa visualização não será mais disponível. Já que a mesma será realizada automaticamente pelo ERP Datasul.

Rotina de Integração:

O desvio para a integração ocorre na função TMSA330Conf() localizado na rotina TMSA330.PRW e será realizado pela rotina de integração TMSI330ABP.prw.

Pela função TMSA330mnt() é chamada a tela de parâmetros e exibida as informações dos documentos. Se o fechamento for confirmado é realizada a chamada da rotina TMSA330Conf() e realizada a integração financeira com o Contas à Pagar gravando o prêmio do seguro,  do contrário é chamada a rotina TMSA330Grv() gerando os registros nas tabelas DU8 e DU9.

Observação:  O parâmetro MV_CDHISAP tem que estar preenchido com o código de histórico de fechamento do prêmio de seguro do TMS.

 

Trecho do código que realiza o desvio para a integração:

       If lTMSERPDTS == .F.

         ...executa integração nativa Financeiro Protheus.

        Else

            If FindFunction("GETROTINTEG") .And. FindFunction("FwHasEAI") .AND. FwHasEAI("TMSA330",,.T.,.T.)

                        //FWIntegDef( cSourceCode, cTypeMessage, cType, cXml, cFunName, lOnlyReturn, cVersion  

                        FwIntegDef("TMSA330",,"TMSA330") 

                   EndIf 

 

                 EndIf

 

Âncora
TMSA250
TMSA250
TMSA250 - Contrato de Carreteiro



Quando o SIGATMS estiver integrado com o ERP Datasul (MV_TMSERP=='1'), durante o processamento de geração do contrato de carreteiro será iniciada a integração entre o SIGATMS e ERP Datasul. O SIGATMS repassará uma mensagem com as informações abaixo de forma síncrona, e o ERP Datasul retornará os valores dos impostos para o SIGATMS. Com as informações dos impostos o contrato de carreteiro terá sua geração confirmada.

  • Tipo do título
  • Número do Título
  • Código do Fornecedor
  • Loja do Fornecedor
  • CNPJ do Fornecedor
  • Loja do Fornecedor
  • Lista com Viagens do Contrato de carreteiro
  • Valor
  • Moeda
  • Data Emissão
  • Filial de Débito
  • Empresa Responsável pela geração
  • Filial Responsável pela geração do contrato.
  • Data de Vencimento (Opcional, se não for enviada gera-se de acordo com regra financeira).

Se o parâmetro MV_GERTIT, estiver habilitado (.T.), ao enviar a mensagem solicitando os valores dos impostos, o SIGATMS identificará através de uma tag da mensagem que os títulos para o contrato de carreteiro e seus impostos devem ser gerados no ERP Datasul.

O Datasul por sua vez, receberá as informações do contrato de carreteiro e definirá através das configurações do fornecedor como serão gerados os títulos (Parcelas, Data de vencimento e Impostos).

Caso o parâmetro MV_GERTIT, não estiver habilitado (.F.), o SIGATMS enviará a mesma mensagem ao ERP Datasul, porém uma das tags da mensagem informará que o título não deve ser gerado no ERP Datasul.

 

Além dos título do contrato de carreteiro e seus impostos, os títulos ref. ao adiantamento e pedágio também poderão ser gerados neste momento no ERP Datasul. 

Para cada um dos títulos deverá ser verificado o contrato do fornecedor e obedecer as regras abaixo:

  1. Título de Adiantamento: 
    O título de adiantamento da viagem que atualmente é gerado na confirmação da viagem, poderá ser gerado no fechamento da viagem, na geração do contrato carreteiro ou ainda na confirmação da viagem, para fornecer esta possibilidade ao transportador, será criado o campo DUJ_TITADI no contrato de fornecedor, este campo terá as seguintes opções de preenchimento (0,1 ou 2.), onde:
    • 0 = Confirmação da viagem;
    • 1 = Fechamento da viagem;
    • 2 = Geração do contrato de carreteiro.
      Se o título de adiantamento estiver configurado para ser gerado na geração do contrato de carreteiro, o SIGATMS ao processar a geração do contrato de carreteiro deverá verificar se o título não foi gerado na viagem. E se o título de adiantamento não tiver sido gerado, o SIGATMS enviará a mensagem de criação de título para o o ERP Datasul através do EAI.

      Observação: Recomendável que está mensagem seja assíncrona já que as informações do adiantamento já são conhecidas pelo SIGATMS, para geração do contrato de carreteiro.

  2. Título de Pedágio:
    O título de pedágio já pode ser gerado em momento diferentes, no fechamento da viagem(DUJ_TITPDG=='1') ou na geração do contrato de carreteiro (DUJ_TITPDG=='2'). 
    Se o título estiver configurado para ser gerado no contrato de carreteiro, ao gerar o contrato de carreteiro, deve-se verificar se o título não foi gerado na viagem. Caso não foi gerado no fechamento da viagem, o SIGATMS enviará a mensagem de criação de título de pedágio para o ERP Datasul, através do EAI.

    Observação: Recomendável que está mensagem seja assíncrona já que as informações do adiantamento já são conhecidas pelo SIGATMS, para geração do contrato de carreteiro.


Importante:

1.             Existe um parâmetro na função Tmsa250GerDTY() que determina se o valor de pedágio deve ser deduzido da base de impostos, implica no campo DTY_BASEIMP. O conteúdo do parâmetro é de acordo com o cadastro do fornecedor campo Deduz Pedag.(DVG_DEDPDG).
Como essa informação é cadastrada no contrato do fornecedor, não será necessário ficar no financeiro Datasul, o SIGATMS ao passar o valor do contrato ao Financeiro Datasul, já deverá resolver se o valor do pedágio será abatido ou não.

Para atender esta demanda o fonte TMSA250 deverá ser reestruturado com o objetivo de facilitar sua leitura, reutilizar as rotinas que serão utilizadas na geração do Financeiro do Protheus e no Financeiro do Datasul, além de separar as chamadas das rotinas que gerarão o contas a pagar no Financeiro do Protheus e no Financeiro do Datasul.

 

Bloco de código
titleExemplo
linenumberstrue
collapsetrue
If cTmsErp == '0'
	
	//-- Verifica o Prefixo do Titulo
	cPrefixo := TMA250GerPrf(cFilAnt)
							
	//--Chama rotina de exclusão de títulos do ERP Protheus
	lRet := A250FinPrt(cPrefixo,cCodForn,cLojForn,cAliasDTY,cTipUso,cContrat,lRepom,@aMsgErr)	
							
	ElseIf cTmsERP == '1'
		//Chama rotina de exclusão de títulos do ERP Datasul	
		lRet := A250FinDTS(cPrefixo,cCodForn,cLojForn,cAliasDTY,cTipUso,cContrat,lRepom,@aMsgErr)
	EndIf
						

Neste trabalho de reestruturação do TMSA250, deverá ser retirado todo o tratamento que o fonte possuí referente a geração de contrato de carreteiro do OMS. Já que esta funcionalidade já foi retirada do Menu do módulo OMS, e a TOTVS possui o módulo SIGAGFE para embarcadores que contratam transportadoras para prestação do serviço de transporte.


Rotina de Integração:

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 houver o retorno positivo da integração será efetivado a inclusão do DTY e atualizado com os impostos que o Datasul calculou.

 

Âncora
TMSA250SLD
TMSA250SLD
TMSA250SLD - Pagamento de Saldo

Se o SIGATMS estiver integrado com o ERP Datasul (MV_TMSERP == '1'), a rotina de pagamento de saldo do carreteiro não poderá mais ser acessada pelo transportador. 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.

 

Âncora
TMSA251
TMSA251
 TMSA251 - Liberação do Contrato de Carreteiro

Se o SIGATMS estiver integrado com o ERP Datasul (MV_TMSERP =='1') e a rotina de Liberação do Contratos estiver habilitada (MV_LIBCTC==.T.). O SIGATMS ao solicitar a geração de títulos no ERP Datasul, enviará um parâmetro na mensagem de inclusão de contrato, indicando que este título está bloqueado para pagamento. Com esta informação o ERP Datasul não permitirá que o pagamento do título seja realizado. O Pagamento só poderá ser realizado quando este título for desbloqueado.

Para liberar o título no ERP Datasul, o SIGATMS enviará uma mensagem alterando o status do título. Está mensagem será enviada a partir da liberação do contrato de carreteiro (TMSA251).


 

Âncora
TMSA240
TMSA240
TMSA240 - Complemento de Viagem

Atualmente o adiantamento da viagem é realizado na inclusão da viagem, porém deverá ser permitido que o transportador gera o título de adiantamento a partir do fechamento da viagem. Esta configuração será realizada na contrato do fornecedor, através 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 MV_TMSERP igual a '0'  deverá ser respeitada a função A050ManSE2(). Caso o ERP for Datasul ou seja MV_TMSERP igual '1', deverá ser chamada a função de integração com o ERP Datasul a partir do EAI.


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 com o valor igual '0', a rotina de integração será 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 é 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
TMSA310
TMSA310
TMSA310 - Fechamento de Viagem

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 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 TMSA310, função TMSA310GRV(), neste ponto é verificado se o parâmetro MV_TMSERP é igual a “1”, se sim é chamada a rotina FwIntegDef que aponta para a rotina de integração TMSI310ABP(), as informações do título é 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.

Observações:

O Contrato de Carreteiro deve estar incluído para que seja enviado a inclusão de título de adiantamento.

 

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 integrado com o Protheus (MV_TMSERP) == '0'.

 

Rotinas/FontesDescrição
TMSA920Geração de AWB.
MATA120Pedido de Compras
TMSA250ProcContrato de Prêmio
Tmsa250SldPagamento de Saldo deo Contrato de Carreteiro
TMSOPdgPCGera Pedido de Compras para integração com Operadora de Frotas
TMSA250SC7Gera Pedido de Compra

 

Modelo da Mensagem Única:

Estrutura da Mensagem:

Constará na estrutura da mensagem os seguintes campos:

Para Envio:

Campos da Mensagem

Campo

Descrição

Empresa

A empresa emissora do documento.

Estabelecimento/Filial

Filial emissora do documento.

Tipo de Documento

Define qual o tipo de documento é enviado ao financeiro para a inclusão do titulo. viagem, contrato carreteiro, ocorrência, seguro ou pedágio;

Subtipo Documento

Informa um tipo mais especifico para a inclusão do título no financeiro da marca que receberá a mensagem. Utilizado para envio de mensagem complementares.

Número do Documento

Pode ser o número da viagem ou do documento de frete gerado ao qual referenciará ao titulo financeiro.

Cnpj Fornecedor

Deve ser informado como uma sub tag da tag GovernmentalInformation.

Inscrição Estadual Fornecedor

Deve ser informado como uma sub tag da tag GovernmentalInformation.

Preview

Informa se foi solicitada uma simulação da geração dos títulos apenas para validação; não efetiva o título na marca receptora da mensagem. Recebe valor 1=SIM e 2=NÃO.

Moeda

Informar a moeda corrente que será utilizado na geração do titulo.

Valor documento

Valor Total do documento, deve constar na tag DocumentsValues e dentro dela a subtag <value>

Pedágio

Valor total do pedágio que será consumido, deve constar na tag DocumentsValues e dentro dela a subtag <TollValue>

Adiantamento de Frete

Valor do adiantamento de frete, deve constar na tag DocumentsValues e dentro dela a subtag <AdvancesValue>

Filial de Débito

Qual a filial que arca com o pagamento do frete terceiro.

Data emissão

Relacionado ao documento de acordo com o campo Tipo do Documento;

Data Transação

Data em que a mensagem foi processada e enviada a outra marca.

Lista de Conhecimentos

Informar quando o tipo de documento for igual a 1-viagem, todos os documentos de frete carregados na viagem.

Lista de Viagens

Informe quando o tipo de documento for igual a ‘contrato’; tem que constar todas as viagens vinculadas a este contrato de frete carreteiro.

Histórico

Informe qualquer informação relevante que fortaleça a característica do título.

 

Para Retorno:

Campos da Mensagem

Campo

Descrição

Chave do Título cadastrado

Uma chave de referência para a localização do título, deve ser composto por: filial emissora,cnpj fornecedor, espécie, série, número do título e parcela.

Valor Bruto

Valor total do título cadastrado.

Valor liquido

Valor já descontado os impostos e compensação (no caso do preview)

Data de Vencimento

Última data para pagamento.

Impostos Calculados(Tributação)

Informar listagem contendo todos os tributos calculado para o título. Será retornado em forma de uma lista.

 

Dados Complementares:

Foi observado a necessidade de Incluir o tipo de Seguro se será 

402 = RCF-DC (Responsabilidade Civil Facultativa do Transportador Rodoviário – Desaparecimento de carga) : quando ocorre algum tipo de roubo da carga ou desaparecimento;

403 = RCTR-C (Responsabilidade Civil do Transportador Rodoviário de Carga) relacionado a cobertura de acidentes decorrentes de colisão, capotagem, tombamento;

Poderá ser incluído como um subtipo do documento.

 


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 - Modelo do XML

 

<?xml version="1.0" encoding="UTF8"?>

<TOTVSMessage>

        <MessageInformation version="1.000">

                <UUID>11b11fe6273e7c8ac3f95771de221857</UUID>

                <Type>BusinessMessage</Type>

                <Transaction>TRANSPORTDOCUMENTS</Transaction>

                <StandardVersion>1.000</StandardVersion>

                <SourceApplication>TP12B</SourceApplication>

                <CompanyId>T1</CompanyId>

                <BranchId>M SP 01</BranchId>

                <Product version="12" name="PROTHEUS" />

                <GeneratedOn>20160923T20:54:28</GeneratedOn>

                <DeliveryType>Async</DeliveryType>

        </MessageInformation>

        <BusinessMessage>

                <BusinessEvent>

                        <Entity>CUSTOMERSHIPPINGADDRESS</Entity>

                        <Event>upsert</Event>

                        <Identification>

                               <key name="InternalId">T1|M SP 01 19272685000153</key>

                        </Identification>

                </BusinessEvent>

                <BusinessContent>

                        <CompanyId>T1</CompanyId>

                        <BranchId>M SP 01 </BranchId>

                        <CompanyInternalId>T1|M SP 01 19272685000153</CompanyInternalId>

                        <DocumentId>000000001</DocumentId>

                        <DocumentType>SEGURO</DocumentType>

                        <DocumentSubType>RC</DocumentSubType>

                        <VendorCode>000003</VendorCode>

                        <VendorrUnit>01</VendorUnit>

                        <VendorDescription>SEGURADORA DO TMS (PJ) </VendorDescription>

                        <GovernmentalInformation>

                               <Id name="CNPJ" issueOn="2016-09-23T17:54:28" expiresOn="" scope="">19272685000153</Id>

                               <Id name="INSCRICAO_ESTADUAL" issueOn="20160923T17:54:28"

                                       expiresOn="" scope="" />

                        </GovernmentalInformation>

                        <Currency>

                               <Code>01</Code>

                               <Description>REAL</Description>

                               <Simbol>$</Simbol>

                        </Currency>

                        <Preview>2</Preview>

                        <IssueDate>23/09/2016</IssueDate>

                        <TransactionDate>23/09/2016</TransactionDate>

                        <DebitBranchCode>M SP 01 </DebitBranchCode>

                        <DocumentValues>

                               <TransportDocumentValue>0.00</TransportDocumentValue >

                               <TollValue>0.00</TollValue>

                               <Adiantamento>0.00</Adiantamento>

                        </DocumentValues>

                        <DocumentHistory/>

                        <ListOfDocumentsPerTravel />

                        <ListOfTravelsPerContract />

                </BusinessContent>

        </BusinessMessage>

</TOTVSMessage>

Tabela 5.1.2

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

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

Como será utilizada 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:

Código Referente ao Tipo de documento

Código

Referência

1

Viagem

2

Contrato Carreteiro

3

Ocorrência

4

Seguro

5

Custos de Transporte

Tabela 5.1

Subcódigo Referente ao Tipo de documento

Código

Referência

101

Viagem – Adiantamento/PDG

201

Contrato Carreteiro – Frete Pagar

202

Contrato Carreteiro – NDF

203

Contrato Carreteiro – NCF

301

Ocorrência – Indenização de Seguro, Sinistros/Roubos da carga/veículos

401

Seguro – Premiação

402

RCF-DC – Cobertura de Seguro contra Roubo ou Desaparecimento da carga.

403

RCTR-C – Cobertura de Seguro contra avarias, tombamentos do equipamento utilizado no transporte.

501

Custos de Transporte – Reservar

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 financeiro/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 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.

 

Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.