Decreto Executivo n.º 74/19

São aprovadas as Regras e Requisitos para Validação de

Sistemas de Processamento Electrónico de Facturação dos

Contribuintes, anexo ao presente Diploma e que e dele parte

integrante.

Aplicam-se subsidiariamente ao presente Diploma o

Código Geral Tributário, o Código Aduaneiro, Código das

Execuções Fiscais e demais legislação tributária em vigor.

As dúvidas e omissões resultantes da interpretação e aplicação do presente Diploma são resolvidas pelo Ministro das

Finanças.

O presente Diploma entra em vigor na data da sua

publicação.

Publique-se.

Luanda, a 1 de Março de 2019.

O Ministro, Archer Mangueira.

ANEXO!

Requisitos técnicos

Para efeito de validação, os sistemas de processamento

electrónico de facturação dos contribuintes devem garantir:

conformidade com o Decreto Presidencial n.º 312/18, de 21

de Dezembro, e o respectivo esquema de validação de dados

«XSD»;

cifra assimétrica e de uma chave privada de conhecimento

exclusivo dos respectivos fabricantes;

local ou remotamente, permitam alterar, de forma directa ou

indirecta, a informação de natureza fiscal, sem gerar evidência agregada a informação original;

pelos sistemas de processamento electrónico de facturação

devem ser observados os seguintes requisitos:

documentos emitidos com eficácia externa (com

excepção dos recibos), nomeadamente:

As facturas e documentos rectificativos;

As guias de transporte, guias de remessa e quaisquer outros documentos que constituam

documento de transporte; e

Quaisquer outros documentos, independentemente

da sua designação, susceptíveis de apresentação ao cliente para conferência de entrega

de mercadorias ou da prestação de serviços,

nomeadamente as designadas consultas de

mesa.

anterior deve obedecer e estar em conformidade

com os requisitos definidos no n.º 34 do presente

anexo (s);

documentos rectificativos de factura, devem

conter de forma evidente a sua natureza e, se susceptíveis de apresentação ao cliente, incluindo

os que devam constar nas tabelas 4.2, 4.3 e 4.4

do SAF-T(AO), conter a expressão «Este documento não serve de factura»;

mercadorias, documentos de conferência de

entrega de mercadorias ou de prestação de serviços susceptíveis de apresentação ao cliente, que

tiveram origem noutros documentos emitidos,

designadamente, facturas, guias de movimentação de mercadorias, consultas de mesa ou

outros documentos susceptíveis de apresentação ao cliente, devem conter a identificação

desses documentos, na estrutura Referência ao

documento de origem (OrderReferences) das

tabelas 4.1a 4.3, consoante o caso;

conter a identificação do (s) documento (s) rectificado (s) na estrutura Referências a facturas

(References) da tabela 4.1;

JJ No caso de utilização do programa em modo de formação, os documentos assim emitidos deverão,

em série específica, indicar sempre no cabeçalho,

os dados identificativos da empresa de software,

ao invés dos da empresa cliente e terão ainda de

ter impresso a expressão: «Documento emitido

para fins de Formação», ainda que impressos em

papel timbrado do cliente;

£) Todos os tipos de documentos, identificados através

das respectivas designações, deverão ser emitidos cronologicamente em uma ou mais série,

convenientemente referenciadas, de acordo com

as necessidades comerciais, devendo ser datados

e numerados de forma progressiva e contínua,

dentro de cada série, por um período não inferior

a um ano fiscal;

utilizados caracteres que violem o esquema de

validação ou possam ser interpretados como

operadores de XML. Não pode constar da

sequência numérica qualquer outra informação

(como por exemplo, o ano ou o numero do

terminal informático, etc.) que, a existir, deverá

sempre constar da identificação da série;

específico de cada um dos estabelecimentos e

ou programa (s), e nunca pode ser repetido no

mesmo contribuinte, para o mesmo tipo de documento, de modo a identificar univocamente cada

documento emitido, mesmo que os documentos

sejam emitidos por mais do que um programa de

facturação;

utilização de uma série for descontinuada, a aplicação deve inibir a sua utilização, não podendo,

de forma aleuma, apagar qualquer informação

relativa a mesma;

em pré-visualização poderá ser impresso em

momento anterior a sua finalização e respectiva

assinatura;

Já assinado seja alterada qualquer informação

fiscalmente relevante, designadamente os campos definidos nas alíneas e) e &) do n.º 34 do

presente anexo.

documentos os sistemas de processamento electrónico de

facturação observem os seguintes requisitos:

circulação, valorados ou não, documentos

emitidos para conferência, entre outros, deverá

sempre ser gerada uma assinatura através do

algoritmo RSA com base na informação relativa

ao documento no ponto 34 do presente anexo;

gravada na base de dados do sistema de processamento electrónico de facturação (que não

pode estar encriptada e deve ser mantida durante

o prazo de arquivo legal), com uma associação

directa ao registo integral do documento original;

(números inteiros sequenciais) da chave privada

que foi utilizada para gerar a assinatura do respectivo documento, nos termos da alínea £) do

n.º 34 do presente anexo;

de processamento electrónico de facturação só

pode ser realizada pelo fabricante apos comunicação a AGT através da Declaração Modelo 8 e

respectivo envio «upload» da respectiva chave

pública;

consideração o Hash do último documento emitido da mesma série/tipo. No caso da gravação

de um primeiro documento de uma série/tipo

de documento de facturação, o campo aplicável

Chave do documento (Hash) das tabelas 4.1 a

caso de utilização de séries plurianuais, no início

de cada exercício, o primeiro documento poderá

ser assinado tendo em consideração o Hash do

último documento emitido da mesma série/tipo,

no exercício fiscal anterior;

SO valor a considerar nos campos Total do documento com impostos (GrossTotal) das tabelas

movimentação de mercadorias ou documentos

de conferência e o que constar na base de dados,

independentemente do modelo utilizado na sua

impressão, valorado ou não. Na ausência de

valor na base de dados, o referido campo deve

ser preenchido com «0.00» (sem aspas) e assim

considerado aquando da assinatura;

£) Caso a emissão do documento seja realizada em

moeda estrangeira, o valor a assinar deve ser o

contravalor em AOA uma vez que vai ser este o

valor a exportar no ficheiro SAF-T(AO).

de documentos os sistemas de processamento de facturação

devem observar os seguintes requisitos:

poderão ser impressos depois de devidamente

identificados nos termos dos requisitos constantes no n.º 34 do presente anexo;

documento electrónico enviado deve conter

obrigatoriamente quatro caracteres da assinatura [campos Chave do documento (Hash) das

tabelas subordinadas da tabela 4 -Documentos

comerciais (Source Documents) do SAF-T (AO)]

correspondentes as posições 1.º, 11.º, 21.º, e 31º

e separado por um «-» (hífen) a expressão Processado por programa validado n.º «Numero do

certificado atribuído pela AGT»/AGT.

Exemplo: “PbRc-Processado por programa val1-

dado n.º 0000/AGT” (sem aspas);

validada fiscalmente, impresso ou enviado por

via electrónica, não susceptível de ser assinado

nos termos do n.º 5 do presente anexo, nomeadamente os recibos, deve conter impressos

obrigatoriamente a expressão — Emitido por

programa validado n.º «Numero do certificado

atribuído pela AGT/AGT. Exemplo: «Emitido

por programa validado n.º 0000/AGT»(sem

aspas);

impressão conter a data no formato «AAAA-

-MM-DD» ou «DD-MM-AAAA» (sem aspas);

entregues a clientes que não facultem a sua identificação fiscal (consumidores finais), deverá ser

inutilizada a correspondente linha do NIF do

adquirente ou impressa a expressão «Consumidor finab> (sem aspas);

Quando necessário, serão utilizados documentos

rectificativos de facturas (notas de debito e notas

de crédito, como documentos de correcção de

operações de compra e venda, cuja forma, conteúdo e finalidade devem ser respeitados. Os

valores negativos apenas poderão ser impressos

nos casos de anulação de registos que já integram

o documento ou para acerto de estimativas nas

prestações de serviços continuadas. O valor negativo nunca poderá ser superior ao valor positivo

da mesma rubrica ou serviço em cada factura.

Caso o acerto, por rubrica, seja superior ao valor

positivo, estamos perante uma regularização que

obriga a emissão da respectiva nota de crédito;

£) A menção de franquias, valores de garantia ou

retenções na fonte devem constar de campos

próprios, desenvolvidos para o efeito na aplicação informática, cuja descrição não seja passível

de modificação. Estes montantes não terão qualquer influência nos totais do documento emitido

devendo ser referidos apos o apuramento do total

do documento com impostos (campo GrossTotal

das tabelas 4.1 a 4.4). Em circunstância aleuma

podem ser criados tipos de produto ou serviços

ou utilizar a tabela de produtos/serviços (Product) para este fim;

qualidade, através da expressão «Copia do

documento originab> (sem aspas), sem prejuízo

de outras que lhe sejam aplicáveis;

non.º 8 do presente anexo, deverão conter, quando

impressos, a expressão — «Copia do documento

originab> e separada por hífen os elementos refetidos no ponto 11) da alínea e) do n.º 8 do presente

anexo, com excepção do elemento relativo ao

HashControl,

Exemplo: Cópia do documento original — FTM

abc/089

quando impressos, a expressão — «Copia do

documento original» e separada por hífen os

elementos referidos no respectivo ponto 11) da

aliena e), com excepção do elemento relativo ao

HashControl;

Exemplo: Cópia do documento original — FTD

XY2019B/092

anexo, quando na sua impressão resultar mais

do que uma página, devem exibir em todas elas

a designação do tipo de documento, a respectiva

numeração de acordo com a alínea d) (do presente

numero), os valores acumulados (transportados

e a transportar), o respectivo número de página e

o número total de páginas. Os apuramentos globais de base tributável, apuramento de impostos

e total do documento, quando existirem, devem

constar exclusivamente na última página;

1!) Se para a impressão dos documentos referidos

no n.º 4 do presente anexo for utilizado papel

pré-impresso, a aplicação deve assegurar a

impressão de todos os elementos fiscalmente

relevantes incluindo as menções obrigatórias, os

elementos identificativos do sujeito passivo emitente e a natureza do documento. Não se inclui

neste contexto a impressão de logotipos;

de bens ou prestação de serviços se encontrem

isentos de imposto, deve exibir a expressão

legalmente prevista que confere a isenção ou,

na sua ausência, o normativo legal aplicável.

Caso não conste o motivo de isenção na linha

respectiva, deverá utilizar um qualquer tipo de

referenciação que possibilite a associação da

linha isenta ao respectivo motivo. O mesmo e

válido para associar qualquer taxa de imposto ao

respectivo produto/serviço;

preservar o seu conteúdo original, ainda que

deva conter qualquer expressão que indique não

se tratar de um original. Assim, por exemplo, se

o domicílio ou denominação de um cliente for

alterado na base de dados, a reimpressão de um

documento deve respeitar os domicílios e denominação originais.

base de dados do sistema de processamento de facturação,

originários de outras aplicações informáticas devem ser

observados os seguintes requisitos:

dos contribuintes, nomeadamente a facturação

em sistemas descentralizados ou em sistemas

móveis (as chamadas soluções de mobilidade),

devem ser tidas em conta regras com vista a

definição das condições de integração de informação entre diferentes sistemas de facturação.

Nestes termos, a aplicação integradora não deve

processar qualquer recálculo ou modificação do conteúdo dos documentos integrados

provindos de outros sistemas, respeitando

inclusive a identificação única dos documentos (fmvoiceNo, DocumentNumber ou

PaymentRefNo), com excepção do mencionado nos pontos seguintes;

e, neste caso, da responsabilidade das soluções

originais (soluções integradas);

facturação, de movimentação de mercadorias ou

de qualquer outro documento susceptível de ser

entregue ao cliente para conferência de entrega

de mercadorias ou de prestação de serviços não

pode conter documentos com diferentes origens

(exemplo: conter documentos criados no sistema e importados de um sistema externo numa

mesma série/tipo de documento de facturação).

deve:

Integrar os documentos provenientes de outros

sistemas, na séries/tipos de documentos originais, distintas e autónomas das que utiliza

para a emissão própria, nas correspondentes tabelas de documentos comerciais (4.1,

entendidos como cópias do documento original, nessas tabelas;

Colocar a informação relativa ao campo Chave

do documento (Hash) igual a que foi gerada

no sistema emissor, nas correspondentes

tabelas 4.1 a 4.3 em que e integrado o documento, isto e, devem ser iguais, no sistema

integrador e integrado;

Preencher os campos Origem do documento

(SourceBilling) das tabelas 4.1 a 4.3, consoante o caso, com o valor «D> (sem aspas);

Preencher o campo Chave de controlo (Hash

Control), das tabelas 4.1 a 4.3, consoante o

caso, com o número do certificado com o qual o

documento foi assinado no sistema original e a

respectiva versão da chave;

O formato da informação a registar, nos campos Chave de controlo (HashControl) das

tabelas 4.1 a 4.3, nos termos da alínea anterior, resultará da concatenação do número do

certificado original + um ponto + versão da

chave privada utilizada na assinatura original

respectivamente dos campos Chave do documento (Hash) das mencionadas tabelas 4.1 a

No caso da informação a integrar provir de programa não validado pela AGT, o valor do

campo Chave de controlo (HashControl) das

tabelas 4.1 a 4.3, aplicável ao tipo de informação, deve ser a menção «Não Validado

pela AGT» (sem aspas). Já o valor do campo

(Hash) respectivo deve ser «O» (zero).

Os documentos nestas condições não devem ser reimpressos pela aplicação integradora.

autorizadas, nos casos de inoperacionalidade dos sistemas

de processamento de facturação, devem ser observados os

seguintes requisites:

rectificativos e documentos de transporte,

processados manualmente deve realizar-se no

programa validado em série específica, de periodicidade anual ou superior e com numeração

sequencial própria, iniciada no n.º 1;

do mesmo tipo, que recolha todos os elementos do

documento manual emitido, com observância dos

requisitos definidos no n.º 34 do presente anexo;

corresponde à data do documento manual sendo

de todo o interesse que se criem campos distintos, de preenchimento obrigatório, um para

acolher a identificação da série manual e o outro

para o número manual, por forma a obviar lapsos

na recolha deste tipo de documentos, designadamente, da série. Podem ser criadas tantas série,

quantas as existentes nos documentos manuais

ou apenas uma única série.

caso, com o valor «M>» (sem aspas).

Control) das tabelas 4.1 e 4.2, consoante o caso,

deve ser aposta a seguinte informação:

e separado por um «-» (hífen);

sigla constante do campo Tipo do documento

(ImvoiceIyvpe ou MovementType), correspondente ao respectivo tipo de documento,

seguida da letra M; um espago; a série do

documento manual; o caracter«/»; o número

do documento manual.

Exemplo: 1-FTM ab/0001, sendo «ab/0001» a

série/número do documento manual.

) Para referenciar um documento manual recolhido

na aplicação, deve ser utilizada a série e o

número do documento manual original, e não a

identificação única do documento (finvoiceNo ou

DocumentNumber) atribuído pela aplicação ao

documento recuperado. (Exemplo: A emissão de

uma nota de crédito deve referenciar o número

da factura original, emitida de modo manual.)

£) Quando, houver necessidade de integrar outros

tipos de documentos manuais, utilizar-se-ão os

campos aplicáveis da tabela que os enquadra,

procedendo de maneira idêntica a já referida nos

números anteriores.

(backup), quando houver necessidade de reposição de dados

por inoperacionalidade do sistema, devem ser observados os

seguintes requisitos:

do programa, devem ser encerradas as séries em

utilização e criadas novas, para prosseguir com

a emissão de documentos, apos a reposição da

última cópia de segurança efectuada;

constam da cópia de segurança reposta, deve

realizar-se no programa certificado, através dos

duplicados desses documentos, em série específica anual e com numeração sequencial própria,

iniciada no n.º 1;

do mesmo tipo do duplicado que recolha todos

os elementos desse documento emitido, com

observância dos requisitos definidos no n.º 34 do

presente anexo;

das tabelas 4.1 a 4.2, consoante o caso, deve ser

preenchido com o valor «MD (sem aspas);

Control) das tabelas 4.1 e 4.2, consoante o caso,

deve ser aposta a seguinte informação:

e separado por um «-» (hífen);

sigla constante do campo Tipo do documento

(ImoiceType ou MovementType conforme

aplicável), que deve corresponder ao tipo de

documento a recuperar através do duplicado,

seguida da letra D; um espago e a identifi-

cação única do documento (InvoiceNo ou

DocumentNumber, consoante o caso).

Exemplo: 1-FTD KM2019A/0099, sendo

«KM2019A/0099»a identificação única do

documento integrado.

fi Nas séries de recuperação de dados, a data do

documento corresponde a do duplicado do

documento. É de todo o interesse que se criem

campos distintos, de preenchimento obrigatório,

para acolher o código interno do tipo de documento, série e número do duplicado por forma a

evitar lapsos na recolha deste tipo de documentos, designadamente, do código interno do tipo

de documento e da série. Poder-se-ão criar tantas

séries, quantas as existentes nos duplicados dos

documentos, ou apenas uma série única;

£) Para referenciar um documento original recolhido

na aplicação, deve ser utilizado o código interno

do tipo de documento, a série e o número do

documento original, e não a identificação única

do documento (fivoiceNo ou DocumentNunber) atribuído pela aplicação ao documento

recuperado;

duplicados de outros tipos de documentos,

utilizar-se-ão os campos aplicáveis e os procedimentos dos números anteriores.

SAF-T(AO), para além do referido no ponto 1, são respeitadas as seguintes condições:

constar todos os elementos dos índices dos

campos definidos como obrigatórios das tabelas

aplicáveis ao tipo de ficheiro, bem como todos

os campos que embora não sejam obrigatórios

tenham valores na base de dados;

únicos para os elementos indicados nas notas

técnicas da estrutura de dados, dentro das tabelas

respectivas, de modo a manter a integridade do

conteúdo do ficheiro XML de SAF-T(AO). Os

elementos referidos nas tabelas de documentos

comerciais (4.1 a 4.3) devem existir nas respectivas tabelas mestres (2.2 a 2.5);

ou a informação a registar na base de dados que

são susceptíveis de extracção para o ficheiro

SAF-T(AO);

das tabelas 4.1 a 4.3, dos documentos comerciais (Source Documents), relativos a Chave do

documento (Hash) e nos relativos a Chave de

controlo (HashControl) de cada estrutura, respectivamente, a assinatura e a versão (números

inteiros sequenciais) da chave privada utilizada,

ambas gravadas previamente na base de dados,

quando se desencadeou o processo de emissão

do documento;

dados, mas que foram originalmente criados

num outro sistema, devem estes ser objecto de

extracção para o ficheiro XML SAF-T(AO) com

os campos Chave do documento (Hash) e Chave

de controlo (HashControl) das respectivas tabelas 4.1 a 4.3, preenchidos nos termos das alíneas

da solução original, com os referidos campos

devidamente preenchidos, em conformidade;

impostos (GrossTotal) das tabelas 4.1 a 43

devem ser extraídos com o mesmo valor que foi

considerado na assinatura, isto e, arredondado a

duas casas decimais.

utilizador a alterar a palavra passe periodicamente. A nova

palavra passe não pode ser vazia e o administrador não a pode

conhecer ou visualizar as palavras passe dos utilizadores.

do número de reposições de cópias de segurança efectuadas.

data e hora de emissão dos documentos.

os campos Estado actual do documento — Tnvoice Status,

MovementStatus, WorkStatus ou PaymentStatus — de valor

«N») proveniente da recolha do mesmo documento manual

ou do procedimento mencionado no n.º 9 do presente anexo.

do que 2 casas decimais para evitar erros de arredondamento.

bem como a informação relativa a assinatura dos últimos

documentos emitidos por série, apos estas terem exportado

os dados para a aplicação de integração;

as quantidades e valores das respectivas facturas a rectificar;

compreendidos entre O e 100 %

impressão dos documentos seja efectuada pelo fabricante do

software ou, caso seja facultado ao utilizador a possibilidade

de criação de novos tipos de documentos, estes sejam obrigatoriamente validados pelo fabricante através de assinatura

digital, ou outro qualquer mecanismo que produza os mesmos efeitos

prestados, por forma a permitir o correcto preenchimento do

campo TaxPointDate

de documentos que são assinados elou exportáveis para o

ficheiro XML SAF-T(AO)

calculo sobre documentos recolhidos ou resultantes de integração de outros sistemas

emitidos, não seja alterado. Apenas poderá ser averbado

o NIF em falta, no caso de o campo não estar preenchido, ou estar preenchido com o NIF do cliente genérico

«999999999»,

documentos emitidos, mas cujo NIF não foi fornecido, seja

alterado. Esta limitação cessa, quando na ficha do cliente for

averbado o respectivo NIF.

Descrição do produto ou serviço (ProductDescription) constante na tabela 2.4.

realização de movimentos fiscalmente relevantes.

rectificados.

quais já tenha sido emitido documento rectificativo (nota de

credito ou debito) ainda que parcial, sem a prévia anulação

do respectivo documento rectificativo.

documentos de venda ou transmissões em documentos de

rectificação.

não for preenchido pelo utilizador, aquando do

processamento de documentos;

posterior a actual, ou esta e superior a data do

sistema. Nesse caso, apos essa emissão, não

poderá ser emitido um novo documento com a

data actual ou anterior, dentro da mesma série;

documento emitido, deve ser pedida a confirmação,

antes da emissão, de que a data e hora de sistema se

encontra correcta. Esta validação deve ser feita util1-

zando a data/hora do SystemEntryDate de qualquer

tipo de documento emitido, independentemente da

sua série;

ponto 2 do presente anexo:

criptografia de dados que usa o sistema de chaves

assimétricas, chave pública e chave privada);

partir da chave privada, em formato PEM - base

64 e deve ser criado o respectivo ficheiro com a

extensão «.txb>;

a chave privada utilizada para a criação da assinatura que e do seu exclusivo conhecimento e

deverá estar devidamente protegida no software;

deverá conter os dados concatenados no formato

indicado nas notas técnicas para cada campo,

separados por«;» (Ponto e vírgula);

(ImvoiceType), devem usar (para a assinatura dos

respectivos documentos) os seguintes campos:

i A data de criação do documento de venda

[campo 4.1.4.7 - data do documento de venda

(Imvoice Date) do SAF-T (AO)];

[campo 4.1.4.12 - data de gravação do documento (System Entry Date) do SAF-T (AO)];

venda (fmoiceNo) do SAF-T (AO)];

iv O valor do documento de venda [campo

4,.1.4.20.3 - total do documento com impostos

(GrossTotal) do SAF-T (AO)];

v A assinatura gerada no documento anterior, do

mesmo tipo e série de documento [canpo4.1.4.4

- chave do documento (Hash) do SAF-T (AO)].

A assinatura resultante do disposto na alínea anterior e a versão da chave privada de encriptação

devem ficar guardadas na base de dados do programa de facturação.

Composto pelo código

interno do documento, seguido de um espaço, seguido

do identificador da série do

sequencial do documento

dentro da série. ([a-zA-

-Z0-9. / -])+ ([a-zA-ZO-9]

*/[0-9] +)

em [EEE oo |

GrossTotal casas decimais, separador 1200.00

decimal (ponto) e sem nenhum separador de milhares.

Base-64 mYJEv4iGwLcnQbR-

Hash, campo do D7dPs2uDimX08XjXIKc

documento anterior Ge3GEHmwMhmmGY

” usfilI JTdSITLX +umj Twz

= E

tratar do primeiro wWIkIXsiEp tO99eIMET/I 7

documento da série 8y3+YIDN + K+YPIQIV

ou do exercicio) mIQSOfXETsOPoSSwU

ZABALtOvToIlVhUZK &j

ACEYI9G6Nl =

Exemplo da mensagem a assinar

2019-01-11,2019-01-11T11:27:08,FAC

001/9;1200.00;m Y JEv41GwLcenQbRD7dPs2u-

DImXO08SXjXIKcGeg3GEHmwMhmmG Yus-

MM JTASITLX+HuuTwzgmL/USnvt6S9s8SIN

3LwkJXsiEpt099elMET/8y3+YIDN+K+YP

JQIV mIGSOfXETsOPo8SwUZdBALtOvTol-

VhUZKejACcjEYJG6ónNI=

£) Os documentos emitidos e englobados na tabela

de mercadorias ou da prestação de serviços

(WorkingDocuments) referidos no campo Tipo

de documento (WorkType), devem, usar (para

a assinatura dos respectivos documentos) os

seguintes campos:

(WorkDate) do SAF-T (AO)];

do documento (System Entry Date) do SAF-T

(AO)];

[campo 4.3.4.1 - identificação única do documento (DocumentNumber) do SAF-T (AO)];

v A assinatura gerada no documento anterior,

do mesmo tipo e série do documento [campo

SAF-T (AO)].

A extracção do Ficheiro do tipo facturação, deve conter

as seguintes tabelas do SAF-T (AO) e os respectivos elementos definidos na estrutura de dados.

1 - Cabeçalho (Header);

prestação de servigos (WorkingDocuments);

4,4 - Documentos de recibos emitidos (Payments).

O ficheiro remetido mensalmente deve conter apenas:

Os Documentos Comerciais emitidos no período (Mês,

Dia);

Os Clientes que tenham referência nos Documentos

Comerciais, excluindo-se aqueles que não efectuaram transações comerciais naquele período.

Dependendo do volume de facturas emitidas, a extracção

e envio poderá ser fraccionada em períodos mais curtos, por

exemplo, por semana ou por dia.

ANEXO II

Informações relevantes exemplificativas:

Para exemplificar a criação do par de chaves RSA, foi

utilizada a aplicação OpenSSL, que é executada directamente na linha de comandos com argumentos (Windows/

Linux, entre outros), e pode ser obtida em www .openssl.oreg.

Permite, entre outras funcionalidades, criar chaves RSA,

DH e DSA, criar certificados X.509, CSRs e CRLs, assinar

digitalmente, criptografar e decriptografar, etc.

Na analise dos exemplos apresentados, deve ter-se em

conta que:

São meramente ilustrativos, não significando de

maneira aleuma que o fabricante de software

tenha ou deva utilizar a aplicação OpenSSL;

As linhas de comando respectivas foram preparadas

e ensaiadas quer com base em Linux quer em

Windows, tendo-se obtido o mesmo resultado

final;

A utilização do comando ECHO, aplicado na linha

de comandos do Windows/Dos, pode apresentar

resultados diferentes dos obtidos em Linux,

pelo que não deverá ser utilizado para efeitos de

testes;

São realizados com o formato PEM.

Para criar a chave privada:

Basta executar o comando openssl com os seguintes

argumentos:

cmd> openssl genrsa -out ChavePrivada.pem 1024

Onde « ChavePrivada.p env> é o nome do ficheiro que

irá conter a chave privada e «1024» e o tamanho

em bits.

Como resultado foi obtida, neste caso, a informação de

que se apresenta uma parte:

-— BEGIN — RSA PRIVATE KEY-----MII-

CXgIBAAKBegQDWDX9wVqg]6ZqN-

ZUlojwBpyKKkuzHTCmfíK39xx/

T9vWkqgpcV7h3sx+t +ZOv2KhhNkle/1140CW

DPCXREA4g0ulQroNS29vMIP3aHHayy 76+IbB

CNVcHFx...

-----END RSA PRIVATE KEY -----

Para criar a chave pública com base na chave privada

anterior:

Deve executar o comando OpenSSL com os seguintes

argumentos:

cmd> openss!l rsa -in ChavePrivada.pem -out Chave-

Publica.pem -outform PEM -pubout

Onde «ChavePublica.penv» é o ficheiro que contem a

chave pública.

Para fazer o upload da mesma juntamente com a

Declaração Modelo 8 basta renomear a sua extensão de

«.pem” para ».txt” (sem as aspas).

Como resultado foi obtida, neste caso, a informação

seguinte de que se apresenta uma parte:

-—— BEGIN PUBLIC KEY----MIGÍMAOGCSqGSID3DQEBAQUAA4GNADCRBi-

QKBeQDWDX9wVqj6ZqNZUlojwBpyK

KkuzHTCmfK39xx/T9vWkqgpcV7h3sx++Z

Ov2KhhNkle/1140 CWDPCXREA4gO0ulQroN

S29vMIP3aHHayy76+IbBCNVcHFxMO0gg]jr

elacnDOqUpZ6Vza7F+PpCyuypD2V/pkLIn

X9Z6z5u YygcOXaSFdwIDAQAB

-----END PUBLIC KEY-----

Para verificar a chave pública:

Basta executar o comando OpenSSL com os seguintes

argumentos:

cmd> openss! rsa -in ChavePublica.pem -noout -text

-pubin

O par de chaves utilizado não requer a emissão de um

certificado por parte de uma entidade credenciada. O fabricante de software poderá gerar o certificado auto-assinado

para efeito da certificação e dele extrair a chave pública para

fornecer à AGT, com a extensão txt.

Para a criação do certificado a partir da chave privada, o

algoritmo RSA deverá ser utilizado com as seguintes específicações nos parâmetros:

Formato = x.509

Charset = UTF-8

Encoding = Base-64

Endianess = Little Endian

OAFEP Padding = PKCS1 vl.5 padding

Tamanho da chave privada = 1024 bits

Formato do Hash da mensagem = SHA-1

Independentemente da implementação do RSA que for

adoptada e que melhor se adeqúe a cada solução deve ser

garantido que as assinaturas contém 172 bytes, sem quaisquer caracteres separadores de linhas.

Os elementos a assinar (fmvoice Date, SystemEntryDale,

ImoiceNo, GrossTotal e Hash) devem ser concatenados

apenas com o separador «> entre cada um dos campos,

não devendo conter aspas nem qualquer carácter de fim de

linha, quando objecto de encriptação, com vista à obtenção

da assinatura.

Tratando-se do primeiro registo, o campo (Hash) é preenchido com o hash resultante da aplicação da chave privada

anteriormente criada, para assinar digitalmente os campos

(Imvoice Date, SystemEntry Date, InvoiceNo e GrossTotal).

O texto a assinar será:

2018-05-18;2018-05-18TI1:22:19;FAC 001/18;53.002;

Guardar a mensagem a assinar

2018-05-18,2018-05-18T11:22:19; FA C 001/18;53.00;

Num ficheiro de texto (que neste exemplo designaremos

Registol .txt), certificando-se que no fim da mensagem não

fica qualquer quebra de linha, apenas o <«;» sem aspas.

Assinar a mensagem contida no ficheiro Registo] .txt

com o seguinte comando:

openss] dest —shal -sien ChavePrivada.pem —outRegisto].

shal Registol.txt O ficheiro Registol.shal conterá o hash em

binário gerado pela aplicação OpenSSL.

Seguidamente é necessário efetuar o encoding para base

64 do ficheiro Registol .shal:

openssl enc -base64 -in Registol .shal -out Registol.

b64-A

O ficheiro designado por Registol.b64 é que contém

os 172 caracteres em e mais tarde exportados

para o campo (Hash) do SAF-T(PT).

O parâmetro - A serve apenas para a aplicação OpenSSL

gerar a assinatura numa única linha evitando as quebras de

linha adicionais.

Como resultado o ficheiro Registo1.D64 conterá uma

assinatura do tipo:

oso2FoOw4V941 CwKTrvóxwzUrOtxBW CwU0O0yL-

VAqgKwfOCNKZHMETGIXZZCA4spRSybylu-

DXBeegplogrl8ggeHnvev A OOUEcoAvGJo9Fa3DO

AOMhZNDa9/INvu71pp+0zHmN2raSIWpiHcemU

Yxm5qgamLBk49rk

egvl7ThimyKCYBKqgu60=

A qual deverá ficar registada no campo HASH da tabela

anterior e na posição correspondente ao

Procedendo de forma idêntica, agora com os dados do

2019-07-18;2019-05-18T15:25;FAC

001/19,75. C)0;o0so02FoOw4 V941CwKTrv6xwzUrOt

XxBWCwUOyL VAGQKwfOCNKZHMETG]

XZZC4spR5ybyluDXBegsgplogrlS8SsHnvevVAOQUE oAVGJo9Fa3DOAOMhZNDa9/

rTNvu7]1pp+0zZHmN2raSIWpiHcemUY

xm5qgamLBk49rkevl7hlmyKC YBKqgu60=

Utilizando os procedimentos acima descritos para o

shal e Registo2.b64.

Como resultado, este ultimo ficheiro, Registo2.b64 ira

conter a assinatura digital do 2.º registo do gênero deste tipo:

Y20g VAC9rcmm9hilZ CG GrxjpkZ P9NHn5shhp 9ph

BIVWIn+Ta2zKfr+

O+05brA 6VUOLULtMQP98P29q+veSwVtxSzLDb

mmkHMt16nEmh

91 QaO JwPpz2uUMqgtR3aMkW YPKANtc/yfn Xp Y1 c-

SeUGbQKkgAsJOF

SIdREA4+DibJaC7WMpw=

A qual deverá ficar registada no campo (Hash) da tabela

anterior e na posição correspondente ao 2.º Registo.

Para confirmar a validade das assinaturas basta executar

o comando:

Openss/dest-shal -verify chavepublica.pem -signature registo1.shal registo1.txt

Webservice (Estrutura de dados).

O pedido é efectuado segundo o protocolo SOAP e é

constituído por duas secções:

* SOAP: Header;

* SOAP: Body

* O Header inclui todos os campos de autenticação

do utilizador;

* O Body contém os dados do documento comercial.

SOAP:Header

Obrigatório: S - Sim; N - Não

Tipo Dados: A validar na especificação WSDL (Web

Service Definition Language) do serviço.

SOAP:Body.

Dados

: NIF do emitente:

'gistrationNumber) ;

(sem qualquer prefixo do país).

Identificação única do documento

de venda Deve ser idêntico ao que

consta no ficheiro SAF-T (AO),

quando gerado a partir sistema de

facturação que emitiu este docu-

2 - Número Documento Sim mento; strin

(ImvoiceNo) Composto pelo código intano do E

documento, seguido de um espaço,

seguido do identificador da série do

documento, seguido de uma barra

(O), e de um número sequencial do

documento dentro da série;

Não podem existir registos com a

mesma identificação.

ceDate)

Tipo de documento:

4 - Tipo (fimwoice Type) Sim | FT -Factura; NC-Nota de Crédito; | string

ND-Nota de Debito;

Status) im | N- Normal; string

A-Anulada

NIF do adquirente nacional

Número de Identificação Fiscal

(sem qualquer

Prefixo do País);

5- NIF Adquirente Deve ser preenchido sempre que se strin

(Customer Tex1D) trate de um adquirente nacional; E

Quando não tenha sido recolhido no sistema de facturação do

emissor, deve ser preenchido com

999999990

Este campo e mutuamente exclusivo com o campo «5 - NIF Adqui-

6- NIF Adquirente rene (Customer TaxID)». Deve ser

Estrangeiro obrigatoriamente preenchido um, e |

(International Customer apenas um dos campos. | string

TenlD) Deve ser preenchido sempre que se

trate de um adquirente estrangeiro,

cujo NIF tenha sido recolhido no

sistema de facturação do emissor;

Camegigennte Tetra

F ; taxa de imposto, e motivo de isenporTaxa (Line) - ao lidos

ção ou não liquidação.

Deve existir uma, e uma só linha,

por cada taxa (TaxType, TaxCode)

e motivo de isenção ou não liquidação (TaxExemptionReason)

Somatório do valor das linhas, sem

imposto, deduzido dos descontos de

linha e cabeçalho, onde foi aplicada

a taxa e/ou motivo de isenção des-

(DebitAmount) Obrigatório para as Notas de Credito. Nos restantes tipos de documento, deve ser preenchido apenas o

campo «7.2 - Valor a Credito (CreditAmount)».

Somatório do valor das linhas, sem

imposto, deduzido dos descontos de

linha e cabeçalho, onde foi aplicada

a taxa e/ou motivo de isenção descri-

(CreditAmount) Obrigatório para as Facturas e

Notas de Debito. Nas Notas de Credito, deve ser preenchido apenas o

campo «7.1 - Valor a Debito (Debit

Amounty».

agmeme | | |

Imposto (TerxType)

a Tipo

Motivo de isenção de IVA Campo

de preenchimento obrigatório quando se trate de uma transmissão ou

Isenção que, justificadamente, não ocorra

(TexExemptionReason ) liquidação de IVA.

Deve ser preenchido com os códigos da tabela Motivos de Isenção

ou não liquidação de IVA.

8 - Totais do

Documento

(DocumentTotals)

Valor do imposto a pagar. Deve

incluir apenas os impostos contem-

plados nas linhas de resumo por

(Tex Pavable) :

taxa em «7 - Linhas do Documento

por Taxa (Line)».

Total do documento sem imposto.

(AetTotal)

Total do documento com imposto.

Deve incluir o valor tributável e todos

os impostos aplicáveis ao documen-

to, mesmo que não contemplados

(GrossTotal) :

nas linhas de resumo por taxa em

«7 - Lnhas do Documento por Taxa

(Line)».

Despacho n.º 17/19

de 6 de Março

Havendo necessidade de proceder à extensão gradual

dos serviços da Administração Geral Tributária, a nível

do território nacional, como forma de garantir maior proximidade do serviço público aos particulares e o eficiente

cumprimento das obrigações tributárias dos contribuintes;

Em conformidade com os poderes delegados pelo

Presidente da República, nos termos do artigo 137.º da

Constituição da República de Angola, e de acordo com as disposições combinadas do Despacho Presidencial n.º 289/17,

de 13 de Outubro, da alínea d) e D) do n.º 1 do artigo 6.º do

Decreto Presidencial n.º 31/18, de 7 de Fevereiro, que aprova

o Estatuto Orgânico do Ministério das Finanças, conjugado

com a alínea 1) do n.º 2 do artigo 6.º do Estatuto Orgânico

da Administração Geral Tributária, aprovado pelo Decreto

Presidencial n.º 324/14, de 15 de Dezembro, determino:

Outubro, que cria a 5.º Repartição Fiscal de Luanda, que

passa a ter a seguinte redacção:

«1. É criada a 5.º Repartição Fiscal de Luanda, na Província

de Luanda, adstrita ao Serviço Regional da Terceira Região

Tributária, com dependência directa da Administração Geral

Tributária, que atenderá a área territorial de jurisdição definida

no Anexo do presente Despacho e que é dele parte integrante.»

aplicação do presente Diploma são resolvidas pelo Ministro

das Finanças.

publicação.

Publique-se.

Luanda, a 1 de Março de 2019.

O Ministro, Archer Mangueira.