Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Migration of unmigrated content due to installation of a new plugin

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

  

(Obrigatório)

Informações Gerais

 

Especificação

Produto

Protheus

Módulo

SIGATMS

Segmento Executor

 

Projeto1

LOGTMS01

IRM/EPIC1

 

Requisito/Story/Issue1

 

Subtarefa1

 

Chamado/Ticket2

 

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). 

(Obrigatório)

Objetivo

 

Atualizar a integração entre TMS e Repom utilizando modelos denominados pela Repom como integração financeiro Integração Financeiro e contábilContábil.

(Obrigatório)

 

Definição da Regra de Negócio

 

Para atender o objetivo acima, será necessário necessária a revisão de métodos utilizados na atual integração. Os pontos de integração entre os sistemas também serão revistos.

O atual serviço de WebService Protheus (TmsEventos, no fonte wstmse65), que a Repom alimenta será descontinuado (serviço de envio da Repom executado por software de transmissão de dados - “BizTalk”BizTalk). A As informações pessoais que eram enviadas pela Repom neste serviço, não serão mais integradas no sistema – tais como, detalhes de saque e compras do cartão creditado no contrato e passagens em postos.

Em substituição ao serviço de envio da Repom ao WebService Protheus, novos métodos de integração desenvolvidos pela Repom, serão consultados com o novo layout de movimentações que foram denominados como financeiro e contábil.

Nestes layout’s poderão ser verificados os dados de encerramento de viagens em postos. Este serviço disponibilizado pela Repom será disponibilizado apenas no dia seguinte ao efetivo ato no posto conveniado.

 

As atualizações na integração respeitarão o novo processo de integração de contas a pagar, onde será possível integrar-se, além do módulo financeiro do Protheus, ao Datasul para a gestão de contas a pagar decorrentes de processos e operações com terceiros no módulo TMS Protheus, conforme fluxo abaixo:

Image Removed

A seguir,

A seguir, segue mapa mental representando os pontos de integração entre os dois sistemas:

 Image Modified

 

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

 

Rotina

Rotina

Tipo de Operação

Opção de Menu

Regras de Negócio

MATA020 – Cadastro de Fornecedor

Alteração

Atualizações / Cadastros

 

TMSA800 – Contrato do Fornecedor

Alteração

Atualizações / Terceiros

 

OMSA040 – Cadastro de Motoristas

Alteração

Atualizações / Transporte

 

OMSA060 – Cadastro de Veículos

Alteração

Atualizações / Transporte

 

OMSA100 – Cadastro de Rotas

Alteração

Atualizações / Logística

 

TMSA240

-

Complemento da Viagem

Alteração

Atualizações / Viagens

 

TMSA310

-

Fechamento da Viagem

Alteração

Atualizações / Viagens

 

TMSA250

-

Contrato de Carreteiro

Alteração

Atualizações / Terceiros

 

TMSA250

-

Contrato de Carreteiro Complementar

Alteração

Atualizações / Terceiros

 

TMSA251

- Liberacao

– Liberação para Pagamento do Contrato de Carreteiro 

Alteração

Atualizações / Terceiros / Lib.Contratos

 

WSTMSE65 – Web service de recepção de retorno Repom

Exclusão

Não Aplicável

 

 

MATA020 – Cadastro de Fornecedor (MATA020) 

O fornecedor do Protheus integra-se como “Contratado” Contratadoà Repom. O método em que se atualiza esta informação deverá ser alterado para que passe a utilizar o método “IntegraDadosCadastroNacionalANTT”IntegraDadosCadastroNacionalANTT.

No cadastro Cadastro de Fornecedores (MATA020) foi disponibilizado o botão “DadosxOperDadosxOper., para permitir a integração on-line do fornecedor com a Repom.

 

TMSA800 – Contrato do Fornecedor (TMSA800) 

No sistema da Repom, as operações de transporte são um conjunto de configurações para que o sistema se comporte de maneira distinta, de forma a atender aos diferentes tipos de operações. Por exemplo, há operações que contemplam a quebra de peso e quebra de frete. Durante a emissão do contrato na base da Repom, é necessário enviar junto dos dados da viagem, qual a operação qual operação deseja utilizar.

No cadastro de contratos Contratos de fornecedores Fornecedores (TMSA800), deverá ser associado a operação Repom a que o fornecedor irá utilizar na integração. Esta operação, se indicada, irá sobrepor a atual indicação que até hoje era indicada no perfil do cliente (devedor do frete na viagem).

As operações devem estar previamente cadastradas na operadora Repom, pois não há integração para inclusão ou manutenção destas – apenas a indicação qual de qual operação interna Repom será utilizada em cada contrato.

 

OMSA040 – Cadastro de Motoristas (OMSA040)

No Cadastro de Motoristas foi disponibilizado o botão “DadosxOperadDadosxOperad.” que permite realizar on-line a integração dos dados do motorista com a Repom. O método em que se atualiza esta informação deverá ser alterado para que passe a utilizar o método “IntegraDadosCadastroNacionalANTT”IntegraDadosCadastroNacionalANTT.

Esta integração também pode ser configurada para ocorrer de maneira automática, por meio da tecla <F12> <F12> disponível no browse. Caso a integração seja ativada de forma automática, a cada novo cadastro ou alteração dos dados do motorista, a integração com a Repom será iniciada.

No Cadastro de Motoristas também está disponível o botão “MotMot.xOper.”, na barra de ferramentas, permitindo amarrar um cartão ao motorista.


OMSA060 – Cadastro de Veículos (OMSA060)

Os veículos do Protheus integram-se como “veiculo” ou “carreta” veículo” ou “carretana Repom. O TMS Protheus enviará à Repom como tipo “carreta” carretaaqueles veículos cuja a categoria do tipo de veículo a qual ele pertence esteja como 3-Carreta. As demais categorias serão enviadas como “veiculo” veículoà Repom.

No Cadastro de Veículos foi disponibilizado o botão “DadosxOperadDadosxOperad.” para realização da integração dos dados com a Repom. O método em que se atualiza esta informação deverá ser alterado para que passe a utilizar o método “IntegraDadosCadastroNacionalANTT”IntegraDadosCadastroNacionalANTT.

Também é possível fazer com que a integração ocorra de forma automática, bastando definir, por meio da tecla <F12><F12>, o parâmetro “Atualizar Atualizar dados com Operadora” Operadoraigual a “Sim”Sim.


OMSA100 – Cadastro de Rotas (OMSA100)

Assim como a operação de transporte, as informações referentes referente ao roteiro/percurso da viagem devem ser enviadas no momento da emissão de um contrato ou na emissão do controle de viagem na Repom. Cada rota do Microsiga Protheus é amarrada a um roteiro/percurso da Repom.

No cadastro Cadastro de Rotas existe atualmente uma consulta ao roteiro, baseada na região de origem, onde associa-se o Roteiro selecionado à rota.

Será criado criada uma tela para a solicitação de Roteiro na Repom a partir do cadastro de Rotas, para as situações onde o Roteiro não existir. A tela deverá conter obrigatoriamente a Origem e o Destino do Roteiro (já sugeridos, se possível, a partir da rota) e, opcionalmente, pontos intermediários em que o Roteiro Repom deverá passar.

A partir desta tela, deverá ser consumido o método “SolicitaRoteiro” SolicitaRoteiroda Repom. Esta ação tem até 15min para ser executada pela Repom atualmente e a confirmação da solicitação não significará que um Roteiro fora incluído.

A consulta aos roteiros tem que ser utilizada novamente para associação após a inclusão do Roteiro pela Repom 3.

Exemplo de uso do método “SolicitaRoteiro”SolicitaRoteiro

<solicita_roteiros>
<roteiro>
<roteiro_codigo_cliente>abc123</roteiro_codigo_cliente> <!-- Código Cliente --/>
<cidade_origem_ibge>2637</cidade_origem_ibge>
<cidade_origem_cep />
<estado_origem>MT</estado_origem>
<cidade_destino_ibge>18701</cidade_destino_ibge>
<cidade_destino_cep />
<estado_destino>SP</estado_destino>
<tipo_processo_transporte>0</tipo_processo_transporte>
<tempo_previsto_viagem />
<tipo_local_quitacao />
<codigo_local_quitacao />
<ida_volta>0</ida_volta>
<altera_roteiro />
<observacao />
<vias> <!-- OPCIONAL (A TAG PODE SER MANDADA FECHADA "<vias />" -->
<via>
<via_descricao>CAMPO NOVO DO PARECIS-MT</via_descricao>
<via_descricao>CUIABA-MT</via_descricao>
<via_descricao>RONDONOPOLIS-MT</via_descricao>
<via_descricao>SAO JOSE DO RIO PRETO-SP</via_descricao>
</via>
</vias>
</roteiro>
</solicita_roteiros> 

 

TMSA240 – Complemento da Viagem (TMSA240/ Abertura da Viagem (TMSA140/141/144) 

Depois de informado o código da operadora no complemento de viagem, ao informar o veículo da viagem, automaticamente será calculado o pedágio referente à rota selecionada na janela tela de viagem.

O cálculo do pedágio ocorre de maneira on-line e o valor retornado é passado pela Repom:

Exemplo de XML de consulta de pedágio à Repom:

 

                <roteiro>

                               <roteiro_codigo>23293</roteiro_codigo>

                               <percurso_codigo>4</percurso_codigo>

                               <roteiro_cliente_codigo></roteiro_cliente_codigo>

                               <numero_eixos>3</numero_eixos>

                </roteiro>

 

Para completar os dados da integração, deve-se informar ainda o número do cartão que o motorista portará durante a viagem. Esse número pode ser obtido automaticamente por meio da amarração entre motorista x cartão.

Mesmo que o número do cartão seja obtido automaticamente, pode-se alterá-lo pelo botão “MotMot.Viag.

Após o preenchimento dos dados do complemento de viagem, esta será gravada. Na gravação, ao utilizar os recursos da integração, serão sincronizados os dados de fornecedores, motoristas e veículos com a base de dados da Repom.

O método de validação do cartão Repom deverá ser retirado desta rotina, pois será utilizado o método “ValidaAbertura”

 

ValidaAbertura

Informações
titleImportante:

É importante frisar que até este momento nenhum processo foi iniciado junto à Repom. Na abertura da viagem, somente são checadas as informações para que, no momento da emissão do contrato ou na abertura do controle de viagem, estejam válidas.

 

  


Opcional

Protótipo de Tela

 

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

 

Protótipo 01

 

 

 Image Removed

 

 

 

 

 

 

Opcional

Fluxo do Processo

 

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

 

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

  

Índice

Chave

01

<FI9_FILIAL+FI9_IDDARF+FI9_STATUS>

02

<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF>

03

<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO>

Campo

<AAA_PERESP>

Tipo

<N>

Tamanho

<6>

Valor Inicial

<Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. 

Mandatório

Sim (  ) Não (  )

Descrição

<Referência Mínima para Cálculo>

Título

<Ref.Calc.>

Picture

<@E999.99>

Help de Campo

<Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação>

 

(Opcional)

Grupo de Perguntas

 

<Informações utilizadas na linha Protheus>.

 

Nome: FINSRF2

X1_ORDEM

01

X1_PERGUNT

Emissão De

X1_TIPO

D

X1_TAMANHO

8

X1_GSC

G

X1_VAR01

MV_PAR01

X1_DEF01

Comum

X1_CNT01

'01/01/08'

X1_HELP

Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório 

 

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

 

Consulta: AMB

Descrição

Configurações de Planejamento

Tipo

Consulta Padrão

Tabela

“AMB”

Índice

“Código”

Campo

“Código”; ”Descrição”

Retorno

AMB->AMB_CODIGO

 

Exemplo de uso do método “ValidaAberturaContrato” a ser enviado na abertura da viagem:

Image Added

Destaca-se aqui que a tag “trechos”, que deve ser enviada fechada, para que não solicite novo Roteiro à Repom. 

 

Fechamento da Viagem (TMSA310) 

A integração dos dados do Protheus com a Repom ocorrerá por viagem, isto é, pode-se definir, a cada viagem, se haverá ou não integração com a Repom.

A emissão do contrato na Repom é o inicio do controle de um processo quando se utiliza frota de terceiros.

No Protheus, a emissão do contrato na Repom será acionada no fechamento da viagem, em que será acionado automaticamente o método “EmiteContrato”.

Esse método processa as informações enviadas com base nos cálculos realizados no Protheus e devolve as informações referente aos pontos de apoio (passagens em postos) e os dados preliminares da quitação do contrato.

A operação de estorno do fechamento deverá chamar o método “CancelaContrato”. 

Image Added

 

 

Informações
titleImportante:

É importante observar que não mais na geração do contrato de carreteiro que abrirá o contrato Repom, mas sim, no fechamento da viagem. 

 

Segue um exemplo de XML de Emissão de contrato com valor previsto (nova funcionalidade) de R$ 1,00 (um real), sem adiantamento:
 
 <processo_transporte>
       <dados_operacionais>
             <operacao_codigo>1</operacao_codigo>
             <roteiro_codigo>23293</roteiro_codigo>
             <percurso_codigo>4</percurso_codigo>
             <solicitacao_roteiro_codigo></solicitacao_roteiro_codigo>
             <roteiro_cliente_codigo></roteiro_cliente_codigo>
             <roteiro_ida_volta>0</roteiro_ida_volta>
             <filial_codigo_cliente>01</filial_codigo_cliente>
             <processo_cliente_codigo>V-001</processo_cliente_codigo>
             <cartao_codigo>600801097</cartao_codigo>
             <usuario>vlademir</usuario>
       </dados_operacionais>
       <configuracoes_viagem>
             <data_saida>07/11/2016</data_saida>
             <hora_saida>18:00</hora_saida>
       </configuracoes_viagem>
       <documentos_integrados>
             <conhecimentos>
                    <conhecimento>
                           <ctrc_codigo>9990001</ctrc_codigo>
                           <ctrc_serie>1</ctrc_serie>
                           <ctrc_filial_codigo_cliente>01</ctrc_filial_codigo_cliente>
                           <documento_tipo>0</documento_tipo>
                           <nfs>
                                  <nf>
                                        <nf_codigo>320736</nf_codigo>
                                        <nf_serie>10</nf_serie>
                                        <nf_remetente_cnpj>70940994008277</nf_remetente_cnpj>
                                        <nf_remetente_razao>PANDURATA ALIMENTOS LTDA</nf_remetente_razao>
                                        <nf_destinatario_cnpj>75315333016293</nf_destinatario_cnpj>
                                        <nf_destinatario_razao>ATACADAO S.A.</nf_destinatario_razao>
                                  </nf>
                           </nfs>
                    </conhecimento>
             </conhecimentos>
       </documentos_integrados>
       <dados_contratado>
             <contratado_cnpj_cpf>57813639634</contratado_cnpj_cpf>
             <motorista_cpf>29973825802</motorista_cpf>
             <cavalo_placa>IBB5648</cavalo_placa>
             <carreta_placa></carreta_placa>
             <carreta_rntrc></carreta_rntrc>
             <carreta_numero_eixos></carreta_numero_eixos>
       </dados_contratado>
       <dados_carga>
              <antt_ncm_codigo_classificacao_mercadoria>0001</antt_ncm_codigo_classificacao_mercadoria>
             <carga_peso>4998</carga_peso>
             <carga_volume></carga_volume>
             <carga_valor>50449</carga_valor>
             <carga_destinatario_cpf_cnpj>75315333016293</carga_destinatario_cpf_cnpj>
             <carga_destinatario_nome_razao_social>ATACADAO S.A.</carga_destinatario_nome_razao_social>
             <carga_unidade_codigo></carga_unidade_codigo>
       </dados_carga>
       <dados_frete>
             <valor_frete>1</valor_frete>
             <valor_adiantamento>0</valor_adiantamento>
       </dados_frete>
       <movimentos></movimentos>
</processo_transporte>  

 

Contrato de Carreteiro (TMSA250) 

A geração do Contrato de Carreteiro, que era obrigatória antes do fechamento da viagem, deixará de sê-lo. Na nova integração o contrato de carreteiro será gerado apenas após o fechamento da viagem.

Quando o contrato de carreteiro for gerado, ele calculará a diferença entre o valor previsto enviado no fechamento de viagem e o total do frete (considerando valor com ou sem impostos, de acordo com o parâmetro MV_IMPCTC), atualizando o valor do contrato Repom por meio do método “IncluiMovimento”.

De acordo com a parametrização de geração do título (MV_LIBCTC e DUJ_TITFRE), será quitado o contrato.

Caso o ERP utilizado seja o Protheus, haverá possibilidade de autorizar o pagamento pela rotina “Pagamento de Saldo”, caso seja outro ERP, não há esta possibilidade e a configuração da Repom será de quitação automática ou deve utilizar parametrização que utilize a autorização de pagamento (Liberação de Contrato).

 

 Image Added

Exemplo de XML de inclusão de movimento: 

                <movimento>

                               <cliente_codigo>0773</cliente_codigo>

                               <processo_transporte_codigo>31</processo_transporte_codigo>

                               <movimento_codigo />

                               <movimento_cliente_codigo>19</movimento_cliente_codigo>

                               <valor>499.00</valor>

                               <tipo_operacao />

                </movimento>

 

Contrato de Carreteiro Complementar (TMSA250)           

Quando há necessidade de acrescentar valores ao contrato Repom e o contrato de carreteiro já fora gerado, poderá ser gerado o Contrato de Carreteiro Complementar.

O método para a inclusão de valores será o “IncluiMovimento” e seu funcionamento atual está correto.

 Image Added

  

Informações
titleImportante:

É importante observar que o processo com contrato complementar de carreteiro já se integra desta maneira com a Repom. Entretanto, com a possibilidade de gerar o contrato de carreteiro após o encerramento da viagem, há possibilidades de trabalhar com componentes calculados para a obtenção de valores extras, sem a necessidade do contrato complementar de carreteiro. O valor no contrato complementar de carreteiro é inserido de forma manual.

 

Liberação para Pagamento do Contrato de Carreteiro (TMSA251) 

Para o fechamento do saldo do contrato Repom, considerados os movimentos de saldo final e também créditos e/ou débitos decorrentes da viagem (seja um contrato complementar ou não), será utilizado o método “QuitaContrato”.

Após o processamento da quitação do contrato de carreteiro, é possível apurar o valor final que é devido ao carreteiro.

Para que o valor final seja creditado na conta corrente do carreteiro, deve-se acionar o método “Autoriza Pagamentos”. Esse método é acionado a partir da Liberação do Contrato de Carreteiro. Ao confirmar a liberação, automaticamente será solicitada a autorização para pagamento do saldo do contrato.

 Image Added

 

Informações
titleImportante:

Não é possível reverter uma autorização para pagamento do saldo de contrato no sistema da Repom. Portanto, ao estornar a liberação do contrato de carreteiro no Protheus, o contrato no sistema da Repom continuará autorizado. Para realização do cancelamento da autorização para pagamento de saldo, entre em contato com o suporte técnico da Repom.

Somente após o cancelamento da autorização, será possível liberar novamente no Protheus o contrato de carreteiro.

(Opcional)

Estrutura de Menu

 

<Informações utilizadas na linha Datasul>.

 

Procedimentos

 

Procedimento

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Módulo

 

 

 

Programa base

 

 

 

Nome Menu

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Registro padrão

Sim

Sim

Sim

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Release de Liberação

 

 

 

 

 

 

Programas

 

Programa

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Nome Externo

 

 

 

Nome Menu/Programa

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Nome Verbalizado[1]

(Max 254 posições)

(Max 254 posições)

(Max 254 posições)

Procedimento

 

 

 

Template

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

Tipo[2]

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Categoria[3]

 

 

 

Executa via RPC

Sim/Não

Sim/Não

Sim/Não

Registro padrão

Sim

Sim

Sim

Outro Produto

Não

Não

Não

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Query on-line

Sim/Não

Sim/Não

Sim/Não

Log Exec.

Sim/Não

Sim/Não

Sim/Não

Rotina (EMS)

 

 

 

Sub-Rotina (EMS)

 

 

 

Localização dentro da Sub Rotina (EMS)

 

 

 

Compact[4]

Sim/Não

Sim/Não

Sim/Não

Home[5]

Sim/Não

Sim/Não

Sim/Não

Posição do Portlet[6]

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

Informar os papeis com os quais o programa deve ser vinculado

 

 

 

 

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.

 

Código Papel

(máx 3 posições)

Descrição em Português*

 

Descrição em Inglês*

 

[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.

[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante

[3] Categorias são obrigatórias para os programas FLEX.

[4] Obrigatório quando o projeto for FLEX

[5] Obrigatório quando o projeto for FLEX

[6] Obrigatório quando o projeto for FLEX

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