Source: http://docplayer.com.br/2680953-Manual-de-integracao-de-software-comunicacao-de-contratos-de-arrendamento-e-emissao-de-recibos-de-renda-a-at.html
Timestamp: 2017-08-21 01:40:40+00:00
Document Index: 32354099

Matched Legal Cases: ['Artigo 8', 'artigo 101', 'artigo 101', 'artigo 101', 'artigo 101', 'artigo 101', 'artigo 101']

MANUAL DE INTEGRAÇÃO DE SOFTWARE Comunicação de contratos de arrendamento e emissão de recibos de renda à AT - PDF
MANUAL DE INTEGRAÇÃO DE SOFTWARE Comunicação de contratos de arrendamento e emissão de recibos de renda à AT
Download "MANUAL DE INTEGRAÇÃO DE SOFTWARE Comunicação de contratos de arrendamento e emissão de recibos de renda à AT"
Luca Freire Anjos
1 MAUAL DE ITEGRAÇÃO DE OFTWARE
2 HITÓRICO DE ALTERAÇÕE DATA ALTERAÇÕE 31/07/2015 Criação do documento Av. Eng.º Duarte Pacheco, º, Lisboa Tel: (+351) Fax: (+351)
3 ÍDICE 1 ITRODUÇÃO amespaces usados EQUADRAMETO Comunicação de contratos de arrendamento e emissão de recibos de renda por Webservice ADAPTAÇÃO DO OFTWARE Comunicação por Webservice ETRUTURA DO ERVIÇO DE COMUICAÇÃO DE COTRATO E EMIÃO DE RECIBO À AT (OAP) Pedido OAP Resposta ao pedido OAP AIATURA CERTIFICADO L (CR) Gerar um certificado L Verificar conteúdo do CR gerado Integrar certificado L com a chave privada EDEREÇO ÚTEI Página de produtores de software Página de apoio ao contribuinte Página de gestão de utilizadores GLOÁRIO Av. Eng.º Duarte Pacheco, º, Lisboa Tel: (+351) Fax: (+351)
4 1 Introdução O presente documento descreve os procedimentos e requisitos necessários à comunicação de início de contratos e à emissão de recibos à Autoridade Tributária e Aduaneira (AT). Este documento destina-se a apoiar as entidades ou indivíduos, doravante designados por produtores de software, que desenvolvam e/ou comercializem software para as associações de proprietários e empresas (seus clientes utilizadores do software produzido). Os produtores de software são responsáveis por desenvolver programas que cumpram com os requisitos legais da comunicação de contratos e emissão de recibos e para este efeito devem guiar-se pelas especificações produzidas pela AT. As associações de proprietários e empresas são responsáveis pelo envio de dados do pedido (credenciais, contratos e recibos), uma vez que utiliza as suas credenciais no Portal das Finanças (Utilizador e enha). Estas credenciais só podem ser conhecidas pelos emitentes devendo o software produzido estar preparado para solicitar estas credenciais, sempre que necessário à comunicação dos dados. Complementarmente às credenciais solicitadas, o software deve também estar preparado para solicitar as credenciais do Contribuinte no Portal das Finanças (Utilizador e enha). Cada software é identificado perante a AT através de um Certificado L emitido pelo produtor de software e assinado digitalmente pela AT através de processo de adesão disponível no site e-fatura [6.1]. A AT só aceita estabelecimento de comunicação de dados se for enviado no processo de comunicação, o Certificado L emitido para este efeito. Este certificado apenas garante o estabelecimento da comunicação sendo responsabilidade do produtor de software transmitir corretamente os dados dos seus clientes. 31 de julho de /32
5 1.1 amespaces usados Por uma questão de síntese, a declaração dos namespaces foi omitida dos exemplos e da referência nos capítulos seguintes. ão listados na seguinte tabela, para referência, todos os prefixos de namespaces utilizados. Prefixo amespace Descrição at AT Authentication Extension OAP Envelope pecification wss Web ervices ecurity Policy Language 31 de julho de /32
6 2 Enquadramento A solução apresentada permite a submissão de contratos de arrendamento e a emissão e obtenção de recibos através de webservice. O cumprimento desta obrigação fica ao encargo do próprio Contribuinte. 2.1 Comunicação de contratos de arrendamento e emissão de recibos de renda por Webservice Para efetuar a comunicação por Webservice os programas informáticos tem que estar adaptados de forma a: 1. Respeitar o modelo de dados tal como definido em formato WDL. 2. Utilizar os protocolos de comunicação definidos para a transmissão de dados utilizando este serviço, designadamente o protocolo OAP. 3. Implementar os mecanismos de segurança na transmissão de dados que visam garantir a confidencialidade dos dados, designadamente: a) Comunicação de dados através de canal HTTP, com utilização de certificado L que identifica o produtor de software e que foi previamente assinado pela AT; b) Encriptação da senha dos utilizadores no Portal das Finanças recorrendo a chave pública (RA) do istema de Autenticação; c) Demais mecanismos, definidos em detalhe neste documento para garantir a segurança da transmissão dos dados para a AT. 31 de julho de /32
7 3 Adaptação do software esta secção a AT apresenta as suas recomendações aos produtores de software de forma a alterarem os seus programas informáticos para incluírem a comunicação de contratos, emissão de recibos e obtenção de recibo emitido, via Webservice. 3.1 Comunicação por Webservice Cada produtor de software é responsável por implementar o módulo que vai enviar dados dos contratos, emitir recibos e obter recibos emitidos, que deverá respeitar os seguintes passos: 1. e ainda não tiver efetuado a adesão ao serviço, deverá realizar o processo de adesão à comunicação de contratos e à emissão e consulta de recibos: a) É necessário utilizar o certificado L e submetê-lo para ser assinado pela AT, através do processo de adesão por parte dos produtores de software. 2. O utilizador preenche a declaração no programa informático próprio; a) O programa informático solicita as credenciais dos intervenientes nesta submissão tal como definidas no Portal das Finanças. 3. Com base nos dados da declaração criada no passo n.º 1 e nas credenciais solicitadas no passo n.º 2 deve construir o pedido OAP: a) eguindo o WDL; b) Estes pedidos OAP (Webservice) são compostos pelas seguinte secções, descritas no capítulo 4 - Estrutura do serviço de comunicação de contratos e emissão de recibos à AT (OAP), e que se resumem a: OAP:Header onde se incluem os campos de autenticação dos utilizadores que vão ser responsáveis pela invocação do Webservice (as senhas que vão nesta secção têm que ser cifradas recorrendo à chave pública do sistema de autenticação do portal das finanças); OAP:Body contém os dados do contrato ou recibo; OAP:Fault contém a exceção de autenticação ocorrida ao efetuar o pedido. 4. Estabelecer uma ligação segura em HTTP com o portal das finanças. 5. Processar corretamente o código de resposta devolvido pelo Webservice, que pode ser de três tipos: a) Mensagens de autenticação inválida; b) Mensagens de processamento inválido do contrato ou recibo; 31 de julho de /32
8 c) Registo com sucesso do contrato ou recibo. Para adaptar os programas informáticos é recomendada execução das seguintes fases de implementação: Desenvolvimento Testes Distribuição Produção Fase de Desenvolvimento Para poder iniciar o desenvolvimento, cada produtor de software deve obter junto da AT os elementos necessários para o efeito, designadamente: 1. Obter a chave pública do istema de Autenticação do Portal das Finanças para cifrar a senha do utilizador e certificado L assinado para comunicação com o endereço de testes: É necessário enviar um à AT a solicitar o envio dos mesmos. A mensagem a enviar por deve respeitar o seguinte template: TO: ubject: Obtenção do certificado L para testes e chave pública do sistema de Autenticação - IF <IF> Exmos. enhores, O Produtor de oftware <OME> (IF <IF>) vem por este meio solicitar o envio dos seguintes elementos para desenvolvimento e testes da comunicação de contratos e emissão de recibos via Webservice: Chave pública do istema de Autenticação do PF; Certificado L para comunicação com o endereço de testes de Webservices. Estes elementos serão utilizados por este produtor de software para incluir nos seguintes programas: Designação oftware Certificado AT / DGCI <OFTWARE 1> <CERTIFICADO 1> 31 de julho de /32
9 <OFTWARE > <CERTIFICADO > Aguardamos a vossa resposta. o template anterior, cada produtor de software deve substituir os seguintes elementos pelos seus dados: <IF> - ubstituir pelo IF do produtor de software; <OME> - ubstituir pelo ome do produtor de software. <OFTWARE > - Designação do software <CERTIFICADO > - º de certificado da AT (DGCI se ainda for o caso) 2. Obter o WDL que define a estrutura do pedido OAP a construir para enviar os contratos e emitir os recidos. Para a correta construção do pedido OAP (invocação do Webservice) deve utilizar a informação complementar disponível no capítulo 4 - Estrutura do serviço de comunicação de contratos e emissão de recibos à AT (OAP), onde se detalha a informação que deve constar dos campos do pedido OAP bem como a sua forma de construção. Fase de Testes A AT disponibiliza um endereço de testes para verificação da comunicação de dados à AT de forma a apoiar cada produtor de software na correta disponibilização dos seus programas aos Contribuintes, seus clientes. Para este efeito, a aplicação desenvolvida para a submissão de contratos e emissão de recibos deverá seguir o seguinte procedimento: 1. olicitar as credenciais de utilizador e senha criada para os testes de comunicação de contratos e emissão de recibos (e.g., EHA); 2. Construir o OAP:Body de acordo com o definido no capítulo Pedido OAP; 3. Cifrar a senha e compor o OAP:Header de acordo com o definido na secção OAP:Header do capítulo Pedido OAP; 4. Estabelecer uma ligação HTTP com o seguinte endereço disponibilizado apenas para testes; 5. ubmeter o pedido OAP construído no ponto 3; 31 de julho de /32
10 6. Processar a resposta que o serviço lhe devolve de acordo com as várias hipóteses definidas no capítulo Resposta ao pedido OAP. As respostas são dos seguintes tipos: a) Código de sucesso; b) Erros de autenticação referentes aos campos do OAP:Header; c) Erros nos dados referentes aos campos preenchidos no OAP:Body. Para efeitos de despiste, é disponibilizada uma página de testes de conectividade e exemplos de pedido e resposta OAP para comparação com o programa do produtor de software. Tendo em consideração que se trata do ambiente de testes, existe a possibilidade dos dados existentes neste ambiente poderem ser apagados periodicamente. Fase de Distribuição Depois de confirmarem a correta adaptação do programa informático e antes de distribuir os vossos programas aos vossos clientes é necessário proceder da seguinte forma: 1. Efetuar a adesão ao envio de dados através do formulário disponível em: ite e-fatura» página Produtores de oftware» opção Aderir ao erviço É necessário aceitar os termos e condições do serviço, disponíveis para consulta no formulário; a) Para completar o pedido de adesão é necessário gerar um certificado L de acordo com as instruções disponíveis no capítulo 5 - Assinatura certificado L (CR); b) A AT responde a este pedido por mensagem de contendo o certificado L assinado digitalmente pela AT. 2. Alterar o endereço de comunicação para o endereço de comunicação de dados à AT em ambiente de produção. 3. ubstituir o certificado L utilizado em testes (ponto 4 da Fase de Testes) pelo certificado L de produção emitido no ponto 1 alínea c) desta fase. Depois de concluído este procedimento o(s) vosso(s) programas informáticos estão prontos para serem distribuídos aos vossos clientes. 31 de julho de /32
11 Fase de produção Depois de instalado o programa informático nos computadores dos vossos clientes (Contribuintes) estão em condições para iniciar o envio de contratos e emissão de recibos via Webservice. Por regra, o envio procede da seguinte forma: 1. O utilizador preenche os dados no programa informático; 2. ão obtidas as credenciais dos intervenientes na submissão do pedido, configuradas no programa informático; 3. É construído o pedido OAP e invocado o Webservice, em produção, com os dados do ponto 1 e ponto 2; 4. Programa processa a resposta do serviço e informa o utilizador do sucesso ou solicita ação do utilizador para o caso de erro no envio. 31 de julho de /32
12 4 Estrutura do serviço de comunicação de contratos e emissão de recibos à AT (OAP) esta secção descreve-se informação complementar ao definido no WDL do serviço de comunicação de contratos e emissão de recibos. O pedido é efetuado segundo o protocolo OAP e é constituído por duas secções: a) OAP:Header; b) OAP:Body A primeira secção, o Header, inclui todos os campos de autenticação dos utilizadores que vão ser responsáveis pela invocação do Webservice. Estes utilizadores podem ser o IF do contribuinte declarante com as respetivas permissões. A segunda secção contém os dados da comunicação de contratos e emissão de recibos, os quais se detalham no tópico OAP:Body. O serviço prevê três operações: a) registardadoscontrato, que permite a comunicação dos dados de um contrato de arrendamento à AT; b) emitirrecibo, que permite a emissão de um recibo; c) obterrecibo, que permite obter um recibo emitido. Mais à frente neste capítulo serão explicados os campos envolvidos na invocação de cada uma das operações deste serviço. 31 de julho de /32
13 4.1 Pedido OAP OAP:Header O desenho do Header tem como requisito garantir a confidencialidade dos dados de autenticação e a impossibilidade de reutilização dos mesmos em ataques Man-in-the-middle (MITM). Por este motivo, só serão aceites invocações que respeitem os seguintes procedimentos de encriptação. O OAP:Header é construído de acordo com o standard W-ecurity, definido pela OAI e recorrendo à definição do Username Token Profile 1.1, também definido pela mesma organização. a seguinte tabela, detalha-se a forma de construção de cada campo do W-ecurity, e de acordo com as necessidades de segurança específicas do sistema de autenticação do portal das finanças. Parâmetro Descrição Obrig. 1 Tipo Dados 2 H.1 - Utilizador (Username) Identificação do utilizador que vai submeter os dados, composto da seguinte forma e de acordo com a autenticação do portal das finanças: <IF do emitente>/<userid> Exemplos possíveis: /0000 (utilizador principal) /1 (subutilizador n.º 1) /0002 (subutilizador n.º 2) /1234 (subutilizador n.º 1234) H.2 - once Chave simétrica gerada por autenticação para cifrar o conteúdo dos campos H.3 - Password e H.4 - Created. Cada autenticação deverá conter esta chave gerada aleatoriamente e a qual não pode ser repetida entre headers de autenticação (wss:ecurity) e entre pedidos. Para garantir a confidencialidade, a chave simétrica tem de ser cifrada com a chave pública do istema de Autenticação de acordo com o algoritmo RA e codificada em Base 64. A chave pública do sistema de autenticação do portal das finanças deve ser obtida por solicitação própria e através do endereço de e- mail conforme o descrito na secção Fase de Desenvolvimento do capítulo 3.1. (base64) 1 Obrigatório: im; ão. 2 A validar na especificação WDL (Web ervice Definition Language) do serviço 31 de julho de /32
14 O campo é construído de acordo com o seguinte procedimento once : Base64( C RA, Kpub ( Ks)) K := array de bytes com a chave simétrica de 128 bits, produzida de acordo com a norma AE. C RA,KpubA := Função de cifra da chave simétrica com o algoritmo RA utilizando a chave pública do sistema de autenticação (K puba). Base64 := Codificação em Base 64 do resultado. A H.3 - Password O campo Password deverá conter a senha do utilizador / subutilizador, a mesma que é utilizada para entrar no Portal das Finanças. Esta senha tem de ser cifrada através da chave simétrica do pedido (ver campo once) e codificado em Base64. Password : Base64( C AE, ECB, PKC5Padding K s ( enhapf)) enhapf := enha do utilizador definido no campo H.1 - Username; AE, ECB, PKC5Padding C Ks := Função de cifra utilizando o algoritmo AE, Modelo ECB, PKC5Padding e a chave simétrica do pedido (K ). Base64 := Codificação em Base 64 do resultado. Adicionalmente este campo deverá conter o atributo Digest. Este atributo deverá conter um digest da password, seguindo a seguinte fórmula: Digest : Base64( C HA 1( K s AE, ECB, PKC5Padding K s Created enhapf))) K s+created+enhapf := ão os bytes dos três campos concatenados; HA-1 := Função de cáluculo de digest usando o algoritmo HA-1; AE, ECB, PKC5Padding C Ks := Função de cifra utilizando o algoritmo AE, Modelo ECB, PKC5Padding e a chave simétrica do pedido (K ). Base64 := Codificação em Base 64 do resultado. ( (base64) H.4 - Data de sistema (Created) O campo Created deverá conter a data e hora de sistema da aplicação que está a invocar o webservice. Esta data é usada para validação temporal do pedido, pelo que é (base64) 31 de julho de /32
15 crucial que o sistema da aplicação cliente tenha o seu relógio de acordo com a hora legal. ugere-se a sincronização com o Observatório Astronómico de Lisboa: A zona temporal deste campo deverá estar definida para UTC e formatado de acordo com a norma IO 8601 tal como é definido pelo W3C: e.g.: T19:20:30.45Z Este campo não deve ser cifrado. Created : Timestamp Timestamp := data hora do sistema (UTC). Autenticação O sistema de autenticação do Portal das Finanças estendeu o protocolo de autenticação atual para permitir a autenticação de mais de um contribuinte. Esta nova versão, versão 2, é compatível com o uso da versão anterior. Isto é, existindo a necessidade de autenticação de apenas um utilizador, é aceite o uso de qualquer uma das versões de autenticação. Para a utilização desta versão deverá ser utilizado o atributo com o valor 2, tal como os exemplos que se seguem o demonstram. Exemplos OAP:Header Como resultado da aplicação das regras de construção anteriores será produzido um header de pedido OAP tal como o seguinte exemplo: <:Header> <wss:ecurity xmlns:wss= at:version= 2 > <wss:usernametoken> <wss:username> </wss:username> <wss:password Digest= AAAAAA== >AAAAAAAAAAAAAAAA=</wss:Password> <wss:once> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA </wss:once> <wss:created> t20:45:05.424z</wss:created> </wss:usernametoken> </wss:ecurity> </:Header> 31 de julho de /32
16 OAP:Body O corpo do pedido é distinto conforma a operação que foi solicitada. As secções seguintes apresentam os diferentes OAP:Body. Operação registardadoscontrato - elemento registardadoscontratorequest De seguida são apresentados os campos para a operação de registo dos dados de um contrato de arrendamento, e que compõem o elemento registardadoscontratorequest. Parâmetro Descrição Obrig. 3 Tipo Dados IF declarante do contrato (nifdeclarante) IF declarante Preencher com o IF do declarante dos dados de um contrato. int 1.2 Referência (referencia) Referência Utilize este campo para atribuir uma identificação pessoal ao contrato. 1.3 Tipo (tipo) Tipo Indica o tipo do contrato. Valores possíveis: 1. ARRED (Arrendamento) 2. UBARR (ubarrendamento) 3. PROME (Promessa de arrendamento com entrega do bem locado) 4. CEDEC (Cedência de uso do prédio ou de parte dele, que não arrendamento) 5. ALUGUE (Aluguer de maquinismos e mobiliário instalados no imóvel locado) 1.4 Finalidade (finalidade) Finalidade Indica a finalidade do contrato. Valores possíveis: 1. H_PERM (Habitacional permanente) 2. H_PER (Habitacional não permanente) 3. _HABI (ão habitacional) 3 Obrigatório: im; ão. 4 A validar na especificação WDL (Web ervice Definition Language) do serviço. 31 de julho de /32
17 1.5 Data de início (datainicio) Data de início Indica a data de início do contrato date 1.6 Data de termo (datatermo) Data de termo Preencher nos casos em que o contrato prevê uma data de fim. date 1.7 Renovável (renovavel) Renovável Assinalar nos casos em que no contrato esteja prevista a possibilidade de renovação. boolean 1.8 Lista de imóveis (imoveis) Imóvel (imovel) Código do distrito (distrito) Distrito Indicar o código do distrito do imóvel. Exemplos possíveis: Código do concelho (concelho) Concelho Indicar o código do concelho do imóvel. Exemplos possíveis: Código da freguesia (freguesia) Freguesia Indicar o código da freguesia do imóvel. Exemplos possíveis: Tipo (tipo) Tipo do imóvel Indicar se o tipo de imóvel é urbano ou rústico. Valores possíveis: 1. U (Urbano) 2. R (Rústico) 31 de julho de /32
18 ecção (seccao) ecção do imóvel Indicar a secção do imóvel Artigo (artigo) Artigo do imóvel Indicar o artigo do imóvel. Exemplos possíveis: (Artigo nº 2321) 2. P123 (Artigo provisório nº 123) Fração ou parte (fracao) Fração ou parte do imóvel Indicar a fração/parte do imóvel Árvore colonia (arvcol) Árvore colonia do imóvel Indicar a árvore colonia do imóvel Código postal (codigopostal) Código postal Indicar o código postal do imóvel. short Exemplos possíveis: Unidade funcional (unidadefuncional) Unidade funcional Indicar a unidade funcional do imóvel. short Exemplos possíveis: Localidade (localidade) Localidade Indicar a localidade do imóvel Morada (morada) Morada Indicar a morada ou localização do imóvel úmero/lote (numerolote) úmero/lote Indicar o número/lote do imóvel. 31 de julho de /32
19 Andar (andar) Andar Indicar o andar do imóvel Parte arrendada (partearrendada) Parte arrendada Indicar a parte arrendada do imóvel Parte comum (partecomum) Parte comum Assinalar quando o contrato é relativo a uma parte comum do imóvel em propriedade horizontal. boolean Bem omisso (bemomisso) Bem omisso Assinalar quando o imóvel não está inscrito na matriz predial. boolean 1.9 Lista de locadores (locadores) Locador (locador) IF (nif) IF int Indicar o IF do locador Quota Parte (quotaparte) Quota parte Indicar a quota parte do locador. Exemplos possíveis: / Regime de casamento (regimecasamento) Regime de casamento Indicar o regime de casamento do locador. Valores possíveis: 1. CO_GER (Comunhão geral) 2. CO_ADQ (Comunhão de adquiridos) IF cônjuge (nifconjuge) IF cônjuge Indicar o IF cônjuge do locador. int 31 de julho de /32
20 Benefício (beneficio) Benefício Indicar o benefício do locador. Valores possíveis: 1. BF001 (O Estado, as Regiões Autónomas, as autarquias locais e as associações e federações de municípios de direito público, e seus serviços, estabelecimentos e organismos, compreendidos os institutos públicos, que não tenham carácter empresarial) 2. BF002 (Pessoas colectivas de utilidade pública administrativa e de mera utilidade pública) 3. BF003 (As instituições particulares de solidariedade social e entidades a estas legalmente equiparadas) 4. BF004 (As instituições de segurança social) 5. BF005 (Zona Franca da Madeira e de anta Maria - Entidades licenciadas nas Zonas ou concessionárias da exploração da Zona) 6. BF006 (ociedades de agricultura de grupo) 7. BF007 (Universidade Católica Portuguesa) 8. BF008 (Observatório europeu da droga e da toxicodependência) 9. BF009 (Banco Inter Americano de Desenvolvimento) 10. BF010 (Programa Polis) 11. BF011 (Partidos políticos) 12. BF012 (Código da Insolvência e da Recuperação de Empresas - Transmissões integradas em Planos de insolvência ou de pagamentos ou no âmbito da liquidação da massa insolvente) 13. BF013 (Instituições de ensino superior público) 14. BF014 (FIIAH / IIAH - Artigo 8 - aquisição pelo FIIAH / IIAH) 15. BF015 (Cooperativas) 16. BF016 (Arrendamento Rural) 1.10 Lista de locatários (locatarios) Locatário (locatario) IF (nif) IF int Indicar o IF do locatário, caso português Documento de Identificação (docidentificacao) Documento de Identificação Indicar o documento de identificação do locatário, caso estrangeiro. 31 de julho de /32
21 ome (nomeestrangeiro) ome Indicar o nome do locatário, caso estrangeiro País (pais) Pais Indicar o código IO de 2 letras do país do locatário Retenção na fonte (retencaofonte) Retenção na fonte Indicar a retenção na fonte caso se trate de um locatário português. Valores possíveis: 1. RIR01 (À taxa de 25% - artigo 101.º, n.º 1, al. e) do CIR) 2. RIR02 (À taxa de 20% (Açores DLR n.º 2/99/A, de 20/01, após )) 3. RIR03 (Dispensa de retenção - artigo 101.º-B, n.º 1, do CIR) 4. RIR04 (em retenção - artigo 101.º, n.º 1, do CIR) 1.11 Valor da renda (valorrenda) Valor da renda Indicar a renda atual. e o arrendamento tiver duração superior a um mês, indicar o valor da renda mensal. e o arrendamento tiver duração inferior a mês, indicar o valor da renda desse período decimal 1.12 Valor das despesas (valordespesas) Valor das despesas Indicar as despesas que são da responsabilidade do locador mas que por acordo contratual são suportadas pelo locatário, acrescendo ao valor da renda. Exemplo: Mensalidade do condomínio. decimal 1.13 Valor da renda máxima (valorrendamaxim a) Valor da renda máxima Indicar a renda mais elevada, quando prevista no contrato. decimal 1.14 Período de renda (periodorenda) Período de renda Indicar se o período da renda é mensal ou inferior a um mês. Exemplos possíveis: 1. MEAL (Mensal) 2. MEORM (Inferior a um mês) 31 de julho de /32
22 1.15 Lista de locadores do contrato anterior (locadoresprevios) Locador do contrato anterior (locadorprevio) IF (nif) IF int Indicar o IF do locatário Observações (observacoes) Observações Indicar informações ou comentários relevantes sobre o contrato para além das indicadas previamente IF autorizado (nifautorizado) IF autorizado Indicar o IF do terceiro autorizado a cumprir as obrigações decorrentes do contrato. int Operação emitirrecibo elemento emitirreciborequest esta secção são definidos os campos para a operação de emissão de recibos, e que compõem o elemento emitirreciborequest. Parâmetro Descrição Obrig. 5 Tipo Dados úmero do contrato (numerocontrato) úmero do contrato Preencher com o número do contrato. long 1.2 IF emitente (nifemitente) IF emitente Indicar o IF emitente do recibo. int 1.3 Lista de locadores (locadores) Locador (locador) IF (nif) IF int Indicar o IF do locador. 1.4 Lista de locatários (locatarios) 5 Obrigatório: im; ão. 6 A validar na especificação WDL (Web ervice Definition Language) do serviço 31 de julho de /32
23 1.4.1 Locatário (locatario) IF (nif) IF int Indicar o IF do locatário, caso português Documento de Identificação (docidentificacao) Documento de Identificação Indicar o documento de identificação do locatário, caso estrangeiro País (pais) País Indicar o código IO de 2 letras do país do locatário Retenção na fonte (retencaofonte) Retenção na fonte Indicar a retenção na fonte caso se trate de um locatário português. Valores possíveis: 5. RIR01 (À taxa de 25% - artigo 101.º, n.º 1, al. e) do CIR) 6. RIR02 (À taxa de 20% (Açores DLR n.º 2/99/A, de 20/01, após )) 7. RIR03 (Dispensa de retenção - artigo 101.º-B, n.º 1, do CIR) 8. RIR04 (em retenção - artigo 101.º, n.º 1, do CIR) 1.5 Tipo (tipo) Tipo Indica o tipo do recibo. Valores possíveis: 1. ARRED (Arrendamento) 2. UBARR (ubarrendamento) 3. CEDEC (Cedência de uso do prédio ou de parte dele, que não arrendamento) 4. ALUGUE (Aluguer de maquinismos e mobiliário instalados no imóvel locado) 1.6 Data de início (datainicio) Data de início Indicar a data de início do período a que respeita a renda. date 31 de julho de /32
24 1.7 Data de fim (datafim) Data de fim Indicar a data de fim do período a que respeita a renda. date 1.8 Tipo de importância (tipoimportancia) Tipo de importância Indicar se a importância recebida é referente a uma renda, caução ou adiantamento. Valores possíveis: 1. REDAC (Renda) 2. CAUCAO (Caução) 3. ADIAT (Adiantamento) 1.9 Valor (valor) Valor decimal Indicar o valor. Operação obterrecibo elemento obterreciborequest esta secção são definidos os campos para a operação de obtenção de recibos, e que compõem o elemento obterreciborequest. Parâmetro Descrição Obrig. 7 Tipo Dados úmero do contrato (numerocontrato) úmero do contrato Preencher com o número do contrato. long 1.2 úmero do recibo (numerorecibo) úmero do recibo Preencher com o número do recibo. long 7 Obrigatório: im; ão. 8 A validar na especificação WDL (Web ervice Definition Language) do serviço 31 de julho de /32
25 4.2 Resposta ao pedido OAP OAP:Body O corpo da resposta ao pedido é distinto conforma a operação que foi solicitada. As secções seguintes apresentam os diferentes OAP:Body. Operação registardadoscontrato dados do elemento registardadoscontratoresponse esta secção são apresentados os campos que compõem o elemento registardadoscontratoresponse. Este campo define a resposta ao pedido de comunicação dos dados de um contrato. Parâmetro Descrição Obrig. 9 Tipo Dados Código de resposta (codigo) Código do resultado da invocação desta interface. e a resposta for zero, a operação foi bem sucedida. e for um número diferente de zero, significa que a operação não foi bem-sucedida. int Código de resposta (serviço): -1 O contrato apresenta um ou mais erros 0 - "Contrato submetido com sucesso." 99 - "Erro interno." 1.2 Mensagem de resposta (mensagem) Mensagem do resultado da invocação desta interface. 1.3 úmero de contrato (numerocontrato) úmero do contrato, caso criado. long 1.4 Erros no registo (erros) Erro (erro) Campo com erro (campo) Campo do formulário que deu origem ao erro Mensagem de erro Mensagem de erro. 9 Obrigatório: im; ão. 10 A validar na especificação WDL (Web ervice Definition Language) do serviço 31 de julho de /32
26 (mensagem) Operação emitirrecibo dados do elemento emitirreciboresponse De seguida são apresentados os campos que compõem o elemento emitirreciboresponse. Este campo define a resposta ao pedido à operação de emissão de um recibo. Parâmetro Descrição Obrig. 11 Tipo Dados Código de resposta (codigo) Código do resultado da invocação desta interface. e a resposta for zero, a operação foi bem sucedida. e for um número diferente de zero, significa que a operação não foi bem-sucedida. int Código de resposta (serviço): -1 O recibo apresenta um ou mais erros e/ou alertas." 0 - "Recibo emitido com sucesso." 99 - "Erro interno." 1.2 Mensagem de resposta (mensagem) Mensagem do resultado da invocação desta interface. 1.3 úmero de recibo (numerorecibo) úmero do recibo, caso criado. long 1.4 Erros na emissão do recibo (erros) Erro (erro) Campo com erro (campo) Campo do formulário que deu origem ao erro Mensagem de erro (mensagem) Mensagem de erro. 11 Obrigatório: im; ão. 12 A validar na especificação WDL (Web ervice Definition Language) do serviço 31 de julho de /32
MANUAL DE INTEGRAÇÃO DE SOFTWARE HISTÓRICO DE ALTERAÇÕES DATA ALTERAÇÕES 03-02-2015 Criação do documento Av. Eng.º Duarte Pacheco, 28-18.º, Lisboa Tel: (+351) 21 383 4200 Fax: (+351) 21 383 4646 Email:
MANUAL DE INTEGRAÇÃO DE SOFTWARE. Comunicação dos Documentos de Transporte à AT
MANUAL DE INTEGRAÇÃO DE OFTWARE HI TÓ RI CO DE ALTERAÇ Õ E DATA ALTERAÇ Õ E 19-02-2013 Criação do documento 21-02-2013 Alteração das descrições do OAP:Body. 14-03-2013 Incluído código de resposta ao Webservice
MANUAL DE INTEGRAÇÃO DE SOFTWARE HI STÓ RI CO DE ALTERAÇ Õ ES DATA ALTERAÇ Õ ES 19-02-2013 Criação do documento 21-02-2013 Alteração das descrições do SOAP:Body. 14-03-2013 Incluído código de resposta
MANUAL DE INTEGRAÇÃO DE SOFTWARE. Comunicação das Faturas à AT
MANUAL DE INTEGRAÇÃO DE SOFTWARE HISTÓRICO DE ALTERAÇÕES DATA ALTERAÇÕES 04-12-2012 Corrigido exemplo de data de sistema que se deve incluir no Header de segurança dos pedidos SOAP. Quando a data se refere
MANUAL DE INTEGRAÇÃO DE SOFTWARE HI STÓ RI CO DE ALTERAÇ Õ ES DATA ALTERAÇ Õ ES 04-12-2012 Corrigido exemplo de data de sistema que se deve incluir no Header de segurança dos pedidos SOAP. Quando a data
28-11-2012 Comunicação das Faturas à AT para cumprimento do disposto no Decreto-Lei n.º 198/2012 de 24 de agosto 0. Introdução Os elementos da fatura emitida devem ser comunicados à AT, por uma das seguintes
MANUAL DE INTEGRAÇÃO DE SOFTWARE Comunicação do Inventário de Existências à AT HISTÓRICO DE ALTERAÇÕES DATA ALTERAÇÕES 24-11-2014 Elaboração do manual de comunicação do Inventário de Existências à AT.