• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

marcolopes

AT - questões legais

4263 posts in this topic

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.

1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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 by marcolopes
3

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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 by thoga31
0

Share this post


Link to post
Share on other sites

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 by marcolopes
0

Share this post


Link to post
Share on other sites

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"!

0

Share this post


Link to post
Share on other sites

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 by marcolopes
1

Share this post


Link to post
Share on other sites

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!

0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

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 by marcolopes
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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??

0

Share this post


Link to post
Share on other sites

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 by JulioNobre
1

Share this post


Link to post
Share on other sites

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"...

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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)

0

Share this post


Link to post
Share on other sites

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 by JulioNobre
0

Share this post


Link to post
Share on other sites

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 by marcolopes
0

Share this post


Link to post
Share on other sites

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.

Discordo de um ponto ... Penso que a assinatura da hash deve ser com o tipo do documento a série do software e o número do software em vez dos dados manuais

0

Share this post


Link to post
Share on other sites

O Julio não deixa de ter razão...

As séries de documentos manuais são:

- Documentos em si mesmos, pelo que são assinados como qualquer outro documento.

A HASH é criada para ele proprio, pois não é permitido criar novamente uma HASH para outro documento (neste caso, o original)

- Obrigam à indicação do documento original

- Obrigam à inserção destes valores no campo HashControl.

Logo, a Hash é criada e se tiver de ser verificada é face aos dados do documento que as originou, ou seja, o documento da serie manual

Ao estar no HashControl (estupidez da AT) o documento original, está "provado" que não houve fuga, apenas houve um "acidente" que foi corrigido por esse método

Só não percebo porque não um campo só para isso... Para quê usar o HashControl, se este é, ou deveria ser, a versão da hash?

Creio que a confusão até pode vir daqui, mas o raciocinio do Julio parece-me correcto.

0

Share this post


Link to post
Share on other sites

Os oducmen

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

Uma vez que, por Lei, um documento certificado apenas pode ser assinalado uma única vez - no momento em que é originalmente emitido, não é possível verificar assinatura de documentos registados, mas previamente emitidos em software certificado. Neste caso, a validação apenas permitir saber que um documento previamente registado/recuperado não sofreu alterações desde que foi registado na série manual. Para mais, tal como o Marco refere, a componente da assinatura SystemEntryDate, combinada com a assinatura do documento anterior na mesma série, serve precisamente para garantir a autenticidade da assinatura original. Quanto aos documentos tipográficos, a questão da autenticidade não se coloca, desde que as respectivas vias se encontrem legíveis dentro dos termos da Lei.

De facto, o registo em série manuais, previsto pela certificação, tem várias implicações que não são imediatamente óbvias.

Fui claro?

Edited by JulioNobre
0

Share this post


Link to post
Share on other sites

O Julio não deixa de ter razão...

As séries de documentos manuais são:

- Documentos em si mesmos, pelo que são assinados como qualquer outro documento.

A HASH é criada para ele proprio, pois não é permitido criar novamente uma HASH para outro documento (neste caso, o original)

- Obrigam à indicação do documento original

- Obrigam à inserção destes valores no campo HashControl.

Logo, a Hash é criada e se tiver de ser verificada é face aos dados do documento que as originou, ou seja, o documento da serie manual

Ao estar no HashControl (estupidez da AT) o documento original, está "provado" que não houve fuga, apenas houve um "acidente" que foi corrigido por esse método

Só não percebo porque não um campo só para isso... Para quê usar o HashControl, se este é, ou deveria ser, a versão da hash?

Creio que a confusão até pode vir daqui, mas o raciocinio do Julio parece-me correcto.

Continuo a achar que a hash deve ser calculada com os dados que indiquei antes ... Aliás é mencionado a a existência de campos específicos para o número e série manual isso deduzir é o documento deve ter numeração própria e série própria dentro da aplicação sendo somente utilizada a data do documento to manual

0

Share this post


Link to post
Share on other sites

Continuo a achar que a hash deve ser calculada com os dados que indiquei antes ... Aliás é mencionado a a existência de campos específicos para o número e série manual isso deduzir é o documento deve ter numeração própria e série própria dentro da aplicação sendo somente utilizada a data do documento to manual

Então, mas foi isso que disse o Julio e eu...

A hash é calculada em função dos dados do documento que se está a criar (na serie manual), e não em função do documento manual em si (ou documento recuperado).

0

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