Jump to content
pv2013

SAFT-PT: debate de dúvidas e ideias

Recommended Posts

desconfiado
16 horas atrás, bioshock disse:

Viva,

Alguém me sabe confirmar se as séries duplicadas e manuais são obrigatórias existirem num software de facturação, bem como tudo o que isso implica no software? Na altura fiz este processo para efeitos de validação do software na AT, mas já não me recordo se isto é uma obrigatoriedade ou uma cortesia.

O que são séries duplicadas?

Share this post


Link to post
Share on other sites
antseq
16 horas atrás, bioshock disse:

Viva,

Alguém me sabe confirmar se as séries duplicadas e manuais são obrigatórias existirem num software de facturação, bem como tudo o que isso implica no software? Na altura fiz este processo para efeitos de validação do software na AT, mas já não me recordo se isto é uma obrigatoriedade ou uma cortesia.

Com a publicação do "Decreto-Lei n.º 28/2019", fica bem claro que os sujeitos passivos (empresa/cliente) em caso de inoperacionalidade tem de utilizar documentos pré-impressos em tipografias autorizadas e depois recuperar os mesmos no programa/software utilizado.


No meu caso no ano passado e em outras certificações, não validaram esta funcionalidade, mas não deixa de ser um "problema" para a empresa/cliente que compra o software e não pode cumprir com esta regra (podem sempre optar por comprar outro... ou um dia que precisem da mesma, descobrem que o SW não permite e dizem logo como é possível um SW certificado não permitir esta funcionalidade...)

Citação

Decreto-Lei n.º 28/2019, de 15/02
http://info.portaldasfinancas.gov.pt/pt/informacao_fiscal/legislacao/diplomas_legislativos/Documents/Decreto_Lei_28_2019.pdf
Artigo 4.º
4 - Em caso de inoperacionalidade do programa de faturação, os sujeitos passivos referidos no n.º 1 devem emitir faturas ou documentos fiscalmente relevantes pré-impressos em tipografias autorizadas, os quais devem posteriormente ser recuperados para o programa.

Citação

Respostas às questões frequentes (FAQ)
http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/Novas_regras_faturacao/Documents/FAQ_DL28_2019_2019_10_01.pdf
Q: Qual o significado de inoperacionalidade dos programas informáticos de faturação? Abrange apenas situações de avarias ou impossibilidade de acesso ao programa (falta de eletricidade ou similar)?
R: Considera-se existir inoperacionalidade do programa quando o acesso a este se mostre inviável, podendo resultar, nomeadamente, de avaria do equipamento informático, da falta de energia elétrica ou falha no acesso à aplicação por falta de cobertura de rede pelo operador de telecomunicações (em caso de utilização de programa através da internet ou de soluções de mobilidade).
Em todo o caso, as faturas e documentos relevantes devem ser emitidos em documentos pré-impressos em tipografias autorizadas e, posteriormente, ser recuperados para o programa.

cps,

  • Vote 1

Share this post


Link to post
Share on other sites
Larissa
16 hours ago, bioshock said:

Viva,

Alguém me sabe confirmar se as séries duplicadas e manuais são obrigatórias existirem num software de facturação, bem como tudo o que isso implica no software? Na altura fiz este processo para efeitos de validação do software na AT, mas já não me recordo se isto é uma obrigatoriedade ou uma cortesia.

Estamos a certificar o software e a integração manual dos documentos é uma obrigatoriedade. O técnico da AT quer inclusive, que todos os campos do documento sejam manualmente editáveis pelo utilizador (no caso por exemplo, do utilizador cometer um erro de cálculo ou preenchimento na hora de fazer o documento manual). Ou seja, o software não pode fazer nenhum cálculo ou preenchimento automático dos campos do documento.

 

Edited by Larissa
  • Vote 1

Share this post


Link to post
Share on other sites
americob
2 horas atrás, desconfiado disse:

O que são séries duplicadas?

Presumo que estivesse a falar da série para recolher faturas pelos duplicados, que tenham desaparecido do sistema ao fazer reposição da última cópia de segurança disponível, numa situação de perda total de dados.

 

  • Vote 2

Share this post


Link to post
Share on other sites
desconfiado
2 horas atrás, Larissa disse:

Estamos a certificar o software e a integração manual dos documentos é uma obrigatoriedade. O técnico da AT quer inclusive, que todos os campos do documento sejam manualmente editáveis pelo utilizador (no caso por exemplo, do utilizador cometer um erro de cálculo ou preenchimento na hora de fazer o documento manual). Ou seja, o software não pode fazer nenhum cálculo ou preenchimento automático dos campos do documento.

 

Isso parece-me um bocado  estúpido, Então agora o programa tem que deixar "alterar" os valores totais do documento?

Isto é à vontade do freguês... conforme o técnico que se apanha, as exigências são diferentes. Viva a tugalandia!

Share this post


Link to post
Share on other sites
desconfiado
Agora, americob disse:

Presumo que estivesse a falar da série para recolher faturas pelos duplicados, que tenham desaparecido do sistema ao fazer reposição da última cópia de segurança disponível, numa situação de perda total de dados.

 

Pois também pensei nisso mas achei estranho o termo "séries duplicadas" e fiquei na duvida. Isso não são séries "duplicadas", são séries de "Reposição".

Share this post


Link to post
Share on other sites
americob
2 minutos atrás, desconfiado disse:

Isso parece-me um bocado  estúpido, Então agora o programa tem que deixar "alterar" os valores totais do documento?

Isto é à vontade do freguês... conforme o técnico que se apanha, as exigências são diferentes. Viva a tugalandia!

Talvez sim ou talvez não.

Se uma fatura emitida manualmente num impresso em tipografia tem as contas mal feitas, se calhar o melhor seria anula-lo e emitir novamente um correto.

Mas, se não for anulada, é válida tal como está. Pode até ser corrigida mais tarde por uma Nota de Débito ou Nota de crédito.

Para todos os efeitos, mesmo depois de recolhida, o que fica válido é a fatura tipográfica, já que o sistema não deve deixar imprimir a fatura recolhida, ou se o fizer tem de dizer "cópia do documento original" e não terá qualquer valor fiscal.

 

  • Vote 1

Share this post


Link to post
Share on other sites
desconfiado
36 minutos atrás, americob disse:

Talvez sim ou talvez não.

Se uma fatura emitida manualmente num impresso em tipografia tem as contas mal feitas, se calhar o melhor seria anula-lo e emitir novamente um correto.

Mas, se não for anulada, é válida tal como está. Pode até ser corrigida mais tarde por uma Nota de Débito ou Nota de crédito.

Para todos os efeitos, mesmo depois de recolhida, o que fica válido é a fatura tipográfica, já que o sistema não deve deixar imprimir a fatura recolhida, ou se o fizer tem de dizer "cópia do documento original" e não terá qualquer valor fiscal.

 

Pois mas isso em termos de software é complicado e muito pouco seguro (deixar alterar valores totais). Daí a minha classificação de "estúpido".

E sim, o software deve permitir a impressão desses documentos com uma menção de "Cópia do documento  XTPO". Essa informação vem numa portaria qualquer que agora não me lembro. E esses documentos devem ser assinados tal como outro documento qualquer.

Share this post


Link to post
Share on other sites
bioshock

Viva, 

Surgiu-me aqui um problema giro.

Na emissão de FS apenas pode ser averbado o NIF o que significa que o cliente seleccionado é sempre o "Consumidor final", mas o NIF poderá tanto ser o "999999990" ou o que o cliente forneceu.

Tenham como exemplo o seguinte cenário:

FS 01 - Consumidor final - 210000000 (NIF averbado)
FS 02 - Consumidor final - 999999990 (NIF não averbado)
  1. Na exportação de SAF-T relativa à tag <MasterFiles> quantos <Customers> devem ser preenchidos?
  2. Na exportação de SAF-T relativa à tag <SourceDocuments> / <SalesInvoices> que valor deve  constar na tag <CustomerID>?

Actualmente, eu só crio 1 <Customer>:

<Customer>
	<CustomerID>Consumidor final</CustomerID>
	<AccountID>Desconhecido</AccountID>
	<CustomerTaxID>210000000</CustomerTaxID>
	<CompanyName>Consumidor final</CompanyName>
	<BillingAddress>
		<AddressDetail>Desconhecido</AddressDetail>
		<City>Desconhecido</City>
		<PostalCode>Desconhecido</PostalCode>
		<Country>Desconhecido</Country>
	</BillingAddress>
	<SelfBillingIndicator>0</SelfBillingIndicator>
</Customer>

Preenchimento da FS 01:

<Invoice>
    <InvoiceNo>FS A/1</InvoiceNo>
    <CustomerID>Consumidor final</CustomerID>
</Invoice>

Preenchimento da FS 02

<Invoice>
	<InvoiceNo>FS A/2</InvoiceNo>
	<CustomerID>Consumidor final</CustomerID>
</Invoice>

Problema: todas as facturas no e-factura vão ficar associadas ao cliente com o NIF 210000000 😅

Assim à 1ª vista, creio que poderia, em caso do NIF não ser o "999999990", criar outra tag <Customer> onde o valor de <CustomerId> seria "Consumidor final_210000000" e essa mesma identificação seria colocada na tag <Invoice>, faz sentido?

Edited by bioshock

Share this post


Link to post
Share on other sites
Vitor Pereira
3 minutos atrás, bioshock disse:

Viva, 

Surgiu-me aqui um problema giro.

Na emissão de FS apenas pode ser averbado o NIF o que significa que o cliente seleccionado é sempre o "Consumidor final", mas o NIF poderá tanto ser o "999999990" ou o que o cliente forneceu.

Tenham como exemplo o seguinte cenário:


FS 01 - Consumidor final - 210000000 (NIF averbado)
FS 02 - Consumidor final - 999999990 (NIF não averbado)
  1. Na exportação de SAF-T relativa à tag <MasterFiles> quantos <Customers> devem ser preenchidos?
  2. Na exportação de SAF-T relativa à tag <SourceDocuments> / <SalesInvoices> que valor deve  constar na tag <CustomerID>?

Actualmente, eu só crio 1 <Customer>:


<Customer>
	<CustomerID>Consumidor final</CustomerID>
	<AccountID>Desconhecido</AccountID>
	<CustomerTaxID>210000000</CustomerTaxID>
	<CompanyName>Consumidor final</CompanyName>
	<BillingAddress>
		<AddressDetail>Desconhecido</AddressDetail>
		<City>Desconhecido</City>
		<PostalCode>Desconhecido</PostalCode>
		<Country>Desconhecido</Country>
	</BillingAddress>
	<SelfBillingIndicator>0</SelfBillingIndicator>
</Customer>

Preenchimento da FS 01:


<Invoice>
    <InvoiceNo>FS A/1</InvoiceNo>
    <CustomerID>Consumidor final</CustomerID>
</Invoice>

Preenchimento da FS 02


<Invoice>
	<InvoiceNo>FS A/2</InvoiceNo>
	<CustomerID>Consumidor final</CustomerID>
</Invoice>

Problema: todas as facturas no e-factura vão ficar associadas ao cliente com o NIF 210000000 😅

Assim à 1ª vista, creio que poderia, em caso do NIF não ser o "999999990", criar outra ficha de cliente onde o valor de <CustomerId> seria "Consumidor final_210000000", faz sentido?

 

Não, não faz sentido sem pode ser !!!

Se o cliente não fornecedor um NIF, obrigatoriamente a Base de dados guarda e envia para o SAFT o "famoso"  999999990

Se o cliente fornecer um NIF e o mesmo for válido ( tem de ser validado antes de ser guardado, a não ser que seja cliente estrangeiro )

 

Share this post


Link to post
Share on other sites
bioshock
43 minutes ago, Vitor Pereira said:

 

Não, não faz sentido sem pode ser !!!

Se o cliente não fornecedor um NIF, obrigatoriamente a Base de dados guarda e envia para o SAFT o "famoso"  999999990

Se o cliente fornecer um NIF e o mesmo for válido ( tem de ser validado antes de ser guardado, a não ser que seja cliente estrangeiro )

 

Olá,

Acho que não percebeste (ou então eu não percebi?).

Quando está a ser emitida uma FS no software de facturação o cliente seleccionado é obrigatoriamente o "Consumidor final" (existe uma ficha de cliente denominada "Consumidor final" que não pode ser apagada / eliminada / alterada). No momento da FS o utilizador pode colocar ou não o contribuinte do cliente. Não é criado nenhuma ficha adicional caso tenha sido colocado um NIF, caso contrário seriam criadas sempre N fichas escusadamente.

No meu SAF-T só está a ser exportado um <Customer> quando na verdade devia ser exportado dois <Customers> pois apesar da ficha de cliente ser a mesma (Consumidor final em ambos) o NIF é diferente (210000000 & 999999990).

Consegues ver +/- onde quero chegar?

Obrigado.

Edited by bioshock

Share this post


Link to post
Share on other sites
Filipe Csota
4 horas atrás, bioshock disse:

Não é criado nenhuma ficha adicional caso tenha sido colocado um NIF, caso contrário seriam criadas sempre N fichas escusadamente.

No meu SAF-T só está a ser exportado um <Customer> quando na verdade devia ser exportado dois <Customers> pois apesar da ficha de cliente ser a mesma (Consumidor final em ambos) o NIF é diferente (210000000 & 999999990).

Sim e está correto. O que deverás fazer (e foi o que eu fiz para o meu software) é inserires um Customer a cada NIF diferente. Não é obrigatório teres a ficha de cliente para todo os NIFs. Tens é de colocar nos campos que são obrigatórios (AccountID ,AddressDetail, City, PostalCode, Country) a string "Desconhecido".

Share this post


Link to post
Share on other sites
desconfiado

Alguém me sabe dizer se o SAF-T da contabilidade pode ser exportado parcialmente ou se tem que ser na totalidade (Obrigatoriamente)?

 

Pergunto isto porque temos uma funcionalidade no programa para contabilidades cujo ano fiscal é diferente como por exemplo clubes de futebol. Neste caso e apesar de o período fiscal ser de Julho a Julho o programa tem bases de dados diferentes para cada ano. Isto complica a geração de 1 único ficheiro SAF-T. Mas temos um cliente que insiste que o SAF-T tem que ser único. Alguém sabe onde isto está indicado se é que está? 

Share this post


Link to post
Share on other sites
americob
2 horas atrás, desconfiado disse:

Alguém me sabe dizer se o SAF-T da contabilidade pode ser exportado parcialmente ou se tem que ser na totalidade (Obrigatoriamente)?

 

Pergunto isto porque temos uma funcionalidade no programa para contabilidades cujo ano fiscal é diferente como por exemplo clubes de futebol. Neste caso e apesar de o período fiscal ser de Julho a Julho o programa tem bases de dados diferentes para cada ano. Isto complica a geração de 1 único ficheiro SAF-T. Mas temos um cliente que insiste que o SAF-T tem que ser único. Alguém sabe onde isto está indicado se é que está? 

Conforme Portaria 302/2016, Anexo, nº1 alínea c):

Citação

c) A geração do ficheiro SAF-T (PT) pelos sistemas de informação deve ser sempre
efetuada para um determinado período anual de tributação, total ou parcial, desde
o início desse período até ao seu termo ou à data da geração se anterior.

Parece-me que a interpretação correta é que a geração é feita por exercício fiscal e que não podem haver 2 SAFT's para o mesmo exercício fiscal. Esse assunto tem sido muito debatido entre Contabilistas por causa da passagem de contabilidades entre eles a meio do ano.

Eu não tenho nenhum caso desses, mas já tenho isso mais ou menos previsto (idealizado) e a ideia é que tenho que ter na mesma 12 meses por cada exercício, mais o mês 13 para Regularizações, 14 para apuramentos, etc...

A grande diferença é que o mês 1 seria o Julho do ano n, o 2 seria o Agosto do ano n, …, e o 12 seria o Junho do ano n+1.

 

  • Vote 2

Share this post


Link to post
Share on other sites
americob
1 hora atrás, CFreitas disse:

Nas FAQs disponíveis no portal das finanças:

07-2740 É possível exportar o SAF-T (PT) por períodos inferiores ao ano fiscal?

O SAF-T (PT), regra geral, abrange um exercício fiscal completo. No que concerne à geração do SAF-T (PT) com os registos contabilísticos terá, obrigatoriamente, que contemplar o exercício fiscal completo num único ficheiro. Excecionalmente, e apenas por motivos técnicos associados à dimensão das tabelas dos documentos comerciais, é possível gerar o ficheiro SAF-T (PT) de faturação por períodos mensais completos - vide alíneas c), e) e i) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.

08-2741 É possível mudar de aplicação informática de contabilidade num momento não coincidente com o início do ano fiscal e iniciar a utilização do novo programa realizando apenas uma migração de saldos?

O SAF-T (PT) de contabilidade tem de ser gerado num único ficheiro. A nova aplicação de contabilidade terá que assegurar a geração do SAF-T (PT) com os registos efetuados na anterior aplicação ainda que reportados às novas referências e nomenclaturas acrescidos dos registos após a sua entrada em funcionamento. A transição dos registos para um novo programa de contabilidade num momento não coincidente com o início do ano fiscal não pode efetuar-se apenas com a migração de saldos.
A aplicação de contabilidade substituída também terá que assegurar a geração do SAF-T (PT) de contabilidade até ao momento da sua descontinuação - vide alíneas a), c) e e) do n.º 1 do Anexo I à Portaria n.º 302/2016, de 02 de dezembro.

 

Ou seja, o saft da contabilidade tem de ser sempre anual (exercício económico), começando no início do ano fiscal e acabando no fim (não são 12 meses quaisquer),  e quando há mudança de contabilista o novo tem de importar os lançamentos efetuados pelo anterior.

De referir ainda que nos casos em que o ano fiscal não coincide com o ano civil, no campo FiscalYear deve constar o ano de início.

É isso mesmo.

Só tenho duvidas em relação á minha interpretação, que o exemplo da AT não esclarece, quando o ano fiscal não coincide com o ano civil, é se o Campo "período" de cada transaction deve ser:

1 - Julho
2 - Agosto
3 - Setembro
4 - Outubro
5 - Novembro
6 - Dezembro
7 - Janeiro
8 - Fevereiro
9 - Março
10 - Abril
11 - Maio
12 - Junho

ou se deve ser:

7 - Julho
8 - Agosto
9 - Setembro
10 - Outubro
11 - Novembro
12 - Dezembro
1 - Janeiro
2 - Fevereiro
3 - Março
4 - Abril
5 - Maio
6 - Junho

 

  • Vote 1

Share this post


Link to post
Share on other sites
desconfiado

Obrigado ao CFreitas e ao americob pelo esclarecimento.

Share this post


Link to post
Share on other sites
bioshock

Olá,

Duas perguntas, uma relacionada com AT e outra menos offtopic:

O cliente engana-se e coloca a data de emissão de uma FT 2020-05-01, anula o documento logo de imediato mas fica impossibilitado de emitir um novo documento com a data correcta (2020-03-14), pois segundo o Despacho n.º 8632/2014 "Após essa emissão, não poderá ser emitido um novo documento com a data actual/anterior dentro da mesma série". Eu faço exactamente isto, mas fiquei na dúvida se havendo anulação mantêm-se a restrição acima transcrita? 

O meu software é online e sempre foi idealizado e construído para que cada cliente tenha a sua base de dados independente, já aquando a certificação de 2017 esta foi uma pergunta que os inspectores fizeram, no entanto tenho identificado alguns softwares de facturação online (através de alguns pontos de identificação nos formulários das suas páginas) que utilizam unicamente uma base de dados, como me parece ser o caso do Moloni.

Ter uma base de dados independente tem algumas vantagens, mas também tem muitas desvantagens, nomeadamente quando existem funcionalidades que requerem Cronjobs ou quando se começa a ter uma base de clientes significativa, pois por cada cliente existe 1 base de dados. Se houver 1000 clientes a utilizar a plataforma existe obrigatoriamente 1000 base de dados e por aí adiante.

Esta situação é um ponto meramente de debate interno de quem desenvolve ou há alguma restrição regulamentada que obrigue o uso de base de dados independentes?

Share this post


Link to post
Share on other sites
Vitor Pereira
13 minutos atrás, bioshock disse:

Olá,

Duas perguntas, uma relacionada com AT e outra menos offtopic:

O cliente engana-se e coloca a data de emissão de uma FT 2020-05-01, anula o documento logo de imediato mas fica impossibilitado de emitir um novo documento com a data correcta (2020-03-14), pois segundo o Despacho n.º 8632/2014 "Após essa emissão, não poderá ser emitido um novo documento com a data actual/anterior dentro da mesma série". Eu faço exactamente isto, mas fiquei na dúvida se havendo anulação mantêm-se a restrição acima transcrita? 

O meu software é online e sempre foi idealizado e construído para que cada cliente tenha a sua base de dados independente, já aquando a certificação de 2017 esta foi uma pergunta que os inspectores fizeram, no entanto tenho identificado alguns softwares de facturação online (através de alguns pontos de identificação nos formulários das suas páginas) que utilizam unicamente uma base de dados, como me parece ser o caso do Moloni.

Ter uma base de dados independente tem algumas vantagens, mas também tem muitas desvantagens, nomeadamente quando existem funcionalidades que requerem Cronjobs ou quando se começa a ter uma base de clientes significativa, pois por cada cliente existe 1 base de dados. Se houver 1000 clientes a utilizar a plataforma existe obrigatoriamente 1000 base de dados e por aí adiante.

Esta situação é um ponto meramente de debate interno de quem desenvolve ou há alguma restrição regulamentada que obrigue o uso de base de dados independentes?


Um documento com data errada ( por avanço ) pode ser anulado, mas seja anulado ou não é OBRIGATÓRIO encerrar a Série e abrir uma nova

Nao é permitido por lei que depois de anularmos um documento possamos fazer outros com data inferior ao documento anulado 

  • Vote 1

Share this post


Link to post
Share on other sites
bioshock
1 hour ago, Vitor Pereira said:


Um documento com data errada ( por avanço ) pode ser anulado, mas seja anulado ou não é OBRIGATÓRIO encerrar a Série e abrir uma nova

Nao é permitido por lei que depois de anularmos um documento possamos fazer outros com data inferior ao documento anulado 

Obrigado, é essa lógica que tenho desde 2017, mas como recentemente houve dois casos com essa situação, quis reconfirmar. 

Edited by bioshock

Share this post


Link to post
Share on other sites
CrominhO
Em 14/03/2020 às 16:09, bioshock disse:

(...)O meu software é online e sempre foi idealizado e construído para que cada cliente tenha a sua base de dados independente, já aquando a certificação de 2017 esta foi uma pergunta que os inspectores fizeram, no entanto tenho identificado alguns softwares de facturação online (através de alguns pontos de identificação nos formulários das suas páginas) que utilizam unicamente uma base de dados, como me parece ser o caso do Moloni.(...)

Eu tenho, entre outros, SaaS desde os primórdios, e tanto quanto sei tens de disponibilizar os dados aos clientes mesmo que estes não paguem. Isto foi-me dito pela AT na altura e voltaram a dizer mais tarde. 

Repara, se "alugas" um software e o cliente deixa de pagar, podes fazer com que o software deixe de  "funcionar", deixar de tirar o SAFT, etc.... O que não podes fazer, é um cliente deixar de pagar em Fevereiro por exemplo e ele não poder retirar os dados durante todo o tempo que utilizou, até porque, os dados são dele e não nossos, e ele precisa deles durante 5 anos se a memória não me falha. 

 O @CFreitas tem razão e no caso de um cliente cancelar um software, ou das-lhes hipótese de tirar um Backup completo ou envias-lhe tu de maneira a que não fiques responsável por o cliente não ter nada :-)  ... Recordo-me que na altura, a AT falou em "dados legíveis" seja lá o que isso for lol :D ... mas podes sempre exportar as tabelas e entregar em texto ou algo do género :-)  

  • Vote 2

As mentes humanas são realmente um local estranho!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.