The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.
Discover the best professional documents and content resources in AnyFlip Document Base.
Search
Published by geral, 2019-07-16 19:11:21

livro_Amazon_16-07-2019

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


Click to View FlipBook Version