AT - questões legais

[marcolopes]

Foi publicado pela Autoridade Tributária e Aduaneira o Ofício-circulado n.º 50001/2013 - 04/07 - Gab SDG da IT - Requisitos técnicos a que se refere a al. e) do artigo 3.º da Portaria n.º 363/2010, de 23 de junho, que visa esclarecer em particular os autores de software acerca das regras de emissão e integração de documentos por sistemas de software de certificação, das regras de emissão do ficheiro normalizado SAF-T PT, bem como dos critérios de avaliação subjacentes ao processo de Certificação de Software de Faturação.

http://info.portaldasfinancas.gov.pt/NR/rdonlyres/60461985-58EC-4E4B-BCCC-F5B561C94629/0/Of%C3%ADcioCirculadon_50001.pdf

Saliento estes pontos:

3. REQUISITOS A OBSERVAR PELA APLICAÇÃO

3.1. A aplicação deve possuir:

3.1.1. Adequados controlos de acessos devendo obrigar o utilizador a alterar a palavra passe (password) no primeiro acesso (a nova palavra passe não pode ser vazia e o administrador não a pode conhecer ou visualizar). O administrador poderá despoletar o processo de criação de uma nova password, a qual deve ser também alterada, logo que acedida.

3.1.2. Implementada uma política de cópias de segurança de periodicidade obrigatória de forma a minimizar o volume de dados a recuperar em caso de corrupção da base de dados e/ou a manutenção de duas ou mais base de dados simultâneas para que quando uma se corrompa a(s) outra(s) assegure(m) a continuidade da facturação.

3.1.3. Controlo direto ou indireto da base de dados que utiliza e o registo do n.º de reposições de cópias de segurança (backup) efetuadas.

3.2. A aplicação deve assegurar:

3.2.1. A sequenciação da numeração comparativamente à evolução da data e hora de emissão dos documentos;

3.2.2. A garantia de que não existe mais de que um documento activo (com os campos 4.1.4.2.1., 4.2.3.2.1, ou 4.3.4.2.1 relativos ao estado atual do documento de valor “N”) proveniente da recolha do mesmo documento manual;

3.2.3. O cumprimento dos requisitos elencados no n.º 1 do artigo 9.º da portaria n.º 363/2010, de 23 de junho, quando emite qualquer documento de conferência da prestação de serviços.

3.3. A aplicação não pode permitir:

3.3.1. Ser o utilizador a definir quais os tipos de documentos que são assinados e/ou exportáveis para o SAF-T(PT), especialmente, os que foram criados ou modificados por aquele.

3.3.2. O processamento de qualquer cálculo sobre documentos recolhidos ou resultantes de integração de outros sistemas. Assim, se porventura, existir uma incorrecta determinação de imposto, esse erro deve ser evidenciado na base de dados integradora, por resultar de um documento já entregue.

3.3.3. A alteração do NIF, numa ficha de cliente já existente e com documentos emitidos. Só podepermitir a alteração da denominação e da morada desse cliente, se tal vier a acontecer, pois o NIF manter-se-á nesses casos.

3.3.4. A alteração do nome e da morada numa ficha de cliente já existente e com documentos emitidos, mas cujo NIF não foi fornecido (neste âmbito não é considerado o NIF do cliente genérico 999999990), Neste caso poderá ser averbado o NIF em falta e após esse averbamento actuar de acordo com o ponto anterior.

3.3.5. A alteração numa ficha de produto já existente e com documentos emitidos, do campo 2.4.4. – Descrição do produto ou serviço (ProductDescription).

3.3.6. A criação de notas de crédito relativas a documentos anteriormente anulados ou já totalmente retificados.

3.3.7. A anulação de documentos sobre os quais já tenha sido emitido documento retificativo (nota de crédito ou débito) ainda que parcial.

3.3.8. A aceitação de devoluções em documentos de venda ou transmissões em documentos de retificação.

[Cr4zyKingLi0n]

Pro

Foi publicado pela Autoridade Tributária e Aduaneira o Ofício-circulado n.º 50001/2013 - 04/07 - Gab SDG da IT - Requisitos técnicos a que se refere a al. e) do artigo 3.º da Portaria n.º 363/2010, de 23 de junho, que visa esclarecer em particular os autores de software acerca das regras de emissão e integração de documentos por sistemas de software de certificação, das regras de emissão do ficheiro normalizado SAF-T PT, bem como dos critérios de avaliação subjacentes ao processo de Certificação de Software de Faturação.

http://info.portaldasfinancas.gov.pt/NR/rdonlyres/60461985-58EC-4E4B-BCCC-F5B561C94629/0/Of%C3%ADcioCirculadon_50001.pdf

Saliento estes pontos:

Provavelmente e como já referiste este ano é para afinar o software com a At. E não me admirava que haja nova certificação no próximo ano.

[nunopicado]

Então e diz lá que não é d'homem...

O meu não é, nem precisa ser, certificado... E ainda assim, há-de cumprir os requisitos como se fosse!

Lindo, não? eheheheh

[marcolopes]

Então e diz lá que não é d'homem...

O meu não é, nem precisa ser, certificado... E ainda assim, há-de cumprir os requisitos como se fosse!

Lindo, não? eheheheh

Lindo? Aberrações como ESTA?

3.1.3. Controlo direto ou indireto da base de dados que utiliza e o registo do n.º de reposições de cópias de segurança (backup) efetuadas.

Quem escreveu isto não está no seu perfeito juízo!

O Software vai ter "poderes mentais" para persuadir o utilizador a não efetuar backups / restores manuais, e controlar caso o tenha feito!

Sinceramente? Falta lá um ponto MUITO IMPORTANTE: A base de dados TEM DE ESTAR ENCRIPTADA! (e já agora, com RSA 2048!). TAU... (sarcasmo!) Isso sim seria um requisito aliciante para os produtores de software! :-\

Mais uns anos e vamos chegar ao que já previ há muito: Vai exsitir uma aplicação GERAL, desenvolvida para a AT, que pode ser usada por todos. Os dados estão do lado da AT, e como tal, beneficiam de estar isentos de envios, comunicações, e afins.

Edited July 5, 2013 at 09:03 PM by marcolopes

[nelsonr]

Sinceramente? Falta lá um ponto MUITO IMPORTANTE: A base de dados TEM DE ESTAR ENCRIPTADA! (e já agora, com RSA 2048!). TAU... (sarcasmo!) Isso sim seria um requisito aliciante para os produtores de software! :-\

Olha que logo no inicio da certificação eles iam nesse caminho, que devíamos certificar que ninguém conseguisse ter acesso aos dados.

[nunopicado]

Lindo? Aberrações como ESTA?

Pois é... Mas de repente lembram-se de revogar a excepção à lei da certificação (do software produzido internamente) e depois estou tramado, pois como é lógico, depois não há tempo para nada.

Mais vale te-la já pronta, e a qualquer momento olha, manda-se certificar.

A propósito, quanto é que se paga para certificar a aplicação?

O Software vai ter "poderes mentais" para persuadir o utilizador a não efetuar backups / restores manuais, e controlar caso o tenha feito!

Então, isto é de quem nunca trabalhou na vida... pelo menos nesta área.

1º Não há como controlar

2º Mesmo que houvesse, e fosse impossibilitada a copia manual, eu sempre queria ver o que fariam quando a aplicação fosse ao ar e não fosse possível fazer cópia.

- "Ah e tal, mas tens de ter copias regulares!"

- Sim claro, e todos nós sabemos que os clientes são muito cumpridores, que os discos não avariam, que sempre tudo corre como no papel, ou na iluminada cabeça de um legislador qualquer.

Sinceramente? Falta lá um ponto MUITO IMPORTANTE: A base de dados TEM DE ESTAR ENCRIPTADA! (e já agora, com RSA 2048!). TAU... (sarcasmo!) Isso sim seria um requisito aliciante para os produtores de software!

Xiuuuu! Cala-te! Não dês ideias!

Mais uns anos e vamos chegar ao que já previ há muito: Vai exsitir uma aplicação GERAL, desenvolvida para a AT, que pode ser usada por todos. Os dados estão do lado da AT, e como tal, beneficiam de estar isentos de envios, comunicações, e afins.

Tu não és mesmo capaz de ficar calado pois não? 😉 Já te disse, não dês ideias.

Aqui entre nós, esta última também me parece que assim será.

Aliás, parte disso já está online, com as guias no portal.

Alguém quer mesmo arriscar uma aposta sobre quanto tempo falta para fazerem o mesmo com as facturas?

Edited July 5, 2013 at 09:04 PM by thoga31

[marcolopes]

Tu não és mesmo capaz de ficar calado pois não? 😉 Já te disse, não dês ideias.

Aqui entre nós, esta última também me parece que assim será.

Aliás, parte disso já está online, com as guias no portal.

Alguém quer mesmo arriscar uma aposta sobre quanto tempo falta para fazerem o mesmo com as facturas?

Então toma lá esta:

A OTOC está a tentar fazer isso mesmo com a sua plataforma... estou curioso para saber qual tem sido a adesão: https://app.toconline.pt/

EU, neste momento, se tivesse de escolher entre as CENTENAS de softwares de facturação, incluíndo das DEZENAS que correm via WEB - e bem jeitosos - escolheria o TOCONLINE - pelo simples motivo destes senhores terem fundos quase "ilimitados", uma equipa de LUXO (tanto quanto sei) a trabalhar na plataforma - e - um CANAL de comunicação PRIVELIGIADO com fisco (pois este não faz grande coisa sem a opinião da OTOC...)

Dou poucos anos para que este sistema "pulverize" grande parte das pequenas e médias empresas de software... resta saber se os contabilistas são mecanismo de persuasão / publicidade suficiente.

Prepare a sua faturação em segundos. De uma forma totalmente simplificada pode criar documentos com um aspecto profissional e enviar eletronicamente aos seus clientes, evitando custos desnecessários de impressão e correio.

O toconline é um sistema de faturação electrónica certificado pela Autoridade Tributária (Certificado Nº 1662 de 21-12-2012)

Principais Características:

- Orçamentos e Faturas Pró-Forma

- Documentos de transporte

- Faturas e Faturas Simplificadas (Multi-moeda, Retenção na fonte)

- Faturação recorrente (Avenças)

- Contas correntes

- Mapas de análise de gestão e de tesouraria

Aliado a um Arquivo documental, está aqui a "papinha" toda, por ZERO euros (para 3 priveligiados convidados pelos TOC) e uns míseros euros mensais para o resto das adesões. Os contabilistas agradecem, pois têm tudo o que precisam numa mesma plataforma... e nós estamos todos lixados! :-\

Edited July 5, 2013 at 08:58 PM by marcolopes

[marcolopes]

Olha que logo no inicio da certificação eles iam nesse caminho, que devíamos certificar que ninguém conseguisse ter acesso aos dados.

Certo... mas bases de dados que suportem encriptação não existem como os cogumelos... e em caso de necessidade de edição "técnica" e / ou recuperação, seria um pouco caótico.

Agora, se a base de dados estiver do lado do prestador do serviço... uma fonte fidedigna... (AT, OTOC...) uma grande parte das questões de "segurança" (leia-se: possibilidade de "prevaricação") é colocada de imediato de parte... logo... uma grande mais valia aos "olhos do fisco"!

[marcolopes]

Pois é... Mas de repente lembram-se de revogar a excepção à lei da certificação (do software produzido internamente) e depois estou tramado, pois como é lógico, depois não há tempo para nada.

Mais vale te-la já pronta, e a qualquer momento olha, manda-se certificar.

A propósito, quanto é que se paga para certificar a aplicação?

Não existem "taxas" (o que é estranho!)

Pagas a deslocação a LX (caso não sejas de lá!) e um dia / tarde perdidos. Com sorte, aceitam-te as "rectificações", que terás(?) concerteza de fazer, por email... e tá feito.

Edited July 5, 2013 at 09:27 PM by marcolopes

[nunopicado]

Não existem "taxas" (o que é estranho!)

Pagas a deslocação a LX (caso não sejas de lá!) e um dia / tarde perdidos. Com sorte, aceitam-te as "rectificações", que terás(?) concerteza de fazer, por email... e tá feito.

Interessante...

Vai na volta, ainda faço isso! Qualquer dia!

[Sergio.]

Não sei se a ideia vai pegar, por várias razões:

- Ainda existe pessoas que gostam de ter os dados em "seu poder"

- Existe muitas empresas com especificidades nas aplicações a pedido, mesmo quando o negocio é o mesmo, não existe 2 clientes a trabalhar da mesma forma.

- A aplicação da OTOC é muito simplista, como muitas que existe no mercado que não são mais do que umas meras maquinas de escrever mais sofisticadas.

- Não responde a um grupo de empresas

- Não responder a produção industrial

- Tenho serias duvidas que responda a inventário permanente na contabilidade.

Mas provavelmente já responde à questão:

3.1.3. Controlo direto ou indireto da base de dados que utiliza e o registo do n.º de reposições de cópias de segurança (backup) efetuadas.

[marcolopes]

Como estão a tratar o ponto 2.5. Integração de documentos através de duplicados que não integram a cópia de segurança (backup), quando houver necessidade de reposição de dados por inoperacionalidade do sistema

Ao longo do tempo, algumas necessidades foram tomando nova forma... se "antigamente", os utilizadores voltavam a lançar os documentos "normalmente", actualmente tal não é possível...

Edited July 6, 2013 at 09:51 AM by marcolopes

[bugFree]

Como estão a tratar o ponto 2.5. Integração de documentos através de duplicados que não integram a cópia de segurança (backup), quando houver necessidade de reposição de dados por inoperacionalidade do sistema

Ao longo do tempo, algumas necessidades foram tomando nova forma... se "antigamente", os utilizadores voltavam a lançar os documentos "normalmente", actualmente tal não é possível...

Estive a verificar o SAFT_DEMO da AT e julgo que lá refere/responde de algum modo a esta questão.

Faz referência ao OC 50000/2012, mas julgo que o tratamento deva ser o mesmo.

Basicamente, será o mesmo tratamento que é dado aos documentos manuais.

Quer isto também dizer que teremos que ter séries manuais para todos os documentos "automáticos" que possam ser produzidos pela aplicação, pelo que percebo.

Não tive ainda tempo para me debruçar a sério sobre o OC 50001/2013, mas numa primeira impressão parece-me ser este o entendimento.

[marcolopes]

Estive a verificar o SAFT_DEMO da AT e julgo que lá refere/responde de algum modo a esta questão.

Faz referência ao OC 50000/2012, mas julgo que o tratamento deva ser o mesmo.

Basicamente, será o mesmo tratamento que é dado aos documentos manuais.

Quer isto também dizer que teremos que ter séries manuais para todos os documentos "automáticos" que possam ser produzidos pela aplicação, pelo que percebo.

Não tive ainda tempo para me debruçar a sério sobre o OC 50001/2013, mas numa primeira impressão parece-me ser este o entendimento.

Sim, esse é o entendimento. Mas o que me preocupa é a parte "técnica"...

1) O utilizador fez um RESTORE MANUAL da base de dados

2) O utilizador fez uma EMISSÃO normal de documentos para registar os documentos em falta... (não pode!)

Controlar pela DATA do sistema não é solução, pois os documentos em falta podem ser DO DIA... portanto, como controlar se o utilizador está, efectivamente, a registar os documentos em falta através do método correcto??

[JulioNobre]

Na minha opinião, uma forma de responder correctamente ao registo de documentos manuais (o que inclui a recuperação manual de documentos originalmente emitidos em software certificado, mas cuja integridade tenha sido posta em causa por avaria), consiste em:

- Criar, consoante necessário, uma série manual (classificada como tal) por cada tipo de documento previsto no SAFT, ou seja, uma para FT, outra para FS, ND, NC, GR, GT, etc. Tomando como exemplo, a série manual FT, nela podem ser lançadas todas as séries manuais relativas a documentos do tipo FT;

- Na tabela de documentos (cabeçalho), adicionar os seguintes campos:

- É documento manual? (S/N);

- Série original (*);

- Nr de sequência na série original (*);

- Data do documento original (*).

(*) A ser preencher pelo utilizador durante a recolha manual

- O utilizador que faz o registo não tem qualquer controlo sobre o nr de sequência atribuído a cada documento que é registado;

- Ao exportar para SAFT, os documentos manuais requerem uma codificação especial consiste declaração simultânea da SérieManual / NrSequênciaNaSérieManual em InvoiceNo e SérieOriginal / NrSequênciaOriginal em HashControl (para mais informações ver amostra)

Atenção aos efeitos secundários, entre os quais, destaco:

- A referência a estes documentos que passa a ser feita pelo SérieManual / NrSequênciaNaSérieManual e não pela SérieOriginal / NrSequênciaOriginal. Tomando como exemplo, a necessária referência impressa entre uma Fatura normal e uma Guia de Remessa manual, posteriormente registada no software onde a Fatura foi emitida, tratando-se da referência a um documento manual, deve apresentar-se a respectiva "GR SérieOriginal / NrSequênciaOriginal emitido DataOriginal);

- A obrigatoriedade de imprimir texto que permita identificar de forma clara quando um documento impresso representa uma "Cópia de documento original", requerendo ainda a impressão dos 4 caracteres do Hash respeitando um formato específico.

Espero que ajude 🙂

Edited July 9, 2013 at 10:11 AM by JulioNobre

[marcolopes]

Na minha opinião, uma forma de responder correctamente ao registo de documentos manuais (o que inclui a recuperação manual de documentos originalmente emitidos em software certificado, mas cuja integridade tenha sido posta em causa por avaria), consiste em:

- Criar, consoante necessário, uma série manual (classificada como tal) por cada tipo de documento previsto no SAFT, ou seja, uma para FT, outra para FS, ND, NC, GR, GT, etc. Tomando como exemplo, a série manual FT, nela podem ser lançadas todas as séries manuais relativas a documentos do tipo FT;

- Na tabela de documentos (cabeçalho), adicionar os seguintes campos:

- É documento manual? (S/N);

- Série original (*);

- Nr de sequência na série original (*);

- Data do documento original (*).

(*) A ser preencher pelo utilizador durante a recolha manual

- O utilizador que faz o registo não tem qualquer controlo sobre o nr de sequência atribuído a cada documento que é registado;

- Ao exportar para SAFT, os documentos manuais requerem uma codificação especial consiste declaração simultânea da SérieManual / NrSequênciaNaSérieManual em InvoiceNo e SérieOriginal / NrSequênciaOriginal em HashControl (para mais informações ver amostra)

Atenção aos efeitos secundários, entre os quais, destaco:

- A referência a estes documentos que passa a ser feita pelo SérieManual / NrSequênciaNaSérieManual e não pela SérieOriginal / NrSequênciaOriginal. Tomando como exemplo, a necessária referência impressa entre uma Fatura normal e uma Guia de Remessa manual, posteriormente registada no software onde a Fatura foi emitida, tratando-se da referência a um documento manual, deve apresentar-se a respectiva "GR SérieOriginal / NrSequênciaOriginal emitido DataOriginal);

- A obrigatoriedade de imprimir texto que permita identificar de forma clara quando um documento impresso representa uma "Cópia de documento original", requerendo ainda a impressão dos 4 caracteres do Hash respeitando um formato específico.

Espero que ajude 🙂

Excelente resumo, com o qual concordo (aliás, já estou a controlar o registo manual de documentos emitidos em caso de FALHA de sistema - embora com algumas limitações relativamente ao detalhe de campos necessários - como sendo - separar a SERIE e o NUMERO por forma a não existirem problemas na introdução da ref. ao documento manual...)

De qualquer forma, continuo com a mesma dúvida...

COMO saber se o utilizador está a efectuar a operação correcta??? Coloquei a dúvida relativa a uma reposição da base de dados, onde o utilizador LANÇA os documentos "perdidos" de forma "normal", e não nas séries de "registo manual"...

[americob]

Excelente resumo, com o qual concordo (aliás, já estou a controlar o registo manual de documentos emitidos em caso de FALHA de sistema - embora com algumas limitações relativamente ao detalhe de campos necessários - como sendo - separar a SERIE e o NUMERO por forma a não existirem problemas na introdução da ref. ao documento manual...)

De qualquer forma, continuo com a mesma dúvida...

COMO saber se o utilizador está a efectuar a operação correcta??? Coloquei a dúvida relativa a uma reposição da base de dados, onde o utilizador LANÇA os documentos "perdidos" de forma "normal", e não nas séries de "registo manual"...

Também me parece uma abordagem correta ao problema e está dentro do que eu já fazia.

No meu caso, uma recolha de Documento Manual só pode ser introduzida numa série "livre" (sem documentos emitidos). Depois de introduzido um Documento Manual essa série só aceita documentos manuais.

Só questiono a necessidade da "Data do Documento Original" e porque não o utilizador recolher com a data do documento original, evidentemente respeitando no SystemEntryDate a data da recolha.

O problema põe-se que se um documento "perdido" for de determinado mês e se só for novamente recolhido no mês seguinte, como fica em termos de "e-fatura", contabilidade, etc.

Se o utilizador estiver a "lançar" os documentos perdidos de forma "normal", não tem lá os campos para identificar o número e série do documento recolhido, logo não está a recolher mas sim a emitir novos.

[marcolopes]

Se o utilizador estiver a "lançar" os documentos perdidos de forma "normal", não tem lá os campos para identificar o número e série do documento recolhido, logo não está a recolher mas sim a emitir novos.

Os utilizadores fazem de tudo... e tenho casos em que já fizeram a recuperação "lançando" novamente os documentos!!! (problema? a HASH... não será igual, devido ao SystemEntryDate)

[JulioNobre]

Na minha opinião, ao lançar numa série manual devem ser seguidas as seguintes regras:

- O utilizador NÃO DEVE ser acesso:

• - Ao nr de sequência da série manual que corresponde à sequência de registo de documentos manuais ;
  
• - À data em que está a ser realizado o registo.. Em condições normais, esta data corresponde à Data de Emissão. Só que, aqui, assume o significado de Data de Registo, por se tratar em um série manual.
  

- O utilizador DEVE, OBRIGATORIAMENTE, preencher:

• - A identificação da série original;
  
• - O nr de sequência do documento original (previamente emitido em sistema informático ou em papel tipográfico);
  
• - Data em que o documento original foi emitido.
  

Para terminar, recordo que embora estejamos perante uma recolha de documentos previamente emitidos, mantêm-se a exigência de assinar digitalmente estes documentos, mas, desta vez, com base dos dados obrigatórios da assinatura do actual tipo, SérieManual e NrSequenciaNaSerieManual combinado com o documento anterior do mesmo tipo/série. Por outras palavras, na assinatura de documentos registados em séries manuais, não são utilizados os campos que contêm a SérieOriginal nem a NrSequênciaNaSérieOrginal.

Fui claro?

Edited July 9, 2013 at 12:26 PM by JulioNobre

[marcolopes]

Para terminar, recordo que embora estejamos perante uma recolha de documentos previamente emitidos, mantêm-se a exigência de assinar digitalmente estes documentos, mas, desta vez, com base dos dados obrigatórios da assinatura do actual tipo, SérieManual e NrSequenciaNaSerieManual combinado com o documento anterior do mesmo tipo/série.

Discordo. Como é feita posteriormente a VERIFICAÇÃO da assinatura??

Edited July 9, 2013 at 12:25 PM by marcolopes