Árvore de páginas

Versões comparadas

Chave

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

INTEGRAÇÃO ROTEIRIZADOR MAPLINK X SIGATMS

Cada vez mais é necessário pensar em soluções logísticas para otimizar e reduzir os custos das operações de transporte.  

Diante deste cenário o módulo Gestão de Transportes (SIGATMS) uniu toda expertise em gestão de transportes com a solução logística de roteirização de carga fornecida pela empresa MapLink, agregando inteligência e otimizando o processo de entregas e coletas dentro do SIGATMS. Fazendo com que as coletas/entregas tenham uma melhor disposição e ordem, e dessa maneira além de reduzir o tempo de operação também se reduz custos dentro da operação de transporte, além da obtenção prévia dos valores de pedágio.


O módulo passa a utilizar as API's fornecidas pela MapLink para solucionar os problemas de ordem de entrega/coleta, melhor trajeto a ser realizado considerando o menor tempo ou menor distância, valores das praças de pedágio, plotagem e visualização do trajeto, coordenadas geográficas dos clientes.

  • API Planning tem como objetivo otimizar a operação de coleta/entrega, atribuindo a melhor ordem para as operações a fim de que o custo total seja reduzido e a produtividade aumente. 
  • API Trip é o serviço de roteirização para rotas simples e com múltiplos pontos, que se adapta ao tipo e especificações do veículo e leva em conta as especifidades e restrições do tempo da operação.
  • API Tolls  inclui os gastos com pedágio nos cálculos da operação e garante as previsões e controle de custos efetivos.
  • API GeoCode tem como objetivo encontrar as coordenadas geográficas dos endereços.


Sistemas Envolvidos

  • SIGATMS - As funcionalidades e rotinas que estão envolvidas no processão são: Cadastro de Clientes, Cadastro de Solicitante, Cadastro de Sequência de Endereço, Cadastro de Referências Geográficas, Viagem, Cadastro Roteirizador, Limpeza de Histórico de Integração
  • MAPLINK - As apis envolvidas são: GeoCode, Planning, Trip, Tolls e Map Display. Para maiores informações acesse: https://maplink.global/apis-maplink/ 


Integração

A integração tem como objetivo otimizar o processo de entrega e/ou coleta dos transportadores que utilizam o módulo SIGATMS.


Para que toda a solução funcione perfeitamente é necessário obter as coordenadas geográficas de todos os clientes, de acordo com os respectivos endereços. Para isso utilizamos a api GeoCode que retorna a latitude e longitude de acordo com o endereço enviado. As informações recebidas são gravadas no Cadastro de Referências Geográficas.

Os documentos serão ordenados na viagem, de acordo com a melhor sequência de entrega/coleta sugerida pela a api Planning.

Após obtido a melhor sequência de entrega/coleta a api Trip sugere a melhor rota para o veículo realizar, de acordo com a melhor sequência de entrega/coleta.

De acordo com a rota sugerida, obtém-se os gastos com pedágio de acordo com a quantidade de eixos dos veículos, através da api Tolls, e os valores de pedágio são atualizados automaticamente dentro da viagem.

Toda a visualização dos pontos de entrega/coleta, rota e praças de pedágio serão exibidas dentro do SIGATMS em um mapa, através da funcionalidade Map Display.


  • Premissas
    • Possuir licenças Maplink.
    • Configurar WebService - Configurar Portais e Webservices .
    • Configurar Servidor REST - 01. Configuração .
    • Parâmetro de integração MV_MAPLINK habilitado.
    • Arquivos HTML
      • Os arquivos html (tmsshowrota.html, pedagio.png, tmsimg32.png e totvstec.js) devem estar na pasta definida na seção HTTP, tag PATH do appserver.ini;
    • Atualização do menu SIGATMS.xnu;


  • Tecnologia
    • Protheus versão 12.1.23 ou superior. 
    • Build superior à 131217A.
    • Dicionário de dados atualizado com tabelas referente a integração.

Escopo


Toda a integração e os dados trafegados são gravados na tabela Histórico de Integração - DLU.


GeoCode

As rotinas Cadastro de ClienteSequência de EndereçoCadastro de Solicitantes foram atualizadas para que ao final da gravação as informações referentes ao endereço sejam enviadas automaticamente para a api GeoCode a fim de obter as coordenadas geográficas do respectivo endereço. As coordenadas geográficas recebidas são gravadas na tabela DAR - Referência Geográficas, e é possível visualiza-las através da rotina Cadastro de Referências Geográficas - TMSAO15.

Envio:

  • País;
  • Estado;
  • Cidade;
  • Bairro;
  • Rua;
  • Número;
  • CEP;

As informações recebidas são:

  • Latitude;
  • Longitude;


Planning

O objetivo da integração com a api Planning é otimizar os pontos de entrega/coleta e reordenar os documentos da viagem. 

A rotina de viagem foi alterada para que quando o campo Tipo de Retorno (DLV_TIPRET) da tabela Dados Cadastrais Roteirizador (DLV) esteja igual a 1=CallBack; a informações sejam enviadas automaticamente para a api Planning.

Pode-se também acionar a rotina a partir do menu criado na rotina Viagem (TMSA144): Ações Relacionadas > Roteirizador > Integra

Envio:

  • callback
    • Endpoint em que se encontra o serviço Rest - O endpoint deverá ser incluído no Cadastro Roteirizador (TMSAO52), campo URL CallBack (DLV_URLCAL);
  • logisticconstraints
    • Duração em tempo das operações de transporte (DTW);
      • DC6_DURAC é o campo que contém a duração das operações de transporte;
      • As operações enviadas são: 
        • Chegada de Viagem - MV_ATIVCHG;
        • Saída de Viagem - MV_ATIVSAI;
        • Chegada em Cliente - MV_ATVCHGC;
        • Saída do Cliente - MV_ATVSAIC;
        • Descarregamento - MV_ATIVDCA;
  • depots
    • Coordenadas geográficas do endereço da filial (SM0);
  • legislationprofiles
    • "DEFAULT";
  • operations
    • Informações dos documentos de entrega/coleta;
      • Número do documento;
      • Destinatário;
      • Prioridade;
      • Produto;
      • Tipo : DELIVERY ou COLLECTION;
      • Local de origem: Filial;
      • Peso;
      • Volume;
  • products
    • Produtos enviados nas notas fiscais;
  • sites
    • Coordenadas geográficas do endereços dos destinatários (Cliente, Solicitante ou Sequência de endereço);
  • vehicletypes
    • Volume máximo do veículo da viagem - DA3_VOLMAX;
    • Capacidade máxima do veículo da viagem - DA3_CAPACM;
    • Tamanho do veículo - DA3_COMEXT;
  • vehicles
    • Legislação vigente: "DEFAULT";
    • Janela de disponibilidade
      • Data atual;
      • Hora atual;
      • 1 dia após a data atual;
      • "23:59";
    • Local de origem: Filial;
    • Local de chegada: Filial;
    • Máximo de rotas: 1;
  • optmizationprofile: "BRAZIL37";
  • tripsprofile: "BRAZIL";


Trip

O objetivo da integração com a api Trip é roteirizar os pontos de entrega/coleta e sugerir a melhor rota.


Envio:

  • points
    • Coordenadas geográficas dos destinatários;
  • profilename: "BRAZIL";
  • calculationmode - De acordo com a opção Modo de Cálculo (mv_par02) informado nas propriedades do roteirizador (Pergunte TMSAO46): Acesse a rotina Cadastro Roteirizador (TMSAO52) > Outras Ações > Propriedades Roteirizador;
    • 1=THE_FASTEST - Indica que a rota deverá ser calculada considerando o caminho mais rápido; 
    • 2=THE_SHORTEST - Indica que a rota deverá ser calculada considerando o caminho mais curto;
  • callback
    • Endpoint em que se encontra o serviço Rest - O endpoint deverá ser incluído no Cadastro Roteirizador (TMSAO52), campo URL CallBack (DLV_URLCAL);
  • startdate: Data e Horário atual;
  • useRealSpeeds - De acordo com a opção User velocidade real? (mv_par03) informado nas propriedades do roteirizador (Pergunte TMSAO46): Acesse a rotina Cadastro Roteirizador (TMSAO52) > Outras Ações > Propriedades Roteirizador;
    • 1 = true - Indica que deverá considerar o histórico de velocidade para o mesmo dia da semana e horário;
    • 2 = false - Indica que deverá considerar a velocidade da via;
  • vehiclespecification - Informações dos veículos
    • Altura máxima: DA3_ALTEXT;
    • Comprimento máximo: DA3_COMEXT;
    • Máxima distância entre eixos: DA3_COMEXT;
    • Capacidade máxima: DA3_CAPACM;
    • Capacidade máxima para materiais perigosos: DA3_CAPACM;
    • Capacidade máxima para materiais explosivos: DA3_CAPACM;
    • Capacidade máxima para materiais poluentes: DA3_CAPACM;
    • Capacidade máxima por eixo: DA3_CAPACM / DTR_QTDEIX;
    • Largura máxima: DA3_LAREXT;


Tolls

A api Tolls fornece os valores e as praças de pedágio que existem no percurso da rota. Após obter os valores de pedágio dentro do complemento da viagem (DTR_VALPDG).


Envio:

  • legs
    • Rota e percurso calculado pela api TRIP;
    • Eixos - De acordo com a opção Calcula retorno filial? (mv_par01) informado nas propriedades do roteirizador (Pergunte TMSAO46): Acesse a rotina Cadastro Roteirizador (TMSAO52) > Outras Ações > Propriedades Roteirizador
      • 1=Sim - É enviada a quantidade de eixos (DTR_QTDEIX) e após a última entrega/coleta é adicionado um novo trecho retornando a filial e nesse último trecho é utilizado a quantidade de eixos do campo (DTR_QTDEIXV);
      • 2=Não - É enviada a quantidade de eixos (DTR_QTDEIX);
  • source: DEFAULT;


MapDisplay

Essa funcionalidade permite a exibição do mapa e os pontos de coleta/entrega. O mapa será exibido quando todas as etapas da integração citadas acima forem concluídas com sucesso.

O mapa pode ser consultado a partir da rotina Viagem > Outras Ações > Roteirizador > Consulta (TMSAO50) após entrar na rotina Controle Integração TMS X Roteirizador acesse a opção Outras Ações > Vis. Mapa


IMPORTANTE!

  • Não é escopo desse documento descrever a instalação do ERP Protheus, nem suas configurações básicas. 
  • Para utilização da integração, o módulo SIGATMS  na versão 12.1.23 (ou superior) do Protheus deve estar com o ambiente atualizado com a última versão de RPO e o dicionário disponível na Central de Downloads TOTVS.
  • Para obter mais informações sobre como atualizar o dicionário de dados do Protheus 12, clique aqui.
  • A inteligência para fornecimento das melhores rotas e/ou sequência de entrega/coleta é responsabilidade da MapLink.
  • Deve-se preencher corretamente as informações país, estado, cidade, bairro, endereço cep. O preenchimento incorreto dos campos ocasionará em coordenadas geográficas erradas e/ou inexistentes.
    • Deve-se preencher corretamente as informações citadas acima para:
      • Cadastro de filiais;
      • Cadastro de clientes;
      • Sequência de endereço;
      • Cadastro de solicitantes;
  • Deve-se preencher corretamente as informações capacidade máxima, volume máximo, altura externa, comprimento externo e largura externa do cadastro de veículos. O preenchimento incorreto dos campos ocasionará falhas de integração e/ou inconsistência no cálculo das apis.





Pré-requisitos instalação/implantação/utilização

Relacione quais são os pré-requisitos (técnicos ou de negócio) para a integração. Este tópico não deve incluir informações da implantação normal do módulo, mas apenas informações específicas da integração. É como se este tópico já partisse do princípio que o módulo que será integrado já está normalmente instalado.


Entre os tópicos deste tópico podemos citar:

  • Versões mínimas de produtos.
  • Módulos ou programas que geram informações necessárias a integração. Muitas vezes a integração partirá de informações que somente são trabalhadas em um determinado programa ou processo, que deverá estar em uso no cliente.
  • Ferramentas que são necessárias a integração, como: EAI, ESB, servidor de WebService etc.
  • Aspectos legais nos quais as partes envolvidas na integração devem estar inseridas, caso as informações envolvidas sejam utilizadas para o cumprimento de alguma lei específica.
  • Requisitos de hardware ou Software, como servidores, link de internet, capacidade de armazenamento e memória, sistema operacional.

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

Instalação/Atualização

Este tópico tem por objetivo orientar a instalação da integração, visando o seu funcionamento completo. Instalação de produtos ou ferramentas necessárias podem referenciar outros documentos existentes, desde que estejam disponíveis no repositório de documentação da TOTVS ou sejam enviados junto com o documento da integração em si. As informações mínimas necessárias para teste tópico são:

  • Procedimentos que devem ser observados quando um dos produtos for atualizado.
  • Configuração necessária que deve ser realizada em arquivos de configuração ou programas de parâmetros etc.
  • Arquivos diversos que devem ser mantidos em determinados locais para o funcionamento da integração, exemplo: xml, xsd.
  • Atualizações necessárias em banco de dados ou instruções para que elas sejam feitas.
  • Processos, módulos ou programas que precisam ser instalados ou atualizados. Deve ser definida a versão mínima necessária dos programas envolvidos.
  • Ferramentas, servidores ou serviços que precisam ser disponibilizados e configurados, o que pode gerar necessidade de novo hardware ou aumento de capacidade. Exemplo: serviço de WebService.
  • Instruções para habilitar a comunicação da ferramenta EAI entre as partes, quais rotas devem ser definidas ou como as transações devem ser habilitadas.

 

Observação: evite o uso de Prints de telas, facilitando, assim, o trabalho de tradução e versionamento deste documento.

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

Controle de Versão

O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.

Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definidas pelo Comitê de Integração TOTVS.

Suporte

O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim as equipes de suporte dos produtos RM Conector e Backoffice Protheus estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.

Observação: Este modelo de suporte está sendo revisado pela TOTVS.

Transações/Entidades/Mensagens únicas

Apresente quais as transações/entidades que são trocadas e quem envia a informação para quem. Pode (e recomenda-se) ter um diagrama, uma tabela ou afins que apresente este fluxo.

Relacione quais são as mensagem únicas (TOTVSMessage) utilizadas e qual o seu relacionamento com as entidades já existentes do ERPs envolvidos.

Exemplos:

 


 



+Método

ID

Descrição

Origem

Destino

XSD (versões podem variar)

Cadastros

01

Cliente/Fornecedor

RM

Protheus

CustomerVendor_1_000.xsd

02

Moeda

RM

Protheus

Currency_1_000.xsd

03

Unidade de Medida

RM

Protheus

UnitOfMeasure_1_000.xsd

04

Produto

RM

Protheus

Item_?_000.xsd

05

Centro de Custo

RM

Protheus

CostCenter_1_000.xsd

06

Ativos

RM

Protheus

NOVA, Ativo fixo

07

Funcionários

RM

Protheus

Employee_1_000.xsd

08

Projeto

RM

Protheus

Project_1_000.xsd

09

Obra

RM

Protheus

SubProject_1_000.xsd

10

Tarefa

RM

Protheus

TaskProject_1_000.xsd

11

Meio de Pagamento

RM

Protheus

?????.xsd

12

Condições de pagamento

RM

Protheus

PaymentCondition_1_000.xsd

13

Coligada*
* implementado, mas o Protheus não vai enviar, estamos avaliando alternativa para preencher o de/para

RM

Protheus

Company_1_000.xsd

14

Filial*
* implementado, mas o Protheus não vai enviar, estamos avaliando alternativa para preencher o de/para

RM

Protheus

Branch_2_000.xsd

Processos

15

Solicitações (compras/armazém)

Protheus

RM

Request_1_000.xsd

16

Cancelar movimento (solicitação, OS, etc)

Protheus

RM

CancelRequest_1_000.xsd

17

Cancelar movimento (solicitação, OS, etc)

RM

Protheus

CancelRequest_1_000.xsd

18

Baixa de estoque

Protheus

RM

Request_1_000.xsd

19

Baixa de estoque

RM

Protheus

Request_1_000.xsd

20

Consulta Saldo

Protheus

RM


21

Apropriação de custos



Request _1_000.xsd

22

Geração de OS




23

Consulta de OS




24

Ampliação patrimonial






Fluxo das Informações

 

Para cada fluxo de informação descreva, se necessário, alterações de comportamento que o respectivo produto irá sofrer. Por exemplo: quando o Logix recebe o PEDIDO de OUTRO ERP, este pedido não poderá ser alterado no Logix.

Liste quais as entidades integradas e como é o mapeamento entre as diferentes estruturas. Por exemplo: Classe no sistema A vira categoria no sistema B, o campo X é refletido no campo Y etc.

Liste quais transações/operações a integração fará com as entidades relacionadas. Exemplo: Insert de PEDIDO, Insert, update de ITEM, buscar saldo em estoque do ITEM no dia X ou buscar dados do FUNCIONÁRIO.

Cadastros

Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.

Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos

Em seguida faça uma descrição para cada um dos fluxos para cada entidade

 

<Transação/Entidade>

Identificador da Mensagem: <mensagem>

Versão: <versão>

Módulo <marca 1>: <BackOffice – Gestão xxxxxxx>

Módulo <marca 2>: <SIGAXXX>

Tipo de Envio: <Assíncrona/Síncrona>


Mensagem Padrão

PROTHEUS

RM

Tabela

Campo

Tabela

Campo

Code

CTO990

CTO_SIMB

GMOEDA

SIMBOLO *

Description

CTO990

CTO_DESC

GMOEDA

DESCRICAO

Symbol

CTO990

CTO_SIMB

GMOEDA

SIMBOLO


Notas:

Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela

A seguir descrever as variações, particularidades da mensagem e processos (integração) de acordo com cada marca


Limitações/Restrições

Descreva limitações e restrições para a integração que está sendo descrita.

Processos

Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.

Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos

Em seguida faça uma descrição para cada um dos fluxos para cada entidade

 

<Transação/Processo>

Tipo de Fluxo: Protheus -> RM

Mensagem: Request_1_000

Versão: 1.000

Descrição de todo o comportamento e funcionamento do processo. Breve contexto, origem, regras, integração (geração da mensagem, envio, recebimento no destino), o quê supostamente irá ocorrer no destino, retorno, impacto, consequências, o que foi afetado, como conferir, validar, etc o retorno.


Acrescentar um diagrama do processo.

A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca


Notas:

Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela


Limitações/Restrições

Descreva limitações e restrições para a integração que está sendo descrita. 

Limitações / Restrições Gerais

Descreva limitações e restrições para cada fluxo descrito no tópico anterior. Exemplo:

  • ERP1 envia ITEM cadastrado para o ERP2

ERP1 somente enviará o ITEM se este estiver em uma das famílias cadastradas no parâmetro FAMILIA_INTEGRACAO.


Se o tipo de valorização do estoque for FIFO.

  • ERP2 envia PEDIDO cadastrado para o ERP1

O pedido recebido no ERP1 vindo do ERP2 estará bloqueado para alteração.

 

Como fazer (opcional)

Descreva os passos que viabilizem a integração.

Exemplo:

Os passos para viabilizar a integração são:

  • No Logix ou no Protheus efetue o cadastro das seguintes informações: Clientes, fornecedores, transportadores, cidades, cotação de moeda e unidades de medida.
  • No Logix cadastrar um novo depositante e efetuar toda a parametrização necessária para a operação de WMS.
  • No Logix cadastrar um novo produto que seja controlado pelo WMS, para o depositante cadastrado anteriormente.
  • No Logix efetuar um processo de recebimento para o produto cadastrado anteriormente, utilizando uma nota fiscal provisória (tipo “A”).
  • No Protheus consultar a nota fiscal de recebimento que foi registrada no Logix, validando as informações recebidas.
  • No Logix efetuar um processamento de regularização fiscal, efetuando a cobertura dos produtos recebidos anteriormente.
  • No Protheus verificar se foi efetuado corretamente o relacionamento entre os dois documentos.
  • No Logix efetuar um processo de expedição para o novo produto cadastrado, até o momento do envio da mensagem de integração de pedido de venda.
  • No Protheus efetuar o faturamento do pedido de venda recebido.
  • No Protheus verificar se a nota fiscal gerada contém todas as informações necessárias para o segmento de operador logístico (armazém geral).
  • No Protheus efetuar a escrituração fiscal das notas fiscais, verificando se as regras da legislação deste segmento foram respeitadas.
  • No Logix é possível consultar o número do pedido de venda gerado para as notas fiscais de retorno simbólico e conta/ordem no programa WMS6333 (Consulta de Documentos). Para os processos de faturamento de serviço o número do pedido está disponível no programa WMS6411 (Movimentos a Faturar).

 

Situações comuns (opcional)

Descreva situações problemáticas comuns que podem ocorrer durante o funcionamento da integração e como solucioná-los. Neste ponto também é importante dar instruções de como reconhecer e investigar problemas que podem vir a ocorrer durante a integração. Se houver, apresente tabelas de códigos e descrições de erros que a integração poderá apresentar.

Este tópico possivelmente será alimentado com as experiências durante o desenvolvimento da integração e poderá ser realimentado durante o uso da integração no cliente.

Exemplo 1:

Tratamento de erros de integração (Produto A)


Erro

Mensagem

Solução

Código do erro

Mensagem exibida

Ação a ser tomada para resolução do erro.


Tratamento de erros de integração (Produto B)

Erro

Mensagem

Solução

Código do erro

Mensagem exibida

Ação a ser tomada para resolução do erro.


 

Exemplo 2:

Quando uma mensagem é enviada do Logix para o Protheus, podem ocorrer situações em que o WebService não estará totalmente funcional. Nestes casos uma mensagem de erro genérica irá aparecer na tela:

Exemplo:

Erro ao enviar a mensagem de Cidade via Integração

Se o arquivo de log for analisado, poderemos ver a falha na comunicação com o sistema destino:

-------------------------------------------------------------------------------

WSCERR044 / Não foi possível POST : URL http://172.16.31.57:8011/ws/FWWSEAI.apw

ADVPL WSDL Client 1.080707 / tst on 20120315 08:49:51

-------------------------------------------------------------------------------


Para resolver este problema, verifique as configurações do sistema de destino, analisando o funcionamento do servidor utilizado para esta comunicação e a habilitação do endereço do WebService. 

Checklist de suporte da aplicação

Crie um check-list de verificação de alguns pontos importantes para o funcionamento e atendimento da integração.

Instalação/Configuração

Relacione itens de verificação para garantir que a integração está corretamente instalada e configurada. Isto não pode ser uma cópia do procedimento de instalação/configuração, mas verificações pontuais que podem remeter aos itens da instalação.


Checklist de Verificações:

Relacione itens de verificações para que o atendente possa:

  • Identificar o funcionamento da integração;
  • Identificar a ocorrências de problemas;
  • Coletar evidências do mau funcionamento relatado pelo cliente;
  • Realizar possíveis ajustes na integração quanto à configuração ou negócio.

Anexos