Jump to content
marcolopes

AT - questões legais

Recommended Posts

marcolopes

DÚVIDA no código L do CÓDIGO QR

Quote

        /*
         * L
         * Nao sujeito / nao tributavel em IVA
         * 16
         * Valor total relativo a operacoes nao sujeitas / nao tributaveis em IVA.
         * Formatar com duas casas decimais, com “.” como separador decimal
         * e sem separador de milhares.
         * L:100.00
         * ++
         */
 

De acordo com a tabela SAFT (TaxType) temos

Quote

    /*
     * No caso do Codigo do tipo de imposto (TaxType)=IVA,
     * deve ser preenchido com:
     * "RED" - Taxa reduzida;
     * "INT" - Taxa intermedia;
     * "NOR" - Taxa normal;
     * "ISE" - Isenta;
     * "OUT" - Outros, aplicavel para os regimes especiais de IVA.
     * No caso do campo 2.5.1.1. - Codigo do tipo de imposto (TaxType)="IS",
     * deve ser preenchido com o codigo da verba respetiva.
     * No caso de nao sujeicao deve ser preenchido com "NS".
     */
 

NÃO SUJEITO é relativo ao caso "NS" da tabela TaxType...

E o NÃO TRIBUTÁVEL?

Devemos aqui incluir os casos  "OUT" da tabela TaxType?

Edited by marcolopes

The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
João Januário
17 minutos atrás, marcolopes disse:

DÚVIDA no código L do CÓDIGO QR

De acordo com a tabela SAFT (TaxType) temos

NÃO SUJEITO é relativo ao caso "NS" da tabela TaxType...

E o NÃO TRIBUTÁVEL?

Devemos aqui incluir os casos  "OUT" da tabela TaxType?

Boas,

Sem ter certezas sobre isso fiz como estás a dizer. 

Share this post


Link to post
Share on other sites
marcolopes
8 minutes ago, João Januário said:

Boas,

Sem ter certezas sobre isso fiz como estás a dizer. 

somando NS e OUT?


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
João Januário
11 horas atrás, marcolopes disse:

somando NS e OUT?

No nosso software só temos Taxype=IVA logo só temos o OUT.

A minha dedução prende-se com o motivo de isenção: M99
Não sujeito; não tributado (ou similar)
Outras situações de não liquidação do imposto (Exemplos: artigo 2.º, n.º 2 ; artigo 3.º, n.ºs 4, 6 e 7; artigo 4.º, n.º 5, todos do CIVA)

E quando a IVA, utilizado, se enquadra em OUT "Outros, aplicável para os regimes especiais de IVA." considero que é NS.

Mas também podemos ser mais restritos e considerar que só devemos colocar em NS quando temos OUT + o motivo M99. Porque não sei se os outros motivos se enquadram todos em Isenções.

Mas como te disse, não tenho certezas sobre isto. Mas é uma questão pertinente até para a classificação dos códigos de IVA/Motivos.

Share this post


Link to post
Share on other sites
Sérgio Lourenço
14 horas atrás, Jose Lindo disse:

Boas

 

Tenho estado a acompanhar o que têm escrito e no meu entender o código identificador da serie será dado ao par TipoDoc+Serie.

Deste modo para a mesma serie e dois TiposDoc teremos dois códigos diferentes

Para o mesmo TipoDoc e duas series, iremos tb ter dois códigos diferentes.

A seguir o ATCUD será Código da serie - Numero do doc. Isto não é mais do que TpDoc Serie/numeroDoc mas escrito de maneira diferente.

Não esquecer que o Código da serie Atribuído representa TipoDoc + Serie.

Para outro par TipoDoc+Serie em que varie 1 ou os 2 elementos em relação ao Anterior (conjunto TipoDoc+Serie) novo Código será atribuído

Tudo muito bem mas o "TipoDoc" é o que que eles identificam como «Tipo de documento» e «Tipo de recibo» do grupo de dados «Documentos
comerciais».

A questão aqui prende-se com o facto de, para o mesmo "TipoDoc" poder haver mais que um "código interno".
Eu posso ter 2 tipos de documento do tipo "FT" mas um tem o código interno "FT" e o outro "FR", e cada um dos tipos com as suas séries.
Ou seja, no SAFT sao todos InvoiceType = "FT", mas no InvoiceNo uns começam por "FT 1/..." e outros por "FR 1/..."

Exemplos de alguns documentos:

FT 1/1 = TipoDoc "FT"; Serie 1
FT 1/2 = TipoDoc "FT"; Serie 1
FR 1/1 = TipoDoc "FT"; Serie 1 (este colide com o primeiro pois o "TipoDoc" é "FT" mas o código interno é "FR")
FT 1/3 = TipoDoc "FT"; Serie 1
FR 2/1 = TipoDoc "FT"; Serie 2
FR 2/2 = TipoDoc "FT"; Serie 2

A única hipótese que eu vejo é, como já foi dito por alguém aqui, o que eles chamam de "identificador da série" não ser apenas o "1" mas sim "FT 1" ou "FR 1".

Share this post


Link to post
Share on other sites
car4321
58 minutos atrás, Sérgio Lourenço disse:

Tudo muito bem mas o "TipoDoc" é o que que eles identificam como «Tipo de documento» e «Tipo de recibo» do grupo de dados «Documentos
comerciais».

A questão aqui prende-se com o facto de, para o mesmo "TipoDoc" poder haver mais que um "código interno".
Eu posso ter 2 tipos de documento do tipo "FT" mas um tem o código interno "FT" e o outro "FR", e cada um dos tipos com as suas séries.
Ou seja, no SAFT sao todos InvoiceType = "FT", mas no InvoiceNo uns começam por "FT 1/..." e outros por "FR 1/..."

Exemplos de alguns documentos:

FT 1/1 = TipoDoc "FT"; Serie 1
FT 1/2 = TipoDoc "FT"; Serie 1
FR 1/1 = TipoDoc "FT"; Serie 1 (este colide com o primeiro pois o "TipoDoc" é "FT" mas o código interno é "FR")
FT 1/3 = TipoDoc "FT"; Serie 1
FR 2/1 = TipoDoc "FT"; Serie 2
FR 2/2 = TipoDoc "FT"; Serie 2

A única hipótese que eu vejo é, como já foi dito por alguém aqui, o que eles chamam de "identificador da série" não ser apenas o "1" mas sim "FT 1" ou "FR 1".

É exatamente como dizes, e já referi isto atrás.

Na portaria 202_2016, define-se a Identificação única do documento de venda (InvoiceNo):

"Esta identificação é composta sequencialmente pelos seguintes elementos: o código interno do tipo de documento atribuído pela aplicação, um espaço, o identificador da série do documento, uma barra (/) e o número sequencial desse documento dentro dessa série."

Com rigor, o identificador da série é o que vem depois do código interno.

Em termos práticos, eles esqueceram-se disso nestas especificações técnicas, e puseram apenas o termo  identificador da série, a pensar que já inclui o código interno. Haverá uma correção das especificações, ou então no momento de enviar os dados da série, vão requerer o código interno na submissão.

 

Edited by car4321
  • Vote 2

Share this post


Link to post
Share on other sites
marcolopes
4 hours ago, João Januário said:

No nosso software só temos Taxype=IVA logo só temos o OUT.

A minha dedução prende-se com o motivo de isenção: M99
Não sujeito; não tributado (ou similar)
Outras situações de não liquidação do imposto (Exemplos: artigo 2.º, n.º 2 ; artigo 3.º, n.ºs 4, 6 e 7; artigo 4.º, n.º 5, todos do CIVA)

E quando a IVA, utilizado, se enquadra em OUT "Outros, aplicável para os regimes especiais de IVA." considero que é NS.

Mas também podemos ser mais restritos e considerar que só devemos colocar em NS quando temos OUT + o motivo M99. Porque não sei se os outros motivos se enquadram todos em Isenções.

Mas como te disse, não tenho certezas sobre isto. Mas é uma questão pertinente até para a classificação dos códigos de IVA/Motivos.

Era o que faltava agora ter de analisar todas as linhas do documento para classificar os totais de IVA por MOTIVO de ISENÇÃO...

Estou a basear-me no tabela de resumo de IVA que já separa todas os "códigos", por tipo de taxa e espaço fiscal...


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
João Januário
6 horas atrás, marcolopes disse:

Era o que faltava agora ter de analisar todas as linhas do documento para classificar os totais de IVA por MOTIVO de ISENÇÃO...

Estou a basear-me no tabela de resumo de IVA que já separa todas os "códigos", por tipo de taxa e espaço fiscal...

Estive a analisar melhor e acho que é uma falsa questão:

 

Saft

(4.2.3.21.12.1.) Código do tipo de imposto (TaxType)

Neste campo deve ser indicado o tipo
de imposto.
Deve ser preenchido com:
"IVA" - Imposto sobre o valor acrescentado;
"IS" - Imposto de Selo.
"NS" - Não sujeição a IVA ou IS.

O código OUT (Outros, aplicável para os regimes especiais de IVA) pertence ao tipo de imposto IVA porque é uma isenção, logo não está incluído no NS. Por isso, vou colocar os valores deste no campos de isenção.

 

Share this post


Link to post
Share on other sites
bubbu78

Caros colegas de luta,

Relativamente ao QRCode, ainda nao consegui perceber em que documentos deve ser impresso. É somente nas faturas ou em todos os documentos comunicáveis no SAFT (via SourceDocuments, MovementOfGoods e Payments)?

No exemplo da AT nas especificações técnicas estão proformas e guias de transporte, pelo que fiquei meio baralhado...

Obrigado!

Share this post


Link to post
Share on other sites
car4321
33 minutos atrás, bubbu78 disse:

Caros colegas de luta,

Relativamente ao QRCode, ainda nao consegui perceber em que documentos deve ser impresso. É somente nas faturas ou em todos os documentos comunicáveis no SAFT (via SourceDocuments, MovementOfGoods e Payments)?

No exemplo da AT nas especificações técnicas estão proformas e guias de transporte, pelo que fiquei meio baralhado...

Obrigado!

Artigo 6.º

Inclusão do código de barras bidimensional (código QR)

1 — Os produtores devem garantir a correta geração do código de barras bidimensional

(código QR) que deve constar obrigatoriamente nas faturas e outros documentos fiscalmente

relevantes,

 

 

São considerados documentos fiscalmente relevantes todos os documentos "formais" para além das faturas e notas de crédito: documentos de transporte, recibos..., como está definido no DL 28/2019, Artigo 2.

Edited by car4321

Share this post


Link to post
Share on other sites
João Januário
23 horas atrás, car4321 disse:

É exatamente como dizes, e já referi isto atrás.

Na portaria 202_2016, define-se a Identificação única do documento de venda (InvoiceNo):

"Esta identificação é composta sequencialmente pelos seguintes elementos: o código interno do tipo de documento atribuído pela aplicação, um espaço, o identificador da série do documento, uma barra (/) e o número sequencial desse documento dentro dessa série."

Com rigor, o identificador da série é o que vem depois do código interno.

Em termos práticos, eles esqueceram-se disso nestas especificações técnicas, e puseram apenas o termo  identificador da série, a pensar que já inclui o código interno. Haverá uma correção das especificações, ou então no momento de enviar os dados da série, vão requerer o código interno na submissão.

 

Boas,

Penso não estar a exagerar, mas se for para incluir os pagamentos também temos de garantir que o código interno dos recibos não sejam iguais aos dos documentos comercias.

Share this post


Link to post
Share on other sites
João Januário
8 minutos atrás, car4321 disse:

Artigo 6.º

Inclusão do código de barras bidimensional (código QR)

1 — Os produtores devem garantir a correta geração do código de barras bidimensional

(código QR) que deve constar obrigatoriamente nas faturas e outros documentos fiscalmente

relevantes,

 

 

São considerados documentos fiscalmente relevantes todos os documentos "formais" como faturas, notas de crédito, documentos de transporte, recibos..., como está definido no DL 28/2019, Artigo 2.

Boas,

 

No caso dos recibos como vamos preencher o campo dos 4 carateres da Hash?

Share this post


Link to post
Share on other sites
car4321
12 minutos atrás, João Januário disse:

Boas,

 

No caso dos recibos como vamos preencher o campo dos 4 carateres da Hash?

O campo é obrigatório. Não sendo produzido o hash, e não existindo instruções, resulta "Q:"

Share this post


Link to post
Share on other sites
marcolopes
2 hours ago, João Januário said:

Boas,

No caso dos recibos como vamos preencher o campo dos 4 carateres da Hash?

Voltamos à velha história!!! A minha interpretação é que os RECIBOS (pelo menos os de IVA de caixa) são fiscalmente relevantes, como tal, são assinados, como tal...

Fazendo parte da estrutura do SAFT; assino e comunico todos os recibos, como tal...


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
Sérgio Lourenço

Eu:

Bom dia. A portaria 195/2020 que entrará em vigor a 1 de janeiro de 2021 diz que (entre outras coisas) os sujeitos passivos devem comunicar o identificador das séries dos documentos. Isto é, para efeitos de facturação, o sujeito passivo deverá informar à AT quais as séries de documentos que tem. A nossa questão é: Como pretendem que esta comunicação seja efectuada?
Na portaria não indica se deve ser feita por e-mail, por webservice, ou por outro qualquer processo.
Além disso, é suposto para cada série ser respondido pela AT um código de validação necessário para o código QR a imprimir nas facturas e a portaria também não indica como será respondido esse código.
Podem esclarecer-nos sobre isso?
Obrigado.

 

AT:

A Autoridade Tributária e Aduaneira (AT) agradece o seu contacto.
Informa-se que os critérios e modo de comunicação das séries documentais em utilização previstos no art.º 35.º do Decreto-Lei n.º 28/2019 serão oportunamente divulgados no Portal da Finanças.
Com os melhores cumprimentos
AT- Autoridade Tributária e Aduaneira

Edited by Sérgio Lourenço

Share this post


Link to post
Share on other sites
car4321
5 horas atrás, marcolopes disse:

Voltamos à velha história!!! A minha interpretação é que os RECIBOS (pelo menos os de IVA de caixa) são fiscalmente relevantes, como tal, são assinados, como tal...

Fazendo parte da estrutura do SAFT; assino e comunico todos os recibos, como tal…

 

No SAFT não há campo do hash para os recibos.

Em relação aos Requisitos técnicos dos programas de faturação, o Despacho n.º 8632/2014 – 03/07 não refere "documentos fiscalmente relevantes":

2.1 - Processo de assinatura para identificação de documentos:

2.1.1 - No processo de identificação de documentos, nomeadamente, fatura ou documento retificativo, documento que acompanhe mercadorias em circulação, valorado ou não, documentos emitidos para conferência, etc., deverá sempre ser gerada uma assinatura através do algoritmo RSA com base na informação relativa ao documento descrita no n.º 1 do artigo 6.º ou no n.º 2 do artigo 7.º da Portaria n.º 363/2010, de 23 de junho e na chave privada do produtor do programa de faturação.


Claro que quem quiser pode assinar os recibos e, nesse caso, o problema fica resolvido.

Share this post


Link to post
Share on other sites
Jose Lindo
Em 27/08/2020 às 12:01, Sérgio Lourenço disse:

Tudo muito bem mas o "TipoDoc" é o que que eles identificam como «Tipo de documento» e «Tipo de recibo» do grupo de dados «Documentos
comerciais».

A questão aqui prende-se com o facto de, para o mesmo "TipoDoc" poder haver mais que um "código interno".
Eu posso ter 2 tipos de documento do tipo "FT" mas um tem o código interno "FT" e o outro "FR", e cada um dos tipos com as suas séries.
Ou seja, no SAFT sao todos InvoiceType = "FT", mas no InvoiceNo uns começam por "FT 1/..." e outros por "FR 1/..."

Exemplos de alguns documentos:

FT 1/1 = TipoDoc "FT"; Serie 1
FT 1/2 = TipoDoc "FT"; Serie 1
FR 1/1 = TipoDoc "FT"; Serie 1 (este colide com o primeiro pois o "TipoDoc" é "FT" mas o código interno é "FR")
FT 1/3 = TipoDoc "FT"; Serie 1
FR 2/1 = TipoDoc "FT"; Serie 2
FR 2/2 = TipoDoc "FT"; Serie 2

A única hipótese que eu vejo é, como já foi dito por alguém aqui, o que eles chamam de "identificador da série" não ser apenas o "1" mas sim "FT 1" ou "FR 1".

boas

O TipoDoc é o TipoDoc que tu crias-te, é o tipoDoc usado na identificação do teu documento independente da classe onde se enquadre.

No teu exemplo FT e FR sao dois tipos de documentos distintos, independente a que pertencem a mesma Classe (Facturas). Por exemplo não podes ter FX na classe de documentos de facturas e ter tb no mesmo software um FX na classe dos recibos.

 

O tipodoc interno !!!.

Não é interno, é a sigla que definiste (FA, FR, etc) para identificar o TipoDoc que é impresso que identifica o documento, que entra na assinatura e que identifica o conjunto de dados na transmissão do saft, docTransporte, etc.

Para o teu FT 1 e FR 1, de certeza que vais ter de requerer os codigos para dois tipos de documentos  e neste caso vais obter dois códigos distintos

Alias, na informação a enviar para requerer o código da serie, é necessário enviar o TipoDoc associado a serie.

 

No software existente na empresa onde trabalho, temos series por ano, (19,20, 21) e dentro da mesma serie tenho vários tipos documentos (por exemplo nas facturas) em função da área de facturação. Por exemplo tenho FA, FAC, FD, que identifica a Área de artigo que é facturado. Por exemplo FA - Facturas de Rolos de Tecidos (facturacao em Metragem), FAC - Facturas de Amostras de Tecido (facturacao em Metragem ou/e Quantidades de itens), FD -Facturas Diversas (Facturacao em qtd Itens), etc

 

 

Edited by Jose Lindo
update

Share this post


Link to post
Share on other sites
americob
23 horas atrás, marcolopes disse:

Voltamos à velha história!!! A minha interpretação é que os RECIBOS (pelo menos os de IVA de caixa) são fiscalmente relevantes, como tal, são assinados, como tal...

Fazendo parte da estrutura do SAFT; assino e comunico todos os recibos, como tal...

Os Recibos do Regime do IVA de Caixa, são documentos fiscalmente relevantes que conferem deveres e direitos, respetivamente ao emitente e ao adquirente, em termos de liquidação e dedução do IVA. Por isso têm de ser emitidos cronologicamente e comunicados à AT.

Os outros recibos não são documentos fiscalmente relevantes. No meu caso, permito que sejam emitidos fora da ordem cronológica, nomeadamente para registar o "recebimento" de cheques pré-datados cujo recibo é datado com a data do cheque que é a data efetiva do recebimento.

Tenho outros casos que emitem recibos porque os comerciais precisam dos recibos para efetuar a cobrança quando visitam os clientes, e precisam deles e só os datam quando efetivamente recebem.

Tenho ainda clientes em que o recibo é apenas uma das vias da fatura, sendo posteriormente registado no software o "recebimento".

A AT não conhece a realidade do país, mas não me parece legitimo querer alterar os procedimentos das empresas, e obrigar todas a trabalhar da mesma forma, só porque sim.

Se a AT insistir nesta paranoia, passarei a ter "Recibos" e "Recebimentos". Assim, os "Recebimentos" já não terão de ir no SAFT.

Share this post


Link to post
Share on other sites
brunotoira
Em 20/08/2020 às 17:02, CrominhO disse:

Bruno no Delphi não tás a passar o correction level pois não? 

No Java aparece, em Delphi não me aparece, para já ignorei e ele vai gerindo sozinho. 

EXATAMENTE,

edita a unit ZXing...

  • Vote 1

Source code para enviar Guias de Transporte

Source code para enviar UBL - Faturação Eletrónica (XML de faturas e validador) - bmartins.p45@gmail.com

QRCode ATCUD https://www.portugal-a-programar.pt/forums/topic/77364-at-questões-legais/?do=findComment&comment=619124

 

 

Share this post


Link to post
Share on other sites
Sérgio Lourenço
Em 29/08/2020 às 14:26, Jose Lindo disse:

Alias, na informação a enviar para requerer o código da serie, é necessário enviar o TipoDoc associado a serie.

Eu espero que sim mas não é o que até à data nos foi comunicado pois na portaria 195/2020 apenas dizem:
"O identificador da série do documento;" e "O tipo de documento, de acordo com as tipologias documentais"
Infelizmente para eles o "identificador da série" é a parte apenas do número da série depois do código interno e antes da barra.
Quanto ao "tipo do documento" para eles é a classe onde se enquadra.

Analisa bem a portaria 302/2016 e a 195/2020.

Edited by Sérgio Lourenço

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.