SAFT(PT) PARA
FATURAÇÃO
JOSÉ AUGUSTO FERREIRA FRANCO
[versão demonstração]
Copyright © 2019 José Franco
Todos os direitos reservados.
ISBN:978-989-20-9697-1
AVISO PRÉVIO
ESTA OBRA É UM LIVRO DE AUTOR. SIGNIFICA ISSO QUE TODO O TRABALHO DE GRAFIA,
EDIÇÃO E FORMATAÇÃO É DA RESPONSABILIDADE DO AUTOR.
É UM LIVRO EM REVISÃO PERMANENTE , ABERTO A IDEIAS E SUGESTÕES.
SE ENCONTRAR ALGUM ERRO, ALERTE O AUTOR.
ERRAR É UMANO
DEDICATÓRIA
Ao meu filho Bernardo, que veja no pai um exemplo de que a força de vontade é capaz de
coisas impossíveis.
Ao Einstein e à Lucy, os meus animais de estimação pelas vezes que resmungaram para
comer, enquanto eu escrevia mais um capítulo.
CONTEÚDO
Capítulo Índice Página
Agradecimentos 6
Prefácio 8
Introdução 9
1 Base de conhecimento 10
1.1- SAFT (PT) , a revolução do software 12
1.2- Portarias SAFT(PT) 17
1.3- Top 10 mais relevantes para o SAFT(PT) 19
1.4- Anotações ao ficheiro XSD 23
1.5- Ferramentas de tratamento e validação 28
1.5.1- Validadores 28
1.5.2- Ferramentas de tratamento e validação 29
2 Ficheiro SAFT(PT) – da teoria à prática 31
2.1- As perguntas que todos fazem quando o assunto é SAFT(PT) 32
2.2- Tipos de envio SAFT(PT). Vantagens e desvantagens 36
2.3- Tabelas SAFT(PT) - aplicações de faturação 40
3 Manipulação XML 43
3.1- Iterar erros no XML 47
3.2- Ler ficheiro no formato XML 49
3.3-Manipular grandes volumes de dados com PHP 50
3.4- Gerar XML a partir do XSD 51
3.5-Gerar Json a partir do XML (e vice-versa) 52
4 Criptografia de chaves 54
4.1 – Crifra de César – os primórdios da criptografia 55
4.2.1- Algoritmos de encriptação simétrica mais usada 61
4.2.1.1- DES (Data Encryption Standard) 61
4.2.1.2- 3DES (Triple Data Encryption Standard) 62
4.2.1.3- AES Advanced Encryptation Standard 62
4.2.1.4- RC4 / RC5 (Rivest Cipher) 63
4.3- Encriptação assimétrica 64
4.4- Criptografia Moderna no PHP - Libsodium 68
4.4.1- Instalação do Libsodium no Windows e Linux 69
4.4.2- Exemplos do libsodium com PHP 71
5 Webservices
5.1- Considerações sobre Webservices
5.1.1- Como funciona um webservice
5.1.2- Tipos de comunicação SOAP , REST
5.1.3- Consumir um webservice com PHP e Curl
5.2- Web Services Security ( WSS)
5.3- Criptografia no protocolo WSS
5.4- Estrutura SOAP-WSS no webservice da AT
6 Comunicar o SAFT(PT) por websevice
6.1- Criar um sub-utilizador
6.2- Criar um CSR (Certificate Signing Request)
6.3- Certificado digital para ambiente de testes e produção
6.4- Gerar chaves ciptográficas com OpenSSL via prompt
6.5- Configurar o OpenSSL no PHP
6.6- Operar OpenSSL a partir do código fonte
6.7- Consumir o webservice da AT com PHP e SOAPClient
6.8- Tratamento de erros
7 Criando um programa de faturação com PHP-MySQLi
7.1- Definindo a estrutura da Base de Dados
7.2- Definido do template com Bootstrap
7.3- Implementação das classes POO
7.4 – Implementação dos Webservices
7.5 – Sistema de Relatórios FPDF
7.5 – Operando o sistema
8 SAFT(PT) Knowledge Base
8.1- Tabelas
8.2- Restrições
8.3- Expressões regulares (restrições)
8.4- Estrutura de dados
8.5 – Estrutura XML SAFT Completa
9 Bibliografia
AGRADECIMENTOS
Não posso deixar de agradeçer à minha colaboradora Bárbara, pelo enorme apoio e
incentivo. “Acho que faz bem, força!”, por vezes são palavras que ficam para a vida.
Por ser o meu braço direito na altura em que encetei este projecto e suportar toda a
pressão dos outros projectos onde estou envolvido. À minha mãe pela forma liberal
com que permitiu que a minha formação prosseguisse, sem nunca me pressionar de
qualquer forma para fazer o que quer que seja , contra a minha vontade. À minha
saudosa avó que me ajudou a criar. É a ela que eu devo tudo.
A uma pessoa muito especial.
PREFÁCIO
Portugal foi um dos primeiros países a adoptar a normativa SAFT
em 2008. Desde então mais sete se juntaram ao leque de países
onde a implementação foi imposta de forma obrigatória.
SAFT(PT) é como é conhecida a aplicação da estrutura proposta
pelo comité de assuntos fiscais OCDE.
Significa Standard Audit File for Taxes Purposes, e na generalidade
é uma ferramenta criada para fazer face à evasão fiscal e facilitar a
auditoria à financeira nas empresas.
Em território português, a Autoridade Tributária é a responsável
pela sua fomentação, que se tornou obrigatória por decreto-lei.
Os produtores de software são aqueles que mais conhecimento
detêm sobre esta inovação, pois além de serem os pioneiros na sua
aplicação , ainda tiveram o papel de ajudar a criar processos para
isso fosse possível, uma vez que a tecnologia teve de ser adaptada
aos programas de faturação e contabilidade, e simplesmente a
esse nível , não existia nada semelhante na europa.
Algum tempo depois, o alarido em volta do tema aumenta à
medida que muitos dos softwares já se encontravam preparados,
quando todos os detalhes técnicos eram conhecidos em modo
profundo pelo mundo informático, que levaram a imposição da
AT , muito a sério.
Nessa altura os técnicos de contabilidade e fiscalidade,
incumbiram-se de fazer a sua própria actualização de
conhecimentos, procurando saber em detalhe, o que estava por
detrás do regulamento. Muito depressa veio em sua desefa, o
presidente dos Técnicos Oficiais de Contas, denunciando que o
SAFT(PT) não eram mais do que um método de caça às bruxas ,
10
apelidando-o mesmo de Big Brother Fiscal.
Apesar de alguma tentativa de resistência, o processo lá foi
implementado, e actualmente faz parte da dinâmica normal do
processo de faturação e contabilistico.
INTRODUÇÃO
Portugal sendo um dos países membros da União Europeia , está
sujeito a um conjunto vasto de regras e obrigações que nos regem
a todos enquanto nação e que são mais ou menos comuns às dos
restantes países que formam a CEE.
Os problemas comuns no seio da União, são assim resolvidos com
soluções que facilmente se encaixam a todos eles, sempre na
tentativa de que isso não afete a soberania dos países que
compõem o eixo da comunidade europeia.
A introdução de sistemas informáticos nas empresas foi o pilar
para a criação dum novo paradigma, a que se pode designar por
cidadão colaborante.
Sem nos darmos conta , passamos nós próprios além de pagar
impostos , a ser funcionários disfarçados do estado. Não se
pretende com esta afirmação tecer qualquer critica. É apenas o
constar duma realidade solidificada pelo modelo fiscal seguido
pela AT na última década até ao momento.
As operações que antes estavam do lado da função pública
tributária, passaram a ser incluídas aos poucos nas nossas
aplicações informáticas de faturação e desta forma cada estado
apercebeu-se que seria possível realizar enorme poupança neste
sector, além dos benefícios de controlo.
11
Isso não foi de todo suficiente para reduzir a quota de faturação
paralela que era um problema genérico a todo o espaço europeu.
Em 2005 , o Comité dos Assuntos Fiscais da OCDE , chegou à
conclusão , que esse problema poderia ser resolvido , se as
aplicações informáticas estivesse dotadas se mecanismos que
impossibilitassem determinadas operações. Apagar faturas sem
qualquer controlo e refazer a contagem interna do número das
faturas ou outro tipo de documento fiscal era até 2005 possível
sem qualquer problema. Apenas restava o risco legal e criminal do
ato.
Em Maio de 2005 era publicada a primeira versão do guia SAF-T e
criado o esquema .XSD (que iremos ver mais à frente).
Pode consultar informações detalhadas aqui (clique no link). [link
1]
Em Portugal é amplamente conhecido pela notação de SAFT (PT) .
É um ficheiro XML que contém praticamente todas as pegadas
deixadas na sua aplicação de faturação e as guarda num ficheiro
em formato digital próprio, conhecido por XML .
XML em inglês significa Schema Language Markup.
Do inglês Standard Audit File For Taxes Purposes, o SAFT(PT) , serve
basicamente para que a Autoridade Tributária (AT), possa
monitorizar e validar a faturação prestada pelas empresas.
Na prática é uma ferramenta de fiscalização.
O XML é uma linguagem de marcação , que permite de forma fácil
ser lida e tratada por diferentes softwares, independentemente do
sistema operativo usado, seja ele Linux, Windows ou Apple. O XML
12
foi criado para comunicar entre todos eles .
Esta obra tem um objetivo simples. Ser-se curto e conciso na
descrição e ir direto a exemplos práticos e reais.
Criar uma aplicação real concebida em PHP que permite exportar
um xml válido e à posteriori testado , num validador, que também
falaremos à frente.
Se já tem algum conhecimento sobre a linguagem de programação
PHP terá a vida facilitada, mas bastará um apanhado geral sobre a
sintaxe de qualquer linguagem para entender facilmente o
processo no ato de meter as mãos na massa.
Mas de modo geral a leitura e acompanhamento deste pequeno
manual é destinada a todos os curiosos ou aficionados pelas novas
tecnologias.
Vamos começar ?
13
CAPITULO 1
1- BASE DE CONHECIMENTO
O primeiro passo para criar qualquer coisa nova é ter informação
suficiente sobre determinada temática ou objeto, ou por outro
lado ter um nível elevado de criatividade.
Em todos os processos de desenvolvimento , e numa aproximação
ao domínio da informática a primeira reação é recorrer à pesquisa
na Internet, na expetativa de encontramos sempre algo já pré-
criado por alguém.
Ao longo desta obra , vamos partir do princípio que para o
desenvolvimento do xml SAFT (PT) nada está feito.
Que teremos de ser nós próprios a pensar como chegar a esse
objetivo, tendo o auxilio apenas de algumas ferramentas para
tratamento do XML.
Isso leva então a que temos de saber onde obter informação fiável,
tal como manuais e outras aplicações auxiliares.
Na informação disponível a partir do [link 1) , sabemos que em
Portugal, é a AT a responsável por acompanhar e introduzir
alterações ao ficheiro.
Então é no site da Autoridade Tributária que vamos obter toda a
informação necessária.
Consulte o link SAF-T PT (Standard Audit File for Tax purposes) -
Versão Portuguesa
É aqui que se encontra o repositório oficial da AT, que incluíu
esquemas , aplicações e portarias.
14
1.1- SAFT(PT), A REVOLUÇÃO DO SOFTWARE
A adoção de novas tecnologias por parte das empresas e
instituições portuguesas sempre se mostrou relutante desde a sua
criação e posterior proliferação mundo fora. Não fomos os últimos
a apanhar o barco, mas estivemos muito longe das primeiras
posições, no que se refere à massificação da tecnologia na
sociedade portuguesa.
Hoje em dia (a aproximar-nos de 2020) tudo é diferente . Mas no
início, o percurso foi árduo. Ainda atualmente, a máquina do
estado, tem falhas graves e bem evidentes na formação dos
funcionários públicos.
Mas, se na prática a introdução do SAFT(PT) é combater a
faturação paralela e gerar poupança (e aqui estamos de acordo), o
erro maior é prosseguir no uso de software proprietário com
licenças de utilização avultadas , sendo que existem soluções livres.
O caso o OpenOffice é um exemplo muito sui generis, mas
existiriam dezenas , senão até milhares de exemplos, de aplicações
de software em que o estado poderia ter a mesma produtividade e
poupar milhões de euros ao erário público.
15
Numa altura de superação e tantos sacrifícios impostos aos
contribuintes, títulos de noticias (com o selo da Universidade de
Coimbra) , com a seguinte são de lamentar.
A informatização generalizou-se em força nos anos 90, mas de
forma tímida.
Em parte até devido ao elevado grau de iliteracia digital, e por
outro em coaduno com o baixíssimo grau de escolaridade dos altos
cargos e patrões que constituíam a pirâmide da economia lusa
nessa altura.
Tudo mudou a partir de meados dos anos 2000.
Chegou ao mercado uma nova geração, e muitos desses ativos
dotados com licenciaturas e mestrados. Uma verdadeira lufada de
ar fresco às empresas .
As empresas adotaram sistemas de faturação, alguns já
desenvolvidos integralmente em território nacional , mas muitos
oriundos da vizinha Espanha e outros países.
Grande parte deles criado a partir de baixíssimos orçamentos , o
que geralmente se traduzia em mau funcionamento e perdas de
informação constantes e até de legalidade duvidosa.
Havia em Portugal nos anos 2000, três ou quatro empresas com
aplicações de renome e criadas em território nacional .
Mas mesmo algumas dessas chegaram a ter alguns problemas
16
perante a lei , por usarem junto com o software original, sistemas
obscuros de faturação paralela , face à desgovernança que
caracterizava o sector responsável por desenvolvimento de
software.
Os próprios meios de inspeção não tinham forma de lhes fazer face
, pois eram também eles iletrados digitais.
O SAFT surge em 2005 a partir duma recomendação do Comité de
Assuntos Fiscais da OCDE, e Portugal adotou-o nos 2 anos
seguintes.
Embora soe estranho, somente ainda sete países da União
Europeia o adotaram; além de Portugal , França , Luxemburgo,
Polónia, Áustria, Lituânia e Noruega.
O SAFT(PT) constituiu-se ele próprio com o grande responsável
pela regulação do sector no desenvolvimento de software,
essencialmente dos sistemas de faturação, que passaram a ter um
pilar de suporte em regras bem definidas.
As software houses foram obrigadas a atualizar as próprias
aplicações e apenas ficaram no mercado aquelas capazes de
responder às exigências da Autoridade Tributária. Foi uma grande
limpeza.
O cerco apertou-se para as empresas produtoras de software , mas
ainda ainda assim manchetes como a seguinte continuaram a ser
capa.
17
Estima-se que milhares de aplicações existentes no mercado a
funcionar de forma duvidosa tenham perdido continuidade.
Além de que o estado arrecadou enorme poupança , uma vez que
atualmente todos os softwares são eles próprios auto vigilantes,
em todos os casos de anulações de documentos indevidas ou
simplesmente pelo enorme risco subjacente ao transporte de bens
de serviços sem a emissão documento fiscal. O SAFT(PT) acabou
por cair nas graças dos próprios legisladores.
A esse respeito na primeira portaria , o manual na AT refere o
seguinte:
(...)aprovou um formato de ficheiro normalizado de auditoria
tributária para exportação de dados, o designado SAF-T (PT), que
tem vindo a revelar-se como um excelente instrumento de
obtenção de informação pelos serviços de inspeção e cuja
estrutura de dados tem vindo a ser adaptada em função das
alterações de natureza contabilística ou fiscal. A evolução
verificada na estrutura de dados do ficheiro SAF-T (PT) tem
incidido, essencialmente, na melhoria da qualidade da informação
relativa à faturação. A experiência de utilização do SAF-T (PT)
evidenciou que a atual estrutura é insuficiente para uma completa
compreensão e controlo da informação relativa à contabilidade,
18
em virtude da flexibilidade existente na utilização das contas pelas
diferentes entidades.
Fonte: AT
A obrigatoriedade do SAFT(PT) mexeu forte com o sector.
As manchetes da altura confirmam isso mesmo.
A ideia de que o SAFT(PT) é a ferramenta mais querida da AT não é
nova.
19
As próprias agências de contabilidade passaram a chamá-lo de O
Grande Big Brother Fiscal
Se o objetivo da OCDE era de criar uma forma ágil e versátil de
comunicar dados fiscais às Finanças , os sucessivos governos em
Portugal subverteram o SAFT(PT) .
Transformaram-no numa ferramenta de terrorismo fiscal em que
toda a informação das empresas é coletada e enviada (alguma sem
critério) , e muita dela sem qualquer significado fiscal , ao mesmo
tempo que se aprovam leis que para proteção de dados
Uma dualidade de critérios incompreensível aos olhos do cidadão
comum.
1.2- PORTARIAS SAFT(PT)
A legislação em vigor na República Portuguesa para que dê entrada
em vigor, têm de ser decretadas em Diário da República através de
portarias, e emanadas dum secretário de Estado ou diretamente
dum Ministro.
A primeira portaria SAFT(PT) entrou em vigor em 2008 , designada
de portaria nº 321-A/2007, legislada do então secretário de estado
dos assuntos fiscais, Paulo Núncio, no governo de Passos Coelho.
20
A adopção deste modelo proporciona às empresas uma
ferramenta que permite satisfazer os requisitos de obtenção de
informação dos serviços de inspecção e facilita o seu tratamento,
evitando a necessidade de especialização dos auditores nos
diversos sistemas, simplificando procedimentos e impulsionando a
utilização de novas tecnologias. Nestes termos, de forma faseada e
começando pelas aplicações de facturação e de contabilidade,
torna-se obrigatória a adopção deste modelo normalizado de
exportação de dados.
Fonte: AT
É muito importante fazer alusão às portarias, porque são os
manuais mais completos nas tarefas auxiliares à criação do ficheiro
de auditoria que pretendemos desenvolver.
Abaixo segue-se a lista das portarias SAFT(PT) por ordem
crescente de antiguidade.
Portaria n.º 302/2016
Portaria n.º 160/2013
Portaria n.º 274/2013
Portaria n.º 321-A/2007
21
A primeira portaria (321-A/2017), é aquela que suporta a
informação mais relevante e descreve em detalhes
pormenorizados , como a estrutura é criada.
As restantes são meras afinações ao esquema XML e às validações
necessárias, e actualizações a novos tipos de dados necessários.
Portanto se compreender aquilo que é pedido na primeira
portaria , o processo de criação do ficheiro fica facilitado.
Através do ficheiro SAFT(PT) os documentos seguintes são de
carácter obrigatório na comunicação à AT:
• Faturas;
• Faturas/Recibos;
• Faturas Simplificadas;
• Notas de Crédito;
• Notas de Débito
• Recibos (nas empresas ao abrigo do regime de IVA de caixa)
1.3- TOP 10 MAIS RELEVANTES PARA O SAFT(PT)
1) O ficheiro a exportar deve ser normalizado na
linguagem XML, obedecendo às regras no ficheiro XSD.
2) Na estrutura de dados * significa campo obrigatório ,
e ** significa campo de preenchimento alternativo.
22
3) Todos os softwares de faturação/contabilidade devem
incluir uma forma de gerar um SAFT(PT) em formato válido.
4) O sistema de exportação deve possuir a subtileza de
exportar entre dois períodos de tributação, num domínio
entre duas datas.
5) Existem dois tipos de SAFT – um relativo à faturação e o
outro relativo à contabilidade.
6) Empresas com diferentes estabelecimentos, têm de
produzir ficheiros para cada estabelecimento se o software
central for distinto daquele usado nas lojas.
7) Conjunto de tabelas que é obrigatória na exportação
no SAFT(PT) relativo à faturação (Cabeçalho, Clientes, Tabela
de Impostos, Produtos/Serviços e Documentos Comerciais
8) Na exportação dos Documentos Comerciais é possível
subdividir a exportação em meses completos, para evitar
congelamento das aplicações, devido ao volume de dados.
9) A estrutura de dados pode ser consultada na Portaria
1192/2009
10) Consulte neste link o esquema XSD
23
Tabela 1) Fragmento da estrutura de dados e especificações
A explicação sobre a sintaxe do XML que vamos elucidar em
seguida é essencial para que a partir da estrutura de dados,
consigamos criar o ficheiro sem grandes dúvidas.
É totalmente recomendável a leitura e interpretação da estrutura.
A título de exemplo, na Tabela 1), por exemplo o campo
CompanyID , será no xml um elemento .
Entenda a seguir como são declarados os elementos e como os
dados são organizados no ficheiro.
Já abordámos superficialmente acerca dos objetivos do XML , mas
parece claro que é necessário saber um pouco mais sobre esta
tecnologia, para entendermos a razão porque que foi a escolhida
para criar o ficheiro de auditoria SAFT(PT).
24
O XML foi criado pelo W3C (World Wide Web Consortium), em
1990 e surgiu da necessidade de criar uma linguagem que fosse
lida por todos os softwares e facilmente integrada pelas restantes
linguagens.
O HTML era insuficiente para isso e SGML (IBM), era mais
complexo na declaração e mais difícil de integrar nas linguagens já
existentes até então.
Sendo uma linguagem de marcação, os dados ficam organizados
entre elementos.
No exemplo da figura 2 abaixo, AuditFileVersion, CompanyId,
CompanyName , etc … , são os elementos, que são abertos e
fechados por tags <> es dados relativos a cada elemento, são
colocados entre a abertura e fecho dos elemento.
Repare no exemplo TaxRegistrationNumber , em que o número
inteiro correspondente ao contribuinte, é colocado entre os
elementos.
Figura 1): Trecho xml SAFT(PT) com os seus elementos e tags
25
1.4- ANOTAÇÕES AO FICHEIRO XSD
Antes de partirmos à criação do ficheiro SAFT(PT), é prioritário
As regras do XML são definidas no XSD, e mesmo que na criação
do ficheiro tenha seguido todas as regras da estrutura de dados e o
XML obtido der erro, existem duas soluções:
ou o tipo de dados mal definido em algum elemento XSD ou a
estrutura seguida está errada em algum dos passos.
Contudo o XSD tal como está definido é mandatário para a
validade do XML.
Abra a ferramenta Conversor XML para XSD disponível online.
Como a definição das regras XML tem uma sintaxe bem mais
complexa iremos seguir o processo de engenharia reversa.
Atente ao exemplo XML do trecho SAFT(PT), na Figura 1).
Vamos usar um pequeno bloco de elementos do exemplo e fechar
ao elemento Header.
<Header>
<CompanyID>123456789</CompanyID>
<CompanyName>Onidesk TI</CompanyName>
</Header>
Trecho 1) Exemplo de XML - elementos SAFT(PT)
26
Ao recorrer à ferramenta de conversão XSD obtemos o seguinte
esquema (use o XSD de Saída no formato VENETIAN BLIND ).
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name=" Header" type="HeaderType"/>
<xs:complexType name = "HeaderType" >
<xs:sequence>
<xs:element type = "xs:int" name = "CompanyID"/>
<xs:element type = "xs:string" name = "CompanyName"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Trecho 2) Regras XSD do exemplo anterior
Podemos visualizar que o XSD indica o tipo de dados para cada
elemento. Não define ainda, no entanto se o preenchimento
desses dados é ou não obrigatório, qual o tamanho ou por
exemplo no caso de CompanyName , a string possa conter
números ou apenas letras. Estes são chamados os tipos de dados.
É esse tipo de validações que o XSD faz.
Uma vez definidas, quando o XML é preenchido nos elementos , se
validarmos o ficheiro , as regras ditam se os dados nos elementos
estão ou não bem formatados e de acordo com as regras e é tudo
isto que garante a integridade do ficheiro XML.
A esta altura , e como estamos num exemplo bastante básico e
superficial , já poderíamos fazer a validação do XML.
27
É possível fazer a validação numa qualquer linguagem de
programação, se você for programador ou autodidata em outra
linguagem informática.
Em PHP o exemplo seguinte permite validar o XML , informando as
regras contidas no ficheiro XSD.
<?php
$xml = new DOMDocument();
$xml->load('./saft.xml');
if (!$xml->schemaValidate('./regras_saft.xsd')) {
echo "Saft inválido<p/>";
}
else {
echo "Saft correto<p/>";
}
?>
Trecho 3) Validação dum documento XML com PHP
Não desespere se não sabe executar o código PHP acima.
O objetivo desta obra não é o de ensinar programação, embora
haja trechos de código no seu decurso, a compreensão é apenas
para efeitos didáticos.
Para o efeito da validação existem validadores online. O
freeformatter é um bom exemplo.
Como era de esperar o exemplo anterior ao validar pela
ferramenta freeformatter devolveu válido (Figura 2).
28
Figura 2): Validação XML contra XSD
Figura 3): Validação XML contra XSD
Podemos fazer o teste, alterando apenas o elemento CompanyID
para texto. Como seria expetável ocorrerá erro, porque as regras
estipuladas no XSD ditam que apenas pode ser preenchido com
valores numéricos inteiros.
Figura 3): Erros no XML devido a mau preenchimento dos elementos
29
No caso da existência de erros , e quando estivermos na presença
dum ficheiro real , cada documento conterá milhares de linhas
XML , era ótimo que soubéssemos em que linha(s) esse(s) erro(s)
ocorreram.
Em modo programador, o código seguinte facilitaria a vida , para
depois procedermos à respetiva análise e correção.
Trecho 4) Validação dum documento XML com PHP
30
1.5 – FERRAMENTAS DE TRATAMENTO E VALIDAÇÃO
1.5.1- VALIDADORES
Depois de gerado o SAFT(PT) será conveniente ter a certeza que foi
bem produzido e está na formação correta.
Os produtores de software disponibilizam validadores junto do
software de forma a resolver esta questão.
No entanto muitos dos erros ocorridos têm a ver com a forma
como a informação que está registada no sistema.
Uma ficha de produtos mal preenchida por exemplo , ou um
produto com algum tipo de dado inválido, farão com que esses
erros sejam enunciados no validador.
Os validadores mostram a linha onde o erro ocorre, o tipo de erro
e denotam o elemento em causa.
Desta forma podemos nós próprios fazer o correto preenchimento
dos dados e corrigir os erros enumerados.
As boas práticas , manda com que cada campo no software só
aceite o tipo de dados válido e assim evita-se erros na produção do
xml.
As finanças disponibiliza um validador que pode instalar em
ambiente windows , a partir deste endereço . (link ref: 9)
31
1.5.2- ANALISADORES
Como o SAFT(PT) é um ficheiro que contém dados da faturação ,
taxas e outros registos contabilísticos surgiram formas mais
sofisticadas na visualização dos dados e dessa forma obter
relatórios detalhados , gráficos por vendas, volume de
tributação ...
DICA:
Existem dezenas de validadores e analisadores para o SAFT(PT)
na internet. Para isso use apenas programas oficiais da AT , ou
algum que inspire confiança.
Muitos são de carácter duvidoso e são feitos para obter emails
ou contactos a partir do ficheiro.
Se pretender validar o seu ficheiro ou navegar sobre os registos
contidos, use este Analisador SAFT (link ref: 10)
Se trabalha em ambiente Linux, também existem boas soluções.
Uma delas é Visualizador SAFT, do Projecto Colibri, na versão 2.0 ,
é compatível com as regras impostas pela AT. Pode fazer o
download aqui (link ref: 11)
32
CAPITULO 2
2- Ficheiro SAFT(PT) - da teoria à prática
Ao longo deste capítulo vamos descrever as regras que nos
permitem criar um ficheiro SAFT(PT) de qualidade, de forma a que
contenha toda a informação obrigatória, mas não fique demasiado
pesado no acto da exportação XML.
A própria AT, de versão para versão foi tendo esse cuidado.
A evolução verificada na estrutura de dados do ficheiro SAF-T (PT)
tem incidido, essencialmente, na melhoria da qualidade da
informação relativa à faturação.
Fonte: AT
É então importante, descrever todo o conjunto de regras. A
resposta à pergunta Como criar o SAFT ? , reside em primeiro
plano podermos analisar um exemplo completo e depois disso
perceber que forma, meios e ferramentas temos à disposição para
o preencher correctamente.
No site da Onidesk, preparamos um exemplo completo e funcional,
que pode consultar para análise toda a estrutura xml. Mas a
melhor ideia, será numa primeira
Em jeito de pergunta-resposta , vamos estrapolar grande parte das
respostas que surgem, relativas à generalidade deste tema.
33
2.1 – As perguntas que todos fazem quando o assunto é SAFT(PT)
Para que serve ?
Quem está obrigado a produzir o SAFT(PT) ?
Qual é a data limite de envio ?
Que tipo de documentos são exportados ?
É uma obrigatoriedade que todos os documentos emitidos pela
empresa para um determinado periodo, sejam exportados.
•Faturas, faturas simplificadas, faturas-recibo, faturas proforma;
•Recibos;
•Notas de crédito, notas de débito, notas de encomenda, notas
de devolução;
•Guias de remessa, guias de transporte;
34
•Guias de movimentação de ativos próprios, guias de
consignação;
•Orçamentos;
•Fichas de serviço;
•Consultas de mesa.
É possível enviar o ficheiro fora do prazo ?
É possivel enviar fora do prazo, no entanto qualquer um que o faça
fica sujeito a multas, de acordo com o perfil tributário onde está
inserido. As multas de pessoas coletivas podem variar entre 450
euros aos 22.500 euros em caso de negligência.
No caso de pessoas singulares, as multas podem variar, caso se
trate, por exemplo de dolo, ou contraordenações fiscais praticadas.
E se a aplicação não produzir SAFT(PT) ?
Essa resposta é dada pela própria AT.
Os produtores de software são responsáveis por desenvolver
programas que cumpram com os requisitos legais da comunicação
de faturas e, para este efeito, devem guiar-se pelas especificações
produzidas pela AT para este efeito de comunicação Fonte: AT
35
Onde obter um exemplo do ficheiro ?
Onde posso validar o SAFT(PT) ?
No portal das finanças tem um validador que pode transferir para o
seu computador. Execute o ficheiro .jar que baixou, clique em
próximo e seguidamente carregue o ficheiro saft que deseja
validar.
Podemos alterar o método de comunicação ?
A resposta é sim , mas atenção que a forma escolhida deve ser
mantida no decorrer do ano todo. Ou seja, se para 2019 escolher
um método de comunicação diferente, deverá manter-se nele até
ao fim do ano.
36
O cenário anterior é o mais habitual, mas existem, no entanto,
duas exceções: se, durante o ano mudar de software de faturação
ou se deixar de emitir faturas em papel e adquirir um software de
faturação. Em ambos os casos, pode escolher o “novo” método de
comunicação que lhe for mais conveniente.
No caso de empresas com faturação considerável , o ficheiro
SAFT(PT) pode constituir-se como um processo complexo dado o
carga de dados do ficheiro xml, que em muitos casos pode
“congelar” e até bloquear a aplicação que faz a exportação.
Dando-se conta desta realidade a AT permitiu que os produtores
de softwares pudessem fazer o envio de forma faseada.
Muitos softwares chegam até a enviar do ficheiro de três em três
dias, com vista a otimizar o processo e evitar freeze das aplicações.
No caso das guias de transporte, o processo é automático e em
tempo real.
Este método de comunicação torna-se mais cómodo para as
empresas que emitem faturas contra pagamento. Fica uma
ressalva, pois para obter o código das guias, ter-se-á de aguardar
que este apareça no documento após finalizá-lo (ou seja, a AT,
depois de receber o documento em causa, devolve-o com um
código associado).
Veja no final deste capítulo os passos a seguir para criar um sub-
utilizador.
Apenas é possível comunicar documentos em tempo real se
realizar esta configuração.
Embora a informação de faturação relativa ao mês de tributação
seja de envio obrigatório à AT, tem se garantir que o software que
37
está a utilizar , lhe dá a garantir de realizar na mesma a exportação
SAFT(PT), num dado período , no caso de alguma auditoria
decorrente.
2.2 – Tipos de envio SAFT(PT). Vantagens e desvantagens
Vantagens do envio em tempo real
Este é o procedimento usado por quase todos os produtores de
software:
1) A comunicação de dados é pausada , se houver algum problema na
ligação à Internet e retomada de seguida, garantindo o envio integral
2) Nem intervenção humana (por exemplo um TOC)
3) O SAFT(PT) é submetido de forma automática
4)Transparência fiscal entre o cliente e a AT
5) Cada documento que é comunicado fica disponível no site e-fatura
6) Poupança de tempo bastante considerável
38
7) As aplicação de faturação emitem avisos de erros possíveis
8) Fiabilidade da informação enviada
9) Desaparecem as condicionantes provocadas pelos prazos
Desvantagens do envio automático
1) O serviço depende duma ligação à Internet
2) Uma vez comunicados os documentos, não é possível de
cancelar/anular . Têm de ser emitidos documentos retificativos.
3) Necessidade de um software de faturação
Envio do ficheiro pelo site e-Fatura
Este é o método aconselhável para as transações que não são
imediatas, porque desta forma controla a data da comunicação das
faturas, diminui-se a margem de erro no processo e evita-se a
retificação de documentos depois de comunicados.
Se o seu volume de faturação é considerável, repita o processo de
exportação pelo duas vezes por mês, para evitar atrasos por
sobrecarga do portal.
39
Vantagens do envio pelo e-Fatura
1) Mais fácil de exportar e importar num procedimento faseado
2) Controlo no envio dos documentos enviados
3) Diminui-se a margem de erro
4) Facilita a consulta e recolha de dados fiscais
5) Comum a todos softwares de faturação e contabilidade
6) Modelo solicitado em caso de inspeção da AT e normallização
do processo de auditoria
Desvantagens do envio pelo e-Fatura
1) É um requisito ter software de faturação
2) Possível intervenção do TOC para correção e cumprir de prazos
3) Podem ocorrer problemas na configuração do ficheiro
4) Coimas por falha no envio e não comunicação dos elementos
5) Maior tempo necessário para o este processo
Comunicação manual
A comunicação manual consiste em comunicar cada uma das
faturas emitidas , no portal e-fatura. Apenas se justifica esta opção
se não usa software de faturação, pois qualquer software de
faturação já faz a exportação em formato digital.
40
Vantagens da comunicação manual
1) Maior controlo sobre os dados enviados
2) É um processo que quem auto-fatura pode realizar, logo sem custos
Desvantagens da comunicação manual
1) Maior margem de erro, por se tratar de uma tarefa repetitiva
2) Este método é inviável se estiver obrigado a usar software de
faturação
3) Maior tempo despendido (tanto maior quanto o nº de documentos)
4) Coimas por falha no envio e não comunicação dos elementos
(Vantagens e desvantagens, inspirado no texto de Lúcia Valdevino. Ver bibliografia)
Recomendação:
Se também é daqueles em faz a comunicação manual do ficheiro SAFT(PT),
recomendamos vivamente que não deixe o procedimento de envio para dia 15 de
cada mês. Se o seu volume de faturação é considerável, reparta o processo por
mais de 2 vezes cada mês.
Essa é altura em que muito utilizadores de software o fazem, chegando a
sobrecarregar o portal e tornando o processo inviável.
41
2.3 - Tabelas SAFT(PT) - aplicações de faturação
Os diferentes blocos xml presentes no ficheiro, referentes às
aplicações de faturação , podem ser resumidos e organizados da
seguinte forma:
Tabela Regra
1) Cabeçalho (Header) obrigatória
2) Tabela de Clientes (Customer) obrigatória
3) Tabela de Impostos (Tax Table) obrigatória
4) Documentos de recibos emitidos Se existir obrigatória
(Payments)
5) Tabela de fornecedores (Supplier) Obrigatório exportar afetos ao período de
faturação
6) Tabela de produtos / serviços (Product) Obrigatório exportar afetos ao período de
faturação
7) Documentos comerciais a clientes Obrigatório exportar afetos ao período de
(SalesInvoices) faturação
8) Documentos de movimentação de Obrigatório exportar afetos ao período de
mercadorias (MovementOfGoods) faturação
9) Documentos de conferência de Obrigatório exportar afetos ao período de
mercadorias ou de prestação de faturação
serviços (WorkingDocuments)
Tabela 2: Tabelas SAFT para faturação
42
Note-se que cada tabela indicada acima, deverá constar no ficheiro
xml, em que as informações contidas , preenhem os elementos.
Por exemplo, se apontarmos no xml aos dados da tabela clientes,
o resultado da exportação dos dados dessa tabela será semelhante
à seguinte estructura xml:
Trecho 5): XML correspondente ao bloco de elementos Cliente
2.4 - Estrutura de dados
Os dados que cada elemento do XML podem conter, são
responsáveis por obter ou não um ficheiro válido .
É indispensável que tenha essa informação presente na hora de
preencher o XML.
43
Entender a estrutura de dados
A informação completa da estrutura de dados , está disponível aqui
no portal da AT.
Abaixo temos apenas um pequeno exemplo de como essa
informação pode ser usada junto dos elementos XML.
Campo Obrigatório Norma XSD
Nome da empresa (CompanyName) , * Texto 100
Nome do contacto na empresa
(Contact
Morada de faturação (BillingAddress) *
2.5 - Preencher os elementos XML
A construção dos elementos XML , no exemplo Nome da
Empresa, seria algo do género:
<CompanyName> Onidesk TI </CompanyName>
44
usando a mesma lógica para Morada de Faturação
<BillingAddress> Rua 232 , Lote 3 </BillingAddressBillingAddress>
A ideia do ficheiro SAFT(PT) é preencher cada elemento XML, de
forma dinâmica. Usando uma linguagem de programação isso pode
ser conseguido com trechos de código simples.
Neste exemplo usaremos a tabela Clientes.
45
CAPITULO 3
3 - Manipulação do XML
Dada a universalidade no uso do XML nas aplicações, qualquer
linguagem de programação atual possui uma extensão com a
capacidade de manipular XML.
Neste manual a linguagem de programação usada é o PHP, que já
vai na sua versão 7.3.6 .
O SimpleXML Parser é um manipulador de XML baseado em
árvore.
Com ele podemos ter acesso fácil ao nome dos elementos, aos
atributos e conteúdo textual, se conhecermos a estrutura do
documento XML ou o seu desenho (layout).
O SimpleXML converte um documento XML numa estrutura de
dados que pode ser iterada com um conjunto de arrays e objectos.
Comparado ao DOM ou ao Expat Parser, o SimpleXML apenas
necessita de meia dúzia de linhas de código para ler os dados
contidos num elemento.
Isso revela muito da sua construção sofisticada e limpa.
A mesma não precisa de qualquer instalação uma vez que faz parte
do core do PHP, e assim podemos usar de imediato as suas
funções.
46
A função PHP simplexml_load_string() é usada para ler dados XML
duma string.
Para exemplificar, usaremos os elementos do bloco Product do
próprio SAFT(PT).
Imaginemos que temos uma variável que contém o bloco Product ,
assim:
<Product>
<ProductType>S</ ProductType>
<ProductCode >6960</ ProductCode>
<ProductGroup>HP OfficeJet Pro</ProductGroup>
<ProductNumberCode >6960</ProductNumberCode>
</Product>
Trecho 6): XML correspondente ao bloco de elementos Produto
DICA:
Em caso de necessidade ou dúvidas, podemos consultar o
manual SAFT(PT) para acompanhamento completo da estrutura
de dados, já referida na capítulo anterior e disponível aqui .
47
Para fazermos o parsing do código e obter os dados de uma forma
totalmente dinâmica , eis um exemplo:
Este troço de código permite obter a seguinte tabela já preenchida
de forma dinâmica.
48
3.1 - Iterar erros no XML
A funcionalidade libxml permite ter controlo sobre os
erros que acorrem no XML, fornecendo algumas
informações úteis que permitem iterar melhor o tipo de
erros e as linhas onde ocorreram.
DICA:
Use a funcionalidade libxml para obter todos os erros
XML quando o documento está a carregar e podermos
iterar os erros.
O exemplo de código seguinte permite visualizar como a libxml faz
o tratamento de erros , quando por exemplo elementos XML são
mal produzidos.
No caso do nosso código, para que o output dos erros ocorridos
seja possível de visualizar é necessário ativar o uso dos erros
internos com libxml_use_internal_errors(true)
49
50