Histórico da Página
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 com o módulo FINANÇAS APB da linha Datasul.
O Protheus usará como ferramenta de Integração o EAI (Enterprise Application Integrator).
O , 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 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 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 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, FINA050 e FINA080, devem ser alteradas para chamar o EAI do Protheus para que o título/baixa seja realizada no DATASUL.
Fonte | Tipo de Operação | Aceso Menu | TMSA070 - Movimento Custo de Transporte||
---|---|---|---|---|
Alteração | Atualizações/Transporte/Movto.custo Transp | TMSA370 - Ocorrência de Indenização | Alteração | Atualizações / Seguro / Reg.de Indenizações |
TMSA330 - Fechamento de Seguro | Alteração | Atualizações / Seguro / Fechamento | ||
TMSA250 - Contrato de Carreteiro | Alteração | Atualizações / Terceiros / Contrato Carret. | ||
TMSA240 - Complemento da Viagem | Alteração | Atualizações / Viagens | ||
TMSIABP - Integração TMS X ABP Datasul | Inclusão |
Genérica | ||
TMSA310 - Fechamento da Viagem | Alteração | Atualizações / Viagens |
TMSA251 - Liberação para Pagamento do Contrato de Carreteiro | Alteração | Atualizações / Terceiros / Lib.Contratos |
TMSAE77 - Controle de envio EAI | Alteração | Atualizações / Recebimento / Reenvio Dts |
TMSAE78 - Reenvio de Mensagens | Alteração | Genérica |
Abaixo exemplo do que deve ser alterado nos fontes 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 | ||||
---|---|---|---|---|
|
(TMSA070)
Quando o SIGATMS estiver integrado com o ERP Datasul (MV_TMSERP = '1'), não será possível incluir movimento de custo de transporte para viagens que já possuem o contrato de carreteiro gerado.
Registro de Indenizações (TMSA370) Âncora TMSA370 TMSA370
Por intermédio da rotina 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 de 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, esteja 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”, na rotina Registro de Indenizações (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.
Informações | ||
---|---|---|
| ||
A indenização é registrada no momento do apontamento de ocorrência do tipo 9-Indenização, a 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
Fechamento de Seguro (TMSA330)
TMSA330 | |
TMSA330 |
Ao confirmar o fechamento de seguros no TMS, hoje é gerado um título no 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() localizada na rotina Fechamento de Seguro (TMSA330) e será realizada pela rotina de Integração TMS X ABP Datasul (TMSI330ABP).
Pela função TMSA330mnt() é chamada a tela de parâmetros e apresentada 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.
Informações | ||
---|---|---|
| ||
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. |
Bloco de código | ||||
---|---|---|---|---|
| ||||
Trecho do código que realiza o desvio para a integração:
If lTMSERPDTS == .F.
...executa integração nativa Financeiro Protheus.
Else
|
Índice | ||||
---|---|---|---|---|
|
Bloco de código |
---|
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 :=If StrZero(1, Len(SE2->E2_PARCELA)) FindFunction("GETROTINTEG") .And. FindFunction("FwHasEAI") .AND. FwHasEAI("TMSA330",,.T.,.T.) SE2->(dbSetOrder(6)) FwIntegDef("TMSA330",,"TMSA330") EndIf 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 |
Movimento Custo Transporte
EndIf |
Contrato de Carreteiro (TMSA250) Âncora TMSA250 TMSA250
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 a regra financeira)
- Valor do INSS Retido
Se o parâmetro MV_GERTIT, estiver habilitado (.T.), ao enviar a mensagem solicitando os valores dos impostos, o SIGATMS identificará por meio 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á por meios 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 esteja 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ítulos do contrato de carreteiro e seus impostos, os títulos referente 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:
- 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 ERP Datasul por meio do EAI.Informações title Observação: Recomendável que está mensagem seja Síncrona para garantirmos que os títulos existirão no SIGATMS e também no ERP Datasul. E em caso de falha na integração o título não será gerado no SIGATMS.
Título de Pedágio:
O título de pedágio já pode ser gerado em momentos 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 tenha sido gerado no Fechamento da Viagem, o SIGATMS enviará a mensagem de criação de título de pedágio para o ERP Datasul, por meio do EAI.Informações title Observação: Recomendável que está mensagem seja Síncrona para garantirmos que os títulos existirão no SIGATMS e também no ERP Datasul. E em caso de falha na integração o título não será gerado no SIGATMS.
Informações | ||
---|---|---|
| ||
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 a rotina Contrato de Carreteiro (TMSA250), deverá ser reestruturada 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 | ||||||
---|---|---|---|---|---|---|
| ||||||
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.
Além disto o TMSA250 será convertido para MVC, fazendo com que as rotinas que estavam vinculadas a opção Mais Detalhes, fiquem disponibilizadas em folders, facilitando a visualização.
Contrato de Carreteiro por Período Âncora Período Período
Por intermédio da opção Gerar Contrato de Carreteiro por Período, é possível gerarmos “n” registros na tabela DTY (Contrato de Carreteiro) com o mesmo número de contrato para o mesmo fornecedor. Cada registro da tabela DTY representa uma viagem no SIGATMS, porém no Contas a Pagar é gerado apenas um título para o frete, e um título para cada imposto cálculo (IRRF, INSS, Pis, Cofins, CSLL, entre outros).
Para atendermos a integração SIGATMS x ERP Datasul Finanças APB, será necessário solicitarmos o cálculo dos impostos considerando o frete total de todos os registros da tabela DTY gerados e posteriormente será necessário atualizar a tabela DTY, com os valores proporcionais de cada imposto.
Considerando a seguinte regra:
((DTY->DTY_VALFRE * nValIRRF)/nValFrete), onde:
- DTY->VALFRE: É o valor do frete da viagem.
- nValIRRF: É o valor do imposto de renda calculado para todas as viagens do contrato de carreteiro.
- nValFrete: É o valor do frete total de todas as viagens do contrato de carreteiro.
Âncora | ||||
---|---|---|---|---|
|
No requisito (Rentabilidade-Ocorrência de receita/despesa), será possível gerar um contrato de carreteiro complementar para as ocorrências de despesas apontadas na viagem. Isso permitirá que as despesas ocorridas no decorrer da viagem, exemplo: Diária, Ajudante, entre outros, sejam apontadas no SIGATMS a partir de ocorrências e essas despesas poderão ser pagas para o fornecedor por meio de um título a pagar, gerado pelo contrato complementar.
O requisito Rentabilidade-Ocorrência de receita/despesa, permitirá que seja gerado um contrato de carreteiro complementar para cada fornecedor e natureza financeira identificada. Ou seja, se a viagem possuir mais de um fornecedor ou as despesas da viagem possuirem mais de uma natureza financeira, será gerado mais de um contrato de carreteiro complementar.
Como a natureza financeira existente no ERP Protheus não será utilizada no SIGATMS, quando a integração com o ERP Datasul estiver habilitada (MV_TMSERP == ‘1’), devemos gerar um contrato de carreteiro complementar para cada despesa, já que cada despesa poderá ter uma configuração de espécie diferente no ERP Datasul.
Sendo assim, ao gerarmos o contrato complementar enviaremos na Tag DocumentType àIdentificação: “303” – Contrato Complementar, já a Tag DocumentSubType, terá em seu conteúdo o código da despesa utilizada na ocorrência. Exemplo: “000000000000001” – Diária.
TMSA250SLD - Pagamento de Saldo Âncora TMSA250SLD TMSA250SLD
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.
Rotina de Integração: Âncora TMSI250ABP TMSI250ABP
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á efetivada a inclusão do DTY e atualizado com os impostos que o Datasul calculou.
Liberação do Contrato de Carreteiro (TMSA251) Âncora TMSA251 TMSA251
Caso o SIGATMS esteja integrado com o ERP Datasul (MV_TMSERP == '1') e a rotina de Liberação de Contratos estiver habilitada (MV_LIBCTC == .T.), ao gerar o Contrato de 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.
Complemento de Viagem (TMSA240) Âncora TMSA240 TMSA240
Atualmente o adiantamento da viagem é realizado na inclusão da viagem, porém deverá ser permitido que o transportador gere o título de adiantamento, a partir do fechamento da viagem. Esta configuração será realizada na contrato do fornecedor, 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 estiver configurado com a opção '0', deverá ser respeitada a função A050ManSE2(). Caso o ERP for Datasul ou seja, se o parâmetro MV_TMSERP estiver configurado com a opção '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, 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, estiver com o valor igual '0', a rotina de integração será chamada somente 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 (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)
TMSA252 | |
TMSA252 |
A rotina de Geração do contrato para redespachante, não deverá sofrer alteração, já que a geração do contrato será 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 Protheus (MV_TMSERP == 0), e na integração com o ERP Datasul (MV_TMSERP == 1).
Fechamento de Viagem (TMSA310) Âncora TMSA310 TMSA310
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 da 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 é 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”, 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 da 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 a % de adiantamento que será 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.
Reprocessamento de Mensagens ao EAI Âncora TMSAE77 TMSAE77
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 de 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 de 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 estiver integrado com o Protheus (MV_TMSERP) == '0'.
Rotinas/Fontes | Descrição |
---|---|
TMSA920 | Geração de AWB |
MATA120 | Pedido de Compras |
TMSA250Proc | Contrato de Prêmio |
Tmsa250Sld | Pagamento de Saldo do Contrato de Carreteiro |
TMSOPdgPC | Gera Pedido de Compras para Integração com Operadora de Frotas |
TMSA250SC7 | Gera Pedido de Compra |
TMSAB30 | Controle de Diárias |
FINA550 | Manutenção de Caixinha |
FINA560 | Movto.Caixinha |
Pedido de Compras Âncora MATA120 MATA120
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’. E mesmo que o campo esteja preenchido com a opção 0=”Não Considera”, não será considerado o parâmetro MV_TMSGRPC.
Âncora | ||||
---|---|---|---|---|
|
O SIGATMS permite que sejam utilizadas utilizadas as rotinas Manutenção 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’).
Âncora | ||||
---|---|---|---|---|
|
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:
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á utilizada 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 a listagem contendo todos os tributos calculado para o título. Será retornado em forma de uma lista. |
Dados Complementares: |
Foi observada 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 módulo Financeiro da marca receptora deverá tratar e gerar os títulos e suas baixas.
Como será 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:
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á 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 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.
Propriedades | |
Campo | Descrição |
NUMERO_VIAGEM | Tipo String |
FILIAL_ORIGEM | Tipo String |
PREFIXO_TITULO | Tipo String |
NUMERO_TITULO | Tipo String |
CONDICAO_PAGTO | Tipo String |
VALOR_DOCUMENTO | Tipo Numérico |
VALOR_PEDAGIO | Tipo Numérico |
VALOR_ADIANTAM | Tipo Numérico |
CODIGO_CLIENTE | Tipo String |
LOJA_CLIENTE | Tipo String |
CNPJCPF_CLIENTE | Tipo String |
DESCRICAO_CLIENTE | Tipo String |
FILIAL_DEBITO | Tipo String |
FILIAL_DEBITO | Tipo String |
DATA_EMISSAO | Tipo Date |
DATA_VENCIMENTO | Tipo Date |
DATA_TRANSACAO | Tipo Date |
NATUREZA_DEBITO | Tipo String |
HISTORICO | Tipo String |
EventType | Tipo String |
NomeTransacao | Tipo String |
TipoMensagem | Tipo String |
SubTipoMensagem | Tipo String |
Moeda | Tipo String |
MoedaDescricao | Tipo String |
Métodos | |
Chamada | Descrição |
New() | Construtor da classe, primeira chamada que fará com que o objeto seja instanciado. Modo de uso: <scopo Local,private> oDTClass := TransportDocumentClass():New() |
Send() | Responsável por montar o xml da mensagem de contas à pagar, o envio é da responsabilidade do Adapter EAI conforme o cadastro via configurador. |
Receive() | Responsável por interpretar o recebimento do XML da mensagem de retorno ou recebimento e também por realizar a inclusão, alteração ou exclusão do título conforme o tipo da ação da mensagem. Recebe 3 parâmetros: cXML: o xml que foi enviado e que será processado pela rotina cadastrada no adapter; nType: o tipo de processamento que será realizado se é um envio ou TRANS_SEND ou recebimento TRANS_RECEIVE; cMessageType: quando o recebimento informa qual é o tipo de recebimento podendo haver uma resposta no final do processamento da mensagem onde que pode assumir os seguintes valores: EAI_MESSAGE_WHOIS: retorna a versão da mensagem; EAI_MESSAGE_RESPONSE: retorna uma resposta ao solicitante ou transmissor da mensagem. EAI_MESSAGE_RECEIPT: trata a recepção de um retorno após o envio; EAI_MESSAGE_BUSINESS: trata a camada de negócio, aqui é processado o XML que realizará alguma ação no sistema receptor. |
setTipoMsg() | Define o tipo de envio para inclusão, alteração ou exclusão de algum título no contas à pagar da marca receptora da mensagem. deve ser informado os seguintes parâmetros. |
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 (SIGACFG) o menu: Ambiente/Schedule/Rotas Eai.
Preencha o campo conforme tabela 5.5.1
Campos | Descrição |
Produto | Informe o nome do produto de origem, transmissor da mensagem. |
Aplicação | Nome da aplicação que fará o envio/transmissão das mensagens. |
Url | Endereço http:// que represente o endpoint da marca receptora da integração. Deve estar no formato SOAP / ?WSDL. Atenção: não deve ser informado o ?WSDL no final do endereço. A aplicação se encarrega disso. |
Client WS | Informar aqui o nome da aplicação WS da marca com a qual faz a integração. Por padrão vem preenchido com WSEAISERVICE. |
Método | Qual o método de recebimento da mensagem será utilizado. Por padrão vem preenchido com receiveMessage. |
Usuário | Preencher este campo com o nome de usuário do WS da marca receptora quando este requer autenticação. |
Senha | Preencher este campo com a senha de acesso ao WS da marca receptora quando este requer autenticação. |
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:
- Verifique se o Protheus possui a última lib aplicada ou em uma versão igual ou superior a ??????????; acesse o canal de suport/downloads para baixar a ultima lib.
- Cadastrar as rotas de acesso as marcas que serão integradas pelo configurador.
- Cadastrar os Adapters E.A.I. para as rotinas que fazem integração com algum processo da marca receptora pelo configurador.
- 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.
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
Campos | Descrição |
Mensagem Única | Informe se o modelo da mensagem será única ou não. |
Rotina | Informe a rotina que possui chamada a rotina de integração. Se a rotina for MVC já possui por padrão as chamadas de integração pelo ModelDef, caso não seja MVC será necessário ter a chamada da rotina via função IntegDef e ativar a chamada pela rotina FwIntegDef(), o controle da chamada fica por conta do desenvolvedor. |
Mensagem | Se estiver configurado na rotina de integração, será preenchido automaticamente, do contrário deverá ser consultado no TFS o nome do arquivo .XSD referente a rotina. |
Envia | Se sim, o adapter se encarrega de realizar o envio das mensagens que estiverem na fila, caso seja Assíncrono. Se Síncrono o envio é de imediato. |
Recebe | Se sim, o adapter se encarrega de tratar a resposta da mensagem enviada. |
Método | Informe uns dos dois tipos de operação : Onde 1-Síncrono e 2-Assíncrono. |
Operação | Informe o tipo de operação que será trafegada por essa mensagem onde: 1-Todos; 2-Atualização; 3-Exclusão. |
Canal de Envio | Informe o tipo de envio, onde 1-ESB e 2-EAI. |
XSD | Informe a localização dos arquivos de validação da mensagem, deve estar abaixo do root do sistema. |
Versão de Envio | Versão da mensagem que será enviada, deve ser definida no bloco WHOIS da rotina de integração. |
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.3
Campos | Descrição |
Mensagem Única | Informe se o modelo da mensagem será única ou não. |
Produto | Se refere a marca cadastrada no cadastro de rotas, deve existir apenas um produto por endpoint. |
Aplicação de Origem | Nome informado no cadastro de rotas. |
Envia | Quando estiver configurado como SIM, o adapter fará o envio das mensagens pelo endpoint cadastrado na rota. |
Tabela 5.5.3
Informações | ||
---|---|---|
| ||
O cadastro das rotinas de integração deverá ser realizado para todas as rotinas informadas no início deste capitulo, referenciado pela tabela 5. |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente |
---|
técnico. |
---|
|
---|